Flutter Template Spec Feature

Single entry point that runs the full feature specification pipeline from idea to implementation-ready tasks. It is designed to be invoked once; each sub-skill may pause for user input during its mandatory clarification steps — that is intentional and correct. After each sub-skill finishes, this orchestrator automatically invokes the next phase without requiring the user to type the next command.

Use this when you want to go from a feature idea directly to a full task breakdown, without manually running /prd, /techspec, and /tasks in sequence.

Prerequisites

• No existing prd.md or techspec.md for this feature (or the user has confirmed it is safe to overwrite).
• The user can answer clarification questions — both prd and techspec have mandatory interactive clarification steps that will pause the pipeline for user input.

If a PRD and tech spec already exist and are complete, use /start-job [feature-name] instead.

Arguments

Accepts an optional feature name. If provided, pass it to each sub-skill so they can pre-fill the folder name and skip asking. If omitted, the prd sub-skill will determine the feature name during its workflow.

Pipeline

Run each phase in order. Between phases, do NOT ask for user approval — the sub-skills themselves handle all necessary user interaction. If a phase fails hard (the sub-skill reports an unrecoverable error), stop and surface it to the user.

Critical orchestration rule: when a sub-skill returns control, do not treat its output as the end of your turn. You are still inside this /spec-feature orchestrator. Immediately invoke the next phase's skill in the same response. The only valid stops are: (a) a sub-skill's mandatory clarification pause (which is correct — wait for the user, then resume), (b) a hard failure, or (c) the Final Report after Phase 3.

Phase 1 — Product Requirements Document

Invoke the prd skill (pass the feature name argument if provided).

The prd skill has two mandatory interactive steps: it will ask clarifying questions (Step 1) and present a plan for confirmation (Step 2). These pauses are correct — wait for user responses. After the user confirms the plan and prd saves prd.md, it will return control.

After prd returns (i.e., after prd.md has been saved): do not stop, do not wait for additional input, do not summarize. Immediately invoke techspec (Phase 2) in the same response.

Phase 2 — Technical Specification

Invoke the techspec skill (pass the feature name argument if provided).

The techspec skill has one mandatory interactive step: it will ask technical clarification questions (Step 3). This pause is correct — wait for user responses. After the user answers and techspec saves techspec.md, it will return control.

After techspec returns (i.e., after techspec.md has been saved): do not stop, do not wait for additional input, do not summarize. Immediately invoke tasks (Phase 3) in the same response.

Phase 3 — Task Breakdown

Invoke the tasks skill (pass the feature name argument if provided).

The tasks skill runs without approval prompts and generates tasks.md plus individual task files. When invoked from this orchestrator (not directly by the user), tasks must skip its next-step prompt and return control here.

After tasks returns: produce the Final Report. This is the only place the pipeline stops on success.

Final Report

Output a single consolidated summary:

• Feature name and the folder created under .claude/tasks/
• What the PRD captured (problem statement, target platforms, scope boundaries)
• Key technical decisions from the tech spec (state model, data sources, navigation shape, any new packages needed)
• Task count, phases, and dependency shape
• Reminder: the feature is now ready for implementation. Run /start-job [feature-name] to execute the implementation pipeline, or step through manually with /implement-tasks-sequence.

Rules

• Never commit. This pipeline only produces spec and task files.
• Never skip sub-skill clarification steps. The mandatory interactive steps in prd and techspec exist to capture requirements accurately. Do not bypass or pre-answer them.
• Do not edit generated specs. After prd or techspec writes a file, do not rewrite it as the orchestrator. Only the sub-skill owns its output.
• Stop on hard failure. If a phase cannot proceed (missing context, the sub-skill reports an unrecoverable error), stop and surface the issue to the user — do not continue on a broken base.
• Pass the feature name through. If an argument was provided, pass it consistently to all three sub-skills so the folder name stays stable across phases.