Inno Pipeline Planner

inno-pipeline-planner

Canonical Summary

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...

Trigger Rules

Use this skill when the user request matches its research workflow scope. Prefer the bundled resources instead of recreating templates or reference material. Keep outputs traceable to project files, citations, scripts, or upstream evidence.

Resource Use Rules

• Read from references/ only when the current task needs the extra detail.

Execution Contract

• Resolve every relative path from this skill directory first.
• Prefer inspection before mutation when invoking bundled scripts.
• If a required runtime, CLI, credential, or API is unavailable, explain the blocker and continue with the best manual fallback instead of silently skipping the step.
• Do not write generated artifacts back into the skill directory; save them inside the active project workspace.

Upstream Instructions

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".