# GSD 機能リファレンス > 全機能と要件の完全なドキュメントです。アーキテクチャの詳細については[アーキテクチャ](ARCHITECTURE.md)を、コマンド構文については[コマンドリファレンス](COMMANDS.md)をご覧ください。 --- ## 目次 - [コア機能](#コア機能) - [プロジェクト初期化](#1-プロジェクト初期化) - [フェーズディスカッション](#2-フェーズディスカッション) - [UI デザインコントラクト](#3-ui-デザインコントラクト) - [フェーズプランニング](#4-フェーズプランニング) - [フェーズ実行](#5-フェーズ実行) - [作業検証](#6-作業検証) - [UI レビュー](#7-ui-レビュー) - [マイルストーン管理](#8-マイルストーン管理) - [プランニング機能](#プランニング機能) - [フェーズ管理](#9-フェーズ管理) - [Quick モード](#10-quick-モード) - [自律モード](#11-自律モード) - [フリーフォームルーティング](#12-フリーフォームルーティング) - [ノートキャプチャ](#13-ノートキャプチャ) - [自動進行（Next）](#14-自動進行next) - [品質保証機能](#品質保証機能) - [Nyquist バリデーション](#15-nyquist-バリデーション) - [プランチェック](#16-プランチェック) - [実行後検証](#17-実行後検証) - [ノードリペア](#18-ノードリペア) - [ヘルスバリデーション](#19-ヘルスバリデーション) - [クロスフェーズ回帰ゲート](#20-クロスフェーズ回帰ゲート) - [要件カバレッジゲート](#21-要件カバレッジゲート) - [コンテキストエンジニアリング機能](#コンテキストエンジニアリング機能) - [コンテキストウィンドウ監視](#22-コンテキストウィンドウ監視) - [セッション管理](#23-セッション管理) - [セッションレポート](#24-セッションレポート) - [マルチエージェントオーケストレーション](#25-マルチエージェントオーケストレーション) - [モデルプロファイル](#26-モデルプロファイル) - [ブラウンフィールド機能](#ブラウンフィールド機能) - [コードベースマッピング](#27-コードベースマッピング) - [ユーティリティ機能](#ユーティリティ機能) - [デバッグシステム](#28-デバッグシステム) - [Todo 管理](#29-todo-管理) - [統計ダッシュボード](#30-統計ダッシュボード) - [アップデートシステム](#31-アップデートシステム) - [設定管理](#32-設定管理) - [テスト生成](#33-テスト生成) - [インフラストラクチャ機能](#インフラストラクチャ機能) - [Git 連携](#34-git-連携) - [CLI ツール](#35-cli-ツール) - [マルチランタイムサポート](#36-マルチランタイムサポート) - [フックシステム](#37-フックシステム) - [開発者プロファイリング](#38-開発者プロファイリング) - [実行ハードニング](#39-実行ハードニング) - [検証デット追跡](#40-検証デット追跡) - [v1.27 の機能](#v127-の機能) - [Fast モード](#41-fast-モード) - [クロス AI ピアレビュー](#42-クロス-ai-ピアレビュー) - [バックログパーキングロット](#43-バックログパーキングロット) - [永続コンテキストスレッド](#44-永続コンテキストスレッド) - [PR ブランチフィルタリング](#45-pr-ブランチフィルタリング) - [セキュリティハードニング](#46-セキュリティハードニング) - [マルチリポワークスペースサポート](#47-マルチリポワークスペースサポート) - [ディスカッション監査証跡](#48-ディスカッション監査証跡) - [v1.28 の機能](#v128-の機能) - [フォレンジクス](#49-フォレンジクス) - [マイルストーンサマリー](#50-マイルストーンサマリー) - [ワークストリームネームスペーシング](#51-ワークストリームネームスペーシング) - [マネージャーダッシュボード](#52-マネージャーダッシュボード) - [Assumptions ディスカッションモード](#53-assumptions-ディスカッションモード) - [UI フェーズ自動検出](#54-ui-フェーズ自動検出) - [マルチランタイムインストーラー選択](#55-マルチランタイムインストーラー選択) --- ## コア機能 ### 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 で構造化しなければならない。`` 要素には `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）:** ```xml Create login endpoint src/app/api/auth/login/route.ts Use jose for JWT. Validate credentials against users table. Return httpOnly cookie on success. curl -X POST localhost:3000/api/auth/login returns 200 + Set-Cookie Valid credentials return cookie, invalid return 401 ``` **プランチェッカー検証（8つの次元）:** 1. 要件カバレッジ — プランがすべてのフェーズ要件に対応しているか 2. タスクのアトミック性 — 各タスクが独立してコミット可能か 3. 依存関係の順序 — タスクが正しい順序で並んでいるか 4. ファイルスコープ — プラン間で過度なファイルの重複がないか 5. 検証コマンド — 各タスクにテスト可能な完了基準があるか 6. コンテキストフィット — タスクが1つのコンテキストウィンドウに収まるか 7. ギャップ検出 — 実装ステップに欠落がないか 8. Nyquist 準拠 — タスクに自動化された検証コマンドがあるか（有効時） --- ### 5. フェーズ実行 **コマンド:** `/gsd:execute-phase ` **目的:** ウェーブベースの並列化を使用して、フェーズ内のすべてのプランを実行します。各エグゼキューターにはフレッシュなコンテキストウィンドウが割り当てられます。 **要件:** - 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: 新しいマイルストーンは既存のワークフロー設定をリセットしてはならない **ギャップクローズ:** `/gsd:plan-milestone-gaps` は監査で特定されたギャップを埋めるためのフェーズを作成します。 --- ## プランニング機能 ### 9. フェーズ管理 **コマンド:** `/gsd:add-phase`、`/gsd:insert-phase [N]`、`/gsd:remove-phase [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:do` **目的:** 自由形式のテキストを分析し、適切な GSD コマンドにルーティングします。 **要件:** - REQ-DO-01: システムは自然言語入力からユーザーの意図を解析しなければならない - REQ-DO-02: システムは意図を最も適切な GSD コマンドにマッピングしなければならない - REQ-DO-03: システムは実行前にルーティング結果をユーザーに確認しなければならない - REQ-DO-04: システムはプロジェクト既存 vs プロジェクト未作成のコンテキストを区別して処理しなければならない --- ### 13. ノートキャプチャ **コマンド:** `/gsd:note` **目的:** ワークフローを中断することなくアイデアを記録する、摩擦ゼロのメモ機能。タイムスタンプ付きメモの追加、全メモの一覧表示、または構造化された 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: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:session-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:set-profile ` **目的:** 各エージェントが使用する 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:add-todo [desc]`、`/gsd:check-todos` **目的:** セッション中にアイデアやタスクをキャプチャし、後で作業できるようにします。 **要件:** - REQ-TODO-01: システムは現在の会話コンテキストから Todo をキャプチャしなければならない - REQ-TODO-02: Todo は `.planning/todos/pending/` に保存されなければならない - REQ-TODO-03: 完了した Todo は `.planning/todos/done/` に移動されなければならない - 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:reapply-patches` は更新後にローカルの変更を復元しなければならない --- ### 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. マルチランタイムサポート **目的:** 6つの異なる AI コーディングエージェントランタイムで GSD を実行します。 **要件:** - REQ-RUNTIME-01: システムは Claude Code、OpenCode、Gemini CLI、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 | Codex | Copilot | Antigravity | |------|------------|----------|--------|-------|---------|-------------| | コマンド | スラッシュコマンド | スラッシュコマンド | スラッシュコマンド | スキル（TOML） | スラッシュコマンド | スキル | | エージェント形式 | Claude ネイティブ | `mode: subagent` | Claude ネイティブ | スキル | ツールマッピング | スキル | | フックイベント | `PostToolUse` | N/A | `AfterTool` | N/A | N/A | N/A | | 設定 | `settings.json` | `opencode.json(c)` | `settings.json` | 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` — 証拠引用付きの完全な行動プロファイル - `/gsd:dev-preferences` コマンド — 任意のセッションで好みを読み込み - `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] [--all]` **目的:** 外部の AI CLI（Gemini、Claude、Codex）を呼び出して、フェーズプランを独立してレビューします。レビュアーごとのフィードバックを含む構造化された 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:add-backlog `、`/gsd:review-backlog`、`/gsd:plant-seed ` **目的:** アクティブなプランニングの準備ができていないアイデアをキャプチャします。バックログ項目は 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 を設定