メニュー
全リクエストの受け皿。質問・相談・調査・実装・修正・GitHubイシュー対応など、 あらゆる開発リクエストを受け取り、内容に応じて最適な対応方法を選択する。 「対応して」「直して」「やって」「見て」「確認して」「どう思う？」 「相談したい」「壁打ちしたい」等の汎用的な指示で発火する。
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 | handle |
| description | 全リクエストの受け皿。質問・相談・調査・実装・修正・GitHubイシュー対応など、 あらゆる開発リクエストを受け取り、内容に応じて最適な対応方法を選択する。 「対応して」「直して」「やって」「見て」「確認して」「どう思う？」 「相談したい」「壁打ちしたい」等の汎用的な指示で発火する。 |
ユーザーのリクエストを以下の基準で分類し、適切な対応を取る。
gh issue view でイシューの body と comments を取得するリクエストを以下のカテゴリに分類する:
| カテゴリ | 判断基準 | 例 |
|---|---|---|
| A. 即答 | リンク・添付なし、短い質問、コード調査不要 | 「これ何？」「○○の意味は？」 |
| B. 調査・回答 | 機能・コード・設計についての質問、調査が必要 | 「認証どうなってる？」「この画面の仕様は？」 |
| C. 相談・壁打ち | 設計方針の議論、意見を求められている | 「どう思う？」「相談したい」「設計を考えたい」 |
| D. 実装（仕様変更なし） | バグ修正、リファクタ、見た目のみの変更 | 「このバグ直して」「CSSだけ変えて」 |
| E. 実装（仕様変更あり） | 機能の追加・変更・削除を伴う | 「フィールド追加して」「バリデーション変えて」 |
| F. 新規機能 | まだ存在しない機能を作る | 「通知機能を作りたい」「新しく○○を追加」 |
判断に迷う場合は、ユーザーに「これは○○ということでよいですか？」と確認する。
そのまま回答する。調査は不要。簡潔に答える。
コードや設計書を読んで回答する。必要に応じて:
docs/ 配下の設計書を確認深く考えて回答する。選択肢がある場合はメリット・デメリットを整理して提示する。 結論を急がず、ユーザーの思考を助ける。
impl-plans/[識別子].md に実装プランを作成（PlanMode）→ ユーザー承認Skill tool で revise-spec を呼び出す。 イシュー起点の場合は、revise-spec 完了後にイシューを閉じるか確認する。
Skill tool で draft-spec を呼び出して要件定義から始める。 要件定義完了後、implement-spec で実装に進むか確認する。