Menu
全リクエストの受け皿。質問・相談・調査・実装・修正・GitHubイシュー対応など、 あらゆる開発リクエストを受け取り、内容に応じて最適な対応方法を選択する。 「対応して」「直して」「やって」「見て」「確認して」「どう思う？」 「相談したい」「壁打ちしたい」等の汎用的な指示で発火する。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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 で実装に進むか確認する。