generate

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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,

From anombyte93/prd-taskmaster, MIT.

More from anombyte93/prd-taskmaster