zhongwei/gh-masseater-claude-code-plugin-sdd
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
master
gh-masseater-claude-code-pl…/commands/implement-phase.md
Zhongwei Li f2613ae15b Initial commit
2025-11-30 08:39:29 +08:00

10 KiB
Raw Permalink Blame History

argument-hint, allowed-tools
argument-hint allowed-tools
<taskname> [phase.task]
Read
Write
Edit
Bash
Task
AskUserQuestion
TodoWrite

specs/[taskname]/配下の仕様書ドキュメントを読み込み、それに基づいて実装作業を行います

以下の引数で指定されたタスクについて、仕様書に基づいた実装作業を行ってください。

【引数】 $ARGUMENTS

引数の形式

  • [taskname] - タスク名のみ指定した場合、そのタスクの最初から作業開始
  • [taskname] [phase].[task] - Phase番号とタスク番号を指定した場合、そのタスクから作業開始
    • 例: user-authentication 2.3 → user-authenticationのphase2のタスク3から開始

実行手順

0. TodoWriteで実装ステップをTodoリストに追加

コマンド実行時、最初に以下の4つのステップをTodoWriteツールでTodoリストに追加：

TodoWrite([
  {
    content: "タスクとPhaseの特定",
    activeForm: "タスクとPhaseを特定中",
    status: "in_progress"
  },
  {
    content: "ステアリングドキュメントと仕様書の読み込み",
    activeForm: "ステアリングドキュメントと仕様書を読み込み中",
    status: "pending"
  },
  {
    content: "Phase状況の確認",
    activeForm: "Phase状況を確認中",
    status: "pending"
  },
  {
    content: "実装作業の実行",
    activeForm: "実装作業を実行中",
    status: "pending"
  }
])

その後、以下のステップを順番に実行し、各ステップ完了時にTodoの状態を更新：

1. タスクとPhase/タスクの特定

上記の引数を解析して作業対象を特定：

  1. 引数が指定されている場合

    • [taskname]のみ: specs/[taskname]/を対象とし、Phase 1から開始
    • [taskname] [phase].[task]: specs/[taskname]/を対象とし、指定されたPhaseとタスクから開始

  2. 引数が指定されていない場合

    • specs/ディレクトリ内のサブディレクトリを一覧表示
    • 複数のタスクがある場合、ユーザーに選択させる： 「どのタスクで作業しますか？」
      • [1] specs/user-authentication/
      • [2] specs/payment-integration/
      • [3] specs/admin-dashboard/
    • 単一のタスクのみの場合は自動選択

  3. 指定されたタスクディレクトリが存在しない場合

    • エラーメッセージを表示: 「specs/[taskname]/ ディレクトリが見つかりません」
    • specs/配下の利用可能なタスクを一覧表示

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

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

specs/_steering/product.md:

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

specs/_steering/tech.md:

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

specs/_steering/structure.md:

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

specs/_steering/principles.md:

  • 開発原則

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

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

3. 仕様書の確認

選択されたタスクディレクトリ（specs/[taskname]/）から以下のファイルを読み込んで内容を把握：

  1. specs/[taskname]/overview.md - プロジェクト全体の概要とPhase構成を理解
  2. specs/[taskname]/specification.md - 機能要件と非機能要件の詳細を確認
  3. specs/[taskname]/technical-details.md - 技術的な実装方針を確認
  4. specs/[taskname]/tasks/phase{N}-{phaseName}.md - 該当するPhaseの計画書を確認

4. 現在の状況確認

以下を確認してユーザーに報告：

  • 各Phaseの現在の状態（未着手/進行中/完了）
  • 実装可能なPhaseの特定（依存関係を考慮）
  • ブロッカーの有無

5. 作業開始位置の決定

5-1. [phase].[task] が指定されている場合

  1. 指定されたPhaseファイル（phase{N}-{phaseName}.md）を読み込む
  2. 指定されたタスク番号のタスクを特定
  3. そのタスクの依存関係を確認：
    • 依存関係が満たされていない場合、警告を表示し、ユーザーに続行するか確認
    • 依存関係が満たされている場合、そのまま続行
  4. 指定されたタスクの詳細を表示し、実装計画に進む

5-2. [phase].[task] が指定されていない場合

ユーザーに以下を質問： 「どのPhaseの作業を進めますか？」

選択肢：

  • Phase {N}: {phaseName}（状態: 〇〇、依存関係: 〇〇）
  • または、特定のタスク番号を指定（例: 2.3 でPhase 2のタスク3）

6. タスクの確認と実行計画

選択されたPhaseまたはタスクについて：

  1. 仕様の確認

    • specification.mdから該当機能の詳細仕様を抽出
    • technical-details.mdから技術的な実装方針を確認
    • Phase計画書から具体的なタスクとその依存関係を確認

  2. 実行可能性の確認

    • 依存関係が満たされているか確認
    • ブロッカーがないか確認
    • 必要なライブラリやツールが揃っているか確認

  3. TodoWriteで実装タスクを追加

    Phase計画書のタスクリストから、以下の形式でTodoWriteに実装用Todoを追加：

    - content: "{タスク名} の実装"
  activeForm: "{タスク名} を実装中"
  status: "pending"

    重要:

    • Phase計画書のタスク1つにつき、Todoアイテム1つを作成
    • タスクの依存関係順に並べる
    • 各Todoには以下の情報を含める：
      • 実装対象のファイルパス
      • 実装する機能の概要
      • テスト対象

  4. ユーザーに確認

    追加した実装用Todoリストを表示し、AskUserQuestionで確認： 「この計画で実装作業を開始してよろしいですか？」

    承認された場合、次のステップへ進む

7. 実装作業

承認後、追加した実装用Todoを1つずつ実行：

各Todoについて以下の手順で作業：

  1. Todoをin_progressに更新

  2. 実装

    • specification.mdの要件を満たすコードを実装
    • technical-details.mdの技術方針に従う
    • 既存のコードベースとの整合性を保つ
    • any型は絶対に使用しない

  3. 品質チェック

    • コードレビュー基準に従っているか確認
    • エラーハンドリングが適切か確認
    • 関数型プログラミングのスタイルを意識（map/filterの活用）

  4. テスト

    • Phase計画書のテスト計画に従ってテストを実装
    • ユニットテスト
    • 統合テスト（必要に応じて）

  5. Todoをcompletedに更新

  6. 次のTodoへ - すべての実装Todoが完了するまで繰り返し

8. 完了報告と状態更新

作業完了後の報告フォーマット：

✅ タスク [Phase.Task] の実装が完了しました
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📍 対象: specs/{taskname}/ - Phase {N}, Task {M}

💡 次のアクション:
   - 次のタスク実施: `/sdd:implement-phase {taskname} {phase}.{task+1}`
   - Phase検証実施: `/sdd:verify-phase {taskname} {phase}` （Phase内の全タスク完了時）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Phase状態の更新:

  • specs/[taskname]/overview.mdのPhase状態を更新
  • 該当するspecs/[taskname]/tasks/phase{N}-{phaseName}.mdのタスク状態を更新
  • タスク目次の該当タスクの状態とTDDステップを更新

9. 品質チェックの実施

作業完了前に必ず以下を確認：

  • 仕様書の要件を満たしているか
  • 依存関係が適切に処理されているか
  • エラーハンドリングが実装されているか
  • テストが実装され、パスしているか
  • any型を使用していないか
  • 関数型のスタイルを意識しているか（配列操作など）
  • 既存の類似実装を確認し、重複を避けているか
  • 既存ライブラリで実現できないか検討したか

重要な注意事項

  • 実装中は仕様書（overview.md、specification.md、technical-details.md）を常に参照し、要件から逸脱しないこと
  • Phase計画書の依存関係を必ず確認し、順序を守ること
  • タスク・Phaseの状態を適切に更新すること
  • 不明点や仕様の矛盾があれば、実装前にユーザーに確認すること

使用例

  1. タスク全体を最初から開始: /sdd:implement-phase user-authentication

  2. Phase 2のタスク3から開始: /sdd:implement-phase user-authentication 2.3

  3. 引数なしで対話的に選択: /sdd:implement-phase

内部品質チェック

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

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

実装完了後、内部的にステアリングドキュメントとの整合性を確認：

  • product.mdのビジネス目標との整合性
  • tech.mdのコーディング標準との整合性
  • structure.mdの命名規則・モジュール境界の遵守
  • principles.mdの開発原則との一致

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

矛盾チェック（内部処理）

実装完了後、内部的に仕様書間の矛盾を確認：

  • 実装内容とPhase計画書の整合性
  • specification.mdとの整合性
  • technical-details.mdとの整合性
  • 依存関係のあるドキュメント間の矛盾

矛盾がある場合のみユーザーに警告を表示。問題がなければ何も出力しない。

Reference in New Issue View Git Blame Copy Permalink