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

Fork 0

Files

Zhongwei Li f2613ae15b Initial commit

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

8.7 KiB

Raw Permalink Blame History

argument-hint, description, allowed-tools

argument-hint

description

allowed-tools

<タスク名>

Phase構成を決定してoverview.mdに追加（詳細なタスク分解はしない）

Read

Edit

Task

AskUserQuestion

Phase構成を決定します

調査完了後に、タスクをPhaseに分割する構成を決定し、overview.md に追加します。

重要: このコマンドは詳細なタスク分解を行いません。Phase構成（Phase数、名前、目標、依存関係）のみを決定します。

【対象タスク名】 $ARGUMENTS

実行手順

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

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

specs/_steering/product.md - プロダクト方針、ビジネス目標
specs/_steering/tech.md - 技術スタック、アーキテクチャパターン
specs/_steering/structure.md - プロジェクト構造
specs/_steering/principles.md - 開発原則

1. タスクディレクトリの確認

タスク名が指定されている場合:

specs/[taskname]/ ディレクトリの存在を確認
必須ファイルの存在確認:
- overview.md
- specification.md
- technical-details.md

タスク名が指定されていない場合:

specs/ ディレクトリ内の利用可能なタスクをリスト表示
AskUserQuestionツールを使用してどのタスクについて作業するかユーザーに選択を求める

2. 調査完了の確認

Phase分けを開始する前に、必ず調査が完了していることを確認:

overview.mdの調査セクション確認
- specs/[taskname]/overview.md の調査項目表を読み込み
- 全ての調査項目の状態を確認
調査ステータスの判定
- 全て「完了」の場合: 次のステップへ進む
- 「未着手」がある場合:
  - 警告メッセージを表示: 「⚠️ 調査が完了していません」
  - 未完了の調査項目をリスト表示
  - AskUserQuestionツールで確認して続行するか判断
  - 続行しない場合: /sdd:conduct-research [taskname] を推奨

3. 既存ドキュメントの分析

以下のドキュメントから情報を抽出してPhase構成を決定:

overview.md

調査結果（調査セクションおよびspecs/research/配下の個別ファイル）
実装概要

specification.md

機能要件の詳細
各機能の優先度
非機能要件

technical-details.md

技術スタックと技術選定
データ設計とAPI設計
セキュリティ要件
アーキテクチャ構成

ステアリングドキュメント

product.md: ビジネス優先順位、成功指標
tech.md: 技術的制約、開発標準
structure.md: プロジェクト構造

4. Phase構成の提案

Phase分けの基準

以下の基準でPhase構成を提案：

独立してデプロイ・リリース可能な単位
- 各Phaseは独立して動作確認とリリースができる状態になる
- Phase完了時点で品質チェックに成功する状態
機能の依存関係による分割
- 後続Phaseが前Phaseの成果物に依存する構造
- 並行開発可能な機能は明示
リスクとビジネス価値による優先順位付け
- 高リスク・高価値の機能は早期のPhaseで実装
- 基盤機能 → コア機能 → 拡張機能の順に配置

Phase数について:

Phase数に制約はありません
プロジェクトの複雑度と機能の依存関係に応じて適切に分割してください

Phase構成の生成

以下の情報を含むPhase構成を生成：

## Phase構成提案

### Phase 1: [Phase名]
- **目標**: [このPhaseで達成すること]
- **依存関係**: なし
- **成果物**:
  - [成果物1]
  - [成果物2]
- **含まれる主要機能**:
  - [機能1]（specification.mdの機能X）
  - [機能2]（specification.mdの機能Y）

### Phase 2: [Phase名]
- **目標**: [このPhaseで達成すること]
- **依存関係**: Phase 1完了
- **成果物**:
  - [成果物1]
  - [成果物2]
- **含まれる主要機能**:
  - [機能3]（specification.mdの機能Z）

### Phase 3: [Phase名]
- **目標**: [このPhaseで達成すること]
- **依存関係**: Phase 2完了
- **成果物**:
  - [成果物1]
- **含まれる主要機能**:
  - [機能4]（specification.mdの機能W）

## Phase依存関係図

```mermaid
graph TB
    P1[Phase 1: [具体的なPhase名]]
    P2[Phase 2: [具体的なPhase名]]
    P3[Phase 3: [具体的なPhase名]]

    P1 --> P2
    P2 --> P3


### 5. ユーザーへの確認

**AskUserQuestionツールを使用**してPhase構成の妥当性を確認：

以下のPhase構成でよろしいですか？

[生成したPhase構成を表示]

選択肢:

承認（このPhase構成でoverview.mdを更新）
修正が必要（Phase数、Phase名、依存関係などを調整したい）
やり直し（Phase構成を再提案）


**「修正が必要」の場合**:
- どの部分を修正したいか質問
- ユーザーの要望に基づいて再提案
- 再度確認

### 6. overview.mdの更新

ユーザーの承認後、`specs/[taskname]/overview.md` に以下のセクションを追加：

```markdown
## Phase概要と依存関係

### Phase 1: [Phase名]
- **開始日時**: （空欄）
- **状態**: 未着手
- **目標**: [目標]
- **依存関係**: なし
- **成果物**:
  - [成果物1]
  - [成果物2]

### Phase 2: [Phase名]
- **開始日時**: （空欄）
- **状態**: 未着手
- **目標**: [目標]
- **依存関係**: Phase 1完了
- **成果物**:
  - [成果物1]
  - [成果物2]

### Phase 3: [Phase名]
- **開始日時**: （空欄）
- **状態**: 未着手
- **目標**: [目標]
- **依存関係**: Phase 2完了
- **成果物**:
  - [成果物1]

## Phase依存関係図

```mermaid
graph TB
    P1[Phase 1: [具体的なPhase名]]
    P2[Phase 2: [具体的なPhase名]]
    P3[Phase 3: [具体的なPhase名]]

    P1 --> P2
    P2 --> P3

シーケンス図

主要な機能のシーケンス図をMermaid記法で記述:

sequenceDiagram
    participant User as ユーザー
    participant Client as クライアント
    participant API as APIサーバー
    participant DB as データベース

    User->>Client: [アクション]
    Client->>API: [リクエスト]
    API->>DB: [データ操作]
    DB-->>API: レスポンス
    API-->>Client: レスポンス
    Client-->>User: 結果表示


**重要**: 既存のoverview.mdの内容は保持し、上記セクションを追加

### 7. 完了報告

✅ Phase構成を決定しました ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 📍 更新先: specs/[taskname]/overview.md 📊 Phase数: [N]個

💡 次のアクション:

Phase 1の詳細計画: /sdd:breakdown-phase [taskname] 1 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━


## 注意事項

- **⚠️ 重要**: このコマンドは詳細なタスク分解を行いません（Phase構成のみ決定）
- **⚠️ 重要**: 調査が完了していない状態でPhase構成を決定すると、後で大きな手戻りが発生する可能性があります
- **⚠️ 重要**: ステアリングドキュメントを参照し、プロジェクトの方針に準拠してください
- Phase数はプロジェクトの規模と複雑さに応じて柔軟に決定してください（2個でも6個以上でも可）
- 各Phaseは独立してデプロイ・リリース可能な単位にする
- Phase間の依存関係を明確にする

## 内部品質チェック

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

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

Phase構成追加後、内部的にステアリングドキュメントとの整合性を確認：
- product.mdのビジネス目標とPhaseの目標の整合性
- tech.mdのアーキテクチャ方針とPhase分割の適切性
- structure.mdのモジュール境界とPhase境界の適切性

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

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

Phase構成追加後、内部的に仕様書間の矛盾を確認：
- Phase構成と機能要件の整合性
- Phase構成と技術詳細の整合性
- Phase間の依存関係の妥当性

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

8.7 KiB Raw Permalink Blame History Unescape Escape