メニュー
Use when running /business:prd, after a Vision.md exists — derives a product-level epic list from the vision's goals. Philosophy adapted from BMAD-METHOD's PM-stage discovery.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/KiemVM/AI-SDLC --skill prd-writingコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Use when running /decide, or whenever a product/technical decision changes something already written (a spec, plan, architecture doc) mid-work — captures it as an ADR and finds what needs to be updated downstream. Philosophy adapted from GitHub Spec-Kit's ADR discipline and BMAD-METHOD's documentation-first governance.
Use when running /spec:plan, after a Specification.md exists and before task breakdown — turns approved requirements into a technical approach, file structure, and testing strategy. Philosophy adapted from GitHub Spec-Kit's plan phase and BMAD-METHOD's architecture discipline.
Use when running /engineering:review, or whenever asked to review a diff or PR for bugs and spec/constitution adherence. If the host project already has Anthropic's official code-review plugin configured, prefer that instead. Philosophy adapted from Superpowers' code-review discipline.
SOC 職業分類に基づく
SKILL.md を表示中
| name | prd-writing |
| description | Use when running /business:prd, after a Vision.md exists — derives a product-level epic list from the vision's goals. Philosophy adapted from BMAD-METHOD's PM-stage discovery. |
A PRD sits between the vision (why/for whom) and feature specs (what a single feature does).
Its job is to decompose the vision's goals into epics — coherent clusters of capability —
at a level still too coarse to implement directly. Each epic becomes a candidate slug for a
future /spec:spec run.
/business:architecture or /spec:plan.Do not write functional requirements here — that's /spec:spec's job, one feature at a time,
once an epic is picked up for implementation. If you catch yourself writing "the system MUST
...", that sentence belongs in a Specification.md, not the PRD.
| Red flag | Why it matters |
|---|---|
| An epic reads like a functional requirement ("MUST validate email format") | Too granular — that belongs in a feature spec |
| An epic has no traceable vision goal | Likely scope creep slipping in without justification |
| Every epic is priority "Must" | Prioritization didn't actually happen |