prd

Files (1)

• SKILL.md

SKILL.md (first lines)

# fsad-harness:prd — PRD & Spec Writing Agent

Follow these phases in order. Show each artifact to the user for approval before moving to the next phase. Never skip a gate.

## Asking the user

This rule covers every question this skill asks the user: a confirmation, a choice, a missing value, a numbered decision list, or a stop-and-ask. It applies even where a later step says "ask the user" or "ask exactly once". The user may watch the decisions pane rather than the chat, so a question that only goes to chat can go unanswered.

- **When `mcp__decision-tracker__decision` is in your tool list** (loaded, or named as a deferred tool; load a deferred one with `ToolSearch` first), log each question before you ask it:
  1. Call it with `action: "open"`, the question (ending in `?`), and `options` when the answers are a closed set. Set `required: false` when the work can go on without an answer. A numbered list of questions opens one decision per item. Keep each returned `id`.
  2. Ask the question in chat as this skill says. The open call does not replace the chat question.
  3. When the user answers, in chat or as a `Decision Dn: <answer>` message from the plugin, call the tool with `action: "close"`, the `id` and the answer.
  4. When the change the answer asked for is in place, call it with `action: "implement"`, the `id` and a `path:line`.
- **When the tool is absent**, ask in chat only.
- An `AskUserQuestion` call is logged on its own. Do not open it again.
- This rule changes where a question is logged. It does not change when this skill asks, or how many times.

## Role definitions

This skill uses two role briefs embedded below:
- **Analyst Role** — discovery interviewer (BMAD Analyst pattern)
- **PM Role** — spec-writing PM (GitHub Spec Kit PM pattern)

Read both role sections below before proceeding.

## Success criteria (checkable, not prose)

By the end of Phase 4, all of the following must hold. The Phase 4 verifier (below) checks these mechanically before the summary prints:

1. Every user story in `spec.md` has at least one falsifiable AC under it.
2. Every AC in `spec.md` is covered by at least one task's `acs` in `tasks.json`.
3. No task in `tasks.json` has an empty `acs` array.
4. No AC text matches a vague/unfalsifiable pattern (e.g. "works correctly", "is intuitive", "looks right", "handles errors" with no specifics).
5. `tasks.json` has no dependency cycles.

## Step 0 — Parse arguments and establish context

1. **Title/goal** — use the argument if provided. If empty, ask: *"What are you building or improving? Give me a one-line goal."*
2. **Project root** — determine the current working directory. This is the project root.
3. **Output directory** — resolve `{project_root}/planning/prd/{slug}/` where `{slug}` = title lowercased, spaces and non-alphanumerics → `_`, collapsed. Create the directory if it doesn't exist.
4. **Confirm the output path** to the user before starting: *"I'll write artifacts to `planning/prd/{slug}/`. Starting discovery now."*

## Phase 1 — Discovery (Analyst role)

Adopt the Analyst persona from the Analyst Role section below.

Track the five discovery goals from that section (problem framing, impact, success definition, constraints, scope boundaries) as a checklist. Ask discovery questions **one at a time** — never dump a list. Wait for each answer before asking the next.

**Condition-based loop, not a fixed count:** keep asking until every discovery goal has a concrete, non-vague answer, or until 8 questions have been asked (hard cap) — whichever comes first. If the cap is reached with goals still unanswered, note which ones are still open and proceed with a stated assumption for each, rather than blocking indefinitely.

When discovery is complete, summarize findings in 3–5 bullet points and ask the user: *"Does this capture the problem correctly? Anything to correct before I write the spec?"*

Incorporate corrections, then proceed to Phase 2.

## Phase 2 — Specify (PM role)

Adopt the PM persona from the PM Role section below.

Using the discovery summary, draft `spec.md` using the section structure from the PM Role:
- Problem Statement
- Target Users
- Goals / Non-Goals
- User Stories (numbered)
- Acceptance Criteria (per story, `- [ ]` checkboxes)
- Success Metrics
- Risks & Mitigations
- Dependencies

Every user story must have at least one AC under it (success criterion 1). Reject and rewrite any AC that matches a vague/unfalsifiable pattern before writing the file (success criterion 4) — e.g. "works correctly", "is intuitive", "looks right" are not acceptable; "form submit button is disabled until all required fields are non-empty" is.

Write the draft to `{output_dir}/spec.md`.

Show the draft path to the user and ask: *"`spec.md` written. Review it and tell me what to change, or say 'approved' to move to the Plan phase."*

Do not proceed until the user approves.

## Phase 3 — Plan (Technical design)

Ask the user: *"Any technical constraints I should know? (e.g. stack, existing APIs to reuse, performance requirements, auth model)"*

Wait for the answer. If the user says "none" or "use your judgment", proceed with reasonable assumptions and note them.

Draft `plan.md` containing:

```markdown
# [Feature Title] — Technical Plan

## Technical Approach
[How it will be built. Architecture, patterns, key decisions.]

## Key Components
- [Component / file / module and its responsibility]
- [Component / file / module and its responsibility]

## Data Model
[Schema changes, new types, or "no data model changes" if applicable.]

## Integrations & Dependencies
[External APIs, libraries, or services required.]

## Out of Scope (Technical)
[What technical work is explicitly deferred.]

## Assumptions
- [Technical assumption 1 — flag if wrong]
- [Technical assumption 2 — flag if wrong]
```

Write the draft to `{output_dir}/plan.md`.

Show the draft path and ask: *"`plan.md` written. Review it and tell me what to change, or say 'approved' to move to task decomposition."*

Do not proceed until the user approves.

## Phase 4 — Tasks (Decomposition)

Using `spec.md` and `plan.md` as inputs, decompose the work into a dependency-ordered task list.

### Structured output

From tbeack/fsad_playbook, MIT.

More from tbeack/fsad_playbook