Plan with QA Skill

タスクの仕様を明確化しながら、実装計画書をMarkdownファイルとして出力します。

使い方

/plan-with-qa ユーザー認証機能を追加したい
/plan-with-qa エレベーター乗降シーケンスのリファクタリング
/plan-with-qa ROS2ノードのパフォーマンス改善

実行フロー

このスキルは以下の3フェーズで進行します。

Phase 1: 初期分析とコードベース調査

1. ユーザーの要求 ($ARGUMENTS) を分析し、タスクの種類を判定する:
   • implementation: 新機能追加・既存機能の変更
   • refactor: コードのリファクタリング・改善
   • design-review: 既存設計の見直し・アーキテクチャ変更
   • general: その他の計画
2. コードベース調査を開始する:
   • Glob/Grep/Read を使って関連するファイル・コードを特定する
   • 既存のアーキテクチャ、パターン、依存関係を把握する
   • Task(Explore) エージェントを使った広範な調査も必要に応じて行う
3. 調査結果を踏まえて、曖昧な点・決定が必要な点を洗い出す

Phase 2: 仕様明確化（QAループ）

AskUserQuestion を使って、曖昧な仕様をまとめて質問する。

ルール:

• 質問は1回あたり2〜4個にまとめる（1個ずつ聞かない）
• 各質問には調査で得たコンテキストを反映させる（例: 「既存の AuthManager クラスを拡張する形にしますか？それとも新規に作りますか？」）
• 選択肢には具体的なメリット/デメリットを添える
• 質問の優先度: アーキテクチャ判断 > インターフェース設計 > 実装詳細 > エッジケース
• 回答を受けて新たな曖昧点が見つかれば追加で質問する（最大3ラウンド）
• 回答によって新たなコード調査が必要になれば、調査してから次の質問を行う

質問の観点チェックリスト:

• スコープ: 何を含み、何を含まないか
• 既存コードとの関係: 拡張 vs 新規作成 vs 置き換え
• インターフェース: API、引数、戻り値、メッセージ形式
• エラーハンドリング: 異常系の扱い方
• テスト: テストの必要性と範囲
• 依存関係: 新しいライブラリや外部サービスの追加
• 互換性: 既存機能への影響

Phase 3: 計画書の生成

QAフェーズで得た情報を元に、以下の構造でMarkdown計画書を作成する。

出力先: 作業ディレクトリに plan-<slug>.md として出力する（<slug> はタスク名から生成）。

計画書テンプレート:

# 計画: <タスク名>

作成日: YYYY-MM-DD

## 概要
<タスクの目的と背景を1〜3文で>

## 前提条件・仕様
<QAフェーズで確定した仕様を箇条書きで>

## 影響範囲
- **変更ファイル**: <変更が必要なファイル一覧>
- **影響を受ける機能**: <既存機能への影響>
- **新規ファイル**: <新規作成が必要なファイル（あれば）>

## 実装ステップ
1. <ステップ1>
   - 対象: `path/to/file.py`
   - 内容: <具体的な変更内容>
2. <ステップ2>
   ...

## テスト計画
- <テスト方針と具体的なテストケース>

## リスクと注意点
- <実装上のリスクや注意すべき点>

## 未決事項
- <QAで解決できなかった、または実装時に判断が必要な項目>

計画書を出力したら、内容をユーザーに要約して伝える。

重要な注意事項

• Phase 2 の質問は 必ず AskUserQuestion ツールを使う（テキストで質問しない）
• 質問を1個ずつ聞くのは禁止。最低2個はまとめる
• コードベース調査は質問フェーズと並行して行い、質問の精度を上げる
• 計画書はファイルとして出力する（会話内のテキスト表示だけで終わらせない）
• 既存コードのパターンや命名規則を尊重した計画を立てる