zhongwei/gh-masseater-claude-code-plugin-sdd

Fork 0

Files

Zhongwei Li f2613ae15b Initial commit

2025-11-30 08:39:29 +08:00

10 KiB

Raw Blame History

argument-hint, allowed-tools

argument-hint

allowed-tools

<タスク名> [調査項目名]

Read

Write

Edit

Bash

WebSearch

Task

overview.mdの調査項目を実施し、個別ファイルとして保存します

このコマンドは specs/[taskname]/overview.md の調査セクションから調査項目を読み取り、調査を実施して specs/research/[調査項目名].md として保存します。

コマンドの役割

/sdd:conduct-research（このコマンド）の役割:

技術的な調査・検証を実施
AIが自律的に調査・実験・ベンチマークなどを行って判断できる項目
例：
- ライブラリやフレームワークの選定（性能比較、機能比較）
- 実装方法の検証（PoC作成、パフォーマンス測定）
- アーキテクチャの実現可能性調査
- セキュリティ手法の選定と検証

/sdd:clarify-spec との違い:

clarify-spec: ビジネス要件やユーザーの意思決定が必要な項目をユーザーに質問
conduct-research: 技術的な調査が必要な項目をAIが調査・検証
clarify-specは「ユーザーに聞く」、conduct-researchは「AIが調べる」

使い分けの例:

✅ research: 「JWT vs セッション認証のパフォーマンス比較」（技術的検証）
✅ clarify: 「ログイン時にメールアドレスとユーザー名のどちらを使うか」（ビジネス要件）
✅ research: 「PostgreSQL vs MySQL のベンチマーク」（技術的検証）
✅ clarify: 「管理者画面の公開範囲（社内のみ or 顧客も使用）」（ビジネス要件）

【引数】 $ARGUMENTS

引数の形式

[taskname] - タスク名のみ指定した場合、全ての未完了調査項目を順に実施
[taskname] [調査項目名] - 特定の調査項目のみ実施
- 例: user-authentication JWT認証のパフォーマンス検証 → 指定された調査項目のみ実施

実行手順

1. タスクと調査項目の特定

引数が指定されている場合
- [taskname]のみ: specs/[taskname]/overview.mdの調査セクションから未完了の調査項目を抽出
- [taskname] [調査項目名]: 指定された調査項目のみを対象
引数が指定されていない場合
- specs/ディレクトリ内のサブディレクトリを一覧表示
- 複数のタスクがある場合、AskUserQuestionツールでユーザーに選択させる
- 単一のタスクのみの場合は自動選択
指定されたタスクディレクトリが存在しない場合
- エラーメッセージを表示: 「specs/[taskname]/ ディレクトリが見つかりません」
- specs/配下の利用可能なタスクを一覧表示

2. overview.mdの確認

ファイルの存在確認
- specs/[taskname]/overview.md の存在を確認
- 存在しない場合: エラーメッセージを表示し、/sdd:init-task コマンドの実行を提案
調査項目の抽出
- overview.mdの「調査項目」セクション（表形式）から調査項目を抽出
- 各調査項目の以下の情報を取得:
  - 状態（未着手/完了）
  - 調査項目名
  - 理由
未完了調査項目のリスト表示
- 状態が「未着手」の項目を表示
- 調査項目が全て完了している場合: 完了メッセージを表示して終了

3. ステアリングドキュメントの読み込み

プロジェクト全体のコンテキストを把握するため、以下のステアリングドキュメントを読み込みます：

specs/_steering/product.md:

プロダクトの目的とビジョン
ターゲットユーザー
主要機能とビジネス目標

specs/_steering/tech.md:

技術スタックとアーキテクチャ
開発標準（型安全性、コード品質、テスト戦略）
重要な技術的決定事項

specs/_steering/structure.md:

プロジェクト構造と命名規則
コード組織原則
モジュール境界

ステアリングドキュメントが存在しない場合:

警告メッセージを表示: 「⚠️ ステアリングドキュメントが見つかりません。プロジェクト固有のコンテキストなしで進めます。」
/sdd:steering コマンドでステアリングドキュメントを作成することを推奨
処理は続行（ステアリングドキュメントは必須ではない）

4. 調査項目の選択

調査項目名が指定されている場合:

指定された名前の調査項目を特定
その調査項目の詳細を表示
手順5へ進む

調査項目名が指定されていない場合:

未完了の調査項目を表示
AskUserQuestionツールを使用してユーザーに選択させる
- 各調査項目を選択肢として提示
- 「全て順番に実施」オプションも含める

5. 調査の実施

選択された調査項目について、以下の手順で調査を実施:

5-1. 調査内容の確認

調査項目の詳細を確認
- overview.mdから調査項目名と理由を取得
- 何を調査すべきかを明確に理解
調査プランの作成（内部処理）
- TodoWriteツールを使用して調査ステップを計画
- 例:
  - コードベースの既存実装を調査
  - ドキュメント・ベストプラクティスを調査（WebSearchツール使用）
  - PoC実装（必要な場合）
  - ベンチマーク実施（必要な場合）
  - 結果の比較と分析
- 調査プランはspecファイルには書かない（内部処理のみ）

5-2. 調査の実行

調査方法に応じて適切なアプローチを選択:

A. コードベース調査

既存の実装パターンを確認
使用されているライブラリやフレームワークを確認
類似機能の実装方法を分析

B. ドキュメント調査

WebSearchツールを使用して最新のベストプラクティスを調査
公式ドキュメントを参照
技術記事やブログを調査

C. PoC（Proof of Concept）実装

小規模な実装例を作成
動作確認とパフォーマンス測定
実装の難易度や工数を評価

D. ベンチマーク

複数の選択肢を比較
パフォーマンス測定
リソース使用量の確認

5-3. 調査結果のまとめと保存

調査完了後、以下の情報をまとめて specs/[taskname]/research/[調査項目名].md として保存:

# [調査項目名]

## 結論
- 選択: [選択した技術/手法]
- 理由: [選択の理由を1-3行で簡潔に]

## 詳細（必要な場合のみ）
- パフォーマンス測定結果
- セキュリティ考慮事項
- 実装の難易度評価
- 注意点やリスク

## 関連タスク
- specs/[taskname]/

ファイル名の決定:

調査項目名をそのままファイル名にする
例: 「JWT認証のパフォーマンス検証」→ JWT認証のパフォーマンス検証.md

6. overview.mdの調査セクション更新

6-1. 表の更新

overview.mdの調査項目表で、該当行の「状態」列を「完了」に更新

「概要」列に調査結果の簡潔なサマリーと結果ファイルへのリンクを追加:

| 完了 | [調査項目名] | [理由] | [選択した技術/手法](research/[調査項目名].md) |

6-2. 全調査項目完了時の処理

全ての調査項目の状態が「完了」になっている場合

overview.mdの「次のステップ」を更新:

**次のステップ**: `/sdd:define-requirements [taskname]` で要件定義を開始してください

7. 完了報告

✅ 調査項目を完了しました
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📍 対象タスク: [taskname]
📝 完了した調査項目: [調査項目名]
🔍 結論: [選択した技術/手法]

📄 保存先: specs/[taskname]/research/[調査項目名].md
📊 調査の進捗: 完了 {完了数} / {総数}

💡 次のアクション:
   - 残りの調査項目: `/sdd:conduct-research [taskname]`
   - 全調査完了: `/sdd:define-requirements [taskname]`
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

複数の調査項目を順に実施する場合:

1つの調査項目が完了したら、次の未完了項目を自動的に表示
ユーザーに「続けて次の調査項目を実施しますか？」と確認
承認されたら手順4に戻って次の調査項目を実施

重要な注意事項

調査は丁寧に: 調査は実装の品質を左右する重要なステップです。時間をかけて丁寧に調査してください
エビデンスベース: 推測ではなく、調査結果（ベンチマーク、ドキュメント、PoC）に基づいて判断すること
調査結果は簡潔に: 結論と理由を明確に。詳細は必要な場合のみ記載
個別ファイルで管理: 各調査項目は specs/research/[調査項目名].md として個別に保存
調査プランはspecに書かない: 調査プランは内部処理のみ。結果だけをファイルに保存

使用例

タスク全体の調査を順に実施: /sdd:conduct-research user-authentication
特定の調査項目のみ実施: /sdd:conduct-research user-authentication JWT認証のパフォーマンス検証
引数なしで対話的に選択: /sdd:conduct-research

内部品質チェック

重要: 以下のチェックはコマンド内部で実施し、生成されるspecファイルには結果を記載しません。

ステアリングドキュメントレビュー（内部処理）

調査結果ファイル生成後、内部的にステアリングドキュメントとの整合性を確認：

tech.mdの技術方針と調査結果の整合性
product.mdのビジネス目標との整合性

問題がある場合のみユーザーに修正を促す。準拠している場合は何も出力しない。

10 KiB Raw Blame History Unescape Escape