msd-core/docs/ja-JP/FEATURES.md

GSD 機能リファレンス

全機能と要件の完全なドキュメントです。アーキテクチャの詳細についてはアーキテクチャを、コマンド構文についてはコマンドリファレンスをご覧ください。

---

目次

• コア機能
  • プロジェクト初期化
  • フェーズディスカッション
  • UI デザインコントラクト
  • フェーズプランニング
  • フェーズ実行
  • 作業検証
  • UI レビュー
  • マイルストーン管理
• プランニング機能
  • フェーズ管理
  • Quick モード
  • 自律モード
  • フリーフォームルーティング
  • ノートキャプチャ
  • 自動進行（Next）
• 品質保証機能
  • Nyquist バリデーション
  • プランチェック
  • 実行後検証
  • ノードリペア
  • ヘルスバリデーション
  • クロスフェーズ回帰ゲート
  • 要件カバレッジゲート
• コンテキストエンジニアリング機能
  • コンテキストウィンドウ監視
  • セッション管理
  • セッションレポート
  • マルチエージェントオーケストレーション
  • モデルプロファイル
• ブラウンフィールド機能
  • コードベースマッピング
• ユーティリティ機能
  • デバッグシステム
  • Todo 管理
  • 統計ダッシュボード
  • アップデートシステム
  • 設定管理
  • テスト生成
• インフラストラクチャ機能
  • Git 連携
  • CLI ツール
  • マルチランタイムサポート
  • フックシステム
  • 開発者プロファイリング
  • 実行ハードニング
  • 検証デット追跡
• v1.27 の機能
  • Fast モード
  • クロス AI ピアレビュー
  • バックログパーキングロット
  • 永続コンテキストスレッド
  • PR ブランチフィルタリング
  • セキュリティハードニング
  • マルチリポワークスペースサポート
  • ディスカッション監査証跡
• v1.28 の機能
  • フォレンジクス
  • マイルストーンサマリー
  • ワークストリームネームスペーシング
  • マネージャーダッシュボード
  • Assumptions ディスカッションモード
  • UI フェーズ自動検出
  • マルチランタイムインストーラー選択
• v1.29 の機能
  • Windsurf ランタイムサポート
  • 国際化ドキュメント
• v1.30 の機能
  • GSD SDK
• v1.31 の機能
  • スキーマドリフト検出
  • セキュリティエンフォースメント
  • ドキュメント生成
  • ディスカスチェーンモード
  • 単一フェーズ自律モード
  • スコープ削減検出
  • クレーム出所タグ付け
  • Worktree トグル
  • プロジェクトコードプレフィックス
  • Claude Code スキルマイグレーション
• v1.32 の機能
  • STATE.md 整合性ゲート
  • 自律モード --to N フラグ
  • リサーチゲート
  • ベリファイヤーマイルストーンスコープフィルタリング
  • Read-Before-Edit ガードフック
  • コンテキスト削減
  • ディスカスフェーズ --power フラグ
  • デバッグ --diagnose フラグ
  • フェーズ依存関係分析
  • アンチパターン重大度レベル
  • メソドロジーアーティファクトタイプ
  • プランナー到達可能性チェック
  • Playwright-MCP UI 検証
  • Pause-Work 拡張
  • レスポンス言語設定
  • 手動アップデート手順
  • 新規ランタイムサポート (Trae, Cline, Augment Code)

---

コア機能

1. プロジェクト初期化

コマンド: /gsd-new-project [--auto @file.md]

目的: ユーザーのアイデアを、リサーチ、スコープ化された要件、フェーズ分けされたロードマップを持つ完全に構造化されたプロジェクトに変換します。

要件:

• REQ-INIT-01: システムはプロジェクトスコープが完全に理解されるまで適応的な質問を実施しなければならない
• REQ-INIT-02: システムはドメインエコシステムを調査するために並列リサーチエージェントを起動しなければならない
• REQ-INIT-03: システムは要件を v1（必須）、v2（将来）、スコープ外のカテゴリに分類しなければならない
• REQ-INIT-04: システムは要件トレーサビリティ付きのフェーズ分けされたロードマップを生成しなければならない
• REQ-INIT-05: システムは続行前にロードマップのユーザー承認を要求しなければならない
• REQ-INIT-06: .planning/PROJECT.md が既に存在する場合、システムは再初期化を防止しなければならない
• REQ-INIT-07: システムは --auto @file.md フラグをサポートし、インタラクティブな質問をスキップしてドキュメントから情報を抽出しなければならない

生成物:

成果物	説明
PROJECT.md	プロジェクトビジョン、制約、技術的決定、発展ルール
REQUIREMENTS.md	一意の ID（REQ-XX）付きのスコープ化された要件
ROADMAP.md	ステータス追跡と要件マッピング付きのフェーズ分割
STATE.md	ポジション、決定事項、メトリクスを含む初期プロジェクト状態
config.json	ワークフロー設定
research/SUMMARY.md	統合されたドメインリサーチ
research/STACK.md	技術スタック調査
research/FEATURES.md	機能実装パターン
research/ARCHITECTURE.md	アーキテクチャパターンとトレードオフ
research/PITFALLS.md	よくある失敗パターンと対策

プロセス:

1. 質問 — 「ドリーム抽出」の哲学に基づく適応的な質問（要件収集ではなく）
2. リサーチ — 4つの並列リサーチャーエージェントがスタック、機能、アーキテクチャ、落とし穴を調査
3. 統合 — リサーチシンセサイザーが調査結果を SUMMARY.md に統合
4. 要件 — ユーザーの回答とリサーチから要件を抽出し、スコープ別に分類
5. ロードマップ — 要件にマッピングされたフェーズ分割、粒度設定によりフェーズ数を制御

機能要件:

• 質問は検出されたプロジェクトタイプ（Web アプリ、CLI、モバイル、API など）に応じて適応する
• リサーチエージェントは最新のエコシステム情報を取得するための Web 検索機能を持つ
• 粒度設定によりフェーズ数を制御: coarse（3-5）、standard（5-8）、fine（8-12）
• --auto モードではインタラクティブな質問なしで提供されたドキュメントからすべての情報を抽出
• 既存のコードベースコンテキスト（/gsd-map-codebase から取得）がある場合は読み込む

---

2. フェーズディスカッション

コマンド: /gsd-discuss-phase [N] [--auto] [--batch]

目的: リサーチとプランニング開始前に、ユーザーの実装に関する要望や決定事項を収集します。AI が推測する原因となるグレーゾーンを排除します。

要件:

• REQ-DISC-01: システムはフェーズのスコープを分析し、決定が必要な領域（グレーゾーン）を特定しなければならない
• REQ-DISC-02: システムはグレーゾーンをタイプ別に分類しなければならない（ビジュアル、API、コンテンツ、構成など）
• REQ-DISC-03: システムは過去の CONTEXT.md ファイルで既に回答済みの質問のみを除外しなければならない
• REQ-DISC-04: システムは決定事項を {phase}-CONTEXT.md に正規参照付きで永続化しなければならない
• REQ-DISC-05: システムは推奨デフォルトを自動選択する --auto フラグをサポートしなければならない
• REQ-DISC-06: システムはグループ化された質問取り込みのための --batch フラグをサポートしなければならない
• REQ-DISC-07: システムはグレーゾーンを特定する前に関連ソースファイルをスカウトしなければならない（コード認識型ディスカッション）

生成物: {padded_phase}-CONTEXT.md — リサーチとプランニングに反映されるユーザーの要望

グレーゾーンカテゴリ:

カテゴリ	決定事項の例
ビジュアル機能	レイアウト、密度、インタラクション、空状態
API/CLI	レスポンス形式、フラグ、エラーハンドリング、詳細度
コンテンツシステム	構造、トーン、深さ、フロー
構成	グルーピング基準、命名、重複、例外

---

3. UI デザインコントラクト

コマンド: /gsd-ui-phase [N]

目的: プランニング前にデザインの決定事項を確定し、フェーズ内のすべてのコンポーネントが一貫したビジュアル基準を共有できるようにします。

要件:

• REQ-UI-01: システムは既存のデザインシステムの状態を検出しなければならない（shadcn の components.json、Tailwind 設定、トークン）
• REQ-UI-02: システムは未回答のデザインコントラクトの質問のみを行わなければならない
• REQ-UI-03: システムは6つの次元（コピーライティング、ビジュアル、カラー、タイポグラフィ、スペーシング、レジストリセーフティ）に対してバリデーションしなければならない
• REQ-UI-04: バリデーションが BLOCKED を返した場合、システムはリビジョンループに入らなければならない（最大2回の反復）
• REQ-UI-05: components.json のない React/Next.js/Vite プロジェクトに対して、システムは shadcn の初期化を提案しなければならない
• REQ-UI-06: システムはサードパーティの shadcn レジストリに対してレジストリセーフティゲートを適用しなければならない

生成物: {padded_phase}-UI-SPEC.md — エグゼキューターが参照するデザインコントラクト

6つのバリデーション次元:

1. コピーライティング — CTA ラベル、空状態、エラーメッセージ
2. ビジュアル — フォーカルポイント、視覚的階層構造、アイコンのアクセシビリティ
3. カラー — アクセントカラーの使用規律、60/30/10 準拠
4. タイポグラフィ — フォントサイズ/ウェイトの制約遵守
5. スペーシング — グリッド配置、トークンの一貫性
6. レジストリセーフティ — サードパーティコンポーネントの検査要件

shadcn 連携:

• React/Next.js/Vite プロジェクトで components.json が欠落していることを検出
• ユーザーを ui.shadcn.com/create のプリセット設定にガイド
• プリセット文字列はフェーズ間で再現可能なプランニング成果物になる
• セーフティゲートにより、サードパーティコンポーネント使用前に npx shadcn view と npx shadcn diff が必要

---

4. フェーズプランニング

コマンド: /gsd-plan-phase [N] [--auto] [--skip-research] [--skip-verify]

目的: 実装ドメインをリサーチし、検証済みのアトミックな実行プランを作成します。

要件:

• REQ-PLAN-01: システムは実装アプローチを調査するフェーズリサーチャーを起動しなければならない
• REQ-PLAN-02: システムはそれぞれ2〜3タスクのプランを作成しなければならず、各タスクは1つのコンテキストウィンドウに収まるサイズとする
• REQ-PLAN-03: システムはプランを XML で構造化しなければならない。<task> 要素には name、files、action、verify、done フィールドを含む
• REQ-PLAN-04: システムはすべてのプランに read_first と acceptance_criteria セクションを含めなければならない
• REQ-PLAN-05: --skip-verify が設定されていない限り、システムはプランチェッカー検証ループ（最大3回の反復）を実行しなければならない
• REQ-PLAN-06: システムはリサーチフェーズをバイパスする --skip-research フラグをサポートしなければならない
• REQ-PLAN-07: フロントエンドフェーズが検出され UI-SPEC.md が存在しない場合、システムはユーザーに /gsd-ui-phase の実行を促さなければならない（UI セーフティゲート）
• REQ-PLAN-08: workflow.nyquist_validation が有効な場合、システムは Nyquist バリデーションマッピングを含めなければならない
• REQ-PLAN-09: プランニング完了前に、すべてのフェーズ要件が少なくとも1つのプランでカバーされていることをシステムは検証しなければならない（要件カバレッジゲート）

生成物:

成果物	説明
{phase}-RESEARCH.md	エコシステムリサーチの結果
{phase}-{N}-PLAN.md	アトミックな実行プラン（各2〜3タスク）
{phase}-VALIDATION.md	テストカバレッジマッピング（Nyquist レイヤー）

プラン構造（XML）:

<task type="auto">
  <name>Create login endpoint</name>
  <files>src/app/api/auth/login/route.ts</files>
  <action>
    Use jose for JWT. Validate credentials against users table.
    Return httpOnly cookie on success.
  </action>
  <verify>curl -X POST localhost:3000/api/auth/login returns 200 + Set-Cookie</verify>
  <done>Valid credentials return cookie, invalid return 401</done>
</task>

プランチェッカー検証（8つの次元）:

1. 要件カバレッジ — プランがすべてのフェーズ要件に対応しているか
2. タスクのアトミック性 — 各タスクが独立してコミット可能か
3. 依存関係の順序 — タスクが正しい順序で並んでいるか
4. ファイルスコープ — プラン間で過度なファイルの重複がないか
5. 検証コマンド — 各タスクにテスト可能な完了基準があるか
6. コンテキストフィット — タスクが1つのコンテキストウィンドウに収まるか
7. ギャップ検出 — 実装ステップに欠落がないか
8. Nyquist 準拠 — タスクに自動化された検証コマンドがあるか（有効時）

---

5. フェーズ実行

コマンド: /gsd-execute-phase <N>

目的: ウェーブベースの並列化を使用して、フェーズ内のすべてのプランを実行します。各エグゼキューターにはフレッシュなコンテキストウィンドウが割り当てられます。

要件:

• REQ-EXEC-01: システムはプランの依存関係を分析し、実行ウェーブにグループ化しなければならない
• REQ-EXEC-02: システムは各ウェーブ内で独立したプランを並列実行しなければならない
• REQ-EXEC-03: システムは各エグゼキューターにフレッシュなコンテキストウィンドウ（200K トークン）を付与しなければならない
• REQ-EXEC-04: システムはタスクごとにアトミックな git コミットを生成しなければならない
• REQ-EXEC-05: システムは完了した各プランに対して SUMMARY.md を生成しなければならない
• REQ-EXEC-06: システムはフェーズ目標が達成されたかを確認する実行後検証を実行しなければならない
• REQ-EXEC-07: システムは git ブランチ戦略（none、phase、milestone）をサポートしなければならない
• REQ-EXEC-08: タスク検証失敗時、システムはノードリペアオペレーターを呼び出さなければならない（有効時）
• REQ-EXEC-09: システムはクロスフェーズ回帰を検出するため、検証前に過去のフェーズのテストスイートを実行しなければならない

生成物:

成果物	説明
{phase}-{N}-SUMMARY.md	プランごとの実行結果
{phase}-VERIFICATION.md	実行後検証レポート
Git コミット	タスクごとのアトミックなコミット

ウェーブ実行:

• 依存関係のないプラン → ウェーブ 1（並列）
• ウェーブ 1 に依存するプラン → ウェーブ 2（並列、ウェーブ 1 完了を待機）
• すべてのプランが完了するまで継続
• ファイル競合がある場合、同一ウェーブ内で順次実行を強制

エグゼキューターの機能:

• 完全なタスク指示を含む PLAN.md を読み取り
• PROJECT.md、STATE.md、CONTEXT.md、RESEARCH.md にアクセス可能
• 構造化されたコミットメッセージで各タスクをアトミックにコミット
• 並列実行中のビルドロック競合を回避するため、コミット時に --no-verify を使用
• チェックポイントタイプに対応: auto、checkpoint:human-verify、checkpoint:decision、checkpoint:human-action
• プランからの逸脱を SUMMARY.md に報告

並列安全性:

• pre-commit フック: 並列エージェントではスキップ（--no-verify）、各ウェーブ後にオーケストレーターが一度実行
• STATE.md ロック: ファイルレベルのロックファイルにより、エージェント間の同時書き込みによるデータ破損を防止

---

6. 作業検証

コマンド: /gsd-verify-work [N]

目的: ユーザー受け入れテスト — 各成果物のテストをユーザーに順に案内し、失敗を自動診断します。

要件:

• REQ-VERIFY-01: システムはフェーズからテスト可能な成果物を抽出しなければならない
• REQ-VERIFY-02: システムは成果物をユーザー確認のために1つずつ提示しなければならない
• REQ-VERIFY-03: システムは失敗を自動診断するためにデバッグエージェントを起動しなければならない
• REQ-VERIFY-04: システムは特定された問題に対する修正プランを作成しなければならない
• REQ-VERIFY-05: サーバー/データベース/シード/スタートアップファイルを変更するフェーズに対して、システムはコールドスタートスモークテストを注入しなければならない
• REQ-VERIFY-06: システムは合否結果を含む UAT.md を生成しなければならない

生成物: {phase}-UAT.md — ユーザー受け入れテスト結果、問題が見つかった場合は修正プランも含む

---

6.5. Ship

コマンド: /gsd-ship [N] [--draft]

目的: ローカル完了からマージ済み PR への橋渡し。検証通過後、ブランチをプッシュし、プランニング成果物から自動生成された本文で PR を作成します。オプションでレビューをトリガーし、STATE.md で追跡します。

要件:

• REQ-SHIP-01: システムはシッピング前にフェーズが検証を通過していることを確認しなければならない
• REQ-SHIP-02: システムは gh CLI を使用してブランチをプッシュし PR を作成しなければならない
• REQ-SHIP-03: システムは SUMMARY.md、VERIFICATION.md、REQUIREMENTS.md から PR 本文を自動生成しなければならない
• REQ-SHIP-04: システムは STATE.md をシッピングステータスと PR 番号で更新しなければならない
• REQ-SHIP-05: システムはドラフト PR のための --draft フラグをサポートしなければならない

前提条件: フェーズ検証済み、gh CLI がインストール・認証済み、フィーチャーブランチで作業中

生成物: リッチな本文を持つ GitHub PR、STATE.md の更新

---

7. UI レビュー

コマンド: /gsd-ui-review [N]

目的: 実装済みフロントエンドコードに対する遡及的な6本柱のビジュアル監査。任意のプロジェクトでスタンドアロンで動作します。

要件:

• REQ-UIREVIEW-01: システムは6つの柱それぞれを1〜4のスケールで評価しなければならない
• REQ-UIREVIEW-02: システムは Playwright CLI を使用して .planning/ui-reviews/ にスクリーンショットをキャプチャしなければならない
• REQ-UIREVIEW-03: システムはスクリーンショットディレクトリ用の .gitignore を作成しなければならない
• REQ-UIREVIEW-04: システムは優先度の高い修正トップ3を特定しなければならない
• REQ-UIREVIEW-05: システムは（UI-SPEC.md なしで）抽象的な品質基準を使用してスタンドアロンで動作しなければならない

6つの監査柱（1〜4で評価）:

1. コピーライティング — CTA ラベル、空状態、エラー状態
2. ビジュアル — フォーカルポイント、視覚的階層構造、アイコンのアクセシビリティ
3. カラー — アクセントカラーの使用規律、60/30/10 準拠
4. タイポグラフィ — フォントサイズ/ウェイトの制約遵守
5. スペーシング — グリッド配置、トークンの一貫性
6. エクスペリエンスデザイン — ローディング/エラー/空状態のカバレッジ

生成物: {padded_phase}-UI-REVIEW.md — スコアと優先度付き修正リスト

---

8. マイルストーン管理

コマンド: /gsd-audit-milestone、/gsd-complete-milestone、/gsd-new-milestone [name]

目的: マイルストーンの完了を検証し、アーカイブし、リリースにタグを付け、次の開発サイクルを開始します。

要件:

• REQ-MILE-01: 監査はすべてのマイルストーン要件が満たされていることを検証しなければならない
• REQ-MILE-02: 監査はスタブ、プレースホルダー実装、未テストコードを検出しなければならない
• REQ-MILE-03: 監査はフェーズ間の Nyquist バリデーション準拠をチェックしなければならない
• REQ-MILE-04: 完了時にマイルストーンデータを MILESTONES.md にアーカイブしなければならない
• REQ-MILE-05: 完了時にリリース用の git タグ作成を提案しなければならない
• REQ-MILE-06: 完了時にブランチ戦略に応じてスカッシュマージまたは履歴付きマージを提案しなければならない
• REQ-MILE-07: 完了時に UI レビューのスクリーンショットをクリーンアップしなければならない
• REQ-MILE-08: 新しいマイルストーンは new-project と同じフロー（質問 → リサーチ → 要件 → ロードマップ）に従わなければならない
• REQ-MILE-09: 新しいマイルストーンは既存のワークフロー設定をリセットしてはならない

---

プランニング機能

9. フェーズ管理

コマンド: /gsd-phase、/gsd-phase --insert [N]、/gsd-phase --remove [N]

目的: 開発中のロードマップの動的な変更。

要件:

• REQ-PHASE-01: 追加は現在のロードマップの末尾に新しいフェーズを追加しなければならない
• REQ-PHASE-02: 挿入は既存フェーズ間に小数番号（例: 3.1）を使用しなければならない
• REQ-PHASE-03: 削除は後続のすべてのフェーズを再番号付けしなければならない
• REQ-PHASE-04: 削除は既に実行されたフェーズの削除を防止しなければならない
• REQ-PHASE-05: すべての操作は ROADMAP.md を更新し、フェーズディレクトリを作成/削除しなければならない

---

10. Quick モード

コマンド: /gsd-quick [--full] [--discuss] [--research]

目的: GSD の保証を維持しながら、より高速なパスでアドホックなタスクを実行します。

要件:

• REQ-QUICK-01: システムは自由形式のタスク説明を受け付けなければならない
• REQ-QUICK-02: システムはフルワークフローと同じプランナー＋エグゼキューターエージェントを使用しなければならない
• REQ-QUICK-03: システムはデフォルトでリサーチ、プランチェッカー、検証をスキップしなければならない
• REQ-QUICK-04: --full フラグはプランチェック（最大2回の反復）と実行後検証を有効にしなければならない
• REQ-QUICK-05: --discuss フラグは軽量なプランニング前ディスカッションを実行しなければならない
• REQ-QUICK-06: --research フラグはプランニング前にフォーカスされたリサーチエージェントを起動しなければならない
• REQ-QUICK-07: フラグは組み合わせ可能でなければならない（--discuss --research --full）
• REQ-QUICK-08: システムは Quick タスクを .planning/quick/YYMMDD-xxx-slug/ で追跡しなければならない
• REQ-QUICK-09: システムは Quick タスク実行時にアトミックなコミットを生成しなければならない

---

11. 自律モード

コマンド: /gsd-autonomous [--from N]

目的: 残りのすべてのフェーズを自律的に実行します — フェーズごとにディスカッション → プラン → 実行を行います。

要件:

• REQ-AUTO-01: システムはロードマップの順序で未完了のすべてのフェーズを反復処理しなければならない
• REQ-AUTO-02: システムは各フェーズに対してディスカッション → プラン → 実行を実行しなければならない
• REQ-AUTO-03: システムは明示的なユーザー判断が必要な場面（グレーゾーンの承認、ブロッカー、バリデーション）で一時停止しなければならない
• REQ-AUTO-04: システムは各フェーズ後に ROADMAP.md を再読み込みし、動的に挿入されたフェーズを検出しなければならない
• REQ-AUTO-05: --from N フラグは特定のフェーズ番号から開始しなければならない

---

12. フリーフォームルーティング

コマンド: /gsd-fast

目的: 自由形式のテキストを分析し、適切な GSD コマンドにルーティングします。

要件:

• REQ-DO-01: システムは自然言語入力からユーザーの意図を解析しなければならない
• REQ-DO-02: システムは意図を最も適切な GSD コマンドにマッピングしなければならない
• REQ-DO-03: システムは実行前にルーティング結果をユーザーに確認しなければならない
• REQ-DO-04: システムはプロジェクト既存 vs プロジェクト未作成のコンテキストを区別して処理しなければならない

---

13. ノートキャプチャ

コマンド: /gsd-capture

目的: ワークフローを中断することなくアイデアを記録する、摩擦ゼロのメモ機能。タイムスタンプ付きメモの追加、全メモの一覧表示、または構造化された Todo へのプロモーションが可能です。

要件:

• REQ-NOTE-01: システムは1回の Write 呼び出しでタイムスタンプ付きメモファイルを保存しなければならない
• REQ-NOTE-02: システムはプロジェクトスコープとグローバルスコープからすべてのメモを表示する list サブコマンドをサポートしなければならない
• REQ-NOTE-03: システムはメモを構造化された Todo に変換する promote N サブコマンドをサポートしなければならない
• REQ-NOTE-04: システムはグローバルスコープ操作のための --global フラグをサポートしなければならない
• REQ-NOTE-05: システムは Task、AskUserQuestion、Bash を使用してはならない — インラインでのみ実行

---

14. 自動進行（Next）

コマンド: /gsd-progress --next

目的: 現在のプロジェクト状態を自動検出し、次の論理的なワークフローステップに進めます。どのフェーズ/ステップにいるかを覚えておく必要がなくなります。

要件:

• REQ-NEXT-01: システムは STATE.md、ROADMAP.md、フェーズディレクトリを読み取り、現在のポジションを判定しなければならない
• REQ-NEXT-02: システムはディスカッション、プラン、実行、検証のいずれが必要かを検出しなければならない
• REQ-NEXT-03: システムは適切なコマンドを自動的に呼び出さなければならない
• REQ-NEXT-04: プロジェクトが存在しない場合、システムは /gsd-new-project を提案しなければならない
• REQ-NEXT-05: すべてのフェーズが完了している場合、システムは /gsd-complete-milestone を提案しなければならない

状態検出ロジック:

状態	アクション
.planning/ ディレクトリなし	/gsd-new-project を提案
フェーズに CONTEXT.md がない	/gsd-discuss-phase を実行
フェーズに PLAN.md ファイルがない	/gsd-plan-phase を実行
プランはあるが SUMMARY.md がない	/gsd-execute-phase を実行
実行済みだが VERIFICATION.md がない	/gsd-verify-work を実行
すべてのフェーズが完了	/gsd-complete-milestone を提案

---

品質保証機能

15. Nyquist バリデーション

目的: コード記述前に、フェーズ要件に対する自動テストカバレッジをマッピングします。Nyquist サンプリング定理にちなんで命名 — すべての要件に対してフィードバック信号が存在することを保証します。

要件:

• REQ-NYQ-01: システムは plan-phase リサーチ中に既存のテストインフラを検出しなければならない
• REQ-NYQ-02: システムは各要件を特定のテストコマンドにマッピングしなければならない
• REQ-NYQ-03: システムはウェーブ 0 タスク（実装前に必要なテストスキャフォールディング）を特定しなければならない
• REQ-NYQ-04: プランチェッカーは Nyquist 準拠を8番目の検証次元として適用しなければならない
• REQ-NYQ-05: システムは /gsd-validate-phase による遡及的バリデーションをサポートしなければならない
• REQ-NYQ-06: システムは workflow.nyquist_validation: false で無効化可能でなければならない

生成物: {phase}-VALIDATION.md — テストカバレッジコントラクト

遡及的バリデーション（/gsd-validate-phase [N]）:

• 実装をスキャンし、要件をテストにマッピング
• 自動検証がない要件のギャップを特定
• テストを生成するオーディターを起動（最大3回試行）
• 実装コードは決して変更しない — テストファイルと VALIDATION.md のみ
• 実装バグはユーザーが対処すべきエスカレーションとしてフラグ付け

---

16. プランチェック

目的: プランがフェーズ目標を達成するかを、実行前にゴールバックワード方式で検証します。

要件:

• REQ-PLANCK-01: システムは8つの品質次元に対してプランを検証しなければならない
• REQ-PLANCK-02: システムはプランが合格するまで最大3回の反復をループしなければならない
• REQ-PLANCK-03: システムは失敗に対して具体的かつ実行可能なフィードバックを提供しなければならない
• REQ-PLANCK-04: システムは workflow.plan_check: false で無効化可能でなければならない

---

17. 実行後検証

目的: コードベースがフェーズの約束を達成しているかを自動チェックします。

要件:

• REQ-POSTVER-01: システムはタスク完了だけでなく、フェーズ目標に対してチェックしなければならない
• REQ-POSTVER-02: システムは合否分析を含む VERIFICATION.md を生成しなければならない
• REQ-POSTVER-03: システムは /gsd-verify-work が対処すべき問題をログに記録しなければならない
• REQ-POSTVER-04: システムは workflow.verifier: false で無効化可能でなければならない

---

18. ノードリペア

目的: 実行中にタスク検証が失敗した場合の自律的な回復。

要件:

• REQ-REPAIR-01: システムは失敗を分析し、RETRY、DECOMPOSE、PRUNE のいずれかの戦略を選択しなければならない
• REQ-REPAIR-02: RETRY は具体的な調整を加えて再試行しなければならない
• REQ-REPAIR-03: DECOMPOSE はタスクをより小さな検証可能なサブステップに分解しなければならない
• REQ-REPAIR-04: PRUNE は達成不可能なタスクを削除し、ユーザーにエスカレーションしなければならない
• REQ-REPAIR-05: システムはリペア予算を尊重しなければならない（デフォルト: タスクあたり2回の試行）
• REQ-REPAIR-06: システムは workflow.node_repair_budget と workflow.node_repair で設定可能でなければならない

---

19. ヘルスバリデーション

コマンド: /gsd-health [--repair]

目的: .planning/ ディレクトリの整合性を検証し、問題を自動修復します。

要件:

• REQ-HEALTH-01: システムは必須ファイルの欠落をチェックしなければならない
• REQ-HEALTH-02: システムは設定の一貫性を検証しなければならない
• REQ-HEALTH-03: システムはサマリーのない孤立したプランを検出しなければならない
• REQ-HEALTH-04: システムはフェーズ番号とロードマップの同期をチェックしなければならない
• REQ-HEALTH-05: --repair フラグは回復可能な問題を自動修正しなければならない

---

20. クロスフェーズ回帰ゲート

目的: 実行後に過去のフェーズのテストスイートを実行することで、フェーズ間での回帰の蓄積を防止します。

要件:

• REQ-REGR-01: システムはフェーズ実行後に、完了済みの過去のすべてのフェーズのテストスイートを実行しなければならない
• REQ-REGR-02: システムはテスト失敗をクロスフェーズ回帰として報告しなければならない
• REQ-REGR-03: 回帰は実行後検証の前に表面化されなければならない
• REQ-REGR-04: システムはどの過去フェーズのテストが壊れたかを特定しなければならない

実行タイミング: /gsd-execute-phase の検証ステップの前に自動実行されます。

---

21. 要件カバレッジゲート

目的: プランニング完了前に、すべてのフェーズ要件が少なくとも1つのプランでカバーされていることを保証します。

要件:

• REQ-COVGATE-01: システムは ROADMAP.md からフェーズに割り当てられたすべての要件 ID を抽出しなければならない
• REQ-COVGATE-02: システムは各要件が少なくとも1つの PLAN.md に含まれていることを検証しなければならない
• REQ-COVGATE-03: カバーされていない要件はプランニング完了をブロックしなければならない
• REQ-COVGATE-04: システムはどの特定の要件にプランカバレッジがないかを報告しなければならない

実行タイミング: /gsd-plan-phase の末尾、プランチェッカーループの後に自動実行されます。

---

コンテキストエンジニアリング機能

22. コンテキストウィンドウ監視

目的: コンテキストが不足し始めた際にユーザーとエージェントの両方にアラートを出し、コンテキストの劣化を防止します。

要件:

• REQ-CTX-01: ステータスラインはユーザーにコンテキスト使用率をパーセンテージで表示しなければならない
• REQ-CTX-02: コンテキストモニターは残量 35% 以下で（WARNING）エージェント向け警告を注入しなければならない
• REQ-CTX-03: コンテキストモニターは残量 25% 以下で（CRITICAL）エージェント向け警告を注入しなければならない
• REQ-CTX-04: 警告はデバウンスされなければならない（繰り返し警告間に5回のツール使用）
• REQ-CTX-05: 重大度のエスカレーション（WARNING→CRITICAL）はデバウンスをバイパスしなければならない
• REQ-CTX-06: コンテキストモニターは GSD アクティブ vs 非 GSD アクティブプロジェクトを区別しなければならない
• REQ-CTX-07: 警告はアドバイザリーであり、ユーザーの意向を上書きする命令的なコマンドであってはならない
• REQ-CTX-08: すべてのフックはサイレントに失敗し、ツール実行をブロックしてはならない

アーキテクチャ: 2部構成のブリッジシステム:

1. ステータスラインがメトリクスを /tmp/claude-ctx-{session}.json に書き込み
2. コンテキストモニターがメトリクスを読み取り、additionalContext 警告を注入

---

23. セッション管理

コマンド: /gsd-pause-work、/gsd-resume-work、/gsd-progress

目的: コンテキストリセットやセッション間でのプロジェクトの継続性を維持します。

要件:

• REQ-SESSION-01: 一時停止は現在のポジションと次のステップを continue-here.md と構造化された HANDOFF.json に保存しなければならない
• REQ-SESSION-02: 再開は HANDOFF.json（優先）または状態ファイル（フォールバック）から完全なプロジェクトコンテキストを復元しなければならない
• REQ-SESSION-03: 進捗は現在のポジション、次のアクション、全体の完了状況を表示しなければならない
• REQ-SESSION-04: 進捗はすべての状態ファイル（STATE.md、ROADMAP.md、フェーズディレクトリ）を読み取らなければならない
• REQ-SESSION-05: すべてのセッション操作は /clear（コンテキストリセット）後も動作しなければならない
• REQ-SESSION-06: HANDOFF.json にはブロッカー、保留中の人的アクション、進行中のタスク状態を含めなければならない
• REQ-SESSION-07: 再開時にセッション開始直後に人的アクションとブロッカーを即座に表面化しなければならない

---

24. セッションレポート

コマンド: /gsd-pause-work --report

目的: 実施した作業、達成した成果、推定リソース使用量をキャプチャした、構造化されたセッション後のサマリードキュメントを生成します。

要件:

• REQ-REPORT-01: システムは STATE.md、git log、プラン/サマリーファイルからデータを収集しなければならない
• REQ-REPORT-02: システムは行ったコミット、実行したプラン、進行したフェーズを含めなければならない
• REQ-REPORT-03: システムはセッションアクティビティに基づいてトークン使用量とコストを推定しなければならない
• REQ-REPORT-04: システムはアクティブなブロッカーと行った決定事項を含めなければならない
• REQ-REPORT-05: システムは次のステップを推奨しなければならない

生成物: .planning/reports/SESSION_REPORT.md

レポートセクション:

• セッション概要（期間、マイルストーン、フェーズ）
• 実施した作業（コミット、プラン、フェーズ）
• 成果と成果物
• ブロッカーと決定事項
• リソース推定（トークン、コスト）
• 次のステップの推奨

---

25. マルチエージェントオーケストレーション

目的: 各タスクにフレッシュなコンテキストウィンドウを持つ専門エージェントを調整します。

要件:

• REQ-ORCH-01: 各エージェントはフレッシュなコンテキストウィンドウを受け取らなければならない
• REQ-ORCH-02: オーケストレーターは軽量でなければならない — エージェントを起動し、結果を収集し、次にルーティング
• REQ-ORCH-03: コンテキストペイロードには関連するすべてのプロジェクト成果物を含めなければならない
• REQ-ORCH-04: 並列エージェントは真に独立でなければならない（共有可変状態なし）
• REQ-ORCH-05: エージェントの結果はオーケストレーターが処理する前にディスクに書き込まれなければならない
• REQ-ORCH-06: 失敗したエージェントは検出されなければならない（実際の出力 vs 報告された失敗をスポットチェック）

---

26. モデルプロファイル

コマンド: /gsd-config --profile <quality|balanced|budget|inherit>

目的: 各エージェントが使用する AI モデルを制御し、品質とコストのバランスを取ります。

要件:

• REQ-MODEL-01: システムは4つのプロファイルをサポートしなければならない: quality、balanced、budget、inherit
• REQ-MODEL-02: 各プロファイルはエージェントごとのモデルティアを定義しなければならない（プロファイルテーブル参照）
• REQ-MODEL-03: エージェントごとのオーバーライドはプロファイルより優先されなければならない
• REQ-MODEL-04: inherit プロファイルはランタイムの現在のモデル選択に従わなければならない
• REQ-MODEL-04a: 非 Anthropic プロバイダー（OpenRouter、ローカルモデル）を使用する場合、予期しない API コストを避けるために inherit プロファイルを使用しなければならない
• REQ-MODEL-05: プロファイル切り替えはプログラマティックでなければならない（スクリプト、LLM 駆動ではない）
• REQ-MODEL-06: モデル解決はオーケストレーションごとに1回のみ実行し、スポーンごとに実行してはならない

プロファイル割り当て:

エージェント	quality	balanced	budget	inherit
gsd-planner	Opus	Opus	Sonnet	Inherit
gsd-roadmapper	Opus	Sonnet	Sonnet	Inherit
gsd-executor	Opus	Sonnet	Sonnet	Inherit
gsd-phase-researcher	Opus	Sonnet	Haiku	Inherit
gsd-project-researcher	Opus	Sonnet	Haiku	Inherit
gsd-research-synthesizer	Sonnet	Sonnet	Haiku	Inherit
gsd-debugger	Opus	Sonnet	Sonnet	Inherit
gsd-codebase-mapper	Sonnet	Haiku	Haiku	Inherit
gsd-verifier	Sonnet	Sonnet	Haiku	Inherit
gsd-plan-checker	Sonnet	Sonnet	Haiku	Inherit
gsd-integration-checker	Sonnet	Sonnet	Haiku	Inherit
gsd-nyquist-auditor	Sonnet	Sonnet	Haiku	Inherit

---

ブラウンフィールド機能

27. コードベースマッピング

コマンド: /gsd-map-codebase [area]

目的: 新しいプロジェクトを開始する前に既存のコードベースを分析し、GSD が既存の構成を理解できるようにします。

要件:

• REQ-MAP-01: システムは各分析領域に対して並列マッパーエージェントを起動しなければならない
• REQ-MAP-02: システムは .planning/codebase/ に構造化されたドキュメントを生成しなければならない
• REQ-MAP-03: システムは技術スタック、アーキテクチャパターン、コーディング規約、懸念事項を検出しなければならない
• REQ-MAP-04: 後続の /gsd-new-project はコードベースマッピングを読み込み、追加する内容に焦点を当てた質問を行わなければならない
• REQ-MAP-05: オプションの [area] 引数はマッピングを特定の領域にスコープしなければならない

生成物:

ドキュメント	内容
STACK.md	言語、フレームワーク、データベース、インフラストラクチャ
ARCHITECTURE.md	パターン、レイヤー、データフロー、境界
CONVENTIONS.md	命名、ファイル構成、コードスタイル、テストパターン
CONCERNS.md	技術的負債、セキュリティ問題、パフォーマンスボトルネック
STRUCTURE.md	ディレクトリレイアウトとファイル構成
TESTING.md	テストインフラ、カバレッジ、パターン
INTEGRATIONS.md	外部サービス、API、サードパーティ依存関係

---

ユーティリティ機能

28. デバッグシステム

コマンド: /gsd-debug [description]

目的: コンテキストリセットを超えて持続する状態を持つ、体系的なデバッグ。

要件:

• REQ-DEBUG-01: システムは .planning/debug/ にデバッグセッションファイルを作成しなければならない
• REQ-DEBUG-02: システムは仮説、証拠、排除された理論を追跡しなければならない
• REQ-DEBUG-03: システムはコンテキストリセット後もデバッグが継続するよう状態を永続化しなければならない
• REQ-DEBUG-04: システムは解決済みとマークする前に人的検証を要求しなければならない
• REQ-DEBUG-05: 解決済みセッションは .planning/debug/knowledge-base.md に追記されなければならない
• REQ-DEBUG-06: ナレッジベースは再調査を防止するために新しいデバッグセッション時に参照されなければならない

デバッグセッションの状態: gathering → investigating → fixing → verifying → awaiting_human_verify → resolved

---

29. Todo 管理

コマンド: /gsd-capture [desc]、/gsd-capture --list

目的: セッション中にアイデアやタスクをキャプチャし、後で作業できるようにします。

要件:

• REQ-TODO-01: システムは現在の会話コンテキストから Todo をキャプチャしなければならない
• REQ-TODO-02: Todo は .planning/todos/pending/ に保存されなければならない
• REQ-TODO-03: 完了した Todo は .planning/todos/completed/ に移動されなければならない
• REQ-TODO-04: check-todos は保留中のすべてのアイテムを一覧表示し、作業するアイテムを選択できなければならない

---

30. 統計ダッシュボード

コマンド: /gsd-stats

目的: プロジェクトメトリクスを表示します — フェーズ、プラン、要件、git 履歴、タイムライン。

要件:

• REQ-STATS-01: システムはフェーズ/プランの完了数を表示しなければならない
• REQ-STATS-02: システムは要件カバレッジを表示しなければならない
• REQ-STATS-03: システムは git コミットメトリクスを表示しなければならない
• REQ-STATS-04: システムは複数の出力形式（json、table、bar）をサポートしなければならない

---

31. アップデートシステム

コマンド: /gsd-update

目的: GSD を最新バージョンに更新し、チェンジログのプレビューを表示します。

要件:

• REQ-UPDATE-01: システムは npm 経由で新しいバージョンをチェックしなければならない
• REQ-UPDATE-02: システムは更新前に新しいバージョンのチェンジログを表示しなければならない
• REQ-UPDATE-03: システムはランタイムを認識し、正しいディレクトリを対象としなければならない
• REQ-UPDATE-04: システムはローカルで変更されたファイルを gsd-local-patches/ にバックアップしなければならない
• REQ-UPDATE-05: /gsd-update --reapply は更新後にローカルの変更を復元しなければならない

---

32. 設定管理

コマンド: /gsd-settings

目的: ワークフロートグルとモデルプロファイルのインタラクティブな設定。

要件:

• REQ-SETTINGS-01: システムは現在の設定をトグルオプション付きで表示しなければならない
• REQ-SETTINGS-02: システムは .planning/config.json を更新しなければならない
• REQ-SETTINGS-03: システムはグローバルデフォルト（~/.gsd/defaults.json）としての保存をサポートしなければならない

設定可能な項目:

設定	型	デフォルト	説明
mode	enum	interactive	interactive または yolo（自動承認）
granularity	enum	standard	coarse、standard、または fine
model_profile	enum	balanced	quality、balanced、budget、または inherit
workflow.research	boolean	true	プランニング前のドメインリサーチ
workflow.plan_check	boolean	true	プラン検証ループ
workflow.verifier	boolean	true	実行後検証
workflow.auto_advance	boolean	false	ディスカッション→プラン→実行の自動チェーン
workflow.nyquist_validation	boolean	true	Nyquist テストカバレッジマッピング
workflow.ui_phase	boolean	true	UI デザインコントラクト生成
workflow.ui_safety_gate	boolean	true	フロントエンドフェーズで ui-phase を促す
workflow.node_repair	boolean	true	自律的なタスクリペア
workflow.node_repair_budget	number	2	タスクあたりの最大リペア試行回数
planning.commit_docs	boolean	true	.planning/ ファイルを git にコミット
planning.search_gitignored	boolean	false	gitignore されたファイルを検索に含める
parallelization.enabled	boolean	true	独立したプランを同時実行
git.branching_strategy	enum	none	none、phase、または milestone

---

33. テスト生成

コマンド: /gsd-add-tests [N]

目的: 完了したフェーズに対して、UAT 基準と実装に基づいてテストを生成します。

要件:

• REQ-TEST-01: システムは完了したフェーズの実装を分析しなければならない
• REQ-TEST-02: システムは UAT 基準と受け入れ基準に基づいてテストを生成しなければならない
• REQ-TEST-03: システムは既存のテストインフラパターンを使用しなければならない

---

インフラストラクチャ機能

34. Git 連携

目的: アトミックなコミット、ブランチ戦略、クリーンな履歴管理。

要件:

• REQ-GIT-01: 各タスクは独自のアトミックなコミットを持たなければならない
• REQ-GIT-02: コミットメッセージは構造化されたフォーマットに従わなければならない: type(scope): description
• REQ-GIT-03: システムは3つのブランチ戦略をサポートしなければならない: none、phase、milestone
• REQ-GIT-04: phase 戦略はフェーズごとに1つのブランチを作成しなければならない
• REQ-GIT-05: milestone 戦略はマイルストーンごとに1つのブランチを作成しなければならない
• REQ-GIT-06: complete-milestone はスカッシュマージ（推奨）または履歴付きマージを提案しなければならない
• REQ-GIT-07: システムは .planning/ ファイルに対して commit_docs 設定を尊重しなければならない
• REQ-GIT-08: システムは .gitignore の .planning/ を自動検出し、コミットをスキップしなければならない

コミットフォーマット:

type(phase-plan): description

# Examples:
docs(08-02): complete user registration plan
feat(08-02): add email confirmation flow
fix(03-01): correct auth token expiry

---

35. CLI ツール

目的: ワークフローとエージェント向けのプログラマティックユーティリティ。反復的なインライン bash パターンを置き換えます。

要件:

• REQ-CLI-01: システムは状態、設定、フェーズ、ロードマップ操作のためのアトミックなコマンドを提供しなければならない
• REQ-CLI-02: システムは各ワークフローのすべてのコンテキストを読み込む複合 init コマンドを提供しなければならない
• REQ-CLI-03: システムは機械可読な出力のための --raw フラグをサポートしなければならない
• REQ-CLI-04: システムはサンドボックス化されたサブエージェント操作のための --cwd フラグをサポートしなければならない
• REQ-CLI-05: すべての操作は Windows でスラッシュパスを使用しなければならない

コマンドカテゴリ: State（11サブコマンド）、Phase（5）、Roadmap（3）、Verify（8）、Template（2）、Frontmatter（4）、Scaffold（4）、Init（12）、Validate（2）、Progress、Stats、Todo

---

36. マルチランタイムサポート

目的: 複数の AI コーディングエージェントランタイムで GSD を実行します。

要件:

• REQ-RUNTIME-01: システムは Claude Code、OpenCode、Gemini CLI、Kilo、Codex、Copilot、Antigravity をサポートしなければならない
• REQ-RUNTIME-02: インストーラーはランタイムごとにコンテンツを変換しなければならない（ツール名、パス、フロントマター）
• REQ-RUNTIME-03: インストーラーはインタラクティブおよび非インタラクティブ（--claude --global）モードをサポートしなければならない
• REQ-RUNTIME-04: インストーラーはグローバルとローカルの両方のインストールをサポートしなければならない
• REQ-RUNTIME-05: アンインストールは他の設定に影響を与えることなく、すべての GSD ファイルをクリーンに削除しなければならない
• REQ-RUNTIME-06: インストーラーはプラットフォームの違い（Windows、macOS、Linux、WSL、Docker）を処理しなければならない

ランタイム変換:

側面	Claude Code	OpenCode	Gemini	Kilo	Codex	Copilot	Antigravity
コマンド	スラッシュコマンド	スラッシュコマンド	スラッシュコマンド	スラッシュコマンド	スキル（TOML）	スラッシュコマンド	スキル
エージェント形式	Claude ネイティブ	mode: subagent	Claude ネイティブ	mode: subagent	スキル	ツールマッピング	スキル
フックイベント	PostToolUse	N/A	AfterTool	N/A	N/A	N/A	N/A
設定	settings.json	opencode.json(c)	settings.json	kilo.json(c)	TOML	Instructions	Config

---

37. フックシステム

目的: コンテキスト監視、ステータス表示、アップデートチェックのためのランタイムイベントフック。

要件:

• REQ-HOOK-01: ステータスラインはモデル、現在のタスク、ディレクトリ、コンテキスト使用量を表示しなければならない
• REQ-HOOK-02: コンテキストモニターは閾値レベルでエージェント向け警告を注入しなければならない
• REQ-HOOK-03: アップデートチェッカーはセッション開始時にバックグラウンドで実行されなければならない
• REQ-HOOK-04: すべてのフックは CLAUDE_CONFIG_DIR 環境変数を尊重しなければならない
• REQ-HOOK-05: すべてのフックは3秒の stdin タイムアウトガードを含まなければならない
• REQ-HOOK-06: すべてのフックはエラー時にサイレントに失敗しなければならない
• REQ-HOOK-07: コンテキスト使用量は autocompact バッファ（16.5% リザーブ）に対して正規化されなければならない

ステータスライン表示:

[⬆ /gsd-update │] model │ [current task │] directory [█████░░░░░ 50%]

カラーコーディング: 50% 未満は緑、65% 未満は黄、80% 未満はオレンジ、80% 以上はドクロ絵文字付き赤

38. 開発者プロファイリング

コマンド: /gsd-profile-user [--questionnaire] [--refresh]

目的: Claude Code のセッション履歴を分析し、8つの次元にわたる行動プロファイルを構築します。開発者のスタイルに合わせて Claude のレスポンスをパーソナライズするための成果物を生成します。

次元:

1. コミュニケーションスタイル（簡潔 vs 冗長、フォーマル vs カジュアル）
2. 意思決定パターン（迅速 vs 慎重、リスク許容度）
3. デバッグアプローチ（体系的 vs 直感的、ログの好み）
4. UX の好み（デザインセンス、アクセシビリティの認識）
5. ベンダー/テクノロジーの選択（フレームワークの好み、エコシステムへの精通度）
6. フラストレーションのトリガー（ワークフローで摩擦を引き起こすもの）
7. 学習スタイル（ドキュメント vs 例、深さの好み）
8. 説明の深さ（ハイレベル vs 実装詳細）

生成される成果物:

• USER-PROFILE.md — 証拠引用付きの完全な行動プロファイル
• CLAUDE.md プロファイルセクション — Claude Code により自動検出

フラグ:

• --questionnaire — セッション履歴が利用できない場合のインタラクティブなアンケートフォールバック
• --refresh — セッションを再分析してプロファイルを再生成

パイプラインモジュール:

• profile-pipeline.cjs — セッションスキャン、メッセージ抽出、サンプリング
• profile-output.cjs — プロファイルレンダリング、アンケート、成果物生成
• gsd-user-profiler エージェント — セッションデータからの行動分析

要件:

• REQ-PROF-01: セッション分析は少なくとも8つの行動次元をカバーしなければならない
• REQ-PROF-02: プロファイルは実際のセッションメッセージからの証拠を引用しなければならない
• REQ-PROF-03: セッション履歴がない場合、アンケートがフォールバックとして利用可能でなければならない
• REQ-PROF-04: 生成された成果物は Claude Code により検出可能でなければならない（CLAUDE.md 連携）

39. 実行ハードニング

目的: 実行パイプラインに対する3つの段階的な品質改善。クロスプランの失敗が連鎖する前に検出します。

コンポーネント:

1. プレウェーブ依存関係チェック（execute-phase） ウェーブ N+1 を起動する前に、前のウェーブの成果物からのキーリンクが存在し、正しく接続されていることを検証します。クロスプランの依存関係ギャップが下流の失敗に連鎖するのを防ぎます。

2. クロスプランデータコントラクト — 第9次元（plan-checker） データパイプラインを共有するプランが互換性のある変換を持っているかチェックする新しい分析次元。あるプランが別のプランが元の形式で必要とするデータを削除する場合にフラグを立てます。

3. エクスポートレベルスポットチェック（verify-phase） レベル3の配線検証が通過した後、個々のエクスポートが実際に使用されているかスポットチェックします。配線されたファイル内に存在するが呼び出されないデッドストアを検出します。

要件:

• REQ-HARD-01: プレウェーブチェックは次のウェーブを起動する前に、すべての前のウェーブの成果物からのキーリンクを検証しなければならない
• REQ-HARD-02: クロスプランコントラクトチェックはプラン間の互換性のないデータ変換を検出しなければならない
• REQ-HARD-03: エクスポートスポットチェックは配線されたファイル内のデッドストアを特定しなければならない

---

40. 検証デット追跡

コマンド: /gsd-audit-uat

目的: 未解決のテストを持つフェーズを通過した際の UAT/検証項目のサイレントな喪失を防止します。すべての過去フェーズの検証デットを表面化し、項目が忘れられないようにします。

コンポーネント:

1. クロスフェーズヘルスチェック（progress.md ステップ 1.6） すべての /gsd-progress 呼び出しで、現在のマイルストーンのすべてのフェーズの未解決項目（pending、skipped、blocked、human_needed）をスキャンします。アクション可能なリンク付きのノンブロッキング警告セクションを表示します。

2. status: partial（verify-work.md、UAT.md） 「セッション終了」と「すべてのテスト解決済み」を区別する新しい UAT ステータス。テストがまだ pending、blocked、または理由なく skipped の場合に status: complete を防止します。

3. result: blocked と blocked_by タグ（verify-work.md、UAT.md） 外部依存関係（サーバー、物理デバイス、リリースビルド、サードパーティサービス）によりブロックされたテストのための新しいテスト結果タイプ。スキップされたテストとは別にカテゴリ分けされます。

4. HUMAN-UAT.md の永続化（execute-phase.md） 検証が human_needed を返した場合、項目は status: partial の追跡可能な HUMAN-UAT.md ファイルとして永続化されます。クロスフェーズヘルスチェックと監査システムに反映されます。

5. フェーズ完了警告（phase.cjs、transition.md） phase complete CLI は JSON 出力に検証デット警告を返します。トランジションワークフローは確認前に未解決項目を表面化します。

要件:

• REQ-DEBT-01: システムは /gsd-progress ですべての過去フェーズの未解決 UAT/検証項目を表面化しなければならない
• REQ-DEBT-02: システムは不完全なテスト（partial）と完了したテスト（complete）を区別しなければならない
• REQ-DEBT-03: システムはブロックされたテストを blocked_by タグでカテゴリ分けしなければならない
• REQ-DEBT-04: システムは human_needed の検証項目を追跡可能な UAT ファイルとして永続化しなければならない
• REQ-DEBT-05: システムは検証デットが存在する場合、フェーズ完了とトランジション時に警告（ノンブロッキング）しなければならない
• REQ-DEBT-06: /gsd-audit-uat はすべてのフェーズをスキャンし、項目をテスト可能性別にカテゴリ分けし、人的テストプランを生成しなければならない

---

v1.27 の機能

41. Fast モード

コマンド: /gsd-fast [task description]

目的: サブエージェントの起動や PLAN.md ファイルの生成なしに、些細なタスクをインラインで実行します。プランニングのオーバーヘッドを正当化できないほど小さなタスク向け: タイポ修正、設定変更、小規模なリファクタリング、コミット忘れ、簡単な追加。

要件:

• REQ-FAST-01: システムはサブエージェントなしで現在のコンテキストでタスクを直接実行しなければならない
• REQ-FAST-02: システムは変更に対してアトミックな git コミットを生成しなければならない
• REQ-FAST-03: システムは状態の一貫性のためにタスクを .planning/quick/ で追跡しなければならない
• REQ-FAST-04: リサーチ、マルチステッププランニング、または検証が必要なタスクにシステムを使用してはならない

/gsd-quick との使い分け:

• /gsd-fast — 2分以内に実行可能な一文のタスク（タイポ修正、設定変更、小規模な追加）
• /gsd-quick — リサーチ、マルチステッププランニング、または検証が必要なもの

---

42. クロス AI ピアレビュー

コマンド: /gsd-review --phase N [--gemini] [--claude] [--codex] [--coderabbit] [--opencode] [--qwen] [--cursor] [--all]

目的: 外部の AI CLI（Gemini、Claude、Codex、CodeRabbit、OpenCode、Qwen Code、Cursor）を呼び出して、フェーズプランを独立してレビューします。レビュアーごとのフィードバックを含む構造化された REVIEWS.md を生成します。

要件:

• REQ-REVIEW-01: システムはシステム上で利用可能な AI CLI を検出しなければならない
• REQ-REVIEW-02: システムはフェーズプランから構造化されたレビュープロンプトを構築しなければならない
• REQ-REVIEW-03: システムは選択された各 CLI を独立して呼び出さなければならない
• REQ-REVIEW-04: システムはレスポンスを収集して REVIEWS.md を生成しなければならない
• REQ-REVIEW-05: レビューは /gsd-plan-phase --reviews で使用可能でなければならない

生成物: {phase}-REVIEWS.md — レビュアーごとの構造化されたフィードバック

---

43. バックログパーキングロット

コマンド: /gsd-capture --backlog <description>、/gsd-review-backlog、/gsd-capture --seed <idea>

目的: アクティブなプランニングの準備ができていないアイデアをキャプチャします。バックログ項目は 999.x の番号付けを使用して、アクティブなフェーズシーケンスの外に留まります。シードは、適切なマイルストーンで自動的に表面化するトリガー条件を持つ、将来を見据えたアイデアです。

要件:

• REQ-BACKLOG-01: バックログ項目はアクティブなフェーズシーケンスの外に留まるために 999.x の番号付けを使用しなければならない
• REQ-BACKLOG-02: /gsd-discuss-phase と /gsd-plan-phase が動作するよう、フェーズディレクトリは即座に作成されなければならない
• REQ-BACKLOG-03: /gsd-review-backlog は項目ごとにプロモート、維持、削除のアクションをサポートしなければならない
• REQ-BACKLOG-04: プロモートされた項目はアクティブなマイルストーンシーケンスに再番号付けされなければならない
• REQ-SEED-01: シードは完全な WHY と表面化条件の WHEN をキャプチャしなければならない
• REQ-SEED-02: /gsd-new-milestone はシードをスキャンして一致するものを提示しなければならない

生成物:

成果物	説明
.planning/phases/999.x-slug/	バックログ項目ディレクトリ
.planning/seeds/SEED-NNN-slug.md	トリガー条件付きシード

---

44. 永続コンテキストスレッド

コマンド: /gsd-thread [name | description]

目的: 複数セッションにまたがるが特定のフェーズには属さない作業のための、軽量なクロスセッションナレッジストア。/gsd-pause-work よりも軽量 — フェーズ状態やプランコンテキストは不要です。

要件:

• REQ-THREAD-01: システムは作成、一覧、再開モードをサポートしなければならない
• REQ-THREAD-02: スレッドは .planning/threads/ にマークダウンファイルとして保存されなければならない
• REQ-THREAD-03: スレッドファイルには Goal、Context、References、Next Steps セクションを含めなければならない
• REQ-THREAD-04: スレッドの再開時にその完全なコンテキストを現在のセッションに読み込まなければならない
• REQ-THREAD-05: スレッドはフェーズまたはバックログ項目にプロモート可能でなければならない

生成物: .planning/threads/{slug}.md — 永続コンテキストスレッド

---

45. PR ブランチフィルタリング

コマンド: /gsd-pr-branch [target branch]

目的: .planning/ のコミットを除外して、プルリクエストに適したクリーンなブランチを作成します。レビュアーにはコード変更のみが表示され、GSD プランニング成果物は表示されません。

要件:

• REQ-PRBRANCH-01: システムは .planning/ ファイルのみを変更するコミットを特定しなければならない
• REQ-PRBRANCH-02: システムはプランニングコミットを除外した新しいブランチを作成しなければならない
• REQ-PRBRANCH-03: コード変更はコミットされた通りに正確に保持されなければならない

---

46. セキュリティハードニング

目的: GSD のプランニング成果物に対する多層防御セキュリティ。GSD は LLM のシステムプロンプトとなるマークダウンファイルを生成するため、これらのファイルに流入するユーザー制御テキストは間接的なプロンプトインジェクションの潜在的なベクターです。

コンポーネント:

1. 集中型セキュリティモジュール（security.cjs）

• パストラバーサル防止 — ファイルパスがプロジェクトディレクトリ内に解決されることを検証
• プロンプトインジェクション検出 — ユーザー提供テキスト内の既知のインジェクションパターンをスキャン
• 安全な JSON パース — 状態破損前に不正な入力をキャッチ
• フィールド名バリデーション — 設定フィールド名を通じたインジェクションを防止
• シェル引数バリデーション — シェル補間前にユーザーテキストをサニタイズ

2. プロンプトインジェクションガードフック（gsd-prompt-guard.js） .planning/ を対象とする Write/Edit 呼び出しをインジェクションパターンでスキャンする PreToolUse フック。アドバイザリーのみ — 正当な操作をブロックせず、検出を認識のためにログ記録します。

3. ワークフローガードフック（gsd-workflow-guard.js） Claude が GSD ワークフローコンテキスト外でファイル編集を試行した際に検出する PreToolUse フック。直接編集の代わりに /gsd-quick や /gsd-fast の使用をアドバイスします。hooks.workflow_guard（デフォルト: false）で設定可能です。

4. CI 対応インジェクションスキャナー（prompt-injection-scan.test.cjs） すべてのエージェント、ワークフロー、コマンドファイルに埋め込まれたインジェクションベクターをスキャンするテストスイート。

要件:

• REQ-SEC-01: すべてのユーザー提供ファイルパスはプロジェクトディレクトリに対して検証されなければならない
• REQ-SEC-02: プロンプトインジェクションパターンはテキストがプランニング成果物に入る前に検出されなければならない
• REQ-SEC-03: セキュリティフックはアドバイザリーのみでなければならない（正当な操作を決してブロックしない）
• REQ-SEC-04: ユーザー入力の JSON パースは不正なデータをグレースフルにキャッチしなければならない
• REQ-SEC-05: macOS の /var → /private/var シンボリックリンク解決がパスバリデーションで処理されなければならない

---

47. マルチリポワークスペースサポート

目的: モノレポおよびマルチリポ構成のための自動検出とプロジェクトルート解決。.planning/ がリポジトリ境界を超えて解決する必要がある場合のワークスペースをサポートします。

要件:

• REQ-MULTIREPO-01: システムはマルチリポワークスペース設定を自動検出しなければならない
• REQ-MULTIREPO-02: システムはリポジトリ境界を超えてプロジェクトルートを解決しなければならない
• REQ-MULTIREPO-03: エグゼキューターはマルチリポモードでリポジトリごとのコミットハッシュを記録しなければならない

---

48. ディスカッション監査証跡

目的: /gsd-discuss-phase 中に DISCUSSION-LOG.md を自動生成し、ディスカッション中の決定事項の完全な監査証跡を残します。

要件:

• REQ-DISCLOG-01: システムは discuss-phase 中に DISCUSSION-LOG.md を自動生成しなければならない
• REQ-DISCLOG-02: ログは質問内容、提示されたオプション、行われた決定をキャプチャしなければならない
• REQ-DISCLOG-03: 決定 ID は discuss-phase から plan-phase へのトレーサビリティを可能にしなければならない

---

v1.28 の機能

49. フォレンジクス

コマンド: /gsd-forensics [description]

目的: 失敗または停滞した GSD ワークフローのポストモーテム調査。

要件:

• REQ-FORENSICS-01: システムは git 履歴の異常（停滞ループ、長いギャップ、繰り返しコミット）を分析しなければならない
• REQ-FORENSICS-02: システムは成果物の整合性をチェックしなければならない（完了したフェーズに期待されるファイルがあるか）
• REQ-FORENSICS-03: システムは .planning/forensics/ に保存されるマークダウンレポートを生成しなければならない
• REQ-FORENSICS-04: システムは調査結果で GitHub Issue の作成を提案しなければならない
• REQ-FORENSICS-05: システムはプロジェクトファイルを変更してはならない（読み取り専用の調査）

生成物:

成果物	説明
.planning/forensics/report-{timestamp}.md	ポストモーテム調査レポート

プロセス:

1. スキャン — git 履歴の異常を分析: 停滞ループ、コミット間の長いギャップ、繰り返しの同一コミット
2. 整合性チェック — 完了したフェーズに期待される成果物ファイルがあるか検証
3. レポート — 調査結果を含むマークダウンレポートを生成し、.planning/forensics/ に保存
4. Issue — チームの可視性のため、調査結果で GitHub Issue の作成を提案

---

50. マイルストーンサマリー

コマンド: /gsd-milestone-summary [version]

目的: チームオンボーディングのためにマイルストーン成果物から包括的なプロジェクトサマリーを生成します。

要件:

• REQ-SUMMARY-01: システムはフェーズプラン、サマリー、検証結果を集約しなければならない
• REQ-SUMMARY-02: システムは現在のマイルストーンとアーカイブ済みマイルストーンの両方で動作しなければならない
• REQ-SUMMARY-03: システムは単一のナビゲート可能なドキュメントを生成しなければならない

生成物:

成果物	説明
MILESTONE-SUMMARY.md	マイルストーン成果物の包括的でナビゲート可能なサマリー

プロセス:

1. 収集 — 対象マイルストーンからフェーズプラン、サマリー、検証結果を集約
2. 統合 — 成果物をクロスリファレンス付きの単一のナビゲート可能なドキュメントに結合
3. 出力 — チームオンボーディングとステークホルダーレビューに適した MILESTONE-SUMMARY.md を作成

---

51. ワークストリームネームスペーシング

コマンド: /gsd-workstreams

目的: 異なるマイルストーン領域での同時作業のための並列ワークストリーム。

要件:

• REQ-WS-01: システムはワークストリーム状態を個別の .planning/workstreams/{name}/ ディレクトリに分離しなければならない
• REQ-WS-02: システムはワークストリーム名を検証しなければならない（英数字とハイフンのみ、パストラバーサルなし）
• REQ-WS-03: システムは list、create、switch、status、progress、complete、resume サブコマンドをサポートしなければならない

生成物:

成果物	説明
.planning/workstreams/{name}/	分離されたワークストリームディレクトリ構造

プロセス:

1. 作成 — 分離された .planning/workstreams/{name}/ ディレクトリで名前付きワークストリームを初期化
2. 切り替え — 後続の GSD コマンドのためにアクティブなワークストリームコンテキストを変更
3. 管理 — ワークストリームの一覧表示、ステータス確認、進捗追跡、完了、または再開

---

52. マネージャーダッシュボード

コマンド: /gsd-manager

目的: 1つのターミナルから複数のフェーズを管理するためのインタラクティブなコマンドセンター。

要件:

• REQ-MGR-01: システムはすべてのフェーズの概要をステータス付きで表示しなければならない
• REQ-MGR-02: システムは現在のマイルストーンスコープにフィルタリングしなければならない
• REQ-MGR-03: システムはフェーズの依存関係と競合を表示しなければならない

生成物: インタラクティブなターミナル出力

プロセス:

1. スキャン — 現在のマイルストーンのすべてのフェーズとそのステータスを読み込み
2. 表示 — フェーズの依存関係、競合、進捗を示す概要をレンダリング
3. 操作 — 個々のフェーズのナビゲーション、検査、操作のコマンドを受け付け

---

53. Assumptions ディスカッションモード

コマンド: /gsd-discuss-phase（workflow.discuss_mode: 'assumptions' 設定時）

目的: インタビュー形式の質問をコードベースファーストの仮定分析に置き換えます。

要件:

• REQ-ASSUME-01: システムは質問の前にコードベースを分析して構造化された仮定を生成しなければならない
• REQ-ASSUME-02: システムは仮定を信頼度レベル（Confident/Likely/Unclear）で分類しなければならない
• REQ-ASSUME-03: システムはデフォルトのディスカスモードと同一の CONTEXT.md フォーマットを生成しなければならない
• REQ-ASSUME-04: システムは信頼度ベースのスキップゲートをサポートしなければならない（すべて HIGH の場合は質問なし）

生成物:

成果物	説明
{phase}-CONTEXT.md	デフォルトのディスカスモードと同じフォーマット

プロセス:

1. 分析 — コードベースをスキャンして実装アプローチに関する構造化された仮定を生成
2. 分類 — 仮定を信頼度レベル別にカテゴリ分け: Confident、Likely、Unclear
3. ゲート — すべての仮定が HIGH 信頼度の場合、質問を完全にスキップ
4. 確認 — 不明確な仮定をターゲット化された質問としてユーザーに提示
5. 出力 — デフォルトのディスカスモードと同一フォーマットで {phase}-CONTEXT.md を生成

---

54. UI フェーズ自動検出

対象: /gsd-new-project および /gsd-progress

目的: UI 重視のプロジェクトを自動検出し、/gsd-ui-phase の推奨を表面化します。

要件:

• REQ-UI-DETECT-01: システムはプロジェクト説明の UI シグナル（キーワード、フレームワーク参照）を検出しなければならない
• REQ-UI-DETECT-02: システムは該当する場合に ROADMAP.md のフェーズに ui_hint をアノテーションしなければならない
• REQ-UI-DETECT-03: システムは UI 重視フェーズのネクストステップに /gsd-ui-phase を提案しなければならない
• REQ-UI-DETECT-04: システムは /gsd-ui-phase を必須にしてはならない

プロセス:

1. 検出 — プロジェクト説明と技術スタックの UI シグナル（キーワード、フレームワーク参照）をスキャン
2. アノテーション — ROADMAP.md の該当フェーズに ui_hint マーカーを追加
3. 表面化 — UI 重視フェーズのネクストステップに /gsd-ui-phase の推奨を含める

---

55. マルチランタイムインストーラー選択

対象: npx get-shit-done-cc

目的: 1回のインタラクティブなインストールセッションで複数のランタイムを選択します。

要件:

• REQ-MULTI-RT-01: インタラクティブプロンプトはマルチセレクトをサポートしなければならない（例: Claude Code + Gemini）
• REQ-MULTI-RT-02: CLI フラグは非インタラクティブインストールで引き続き動作しなければならない

プロセス:

1. 検出 — システム上で利用可能な AI CLI ランタイムを特定
2. プロンプト — ランタイム選択のためのマルチセレクトインターフェースを提示
3. インストール — 1回のセッションで選択されたすべてのランタイムに対して GSD を設定

---

v1.29 の機能

56. Windsurf ランタイムサポート

対象: npx get-shit-done-cc

目的: Windsurf AI IDE のサポートを追加します。

要件:

• REQ-WINDSURF-01: インストーラーは --windsurf フラグによる Windsurf インストールをサポートしなければならない
• REQ-WINDSURF-02: Windsurf ルール形式に対応したプロンプトファイルを生成しなければならない

プロセス:

1. 検出 — Windsurf のインストール状態を確認
2. 変換 — GSD プロンプトを Windsurf ルール形式に変換
3. インストール — Windsurf 設定ディレクトリに GSD を設定

---

57. 国際化ドキュメント

対象: docs/ ディレクトリ

目的: GSD ドキュメントをポルトガル語、韓国語、日本語で提供します。

要件:

• REQ-I18N-01: ドキュメントはポルトガル語（pt）、韓国語（ko）、日本語（ja）で提供されなければならない
• REQ-I18N-02: 翻訳は英語のソースドキュメントと同期を維持しなければならない

プロセス:

1. 翻訳 — コアドキュメントを対象言語に変換
2. 公開 — 翻訳されたドキュメントを英語版と並んでアクセス可能にする

---

v1.30 の機能

58. GSD SDK

コマンド: プログラマティック API（ヘッドレス）

目的: CLI セッションなしでプログラムから GSD ワークフローを実行するためのヘッドレス TypeScript SDK。

要件:

• REQ-SDK-01: SDK は GSD ワークフロー操作を TypeScript 関数として公開しなければならない
• REQ-SDK-02: SDK はインタラクティブプロンプトなしのヘッドレス実行をサポートしなければならない
• REQ-SDK-03: SDK は CLI 駆動ワークフローと同一のアーティファクトを生成しなければならない

プロセス:

1. インポート — GSD SDK を TypeScript/JavaScript プロジェクトにインポート
2. 設定 — プロジェクトパスとワークフローオプションをプログラムから設定
3. 実行 — API コールで GSD フェーズ（discuss、plan、execute）を実行

---

v1.31 の機能

59. スキーマドリフト検出

コマンド: /gsd-execute-phase 実行時に自動

目的: ORM スキーマファイルが対応するマイグレーションまたは push コマンドなしに変更された場合を検出し、誤検知の検証を防止します。

要件:

• REQ-SCHEMA-01: システムは ORM スキーマファイル（Prisma、Drizzle、Payload、Sanity、Mongoose）の変更を検出しなければならない
• REQ-SCHEMA-02: スキーマ変更が検出された場合、対応するマイグレーション/push コマンドの存在を確認しなければならない
• REQ-SCHEMA-03: 二層防御を実装しなければならない: 計画時注入と実行時ゲート
• REQ-SCHEMA-04: 検出をオーバーライドする GSD_SKIP_SCHEMA_CHECK 環境変数をサポートしなければならない
• REQ-SCHEMA-05: マイグレーションなしのスキーマ変更時に誤検知の検証を防止しなければならない

プロセス:

1. 検出 — 計画実行中の ORM スキーマファイルの変更を監視
2. 確認 — 計画に対応するマイグレーション/push コマンドが含まれていることを確認
3. ゲート — マイグレーションなしのスキーマドリフトが検出された場合、実行をブロック（実行時ゲート）
4. 注入 — 計画生成中にマイグレーションリマインダーを追加（計画時注入）

設定: GSD_SKIP_SCHEMA_CHECK 環境変数で検出をバイパス。

---

60. セキュリティエンフォースメント

コマンド: /gsd-secure-phase <N>

目的: フェーズ実装に対する脅威モデルアンカードのセキュリティ検証。

要件:

• REQ-SEC-01: システムは脅威モデルアンカードの検証（ブラインドスキャンではない）を実行しなければならない
• REQ-SEC-02: 設定可能な OWASP ASVS 検証レベル（1-3）をサポートしなければならない
• REQ-SEC-03: 設定可能な重大度しきい値に基づいてフェーズ進行をブロックしなければならない
• REQ-SEC-04: 分析のために gsd-security-auditor エージェントを起動しなければならない

生成物:

成果物	説明
セキュリティ監査レポート	重大度分類付きの脅威モデルアンカードの発見事項

プロセス:

1. モデル — フェーズ実装コンテキストから脅威モデルを構築
2. 監査 — gsd-security-auditor を起動して脅威モデルに対して検証
3. ゲート — 発見事項が security_block_on 重大度以上の場合、フェーズ進行をブロック

設定:

設定	型	デフォルト	説明
security_enforcement	boolean	true	脅威モデルセキュリティ検証を有効化
security_asvs_level	number (1-3)	1	OWASP ASVS 検証レベル
security_block_on	string	"high"	フェーズ進行をブロックする最小重大度

---

61. ドキュメント生成

コマンド: /gsd-docs-update

目的: 正確性チェック付きのプロジェクトドキュメントを生成・検証します。

要件:

• REQ-DOCS-01: システムはドキュメント生成のために gsd-doc-writer エージェントを起動しなければならない
• REQ-DOCS-02: システムは正確性チェックのために gsd-doc-verifier エージェントを起動しなければならない
• REQ-DOCS-03: システムは生成されたドキュメントを実際の実装に対して検証しなければならない

生成物:

成果物	説明
更新されたプロジェクトドキュメント	生成および検証されたドキュメントファイル

プロセス:

1. 生成 — gsd-doc-writer を起動して実装からドキュメントを作成・更新
2. 検証 — gsd-doc-verifier を起動してコードベースに対するドキュメント正確性をチェック
3. 出力 — 正確性アノテーション付きの検証済みドキュメントを生成

---

62. ディスカスチェーンモード

フラグ: /gsd-discuss-phase <N> --chain

目的: 手動のコマンド連続実行を削減するため、discuss、plan、execute フェーズを1つのフローで自動チェーンします。

要件:

• REQ-CHAIN-01: --chain フラグが提供された場合、システムは discuss → plan → execute を自動チェーンしなければならない
• REQ-CHAIN-02: チェーンされたフェーズ間のすべてのゲート設定を尊重しなければならない
• REQ-CHAIN-03: いずれかのフェーズが失敗した場合、チェーンを停止しなければならない

プロセス:

1. ディスカス — コンテキスト収集のためにディスカスフェーズを実行
2. プラン — 収集されたコンテキストでプランフェーズを自動的に呼び出し
3. エクセキュート — 生成されたプランでエクセキュートフェーズを自動的に呼び出し

---

63. 単一フェーズ自律モード

フラグ: /gsd-autonomous --only N

目的: 全残りフェーズではなく、1つのフェーズだけを自律的に実行します。

要件:

• REQ-ONLY-01: --only N が提供された場合、システムは指定されたフェーズ番号のみを実行しなければならない
• REQ-ONLY-02: フル自律モードと同じ discuss → plan → execute フローに従わなければならない
• REQ-ONLY-03: 指定されたフェーズが完了した後に停止しなければならない

プロセス:

1. 選択 — --only N 引数からターゲットフェーズを特定
2. 実行 — そのフェーズに対してフル自律フロー（discuss → plan → execute）を実行
3. 停止 — 次のフェーズに進まず、フェーズ完了後に停止

---

64. スコープ削減検出

対象: /gsd-plan-phase

目的: 三層防御により、計画生成中のサイレントな要件削除を防止します。

要件:

• REQ-SCOPE-01: プランナーは明示的な正当化なしにスコープを削減することを禁止されなければならない
• REQ-SCOPE-02: プランチェッカーは要件ディメンションカバレッジを検証しなければならない
• REQ-SCOPE-03: オーケストレーターは削除された要件を回復して再注入しなければならない
• REQ-SCOPE-04: 三層防御を実装しなければならない: プランナー禁止、チェッカーディメンション、オーケストレーター回復

プロセス:

1. 禁止 — プランナー指示でスコープ削減を明示的に禁止
2. チェック — プランチェッカーがすべてのフェーズ要件が計画でカバーされていることを確認
3. 回復 — オーケストレーターが削除された要件を検出してプランニングループに再注入

---

65. クレーム出所タグ付け

対象: /gsd-plan-phase --research-phase

目的: リサーチのクレームにソースエビデンスのタグを付け、仮定を別途記録します。

要件:

• REQ-PROVENANCE-01: リサーチャーはクレームにソースエビデンス参照をマークしなければならない
• REQ-PROVENANCE-02: 仮定はソース付きクレームとは別に記録されなければならない
• REQ-PROVENANCE-03: システムはエビデンス付き事実と推論された仮定を区別しなければならない

プロセス:

1. リサーチ — リサーチャーがコードベースとドメインソースから情報を収集
2. タグ — 各クレームにソース（ファイルパス、ドキュメント、API レスポンス）をアノテーション
3. 分離 — 直接的なエビデンスのない仮定を別セクションに記録

---

66. Worktree トグル

設定: workflow.use_worktrees: false

目的: 順次実行を好むユーザーのために git worktree 分離を無効化します。

要件:

• REQ-WORKTREE-01: システムは分離戦略を決定する際に workflow.use_worktrees 設定を尊重しなければならない
• REQ-WORKTREE-02: 後方互換性のためにデフォルトは true（worktree 有効）でなければならない
• REQ-WORKTREE-03: worktree が無効な場合、順次実行にフォールバックしなければならない

設定:

設定	型	デフォルト	説明
workflow.use_worktrees	boolean	true	false の場合、git worktree 分離を無効化

---

67. プロジェクトコードプレフィックス

設定: project_code: "ABC"

目的: マルチプロジェクトの曖昧さ解消のためにフェーズディレクトリ名にプロジェクトコードをプレフィックスします。

要件:

• REQ-PREFIX-01: 設定された場合、システムはフェーズディレクトリにプロジェクトコードをプレフィックスしなければならない（例: ABC-01-setup/）
• REQ-PREFIX-02: project_code が設定されていない場合、標準命名を使用しなければならない
• REQ-PREFIX-03: すべてのフェーズ操作で一貫してプレフィックスを適用しなければならない

設定:

設定	型	デフォルト	説明
project_code	string	(なし)	フェーズディレクトリ名のプレフィックス

---

68. Claude Code スキルマイグレーション

対象: npx get-shit-done-cc

目的: GSD コマンドを Claude Code 2.1.88+ のスキル形式に後方互換性を維持してマイグレーションします。

要件:

• REQ-SKILLS-01: インストーラーは Claude Code 2.1.88+ 向けに skills/gsd-*/SKILL.md を書き込まなければならない
• REQ-SKILLS-02: インストーラーはレガシー commands/gsd/ ディレクトリを自動クリーンしなければならない
• REQ-SKILLS-03: Gemini パスを通じて古い Claude Code バージョンとの後方互換性を維持しなければならない

プロセス:

1. 検出 — Claude Code のバージョンをチェックしてスキルサポートを判定
2. マイグレーション — 各 GSD コマンドに対して skills/gsd-*/SKILL.md ファイルを書き込み
3. クリーン — スキルがインストールされた場合、レガシー commands/gsd/ ディレクトリを削除
4. フォールバック — 古い Claude Code バージョンのために Gemini パス互換性を維持

---

v1.32 の機能

69. STATE.md 整合性ゲート

コマンド: state validate、state sync [--verify]、state planned-phase --phase N --plans N

目的: STATE.md と実際のファイルシステム間のドリフトを検出・修復し、古い状態からのカスケードエラーを防止します。

要件:

• REQ-STATE-01: state validate は STATE.md フィールドとファイルシステムの実態間のドリフトを検出しなければならない
• REQ-STATE-02: state sync はディスク上の実際のプロジェクト状態から STATE.md を再構築しなければならない
• REQ-STATE-03: state sync --verify は書き込みなしで提案される変更を表示するドライランを実行しなければならない
• REQ-STATE-04: state planned-phase はプランフェーズ完了後の状態遷移を記録しなければならない（Planned/Ready to execute）

生成物:

成果物	説明
更新された STATE.md	ファイルシステムの実態を反映した修正済み状態

プロセス:

1. 検証 — STATE.md フィールドをファイルシステム（フェーズディレクトリ、計画ファイル、サマリー）と比較
2. 同期 — ドリフトが検出された場合、ディスクから STATE.md を再構築
3. 遷移 — エクセキュートフェーズの準備状態として計画数付きのポストプランニング状態を記録

---

70. 自律モード --to N フラグ

フラグ: /gsd-autonomous --to N

目的: 特定のフェーズ完了後に自律実行を停止し、部分的な自律実行を可能にします。

要件:

• REQ-TO-01: システムは指定されたフェーズ番号の完了後に実行を停止しなければならない
• REQ-TO-02: N までの各フェーズに対して同じ discuss → plan → execute フローに従わなければならない
• REQ-TO-03: --to N は境界付き自律範囲のために --from N と組み合わせ可能でなければならない

プロセス:

1. 境界設定 — --to N 引数から上限フェーズを設定
2. 実行 — フェーズ N まで（含む）の各フェーズに対して自律フローを実行
3. 停止 — フェーズ N の完了後に停止

---

71. リサーチゲート

対象: /gsd-plan-phase

目的: RESEARCH.md に未解決のオープンクエスチョンがある場合にプランニングをブロックし、不完全な情報に基づく計画を防止します。

要件:

• REQ-RESGATE-01: プランニング開始前に RESEARCH.md の未解決オープンクエスチョンをスキャンしなければならない
• REQ-RESGATE-02: オープンクエスチョンが存在する場合、プランフェーズのエントリをブロックしなければならない
• REQ-RESGATE-03: 具体的な未解決クエスチョンをユーザーに表示しなければならない

プロセス:

1. スキャン — RESEARCH.md のオープンクエスチョンセクションで未解決項目をチェック
2. ゲート — 未解決クエスチョンが見つかった場合、プランニングをブロック
3. 表示 — 解決が必要な具体的なオープンクエスチョンを表示

---

72. ベリファイヤーマイルストーンスコープフィルタリング

対象: /gsd-execute-phase（ベリファイヤーステップ）

目的: 真のギャップと後続フェーズに延期された項目を区別し、検証の偽陰性を削減します。

要件:

• REQ-VSCOPE-01: ベリファイヤーはギャップが後続マイルストーンフェーズで対処されるかチェックしなければならない
• REQ-VSCOPE-02: 後続フェーズで対処されるギャップは「ギャップ」ではなく「延期」とマークされなければならない
• REQ-VSCOPE-03: 真のギャップ（将来のフェーズでもカバーされない）のみが失敗として報告されなければならない

プロセス:

1. 検証 — 標準的なゴール逆行検証を実行
2. フィルター — 検出されたギャップを後続マイルストーンフェーズとクロスリファレンス
3. 分類 — 延期された項目を真のギャップとは別にマーク

---

73. Read-Before-Edit ガードフック

対象: フック（PreToolUse）

目的: ファイルが編集前に読み込まれることを確認し、非 Claude ランタイムでの無限リトライループを防止します。

要件:

• REQ-RBE-01: フックはセッションで以前に読み込まれていないファイルを対象とする Edit/Write ツールコールを検出しなければならない
• REQ-RBE-02: フックはまずファイルを読み込むよう勧告しなければならない（勧告的、非ブロッキング）
• REQ-RBE-03: フックは組み込みの read-before-edit 強制のないランタイムで一般的な無限リトライループを防止しなければならない

---

74. コンテキスト削減

対象: GSD SDK プロンプトアセンブリ

目的: Markdown 切り詰めとキャッシュフレンドリーなプロンプト順序により、コンテキストプロンプトサイズを削減します。

要件:

• REQ-CTXRED-01: システムはコンテキスト予算内に収まるよう、大きすぎる Markdown アーティファクトを切り詰めなければならない
• REQ-CTXRED-02: キャッシュフレンドリーなアセンブリのためにプロンプトを順序付けなければならない（安定したプレフィックスを先頭に）
• REQ-CTXRED-03: 削減は必須情報（見出し、要件、タスク構造）を保持しなければならない

プロセス:

1. 計測 — ワークフローの総プロンプトサイズを計算
2. 切り詰め — 大きすぎるアーティファクトに Markdown 対応の切り詰めを適用
3. 順序付け — KV キャッシュ再利用の最適化のためにプロンプトセクションを配置

---

75. ディスカスフェーズ --power フラグ

フラグ: /gsd-discuss-phase --power

目的: ディスカスフェーズのファイルベースの一括質問回答で、準備済み回答ファイルからのバッチ入力を可能にします。

要件:

• REQ-POWER-01: システムはディスカッション質問への事前記述済み回答を含むファイルを受け付けなければならない
• REQ-POWER-02: システムは回答を対応するグレーエリア質問にマッピングしなければならない
• REQ-POWER-03: システムはインタラクティブなディスカスフェーズと同一の CONTEXT.md を生成しなければならない

---

76. デバッグ --diagnose フラグ

フラグ: /gsd-debug --diagnose

目的: 修正を試みず調査のみを行う診断専用モード。

要件:

• REQ-DIAG-01: システムは完全なデバッグ調査（仮説、エビデンス、根本原因）を実行しなければならない
• REQ-DIAG-02: システムはコード変更を一切行ってはならない
• REQ-DIAG-03: システムは発見事項と推奨修正を含む診断レポートを生成しなければならない

---

77. フェーズ依存関係分析

コマンド: /gsd-manager --analyze-deps

目的: フェーズ依存関係を検出し、/gsd-manager 実行前に ROADMAP.md への Depends on エントリを提案します。

要件:

• REQ-DEP-01: システムはフェーズ間のファイルオーバーラップを検出しなければならない
• REQ-DEP-02: システムはセマンティック依存関係（API/スキーマのプロデューサーとコンシューマー）を検出しなければならない
• REQ-DEP-03: システムはデータフロー依存関係（出力プロデューサーとリーダー）を検出しなければならない
• REQ-DEP-04: システムは依存関係エントリを提案し、書き込み前にユーザー確認を要求しなければならない

生成物: 依存関係提案テーブル；オプションで ROADMAP.md の Depends on フィールドを更新

---

78. アンチパターン重大度レベル

対象: /gsd-resume-work

目的: 重大度ベースのアンチパターン強制によるリジューム時の必須理解チェック。

要件:

• REQ-ANTI-01: システムはアンチパターンを重大度レベルで分類しなければならない
• REQ-ANTI-02: システムはセッションリジューム時に必須の理解チェックを強制しなければならない
• REQ-ANTI-03: より高い重大度のアンチパターンは承認されるまでワークフロー進行をブロックしなければならない

---

79. メソドロジーアーティファクトタイプ

対象: プランニングアーティファクト

目的: メソドロジードキュメントの消費メカニズムを定義し、エージェントによって正しく消費されることを確保します。

要件:

• REQ-METHOD-01: システムはメソドロジーを独自のアーティファクトタイプとしてサポートしなければならない
• REQ-METHOD-02: メソドロジーアーティファクトはエージェント向けの定義された消費メカニズムを持たなければならない

---

80. プランナー到達可能性チェック

対象: /gsd-plan-phase

目的: 実行にコミットする前にプランステップが達成可能であることを検証します。

要件:

• REQ-REACH-01: プランナーは各プランステップが到達可能なファイルと API を参照していることを検証しなければならない
• REQ-REACH-02: 到達不可能なステップは実行中ではなくプランニング中にフラグ付けされなければならない

---

81. Playwright-MCP UI 検証

対象: /gsd-verify-work（オプション）

目的: ベリファイフェーズ中の Playwright-MCP を使用した自動ビジュアル検証。

要件:

• REQ-PLAY-01: システムはベリファイフェーズ中のオプションの Playwright-MCP ビジュアル検証をサポートしなければならない
• REQ-PLAY-02: ビジュアル検証はオプトインであり、必須であってはならない
• REQ-PLAY-03: システムは UI-SPEC.md の期待値に対してビジュアル状態をキャプチャ・比較しなければならない

---

82. Pause-Work 拡張

対象: /gsd-pause-work

目的: よりリッチなハンドオフデータで非フェーズコンテキストをサポートし、pause-work の適用範囲を拡大します。

要件:

• REQ-PAUSE-01: システムは非フェーズコンテキスト（クイックタスク、デバッグセッション、スレッド）でのポーズをサポートしなければならない
• REQ-PAUSE-02: ハンドオフデータは現在の作業タイプに適切なよりリッチなコンテキストを含まなければならない

---

83. レスポンス言語設定

設定: response_language

目的: 非英語ユーザーのためのクロスフェーズ言語一貫性。

要件:

• REQ-LANG-01: システムはすべてのフェーズとエージェントで response_language 設定を尊重しなければならない
• REQ-LANG-02: 設定はすべてのスポーンされたエージェントに伝播し、一貫した言語出力を確保しなければならない

設定:

設定	型	デフォルト	説明
response_language	string	(なし)	エージェントレスポンスの言語コード（例: "pt"、"ko"、"ja"）

---

84. 手動アップデート手順

対象: docs/manual-update.md

目的: npx が利用不可または npm パブリッシュに障害が発生している環境のための手動アップデートパスを文書化します。

要件:

• REQ-MANUAL-01: ドキュメントはステップバイステップの手動アップデート手順を記述しなければならない
• REQ-MANUAL-02: 手順は npm アクセスなしで機能しなければならない

---

85. 新規ランタイムサポート (Trae, Cline, Augment Code)

対象: npx get-shit-done-cc

目的: Trae IDE、Cline、Augment Code ランタイムへの GSD インストールを拡張します。

要件:

• REQ-TRAE-01: インストーラーは Trae IDE インストールのための --trae フラグをサポートしなければならない
• REQ-CLINE-01: インストーラーは .clinerules 設定を通じて Cline をサポートしなければならない
• REQ-AUGMENT-01: インストーラーはスキル変換と設定管理で Augment Code をサポートしなければならない