Generate

Phase 2: Generate

Declarative phase skill. Invoked by the prd-taskmaster orchestrator when current_phase is GENERATE. Never called directly by a user.

The one rule: generate the spec, validate it catches placeholders, parse it into tasks, expand every task into subtasks. Quality over speed.

Entry gate

1. Call mcp__plugin_prd_go__check_gate(phase="GENERATE", evidence={}) for diagnostics.

   check_gate is an EXIT gate: it checks task_count > 0, subtask_coverage >= 1.0, and validation_grade in (EXCELLENT, GOOD) — all of which are GENERATE's OWN OUTPUTS, i.e. evidence to advance, not preconditions to enter. On first entry none exist yet, so a gate_passed: false here is EXPECTED — the state machine's legal transitions already guarantee only legal entry.

   • First entry (no evidence yet): note the result and continue with the Procedure.
   • Re-entry: if the gate reports violations, report them and stop — it protects against re-running a completed phase or skipping ahead from DISCOVER.

2. Read the DISCOVER output (discovery summary + CONSTRAINTS CAPTURED block

   • scale classification). If any of these are missing, report and stop — the gate should have caught this, but belt-and-braces.

Generate checklist

Copy into your response before running the procedure:

GENERATE CHECKLIST:
- [ ] Template loaded (comprehensive|minimal)
- [ ] Spec written with discovery answers (no bare placeholders remaining)
- [ ] CONSTRAINT CHECK: every DISCOVER constraint appears in the spec
- [ ] SCOPE CHECK: task count matches scale (Solo 8-12, Team 12-20, Enterprise 20-30)
- [ ] Validation score: ___ / ___ (grade: ___)
- [ ] placeholders_found: ___ (bare placeholders = 0 required)
- [ ] Warnings addressed or acknowledged
- [ ] Tasks parsed: ___ tasks created
- [ ] Complexity analyzed via TaskMaster: Y/N
- [ ] All tasks expanded into subtasks: Y/N

Step 1: Choose and load template

Decide based on discovery depth:

• Comprehensive: 4+ detailed answers, complex project, Team / Enterprise scale
• Minimal: thin answers, user wants speed, Solo scale

MCP (preferred): mcp__plugin_prd_go__load_template(type="comprehensive")

CLI fallback: python3 script.py load-template --type comprehensive

The template is the canonical shape — do not invent your own. If the template load fails, report and stop. Do not paper over with a home-rolled skeleton.

Step 2: Generate spec at .taskmaster/docs/prd.md

Fill the template with discovery answers. AI judgment required:

• Replace ALL placeholders with actual content pulled from DISCOVER.
• Expand with project-specific details — do not leave template prose verbatim.
• Add technical depth proportional to what the user provided in discovery.
• Generate domain-appropriate sections (pentest = threat model, app = user stories, business = success metrics, learning = assessment criteria).
• Document assumptions where discovery was thin — explicitly, not silently.

CONSTRAINT CHECK (MANDATORY)

Verify EVERY constraint from the DISCOVER phase CONSTRAINTS CAPTURED block appears in the spec. If "must use Python" was a constraint, the spec MUST reference Python. Missing constraints = spec bug.

Emit the check explicitly:

CONSTRAINT CHECK:
- Tech stack (Python): FOUND in spec section "Technical Stack"
- Timeline (MVP in 2 weeks): FOUND in spec section "Milestones"
- ...

Every constraint must be marked FOUND. If any are MISSING, loop back and fix the spec before proceeding.

SCOPE CHECK (MANDATORY)

Use the scale classification from DISCOVER to set task count range:

If DISCOVER classified the project as Team but the spec implies 30 tasks, that's a scope bug — narrow the spec or re-classify explicitly.

Domain-neutral vocabulary

When the domain is unclear, default to neutral terms:

If the domain IS software, use software terms. Neutral terms are for non-software goals.

Deferred decisions — the reason: convention

Every [placeholder], {{variable}}, [TBD], [TODO] must be either:

(a) Replaced with real content, (b) Removed entirely, or (c) Paired with a reason: explanation on the same line or the next line documenting why the decision is deferred.

Per the v4 spec: placeholders with reason: attribution are allowed and surfaced in the validation output as deferred_decisions. A bare placeholder is a validation failure; an attributed one is a known deferred decision with accountability.

Examples:

# BAD — bare placeholder, fails validation:
Target latency: {{TBD}}

# GOOD — attributed, appears in deferred_decisions:
Target latency: {{TBD}} reason: awaiting load-test results scheduled 2026-04-20

Write the final spec to .taskmaster/docs/prd.md. This is the canonical path — downstream tools read from here.

Step 3: Validate spec quality

MCP (preferred): mcp__plugin_prd_go__validate_prd(input_path=".taskmaster/docs/prd.md")

CLI fallback: python3 script.py validate-prd --input .taskmaster/docs/prd.md

Returns: score, grade, checks, warnings, placeholders_found. The validate call persists its result, so render the GENERATE scorecard and print it: MCP render_status(phase="GENERATE") → print rendered; CLI python3 script.py status --phase GENERATE.

Optional AI-augmented review (opt-in): pass --ai (CLI) or ai=True (MCP) to additionally invoke TaskMaster's configured main model for a holistic quality review. The deterministic regex checks always run first — AI review is additive, never a replacement.

Grading thresholds:

• EXCELLENT: 91%+
• GOOD: 83–90%
• ACCEPTABLE: 75–82%
• NEEDS_WORK: <75%

Decision rules:

• If placeholders_found > 0 (bare placeholders, not reason:-attributed): fix before proceeding. No exceptions.
• If grade is NEEDS_WORK: offer auto-fix or proceed-with-risk — do not silently advance. Surface the decision.
• If grade is ACCEPTABLE or better AND placeholders_found == 0: proceed to Step 4.

Step 4: Parse tasks via backend

Calculate task count first:

MCP: mcp__plugin_prd_go__calc_tasks(requirements_count=<count>)

CLI: python3 script.py calc-tasks --requirements <count>

Then parse through the normative backend operation:

backend op parse-prd: python3 script.py parse-prd --input .taskmaster/docs/prd.md --num-tasks <recommended>

TaskMaster backend direct methods (only when explicitly operating that backend):

• MCP: mcp__task-master-ai__parse_prd(input=".taskmaster/docs/prd.md", numTasks=<recommended>)
• MCP fallback: mcp__plugin_prd_go__tm_parse_prd(input_path=".taskmaster/docs/prd.md", num_tasks=<recommended>)
• CLI: task-master parse-prd --input .taskmaster/docs/prd.md --num-tasks <recommended>

The backend operation writes to .taskmaster/tasks/tasks.json. Verify the file exists and contains the expected number of tasks before continuing.

Step 5: Rate complexity via backend

Use the normative backend operation instead of home-rolled classification:

backend op rate: python3 script.py rate

TaskMaster backend direct methods (only when explicitly operating that backend):

• MCP: mcp__task-master-ai__analyze_complexity (analyzes all tasks)
• MCP fallback: mcp__plugin_prd_go__tm_analyze_complexity (wraps the CLI)
• CLI: task-master analyze-complexity

Important — output location: the analyze-complexity step does NOT emit JSON to stdout. It writes structured analysis to .taskmaster/reports/task-complexity-report.json and prints a human-readable table to stdout. To read the structured result, read the report file:

cat .taskmaster/reports/task-complexity-report.json | jq .

Do not try to parse the stdout table — it's colour-coded ASCII and will break consumers. TaskMaster's built-in analysis is more accurate than anything hand-rolled because it has full context of the task graph and dependencies.