/inno-pipeline-planner

name: inno-pipeline-planner
description: Guides the user through an interactive conversation to define their research project, then generates research_brief.json and tasks.json. Use when starting a new project, when no research_brief.json exists, when the user wants to start from a specific pipeline stage, or when the user wants to redefine their research pipeline.

Inno Pipeline Planner

Run an interactive planning flow that turns user conversation into:

• `.pipeline/docs/research_brief.json`
• `.pipeline/tasks/tasks.json`

Keep this file short. Load full schemas and field-level rules from:

• `references/pipeline-contract.md` (index)

Read only what you need:

• `references/generation-rules.md`: generation logic, ordering, dependencies, `nextActionPrompt`
• `references/brief-schema.md`: `.pipeline/docs/research_brief.json` contract
• `references/tasks-schema.md`: `.pipeline/tasks/tasks.json` contract

Non-negotiables

• Work only inside the current project directory.
• Do not fabricate papers, datasets, metrics, or results.
• Ask follow-up questions when information is vague; do not guess.
• Ask in small batches (2-3 questions), not a long static form.

Workflow

1) Inspect existing pipeline state

Check:

• `.pipeline/docs/research_brief.json`
• `.pipeline/tasks/tasks.json`
• `instance.json` (legacy source)
• Content in `Survey/`, `Ideation/`, `Experiment/`, `Publication/`, and `Promotion/` directories (to detect pre-existing artifacts)

If brief exists, summarize title, goal, current `startStage`, and completion status, then ask:

• Refine existing brief/tasks
• Regenerate from scratch
• Change the starting stage

2) Collect project context via conversation

Capture at least:

• Topic/problem
• Goal or hypothesis
• Success criteria or evaluation signal
• Current survey depth or known reference set

**Determine the starting stage** early in the conversation:

• Ask what the user already has: "Do you already have a research idea, experimental results, or are you starting from scratch?"
• If the user mainly needs literature review, gap analysis, or reference collection -> `startStage = "survey"`
• If the user has a concrete idea with problem framing and success criteria -> `startStage = "experiment"`
• If the user has experimental results and analysis -> `startStage = "publication"`
• If the user already has a paper/manuscript and mainly needs a homepage, slide deck, narration, or demo assets -> `startStage = "promotion"`
• If the user is starting from scratch or only has a vague direction -> `startStage = "survey"` (default)
• Detect automatically from conversation context (e.g., "I already ran all experiments" implies publication; "I need slides for my paper" implies promotion).

Typical question buckets:

• Project identity: topic, prior paper/method/dataset, target venue (optional)
• Scope and method: core question, approach, expected outcome
• Evaluation: data source, metrics/protocol, baseline expectations

Adapt to context:

• Skip already-provided details.
• **Skip questions for stages before `startStage`**: If starting from experiment, do not ask survey or ideation questions in detail — just capture a brief summary of the existing context in those sections.
• If exploratory, keep experiment/publication/promotion sections lightweight.
• If user provides concrete plan, prepare for `pipeline.mode = "plan"`; otherwise use `"idea"`.

3) Write pipeline files

Create if missing:

• `.pipeline/config.json`
• `.pipeline/docs/research_brief.json`
• `.pipeline/tasks/tasks.json`

Use the exact JSON contracts and generation rules in:

• `references/pipeline-contract.md` and linked reference files

Rules:

• Set `pipeline.startStage` to the determined starting stage (default: `"survey"`).
• **Generate tasks only for stages >= `startStage`** in the stage order (survey < ideation < experiment < publication < promotion).
• For skipped stages: still populate their `sections.*` fields in the brief with whatever context the user provided, but do not create task blueprints or tasks for them.
• Tailor blueprint titles/descriptions to the user topic (never generic filler).
• Keep quality gates domain-appropriate.
• Resolve recommended skills from local available skills (`.agents/skills/` or `skills/`), optionally using `stage-skill-map.json` if present.

4) Summarize and confirm next action

After writing files, present:

• Brief summary (title, goal, starting stage, filled vs missing sections)
• Task overview (count by stage + first 2-3 task titles per stage) — only for active stages
• Recommended first task and why

5) Handle iteration requests

If user asks for updates:

• Update brief content directly when only text/content changes.
• Regenerate `tasks.json` when pipeline structure/blueprints/stages change.
• **If user asks to change the starting stage**: update `pipeline.startStage` in the brief, then regenerate `tasks.json` to include only the active stages.
• If asked to add one task only, append a single task with next numeric `id` instead of full regeneration.