メニュー
新機能の要件定義。自然言語の入力から質問→要件定義書を自動生成する。 「通知機能を作りたい」「こういう機能がほしい」「○○ができるようにして」 「新しく○○を追加したい」「○○機能の要件を作って」などのリクエストで使用する。 まだコードが存在しない新機能を定義するときに使う。既存コードのSpec化にはspec-featureを使う。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
ClaudeDesign（claude.ai/design）とClaude Codeの連携。DesignSyncツールで デザインプロジェクトからプロトタイプHTML等を取得（インポート）、または ローカルのコンポーネントをデザインシステムプロジェクトへ同期（プッシュ）する。 「ClaudeDesignからデザインを取得して」「claude.ai/design のURLを取り込んで」 「デザインプロジェクトに同期して」「デザインシステムをプッシュして」 などのリクエスト、または claude.ai/design のURLが渡されたときに使用する。 取得したデザインのコード実装への適用は apply-design を使う。
詳細設計書の一括生成。2つのモードを自動判定する: (A) コード分析モード: 既存コードから詳細設計書を逆生成する（init-spec + spec-all 完了後） (B) 設計書ファーストモード: 要件定義書から詳細設計書を新規作成する（コードなし） 「詳細設計を作って」「設計書を完成させて」「実装に必要な設計書を全部作って」 「他のエンジニアに渡せる設計書にして」などのリクエストで使用する。
既存プロジェクトの初期セットアップ（初回のみ）。コードリポジトリを分析してCLAUDE.md、要件概要、 基本設計書（アーキテクチャ、DB設計、API設計）、OpenAPI仕様、MkDocs設定を自動生成する。 「このプロジェクトをセットアップして」「既存コードを分析して」「設計書を初期化して」 「プロジェクトの構造を把握して」などのリクエストで使用する。 既にドキュメントがある場合は移行モードで差分だけ補完する。 ※ 既存Specの全更新・再生成には spec-all を使う。
全機能の一括Spec化・一括更新。PM として並列サブエージェントにコード分析を委任し、 結果を統合して全機能の要件定義書を一括生成・更新する。 「全部のSpecを作って」「設計書を全部作って」「全機能をドキュメント化して」 「要件定義を全て更新して」「Specを全部更新して」などのリクエストで使用する。 個別のSpec化には spec-feature を使う。init-specは初期セットアップ専用。
既存機能のSpec化。実装済みコードを分析して要件定義書を逆生成する。 spec-map.yml にコードとSpecの対応関係を記録する（コード変更なし）。 「ツイート機能のSpecを作って」「認証周りをドキュメント化して」「既存の○○機能を設計書にして」 「この機能の要件を整理して」「○○の仕様を分析して」などのリクエストで使用する。 既に動いているコードからドキュメントを起こすときに使う。新規機能にはdraft-specを使う。 コード変更後のドキュメント追従にはupdate-docsを使う。
コード変更からドキュメントを追従更新する。設計書ファースト原則の例外措置。 やむを得ず先にコードを変更した場合にのみ使用する。 「さっきの変更をドキュメントに反映して」「設計書を最新にして」 「コードと設計書がズレてるから直して」「ドキュメントを最新化して」 「ドキュメント更新して」「設計書を現状に合わせて」などのリクエストで使用する。 通常はドキュメントを先に更新してからコードを修正すること（revise-specを使う）。
| name | draft-spec |
| description | 新機能の要件定義。自然言語の入力から質問→要件定義書を自動生成する。 「通知機能を作りたい」「こういう機能がほしい」「○○ができるようにして」 「新しく○○を追加したい」「○○機能の要件を作って」などのリクエストで使用する。 まだコードが存在しない新機能を定義するときに使う。既存コードのSpec化にはspec-featureを使う。 |
| context | {"required":["_shared/spec-writing-standard.md","_shared/spec-unified-base.md","_shared/screen-transition-diagram.md"]} |
Spec 統一基盤確認 を実施する。
ユーザーにdocs/drafts/への記入を求めない。会話から直接要件を引き出すこと。
以下のテンプレートを参照し、生成する文書のセクション構成を合わせる：
| テンプレート | 用途 |
|---|---|
docs/templates/phase1/requirements-spec.md | 要件定義書の構成 |
docs/templates/phase1/business-flow.md | 業務フロー図の構成 |
docs/templates/phase1/usecase.md | ユースケースの構成 |
docs/templates/phase1/screen-flow.md | 画面一覧・遷移図の構成 |
docs/templates/phase1/glossary.md | 用語定義書の構成 |
docs/templates/phase2/non-functional.md | 非機能要件定義書の構成（インデックス → 性能・可用性・運用の各テンプレートへリンク） |
テンプレートが存在しない場合は、従来の手順でそのまま生成する（テンプレート不在でブロックしない）。
本スキルは親=ヒアリング・方針・レビュー / spec-writer(Sonnet)=執筆の分担で進める。
docs/design/shared-components.md が存在する場合、既存の共通コンポーネントを確認する
overview.md の機能一覧と依存関係セクションを読み、関連する既存Specを特定するREQ-OVERVIEW-001）docs/requirements/features/[REQ-ID].md）Agent(subagent_type: spec-writer) に以下を並列で委任する（ファイル単位で独立しているため）:
委任プロンプト形式:
あなたは spec-writer です。以下のドキュメントを生成してください。
## 生成対象
docs/requirements/features/[REQ-ID].md
## 参照テンプレート
docs/templates/phase1/requirements-spec.md
## 埋める情報
- REQ-ID: [採番値]
- 担当者: [名前 or 未定]
- ステータス: [値]
- 受入条件: [親が整理した条件リスト]
- 関連Spec: [特定済みREQ-IDリスト]
- 活用可能な共通コンポーネント: [リスト]
- 非機能要件: [OVERVIEWに集約する分は記載しない]
## ヒアリング結果サマリ
[フェーズ1で得た回答を整理して渡す]
## 厳守事項
- 要件定義書にはWHAT（何を作るか）だけ記載。HOW（API/DB/画面遷移図）は基本設計で別途生成
- 不明点は「※ 要確認」マーカーを残し、推測で埋めない
- index系ファイル（overview.md / spec-map.yml / mkdocs.yml / dependency-graph.md）は触らない（親が更新）
- 完了時に軽量セルフチェックを実行し、結果を報告すること
並列委任する対象（該当するもののみ）:
docs/requirements/business-flow.md）docs/requirements/usecase.md）docs/templates/phase2/non-functional.md のインデックス構成）spec-writer は index 系に触らないため、親が責任を持って更新する:
docs/requirements/overview.md を更新
spec-map.yml に新規REQ-IDのエントリを追加し、depends_on に依存先を記載docs/design/dependency-graph.md が存在する場合、新規Specの依存関係を追記（Mermaid図 + 依存マトリクス）mkdocs.yml の nav を更新docs/design/screen-flow.md を更新（UI を持つ機能の場合）
docs/templates/phase1/screen-flow.md）に従い画面情報を追記Agent(subagent_type: integrity-checker) を起動して機械的整合性チェック
.claude/skills/_shared/doc-integrity-check.md 参照git add してコミットOVERVIEW Specはシステム全体の共通仕様を一元管理するファイルである。