writing-prd

PRD の作成

概要

あらゆるリポジトリで使用できる、PRD のテンプレートと書式ルールです。これはインタビューではありません。会話ですでに分かっていることからドキュメントを作成し、必須セクションを本当に埋められない場合に限って質問してください。

使用するタイミング

• ユーザーが PRD、「продуктовые требования」、「product requirements document」の作成やドラフトを依頼した場合。
• 目標やスコープがまだ決まっていない場合は、まず superpowers:brainstorming を実行してください。PRD は決定を文書化するものであり、決定を下すものではありません。

保存場所と命名規則

ロードマップと同じ docs/ の規則を使用します（roadmap/SKILL.md を参照。こちらもプロジェクトに依存しません）。

• リポジトリのルートに docs/<feature-slug>/YYYY-MM-DD-<feature-slug>-prd.md を配置します。
• Git で追跡し、恒久的に保持してください。tmp/ には置かず、リリース後も削除しないでください。
• 現在の環境でネイティブの Plan Mode（EnterPlanMode/ExitPlanMode）が利用できる場合は、brainstorming/writing-plans と同様に使用してください。Plan Mode のサービスファイルでドラフトを作成し、ExitPlanMode を実行して、承認後にのみ docs/ に保存します。Plan Mode が利用できない場合（ディスパッチされたサブエージェントなど）は、まずチャットで内容をドラフトし、保存前にユーザーから明示的な承認を得てください。
• 自動的にコミットしないでください。明示的に依頼された場合に限りコミットしてください。

テンプレート

# <Feature name> — PRD

**Тикет:** `TBD` (реальный номер сообщает пользователь, в трекере проекта — не угадывать)
**Дата:** YYYY-MM-DD
**Статус:** Draft / In Review / Approved

## Проблема и контекст

Какая проблема существует сейчас, у кого, почему это важно решить именно сейчас.

## Цели

Что должно стать правдой в результате. Измеримо, где возможно.

## Не цели

Что сознательно остаётся вне рамок этой задачи — предотвращает расползание скоупа.

## Юзкейсы

Формат `Действие → Результат`, один на строку. Пример: `Пользователь открывает заявку с новым комментарием → видит уведомление о комментарии и переходит к нему`.

## Требования

### Функциональные

Пронумерованный список конкретных, проверяемых требований. Без «быстро»/«удобно»/«современно» — только измеримое:

```diff
- Поиск должен быть быстрым и удобным.
+ Поиск должен возвращать результат за ≤200мс на 10k записей.

非機能要件

パフォーマンス、セキュリティ、アクセシビリティ、互換性など、実際に該当するもののみを記載します。

成功指標

測定可能な KPI を 3～5 個記載します。「UX を改善する」のような曖昧な表現は避けてください。

リスクと未解決の質問

不明な点や問題が発生する可能性のある点と、それに回答する担当者を記載します。

スコープ外／今後の対応

今後に明確に延期する事項を記載します。

## Formatting rules

- **Hard rule, no exceptions: the PRD body is written entirely in Russian** — headings, prose, and requirements alike — regardless of what language the request came in. No project-file lookup needed to decide this. Code blocks, identifiers, and technical terms stay in their original form.
- Section inapplicable? Keep the heading, write `Не применимо` — don't delete it.
- Unknown fact (ticket, stack, deadline, integration detail) → literal `TBD`, never guess. Ticket number specifically: only the user supplies the real one, in whatever format their tracker uses — never invent a prefix or number.
- No filler — facts and decisions only, not a narrative of the conversation.

## Common mistakes

| Mistake | Fix |
|---|---|
| Writing the PRD before the goal/scope is actually decided | Run `brainstorming` first; PRD documents a decision, it doesn't discover one |
| Saving straight to `docs/` without approval | Draft first (Plan Mode if available, chat otherwise), save only after explicit approval |
| Guessing a ticket number/prefix or any unstated fact (stack, deadline, integration) | Use `TBD` until the user supplies it |
| Dropping a template section instead of marking it not applicable | Keep the heading, write `Не применимо` with a one-line reason |
| Assuming a project-specific storage path or ticket format from a project's CLAUDE.md | This skill doesn't read project rule files — ask the user if a project convention should override the defaults above |