既存プロジェクトに新しいリポジトリを追加する。Workspaceにリポを追加した後、 CLAUDE.md・設計書・ドメイン構成を差分更新する。 「モバイルリポを追加した」「新しいリポを取り込んで」「リポを追加したので設計書を更新して」 「Workspaceにリポを足した」などのリクエストで使用する。 init-spec の移行モードではファイル存在チェックしか行わないため、 既存ドキュメントの内容を新リポに合わせて拡張するにはこのスキルを使う。
handle
全リクエストの受け皿。質問・相談・調査・実装・修正・GitHubイシュー対応など、 あらゆる開発リクエストを受け取り、内容に応じて最適な対応方法を選択する。「対応して」「直して」「やって」「見て」「確認して」「どう思う?」 「相談したい」「壁打ちしたい」等の汎用的な指示で発火する。
含まれるファイル(1)
- SKILL.md3.6 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
リクエストの分類と対応
ユーザーのリクエストを以下の基準で分類し、適切な対応を取る。
Step 1: 入力の正規化
- GitHubイシューURL が含まれる場合:
gh issue viewでイシューの body と comments を取得する - 口頭・テキストの指示のみ: そのまま分類へ進む
Step 2: 分類
リクエストを以下のカテゴリに分類する:
| カテゴリ | 判断基準 | 例 |
|---|---|---|
| A. 即答 | リンク・添付なし、短い質問、コード調査不要 | 「これ何?」「○○の意味は?」 |
| B. 調査・回答 | 機能・コード・設計についての質問、調査が必要 | 「認証どうなってる?」「この画面の仕様は?」 |
| C. 相談・壁打ち | 設計方針の議論、意見を求められている | 「どう思う?」「相談したい」「設計を考えたい」 |
| D. 実装(仕様変更なし) | バグ修正、リファクタ、見た目のみの変更 | 「このバグ直して」「CSSだけ変えて」 |
| E. 実装(仕様変更あり) | 機能の追加・変更・削除を伴う | 「フィールド追加して」「バリデーション変えて」 |
| F. 新規機能 | まだ存在しない機能を作る | 「通知機能を作りたい」「新しく○○を追加」 |
判断に迷う場合は、ユーザーに「これは○○ということでよいですか?」と確認する。
Step 3: カテゴリ別の対応
A. 即答
そのまま回答する。調査は不要。簡潔に答える。
B. 調査・回答
コードや設計書を読んで回答する。必要に応じて:
docs/配下の設計書を確認- ソースコードを Grep/Read で調査
- 回答には根拠(ファイルパス:行番号)を含める
C. 相談・壁打ち
深く考えて回答する。選択肢がある場合はメリット・デメリットを整理して提示する。 結論を急がず、ユーザーの思考を助ける。
D. 実装(仕様変更なし)
- コードを調査して原因・影響範囲を特定
impl-plans/[識別子].mdに実装プランを作成(PlanMode)→ ユーザー承認- 実装(Agent(model: "sonnet") に委任可能)
- テスト実行
- コミット
- GitHubイシュー起点なら → イシューを閉じるか確認
E. 実装(仕様変更あり)
Skill tool で revise-spec を呼び出す。 イシュー起点の場合は、revise-spec 完了後にイシューを閉じるか確認する。
F. 新規機能
Skill tool で draft-spec を呼び出して要件定義から始める。 要件定義完了後、implement-spec で実装に進むか確認する。
ルール
- 分類を明示する: 「これはカテゴリDと判断しました」と伝えてから対応する
- 実装は必ずプランを経由する: D/E/F では設計なしにコードを書き始めない
- GitHubイシューの後処理: イシュー起点の作業が完了したら、閉じるかどうかユーザーに確認する
- 判断に迷ったら聞く: 無理に分類せず、ユーザーに確認する
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
既存プロジェクトをサブエージェントで並列分析し、 精度の高い overview.md を生成する。init-spec の前処理として使う。 「既存プロジェクトを分析して」「コードベースを理解して設計書を作って」 「overview.mdを作って」などのリクエストで使用する。 ファイル数が200を超えるプロジェクトで特に有効。 200以下の場合は単一エージェントで全体を読む方が精度が高いため、 init-spec をそのまま実行することを提案する。
デザインの差し替え。ロジックは一切触らず見た目(HTML/CSS/テンプレート)だけを更新する。 「このデザインに差し替えて」「UIをFigmaの通りに変えて」「見た目だけ変えて」 「デザインを更新して」「CSSだけ直して」などのリクエストで使用する。 ロジック変更を伴う場合はrevise-specを使う。
ブラウザで画面を確認する。agent-browser CLI を使って画面のスクリーンショット撮影、 アクセシビリティツリー取得、フォーム操作、画面遷移などを行う。 「画面見て」「ブラウザ確認して」「スクショ撮って」「現状把握して」「画面開いて」 「ログインして確認して」「画面の状態を教えて」「UIを確認して」などのリクエストで使用する。 E2Eテストの作成・実行には gen-tests(Playwright)を使うこと。本スキルはテスト実行ではなく 「AIの目」としてブラウザを操作し、画面状態を把握するためのもの。
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) 設計書ファーストモード: 要件定義書から詳細設計書を新規作成する(コードなし) 「詳細設計を作って」「設計書を完成させて」「実装に必要な設計書を全部作って」 「他のエンジニアに渡せる設計書にして」などのリクエストで使用する。