spec-writer

这段内容是审核时保存的快照。外部来源才是完整且最新的版本。

---
name: spec-writer
description: Create a comprehensive Product Requirements Document from conversation and repo context. Use when the user wants a PRD, product spec, feature requirements, or similar documentation.
metadata:
  author: kambleakash0
  version: 1.0.0
triggers:
  - /spec
  - /spec-writer
---

# Write a Product Requirements Document

This skill turns a clarified idea into a **structured PRD** using conversation and repository context. It assumes that major ambiguities have already been grilled out (for example with `/grill-me`), but it can also perform its own lightweight clarification when needed.

## When to Use

Use this skill when the user:

- Asks to "write a PRD", "product spec", "requirements doc", "feature specification", or similar.
- Wants to document a new feature, change, or system in a structured way before implementation.
- Has already clarified the idea and now needs a single, coherent document you can file as an issue, share with stakeholders, or feed into `/slice-the-spec`.

If the idea is still fuzzy or underspecified, recommend using `/grill-me` first and then come back to this skill.

## Overall Workflow

You may skip or compress steps that are clearly already complete (for example, if the user pastes a detailed problem statement or user story list).

1. **Collect a rich problem description**
   - Ask the user for a long, detailed description of:
     - The problem they want to solve
     - Who it is for
     - Why it matters now
     - Any initial solution ideas or constraints they already have
   - Encourage them to paste existing context (docs, tickets, research) instead of re‑typing everything.

2. **Explore the repo and verify assumptions**
   - Inspect the codebase to understand current behavior, relevant modules, data models, and existing APIs.
   - Cross‑check the user’s assertions: note where the repo agrees, disagrees, or is silent, and adjust your understanding accordingly.
   - Capture any repo‑grounded facts that will matter for scope, edge cases, or implementation constraints.

3. **Consider alternative approaches**
   - Ask the user whether they have considered other solution options or design directions.
   - Briefly outline 2–3 plausible approaches, with trade‑offs (complexity, time‑to‑ship, risk, UX impact).
   - Confirm which approach you should treat as the primary one for this PRD.

4. **Deep implementation interview (if needed)**
   - If the requirements still feel high‑level, interview the user about how they want it to behave in detail: flows, states, inputs/outputs, failure modes, permissions, and performance expectations.
   - Where answers depend on existing behavior, prefer inspecting the repo over guessing.
   - Make assumptions explicit and ask for confirmation.

5. **Hammer out exact scope**
   - Work out what will be **in scope** and explicitly list what is **out of scope** for this PRD (e.g., deferred edge cases, nice‑to‑haves, follow‑ups).
   - Clarify the target release slice (MVP vs full feature) and any sequencing or phase‑1/phase‑2 distinctions.

6. **Sketch modules and architecture (lightweight)**
   - Identify the major modules, services, or components that will be created or modified.
   - Call out opportunities to extract deep, testable modules that can be validated in isolation (good for later TDD or `/tdd` usage).

7. **Write the PRD using a structured template**
   - Draft a complete PRD with clearly labeled sections (see template below).
   - Use plain, precise language suitable for engineers, PMs, and designers.

8. **File it where it belongs (optional)**
   - If appropriate, format the PRD as a GitHub issue or markdown file according to the repo’s conventions.
   - Include labels, owners, and links to related issues or docs if the context provides them.

## PRD Template

Use and adapt this structure. You can omit sections that are clearly irrelevant, but err on the side of including them.

### 1. Summary

- 2–3 sentences describing **what** we ar