/generate

name: generate
description: >-
  Phase 2 of the prd-taskmaster pipeline: spec generation and task parsing.
  Loads a template (comprehensive|minimal), fills it with DISCOVER-phase
  constraints and answers, validates the spec (placeholders_found, grade
  thresholds), parses the PRD into tasks via task-master, runs TaskMaster's
  native complexity analysis, and expands every task into verifiable subtasks.
  Autonomous-safe. Declares GENERATE complete so HANDOFF can follow.
user-invocable: false
allowed-tools:
  - Read
  - Write
  - Edit
  - Bash
  - Skill
  - ToolSearch
  - mcp__atlas-engine
  - mcp__plugin_prd_go
  - mcp__plugin_prd-taskmaster_go
  - mcp__plugin_atlas-go_go

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:

| Scale | Task Count | Subtask Depth | |------------|-----------|------------------| | Solo | 8–12 | 2–3 subtasks each | | Team | 12–20 | 3–5 subtasks each | | Enterprise | 20–30 | 5–8 subtasks each |

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:

| Software term | Neutral equivalent | When to use neutral | |---------------|-------------------|---------------------| | tests | verification criteria | pentest, business, learning | | code | deliverable | business, learning | | deploy | execute / deliver | business, learning | | repo | workspace | non-software | | PR | output / submission | non-software |

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: