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.