| name | handle |
| description | 全リクエストの受け皿。質問・相談・調査・実装・修正・GitHubイシュー対応など、
あらゆる開発リクエストを受け取り、内容に応じて最適な対応方法を選択する。
「対応して」「直して」「やって」「見て」「確認して」「どう思う？」
「相談したい」「壁打ちしたい」等の汎用的な指示で発火する。
|
リクエストの分類と対応
ユーザーのリクエストを以下の基準で分類し、適切な対応を取る。
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イシューの後処理: イシュー起点の作業が完了したら、閉じるかどうかユーザーに確認する
- 判断に迷ったら聞く: 無理に分類せず、ユーザーに確認する
