refactor: hard-fork GSD -> MSD (Make Software Done)
Mechanical rename produced by scripts/msd-rename.cjs: gsd/Gsd/GSD -> msd/Msd/MSD across contents and paths, upstream package/repo coordinates -> @golem15/msd-core and golem15com/msd-core. Deep links into upstream history, sibling upstream packages, the GSD-2 import feature, CHANGELOG.md and .changeset/ are kept as-is. Hand edits on top: MSD block-letter banner and logos, LICENSE copyright line, package/plugin identity, regenerated lockfile, install-tree fixtures, derived registries and benchmark baseline; migration checksum baseline re-locked (MSD keeps its own install state, so no install had applied the old sums); sort-order and regex-escaped expectations in tests adjusted.
This commit is contained in:
Jakub Zych
@@ -1,4 +1,4 @@
|
||||
# GSD エージェントリファレンス
|
||||
# MSD エージェントリファレンス
|
||||
|
||||
> 全18種の専門エージェント（v1.32 現在） — 役割、ツール、スポーンパターン、相互関係。アーキテクチャの詳細は[アーキテクチャ](ARCHITECTURE.md)を参照してください。
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
## 概要
|
||||
|
||||
GSD はマルチエージェントアーキテクチャを採用しており、軽量なオーケストレーター（ワークフローファイル）が新しいコンテキストウィンドウを持つ専門エージェントをスポーンします。各エージェントは特定の役割に特化し、限定的なツールアクセス権を持ち、特定の成果物を生成します。
|
||||
MSD はマルチエージェントアーキテクチャを採用しており、軽量なオーケストレーター（ワークフローファイル）が新しいコンテキストウィンドウを持つ専門エージェントをスポーンします。各エージェントは特定の役割に特化し、限定的なツールアクセス権を持ち、特定の成果物を生成します。
|
||||
|
||||
### エージェントカテゴリ
|
||||
|
||||
@@ -28,13 +28,13 @@ GSD はマルチエージェントアーキテクチャを採用しており、
|
||||
|
||||
## エージェント詳細
|
||||
|
||||
### gsd-project-researcher
|
||||
### msd-project-researcher
|
||||
|
||||
**役割:** ロードマップ作成前にドメインエコシステムを調査する。
|
||||
|
||||
| プロパティ | 値 |
|
||||
|------------|-----|
|
||||
| **スポーン元** | `/gsd-new-project`, `/gsd-new-milestone` |
|
||||
| **スポーン元** | `/msd-new-project`, `/msd-new-milestone` |
|
||||
| **並列数** | 4インスタンス（stack, features, architecture, pitfalls） |
|
||||
| **ツール** | Read, Write, Bash, Grep, Glob, WebSearch, WebFetch, mcp (context7) |
|
||||
| **モデル (balanced)** | Sonnet |
|
||||
@@ -47,13 +47,13 @@ GSD はマルチエージェントアーキテクチャを採用しており、
|
||||
|
||||
---
|
||||
|
||||
### gsd-phase-researcher
|
||||
### msd-phase-researcher
|
||||
|
||||
**役割:** 計画策定前に、特定フェーズの実装方法を調査する。
|
||||
|
||||
| プロパティ | 値 |
|
||||
|------------|-----|
|
||||
| **スポーン元** | `/gsd-plan-phase` |
|
||||
| **スポーン元** | `/msd-plan-phase` |
|
||||
| **並列数** | 4インスタンス（project-researcher と同じフォーカスエリア） |
|
||||
| **ツール** | Read, Write, Bash, Grep, Glob, WebSearch, WebFetch, mcp (context7) |
|
||||
| **モデル (balanced)** | Sonnet |
|
||||
@@ -66,13 +66,13 @@ GSD はマルチエージェントアーキテクチャを採用しており、
|
||||
|
||||
---
|
||||
|
||||
### gsd-ui-researcher
|
||||
### msd-ui-researcher
|
||||
|
||||
**役割:** フロントエンドフェーズ向けのUIデザインコントラクトを作成する。
|
||||
|
||||
| プロパティ | 値 |
|
||||
|------------|-----|
|
||||
| **スポーン元** | `/gsd-ui-phase` |
|
||||
| **スポーン元** | `/msd-ui-phase` |
|
||||
| **並列数** | 単一インスタンス |
|
||||
| **ツール** | Read, Write, Bash, Grep, Glob, WebSearch, WebFetch, mcp (context7) |
|
||||
| **モデル (balanced)** | Sonnet |
|
||||
@@ -87,7 +87,7 @@ GSD はマルチエージェントアーキテクチャを採用しており、
|
||||
|
||||
---
|
||||
|
||||
### gsd-assumptions-analyzer
|
||||
### msd-assumptions-analyzer
|
||||
|
||||
**役割:** フェーズに対してコードベースを深く分析し、エビデンス・信頼度・誤った場合の影響を含む構造化された前提条件を返す。
|
||||
|
||||
@@ -110,7 +110,7 @@ GSD はマルチエージェントアーキテクチャを採用しており、
|
||||
|
||||
---
|
||||
|
||||
### gsd-advisor-researcher
|
||||
### msd-advisor-researcher
|
||||
|
||||
**役割:** discuss-phase のアドバイザーモードにおいて、単一のグレーエリアの決定事項を調査し、構造化された比較表を返す。
|
||||
|
||||
@@ -132,13 +132,13 @@ GSD はマルチエージェントアーキテクチャを採用しており、
|
||||
|
||||
---
|
||||
|
||||
### gsd-research-synthesizer
|
||||
### msd-research-synthesizer
|
||||
|
||||
**役割:** 並列リサーチャーの出力を統合サマリーにまとめる。
|
||||
|
||||
| プロパティ | 値 |
|
||||
|------------|-----|
|
||||
| **スポーン元** | `/gsd-new-project`（4つのリサーチャー完了後） |
|
||||
| **スポーン元** | `/msd-new-project`（4つのリサーチャー完了後） |
|
||||
| **並列数** | 単一インスタンス（リサーチャー後に順次実行） |
|
||||
| **ツール** | Read, Write, Bash |
|
||||
| **モデル (balanced)** | Sonnet |
|
||||
@@ -147,13 +147,13 @@ GSD はマルチエージェントアーキテクチャを採用しており、
|
||||
|
||||
---
|
||||
|
||||
### gsd-planner
|
||||
### msd-planner
|
||||
|
||||
**役割:** タスク分解、依存関係分析、ゴール逆算検証を含む実行可能なフェーズ計画を作成する。
|
||||
|
||||
| プロパティ | 値 |
|
||||
|------------|-----|
|
||||
| **スポーン元** | `/gsd-plan-phase`, `/gsd-quick` |
|
||||
| **スポーン元** | `/msd-plan-phase`, `/msd-quick` |
|
||||
| **並列数** | 単一インスタンス |
|
||||
| **ツール** | Read, Write, Bash, Glob, Grep, WebFetch, mcp (context7) |
|
||||
| **モデル (balanced)** | Opus |
|
||||
@@ -169,13 +169,13 @@ GSD はマルチエージェントアーキテクチャを採用しており、
|
||||
|
||||
---
|
||||
|
||||
### gsd-roadmapper
|
||||
### msd-roadmapper
|
||||
|
||||
**役割:** フェーズ分解と要件マッピングを含むプロジェクトロードマップを作成する。
|
||||
|
||||
| プロパティ | 値 |
|
||||
|------------|-----|
|
||||
| **スポーン元** | `/gsd-new-project` |
|
||||
| **スポーン元** | `/msd-new-project` |
|
||||
| **並列数** | 単一インスタンス |
|
||||
| **ツール** | Read, Write, Bash, Glob, Grep |
|
||||
| **モデル (balanced)** | Sonnet |
|
||||
@@ -190,13 +190,13 @@ GSD はマルチエージェントアーキテクチャを採用しており、
|
||||
|
||||
---
|
||||
|
||||
### gsd-executor
|
||||
### msd-executor
|
||||
|
||||
**役割:** アトミックコミット、逸脱処理、チェックポイントプロトコルを使用して GSD 計画を実行する。
|
||||
**役割:** アトミックコミット、逸脱処理、チェックポイントプロトコルを使用して MSD 計画を実行する。
|
||||
|
||||
| プロパティ | 値 |
|
||||
|------------|-----|
|
||||
| **スポーン元** | `/gsd-execute-phase`, `/gsd-quick` |
|
||||
| **スポーン元** | `/msd-execute-phase`, `/msd-quick` |
|
||||
| **並列数** | 複数（ウェーブ内は並列、ウェーブ間は順次） |
|
||||
| **ツール** | Read, Write, Edit, Bash, Grep, Glob |
|
||||
| **モデル (balanced)** | Sonnet |
|
||||
@@ -213,13 +213,13 @@ GSD はマルチエージェントアーキテクチャを採用しており、
|
||||
|
||||
---
|
||||
|
||||
### gsd-plan-checker
|
||||
### msd-plan-checker
|
||||
|
||||
**役割:** 実行前に計画がフェーズ目標を達成できるかを検証する。
|
||||
|
||||
| プロパティ | 値 |
|
||||
|------------|-----|
|
||||
| **スポーン元** | `/gsd-plan-phase`（検証ループ、最大3回の反復） |
|
||||
| **スポーン元** | `/msd-plan-phase`（検証ループ、最大3回の反復） |
|
||||
| **並列数** | 単一インスタンス（反復型） |
|
||||
| **ツール** | Read, Bash, Glob, Grep |
|
||||
| **モデル (balanced)** | Sonnet |
|
||||
@@ -238,13 +238,13 @@ GSD はマルチエージェントアーキテクチャを採用しており、
|
||||
|
||||
---
|
||||
|
||||
### gsd-integration-checker
|
||||
### msd-integration-checker
|
||||
|
||||
**役割:** フェーズ間の統合とエンドツーエンドフローを検証する。
|
||||
|
||||
| プロパティ | 値 |
|
||||
|------------|-----|
|
||||
| **スポーン元** | `/gsd-audit-milestone` |
|
||||
| **スポーン元** | `/msd-audit-milestone` |
|
||||
| **並列数** | 単一インスタンス |
|
||||
| **ツール** | Read, Bash, Grep, Glob |
|
||||
| **モデル (balanced)** | Sonnet |
|
||||
@@ -253,13 +253,13 @@ GSD はマルチエージェントアーキテクチャを採用しており、
|
||||
|
||||
---
|
||||
|
||||
### gsd-ui-checker
|
||||
### msd-ui-checker
|
||||
|
||||
**役割:** UI-SPEC.md のデザインコントラクトを品質ディメンションに対して検証する。
|
||||
|
||||
| プロパティ | 値 |
|
||||
|------------|-----|
|
||||
| **スポーン元** | `/gsd-ui-phase`（検証ループ、最大2回の反復） |
|
||||
| **スポーン元** | `/msd-ui-phase`（検証ループ、最大2回の反復） |
|
||||
| **並列数** | 単一インスタンス |
|
||||
| **ツール** | Read, Bash, Glob, Grep |
|
||||
| **モデル (balanced)** | Sonnet |
|
||||
@@ -268,13 +268,13 @@ GSD はマルチエージェントアーキテクチャを採用しており、
|
||||
|
||||
---
|
||||
|
||||
### gsd-verifier
|
||||
### msd-verifier
|
||||
|
||||
**役割:** ゴール逆算分析によりフェーズ目標の達成を検証する。
|
||||
|
||||
| プロパティ | 値 |
|
||||
|------------|-----|
|
||||
| **スポーン元** | `/gsd-execute-phase`（すべてのエグゼキューター完了後） |
|
||||
| **スポーン元** | `/msd-execute-phase`（すべてのエグゼキューター完了後） |
|
||||
| **並列数** | 単一インスタンス |
|
||||
| **ツール** | Read, Write, Bash, Grep, Glob |
|
||||
| **モデル (balanced)** | Sonnet |
|
||||
@@ -284,17 +284,17 @@ GSD はマルチエージェントアーキテクチャを採用しており、
|
||||
**主な動作:**
|
||||
- タスク完了だけでなく、フェーズ目標に対してコードベースを検証
|
||||
- 具体的なエビデンス付きの PASS/FAIL 判定
|
||||
- `/gsd-verify-work` で対処すべき問題をログに記録
|
||||
- `/msd-verify-work` で対処すべき問題をログに記録
|
||||
|
||||
---
|
||||
|
||||
### gsd-nyquist-auditor
|
||||
### msd-nyquist-auditor
|
||||
|
||||
**役割:** テストを生成して Nyquist バリデーションのギャップを埋める。
|
||||
|
||||
| プロパティ | 値 |
|
||||
|------------|-----|
|
||||
| **スポーン元** | `/gsd-validate-phase` |
|
||||
| **スポーン元** | `/msd-validate-phase` |
|
||||
| **並列数** | 単一インスタンス |
|
||||
| **ツール** | Read, Write, Edit, Bash, Grep, Glob |
|
||||
| **モデル (balanced)** | Sonnet |
|
||||
@@ -307,13 +307,13 @@ GSD はマルチエージェントアーキテクチャを採用しており、
|
||||
|
||||
---
|
||||
|
||||
### gsd-ui-auditor
|
||||
### msd-ui-auditor
|
||||
|
||||
**役割:** 実装済みフロントエンドコードの事後的な6ピラービジュアル監査を行う。
|
||||
|
||||
| プロパティ | 値 |
|
||||
|------------|-----|
|
||||
| **スポーン元** | `/gsd-ui-review` |
|
||||
| **スポーン元** | `/msd-ui-review` |
|
||||
| **並列数** | 単一インスタンス |
|
||||
| **ツール** | Read, Write, Bash, Grep, Glob |
|
||||
| **モデル (balanced)** | Sonnet |
|
||||
@@ -330,13 +330,13 @@ GSD はマルチエージェントアーキテクチャを採用しており、
|
||||
|
||||
---
|
||||
|
||||
### gsd-codebase-mapper
|
||||
### msd-codebase-mapper
|
||||
|
||||
**役割:** コードベースを探索し、構造化された分析ドキュメントを作成する。
|
||||
|
||||
| プロパティ | 値 |
|
||||
|------------|-----|
|
||||
| **スポーン元** | `/gsd-map-codebase` |
|
||||
| **スポーン元** | `/msd-map-codebase` |
|
||||
| **並列数** | 4インスタンス（tech, architecture, quality, concerns） |
|
||||
| **ツール** | Read, Bash, Grep, Glob, Write |
|
||||
| **モデル (balanced)** | Haiku |
|
||||
@@ -350,13 +350,13 @@ GSD はマルチエージェントアーキテクチャを採用しており、
|
||||
|
||||
---
|
||||
|
||||
### gsd-debugger
|
||||
### msd-debugger
|
||||
|
||||
**役割:** 永続的な状態を持つ科学的手法でバグを調査する。
|
||||
|
||||
| プロパティ | 値 |
|
||||
|------------|-----|
|
||||
| **スポーン元** | `/gsd-debug`, `/gsd-verify-work`（失敗時） |
|
||||
| **スポーン元** | `/msd-debug`, `/msd-verify-work`（失敗時） |
|
||||
| **並列数** | 単一インスタンス（インタラクティブ） |
|
||||
| **ツール** | Read, Write, Edit, Bash, Grep, Glob, WebSearch |
|
||||
| **モデル (balanced)** | Sonnet |
|
||||
@@ -375,13 +375,13 @@ GSD はマルチエージェントアーキテクチャを採用しており、
|
||||
|
||||
---
|
||||
|
||||
### gsd-user-profiler
|
||||
### msd-user-profiler
|
||||
|
||||
**役割:** 8つの行動ディメンションにわたってセッションメッセージを分析し、スコア付きの開発者プロファイルを作成する。
|
||||
|
||||
| プロパティ | 値 |
|
||||
|------------|-----|
|
||||
| **スポーン元** | `/gsd-profile-user` |
|
||||
| **スポーン元** | `/msd-profile-user` |
|
||||
| **並列数** | 単一インスタンス |
|
||||
| **ツール** | Read |
|
||||
| **モデル (balanced)** | Sonnet |
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# GSD Core アーキテクチャ
|
||||
# MSD Core アーキテクチャ
|
||||
|
||||
> コントリビューターおよび上級ユーザー向けのシステムアーキテクチャ文書です。ユーザー向けドキュメントは [機能リファレンス](FEATURES.md) または [ユーザーガイド](USER-GUIDE.md) をご覧ください。
|
||||
|
||||
@@ -21,7 +21,7 @@
|
||||
|
||||
## システム概要
|
||||
|
||||
GSD Core は、ユーザーと AI コーディングエージェント（Claude Code、Kimi CLI、OpenCode、Kilo、Codex、Copilot、Antigravity、Trae、Cline、Augment Code）の間に位置する **メタプロンプティングフレームワーク** です。以下の機能を提供します：
|
||||
MSD Core は、ユーザーと AI コーディングエージェント（Claude Code、Kimi CLI、OpenCode、Kilo、Codex、Copilot、Antigravity、Trae、Cline、Augment Code）の間に位置する **メタプロンプティングフレームワーク** です。以下の機能を提供します：
|
||||
|
||||
1. **コンテキストエンジニアリング** — タスクごとに AI が必要とするすべてを提供する構造化アーティファクト（[コンテキストエンジニアリング](explanation/context-engineering.md) 参照）
|
||||
2. **マルチエージェントオーケストレーション** — フレッシュなコンテキストウィンドウで専門化されたエージェントを生成する薄いオーケストレーター（[マルチエージェントオーケストレーション](explanation/multi-agent-orchestration.md) 参照）
|
||||
@@ -31,18 +31,18 @@ GSD Core は、ユーザーと AI コーディングエージェント（Claude
|
||||
```
|
||||
┌──────────────────────────────────────────────────────┐
|
||||
│ USER │
|
||||
│ /gsd-command [args] │
|
||||
│ /msd-command [args] │
|
||||
└─────────────────────┬────────────────────────────────┘
|
||||
│
|
||||
┌─────────────────────▼────────────────────────────────┐
|
||||
│ COMMAND LAYER │
|
||||
│ commands/gsd/*.md — Prompt-based command files │
|
||||
│ commands/msd/*.md — Prompt-based command files │
|
||||
│ (Claude Code custom commands / Codex skills) │
|
||||
└─────────────────────┬────────────────────────────────┘
|
||||
│
|
||||
┌─────────────────────▼────────────────────────────────┐
|
||||
│ WORKFLOW LAYER │
|
||||
│ gsd-core/workflows/*.md — Orchestration logic │
|
||||
│ msd-core/workflows/*.md — Orchestration logic │
|
||||
│ (Reads references, spawns agents, manages state) │
|
||||
└──────┬──────────────┬─────────────────┬──────────────┘
|
||||
│ │ │
|
||||
@@ -54,7 +54,7 @@ GSD Core は、ユーザーと AI コーディングエージェント（Claude
|
||||
│ │ │
|
||||
┌──────▼──────────────▼─────────────────▼──────────────┐
|
||||
│ CLI TOOLS LAYER │
|
||||
│ gsd-core/bin/gsd-tools.cjs │
|
||||
│ msd-core/bin/msd-tools.cjs │
|
||||
│ (State, config, phase, roadmap, verify, templates) │
|
||||
└──────────────────────┬───────────────────────────────┘
|
||||
│
|
||||
@@ -75,8 +75,8 @@ GSD Core は、ユーザーと AI コーディングエージェント（Claude
|
||||
|
||||
### 2. 軽量オーケストレーター
|
||||
|
||||
ワークフローファイル（`gsd-core/workflows/*.md`）は重い処理を行いません。以下の役割に徹します：
|
||||
- `gsd-tools.cjs init <workflow>` でコンテキストを読み込む
|
||||
ワークフローファイル（`msd-core/workflows/*.md`）は重い処理を行いません。以下の役割に徹します：
|
||||
- `msd-tools.cjs init <workflow>` でコンテキストを読み込む
|
||||
- 焦点を絞ったプロンプトで専門エージェントを起動する
|
||||
- 結果を収集し、次のステップにルーティングする
|
||||
- ステップ間で状態を更新する
|
||||
@@ -104,31 +104,31 @@ GSD Core は、ユーザーと AI コーディングエージェント（Claude
|
||||
|
||||
## コンポーネントアーキテクチャ
|
||||
|
||||
### コマンド（`commands/gsd/*.md`）
|
||||
### コマンド（`commands/msd/*.md`）
|
||||
|
||||
ユーザー向けのエントリーポイントです。各ファイルには YAML フロントマター（name、description、allowed-tools）とワークフローをブートストラップするプロンプト本文が含まれています。コマンドは以下の形式でインストールされます：
|
||||
|
||||
- **Claude Code:** カスタムスラッシュコマンド（ハイフン形式、`/gsd-command-name`）
|
||||
- **OpenCode / Kilo:** スラッシュコマンド（ハイフン形式、`/gsd-command-name`）
|
||||
- **Codex:** スキル（`$gsd-command-name`）
|
||||
- **Copilot:** スラッシュコマンド（ハイフン形式、`/gsd-command-name`）
|
||||
- **Claude Code:** カスタムスラッシュコマンド（ハイフン形式、`/msd-command-name`）
|
||||
- **OpenCode / Kilo:** スラッシュコマンド（ハイフン形式、`/msd-command-name`）
|
||||
- **Codex:** スキル（`$msd-command-name`）
|
||||
- **Copilot:** スラッシュコマンド（ハイフン形式、`/msd-command-name`）
|
||||
- **Antigravity:** スキル
|
||||
|
||||
**コマンド総数:** 信頼できる数と完全なロスターについては [`docs/INVENTORY.md`](INVENTORY.md#commands) を参照。
|
||||
|
||||
#### 2 段階の階層的ルーティング（v1.40、[#2792](https://github.com/open-gsd/gsd-core/issues/2792)）
|
||||
|
||||
eager なスキルリストのトークンコストを低く保つため、v1.40 では 6 つの名前空間 **メタスキル**（`gsd-workflow`、`gsd-project`、`gsd-quality`、`gsd-context`、`gsd-manage`、`gsd-ideate` ——`commands/gsd/ns-*.md` から取得されるが、呼び出し可能な `name:` はここに示すベア形式）を具体的なサブスキルの上にレイヤーとして導入しています。モデルは平坦な 86 スキルリスト（約 2,150 トークン）の代わりに 6 つの名前空間ルーター（約 120 トークン）を見て名前空間を選択し、名前空間ルーターの本文に埋め込まれたルーティングテーブルを通じて具体的なサブスキルにルーティングします。名前空間スキルは **付加的** です——すべての具体的なコマンドは依然として直接呼び出し可能です。
|
||||
eager なスキルリストのトークンコストを低く保つため、v1.40 では 6 つの名前空間 **メタスキル**（`msd-workflow`、`msd-project`、`msd-quality`、`msd-context`、`msd-manage`、`msd-ideate` ——`commands/msd/ns-*.md` から取得されるが、呼び出し可能な `name:` はここに示すベア形式）を具体的なサブスキルの上にレイヤーとして導入しています。モデルは平坦な 86 スキルリスト（約 2,150 トークン）の代わりに 6 つの名前空間ルーター（約 120 トークン）を見て名前空間を選択し、名前空間ルーターの本文に埋め込まれたルーティングテーブルを通じて具体的なサブスキルにルーティングします。名前空間スキルは **付加的** です——すべての具体的なコマンドは依然として直接呼び出し可能です。
|
||||
|
||||
#### MCP トークンバジェットの相互作用
|
||||
|
||||
eager なスキルリストはターンごとの 2 つの主要コストの一つです。もう一つは `.claude/settings.json` で有効化されている各 MCP サーバーが注入する MCP ツールスキーマです。重量級の MCP サーバー（ブラウザ/playwright、Mac ツール、Windows ツール）はそれぞれターンごとに 20k+ トークンかかる場合があり、多くの場合 `model_profile` のチューニングで節約できるものをはるかに上回ります。トグルは Claude Code ハーネスにあります（`.claude/settings.json` の `enabledMcpjsonServers` / `disabledMcpjsonServers`）で、GSD の懸念事項ではありません。
|
||||
eager なスキルリストはターンごとの 2 つの主要コストの一つです。もう一つは `.claude/settings.json` で有効化されている各 MCP サーバーが注入する MCP ツールスキーマです。重量級の MCP サーバー（ブラウザ/playwright、Mac ツール、Windows ツール）はそれぞれターンごとに 20k+ トークンかかる場合があり、多くの場合 `model_profile` のチューニングで節約できるものをはるかに上回ります。トグルは Claude Code ハーネスにあります（`.claude/settings.json` の `enabledMcpjsonServers` / `disabledMcpjsonServers`）で、MSD の懸念事項ではありません。
|
||||
|
||||
### ワークフロー（`gsd-core/workflows/*.md`）
|
||||
### ワークフロー（`msd-core/workflows/*.md`）
|
||||
|
||||
コマンドが参照するオーケストレーションロジックです。以下を含むステップバイステップのプロセスが記述されています：
|
||||
|
||||
- `gsd-tools.cjs init` によるコンテキスト読み込み
|
||||
- `msd-tools.cjs init` によるコンテキスト読み込み
|
||||
- モデル解決を伴うエージェント起動の指示
|
||||
- ゲート/チェックポイントの定義
|
||||
- 状態更新パターン
|
||||
@@ -138,7 +138,7 @@ eager なスキルリストはターンごとの 2 つの主要コストの一
|
||||
|
||||
#### ワークフローのプログレッシブディスクロージャー
|
||||
|
||||
ワークフローファイルは、対応する `/gsd-*` コマンドが呼び出されるたびに Claude のコンテキストにそのまま読み込まれます。そのコストを制限するため、`tests/workflow-size-budget.test.cjs` で強制されるワークフローサイズバジェットはエージェントサイズバジェット規則を反映します：
|
||||
ワークフローファイルは、対応する `/msd-*` コマンドが呼び出されるたびに Claude のコンテキストにそのまま読み込まれます。そのコストを制限するため、`tests/workflow-size-budget.test.cjs` で強制されるワークフローサイズバジェットはエージェントサイズバジェット規則を反映します：
|
||||
|
||||
| ティア | ファイルごとの行数制限 |
|
||||
|-----------|--------------------|
|
||||
@@ -157,7 +157,7 @@ eager なスキルリストはターンごとの 2 つの主要コストの一
|
||||
|
||||
**エージェント総数:** 33
|
||||
|
||||
### リファレンス（`gsd-core/references/*.md`）
|
||||
### リファレンス（`msd-core/references/*.md`）
|
||||
|
||||
ワークフローとエージェントが `@-reference` で参照する共有知識ドキュメント（信頼できる数と完全なロスターについては [`docs/INVENTORY.md`](INVENTORY.md#references-41-shipped) を参照）：
|
||||
|
||||
@@ -193,9 +193,9 @@ eager なスキルリストはターンごとの 2 つの主要コストの一
|
||||
- `user-profiling.md` — ユーザー行動プロファイリングの方法論
|
||||
- `thinking-partner.md` — 決定ポイントでの条件付きシンキングパートナー起動
|
||||
|
||||
### テンプレート（`gsd-core/templates/`）
|
||||
### テンプレート（`msd-core/templates/`）
|
||||
|
||||
すべてのプランニングアーティファクト用のMarkdownテンプレートです。`gsd-tools.cjs template fill` および `scaffold` コマンドにより、事前構造化されたファイルを作成するために使用されます：
|
||||
すべてのプランニングアーティファクト用のMarkdownテンプレートです。`msd-tools.cjs template fill` および `scaffold` コマンドにより、事前構造化されたファイルを作成するために使用されます：
|
||||
- `project.md`、`requirements.md`、`roadmap.md`、`state.md` — コアプロジェクトファイル
|
||||
- `phase-prompt.md` — フェーズ実行プロンプトテンプレート
|
||||
- `summary.md`（+ `summary-minimal.md`、`summary-standard.md`、`summary-complex.md`）— 粒度対応のサマリーテンプレート
|
||||
@@ -211,20 +211,20 @@ eager なスキルリストはターンごとの 2 つの主要コストの一
|
||||
|
||||
| フック | イベント | 目的 |
|
||||
|------|-------|---------|
|
||||
| `gsd-statusline.js` | `statusLine` | モデル、タスク、ディレクトリ、コンテキスト使用量バーを表示 |
|
||||
| `gsd-context-monitor.js` | `PostToolUse` / `AfterTool` | コンテキスト残量35%/25%でエージェント向け警告を注入 |
|
||||
| `gsd-check-update.js` | `SessionStart` | GSDの新バージョンをバックグラウンドで確認 |
|
||||
| `gsd-prompt-guard.js` | `PreToolUse` | `.planning/` への書き込みにプロンプトインジェクションパターンがないかスキャン（アドバイザリー） |
|
||||
| `gsd-workflow-guard.js` | `PreToolUse` | GSDワークフローコンテキスト外でのファイル編集を検出（アドバイザリー、`hooks.workflow_guard` によるオプトイン） |
|
||||
| `gsd-secret-read-guard.js` | `PreToolUse` | Read / Grep / Bash による `.env`、`.env.<suffix>`（`.env.example` などのテンプレートは除外）、`.secrets` の読み取りをハードブロック。インストーラが書き込んでいた `Read(.env*)` の deny ルールを置き換える（#4221） |
|
||||
| `msd-statusline.js` | `statusLine` | モデル、タスク、ディレクトリ、コンテキスト使用量バーを表示 |
|
||||
| `msd-context-monitor.js` | `PostToolUse` / `AfterTool` | コンテキスト残量35%/25%でエージェント向け警告を注入 |
|
||||
| `msd-check-update.js` | `SessionStart` | MSDの新バージョンをバックグラウンドで確認 |
|
||||
| `msd-prompt-guard.js` | `PreToolUse` | `.planning/` への書き込みにプロンプトインジェクションパターンがないかスキャン（アドバイザリー） |
|
||||
| `msd-workflow-guard.js` | `PreToolUse` | MSDワークフローコンテキスト外でのファイル編集を検出（アドバイザリー、`hooks.workflow_guard` によるオプトイン） |
|
||||
| `msd-secret-read-guard.js` | `PreToolUse` | Read / Grep / Bash による `.env`、`.env.<suffix>`（`.env.example` などのテンプレートは除外）、`.secrets` の読み取りをハードブロック。インストーラが書き込んでいた `Read(.env*)` の deny ルールを置き換える（#4221） |
|
||||
|
||||
### コマンドルーティングハブ（`gsd-core/bin/lib/command-routing-hub.cjs`）
|
||||
### コマンドルーティングハブ（`msd-core/bin/lib/command-routing-hub.cjs`）
|
||||
|
||||
CJS コマンドファミリールーターは `CommandRoutingHub` を通じてディスパッチします。ハブはノースロー純粋結果コントラクト（`hub.dispatch()` は内部例外をキャッチして `{ ok: false, kind, ...typedPayload }` を返す）とクローズドランタイムエラー分類（`UnknownCommand`、`InvalidArgs`、`HandlerRefusal`、`HandlerFailure`）を所有します。ルーターアダプターは薄い CLI トランスレーターのままです——ハブを構築し、`dispatch` を呼び出し、結果を `output()`/`error()` 呼び出しにマッピングします。`docs/adr/0174-retire-gsd-sdk-package-boundary.md` を参照。
|
||||
CJS コマンドファミリールーターは `CommandRoutingHub` を通じてディスパッチします。ハブはノースロー純粋結果コントラクト（`hub.dispatch()` は内部例外をキャッチして `{ ok: false, kind, ...typedPayload }` を返す）とクローズドランタイムエラー分類（`UnknownCommand`、`InvalidArgs`、`HandlerRefusal`、`HandlerFailure`）を所有します。ルーターアダプターは薄い CLI トランスレーターのままです——ハブを構築し、`dispatch` を呼び出し、結果を `output()`/`error()` 呼び出しにマッピングします。`docs/adr/0174-retire-msd-sdk-package-boundary.md` を参照。
|
||||
|
||||
### CLI ツール（`gsd-core/bin/`）
|
||||
### CLI ツール（`msd-core/bin/`）
|
||||
|
||||
`gsd-core/bin/lib/` にドメインモジュールが分割された Node.js CLI ユーティリティ（`gsd-tools.cjs`）（信頼できるロスターについては [`docs/INVENTORY.md`](INVENTORY.md#cli-modules-33-shipped) を参照）：
|
||||
`msd-core/bin/lib/` にドメインモジュールが分割された Node.js CLI ユーティリティ（`msd-tools.cjs`）（信頼できるロスターについては [`docs/INVENTORY.md`](INVENTORY.md#cli-modules-33-shipped) を参照）：
|
||||
|
||||
| モジュール | 責務 |
|
||||
| ---------------------- | --------------------------------------------------------------------------------------------------- |
|
||||
@@ -258,10 +258,10 @@ CJS コマンドファミリールーターは `CommandRoutingHub` を通じて
|
||||
```
|
||||
Orchestrator (workflow .md)
|
||||
│
|
||||
├── Load context: gsd-tools.cjs init <workflow> <phase>
|
||||
├── Load context: msd-tools.cjs init <workflow> <phase>
|
||||
│ Returns JSON with: project info, config, state, phase details
|
||||
│
|
||||
├── Resolve model: gsd-tools.cjs resolve-model <agent-name>
|
||||
├── Resolve model: msd-tools.cjs resolve-model <agent-name>
|
||||
│ Returns: opus | sonnet | haiku | inherit
|
||||
│
|
||||
├── Spawn Agent (Task/SubAgent call)
|
||||
@@ -272,27 +272,27 @@ Orchestrator (workflow .md)
|
||||
│
|
||||
├── Collect result
|
||||
│
|
||||
└── Update state: gsd-tools.cjs state update/patch/advance-plan
|
||||
└── Update state: msd-tools.cjs state update/patch/advance-plan
|
||||
```
|
||||
|
||||
### 主要エージェント生成カテゴリ
|
||||
|
||||
21 の主要エージェントの概念的な生成パターン分類。信頼できる 31 エージェントロスター（`gsd-pattern-mapper`、`gsd-code-reviewer`、`gsd-code-fixer`、`gsd-ai-researcher`、`gsd-domain-researcher`、`gsd-eval-planner`、`gsd-eval-auditor`、`gsd-framework-selector`、`gsd-debug-session-manager`、`gsd-intel-updater` などの 10 の高度/専門化エージェントを含む）については、[`docs/INVENTORY.md`](INVENTORY.md#agents-31-shipped) を参照。
|
||||
21 の主要エージェントの概念的な生成パターン分類。信頼できる 31 エージェントロスター（`msd-pattern-mapper`、`msd-code-reviewer`、`msd-code-fixer`、`msd-ai-researcher`、`msd-domain-researcher`、`msd-eval-planner`、`msd-eval-auditor`、`msd-framework-selector`、`msd-debug-session-manager`、`msd-intel-updater` などの 10 の高度/専門化エージェントを含む）については、[`docs/INVENTORY.md`](INVENTORY.md#agents-31-shipped) を参照。
|
||||
|
||||
| カテゴリ | エージェント | 並列性 |
|
||||
| ---------------- | --------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
|
||||
| **リサーチャー** | gsd-project-researcher、gsd-phase-researcher、gsd-ui-researcher、gsd-advisor-researcher | 4 並列（stack、features、architecture、pitfalls）；advisor は discuss-phase 中に起動 |
|
||||
| **シンセサイザー** | gsd-research-synthesizer | 逐次（リサーチャー完了後） |
|
||||
| **プランナー** | gsd-planner、gsd-roadmapper | 逐次 |
|
||||
| **チェッカー** | gsd-plan-checker、gsd-integration-checker、gsd-ui-checker、gsd-nyquist-auditor | 逐次（検証ループ、最大 3 回反復） |
|
||||
| **エグゼキューター** | gsd-executor | ウェーブ内は並列、ウェーブ間は逐次 |
|
||||
| **ベリファイアー** | gsd-verifier | 逐次（全エグゼキューター完了後） |
|
||||
| **マッパー** | gsd-codebase-mapper | 4 並列（tech、arch、quality、concerns） |
|
||||
| **デバッガー** | gsd-debugger | 逐次（インタラクティブ） |
|
||||
| **オーディター** | gsd-ui-auditor、gsd-security-auditor | 逐次 |
|
||||
| **Doc ライター** | gsd-doc-writer、gsd-doc-verifier | 逐次（ライター後に検証者） |
|
||||
| **プロファイラー** | gsd-user-profiler | 逐次 |
|
||||
| **アナライザー** | gsd-assumptions-analyzer | 逐次（discuss-phase 中） |
|
||||
| **リサーチャー** | msd-project-researcher、msd-phase-researcher、msd-ui-researcher、msd-advisor-researcher | 4 並列（stack、features、architecture、pitfalls）；advisor は discuss-phase 中に起動 |
|
||||
| **シンセサイザー** | msd-research-synthesizer | 逐次（リサーチャー完了後） |
|
||||
| **プランナー** | msd-planner、msd-roadmapper | 逐次 |
|
||||
| **チェッカー** | msd-plan-checker、msd-integration-checker、msd-ui-checker、msd-nyquist-auditor | 逐次（検証ループ、最大 3 回反復） |
|
||||
| **エグゼキューター** | msd-executor | ウェーブ内は並列、ウェーブ間は逐次 |
|
||||
| **ベリファイアー** | msd-verifier | 逐次（全エグゼキューター完了後） |
|
||||
| **マッパー** | msd-codebase-mapper | 4 並列（tech、arch、quality、concerns） |
|
||||
| **デバッガー** | msd-debugger | 逐次（インタラクティブ） |
|
||||
| **オーディター** | msd-ui-auditor、msd-security-auditor | 逐次 |
|
||||
| **Doc ライター** | msd-doc-writer、msd-doc-verifier | 逐次（ライター後に検証者） |
|
||||
| **プロファイラー** | msd-user-profiler | 逐次 |
|
||||
| **アナライザー** | msd-assumptions-analyzer | 逐次（discuss-phase 中） |
|
||||
|
||||
### ウェーブ実行モデル
|
||||
|
||||
@@ -321,7 +321,7 @@ Wave Analysis:
|
||||
- **エグゼキューターエージェント** は前のウェーブの SUMMARY.md ファイルとフェーズの CONTEXT.md/RESEARCH.md を受け取り、フェーズ内でのクロスプラン認識を可能にする
|
||||
- **検証者エージェント** はすべての PLAN.md、SUMMARY.md、CONTEXT.md ファイルと REQUIREMENTS.md を受け取り、履歴を考慮した検証を可能にする
|
||||
|
||||
オーケストレーターは設定から `context_window` を読み取り（`gsd-tools.cjs config-get context_window`）、値が >= 500,000 の場合に条件付きでより豊富なコンテキストを含めます。標準 200K ウィンドウでは、プロンプトはコンテキスト効率を最大化するためにキャッシュフレンドリーな順序で切り詰められたバージョンを使います。
|
||||
オーケストレーターは設定から `context_window` を読み取り（`msd-tools.cjs config-get context_window`）、値が >= 500,000 の場合に条件付きでより豊富なコンテキストを含めます。標準 200K ウィンドウでは、プロンプトはコンテキスト効率を最大化するためにキャッシュフレンドリーな順序で切り詰められたバージョンを使います。
|
||||
|
||||
#### 並列コミットの安全性
|
||||
|
||||
@@ -426,10 +426,10 @@ UI-SPEC.md (per phase) ───────────────────
|
||||
|
||||
```
|
||||
~/.claude/ # Claude Code (global install)
|
||||
├── skills/gsd-*/SKILL.md # Global skills (authoritative roster: docs/INVENTORY.md)
|
||||
├── commands/gsd/*.md # Local Claude installs use slash commands instead of global skills
|
||||
├── gsd-core/
|
||||
│ ├── bin/gsd-tools.cjs # CLI utility
|
||||
├── skills/msd-*/SKILL.md # Global skills (authoritative roster: docs/INVENTORY.md)
|
||||
├── commands/msd/*.md # Local Claude installs use slash commands instead of global skills
|
||||
├── msd-core/
|
||||
│ ├── bin/msd-tools.cjs # CLI utility
|
||||
│ ├── bin/lib/*.cjs # Domain modules (authoritative roster: docs/INVENTORY.md)
|
||||
│ ├── workflows/*.md # Workflow definitions (authoritative roster: docs/INVENTORY.md)
|
||||
│ ├── references/*.md # Shared reference docs (authoritative roster: docs/INVENTORY.md)
|
||||
@@ -467,14 +467,14 @@ UI-SPEC.md (per phase) ───────────────────
|
||||
├── STATE.md # 生きたメモリ：位置、決定事項、ブロッカー、メトリクス
|
||||
├── config.json # ワークフロー設定
|
||||
├── MILESTONES.md # 完了済みマイルストーンのアーカイブ
|
||||
├── research/ # /gsd-new-project によるドメインリサーチ
|
||||
├── research/ # /msd-new-project によるドメインリサーチ
|
||||
│ ├── SUMMARY.md
|
||||
│ ├── STACK.md
|
||||
│ ├── FEATURES.md
|
||||
│ ├── ARCHITECTURE.md
|
||||
│ └── PITFALLS.md
|
||||
├── codebase/ # ブラウンフィールドマッピング（/gsd-map-codebase または /gsd-onboard から）
|
||||
├── onboarding/ # ブラウンフィールドオンボーディング概要（/gsd-onboard から）
|
||||
├── codebase/ # ブラウンフィールドマッピング（/msd-map-codebase または /msd-onboard から）
|
||||
├── onboarding/ # ブラウンフィールドオンボーディング概要（/msd-onboard から）
|
||||
│ ├── STACK.md
|
||||
│ ├── ARCHITECTURE.md
|
||||
│ ├── CONVENTIONS.md
|
||||
@@ -500,13 +500,13 @@ UI-SPEC.md (per phase) ───────────────────
|
||||
├── todos/
|
||||
│ ├── pending/ # キャプチャされたアイデア
|
||||
│ └── completed/ # 完了済みtodo
|
||||
├── threads/ # 永続コンテキストスレッド（/gsd-thread から）
|
||||
├── seeds/ # 将来に向けたアイデア（/gsd-capture --seed から）
|
||||
├── threads/ # 永続コンテキストスレッド（/msd-thread から）
|
||||
├── seeds/ # 将来に向けたアイデア（/msd-capture --seed から）
|
||||
├── debug/ # アクティブなデバッグセッション
|
||||
│ ├── *.md # アクティブセッション
|
||||
│ ├── resolved/ # アーカイブ済みセッション
|
||||
│ └── knowledge-base.md # 永続的なデバッグ知見
|
||||
├── ui-reviews/ # /gsd-ui-review からのスクリーンショット（gitignore対象）
|
||||
├── ui-reviews/ # /msd-ui-review からのスクリーンショット（gitignore対象）
|
||||
└── continue-here.md # コンテキスト引き継ぎ（pause-work から）
|
||||
```
|
||||
|
||||
@@ -530,15 +530,15 @@ UI-SPEC.md (per phase) ───────────────────
|
||||
- Windsurf: ルール参照付きスキルファースト
|
||||
- Trae: `~/.trae` / `./.trae` へのスキルファーストインストール、`settings.json` またはフック統合なし
|
||||
- Qwen Code: Qwen ブランドのパスとプロンプト書き換え付きスキルファースト
|
||||
- Hermes Agent: `skills/gsd/` 下のカテゴリベーススキル
|
||||
- Hermes Agent: `skills/msd/` 下のカテゴリベーススキル
|
||||
- CodeBuddy: CodeBuddy パスとプロンプト書き換え付きスキルファースト
|
||||
- Cline: ルールベース統合のための `.clinerules` を書き込む
|
||||
- Augment Code: スキルファースト、完全なスキル変換と設定管理
|
||||
5. **パス正規化** — `~/.claude/` パスをランタイム固有のパスに置換
|
||||
6. **設定統合** — ランタイムの `settings.json` にフックを登録
|
||||
7. **パッチバックアップ** — v1.17 以降、ローカルで変更されたファイルを `/gsd-update --reapply` 用に `gsd-local-patches/` へバックアップ
|
||||
8. **マニフェスト追跡** — クリーンアンインストールのために `gsd-file-manifest.json` を書き込み
|
||||
9. **アンインストールモード** — `--uninstall` ですべての GSD ファイル、フック、設定を削除
|
||||
7. **パッチバックアップ** — v1.17 以降、ローカルで変更されたファイルを `/msd-update --reapply` 用に `msd-local-patches/` へバックアップ
|
||||
8. **マニフェスト追跡** — クリーンアンインストールのために `msd-file-manifest.json` を書き込み
|
||||
9. **アンインストールモード** — `--uninstall` ですべての MSD ファイル、フック、設定を削除
|
||||
|
||||
インストール時のファイル移動、古いアーティファクトのクリーンアップ、設定の書き換え、ユーザーデータの保全は Installer Migration Module によって管理されます。[Installer Migrations](../installer-migrations.md) と [ADR 0008](../adr/0008-installer-migration-module.md) を参照してください。
|
||||
|
||||
@@ -557,17 +557,17 @@ UI-SPEC.md (per phase) ───────────────────
|
||||
```
|
||||
Runtime Engine (Claude Code / Antigravity CLI)
|
||||
│
|
||||
├── statusLine event ──► gsd-statusline.js
|
||||
├── statusLine event ──► msd-statusline.js
|
||||
│ Reads: stdin (session JSON)
|
||||
│ Writes: stdout (formatted status), /tmp/claude-ctx-{session}.json (bridge)
|
||||
│
|
||||
├── PostToolUse/AfterTool event ──► gsd-context-monitor.js
|
||||
├── PostToolUse/AfterTool event ──► msd-context-monitor.js
|
||||
│ Reads: stdin (tool event JSON), /tmp/claude-ctx-{session}.json (bridge)
|
||||
│ Writes: stdout (hookSpecificOutput with additionalContext warning)
|
||||
│
|
||||
└── SessionStart event ──► gsd-check-update.js
|
||||
└── SessionStart event ──► msd-check-update.js
|
||||
Reads: VERSION file
|
||||
Writes: ~/.claude/cache/gsd-update-check.json (spawns background process)
|
||||
Writes: ~/.claude/cache/msd-update-check.json (spawns background process)
|
||||
```
|
||||
|
||||
### コンテキストモニターの閾値
|
||||
@@ -596,52 +596,52 @@ Runtime Engine (Claude Code / Antigravity CLI)
|
||||
|
||||
| レイヤー | コンポーネント | アクション |
|
||||
|-------|-----------|--------|
|
||||
| 調査 | `gsd-phase-researcher` | `gsd-tools query package-legitimacy check --ecosystem <npm\|pypi\|crates> <pkgs>` を実行；`## Package Legitimacy Audit` テーブルを RESEARCH.md に書き込む；RESEARCH.md が書かれる前に `[SLOP]` パッケージを除去 |
|
||||
| 計画 | `gsd-planner` | 監査テーブルを読み取る；任意の `[ASSUMED]` または `[SUS]` インストールタスクの前に `checkpoint:human-verify` を挿入；`<threat_model>` に `T-{phase}-SC` STRIDE サプライチェーン行を追加 |
|
||||
| 実行 | `gsd-executor` | RULE 3 はパッケージインストールを自動修正スコープから除外；失敗したインストールはチェックポイントとして表面化し、サイレントな代替なし |
|
||||
| 調査 | `msd-phase-researcher` | `msd-tools query package-legitimacy check --ecosystem <npm\|pypi\|crates> <pkgs>` を実行；`## Package Legitimacy Audit` テーブルを RESEARCH.md に書き込む；RESEARCH.md が書かれる前に `[SLOP]` パッケージを除去 |
|
||||
| 計画 | `msd-planner` | 監査テーブルを読み取る；任意の `[ASSUMED]` または `[SUS]` インストールタスクの前に `checkpoint:human-verify` を挿入；`<threat_model>` に `T-{phase}-SC` STRIDE サプライチェーン行を追加 |
|
||||
| 実行 | `msd-executor` | RULE 3 はパッケージインストールを自動修正スコープから除外；失敗したインストールはチェックポイントとして表面化し、サイレントな代替なし |
|
||||
|
||||
セキュリティモデルの概念的な概要については [セキュリティモデル](explanation/security-model.md) を参照。
|
||||
|
||||
### セキュリティフック（v1.27）
|
||||
|
||||
**Prompt Guard**（`gsd-prompt-guard.js`）：
|
||||
**Prompt Guard**（`msd-prompt-guard.js`）：
|
||||
|
||||
- `.planning/` ファイルへの Write/Edit 時にトリガー
|
||||
- プロンプトインジェクションパターン（ロールオーバーライド、指示バイパス、system タグインジェクション）をスキャン
|
||||
- アドバイザリーのみ — 検出をログに記録するが、ブロックはしない
|
||||
- フックの独立性のため、パターンはインライン化（`security.cjs` のサブセット）
|
||||
|
||||
**Workflow Guard**（`gsd-workflow-guard.js`）：
|
||||
**Workflow Guard**（`msd-workflow-guard.js`）：
|
||||
|
||||
- `.planning/` 以外のファイルへの Write/Edit 時にトリガー
|
||||
- GSD ワークフローコンテキスト外での編集を検出（アクティブな `/gsd-` コマンドや Task サブエージェントがない場合）
|
||||
- 状態追跡される変更には `/gsd-quick` や `/gsd-fast` の使用をアドバイス
|
||||
- MSD ワークフローコンテキスト外での編集を検出（アクティブな `/msd-` コマンドや Task サブエージェントがない場合）
|
||||
- 状態追跡される変更には `/msd-quick` や `/msd-fast` の使用をアドバイス
|
||||
- `hooks.workflow_guard: true` によるオプトイン（デフォルト: false）
|
||||
|
||||
---
|
||||
|
||||
## ランタイム抽象化
|
||||
|
||||
GSD Core は統一されたコマンド/ワークフローアーキテクチャを通じて複数の AI コーディングランタイムをサポートしています：
|
||||
MSD Core は統一されたコマンド/ワークフローアーキテクチャを通じて複数の AI コーディングランタイムをサポートしています：
|
||||
|
||||
### ランタイムインストールコントラクトマトリクス
|
||||
|
||||
| ランタイム | グローバルルート | ローカルルート | 呼び出し面 | エージェント面 | 設定とフック |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| Claude Code | `~/.claude` | `./.claude` | グローバル `skills/gsd-*/SKILL.md`；ローカル `commands/gsd/*.md` | `agents/gsd-*.md` | `settings.json` フックと statusLine エントリ |
|
||||
| OpenCode | `~/.config/opencode` | `./.opencode` | `command/gsd-*.md` | `agents/gsd-*.md` | `opencode.json` または `opencode.jsonc`；GSD フックなし |
|
||||
| Kilo | `~/.config/kilo` | `./.kilo` | `command/gsd-*.md` | `agents/gsd-*.md` | `kilo.json` または `kilo.jsonc`；GSD フックなし |
|
||||
| Codex | `~/.codex` | `./.codex` | `skills/gsd-*/SKILL.md` | エージェントソース markdown + エージェントごとの TOML | `config.toml` `[agents.gsd-*]`、`[features].hooks`、フックテーブル |
|
||||
| GitHub Copilot | `~/.copilot` | `./.github` | `skills/gsd-*/SKILL.md` と `copilot-instructions.md` | `.agent.md` ファイル | GSD フックまたは statusline なし |
|
||||
| Antigravity | auto-detected：`~/.gemini/antigravity`、`~/.gemini/antigravity-ide`、または `~/.gemini/antigravity-cli` | `./.agent` | `skills/gsd-*/SKILL.md` | `agents/gsd-*.md` | GSD がインストールした場合の Gemini スタイル `settings.json` フックエントリ |
|
||||
| Cursor | `~/.cursor` | `./.cursor` | `skills/gsd-*/SKILL.md` | `agents/gsd-*.md` | `rules/` 下のルール参照；GSD フックなし |
|
||||
| Windsurf | `~/.codeium/windsurf` | `./.windsurf` | `skills/gsd-*/SKILL.md` | `agents/gsd-*.md` | `rules/` 下のルール参照；GSD フックなし |
|
||||
| Augment Code | `~/.augment` | `./.augment` | `skills/gsd-*/SKILL.md` | `agents/gsd-*.md` | GSD フックまたは statusline なし |
|
||||
| Trae | `~/.trae` | `./.trae` | `skills/gsd-*/SKILL.md` | `agents/gsd-*.md` | `rules/` 下のルール参照；GSD フックなし |
|
||||
| Qwen Code | `~/.qwen` | `./.qwen` | `skills/gsd-*/SKILL.md` | `agents/gsd-*.md` | サポートされている場合の共通 GSD 設定とフックエントリ |
|
||||
| Hermes Agent | `~/.hermes` | `./.hermes` | `skills/gsd/DESCRIPTION.md` と `skills/gsd/gsd-*/SKILL.md` | `agents/gsd-*.md` | サポートされている場合の共通 GSD 設定とフックエントリ |
|
||||
| CodeBuddy | `~/.codebuddy` | `./.codebuddy` | `skills/gsd-*/SKILL.md` | `agents/gsd-*.md` | サポートされている場合の共通 GSD 設定とフックエントリ |
|
||||
| Cline | `~/.cline` | project root | `.clinerules` | ルールのみ | GSD フックまたは statusline なし |
|
||||
| Claude Code | `~/.claude` | `./.claude` | グローバル `skills/msd-*/SKILL.md`；ローカル `commands/msd/*.md` | `agents/msd-*.md` | `settings.json` フックと statusLine エントリ |
|
||||
| OpenCode | `~/.config/opencode` | `./.opencode` | `command/msd-*.md` | `agents/msd-*.md` | `opencode.json` または `opencode.jsonc`；MSD フックなし |
|
||||
| Kilo | `~/.config/kilo` | `./.kilo` | `command/msd-*.md` | `agents/msd-*.md` | `kilo.json` または `kilo.jsonc`；MSD フックなし |
|
||||
| Codex | `~/.codex` | `./.codex` | `skills/msd-*/SKILL.md` | エージェントソース markdown + エージェントごとの TOML | `config.toml` `[agents.msd-*]`、`[features].hooks`、フックテーブル |
|
||||
| GitHub Copilot | `~/.copilot` | `./.github` | `skills/msd-*/SKILL.md` と `copilot-instructions.md` | `.agent.md` ファイル | MSD フックまたは statusline なし |
|
||||
| Antigravity | auto-detected：`~/.gemini/antigravity`、`~/.gemini/antigravity-ide`、または `~/.gemini/antigravity-cli` | `./.agent` | `skills/msd-*/SKILL.md` | `agents/msd-*.md` | MSD がインストールした場合の Gemini スタイル `settings.json` フックエントリ |
|
||||
| Cursor | `~/.cursor` | `./.cursor` | `skills/msd-*/SKILL.md` | `agents/msd-*.md` | `rules/` 下のルール参照；MSD フックなし |
|
||||
| Windsurf | `~/.codeium/windsurf` | `./.windsurf` | `skills/msd-*/SKILL.md` | `agents/msd-*.md` | `rules/` 下のルール参照；MSD フックなし |
|
||||
| Augment Code | `~/.augment` | `./.augment` | `skills/msd-*/SKILL.md` | `agents/msd-*.md` | MSD フックまたは statusline なし |
|
||||
| Trae | `~/.trae` | `./.trae` | `skills/msd-*/SKILL.md` | `agents/msd-*.md` | `rules/` 下のルール参照；MSD フックなし |
|
||||
| Qwen Code | `~/.qwen` | `./.qwen` | `skills/msd-*/SKILL.md` | `agents/msd-*.md` | サポートされている場合の共通 MSD 設定とフックエントリ |
|
||||
| Hermes Agent | `~/.hermes` | `./.hermes` | `skills/msd/DESCRIPTION.md` と `skills/msd/msd-*/SKILL.md` | `agents/msd-*.md` | サポートされている場合の共通 MSD 設定とフックエントリ |
|
||||
| CodeBuddy | `~/.codebuddy` | `./.codebuddy` | `skills/msd-*/SKILL.md` | `agents/msd-*.md` | サポートされている場合の共通 MSD 設定とフックエントリ |
|
||||
| Cline | `~/.cline` | project root | `.clinerules` | ルールのみ | MSD フックまたは statusline なし |
|
||||
|
||||
### 抽象化ポイント
|
||||
|
||||
@@ -649,7 +649,7 @@ GSD Core は統一されたコマンド/ワークフローアーキテクチャ
|
||||
2. **フックイベント名** — Claude Code は `PostToolUse`、Antigravity は `AfterTool` を使用
|
||||
3. **エージェントフロントマター** — 各ランタイムは独自のエージェント定義形式を持つ
|
||||
4. **パス規約** — 各ランタイムは異なるディレクトリに設定を保存
|
||||
5. **モデル参照** — `inherit` プロファイルにより、GSD はランタイムのモデル選択に委譲
|
||||
5. **モデル参照** — `inherit` プロファイルにより、MSD はランタイムのモデル選択に委譲
|
||||
|
||||
インストーラーはインストール時にすべての変換を処理します。ワークフローとエージェントは Claude Code のネイティブ形式で記述され、デプロイ時に変換されます。
|
||||
|
||||
|
||||
@@ -1,25 +1,25 @@
|
||||
# GSD CLI ツールリファレンス
|
||||
# MSD CLI ツールリファレンス
|
||||
|
||||
> `gsd-tools` CLI（`gsd-core/bin/gsd-tools.cjs`）のリファレンスです。スラッシュコマンドとユーザーフローについては [コマンドリファレンス](COMMANDS.md) を参照してください。[docs インデックス](README.md) に戻る。
|
||||
> `msd-tools` CLI（`msd-core/bin/msd-tools.cjs`）のリファレンスです。スラッシュコマンドとユーザーフローについては [コマンドリファレンス](COMMANDS.md) を参照してください。[docs インデックス](README.md) に戻る。
|
||||
|
||||
---
|
||||
|
||||
## 概要
|
||||
|
||||
`gsd-tools.cjs` は、設定の解析、モデル解決、フェーズ検索、git コミット、サマリー検証、状態管理、テンプレート操作を GSD コマンド・ワークフロー・エージェント全体で一元化します。
|
||||
`msd-tools.cjs` は、設定の解析、モデル解決、フェーズ検索、git コミット、サマリー検証、状態管理、テンプレート操作を MSD コマンド・ワークフロー・エージェント全体で一元化します。
|
||||
|
||||
|
||||
| | |
|
||||
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| **配置パス** | `gsd-core/bin/gsd-tools.cjs` |
|
||||
| **実装** | `gsd-core/bin/lib/` 配下の 20 個のドメインモジュール（ディレクトリが正式） |
|
||||
| **配置パス** | `msd-core/bin/msd-tools.cjs` |
|
||||
| **実装** | `msd-core/bin/lib/` 配下の 20 個のドメインモジュール（ディレクトリが正式） |
|
||||
| **ステータス** | オーケストレーション・ワークフロー・自動化処理のための主要ランタイムコマンドサーフェス。 |
|
||||
|
||||
|
||||
**使い方（CJS）:**
|
||||
|
||||
```bash
|
||||
node gsd-tools.cjs <command> [args] [--raw] [--cwd <path>]
|
||||
node msd-tools.cjs <command> [args] [--raw] [--cwd <path>]
|
||||
```
|
||||
|
||||
**グローバルフラグ（CJS）:**
|
||||
@@ -40,47 +40,47 @@ node gsd-tools.cjs <command> [args] [--raw] [--cwd <path>]
|
||||
|
||||
```bash
|
||||
# プロジェクトの全設定 + 状態を JSON として読み込む
|
||||
node gsd-tools.cjs state load
|
||||
node msd-tools.cjs state load
|
||||
|
||||
# STATE.md のフロントマターを JSON として出力
|
||||
node gsd-tools.cjs state json
|
||||
node msd-tools.cjs state json
|
||||
|
||||
# 単一フィールドを更新
|
||||
node gsd-tools.cjs state update <field> <value>
|
||||
node msd-tools.cjs state update <field> <value>
|
||||
|
||||
# STATE.md の内容または特定セクションを取得
|
||||
node gsd-tools.cjs state get [section]
|
||||
node msd-tools.cjs state get [section]
|
||||
|
||||
# 複数フィールドの一括更新
|
||||
node gsd-tools.cjs state patch --field1 val1 --field2 val2
|
||||
node msd-tools.cjs state patch --field1 val1 --field2 val2
|
||||
|
||||
# プランカウンターをインクリメント
|
||||
node gsd-tools.cjs state advance-plan
|
||||
node msd-tools.cjs state advance-plan
|
||||
|
||||
# 実行メトリクスを記録
|
||||
node gsd-tools.cjs state record-metric --phase N --plan M --duration Xmin [--tasks N] [--files N]
|
||||
node msd-tools.cjs state record-metric --phase N --plan M --duration Xmin [--tasks N] [--files N]
|
||||
|
||||
# プログレスバーを再計算
|
||||
node gsd-tools.cjs state update-progress
|
||||
node msd-tools.cjs state update-progress
|
||||
|
||||
# 決定事項を追加
|
||||
node gsd-tools.cjs state add-decision --summary "..." [--phase N] [--rationale "..."]
|
||||
node msd-tools.cjs state add-decision --summary "..." [--phase N] [--rationale "..."]
|
||||
# ファイルから追加する場合:
|
||||
node gsd-tools.cjs state add-decision --summary-file path [--rationale-file path]
|
||||
node msd-tools.cjs state add-decision --summary-file path [--rationale-file path]
|
||||
|
||||
# ブロッカーの追加・解決
|
||||
node gsd-tools.cjs state add-blocker --text "..."
|
||||
node gsd-tools.cjs state resolve-blocker --text "..."
|
||||
node msd-tools.cjs state add-blocker --text "..."
|
||||
node msd-tools.cjs state resolve-blocker --text "..."
|
||||
|
||||
# セッション継続性を記録
|
||||
node gsd-tools.cjs state record-session --stopped-at "..." [--resume-file path]
|
||||
node msd-tools.cjs state record-session --stopped-at "..." [--resume-file path]
|
||||
|
||||
# フェーズ開始 — 新しいフェーズの STATE.md Status/Last activity を更新
|
||||
node gsd-tools.cjs state begin-phase --phase N --name SLUG --plans COUNT
|
||||
node msd-tools.cjs state begin-phase --phase N --name SLUG --plans COUNT
|
||||
|
||||
# エージェント検出可能なブロッカーシグナル送信（discuss-phase / UI フローで使用）
|
||||
node gsd-tools.cjs state signal-waiting --type TYPE --question "..." --options "A|B" --phase P
|
||||
node gsd-tools.cjs state signal-resume
|
||||
node msd-tools.cjs state signal-waiting --type TYPE --question "..." --options "A|B" --phase P
|
||||
node msd-tools.cjs state signal-resume
|
||||
```
|
||||
|
||||
### State スナップショット
|
||||
@@ -88,7 +88,7 @@ node gsd-tools.cjs state signal-resume
|
||||
STATE.md 全体の構造化パース:
|
||||
|
||||
```bash
|
||||
node gsd-tools.cjs state-snapshot
|
||||
node msd-tools.cjs state-snapshot
|
||||
```
|
||||
|
||||
現在位置、フェーズ、プラン、ステータス、決定事項、ブロッカー、メトリクス、最終アクティビティを含む JSON を返します。
|
||||
@@ -101,28 +101,28 @@ node gsd-tools.cjs state-snapshot
|
||||
|
||||
```bash
|
||||
# 番号でフェーズディレクトリを検索
|
||||
node gsd-tools.cjs find-phase <phase>
|
||||
node msd-tools.cjs find-phase <phase>
|
||||
|
||||
# 挿入用の次の小数フェーズ番号を計算
|
||||
node gsd-tools.cjs phase next-decimal <phase>
|
||||
node msd-tools.cjs phase next-decimal <phase>
|
||||
|
||||
# ロードマップに新しいフェーズを追加 + ディレクトリを作成
|
||||
node gsd-tools.cjs phase add <description>
|
||||
node msd-tools.cjs phase add <description>
|
||||
|
||||
# 既存フェーズの後に小数フェーズを挿入
|
||||
node gsd-tools.cjs phase insert <after> <description>
|
||||
node msd-tools.cjs phase insert <after> <description>
|
||||
|
||||
# フェーズを削除し、後続を振り直し
|
||||
node gsd-tools.cjs phase remove <phase> [--force]
|
||||
node msd-tools.cjs phase remove <phase> [--force]
|
||||
|
||||
# フェーズを完了としてマークし、状態 + ロードマップを更新
|
||||
node gsd-tools.cjs phase complete <phase>
|
||||
node msd-tools.cjs phase complete <phase>
|
||||
|
||||
# ウェーブとステータス付きでプランをインデックス化
|
||||
node gsd-tools.cjs phase-plan-index <phase>
|
||||
node msd-tools.cjs phase-plan-index <phase>
|
||||
|
||||
# フィルタリング付きでフェーズを一覧表示
|
||||
node gsd-tools.cjs phases list [--type planned|executed|all] [--phase N] [--include-archived]
|
||||
node msd-tools.cjs phases list [--type planned|executed|all] [--phase N] [--include-archived]
|
||||
```
|
||||
|
||||
---
|
||||
@@ -133,13 +133,13 @@ node gsd-tools.cjs phases list [--type planned|executed|all] [--phase N] [--incl
|
||||
|
||||
```bash
|
||||
# ROADMAP.md からフェーズセクションを抽出
|
||||
node gsd-tools.cjs roadmap get-phase <phase>
|
||||
node msd-tools.cjs roadmap get-phase <phase>
|
||||
|
||||
# ディスク状態を含む完全なロードマップ解析
|
||||
node gsd-tools.cjs roadmap analyze
|
||||
node msd-tools.cjs roadmap analyze
|
||||
|
||||
# ディスクからプログレステーブル行を更新
|
||||
node gsd-tools.cjs roadmap update-plan-progress <N>
|
||||
node msd-tools.cjs roadmap update-plan-progress <N>
|
||||
```
|
||||
|
||||
---
|
||||
@@ -150,16 +150,16 @@ node gsd-tools.cjs roadmap update-plan-progress <N>
|
||||
|
||||
```bash
|
||||
# デフォルト値で config.json を初期化
|
||||
node gsd-tools.cjs config-ensure-section
|
||||
node msd-tools.cjs config-ensure-section
|
||||
|
||||
# 設定値をセット（ドット記法）
|
||||
node gsd-tools.cjs config-set <key> <value>
|
||||
node msd-tools.cjs config-set <key> <value>
|
||||
|
||||
# 設定値を取得
|
||||
node gsd-tools.cjs config-get <key>
|
||||
node msd-tools.cjs config-get <key>
|
||||
|
||||
# モデルプロファイルを設定
|
||||
node gsd-tools.cjs config-set-model-profile <profile>
|
||||
node msd-tools.cjs config-set-model-profile <profile>
|
||||
```
|
||||
|
||||
---
|
||||
@@ -168,13 +168,13 @@ node gsd-tools.cjs config-set-model-profile <profile>
|
||||
|
||||
```bash
|
||||
# 現在のプロファイルに基づいてエージェント用モデルを取得
|
||||
node gsd-tools.cjs resolve-model <agent-name>
|
||||
node msd-tools.cjs resolve-model <agent-name>
|
||||
# --raw 出力では選択されたモデル ID/ティアを返します。
|
||||
# JSON 出力ではプロファイルも含み、アクティブなランタイムがサポートしている場合は
|
||||
# reasoning_effort も含まれます。
|
||||
```
|
||||
|
||||
エージェント名: `gsd-planner`, `gsd-executor`, `gsd-phase-researcher`, `gsd-project-researcher`, `gsd-research-synthesizer`, `gsd-verifier`, `gsd-plan-checker`, `gsd-integration-checker`, `gsd-roadmapper`, `gsd-debugger`, `gsd-codebase-mapper`, `gsd-nyquist-auditor`
|
||||
エージェント名: `msd-planner`, `msd-executor`, `msd-phase-researcher`, `msd-project-researcher`, `msd-research-synthesizer`, `msd-verifier`, `msd-plan-checker`, `msd-integration-checker`, `msd-roadmapper`, `msd-debugger`, `msd-codebase-mapper`, `msd-nyquist-auditor`
|
||||
|
||||
---
|
||||
|
||||
@@ -184,25 +184,25 @@ node gsd-tools.cjs resolve-model <agent-name>
|
||||
|
||||
```bash
|
||||
# SUMMARY.md ファイルを検証
|
||||
node gsd-tools.cjs verify-summary <path> [--check-count N]
|
||||
node msd-tools.cjs verify-summary <path> [--check-count N]
|
||||
|
||||
# PLAN.md の構造 + タスクをチェック
|
||||
node gsd-tools.cjs verify plan-structure <file>
|
||||
node msd-tools.cjs verify plan-structure <file>
|
||||
|
||||
# 全プランにサマリーがあるか確認
|
||||
node gsd-tools.cjs verify phase-completeness <phase>
|
||||
node msd-tools.cjs verify phase-completeness <phase>
|
||||
|
||||
# @参照 + パスが解決可能か確認
|
||||
node gsd-tools.cjs verify references <file>
|
||||
node msd-tools.cjs verify references <file>
|
||||
|
||||
# コミットハッシュの一括検証
|
||||
node gsd-tools.cjs verify commits <hash1> [hash2] ...
|
||||
node msd-tools.cjs verify commits <hash1> [hash2] ...
|
||||
|
||||
# must_haves.artifacts をチェック
|
||||
node gsd-tools.cjs verify artifacts <plan-file>
|
||||
node msd-tools.cjs verify artifacts <plan-file>
|
||||
|
||||
# must_haves.key_links をチェック
|
||||
node gsd-tools.cjs verify key-links <plan-file>
|
||||
node msd-tools.cjs verify key-links <plan-file>
|
||||
```
|
||||
|
||||
---
|
||||
@@ -213,19 +213,19 @@ node gsd-tools.cjs verify key-links <plan-file>
|
||||
|
||||
```bash
|
||||
# フェーズ番号、ディスク/ロードマップの同期を確認
|
||||
node gsd-tools.cjs validate consistency
|
||||
node msd-tools.cjs validate consistency
|
||||
|
||||
# .planning/ の整合性チェック、任意で修復
|
||||
node gsd-tools.cjs validate health [--repair]
|
||||
node msd-tools.cjs validate health [--repair]
|
||||
|
||||
# ステータスライン / フック呼び出し元向けのコンテキストウィンドウ使用率をプローブ（v1.40.0）
|
||||
node gsd-tools.cjs validate context
|
||||
node msd-tools.cjs validate context
|
||||
|
||||
# 型付き JSON サーフェスとしてのコンテキスト使用率（#455）
|
||||
node gsd-tools.cjs validate context --json
|
||||
node msd-tools.cjs validate context --json
|
||||
```
|
||||
|
||||
`validate context` は `utilization`、`status`（60% / 70% の閾値で `ok` / `warn` / `critical`）、および `suggestion` 文字列を含む構造化エンベロープを出力します。同じデータが `/gsd-health --context` を支えます。
|
||||
`validate context` は `utilization`、`status`（60% / 70% の閾値で `ok` / `warn` / `critical`）、および `suggestion` 文字列を含む構造化エンベロープを出力します。同じデータが `/msd-health --context` を支えます。
|
||||
型付き IR を直接受け取るには `--json` を渡してください（スクリプトやテストアサーションで有用）。
|
||||
|
||||
---
|
||||
@@ -236,10 +236,10 @@ node gsd-tools.cjs validate context --json
|
||||
|
||||
```bash
|
||||
# 粒度に基づいてサマリーテンプレートを選択
|
||||
node gsd-tools.cjs template select <type>
|
||||
node msd-tools.cjs template select <type>
|
||||
|
||||
# 変数でテンプレートを穴埋め
|
||||
node gsd-tools.cjs template fill <type> --phase N [--plan M] [--name "..."] [--type execute|tdd] [--wave N] [--fields '{json}']
|
||||
node msd-tools.cjs template fill <type> --phase N [--plan M] [--name "..."] [--type execute|tdd] [--wave N] [--fields '{json}']
|
||||
```
|
||||
|
||||
`fill` のテンプレートタイプ: `summary`, `plan`, `verification`
|
||||
@@ -252,16 +252,16 @@ node gsd-tools.cjs template fill <type> --phase N [--plan M] [--name "..."] [--t
|
||||
|
||||
```bash
|
||||
# フロントマターを JSON として抽出
|
||||
node gsd-tools.cjs frontmatter get <file> [--field key]
|
||||
node msd-tools.cjs frontmatter get <file> [--field key]
|
||||
|
||||
# 単一フィールドを更新
|
||||
node gsd-tools.cjs frontmatter set <file> --field key --value jsonVal
|
||||
node msd-tools.cjs frontmatter set <file> --field key --value jsonVal
|
||||
|
||||
# JSON をフロントマターにマージ
|
||||
node gsd-tools.cjs frontmatter merge <file> --data '{json}'
|
||||
node msd-tools.cjs frontmatter merge <file> --data '{json}'
|
||||
|
||||
# 必須フィールドを検証
|
||||
node gsd-tools.cjs frontmatter validate <file> --schema plan|summary|verification
|
||||
node msd-tools.cjs frontmatter validate <file> --schema plan|summary|verification
|
||||
```
|
||||
|
||||
---
|
||||
@@ -272,48 +272,48 @@ node gsd-tools.cjs frontmatter validate <file> --schema plan|summary|verificatio
|
||||
|
||||
```bash
|
||||
# CONTEXT.md テンプレートを作成
|
||||
node gsd-tools.cjs scaffold context --phase N
|
||||
node msd-tools.cjs scaffold context --phase N
|
||||
|
||||
# UAT.md テンプレートを作成
|
||||
node gsd-tools.cjs scaffold uat --phase N
|
||||
node msd-tools.cjs scaffold uat --phase N
|
||||
|
||||
# VERIFICATION.md テンプレートを作成
|
||||
node gsd-tools.cjs scaffold verification --phase N
|
||||
node msd-tools.cjs scaffold verification --phase N
|
||||
|
||||
# フェーズディレクトリを作成
|
||||
node gsd-tools.cjs scaffold phase-dir --phase N --name "phase name"
|
||||
node msd-tools.cjs scaffold phase-dir --phase N --name "phase name"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Init コマンド（複合コンテキスト読み込み）
|
||||
|
||||
特定のワークフローに必要なすべてのコンテキストを一度に読み込みます。プロジェクト情報、設定、状態、ワークフロー固有のデータを含む JSON を返します。`init onboard [--fast] [--text]` は `/gsd-onboard` 用に、brownfield シグナル、計画ドキュメント候補、コードベースマップの完全性、fast マップの準備状況、テキストモードルーティング、部分的な planning 状態、オンボーディングサマリー状態を返します。
|
||||
特定のワークフローに必要なすべてのコンテキストを一度に読み込みます。プロジェクト情報、設定、状態、ワークフロー固有のデータを含む JSON を返します。`init onboard [--fast] [--text]` は `/msd-onboard` 用に、brownfield シグナル、計画ドキュメント候補、コードベースマップの完全性、fast マップの準備状況、テキストモードルーティング、部分的な planning 状態、オンボーディングサマリー状態を返します。
|
||||
|
||||
```bash
|
||||
node gsd-tools.cjs init execute-phase <phase>
|
||||
node gsd-tools.cjs init plan-phase <phase>
|
||||
node gsd-tools.cjs init new-project
|
||||
node gsd-tools.cjs init new-milestone
|
||||
node gsd-tools.cjs init onboard [--fast] [--text]
|
||||
node gsd-tools.cjs init quick <description>
|
||||
node gsd-tools.cjs init resume
|
||||
node gsd-tools.cjs init verify-work <phase>
|
||||
node gsd-tools.cjs init phase-op <phase>
|
||||
node gsd-tools.cjs init todos [area]
|
||||
node gsd-tools.cjs init milestone-op
|
||||
node gsd-tools.cjs init map-codebase
|
||||
node gsd-tools.cjs init progress
|
||||
node msd-tools.cjs init execute-phase <phase>
|
||||
node msd-tools.cjs init plan-phase <phase>
|
||||
node msd-tools.cjs init new-project
|
||||
node msd-tools.cjs init new-milestone
|
||||
node msd-tools.cjs init onboard [--fast] [--text]
|
||||
node msd-tools.cjs init quick <description>
|
||||
node msd-tools.cjs init resume
|
||||
node msd-tools.cjs init verify-work <phase>
|
||||
node msd-tools.cjs init phase-op <phase>
|
||||
node msd-tools.cjs init todos [area]
|
||||
node msd-tools.cjs init milestone-op
|
||||
node msd-tools.cjs init map-codebase
|
||||
node msd-tools.cjs init progress
|
||||
|
||||
# ワークストリームスコープ付き init（`--ws` フラグ）
|
||||
node gsd-tools.cjs init execute-phase <phase> --ws <name>
|
||||
node gsd-tools.cjs init plan-phase <phase> --ws <name>
|
||||
node msd-tools.cjs init execute-phase <phase> --ws <name>
|
||||
node msd-tools.cjs init plan-phase <phase> --ws <name>
|
||||
```
|
||||
|
||||
**大容量ペイロードの処理:** 出力が約 50KB を超える場合、CLI は一時ファイルに書き出し、`@file:/tmp/gsd-init-XXXXX.json` を返します。ワークフローは `@file:` プレフィックスを確認し、ディスクから読み込みます:
|
||||
**大容量ペイロードの処理:** 出力が約 50KB を超える場合、CLI は一時ファイルに書き出し、`@file:/tmp/msd-init-XXXXX.json` を返します。ワークフローは `@file:` プレフィックスを確認し、ディスクから読み込みます:
|
||||
|
||||
```bash
|
||||
INIT=$(node gsd-tools.cjs init execute-phase "1")
|
||||
INIT=$(node msd-tools.cjs init execute-phase "1")
|
||||
if [[ "$INIT" == @file:* ]]; then INIT=$(cat "${INIT#@file:}"); fi
|
||||
```
|
||||
|
||||
@@ -323,10 +323,10 @@ if [[ "$INIT" == @file:* ]]; then INIT=$(cat "${INIT#@file:}"); fi
|
||||
|
||||
```bash
|
||||
# マイルストーンをアーカイブ
|
||||
node gsd-tools.cjs milestone complete <version> (--confirm | --dry-run) [--name <name>] [--no-archive-phases] [--force] [--archive-quick]
|
||||
node msd-tools.cjs milestone complete <version> (--confirm | --dry-run) [--name <name>] [--no-archive-phases] [--force] [--archive-quick]
|
||||
|
||||
# 要件を完了としてマーク
|
||||
node gsd-tools.cjs requirements mark-complete <ids>
|
||||
node msd-tools.cjs requirements mark-complete <ids>
|
||||
# 受け付ける形式: REQ-01,REQ-02 または REQ-01 REQ-02 または [REQ-01, REQ-02]
|
||||
```
|
||||
|
||||
@@ -338,10 +338,10 @@ node gsd-tools.cjs requirements mark-complete <ids>
|
||||
|
||||
```bash
|
||||
# 生の XML スキルブロックを出力（デフォルト — シェル展開に安全）
|
||||
node gsd-tools.cjs agent-skills <agent-type>
|
||||
node msd-tools.cjs agent-skills <agent-type>
|
||||
|
||||
# 型付き JSON サーフェス（#455）を出力 — { agent_type, block, skills_count }
|
||||
node gsd-tools.cjs agent-skills <agent-type> --json
|
||||
node msd-tools.cjs agent-skills <agent-type> --json
|
||||
```
|
||||
|
||||
`--json` フラグは構造化消費やテストアサーションに適した型付き IR オブジェクトを返します。デフォルト（フラグなし）はワークフローのシェル展開が依存する生の XML 出力を維持します。
|
||||
@@ -354,13 +354,13 @@ node gsd-tools.cjs agent-skills <agent-type> --json
|
||||
|
||||
```bash
|
||||
# スキルマニフェストを生成（.claude/skill-manifest.json に書き込む）
|
||||
node gsd-tools.cjs skill-manifest
|
||||
node msd-tools.cjs skill-manifest
|
||||
|
||||
# カスタム出力パスで生成
|
||||
node gsd-tools.cjs skill-manifest --output <path>
|
||||
node msd-tools.cjs skill-manifest --output <path>
|
||||
```
|
||||
|
||||
利用可能なすべての GSD スキルとそのメタデータ（名前、説明、ファイルパス、引数ヒント）の JSON マッピングを返します。インストーラとセッション開始フックが繰り返しのファイルシステムスキャンを避けるために使用します。
|
||||
利用可能なすべての MSD スキルとそのメタデータ（名前、説明、ファイルパス、引数ヒント）の JSON マッピングを返します。インストーラとセッション開始フックが繰り返しのファイルシステムスキャンを避けるために使用します。
|
||||
|
||||
---
|
||||
|
||||
@@ -368,54 +368,54 @@ node gsd-tools.cjs skill-manifest --output <path>
|
||||
|
||||
```bash
|
||||
# テキストを URL セーフなスラッグに変換
|
||||
node gsd-tools.cjs generate-slug "Some Text Here"
|
||||
node msd-tools.cjs generate-slug "Some Text Here"
|
||||
# → some-text-here
|
||||
|
||||
# タイムスタンプを取得
|
||||
node gsd-tools.cjs current-timestamp [full|date|filename]
|
||||
node msd-tools.cjs current-timestamp [full|date|filename]
|
||||
|
||||
# 保留中の TODO をカウントして一覧表示
|
||||
node gsd-tools.cjs list-todos [area]
|
||||
node msd-tools.cjs list-todos [area]
|
||||
|
||||
# ファイル/ディレクトリの存在確認
|
||||
node gsd-tools.cjs verify-path-exists <path>
|
||||
node msd-tools.cjs verify-path-exists <path>
|
||||
|
||||
# 全 SUMMARY.md データを集約
|
||||
node gsd-tools.cjs history-digest
|
||||
node msd-tools.cjs history-digest
|
||||
|
||||
# SUMMARY.md から構造化データを抽出
|
||||
node gsd-tools.cjs summary-extract <path> [--fields field1,field2]
|
||||
node msd-tools.cjs summary-extract <path> [--fields field1,field2]
|
||||
|
||||
# プロジェクト統計
|
||||
node gsd-tools.cjs stats [json|table]
|
||||
node msd-tools.cjs stats [json|table]
|
||||
|
||||
# 進捗表示（人間が読める形式）
|
||||
node gsd-tools.cjs progress [json|table|bar]
|
||||
node msd-tools.cjs progress [json|table|bar]
|
||||
|
||||
# 型付き JSON サーフェスとしての進捗（#455）
|
||||
node gsd-tools.cjs progress --json
|
||||
node msd-tools.cjs progress --json
|
||||
|
||||
# TODO を完了にする
|
||||
node gsd-tools.cjs todo complete <filename> [--dry-run]
|
||||
node msd-tools.cjs todo complete <filename> [--dry-run]
|
||||
|
||||
# UAT 監査 — 全フェーズの未解決項目をスキャン
|
||||
node gsd-tools.cjs audit-uat
|
||||
node msd-tools.cjs audit-uat
|
||||
|
||||
# クロスアーティファクト監査キュー — `.planning/` の未解決監査項目をスキャン
|
||||
node gsd-tools.cjs audit-open [--json]
|
||||
node msd-tools.cjs audit-open [--json]
|
||||
|
||||
# GSD-2 プロジェクトを現在の構造にリバースマイグレーション（`/gsd-import --from-gsd2` のバックエンド）
|
||||
node gsd-tools.cjs from-gsd2 [--path <dir>] [--force] [--dry-run]
|
||||
# GSD-2 プロジェクトを現在の構造にリバースマイグレーション（`/msd-import --from-gsd2` のバックエンド）
|
||||
node msd-tools.cjs from-gsd2 [--path <dir>] [--force] [--dry-run]
|
||||
|
||||
# 設定チェック付き git コミット
|
||||
node gsd-tools.cjs commit <message> [--files f1 f2] [--amend] [--no-verify] [--respect-staged]
|
||||
node msd-tools.cjs commit <message> [--files f1 f2] [--amend] [--no-verify] [--respect-staged]
|
||||
```
|
||||
|
||||
> `--no-verify`: プリコミットフックをスキップします。ウェーブベース実行時に並列エグゼキューターエージェントがビルドロックの競合（例: Rust プロジェクトでの cargo ロック競合）を避けるために使用します。オーケストレーターは各ウェーブ完了後にフックを一度実行します。順次実行時には `--no-verify` を使用せず、フックを通常通り実行してください。
|
||||
> `--files <paths>` **ステージング動作**: デフォルトでは、`--files` はコミット前に各指定ファイルに対して `git add -- <path>` を実行します。これにより `git add -p` で設定したハンク単位のステージングが上書きされます。`git add` ステップをスキップして指定パス内のステージング済みファイルのみをコミットするには `--respect-staged` を渡してください。そのスコープ内でステージングされたファイルがない場合、コマンドはエラーなしで `{ committed: false, reason: 'nothing staged' }` を返します。コミット時の末尾 `-- <paths>` パス指定は両モードで適用されるため、`--files` スコープ外でステージングされたファイルは決して含まれません（#3061 不変条件）。
|
||||
|
||||
# Web 検索（Brave API キーが必要）
|
||||
node gsd-tools.cjs websearch <query> [--limit N] [--freshness day|week|month]
|
||||
node msd-tools.cjs websearch <query> [--limit N] [--freshness day|week|month]
|
||||
```
|
||||
|
||||
---
|
||||
@@ -426,22 +426,22 @@ node gsd-tools.cjs websearch <query> [--limit N] [--freshness day|week|month]
|
||||
|
||||
```bash
|
||||
# ナレッジグラフをビルドまたは再ビルド
|
||||
node gsd-tools.cjs graphify build
|
||||
node msd-tools.cjs graphify build
|
||||
|
||||
# グラフで用語を検索
|
||||
node gsd-tools.cjs graphify query <term>
|
||||
node msd-tools.cjs graphify query <term>
|
||||
|
||||
# グラフの鮮度と統計を表示
|
||||
node gsd-tools.cjs graphify status
|
||||
node msd-tools.cjs graphify status
|
||||
|
||||
# 前回のビルドからの変更を表示
|
||||
node gsd-tools.cjs graphify diff
|
||||
node msd-tools.cjs graphify diff
|
||||
|
||||
# 現在のグラフの名前付きスナップショットを書き込む
|
||||
node gsd-tools.cjs graphify snapshot [name]
|
||||
node msd-tools.cjs graphify snapshot [name]
|
||||
```
|
||||
|
||||
ユーザー向けエントリーポイント: `/gsd-graphify`（[コマンドリファレンス](COMMANDS.md#gsd-graphify) を参照）。
|
||||
ユーザー向けエントリーポイント: `/msd-graphify`（[コマンドリファレンス](COMMANDS.md#msd-graphify) を参照）。
|
||||
|
||||
---
|
||||
|
||||
@@ -465,30 +465,30 @@ node gsd-tools.cjs graphify snapshot [name]
|
||||
| UAT | `lib/uat.cjs` | 全フェーズ横断 UAT/検証監査 |
|
||||
| Profile Output | `lib/profile-output.cjs` | 開発者プロファイルのフォーマット |
|
||||
| Profile Pipeline | `lib/profile-pipeline.cjs` | セッション分析パイプライン |
|
||||
| Graphify | `lib/graphify.cjs` | ナレッジグラフのビルド/クエリ/ステータス/差分/スナップショット（`/gsd-graphify` のバックエンド） |
|
||||
| Learnings | `lib/learnings.cjs` | フェーズ/SUMMARY アーティファクトからの学習抽出（`/gsd-extract-learnings` のバックエンド） |
|
||||
| Graphify | `lib/graphify.cjs` | ナレッジグラフのビルド/クエリ/ステータス/差分/スナップショット（`/msd-graphify` のバックエンド） |
|
||||
| Learnings | `lib/learnings.cjs` | フェーズ/SUMMARY アーティファクトからの学習抽出（`/msd-extract-learnings` のバックエンド） |
|
||||
| Audit | `lib/audit.cjs` | フェーズ/マイルストーン監査キューハンドラ; `audit-open` ヘルパー |
|
||||
| GSD2 Import | `lib/gsd2-import.cjs` | GSD-2 プロジェクトからのリバースマイグレーションインポーター（`/gsd-import --from-gsd2` のバックエンド） |
|
||||
| Intel | `lib/intel.cjs` | クエリ可能なコードベースインテリジェンスインデックス（`/gsd-map-codebase --query` のバックエンド） |
|
||||
| MSD2 Import | `lib/gsd2-import.cjs` | GSD-2 プロジェクトからのリバースマイグレーションインポーター（`/msd-import --from-gsd2` のバックエンド） |
|
||||
| Intel | `lib/intel.cjs` | クエリ可能なコードベースインテリジェンスインデックス（`/msd-map-codebase --query` のバックエンド） |
|
||||
|
||||
---
|
||||
|
||||
## レビュアー CLI ルーティング
|
||||
|
||||
`review.models.<cli>` はレビュアーフレーバーをコードレビューワークフローが呼び出すシェルコマンドにマッピングします。[`/gsd-config --integrations`](COMMANDS.md#gsd-config) または直接設定できます:
|
||||
`review.models.<cli>` はレビュアーフレーバーをコードレビューワークフローが呼び出すシェルコマンドにマッピングします。[`/msd-config --integrations`](COMMANDS.md#msd-config) または直接設定できます:
|
||||
|
||||
```bash
|
||||
node gsd-tools.cjs config-set review.models.codex "codex exec --model gpt-5"
|
||||
node gsd-tools.cjs config-set review.models.agy "gemini-3.1-pro-preview"
|
||||
node gsd-tools.cjs config-set review.models.opencode "opencode run --model claude-sonnet-4"
|
||||
node gsd-tools.cjs config-set review.models.claude "" # クリア — セッションモデルにフォールバック
|
||||
node msd-tools.cjs config-set review.models.codex "codex exec --model gpt-5"
|
||||
node msd-tools.cjs config-set review.models.agy "gemini-3.1-pro-preview"
|
||||
node msd-tools.cjs config-set review.models.opencode "opencode run --model claude-sonnet-4"
|
||||
node msd-tools.cjs config-set review.models.claude "" # クリア — セッションモデルにフォールバック
|
||||
```
|
||||
|
||||
スラッグは `[a-zA-Z0-9_-]+` に対してバリデーションされます。空またはパスを含むスラッグは拒否されます。完全なフィールドリファレンスは [`docs/CONFIGURATION.md`](CONFIGURATION.md#code-review-cli-routing) を参照してください。
|
||||
|
||||
## シークレット処理
|
||||
|
||||
`/gsd-settings` で設定された API キー（`brave_search`、`firecrawl`、`exa_search`）は `.planning/config.json` に平文で書き込まれますが、`config-set` / `config-get` のすべての出力、確認テーブル、インタラクティブプロンプトでは（`****<last-4>` として）マスクされます。マスキングの実装は `gsd-core/bin/lib/secrets.cjs` を参照してください。`config.json` ファイル自体がセキュリティ境界です — ファイルシステムのパーミッションで保護し、git には含めないようにしてください（`.planning/` はデフォルトで gitignore されます）。
|
||||
`/msd-settings` で設定された API キー（`brave_search`、`firecrawl`、`exa_search`）は `.planning/config.json` に平文で書き込まれますが、`config-set` / `config-get` のすべての出力、確認テーブル、インタラクティブプロンプトでは（`****<last-4>` として）マスクされます。マスキングの実装は `msd-core/bin/lib/secrets.cjs` を参照してください。`config.json` ファイル自体がセキュリティ境界です — ファイルシステムのパーミッションで保護し、git には含めないようにしてください（`.planning/` はデフォルトで gitignore されます）。
|
||||
|
||||
---
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,4 +1,4 @@
|
||||
# GSD 設定リファレンス
|
||||
# MSD 設定リファレンス
|
||||
|
||||
> 設定スキーマの全容、ワークフロートグル、モデルプロファイル、Git ブランチオプション。機能の詳細については[機能リファレンス](FEATURES.md)を参照してください。
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
## 設定ファイル
|
||||
|
||||
GSD はプロジェクト設定を `.planning/config.json` に保存します。`/gsd-new-project` 実行時に作成され、`/gsd-settings` で更新できます。
|
||||
MSD はプロジェクト設定を `.planning/config.json` に保存します。`/msd-new-project` 実行時に作成され、`/msd-settings` で更新できます。
|
||||
|
||||
### 完全スキーマ
|
||||
|
||||
@@ -50,8 +50,8 @@ GSD はプロジェクト設定を `.planning/config.json` に保存します。
|
||||
},
|
||||
"git": {
|
||||
"branching_strategy": "none",
|
||||
"phase_branch_template": "gsd/phase-{phase}-{slug}",
|
||||
"milestone_branch_template": "gsd/{milestone}-{slug}",
|
||||
"phase_branch_template": "msd/phase-{phase}-{slug}",
|
||||
"milestone_branch_template": "msd/{milestone}-{slug}",
|
||||
"quick_branch_template": null
|
||||
},
|
||||
"gates": {
|
||||
@@ -97,15 +97,15 @@ GSD はプロジェクト設定を `.planning/config.json` に保存します。
|
||||
| `workflow.auto_advance` | boolean | `false` | discuss → plan → execute を停止せずに自動連鎖 |
|
||||
| `workflow.nyquist_validation` | boolean | `true` | plan-phase のリサーチ中にテストカバレッジマッピングを実施 |
|
||||
| `workflow.ui_phase` | boolean | `true` | フロントエンドフェーズで UI デザインコントラクトを生成 |
|
||||
| `workflow.ui_safety_gate` | boolean | `true` | plan-phase 中にフロントエンドフェーズに対して /gsd-ui-phase の実行を促すプロンプトを表示 |
|
||||
| `workflow.ui_safety_gate` | boolean | `true` | plan-phase 中にフロントエンドフェーズに対して /msd-ui-phase の実行を促すプロンプトを表示 |
|
||||
| `workflow.node_repair` | boolean | `true` | 検証失敗時にタスクを自律的に修復 |
|
||||
| `workflow.node_repair_budget` | number | `2` | 失敗タスクあたりの最大修復試行回数 |
|
||||
| `workflow.research_before_questions` | boolean | `false` | ディスカッション質問の後ではなく前にリサーチを実行 |
|
||||
| `workflow.use_worktrees` | boolean | `true` | `false` の場合、git worktree 分離を無効化 (v1.31) |
|
||||
| `workflow.discuss_mode` | string | `'discuss'` | `/gsd-discuss-phase` のコンテキスト収集方法を制御。`'discuss'`（デフォルト）は質問を1つずつ行います。`'assumptions'` はまずコードベースを読み取り、信頼度レベル付きの構造化された仮説を生成し、誤っている点のみ修正を求めます。v1.28 で追加 |
|
||||
| `workflow.skip_discuss` | boolean | `false` | `true` の場合、`/gsd-autonomous` は discuss-phase を完全にスキップし、ROADMAP のフェーズ目標から最小限の CONTEXT.md を作成します。開発者の要望が PROJECT.md/REQUIREMENTS.md に十分に記載されているプロジェクトに適しています。v1.28 で追加 |
|
||||
| `workflow.discuss_mode` | string | `'discuss'` | `/msd-discuss-phase` のコンテキスト収集方法を制御。`'discuss'`（デフォルト）は質問を1つずつ行います。`'assumptions'` はまずコードベースを読み取り、信頼度レベル付きの構造化された仮説を生成し、誤っている点のみ修正を求めます。v1.28 で追加 |
|
||||
| `workflow.skip_discuss` | boolean | `false` | `true` の場合、`/msd-autonomous` は discuss-phase を完全にスキップし、ROADMAP のフェーズ目標から最小限の CONTEXT.md を作成します。開発者の要望が PROJECT.md/REQUIREMENTS.md に十分に記載されているプロジェクトに適しています。v1.28 で追加 |
|
||||
| `workflow.text_mode` | boolean | `false` | AskUserQuestion の TUI メニューをプレーンテキストの番号付きリストに置き換えます。TUI メニューが表示されない Claude Code リモートセッション（`/rc` モード）で必要です。discuss-phase で `--text` フラグを使用してセッションごとに設定することもできます。v1.28 で追加 |
|
||||
| `planner.stall_detection_enabled` | boolean | `true` | 標準プランナー、チャンク化されたアウトライン/プラン別プランナー、プランチェッカー、改訂プランナーの有界な停止検出を制御します。`gsd config-set planner.stall_detection_enabled false` を設定すると watchdog ポーリングを省略し、各エージェントをランタイムネイティブの完了機構で待機します。**警告:** `false` はランタイムが完了通知を失った場合の有界な復旧を放棄します。既存のファイルシステムフォールバックを使うために中断が必要になることがあります。 |
|
||||
| `planner.stall_detection_enabled` | boolean | `true` | 標準プランナー、チャンク化されたアウトライン/プラン別プランナー、プランチェッカー、改訂プランナーの有界な停止検出を制御します。`msd config-set planner.stall_detection_enabled false` を設定すると watchdog ポーリングを省略し、各エージェントをランタイムネイティブの完了機構で待機します。**警告:** `false` はランタイムが完了通知を失った場合の有界な復旧を放棄します。既存のファイルシステムフォールバックを使うために中断が必要になることがあります。 |
|
||||
|
||||
### 推奨プリセット
|
||||
|
||||
@@ -122,7 +122,7 @@ GSD はプロジェクト設定を `.planning/config.json` に保存します。
|
||||
| 設定 | 型 | デフォルト | 説明 |
|
||||
|------|-----|-----------|------|
|
||||
| `planning.commit_docs` | boolean | `true` | `.planning/` ファイルを git にコミットするかどうか |
|
||||
| `planning.pr_strict` | boolean | `false` | `/gsd-pr-branch` のフィルタモード。`false` は STATE.md、ROADMAP.md、MILESTONES.md、PROJECT.md、REQUIREMENTS.md、milestones/ などの構造的なプランニング状態を PR ブランチに残す。`true` はすべての `.planning/` パスを削除する |
|
||||
| `planning.pr_strict` | boolean | `false` | `/msd-pr-branch` のフィルタモード。`false` は STATE.md、ROADMAP.md、MILESTONES.md、PROJECT.md、REQUIREMENTS.md、milestones/ などの構造的なプランニング状態を PR ブランチに残す。`true` はすべての `.planning/` パスを削除する |
|
||||
| `planning.search_gitignored` | boolean | `false` | `.planning/` を含めるために広範な検索に `--no-ignore` を追加 |
|
||||
|
||||
### 自動検出
|
||||
@@ -136,9 +136,9 @@ GSD はプロジェクト設定を `.planning/config.json` に保存します。
|
||||
| 設定 | 型 | デフォルト | 説明 |
|
||||
|------|-----|-----------|------|
|
||||
| `hooks.context_warnings` | boolean | `true` | コンテキストモニターフックによるコンテキストウィンドウ使用量の警告を表示 |
|
||||
| `hooks.workflow_guard` | boolean | `false` | GSD ワークフローのコンテキスト外でファイル編集が行われた場合に警告（`/gsd-quick` または `/gsd-fast` の使用を推奨） |
|
||||
| `hooks.workflow_guard` | boolean | `false` | MSD ワークフローのコンテキスト外でファイル編集が行われた場合に警告（`/msd-quick` または `/msd-fast` の使用を推奨） |
|
||||
|
||||
プロンプトインジェクションガードフック（`gsd-prompt-guard.js`）は常に有効であり、無効にすることはできません。これはワークフロートグルではなく、セキュリティ機能です。
|
||||
プロンプトインジェクションガードフック（`msd-prompt-guard.js`）は常に有効であり、無効にすることはできません。これはワークフロートグルではなく、セキュリティ機能です。
|
||||
|
||||
### プライベートプランニングのセットアップ
|
||||
|
||||
@@ -170,9 +170,9 @@ GSD はプロジェクト設定を `.planning/config.json` に保存します。
|
||||
| 設定 | 型 | デフォルト | 説明 |
|
||||
|------|-----|-----------|------|
|
||||
| `git.branching_strategy` | enum | `none` | `none`、`phase`、または `milestone` |
|
||||
| `git.phase_branch_template` | string | `gsd/phase-{phase}-{slug}` | phase 戦略のブランチ名テンプレート |
|
||||
| `git.milestone_branch_template` | string | `gsd/{milestone}-{slug}` | milestone 戦略のブランチ名テンプレート |
|
||||
| `git.quick_branch_template` | string or null | `null` | `/gsd-quick` タスク用のオプションのブランチ名テンプレート |
|
||||
| `git.phase_branch_template` | string | `msd/phase-{phase}-{slug}` | phase 戦略のブランチ名テンプレート |
|
||||
| `git.milestone_branch_template` | string | `msd/{milestone}-{slug}` | milestone 戦略のブランチ名テンプレート |
|
||||
| `git.quick_branch_template` | string or null | `null` | `/msd-quick` タスク用のオプションのブランチ名テンプレート |
|
||||
|
||||
### 戦略の比較
|
||||
|
||||
@@ -195,7 +195,7 @@ quick タスクのブランチ設定例：
|
||||
|
||||
```json
|
||||
"git": {
|
||||
"quick_branch_template": "gsd/quick-{num}-{slug}"
|
||||
"quick_branch_template": "msd/quick-{num}-{slug}"
|
||||
}
|
||||
```
|
||||
|
||||
@@ -270,18 +270,18 @@ quick タスクのブランチ設定例：
|
||||
|
||||
| エージェント | `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 |
|
||||
| msd-planner | Opus | Opus | Sonnet | Inherit |
|
||||
| msd-roadmapper | Opus | Sonnet | Sonnet | Inherit |
|
||||
| msd-executor | Opus | Sonnet | Sonnet | Inherit |
|
||||
| msd-phase-researcher | Opus | Sonnet | Haiku | Inherit |
|
||||
| msd-project-researcher | Opus | Sonnet | Haiku | Inherit |
|
||||
| msd-research-synthesizer | Sonnet | Sonnet | Haiku | Inherit |
|
||||
| msd-debugger | Opus | Sonnet | Sonnet | Inherit |
|
||||
| msd-codebase-mapper | Sonnet | Haiku | Haiku | Inherit |
|
||||
| msd-verifier | Sonnet | Sonnet | Haiku | Inherit |
|
||||
| msd-plan-checker | Sonnet | Sonnet | Haiku | Inherit |
|
||||
| msd-integration-checker | Sonnet | Sonnet | Haiku | Inherit |
|
||||
| msd-nyquist-auditor | Sonnet | Sonnet | Haiku | Inherit |
|
||||
|
||||
### エージェントごとのオーバーライド
|
||||
|
||||
@@ -291,8 +291,8 @@ quick タスクのブランチ設定例：
|
||||
{
|
||||
"model_profile": "balanced",
|
||||
"model_overrides": {
|
||||
"gsd-executor": "opus",
|
||||
"gsd-planner": "haiku"
|
||||
"msd-executor": "opus",
|
||||
"msd-planner": "haiku"
|
||||
}
|
||||
}
|
||||
```
|
||||
@@ -301,7 +301,7 @@ quick タスクのブランチ設定例：
|
||||
|
||||
### 非 Claude ランタイム（Codex、OpenCode、Antigravity CLI、Kilo）
|
||||
|
||||
GSD が非 Claude ランタイム向けにインストールされると、インストーラーは自動的に `~/.gsd/defaults.json` に `resolve_model_ids: "omit"` を設定します。これにより GSD はすべてのエージェントに対して空のモデルパラメータを返し、各エージェントはランタイムで設定されたモデルを使用します。デフォルトの場合、追加のセットアップは不要です。
|
||||
MSD が非 Claude ランタイム向けにインストールされると、インストーラーは自動的に `~/.msd/defaults.json` に `resolve_model_ids: "omit"` を設定します。これにより MSD はすべてのエージェントに対して空のモデルパラメータを返し、各エージェントはランタイムで設定されたモデルを使用します。デフォルトの場合、追加のセットアップは不要です。
|
||||
|
||||
異なるエージェントに異なるモデルを使用させたい場合は、ランタイムが認識する完全修飾モデル ID で `model_overrides` を使用してください：
|
||||
|
||||
@@ -309,10 +309,10 @@ GSD が非 Claude ランタイム向けにインストールされると、イ
|
||||
{
|
||||
"resolve_model_ids": "omit",
|
||||
"model_overrides": {
|
||||
"gsd-planner": "o3",
|
||||
"gsd-executor": "o4-mini",
|
||||
"gsd-debugger": "o3",
|
||||
"gsd-codebase-mapper": "o4-mini"
|
||||
"msd-planner": "o3",
|
||||
"msd-executor": "o4-mini",
|
||||
"msd-debugger": "o3",
|
||||
"msd-codebase-mapper": "o4-mini"
|
||||
}
|
||||
}
|
||||
```
|
||||
@@ -354,7 +354,7 @@ GSD が非 Claude ランタイム向けにインストールされると、イ
|
||||
| `CLAUDE_CONFIG_DIR` | デフォルトの設定ディレクトリ（`~/.claude/`）をオーバーライド |
|
||||
| `GEMINI_API_KEY` | コンテキストモニターがフックイベント名を切り替えるために検出 |
|
||||
| `WSL_DISTRO_NAME` | インストーラーが WSL のパス処理のために検出 |
|
||||
| `GSD_SKIP_SCHEMA_CHECK` | スキーマドリフト検出をバイパス (v1.31) |
|
||||
| `MSD_SKIP_SCHEMA_CHECK` | スキーマドリフト検出をバイパス (v1.31) |
|
||||
|
||||
---
|
||||
|
||||
@@ -362,6 +362,6 @@ GSD が非 Claude ランタイム向けにインストールされると、イ
|
||||
|
||||
将来のプロジェクト向けにグローバルデフォルトとして設定を保存できます。
|
||||
|
||||
**保存場所:** `~/.gsd/defaults.json`
|
||||
**保存場所:** `~/.msd/defaults.json`
|
||||
|
||||
`/gsd-new-project` が新しい `config.json` を作成する際、グローバルデフォルトを読み込み、初期設定としてマージします。プロジェクトごとの設定は常にグローバル設定を上書きします。
|
||||
`/msd-new-project` が新しい `config.json` を作成する際、グローバルデフォルトを読み込み、初期設定としてマージします。プロジェクトごとの設定は常にグローバル設定を上書きします。
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,64 +1,64 @@
|
||||
# GSD 出荷済みサーフェスインベントリ
|
||||
# MSD 出荷済みサーフェスインベントリ
|
||||
|
||||
> 出荷済みのすべての GSD サーフェスの正式な一覧: コマンド、エージェント、ワークフロー、リファレンス、CLI モジュール、フック。広範なドキュメント（AGENTS.md、COMMANDS.md、ARCHITECTURE.md、CLI-TOOLS.md）とファイルシステムが乖離している場合は、このファイルとリポジトリツリー自体を正式なソースとして扱ってください。
|
||||
> 出荷済みのすべての MSD サーフェスの正式な一覧: コマンド、エージェント、ワークフロー、リファレンス、CLI モジュール、フック。広範なドキュメント（AGENTS.md、COMMANDS.md、ARCHITECTURE.md、CLI-TOOLS.md）とファイルシステムが乖離している場合は、このファイルとリポジトリツリー自体を正式なソースとして扱ってください。
|
||||
|
||||
## このファイルの使い方
|
||||
|
||||
- ここに記載された数値は v1.36.0 時点のファイルシステムから導出されており、リリース間で変動する可能性があります。最新の数値を確認するには、チェックアウトに対して `ls commands/gsd/*.md | wc -l`、`ls agents/gsd-*.md | wc -l` などを実行してください。
|
||||
- ここに記載された数値は v1.36.0 時点のファイルシステムから導出されており、リリース間で変動する可能性があります。最新の数値を確認するには、チェックアウトに対して `ls commands/msd/*.md | wc -l`、`ls agents/msd-*.md | wc -l` などを実行してください。
|
||||
- このファイルは出荷済みのすべてのサーフェスを 6 つのファミリー（エージェント、コマンド、ワークフロー、リファレンス、CLI モジュール、フック）にわたって列挙します。広範なドキュメントはナラティブや厳選されたサブセットを提示する場合があります。ファイルシステムと異なる場合は、このファイルとディレクトリ一覧が正式です。
|
||||
- v1.36.0 以降に追加された新しいサーフェスはまずここに記載し、その後広範なドキュメントに伝播させてください。`tests/inventory-manifest-sync.test.cjs` のドリフト管理テストが、ファイルシステムに対してロスター内容を固定します。
|
||||
|
||||
これは出荷済みのすべての GSD Core サーフェスの正式な一覧です。トピック別のナビゲーションは [docs インデックス](README.md) を参照してください。
|
||||
これは出荷済みのすべての MSD Core サーフェスの正式な一覧です。トピック別のナビゲーションは [docs インデックス](README.md) を参照してください。
|
||||
|
||||
---
|
||||
|
||||
## エージェント (33 shipped)
|
||||
|
||||
完全な一覧は `agents/gsd-*.md` を参照してください。"Primary doc" 列は [`docs/AGENTS.md`](../AGENTS.md) が完全なロールカードを掲載している場合（*primary*）、"Advanced and Specialized Agents" セクションに短いスタブがある場合（*advanced stub*）、または掲載がない場合（*inventory only*）を示します。
|
||||
完全な一覧は `agents/msd-*.md` を参照してください。"Primary doc" 列は [`docs/AGENTS.md`](../AGENTS.md) が完全なロールカードを掲載している場合（*primary*）、"Advanced and Specialized Agents" セクションに短いスタブがある場合（*advanced stub*）、または掲載がない場合（*inventory only*）を示します。
|
||||
|
||||
| エージェント | 役割（一行） | 起動元 | Primary doc |
|
||||
|--------------|-------------|--------|-------------|
|
||||
| gsd-project-researcher | ロードマップ作成前にドメインエコシステムを調査（スタック、機能、アーキテクチャ、落とし穴）。 | `/gsd-new-project`, `/gsd-new-milestone` | primary |
|
||||
| gsd-phase-researcher | 計画前に特定フェーズの実装アプローチを調査。 | `/gsd-plan-phase` | primary |
|
||||
| gsd-ui-researcher | フロントエンドフェーズ向けの UI デザインコントラクトを作成。 | `/gsd-ui-phase` | primary |
|
||||
| gsd-assumptions-analyzer | discuss-phase（仮定モード）向けに証拠に基づく仮定を作成。 | `discuss-phase-assumptions` workflow | primary |
|
||||
| gsd-advisor-researcher | discuss-phase アドバイザーモード中に単一のグレーゾーン決定を調査。 | `discuss-phase` workflow (advisor mode) | primary |
|
||||
| gsd-research-synthesizer | 並列調査エージェントの出力を統合した SUMMARY.md にまとめる。 | `/gsd-new-project` | primary |
|
||||
| gsd-planner | タスク分解とゴール後退型検証を含む実行可能なフェーズプランを作成。 | `/gsd-plan-phase`, `/gsd-quick` | primary |
|
||||
| gsd-roadmapper | フェーズ分解と要件マッピングを含むプロジェクトロードマップを作成。 | `/gsd-new-project` | primary |
|
||||
| gsd-executor | アトミックコミットと逸脱処理を伴って GSD プランを実行。 | `/gsd-execute-phase`, `/gsd-quick` | primary |
|
||||
| gsd-plan-checker | プランがフェーズ目標を達成できるか検証（8 つの検証ディメンション）。 | `/gsd-plan-phase` (verification loop) | primary |
|
||||
| gsd-integration-checker | クロスフェーズ統合とエンドツーエンドフローを検証。 | `/gsd-audit-milestone` | primary |
|
||||
| gsd-ui-checker | UI-SPEC.md デザインコントラクトを品質ディメンションに対して検証。 | `/gsd-ui-phase` (validation loop) | primary |
|
||||
| gsd-verifier | ゴール後退型分析によってフェーズ目標の達成を検証。 | `/gsd-execute-phase` | primary |
|
||||
| gsd-nyquist-auditor | テストを生成して Nyquist バリデーションのギャップを埋める。 | `/gsd-validate-phase` | primary |
|
||||
| gsd-ui-auditor | 実装済みフロントエンドコードの 6 本柱ビジュアル監査を遡及的に実施。 | `/gsd-ui-review` | primary |
|
||||
| gsd-codebase-mapper | コードベースを探索して構造化分析ドキュメントを作成。 | `/gsd-map-codebase` | primary |
|
||||
| gsd-debugger | 永続的な状態を持つ科学的手法でバグを調査。 | `/gsd-debug`, `/gsd-verify-work` | primary |
|
||||
| gsd-user-profiler | 8 つのディメンションで開発者の行動をスコアリング。 | `/gsd-profile-user` | primary |
|
||||
| gsd-doc-writer | プロジェクトドキュメントを作成・更新。 | `/gsd-docs-update` | primary |
|
||||
| gsd-doc-verifier | 生成されたドキュメントの事実に基づくクレームを検証。 | `/gsd-docs-update` | primary |
|
||||
| gsd-security-auditor | PLAN.md の脅威モデルから脅威への対策を検証。 | `/gsd-secure-phase` | primary |
|
||||
| gsd-pattern-mapper | 新しいファイルを最も近い既存の類似物にマッピングし、プランナー向けの PATTERNS.md を作成。 | `/gsd-plan-phase` (between research and planning) | advanced stub |
|
||||
| gsd-debug-session-manager | メインコンテキストをスリムに保つために、完全な `/gsd-debug` チェックポイントと継続ループを独立したコンテキストで実行。 | `/gsd-debug` | advanced stub |
|
||||
| gsd-code-reviewer | バグ、セキュリティ問題、コード品質の問題についてソースファイルをレビューし、REVIEW.md を作成。 | `/gsd-code-review` | advanced stub |
|
||||
| gsd-code-fixer | アトミックな修正コミットで REVIEW.md の指摘を適用し、REVIEW-FIX.md を作成。 | `/gsd-code-review --fix` | advanced stub |
|
||||
| gsd-ai-researcher | 選択した AI フレームワークの公式ドキュメントを実装準備済みのガイダンス（AI-SPEC.md §3–§4b）に調査。 | `/gsd-ai-integration-phase` | advanced stub |
|
||||
| gsd-domain-researcher | AI システムのドメイン専門家による評価基準と失敗モードを浮き上がらせる（AI-SPEC.md §1b）。 | `/gsd-ai-integration-phase` | advanced stub |
|
||||
| gsd-eval-planner | AI フェーズの構造化された評価戦略を設計（AI-SPEC.md §5–§7）。 | `/gsd-ai-integration-phase` | advanced stub |
|
||||
| gsd-eval-auditor | AI フェーズの評価カバレッジを遡及監査し、EVAL-REVIEW.md（COVERED/PARTIAL/MISSING）を作成。 | `/gsd-eval-review` | advanced stub |
|
||||
| gsd-framework-selector | AI/LLM フレームワークをスコアリングして推奨する 6 問以内のインタラクティブな決定マトリクス。 | `/gsd-ai-integration-phase` | advanced stub |
|
||||
| gsd-intel-updater | クエリ可能なコードベースナレッジベースとして使用される構造化インテルファイル（`.planning/intel/*.json`）を作成。 | `/gsd-map-codebase --query` | advanced stub |
|
||||
| gsd-doc-classifier | 単一の計画ドキュメントを ADR、PRD、SPEC、DOC、UNKNOWN に分類し、ドキュメントコーパスを並列処理するために生成。 | `/gsd-ingest-docs` | advanced stub |
|
||||
| gsd-doc-synthesizer | 分類された計画ドキュメントを優先規則、サイクル検出、3 バケット競合レポートで単一の統合コンテキストに合成。 | `/gsd-ingest-docs` | advanced stub |
|
||||
| msd-project-researcher | ロードマップ作成前にドメインエコシステムを調査（スタック、機能、アーキテクチャ、落とし穴）。 | `/msd-new-project`, `/msd-new-milestone` | primary |
|
||||
| msd-phase-researcher | 計画前に特定フェーズの実装アプローチを調査。 | `/msd-plan-phase` | primary |
|
||||
| msd-ui-researcher | フロントエンドフェーズ向けの UI デザインコントラクトを作成。 | `/msd-ui-phase` | primary |
|
||||
| msd-assumptions-analyzer | discuss-phase（仮定モード）向けに証拠に基づく仮定を作成。 | `discuss-phase-assumptions` workflow | primary |
|
||||
| msd-advisor-researcher | discuss-phase アドバイザーモード中に単一のグレーゾーン決定を調査。 | `discuss-phase` workflow (advisor mode) | primary |
|
||||
| msd-research-synthesizer | 並列調査エージェントの出力を統合した SUMMARY.md にまとめる。 | `/msd-new-project` | primary |
|
||||
| msd-planner | タスク分解とゴール後退型検証を含む実行可能なフェーズプランを作成。 | `/msd-plan-phase`, `/msd-quick` | primary |
|
||||
| msd-roadmapper | フェーズ分解と要件マッピングを含むプロジェクトロードマップを作成。 | `/msd-new-project` | primary |
|
||||
| msd-executor | アトミックコミットと逸脱処理を伴って MSD プランを実行。 | `/msd-execute-phase`, `/msd-quick` | primary |
|
||||
| msd-plan-checker | プランがフェーズ目標を達成できるか検証（8 つの検証ディメンション）。 | `/msd-plan-phase` (verification loop) | primary |
|
||||
| msd-integration-checker | クロスフェーズ統合とエンドツーエンドフローを検証。 | `/msd-audit-milestone` | primary |
|
||||
| msd-ui-checker | UI-SPEC.md デザインコントラクトを品質ディメンションに対して検証。 | `/msd-ui-phase` (validation loop) | primary |
|
||||
| msd-verifier | ゴール後退型分析によってフェーズ目標の達成を検証。 | `/msd-execute-phase` | primary |
|
||||
| msd-nyquist-auditor | テストを生成して Nyquist バリデーションのギャップを埋める。 | `/msd-validate-phase` | primary |
|
||||
| msd-ui-auditor | 実装済みフロントエンドコードの 6 本柱ビジュアル監査を遡及的に実施。 | `/msd-ui-review` | primary |
|
||||
| msd-codebase-mapper | コードベースを探索して構造化分析ドキュメントを作成。 | `/msd-map-codebase` | primary |
|
||||
| msd-debugger | 永続的な状態を持つ科学的手法でバグを調査。 | `/msd-debug`, `/msd-verify-work` | primary |
|
||||
| msd-user-profiler | 8 つのディメンションで開発者の行動をスコアリング。 | `/msd-profile-user` | primary |
|
||||
| msd-doc-writer | プロジェクトドキュメントを作成・更新。 | `/msd-docs-update` | primary |
|
||||
| msd-doc-verifier | 生成されたドキュメントの事実に基づくクレームを検証。 | `/msd-docs-update` | primary |
|
||||
| msd-security-auditor | PLAN.md の脅威モデルから脅威への対策を検証。 | `/msd-secure-phase` | primary |
|
||||
| msd-pattern-mapper | 新しいファイルを最も近い既存の類似物にマッピングし、プランナー向けの PATTERNS.md を作成。 | `/msd-plan-phase` (between research and planning) | advanced stub |
|
||||
| msd-debug-session-manager | メインコンテキストをスリムに保つために、完全な `/msd-debug` チェックポイントと継続ループを独立したコンテキストで実行。 | `/msd-debug` | advanced stub |
|
||||
| msd-code-reviewer | バグ、セキュリティ問題、コード品質の問題についてソースファイルをレビューし、REVIEW.md を作成。 | `/msd-code-review` | advanced stub |
|
||||
| msd-code-fixer | アトミックな修正コミットで REVIEW.md の指摘を適用し、REVIEW-FIX.md を作成。 | `/msd-code-review --fix` | advanced stub |
|
||||
| msd-ai-researcher | 選択した AI フレームワークの公式ドキュメントを実装準備済みのガイダンス（AI-SPEC.md §3–§4b）に調査。 | `/msd-ai-integration-phase` | advanced stub |
|
||||
| msd-domain-researcher | AI システムのドメイン専門家による評価基準と失敗モードを浮き上がらせる（AI-SPEC.md §1b）。 | `/msd-ai-integration-phase` | advanced stub |
|
||||
| msd-eval-planner | AI フェーズの構造化された評価戦略を設計（AI-SPEC.md §5–§7）。 | `/msd-ai-integration-phase` | advanced stub |
|
||||
| msd-eval-auditor | AI フェーズの評価カバレッジを遡及監査し、EVAL-REVIEW.md（COVERED/PARTIAL/MISSING）を作成。 | `/msd-eval-review` | advanced stub |
|
||||
| msd-framework-selector | AI/LLM フレームワークをスコアリングして推奨する 6 問以内のインタラクティブな決定マトリクス。 | `/msd-ai-integration-phase` | advanced stub |
|
||||
| msd-intel-updater | クエリ可能なコードベースナレッジベースとして使用される構造化インテルファイル（`.planning/intel/*.json`）を作成。 | `/msd-map-codebase --query` | advanced stub |
|
||||
| msd-doc-classifier | 単一の計画ドキュメントを ADR、PRD、SPEC、DOC、UNKNOWN に分類し、ドキュメントコーパスを並列処理するために生成。 | `/msd-ingest-docs` | advanced stub |
|
||||
| msd-doc-synthesizer | 分類された計画ドキュメントを優先規則、サイクル検出、3 バケット競合レポートで単一の統合コンテキストに合成。 | `/msd-ingest-docs` | advanced stub |
|
||||
|
||||
**カバレッジ注記。** `docs/AGENTS.md` は 21 のプライマリエージェントに完全なロールカードを、12 の上級エージェントに簡潔なスタブを提供します。同ファイルのエージェントツール権限サマリーはプライマリ 21 エージェントのみをカバーします。上級エージェントのツール一覧は `agents/gsd-*.md` の各エージェントフロントマターに記載されています。
|
||||
**カバレッジ注記。** `docs/AGENTS.md` は 21 のプライマリエージェントに完全なロールカードを、12 の上級エージェントに簡潔なスタブを提供します。同ファイルのエージェントツール権限サマリーはプライマリ 21 エージェントのみをカバーします。上級エージェントのツール一覧は `agents/msd-*.md` の各エージェントフロントマターに記載されています。
|
||||
|
||||
---
|
||||
|
||||
## コマンド (67 shipped)
|
||||
|
||||
完全な一覧は `commands/gsd/*.md` を参照してください。以下のグループ分けは `docs/COMMANDS.md` のセクション順に対応しています。各行にはコマンド名、コマンドのフロントマター `description:` から導出された一行の役割、ソースファイルへのリンクが含まれます。`tests/command-count-sync.test.cjs` がこの数値をファイルシステムに対して固定します。
|
||||
完全な一覧は `commands/msd/*.md` を参照してください。以下のグループ分けは `docs/COMMANDS.md` のセクション順に対応しています。各行にはコマンド名、コマンドのフロントマター `description:` から導出された一行の役割、ソースファイルへのリンクが含まれます。`tests/command-count-sync.test.cjs` がこの数値をファイルシステムに対して固定します。
|
||||
|
||||
### 名前空間メタスキル
|
||||
|
||||
@@ -66,199 +66,199 @@
|
||||
|
||||
| コマンド | 役割 | ソース |
|
||||
|----------|------|--------|
|
||||
| `/gsd-workflow` | フェーズパイプラインルーター — discuss / plan / execute / verify / phase / progress。 | [commands/gsd/ns-workflow.md](../../commands/gsd/ns-workflow.md) |
|
||||
| `/gsd-project` | プロジェクトライフサイクルルーター — マイルストーン、監査、サマリー。 | [commands/gsd/ns-project.md](../../commands/gsd/ns-project.md) |
|
||||
| `/gsd-quality` | 品質ゲートルーター — コードレビュー、デバッグ、監査、セキュリティ、eval、UI。 | [commands/gsd/ns-review.md](../../commands/gsd/ns-review.md) |
|
||||
| `/gsd-context` | コードベースインテリジェンスルーター — map、graphify、docs、learnings。 | [commands/gsd/ns-context.md](../../commands/gsd/ns-context.md) |
|
||||
| `/gsd-manage` | 管理ルーター — config、workspace、workstreams、thread、update、ship、inbox。 | [commands/gsd/ns-manage.md](../../commands/gsd/ns-manage.md) |
|
||||
| `/gsd-ideate` | 探索・キャプチャルーター — explore、sketch、spike、spec、capture。 | [commands/gsd/ns-ideate.md](../../commands/gsd/ns-ideate.md) |
|
||||
| `/msd-workflow` | フェーズパイプラインルーター — discuss / plan / execute / verify / phase / progress。 | [commands/msd/ns-workflow.md](../../commands/msd/ns-workflow.md) |
|
||||
| `/msd-project` | プロジェクトライフサイクルルーター — マイルストーン、監査、サマリー。 | [commands/msd/ns-project.md](../../commands/msd/ns-project.md) |
|
||||
| `/msd-quality` | 品質ゲートルーター — コードレビュー、デバッグ、監査、セキュリティ、eval、UI。 | [commands/msd/ns-review.md](../../commands/msd/ns-review.md) |
|
||||
| `/msd-context` | コードベースインテリジェンスルーター — map、graphify、docs、learnings。 | [commands/msd/ns-context.md](../../commands/msd/ns-context.md) |
|
||||
| `/msd-manage` | 管理ルーター — config、workspace、workstreams、thread、update、ship、inbox。 | [commands/msd/ns-manage.md](../../commands/msd/ns-manage.md) |
|
||||
| `/msd-ideate` | 探索・キャプチャルーター — explore、sketch、spike、spec、capture。 | [commands/msd/ns-ideate.md](../../commands/msd/ns-ideate.md) |
|
||||
|
||||
### コアワークフロー
|
||||
|
||||
| コマンド | 役割 | ソース |
|
||||
|----------|------|--------|
|
||||
| `/gsd-new-project` | 深いコンテキスト収集と PROJECT.md で新しいプロジェクトを初期化。 | [commands/gsd/new-project.md](../../commands/gsd/new-project.md) |
|
||||
| `/gsd-onboard` | 既存コードベースをマッピング、ドキュメント取り込み、プロジェクト設定、onboarding summary へ案内。 | [commands/gsd/onboard.md](../../commands/gsd/onboard.md) |
|
||||
| `/gsd-workspace` | GSD ワークスペースを管理 — 独立したワークスペース環境を作成（`--new`）、一覧表示（`--list`）、削除（`--remove`）。 | [commands/gsd/workspace.md](../../commands/gsd/workspace.md) |
|
||||
| `/gsd-discuss-phase` | 計画前にアダプティブな質問でフェーズコンテキストを収集。 | [commands/gsd/discuss-phase.md](../../commands/gsd/discuss-phase.md) |
|
||||
| `/gsd-mvp-phase` | フェーズを垂直 MVP スライスとして計画 — ユーザーストーリー、SPIDR 分割、その後 plan-phase。 | [commands/gsd/mvp-phase.md](../../commands/gsd/mvp-phase.md) |
|
||||
| `/gsd-spec-phase` | 反証可能な要件を持つ SPEC.md を生成するソクラテス的仕様精緻化。 | [commands/gsd/spec-phase.md](../../commands/gsd/spec-phase.md) |
|
||||
| `/gsd-ui-phase` | フロントエンドフェーズ向けの UI デザインコントラクト（UI-SPEC.md）を生成。 | [commands/gsd/ui-phase.md](../../commands/gsd/ui-phase.md) |
|
||||
| `/gsd-ai-integration-phase` | フレームワーク選択、調査、eval 計画を経て AI デザインコントラクト（AI-SPEC.md）を生成。 | [commands/gsd/ai-integration-phase.md](../../commands/gsd/ai-integration-phase.md) |
|
||||
| `/gsd-plan-phase` | 検証ループ付きの詳細なフェーズプラン（PLAN.md）を作成。 | [commands/gsd/plan-phase.md](../../commands/gsd/plan-phase.md) |
|
||||
| `/gsd-plan-review-convergence` | クロス AI プラン収束ループ — HIGH の懸念がなくなるまでレビューフィードバックで再計画（最大 3 サイクル）。 | [commands/gsd/plan-review-convergence.md](../../commands/gsd/plan-review-convergence.md) |
|
||||
| `/gsd-ultraplan-phase` | [BETA] フェーズ計画を Claude Code の ultraplan クラウドにオフロード — リモートで下書きし、ブラウザでレビューし、`/gsd-import` 経由でインポート。Claude Code のみ。 | [commands/gsd/ultraplan-phase.md](../../commands/gsd/ultraplan-phase.md) |
|
||||
| `/gsd-spike` | 使い捨ての実験でアイデアを素早くスパイク。`--wrap-up` で調査結果を永続的なスキルとしてパッケージ化。 | [commands/gsd/spike.md](../../commands/gsd/spike.md) |
|
||||
| `/gsd-sketch` | 使い捨ての HTML モックアップで UI/デザインアイデアを素早くスケッチ。`--wrap-up` で調査結果をパッケージ化。 | [commands/gsd/sketch.md](../../commands/gsd/sketch.md) |
|
||||
| `/gsd-execute-phase` | ウェーブベースの並列化でフェーズのすべてのプランを実行。 | [commands/gsd/execute-phase.md](../../commands/gsd/execute-phase.md) |
|
||||
| `/gsd-verify-work` | 自動診断付きの会話型 UAT で構築した機能を検証。 | [commands/gsd/verify-work.md](../../commands/gsd/verify-work.md) |
|
||||
| `/gsd-ship` | 検証後に PR を作成し、レビューを実行してマージ準備を行う。 | [commands/gsd/ship.md](../../commands/gsd/ship.md) |
|
||||
| `/gsd-fast` | サブエージェントや計画オーバーヘッドなしに些細なタスクをインラインで実行。 | [commands/gsd/fast.md](../../commands/gsd/fast.md) |
|
||||
| `/gsd-quick` | GSD の保証（アトミックコミット、状態追跡）付きでクイックタスクを実行し、オプションのエージェントをスキップ。 | [commands/gsd/quick.md](../../commands/gsd/quick.md) |
|
||||
| `/gsd-ui-review` | 実装済みフロントエンドコードの 6 本柱ビジュアル監査を遡及的に実施。 | [commands/gsd/ui-review.md](../../commands/gsd/ui-review.md) |
|
||||
| `/gsd-code-review` | フェーズ中に変更されたソースファイルをバグ、セキュリティ、コード品質の問題についてレビュー。`--fix` で指摘を自動適用。 | [commands/gsd/code-review.md](../../commands/gsd/code-review.md) |
|
||||
| `/gsd-eval-review` | 実行済み AI フェーズの評価カバレッジを遡及監査し、EVAL-REVIEW.md を作成。 | [commands/gsd/eval-review.md](../../commands/gsd/eval-review.md) |
|
||||
| `/msd-new-project` | 深いコンテキスト収集と PROJECT.md で新しいプロジェクトを初期化。 | [commands/msd/new-project.md](../../commands/msd/new-project.md) |
|
||||
| `/msd-onboard` | 既存コードベースをマッピング、ドキュメント取り込み、プロジェクト設定、onboarding summary へ案内。 | [commands/msd/onboard.md](../../commands/msd/onboard.md) |
|
||||
| `/msd-workspace` | MSD ワークスペースを管理 — 独立したワークスペース環境を作成（`--new`）、一覧表示（`--list`）、削除（`--remove`）。 | [commands/msd/workspace.md](../../commands/msd/workspace.md) |
|
||||
| `/msd-discuss-phase` | 計画前にアダプティブな質問でフェーズコンテキストを収集。 | [commands/msd/discuss-phase.md](../../commands/msd/discuss-phase.md) |
|
||||
| `/msd-mvp-phase` | フェーズを垂直 MVP スライスとして計画 — ユーザーストーリー、SPIDR 分割、その後 plan-phase。 | [commands/msd/mvp-phase.md](../../commands/msd/mvp-phase.md) |
|
||||
| `/msd-spec-phase` | 反証可能な要件を持つ SPEC.md を生成するソクラテス的仕様精緻化。 | [commands/msd/spec-phase.md](../../commands/msd/spec-phase.md) |
|
||||
| `/msd-ui-phase` | フロントエンドフェーズ向けの UI デザインコントラクト（UI-SPEC.md）を生成。 | [commands/msd/ui-phase.md](../../commands/msd/ui-phase.md) |
|
||||
| `/msd-ai-integration-phase` | フレームワーク選択、調査、eval 計画を経て AI デザインコントラクト（AI-SPEC.md）を生成。 | [commands/msd/ai-integration-phase.md](../../commands/msd/ai-integration-phase.md) |
|
||||
| `/msd-plan-phase` | 検証ループ付きの詳細なフェーズプラン（PLAN.md）を作成。 | [commands/msd/plan-phase.md](../../commands/msd/plan-phase.md) |
|
||||
| `/msd-plan-review-convergence` | クロス AI プラン収束ループ — HIGH の懸念がなくなるまでレビューフィードバックで再計画（最大 3 サイクル）。 | [commands/msd/plan-review-convergence.md](../../commands/msd/plan-review-convergence.md) |
|
||||
| `/msd-ultraplan-phase` | [BETA] フェーズ計画を Claude Code の ultraplan クラウドにオフロード — リモートで下書きし、ブラウザでレビューし、`/msd-import` 経由でインポート。Claude Code のみ。 | [commands/msd/ultraplan-phase.md](../../commands/msd/ultraplan-phase.md) |
|
||||
| `/msd-spike` | 使い捨ての実験でアイデアを素早くスパイク。`--wrap-up` で調査結果を永続的なスキルとしてパッケージ化。 | [commands/msd/spike.md](../../commands/msd/spike.md) |
|
||||
| `/msd-sketch` | 使い捨ての HTML モックアップで UI/デザインアイデアを素早くスケッチ。`--wrap-up` で調査結果をパッケージ化。 | [commands/msd/sketch.md](../../commands/msd/sketch.md) |
|
||||
| `/msd-execute-phase` | ウェーブベースの並列化でフェーズのすべてのプランを実行。 | [commands/msd/execute-phase.md](../../commands/msd/execute-phase.md) |
|
||||
| `/msd-verify-work` | 自動診断付きの会話型 UAT で構築した機能を検証。 | [commands/msd/verify-work.md](../../commands/msd/verify-work.md) |
|
||||
| `/msd-ship` | 検証後に PR を作成し、レビューを実行してマージ準備を行う。 | [commands/msd/ship.md](../../commands/msd/ship.md) |
|
||||
| `/msd-fast` | サブエージェントや計画オーバーヘッドなしに些細なタスクをインラインで実行。 | [commands/msd/fast.md](../../commands/msd/fast.md) |
|
||||
| `/msd-quick` | MSD の保証（アトミックコミット、状態追跡）付きでクイックタスクを実行し、オプションのエージェントをスキップ。 | [commands/msd/quick.md](../../commands/msd/quick.md) |
|
||||
| `/msd-ui-review` | 実装済みフロントエンドコードの 6 本柱ビジュアル監査を遡及的に実施。 | [commands/msd/ui-review.md](../../commands/msd/ui-review.md) |
|
||||
| `/msd-code-review` | フェーズ中に変更されたソースファイルをバグ、セキュリティ、コード品質の問題についてレビュー。`--fix` で指摘を自動適用。 | [commands/msd/code-review.md](../../commands/msd/code-review.md) |
|
||||
| `/msd-eval-review` | 実行済み AI フェーズの評価カバレッジを遡及監査し、EVAL-REVIEW.md を作成。 | [commands/msd/eval-review.md](../../commands/msd/eval-review.md) |
|
||||
|
||||
### フェーズ & マイルストーン管理
|
||||
|
||||
| コマンド | 役割 | ソース |
|
||||
|----------|------|--------|
|
||||
| `/gsd-phase` | フェーズの CRUD — ROADMAP.md でフェーズを追加（デフォルト）、挿入（`--insert`）、削除（`--remove`）、編集（`--edit`）。 | [commands/gsd/phase.md](../../commands/gsd/phase.md) |
|
||||
| `/gsd-add-tests` | UAT 基準と実装に基づいて完了したフェーズのテストを生成。 | [commands/gsd/add-tests.md](../../commands/gsd/add-tests.md) |
|
||||
| `/gsd-validate-phase` | 完了したフェーズの Nyquist バリデーションのギャップを遡及監査して埋める。 | [commands/gsd/validate-phase.md](../../commands/gsd/validate-phase.md) |
|
||||
| `/gsd-secure-phase` | 完了したフェーズの脅威への対策を遡及検証。 | [commands/gsd/secure-phase.md](../../commands/gsd/secure-phase.md) |
|
||||
| `/gsd-audit-milestone` | アーカイブ前に元の意図に対してマイルストーン完了を監査。 | [commands/gsd/audit-milestone.md](../../commands/gsd/audit-milestone.md) |
|
||||
| `/gsd-audit-uat` | 全未解決 UAT および検証項目のクロスフェーズ監査。 | [commands/gsd/audit-uat.md](../../commands/gsd/audit-uat.md) |
|
||||
| `/gsd-audit-fix` | 自律監査-修正パイプライン — 問題の発見、分類、修正、テスト、コミット。 | [commands/gsd/audit-fix.md](../../commands/gsd/audit-fix.md) |
|
||||
| `/gsd-complete-milestone` | 完了したマイルストーンをアーカイブし、次のバージョンに向けて準備。 | [commands/gsd/complete-milestone.md](../../commands/gsd/complete-milestone.md) |
|
||||
| `/gsd-new-milestone` | 新しいマイルストーンサイクルを開始 — PROJECT.md を更新して要件にルーティング。 | [commands/gsd/new-milestone.md](../../commands/gsd/new-milestone.md) |
|
||||
| `/gsd-milestone-summary` | マイルストーンアーティファクトから包括的なプロジェクトサマリーを生成。 | [commands/gsd/milestone-summary.md](../../commands/gsd/milestone-summary.md) |
|
||||
| `/gsd-cleanup` | 完了したマイルストーンから蓄積されたフェーズディレクトリをアーカイブ。 | [commands/gsd/cleanup.md](../../commands/gsd/cleanup.md) |
|
||||
| `/gsd-manager` | 1 つのターミナルから複数のフェーズを管理するインタラクティブなコマンドセンター。 | [commands/gsd/manager.md](../../commands/gsd/manager.md) |
|
||||
| `/gsd-workstreams` | 並列ワークストリームを管理 — list、create、switch、status、progress、complete、resume。 | [commands/gsd/workstreams.md](../../commands/gsd/workstreams.md) |
|
||||
| `/gsd-autonomous` | 残りのすべてのフェーズを自律的に実行 — フェーズごとに discuss → plan → execute。 | [commands/gsd/autonomous.md](../../commands/gsd/autonomous.md) |
|
||||
| `/gsd-undo` | 安全な git リバート — フェーズマニフェストを使ってフェーズまたはプランのコミットをロールバック。 | [commands/gsd/undo.md](../../commands/gsd/undo.md) |
|
||||
| `/msd-phase` | フェーズの CRUD — ROADMAP.md でフェーズを追加（デフォルト）、挿入（`--insert`）、削除（`--remove`）、編集（`--edit`）。 | [commands/msd/phase.md](../../commands/msd/phase.md) |
|
||||
| `/msd-add-tests` | UAT 基準と実装に基づいて完了したフェーズのテストを生成。 | [commands/msd/add-tests.md](../../commands/msd/add-tests.md) |
|
||||
| `/msd-validate-phase` | 完了したフェーズの Nyquist バリデーションのギャップを遡及監査して埋める。 | [commands/msd/validate-phase.md](../../commands/msd/validate-phase.md) |
|
||||
| `/msd-secure-phase` | 完了したフェーズの脅威への対策を遡及検証。 | [commands/msd/secure-phase.md](../../commands/msd/secure-phase.md) |
|
||||
| `/msd-audit-milestone` | アーカイブ前に元の意図に対してマイルストーン完了を監査。 | [commands/msd/audit-milestone.md](../../commands/msd/audit-milestone.md) |
|
||||
| `/msd-audit-uat` | 全未解決 UAT および検証項目のクロスフェーズ監査。 | [commands/msd/audit-uat.md](../../commands/msd/audit-uat.md) |
|
||||
| `/msd-audit-fix` | 自律監査-修正パイプライン — 問題の発見、分類、修正、テスト、コミット。 | [commands/msd/audit-fix.md](../../commands/msd/audit-fix.md) |
|
||||
| `/msd-complete-milestone` | 完了したマイルストーンをアーカイブし、次のバージョンに向けて準備。 | [commands/msd/complete-milestone.md](../../commands/msd/complete-milestone.md) |
|
||||
| `/msd-new-milestone` | 新しいマイルストーンサイクルを開始 — PROJECT.md を更新して要件にルーティング。 | [commands/msd/new-milestone.md](../../commands/msd/new-milestone.md) |
|
||||
| `/msd-milestone-summary` | マイルストーンアーティファクトから包括的なプロジェクトサマリーを生成。 | [commands/msd/milestone-summary.md](../../commands/msd/milestone-summary.md) |
|
||||
| `/msd-cleanup` | 完了したマイルストーンから蓄積されたフェーズディレクトリをアーカイブ。 | [commands/msd/cleanup.md](../../commands/msd/cleanup.md) |
|
||||
| `/msd-manager` | 1 つのターミナルから複数のフェーズを管理するインタラクティブなコマンドセンター。 | [commands/msd/manager.md](../../commands/msd/manager.md) |
|
||||
| `/msd-workstreams` | 並列ワークストリームを管理 — list、create、switch、status、progress、complete、resume。 | [commands/msd/workstreams.md](../../commands/msd/workstreams.md) |
|
||||
| `/msd-autonomous` | 残りのすべてのフェーズを自律的に実行 — フェーズごとに discuss → plan → execute。 | [commands/msd/autonomous.md](../../commands/msd/autonomous.md) |
|
||||
| `/msd-undo` | 安全な git リバート — フェーズマニフェストを使ってフェーズまたはプランのコミットをロールバック。 | [commands/msd/undo.md](../../commands/msd/undo.md) |
|
||||
|
||||
### セッション & ナビゲーション
|
||||
|
||||
| コマンド | 役割 | ソース |
|
||||
|----------|------|--------|
|
||||
| `/gsd-progress` | プロジェクトの進捗を確認し、コンテキストを表示して次のアクションにルーティング。`--next` で自動進行、`--do` で自由形式タスクを実行。 | [commands/gsd/progress.md](../../commands/gsd/progress.md) |
|
||||
| `/gsd-capture` | アイデア、タスク、メモ、シードをキャプチャ — todo（デフォルト）、`--note`、`--backlog`、`--seed`、または `--list` で保留中の TODO を一覧表示。 | [commands/gsd/capture.md](../../commands/gsd/capture.md) |
|
||||
| `/gsd-stats` | プロジェクト統計を表示 — フェーズ、プラン、要件、git メトリクス、タイムライン。 | [commands/gsd/stats.md](../../commands/gsd/stats.md) |
|
||||
| `/gsd-pause-work` | フェーズ途中で作業を一時停止する際にコンテキスト引き継ぎを作成。 | [commands/gsd/pause-work.md](../../commands/gsd/pause-work.md) |
|
||||
| `/gsd-resume-work` | 完全なコンテキスト復元で前のセッションから作業を再開。 | [commands/gsd/resume-work.md](../../commands/gsd/resume-work.md) |
|
||||
| `/gsd-explore` | コミットする前にアイデアを考え抜くためのソクラテス的アイデア創出とアイデアルーティング。 | [commands/gsd/explore.md](../../commands/gsd/explore.md) |
|
||||
| `/gsd-review-backlog` | バックログアイテムをレビューしてアクティブなマイルストーンに昇格。 | [commands/gsd/review-backlog.md](../../commands/gsd/review-backlog.md) |
|
||||
| `/gsd-thread` | クロスセッション作業のための永続的なコンテキストスレッドを管理。 | [commands/gsd/thread.md](../../commands/gsd/thread.md) |
|
||||
| `/msd-progress` | プロジェクトの進捗を確認し、コンテキストを表示して次のアクションにルーティング。`--next` で自動進行、`--do` で自由形式タスクを実行。 | [commands/msd/progress.md](../../commands/msd/progress.md) |
|
||||
| `/msd-capture` | アイデア、タスク、メモ、シードをキャプチャ — todo（デフォルト）、`--note`、`--backlog`、`--seed`、または `--list` で保留中の TODO を一覧表示。 | [commands/msd/capture.md](../../commands/msd/capture.md) |
|
||||
| `/msd-stats` | プロジェクト統計を表示 — フェーズ、プラン、要件、git メトリクス、タイムライン。 | [commands/msd/stats.md](../../commands/msd/stats.md) |
|
||||
| `/msd-pause-work` | フェーズ途中で作業を一時停止する際にコンテキスト引き継ぎを作成。 | [commands/msd/pause-work.md](../../commands/msd/pause-work.md) |
|
||||
| `/msd-resume-work` | 完全なコンテキスト復元で前のセッションから作業を再開。 | [commands/msd/resume-work.md](../../commands/msd/resume-work.md) |
|
||||
| `/msd-explore` | コミットする前にアイデアを考え抜くためのソクラテス的アイデア創出とアイデアルーティング。 | [commands/msd/explore.md](../../commands/msd/explore.md) |
|
||||
| `/msd-review-backlog` | バックログアイテムをレビューしてアクティブなマイルストーンに昇格。 | [commands/msd/review-backlog.md](../../commands/msd/review-backlog.md) |
|
||||
| `/msd-thread` | クロスセッション作業のための永続的なコンテキストスレッドを管理。 | [commands/msd/thread.md](../../commands/msd/thread.md) |
|
||||
|
||||
### コードベースインテリジェンス
|
||||
|
||||
| コマンド | 役割 | ソース |
|
||||
|----------|------|--------|
|
||||
| `/gsd-map-codebase` | 並列マッパーエージェントでコードベースを分析。`--fast` で軽量スキャン、`--query` でインテルクエリ。 | [commands/gsd/map-codebase.md](../../commands/gsd/map-codebase.md) |
|
||||
| `/gsd-graphify` | `.planning/graphs/` 内のプロジェクトナレッジグラフをビルド、クエリ、検査。 | [commands/gsd/graphify.md](../../commands/gsd/graphify.md) |
|
||||
| `/gsd-extract-learnings` | 完了したフェーズのアーティファクトから決定事項、教訓、パターン、驚きを抽出。 | [commands/gsd/extract-learnings.md](../../commands/gsd/extract-learnings.md) |
|
||||
| `/msd-map-codebase` | 並列マッパーエージェントでコードベースを分析。`--fast` で軽量スキャン、`--query` でインテルクエリ。 | [commands/msd/map-codebase.md](../../commands/msd/map-codebase.md) |
|
||||
| `/msd-graphify` | `.planning/graphs/` 内のプロジェクトナレッジグラフをビルド、クエリ、検査。 | [commands/msd/graphify.md](../../commands/msd/graphify.md) |
|
||||
| `/msd-extract-learnings` | 完了したフェーズのアーティファクトから決定事項、教訓、パターン、驚きを抽出。 | [commands/msd/extract-learnings.md](../../commands/msd/extract-learnings.md) |
|
||||
|
||||
### レビュー、デバッグ & リカバリー
|
||||
|
||||
| コマンド | 役割 | ソース |
|
||||
|----------|------|--------|
|
||||
| `/gsd-review` | 外部 AI CLI からフェーズプランのクロス AI ピアレビューをリクエスト。 | [commands/gsd/review.md](../../commands/gsd/review.md) |
|
||||
| `/gsd-debug` | コンテキストリセット全体で永続的な状態を持つ体系的なデバッグ。 | [commands/gsd/debug.md](../../commands/gsd/debug.md) |
|
||||
| `/gsd-forensics` | 失敗した GSD ワークフローのポストモーテム調査 — git、アーティファクト、状態を分析。 | [commands/gsd/forensics.md](../../commands/gsd/forensics.md) |
|
||||
| `/gsd-health` | 計画ディレクトリの健全性を診断し、任意で問題を修復。 | [commands/gsd/health.md](../../commands/gsd/health.md) |
|
||||
| `/gsd-import` | プロジェクト決定に対する競合検出付きで外部プランをインジェスト。 | [commands/gsd/import.md](../../commands/gsd/import.md) |
|
||||
| `/gsd-inbox` | プロジェクトテンプレートに対してすべてのオープンな GitHub イシューと PR をトリアージおよびレビュー。 | [commands/gsd/inbox.md](../../commands/gsd/inbox.md) |
|
||||
| `/msd-review` | 外部 AI CLI からフェーズプランのクロス AI ピアレビューをリクエスト。 | [commands/msd/review.md](../../commands/msd/review.md) |
|
||||
| `/msd-debug` | コンテキストリセット全体で永続的な状態を持つ体系的なデバッグ。 | [commands/msd/debug.md](../../commands/msd/debug.md) |
|
||||
| `/msd-forensics` | 失敗した MSD ワークフローのポストモーテム調査 — git、アーティファクト、状態を分析。 | [commands/msd/forensics.md](../../commands/msd/forensics.md) |
|
||||
| `/msd-health` | 計画ディレクトリの健全性を診断し、任意で問題を修復。 | [commands/msd/health.md](../../commands/msd/health.md) |
|
||||
| `/msd-import` | プロジェクト決定に対する競合検出付きで外部プランをインジェスト。 | [commands/msd/import.md](../../commands/msd/import.md) |
|
||||
| `/msd-inbox` | プロジェクトテンプレートに対してすべてのオープンな GitHub イシューと PR をトリアージおよびレビュー。 | [commands/msd/inbox.md](../../commands/msd/inbox.md) |
|
||||
|
||||
### ドキュメント、プロファイル & ユーティリティ
|
||||
|
||||
| コマンド | 役割 | ソース |
|
||||
|----------|------|--------|
|
||||
| `/gsd-docs-update` | コードベースに対して検証されたプロジェクトドキュメントを生成または更新。 | [commands/gsd/docs-update.md](../../commands/gsd/docs-update.md) |
|
||||
| `/gsd-ingest-docs` | リポジトリで混在した ADR/PRD/SPEC/DOC をスキャンし、分類・合成・競合レポートで `.planning/` セットアップをブートストラップまたはマージ。 | [commands/gsd/ingest-docs.md](../../commands/gsd/ingest-docs.md) |
|
||||
| `/gsd-profile-user` | 開発者の行動プロファイルと Claude が検出可能なアーティファクトを生成。 | [commands/gsd/profile-user.md](../../commands/gsd/profile-user.md) |
|
||||
| `/gsd-settings` | GSD ワークフロートグルとモデルプロファイルを設定。 | [commands/gsd/settings.md](../../commands/gsd/settings.md) |
|
||||
| `/gsd-config` | GSD 設定を構成 — ワークフロートグル（デフォルト）、高度なノブ（`--advanced`）、インテグレーション（`--integrations`）、またはモデルプロファイル（`--profile`）。 | [commands/gsd/config.md](../../commands/gsd/config.md) |
|
||||
| `/gsd-pr-branch` | `.planning/` コミットをフィルタリングしてクリーンな PR ブランチを作成。 | [commands/gsd/pr-branch.md](../../commands/gsd/pr-branch.md) |
|
||||
| `/gsd-surface` | サーフェスに出るスキルを切り替え — 再インストールなしでプロファイルを適用、一覧表示、またはクラスターを無効化。 | [commands/gsd/surface.md](../../commands/gsd/surface.md) |
|
||||
| `/gsd-update` | GSD を最新バージョンに更新。`--sync` でランタイム間でスキルを同期、`--reapply` でローカルパッチを再適用。 | [commands/gsd/update.md](../../commands/gsd/update.md) |
|
||||
| `/gsd-help` | 利用可能な GSD コマンドと使い方ガイドを表示。 | [commands/gsd/help.md](../../commands/gsd/help.md) |
|
||||
| `/msd-docs-update` | コードベースに対して検証されたプロジェクトドキュメントを生成または更新。 | [commands/msd/docs-update.md](../../commands/msd/docs-update.md) |
|
||||
| `/msd-ingest-docs` | リポジトリで混在した ADR/PRD/SPEC/DOC をスキャンし、分類・合成・競合レポートで `.planning/` セットアップをブートストラップまたはマージ。 | [commands/msd/ingest-docs.md](../../commands/msd/ingest-docs.md) |
|
||||
| `/msd-profile-user` | 開発者の行動プロファイルと Claude が検出可能なアーティファクトを生成。 | [commands/msd/profile-user.md](../../commands/msd/profile-user.md) |
|
||||
| `/msd-settings` | MSD ワークフロートグルとモデルプロファイルを設定。 | [commands/msd/settings.md](../../commands/msd/settings.md) |
|
||||
| `/msd-config` | MSD 設定を構成 — ワークフロートグル（デフォルト）、高度なノブ（`--advanced`）、インテグレーション（`--integrations`）、またはモデルプロファイル（`--profile`）。 | [commands/msd/config.md](../../commands/msd/config.md) |
|
||||
| `/msd-pr-branch` | `.planning/` コミットをフィルタリングしてクリーンな PR ブランチを作成。 | [commands/msd/pr-branch.md](../../commands/msd/pr-branch.md) |
|
||||
| `/msd-surface` | サーフェスに出るスキルを切り替え — 再インストールなしでプロファイルを適用、一覧表示、またはクラスターを無効化。 | [commands/msd/surface.md](../../commands/msd/surface.md) |
|
||||
| `/msd-update` | MSD を最新バージョンに更新。`--sync` でランタイム間でスキルを同期、`--reapply` でローカルパッチを再適用。 | [commands/msd/update.md](../../commands/msd/update.md) |
|
||||
| `/msd-help` | 利用可能な MSD コマンドと使い方ガイドを表示。 | [commands/msd/help.md](../../commands/msd/help.md) |
|
||||
|
||||
---
|
||||
|
||||
## ワークフロー (88 shipped)
|
||||
|
||||
完全な一覧は `gsd-core/workflows/*.md` を参照してください。ワークフローはコマンドが内部で参照する薄いオーケストレーターです。ほとんどはエンドユーザーが直接読むものではありません。以下の行は各ワークフローファイルをその役割（`<purpose>` ブロックから導出）と、該当する場合はそれを呼び出すコマンドにマッピングします。
|
||||
完全な一覧は `msd-core/workflows/*.md` を参照してください。ワークフローはコマンドが内部で参照する薄いオーケストレーターです。ほとんどはエンドユーザーが直接読むものではありません。以下の行は各ワークフローファイルをその役割（`<purpose>` ブロックから導出）と、該当する場合はそれを呼び出すコマンドにマッピングします。
|
||||
|
||||
| ワークフロー | 役割 | 呼び出し元 |
|
||||
|-------------|------|-----------|
|
||||
| `add-backlog.md` | 999.x 番号付けを使って ROADMAP.md にバックログアイテムを追加。 | `/gsd-capture --backlog` |
|
||||
| `add-phase.md` | ロードマップの現在のマイルストーン末尾に新しい整数フェーズを追加。 | `/gsd-phase` (default) |
|
||||
| `add-tests.md` | フェーズのアーティファクトに基づいて完了したフェーズのユニットテストと E2E テストを生成。 | `/gsd-add-tests` |
|
||||
| `add-todo.md` | セッション中に浮上したアイデアやタスクを構造化された todo としてキャプチャ。 | `/gsd-capture` (default) |
|
||||
| `ai-integration-phase.md` | フレームワーク選択 → AI 調査 → ドメイン調査 → eval 計画を AI-SPEC.md に統合してオーケストレーション。 | `/gsd-ai-integration-phase` |
|
||||
| `analyze-dependencies.md` | ROADMAP.md のフェーズをファイル重複とセマンティックな依存関係について分析し、`Depends on` エッジを提案。 | `/gsd-manager --analyze-deps` |
|
||||
| `audit-fix.md` | 自律監査-修正パイプライン — 監査実行、解析、分類、修正、テスト、コミット。 | `/gsd-audit-fix` |
|
||||
| `audit-milestone.md` | フェーズ検証を集約してマイルストーンが完了の定義を満たしているか検証。 | `/gsd-audit-milestone` |
|
||||
| `audit-uat.md` | UAT と検証ファイルのクロスフェーズ監査。優先順位付けされた未解決項目リストを作成。 | `/gsd-audit-uat` |
|
||||
| `autonomous.md` | マイルストーンのフェーズを自律的に進行 — 残り全部、範囲指定、または単一フェーズ。 | `/gsd-autonomous` |
|
||||
| `check-todos.md` | 保留中の TODO を一覧表示し、選択を許可してコンテキストを読み込み、適切なアクションにルーティング。 | `/gsd-capture --list` |
|
||||
| `cleanup.md` | 完了したマイルストーンから蓄積されたフェーズディレクトリをアーカイブ。 | `/gsd-cleanup` |
|
||||
| `code-review-fix.md` | gsd-code-fixer を使って REVIEW.md の問題を修正ごとのアトミックコミットで自動修正。 | `/gsd-code-review --fix` |
|
||||
| `code-review.md` | gsd-code-reviewer でフェーズのソース変更をレビュー。REVIEW.md を作成。 | `/gsd-code-review` |
|
||||
| `complete-milestone.md` | 出荷されたバージョンを完了としてマーク — MILESTONES.md エントリー、PROJECT.md の進化、タグ。 | `/gsd-complete-milestone` |
|
||||
| `diagnose-issues.md` | 並列デバッグエージェントをオーケストレーションして UAT のギャップを調査し、根本原因を特定。 | `/gsd-verify-work` (auto-diagnosis) |
|
||||
| `discuss-phase-assumptions.md` | 仮定モードの discuss — コードベースファーストの分析で実装決定を抽出。 | `/gsd-discuss-phase` (when `discuss_mode=assumptions`) |
|
||||
| `discuss-phase-power.md` | パワーユーザー discuss — すべての質問を JSON 状態ファイル + HTML UI に事前生成。 | `/gsd-discuss-phase --power` |
|
||||
| `discuss-phase.md` | 反復的なグレーゾーンの議論を通じて実装決定を抽出。 | `/gsd-discuss-phase` |
|
||||
| `mvp-phase.md` | フェーズを垂直 MVP スライスとして計画 — ユーザーストーリー、SPIDR 分割、その後 plan-phase。 | `/gsd-mvp-phase` |
|
||||
| `do.md` | ユーザーからの自由形式テキストを最も適合する GSD コマンドにルーティング。 | `/gsd-progress --do` |
|
||||
| `docs-update.md` | 正規のおよび手書きのプロジェクトドキュメントを生成、更新、検証。 | `/gsd-docs-update` |
|
||||
| `edit-phase.md` | ROADMAP.md の既存フェーズの任意フィールドを番号と位置を保ちながら編集。 | `/gsd-phase --edit` |
|
||||
| `eval-review.md` | 実装済み AI フェーズの評価カバレッジの遡及監査。 | `/gsd-eval-review` |
|
||||
| `execute-phase.md` | ウェーブベースの並列実行でフェーズのすべてのプランを実行。 | `/gsd-execute-phase` |
|
||||
| `add-backlog.md` | 999.x 番号付けを使って ROADMAP.md にバックログアイテムを追加。 | `/msd-capture --backlog` |
|
||||
| `add-phase.md` | ロードマップの現在のマイルストーン末尾に新しい整数フェーズを追加。 | `/msd-phase` (default) |
|
||||
| `add-tests.md` | フェーズのアーティファクトに基づいて完了したフェーズのユニットテストと E2E テストを生成。 | `/msd-add-tests` |
|
||||
| `add-todo.md` | セッション中に浮上したアイデアやタスクを構造化された todo としてキャプチャ。 | `/msd-capture` (default) |
|
||||
| `ai-integration-phase.md` | フレームワーク選択 → AI 調査 → ドメイン調査 → eval 計画を AI-SPEC.md に統合してオーケストレーション。 | `/msd-ai-integration-phase` |
|
||||
| `analyze-dependencies.md` | ROADMAP.md のフェーズをファイル重複とセマンティックな依存関係について分析し、`Depends on` エッジを提案。 | `/msd-manager --analyze-deps` |
|
||||
| `audit-fix.md` | 自律監査-修正パイプライン — 監査実行、解析、分類、修正、テスト、コミット。 | `/msd-audit-fix` |
|
||||
| `audit-milestone.md` | フェーズ検証を集約してマイルストーンが完了の定義を満たしているか検証。 | `/msd-audit-milestone` |
|
||||
| `audit-uat.md` | UAT と検証ファイルのクロスフェーズ監査。優先順位付けされた未解決項目リストを作成。 | `/msd-audit-uat` |
|
||||
| `autonomous.md` | マイルストーンのフェーズを自律的に進行 — 残り全部、範囲指定、または単一フェーズ。 | `/msd-autonomous` |
|
||||
| `check-todos.md` | 保留中の TODO を一覧表示し、選択を許可してコンテキストを読み込み、適切なアクションにルーティング。 | `/msd-capture --list` |
|
||||
| `cleanup.md` | 完了したマイルストーンから蓄積されたフェーズディレクトリをアーカイブ。 | `/msd-cleanup` |
|
||||
| `code-review-fix.md` | msd-code-fixer を使って REVIEW.md の問題を修正ごとのアトミックコミットで自動修正。 | `/msd-code-review --fix` |
|
||||
| `code-review.md` | msd-code-reviewer でフェーズのソース変更をレビュー。REVIEW.md を作成。 | `/msd-code-review` |
|
||||
| `complete-milestone.md` | 出荷されたバージョンを完了としてマーク — MILESTONES.md エントリー、PROJECT.md の進化、タグ。 | `/msd-complete-milestone` |
|
||||
| `diagnose-issues.md` | 並列デバッグエージェントをオーケストレーションして UAT のギャップを調査し、根本原因を特定。 | `/msd-verify-work` (auto-diagnosis) |
|
||||
| `discuss-phase-assumptions.md` | 仮定モードの discuss — コードベースファーストの分析で実装決定を抽出。 | `/msd-discuss-phase` (when `discuss_mode=assumptions`) |
|
||||
| `discuss-phase-power.md` | パワーユーザー discuss — すべての質問を JSON 状態ファイル + HTML UI に事前生成。 | `/msd-discuss-phase --power` |
|
||||
| `discuss-phase.md` | 反復的なグレーゾーンの議論を通じて実装決定を抽出。 | `/msd-discuss-phase` |
|
||||
| `mvp-phase.md` | フェーズを垂直 MVP スライスとして計画 — ユーザーストーリー、SPIDR 分割、その後 plan-phase。 | `/msd-mvp-phase` |
|
||||
| `do.md` | ユーザーからの自由形式テキストを最も適合する MSD コマンドにルーティング。 | `/msd-progress --do` |
|
||||
| `docs-update.md` | 正規のおよび手書きのプロジェクトドキュメントを生成、更新、検証。 | `/msd-docs-update` |
|
||||
| `edit-phase.md` | ROADMAP.md の既存フェーズの任意フィールドを番号と位置を保ちながら編集。 | `/msd-phase --edit` |
|
||||
| `eval-review.md` | 実装済み AI フェーズの評価カバレッジの遡及監査。 | `/msd-eval-review` |
|
||||
| `execute-phase.md` | ウェーブベースの並列実行でフェーズのすべてのプランを実行。 | `/msd-execute-phase` |
|
||||
| `execute-plan.md` | フェーズプロンプト（PLAN.md）を実行して成果サマリー（SUMMARY.md）を作成。 | `execute-phase.md` (per-plan subagent) |
|
||||
| `explore.md` | ソクラテス的アイデア創出 — 開発者を探索的な質問を通じてガイド。 | `/gsd-explore` |
|
||||
| `debug.md` | 体系的なデバッグ — サブコマンドルーティング、セッション作成、gsd-debug-session-manager への委任。 | `/gsd-debug` |
|
||||
| `extract-learnings.md` | 完了したフェーズのアーティファクトから決定事項、教訓、パターン、驚きを抽出。 | `/gsd-extract-learnings` |
|
||||
| `fast.md` | サブエージェントのオーバーヘッドなしに些細なタスクをインラインで実行。 | `/gsd-fast` |
|
||||
| `forensics.md` | 失敗したワークフローのフォレンジクス調査 — git、アーティファクト、状態分析。 | `/gsd-forensics` |
|
||||
| `explore.md` | ソクラテス的アイデア創出 — 開発者を探索的な質問を通じてガイド。 | `/msd-explore` |
|
||||
| `debug.md` | 体系的なデバッグ — サブコマンドルーティング、セッション作成、msd-debug-session-manager への委任。 | `/msd-debug` |
|
||||
| `extract-learnings.md` | 完了したフェーズのアーティファクトから決定事項、教訓、パターン、驚きを抽出。 | `/msd-extract-learnings` |
|
||||
| `fast.md` | サブエージェントのオーバーヘッドなしに些細なタスクをインラインで実行。 | `/msd-fast` |
|
||||
| `forensics.md` | 失敗したワークフローのフォレンジクス調査 — git、アーティファクト、状態分析。 | `/msd-forensics` |
|
||||
| `graduation.md` | フェーズ横断で繰り返し出現する LEARNINGS.md アイテムをクラスタリングして HITL 昇格候補を浮き上がらせる。 | `transition.md` (graduation_scan step) |
|
||||
| `health.md` | `.planning/` ディレクトリの整合性を検証し、対処可能な問題を報告。 | `/gsd-health` |
|
||||
| `help.md` | 完全な GSD Core コマンドリファレンスを表示。 | `/gsd-help` |
|
||||
| `import.md` | 既存のプロジェクト決定に対する競合検出付きで外部プランをインジェスト。 | `/gsd-import` |
|
||||
| `inbox.md` | プロジェクトのコントリビューションテンプレートに対してオープンな GitHub イシューと PR をトリアージ。 | `/gsd-inbox` |
|
||||
| `ingest-docs.md` | リポジトリで混在した計画ドキュメントをスキャンし、分類・合成して `.planning/` に競合レポート付きでブートストラップまたはマージ。 | `/gsd-ingest-docs` |
|
||||
| `insert-phase.md` | マイルストーン途中で発見された緊急作業のために小数フェーズを挿入。 | `/gsd-phase --insert` |
|
||||
| `list-phase-assumptions.md` | 計画前にフェーズに関する Claude の仮定を浮き上がらせる。 | `/gsd-discuss-phase --assumptions` |
|
||||
| `list-workspaces.md` | `~/gsd-workspaces/` 内のすべての GSD ワークスペースをステータスとともに一覧表示。 | `/gsd-workspace --list` |
|
||||
| `manager.md` | インタラクティブなマイルストーンコマンドセンター — ダッシュボード、インライン discuss、バックグラウンド plan/execute。 | `/gsd-manager` |
|
||||
| `map-codebase.md` | 並列コードベースマッパーエージェントをオーケストレーションして `.planning/codebase/` ドキュメントを作成。 | `/gsd-map-codebase` |
|
||||
| `milestone-summary.md` | マイルストーンサマリー合成 — マイルストーンアーティファクトからオンボーディングとレビューアーティファクトを作成。 | `/gsd-milestone-summary` |
|
||||
| `new-milestone.md` | 新しいマイルストーンサイクルを開始 — プロジェクトコンテキストを読み込み、目標を収集して PROJECT.md/STATE.md を更新。 | `/gsd-new-milestone` |
|
||||
| `new-project.md` | 統合新プロジェクトフロー — 質問、調査（任意）、要件、ロードマップ。 | `/gsd-new-project` |
|
||||
| `onboard.md` | Brownfield onboarding orchestration — コードベースをマップし、docs を取り込み、planning を初期化し、次のステップを要約。 | `/gsd-onboard` |
|
||||
| `new-workspace.md` | リポジトリのワークツリー/クローンと独立した `.planning/` を持つ独立したワークスペースを作成。 | `/gsd-workspace --new` |
|
||||
| `next.md` | 現在のプロジェクト状態を検出して次の論理的なステップに自動的に進む。 | `/gsd-progress --next` |
|
||||
| `health.md` | `.planning/` ディレクトリの整合性を検証し、対処可能な問題を報告。 | `/msd-health` |
|
||||
| `help.md` | 完全な MSD Core コマンドリファレンスを表示。 | `/msd-help` |
|
||||
| `import.md` | 既存のプロジェクト決定に対する競合検出付きで外部プランをインジェスト。 | `/msd-import` |
|
||||
| `inbox.md` | プロジェクトのコントリビューションテンプレートに対してオープンな GitHub イシューと PR をトリアージ。 | `/msd-inbox` |
|
||||
| `ingest-docs.md` | リポジトリで混在した計画ドキュメントをスキャンし、分類・合成して `.planning/` に競合レポート付きでブートストラップまたはマージ。 | `/msd-ingest-docs` |
|
||||
| `insert-phase.md` | マイルストーン途中で発見された緊急作業のために小数フェーズを挿入。 | `/msd-phase --insert` |
|
||||
| `list-phase-assumptions.md` | 計画前にフェーズに関する Claude の仮定を浮き上がらせる。 | `/msd-discuss-phase --assumptions` |
|
||||
| `list-workspaces.md` | `~/msd-workspaces/` 内のすべての MSD ワークスペースをステータスとともに一覧表示。 | `/msd-workspace --list` |
|
||||
| `manager.md` | インタラクティブなマイルストーンコマンドセンター — ダッシュボード、インライン discuss、バックグラウンド plan/execute。 | `/msd-manager` |
|
||||
| `map-codebase.md` | 並列コードベースマッパーエージェントをオーケストレーションして `.planning/codebase/` ドキュメントを作成。 | `/msd-map-codebase` |
|
||||
| `milestone-summary.md` | マイルストーンサマリー合成 — マイルストーンアーティファクトからオンボーディングとレビューアーティファクトを作成。 | `/msd-milestone-summary` |
|
||||
| `new-milestone.md` | 新しいマイルストーンサイクルを開始 — プロジェクトコンテキストを読み込み、目標を収集して PROJECT.md/STATE.md を更新。 | `/msd-new-milestone` |
|
||||
| `new-project.md` | 統合新プロジェクトフロー — 質問、調査（任意）、要件、ロードマップ。 | `/msd-new-project` |
|
||||
| `onboard.md` | Brownfield onboarding orchestration — コードベースをマップし、docs を取り込み、planning を初期化し、次のステップを要約。 | `/msd-onboard` |
|
||||
| `new-workspace.md` | リポジトリのワークツリー/クローンと独立した `.planning/` を持つ独立したワークスペースを作成。 | `/msd-workspace --new` |
|
||||
| `next.md` | 現在のプロジェクト状態を検出して次の論理的なステップに自動的に進む。 | `/msd-progress --next` |
|
||||
| `node-repair.md` | タスク検証が失敗した場合の自律修復オペレーター。`execute-plan` から呼び出し。 | `execute-plan.md` (recovery) |
|
||||
| `note.md` | ゼロフリクションのアイデアキャプチャ — 1 回の Write 呼び出しと 1 行の確認。 | `/gsd-capture --note` |
|
||||
| `pause-work.md` | 構造化された `.planning/HANDOFF.json` と `.continue-here.md` 引き継ぎファイルを作成。 | `/gsd-pause-work` |
|
||||
| `plan-phase.md` | 統合された調査と検証ループを含む実行可能な PLAN.md ファイルを作成。 | `/gsd-plan-phase`, `/gsd-quick` |
|
||||
| `plan-review-convergence.md` | クロス AI プラン収束ループ — HIGH の懸念がなくなるまでレビューフィードバックで再計画。 | `/gsd-plan-review-convergence` |
|
||||
| `plant-seed.md` | 先見的なアイデアをトリガー条件付きの構造化されたシードファイルとしてキャプチャ。 | `/gsd-capture --seed` |
|
||||
| `pr-branch.md` | `.planning/` コミットをフィルタリングしてプルリクエスト用のクリーンなブランチを作成。 | `/gsd-pr-branch` |
|
||||
| `profile-user.md` | 完全な開発者プロファイリングフローをオーケストレーション — 同意、セッションスキャン、プロファイル生成。 | `/gsd-profile-user` |
|
||||
| `progress.md` | 進捗レンダリング — プロジェクトコンテキスト、位置、次のアクションルーティング。 | `/gsd-progress` |
|
||||
| `quick.md` | GSD の保証付きのクイックタスク実行（アトミックコミット、状態追跡）。 | `/gsd-quick` |
|
||||
| `reapply-patches.md` | GSD 更新後にローカルの変更を再適用。 | `/gsd-update --reapply` |
|
||||
| `remove-phase.md` | ロードマップから将来のフェーズを削除し、後続フェーズを振り直し。 | `/gsd-phase --remove` |
|
||||
| `remove-workspace.md` | GSD ワークスペースを削除してワークツリーをクリーンアップ。 | `/gsd-workspace --remove` |
|
||||
| `resume-project.md` | 作業を再開 — STATE.md、HANDOFF.json、アーティファクトから完全なコンテキストを復元。 | `/gsd-resume-work` |
|
||||
| `review.md` | 外部 CLI 経由のクロス AI プランレビュー。REVIEWS.md を作成。 | `/gsd-review` |
|
||||
| `scan.md` | 迅速な単一フォーカスのコードベーススキャン — map-codebase の軽量代替。 | `/gsd-map-codebase --fast` |
|
||||
| `secure-phase.md` | 完了したフェーズの遡及的な脅威対策監査。 | `/gsd-secure-phase` |
|
||||
| `session-report.md` | セッションレポート — トークン使用量、作業サマリー、成果。 | `/gsd-pause-work --report` |
|
||||
| `settings.md` | GSD ワークフロートグルとモデルプロファイルを設定。 | `/gsd-settings`, `/gsd-config --profile` |
|
||||
| `settings-advanced.md` | GSD パワーユーザーノブを設定 — プランバウンス、タイムアウト、ブランチテンプレート、クロス AI 実行、ランタイムノブ。 | `/gsd-config --advanced` |
|
||||
| `settings-integrations.md` | サードパーティ API キー（Brave/Firecrawl/Exa）、`review.models.<cli>` CLI ルーティング、`agent_skills.<agent-type>` インジェクションをマスク済み（`****<last-4>`）表示で設定。 | `/gsd-config --integrations` |
|
||||
| `ship.md` | 検証後に PR を作成し、レビューを実行してマージ準備を行う。 | `/gsd-ship` |
|
||||
| `sketch.md` | 1 スケッチにつき 2〜3 バリアントの使い捨て HTML モックアップでデザインの方向性を探索。 | `/gsd-sketch` |
|
||||
| `sketch-wrap-up.md` | スケッチの調査結果を厳選して永続的な `sketch-findings-[project]` スキルとしてパッケージ化。 | `/gsd-sketch --wrap-up` |
|
||||
| `spec-phase.md` | 曖昧さスコアリング付きのソクラテス的仕様精緻化。SPEC.md を作成。 | `/gsd-spec-phase` |
|
||||
| `spike.md` | 集中した使い捨ての実験によって迅速に実現可能性を検証。 | `/gsd-spike` |
|
||||
| `spike-wrap-up.md` | スパイクの調査結果を厳選して永続的な `spike-findings-[project]` スキルとしてパッケージ化。 | `/gsd-spike --wrap-up` |
|
||||
| `stats.md` | プロジェクト統計レンダリング — フェーズ、プラン、要件、git メトリクス。 | `/gsd-stats` |
|
||||
| `sync-skills.md` | クロスランタイム GSD スキル同期 — ランタイムルート間で `gsd-*` スキルディレクトリを差分して適用。 | `/gsd-update --sync` |
|
||||
| `transition.md` | フェーズ境界遷移ワークフロー — ワークストリームチェック、状態進行。 | `execute-phase.md`, `/gsd-progress --next` |
|
||||
| `ui-phase.md` | gsd-ui-researcher で UI-SPEC.md デザインコントラクトを生成。 | `/gsd-ui-phase` |
|
||||
| `ui-review.md` | gsd-ui-auditor による遡及的な 6 本柱ビジュアル監査。 | `/gsd-ui-review` |
|
||||
| `ultraplan-phase.md` | [BETA] 計画を Claude Code の ultraplan クラウドにオフロードし、リモートで下書きして `/gsd-import` 経由でインポート。 | `/gsd-ultraplan-phase` |
|
||||
| `undo.md` | 安全な git リバート — フェーズマニフェストを使ってフェーズまたはプランのコミットをロールバック。 | `/gsd-undo` |
|
||||
| `thread.md` | クロスセッション作業のための永続的なコンテキストスレッドを作成、一覧表示、クローズ、または再開。 | `/gsd-thread` |
|
||||
| `update.md` | 変更履歴の表示付きで GSD を最新バージョンに更新。 | `/gsd-update` |
|
||||
| `validate-phase.md` | 完了したフェーズの Nyquist バリデーションのギャップを遡及監査して埋める。 | `/gsd-validate-phase` |
|
||||
| `verify-work.md` | 自動診断付きの会話型 UAT — UAT.md と修正プランを作成。 | `/gsd-verify-work` |
|
||||
| `note.md` | ゼロフリクションのアイデアキャプチャ — 1 回の Write 呼び出しと 1 行の確認。 | `/msd-capture --note` |
|
||||
| `pause-work.md` | 構造化された `.planning/HANDOFF.json` と `.continue-here.md` 引き継ぎファイルを作成。 | `/msd-pause-work` |
|
||||
| `plan-phase.md` | 統合された調査と検証ループを含む実行可能な PLAN.md ファイルを作成。 | `/msd-plan-phase`, `/msd-quick` |
|
||||
| `plan-review-convergence.md` | クロス AI プラン収束ループ — HIGH の懸念がなくなるまでレビューフィードバックで再計画。 | `/msd-plan-review-convergence` |
|
||||
| `plant-seed.md` | 先見的なアイデアをトリガー条件付きの構造化されたシードファイルとしてキャプチャ。 | `/msd-capture --seed` |
|
||||
| `pr-branch.md` | `.planning/` コミットをフィルタリングしてプルリクエスト用のクリーンなブランチを作成。 | `/msd-pr-branch` |
|
||||
| `profile-user.md` | 完全な開発者プロファイリングフローをオーケストレーション — 同意、セッションスキャン、プロファイル生成。 | `/msd-profile-user` |
|
||||
| `progress.md` | 進捗レンダリング — プロジェクトコンテキスト、位置、次のアクションルーティング。 | `/msd-progress` |
|
||||
| `quick.md` | MSD の保証付きのクイックタスク実行（アトミックコミット、状態追跡）。 | `/msd-quick` |
|
||||
| `reapply-patches.md` | MSD 更新後にローカルの変更を再適用。 | `/msd-update --reapply` |
|
||||
| `remove-phase.md` | ロードマップから将来のフェーズを削除し、後続フェーズを振り直し。 | `/msd-phase --remove` |
|
||||
| `remove-workspace.md` | MSD ワークスペースを削除してワークツリーをクリーンアップ。 | `/msd-workspace --remove` |
|
||||
| `resume-project.md` | 作業を再開 — STATE.md、HANDOFF.json、アーティファクトから完全なコンテキストを復元。 | `/msd-resume-work` |
|
||||
| `review.md` | 外部 CLI 経由のクロス AI プランレビュー。REVIEWS.md を作成。 | `/msd-review` |
|
||||
| `scan.md` | 迅速な単一フォーカスのコードベーススキャン — map-codebase の軽量代替。 | `/msd-map-codebase --fast` |
|
||||
| `secure-phase.md` | 完了したフェーズの遡及的な脅威対策監査。 | `/msd-secure-phase` |
|
||||
| `session-report.md` | セッションレポート — トークン使用量、作業サマリー、成果。 | `/msd-pause-work --report` |
|
||||
| `settings.md` | MSD ワークフロートグルとモデルプロファイルを設定。 | `/msd-settings`, `/msd-config --profile` |
|
||||
| `settings-advanced.md` | MSD パワーユーザーノブを設定 — プランバウンス、タイムアウト、ブランチテンプレート、クロス AI 実行、ランタイムノブ。 | `/msd-config --advanced` |
|
||||
| `settings-integrations.md` | サードパーティ API キー（Brave/Firecrawl/Exa）、`review.models.<cli>` CLI ルーティング、`agent_skills.<agent-type>` インジェクションをマスク済み（`****<last-4>`）表示で設定。 | `/msd-config --integrations` |
|
||||
| `ship.md` | 検証後に PR を作成し、レビューを実行してマージ準備を行う。 | `/msd-ship` |
|
||||
| `sketch.md` | 1 スケッチにつき 2〜3 バリアントの使い捨て HTML モックアップでデザインの方向性を探索。 | `/msd-sketch` |
|
||||
| `sketch-wrap-up.md` | スケッチの調査結果を厳選して永続的な `sketch-findings-[project]` スキルとしてパッケージ化。 | `/msd-sketch --wrap-up` |
|
||||
| `spec-phase.md` | 曖昧さスコアリング付きのソクラテス的仕様精緻化。SPEC.md を作成。 | `/msd-spec-phase` |
|
||||
| `spike.md` | 集中した使い捨ての実験によって迅速に実現可能性を検証。 | `/msd-spike` |
|
||||
| `spike-wrap-up.md` | スパイクの調査結果を厳選して永続的な `spike-findings-[project]` スキルとしてパッケージ化。 | `/msd-spike --wrap-up` |
|
||||
| `stats.md` | プロジェクト統計レンダリング — フェーズ、プラン、要件、git メトリクス。 | `/msd-stats` |
|
||||
| `sync-skills.md` | クロスランタイム MSD スキル同期 — ランタイムルート間で `msd-*` スキルディレクトリを差分して適用。 | `/msd-update --sync` |
|
||||
| `transition.md` | フェーズ境界遷移ワークフロー — ワークストリームチェック、状態進行。 | `execute-phase.md`, `/msd-progress --next` |
|
||||
| `ui-phase.md` | msd-ui-researcher で UI-SPEC.md デザインコントラクトを生成。 | `/msd-ui-phase` |
|
||||
| `ui-review.md` | msd-ui-auditor による遡及的な 6 本柱ビジュアル監査。 | `/msd-ui-review` |
|
||||
| `ultraplan-phase.md` | [BETA] 計画を Claude Code の ultraplan クラウドにオフロードし、リモートで下書きして `/msd-import` 経由でインポート。 | `/msd-ultraplan-phase` |
|
||||
| `undo.md` | 安全な git リバート — フェーズマニフェストを使ってフェーズまたはプランのコミットをロールバック。 | `/msd-undo` |
|
||||
| `thread.md` | クロスセッション作業のための永続的なコンテキストスレッドを作成、一覧表示、クローズ、または再開。 | `/msd-thread` |
|
||||
| `update.md` | 変更履歴の表示付きで MSD を最新バージョンに更新。 | `/msd-update` |
|
||||
| `validate-phase.md` | 完了したフェーズの Nyquist バリデーションのギャップを遡及監査して埋める。 | `/msd-validate-phase` |
|
||||
| `verify-work.md` | 自動診断付きの会話型 UAT — UAT.md と修正プランを作成。 | `/msd-verify-work` |
|
||||
|
||||
> **注記:** 一部のワークフローには直接ユーザー向けのコマンドがありません（例: `execute-plan.md`、`transition.md`、`node-repair.md`、`diagnose-issues.md`）— これらはオーケストレーターワークフローによって内部的に呼び出されます。
|
||||
|
||||
@@ -266,7 +266,7 @@
|
||||
|
||||
## リファレンス (62 shipped)
|
||||
|
||||
完全な一覧は `gsd-core/references/*.md` を参照してください。リファレンスはワークフローとエージェントが `@-reference` として参照する共有ナレッジドキュメントです。以下のグループ分けは [`docs/ARCHITECTURE.md`](../ARCHITECTURE.md#references-gsd-corereferencesmd) に対応します — コア、ワークフロー、思考モデルクラスター、モジュラープランナー分解。
|
||||
完全な一覧は `msd-core/references/*.md` を参照してください。リファレンスはワークフローとエージェントが `@-reference` として参照する共有ナレッジドキュメントです。以下のグループ分けは [`docs/ARCHITECTURE.md`](../ARCHITECTURE.md#references-msd-corereferencesmd) に対応します — コア、ワークフロー、思考モデルクラスター、モジュラープランナー分解。
|
||||
|
||||
### コアリファレンス
|
||||
|
||||
@@ -278,7 +278,7 @@
|
||||
| `model-profile-resolution.md` | モデル解決アルゴリズムのドキュメント。 |
|
||||
| `verification-patterns.md` | 異なるアーティファクトタイプの検証方法。 |
|
||||
| `verification-overrides.md` | アーティファクトごとの検証オーバーライドルール。 |
|
||||
| `verifier-phase-gates.md` | gsd-verifier が eager import する検証時ゲート（廃止された verify-phase ワークフローから移行、#1892）：デシジョンカバレッジ検証（#2492）、テスト品質監査、インフラストラクチャフェーズの human-verification スコープ（#2504）。 |
|
||||
| `verifier-phase-gates.md` | msd-verifier が eager import する検証時ゲート（廃止された verify-phase ワークフローから移行、#1892）：デシジョンカバレッジ検証（#2492）、テスト品質監査、インフラストラクチャフェーズの human-verification スコープ（#2504）。 |
|
||||
| `planning-config.md` | 完全な設定スキーマと動作。 |
|
||||
| `git-integration.md` | git コミット、ブランチ、履歴パターン。 |
|
||||
| `git-planning-commit.md` | 計画ディレクトリのコミット規約。 |
|
||||
@@ -286,7 +286,7 @@
|
||||
| `tdd.md` | テスト駆動開発の統合パターン。 |
|
||||
| `ui-brand.md` | ビジュアル出力フォーマットパターン。 |
|
||||
| `common-bug-patterns.md` | コードレビューと検証のための一般的なバグパターン。 |
|
||||
| `debugger-philosophy.md` | `gsd-debugger` が読み込む常緑のデバッグ規律。 |
|
||||
| `debugger-philosophy.md` | `msd-debugger` が読み込む常緑のデバッグ規律。 |
|
||||
| `mandatory-initial-read.md` | エージェントプロンプトに注入される共有の必読ボイラープレート。 |
|
||||
| `project-skills-discovery.md` | エージェントプロンプトに注入される共有のプロジェクトスキル検出ボイラープレート。 |
|
||||
|
||||
@@ -311,9 +311,9 @@
|
||||
| `thinking-partner.md` | 意思決定ポイントでの条件付き思考パートナー起動。 |
|
||||
| `autonomous-smart-discuss.md` | 自律モード向けのスマート discuss ロジック。 |
|
||||
| `ios-scaffold.md` | iOS アプリケーションスキャフォールディングパターン。 |
|
||||
| `ai-evals.md` | `/gsd-ai-integration-phase` 向けの AI 評価設計リファレンス。 |
|
||||
| `ai-frameworks.md` | `gsd-framework-selector` 向けの AI フレームワーク決定マトリクスリファレンス。 |
|
||||
| `executor-examples.md` | gsd-executor エージェントの実例。 |
|
||||
| `ai-evals.md` | `/msd-ai-integration-phase` 向けの AI 評価設計リファレンス。 |
|
||||
| `ai-frameworks.md` | `msd-framework-selector` 向けの AI フレームワーク決定マトリクスリファレンス。 |
|
||||
| `executor-examples.md` | msd-executor エージェントの実例。 |
|
||||
| `doc-conflict-engine.md` | ingest/import ワークフロー向けの共有競合検出コントラクト。 |
|
||||
| `execute-mvp-tdd.md` | MVP+TDD での execute-phase のランタイムゲートセマンティクス — タスク前の失敗テスト検証、フェーズ末尾のブロッキングレビュー。 |
|
||||
| `mvp-concepts.md` | 6 つの MVP 関連リファレンスファイルのクロスリファレンスインデックス。各ファイルの目的とどのワークフローが読み込むかをマッピング。 |
|
||||
@@ -321,7 +321,7 @@
|
||||
|
||||
### スケッチリファレンス
|
||||
|
||||
`/gsd-sketch` ワークフローとその wrap-up コンパニオンが使用するリファレンス。
|
||||
`/msd-sketch` ワークフローとその wrap-up コンパニオンが使用するリファレンス。
|
||||
|
||||
| リファレンス | 役割 |
|
||||
|-------------|------|
|
||||
@@ -332,7 +332,7 @@
|
||||
|
||||
### 思考モデルリファレンス
|
||||
|
||||
思考クラスモデル（o3、o4-mini、Gemini 2.5 Pro）を GSD ワークフローに統合するためのリファレンス。
|
||||
思考クラスモデル（o3、o4-mini、Gemini 2.5 Pro）を MSD ワークフローに統合するためのリファレンス。
|
||||
|
||||
| リファレンス | 役割 |
|
||||
|-------------|------|
|
||||
@@ -344,14 +344,14 @@
|
||||
|
||||
### モジュラープランナー分解
|
||||
|
||||
`gsd-planner` エージェントは、ランタイムの文字数制限に収めるためにコアエージェントとリファレンスモジュールに分解されます。
|
||||
`msd-planner` エージェントは、ランタイムの文字数制限に収めるためにコアエージェントとリファレンスモジュールに分解されます。
|
||||
|
||||
| リファレンス | 役割 |
|
||||
|-------------|------|
|
||||
| `planner-antipatterns.md` | プランナーのアンチパターンと具体性の例。 |
|
||||
| `planner-chunked.md` | チャンクモードの戻り形式（`## OUTLINE COMPLETE`、`## PLAN COMPLETE`）— Windows stdio ハングの緩和策。 |
|
||||
| `planner-gap-closure.md` | ギャップクロージャーモードの動作（VERIFICATION.md を読み込み、ターゲットを絞った再計画）。 |
|
||||
| `planner-reviews.md` | クロス AI レビュー統合（`/gsd-review` からの REVIEWS.md を読み込み）。 |
|
||||
| `planner-reviews.md` | クロス AI レビュー統合（`/msd-review` からの REVIEWS.md を読み込み）。 |
|
||||
| `planner-revision.md` | 反復的な精緻化のためのプラン修正パターン。 |
|
||||
| `planner-source-audit.md` | プランナーのソース監査と権威制限ルール。 |
|
||||
| `planner-mvp-mode.md` | MVP モード向けの垂直スライス計画ルール。 |
|
||||
@@ -362,26 +362,26 @@
|
||||
| `user-story-template.md` | MVP 計画向けのユーザーストーリーフォーマット — "As a / I want to / So that" の構造化フィールド。 |
|
||||
| `spidr-splitting.md` | MVP モードで大きなユーザーストーリーを処理するための SPIDR 分割ルール。 |
|
||||
|
||||
> **サブディレクトリ:** `gsd-core/references/few-shot-examples/` には、特定のエージェントから参照される追加のフューショット例（`plan-checker.md`、`verifier.md`）が含まれます。これらは 62 のトップレベルリファレンスにはカウントされません。
|
||||
> **サブディレクトリ:** `msd-core/references/few-shot-examples/` には、特定のエージェントから参照される追加のフューショット例（`plan-checker.md`、`verifier.md`）が含まれます。これらは 62 のトップレベルリファレンスにはカウントされません。
|
||||
|
||||
---
|
||||
|
||||
## CLI モジュール (81 shipped)
|
||||
|
||||
完全な一覧: `gsd-core/bin/lib/*.cjs`。
|
||||
完全な一覧: `msd-core/bin/lib/*.cjs`。
|
||||
|
||||
| モジュール | 責務 |
|
||||
|-----------|------|
|
||||
| `active-workstream-store.cjs` | ワークストリームソースの優先度と選択（CLI `--ws` > `GSD_WORKSTREAM` 環境変数 > 保存済みポインター）、名前のバリデーションと環境への伝播 |
|
||||
| `active-workstream-store.cjs` | ワークストリームソースの優先度と選択（CLI `--ws` > `MSD_WORKSTREAM` 環境変数 > 保存済みポインター）、名前のバリデーションと環境への伝播 |
|
||||
| `adr-parser.cjs` | plan-phase インジェストエクスプレスパス向けの ADR 決定パーサー。セクションの同義語を正規化し、ステータス/決定/スコープフェンスを解析して、ステータス拒否ゲートを適用 |
|
||||
| `agent-command-router.cjs` | `gsd-tools agent` 向けの薄い CJS サブコマンドルーターアダプター |
|
||||
| `artifacts.cjs` | 標準的なアーティファクトレジストリ — 既知の `.planning/` ルートファイル名。`gsd-health` W019 リントで使用 |
|
||||
| `agent-command-router.cjs` | `msd-tools agent` 向けの薄い CJS サブコマンドルーターアダプター |
|
||||
| `artifacts.cjs` | 標準的なアーティファクトレジストリ — 既知の `.planning/` ルートファイル名。`msd-health` W019 リントで使用 |
|
||||
| `audit.cjs` | 監査ディスパッチ、監査オープンセッション、監査ストレージヘルパー |
|
||||
| `check-command-router.cjs` | `gsd-tools check` 向けの薄い CJS サブコマンドルーターアダプター |
|
||||
| `check-command-router.cjs` | `msd-tools check` 向けの薄い CJS サブコマンドルーターアダプター |
|
||||
| `cjs-command-router-adapter.cjs` | マニフェストバックの CJS コマンドファミリールーター向けの共有互換アダプター |
|
||||
| `clock.cjs` | 決定論的なロックテスト向けの注入可能なクロックシーム（now/sleep） |
|
||||
| `clusters.cjs` | ランタイムサーフェスモジュール向けのスキルクラスター定義（ADR-0011 フェーズ 2） |
|
||||
| `code-review-flags.cjs` | `/gsd-code-review` 向けの型付きフラグパーサー。`parseCodeReviewFlags(argv)`（→ `{ fix, all, auto, depth, files }`）と `resolveCodeReviewWorkflow(flags)`（→ `'code-review.md' \| 'code-review-fix.md'`）をエクスポート。`--fix`/`--all`/`--auto` ルーティングの標準ディスパッチシーム |
|
||||
| `code-review-flags.cjs` | `/msd-code-review` 向けの型付きフラグパーサー。`parseCodeReviewFlags(argv)`（→ `{ fix, all, auto, depth, files }`）と `resolveCodeReviewWorkflow(flags)`（→ `'code-review.md' \| 'code-review-fix.md'`）をエクスポート。`--fix`/`--all`/`--auto` ルーティングの標準ディスパッチシーム |
|
||||
| `command-aliases.cjs` | マニフェストバックのファミリールーター向けのエイリアス/サブコマンドメタデータ |
|
||||
| `command-arg-projection.cjs` | コマンドファミリールーター間で共有される型付きフラグと位置引数のプロジェクションヘルパー |
|
||||
| `command-routing-hub.cjs` | すべてのコマンドファミリールーターのモード決定（SDK vs CJS）、エラー分類、ノースロー契約を一元化する純粋結果ディスパッチハブ（#3788） |
|
||||
@@ -390,63 +390,63 @@
|
||||
| `config.cjs` | `config.json` の読み書き、セクション初期化。`config-schema.cjs` からバリデーターをインポート |
|
||||
| `config-types.cjs` | `model_policy` 設定ブロックの TypeScript 型定義 — `ModelPolicyConfig`、`TierEntry`、`RuntimeTiers`。発行時に `src/config-types.cts` からコンパイル（ADR-457） |
|
||||
| `configuration.cjs` | 設定モジュール — 標準的な設定読み込み、レガシーキー正規化、デフォルトマージ、明示的なディスク上のマイグレーション。SDK と CJS 両方のコンシューマーの信頼できるソース |
|
||||
| `context-utilization.cjs` | `gsd-health --context` 向けの純粋なクラシファイアー — （tokensUsed, contextWindow）を 60%/70% の骨折点閾値に対する `{ percent, state }` トリアージ結果に変換（#2792） |
|
||||
| `context-utilization.cjs` | `msd-health --context` 向けの純粋なクラシファイアー — （tokensUsed, contextWindow）を 60%/70% の骨折点閾値に対する `{ percent, state }` トリアージ結果に変換（#2792） |
|
||||
| `core.cjs` | エラー処理、出力フォーマット、共通ユーティリティ、ランタイムフォールバック。planning-workspace ヘルパーの互換性再エクスポート |
|
||||
| `decisions.cjs` | CONTEXT.md の `<decisions>` ブロックを解析。数値（D-42）と英数字（D-INFRA-01）の ID を受け付け。`{id, text, category, tags, trackable}` を返す |
|
||||
| `docs.cjs` | docs-update ワークフロー初期化、Markdown スキャン、モノリポ検出 |
|
||||
| `drift.cjs` | 実行後のコードベース構造ドリフト検出器（#2003）: ファイル変更を new-dir/barrel/migration/route カテゴリに分類し、`last_mapped_commit` フロントマターをラウンドトリップ |
|
||||
| `fallow-runner.cjs` | `/gsd-code-review` 向けのファロー監査アダプター: バイナリ解決（`node_modules/.bin` 次に `PATH`）、アクション可能なバイナリ欠落エラー、構造的な調査結果の正規化 |
|
||||
| `fallow-runner.cjs` | `/msd-code-review` 向けのファロー監査アダプター: バイナリ解決（`node_modules/.bin` 次に `PATH`）、アクション可能なバイナリ欠落エラー、構造的な調査結果の正規化 |
|
||||
| `frontmatter.cjs` | YAML フロントマター CRUD 操作 |
|
||||
| `gap-checker.cjs` | 計画後のギャップ分析（#2493）: REQUIREMENTS.md + CONTEXT.md 決定事項 vs PLAN.md カバレッジレポート（`gsd-tools gap-analysis`）の統合 |
|
||||
| `graphify.cjs` | `/gsd-graphify` 向けのナレッジグラフビルド/クエリ/ステータス/差分 |
|
||||
| `gsd2-import.cjs` | `/gsd-import --from-gsd2` 向けの外部プランインジェスト |
|
||||
| `init-command-router.cjs` | `gsd-tools init` 向けの薄い CJS サブコマンドルーターアダプター |
|
||||
| `gap-checker.cjs` | 計画後のギャップ分析（#2493）: REQUIREMENTS.md + CONTEXT.md 決定事項 vs PLAN.md カバレッジレポート（`msd-tools gap-analysis`）の統合 |
|
||||
| `graphify.cjs` | `/msd-graphify` 向けのナレッジグラフビルド/クエリ/ステータス/差分 |
|
||||
| `gsd2-import.cjs` | `/msd-import --from-gsd2` 向けの外部プランインジェスト |
|
||||
| `init-command-router.cjs` | `msd-tools init` 向けの薄い CJS サブコマンドルーターアダプター |
|
||||
| `init.cjs` | 各ワークフロータイプの複合コンテキスト読み込み |
|
||||
| `install-profiles.cjs` | `--minimal` インストール向けのインストールプロファイル許可リスト + スキルステージング（#2762）。どの `gsd-*` スキル/エージェントがランタイム設定ディレクトリに配置されるかの単一ソース |
|
||||
| `install-profiles.cjs` | `--minimal` インストール向けのインストールプロファイル許可リスト + スキルステージング（#2762）。どの `msd-*` スキル/エージェントがランタイム設定ディレクトリに配置されるかの単一ソース |
|
||||
| `installer-migration-authoring.cjs` | レコードメタデータ、明示的スコープ、所有権の証拠、ランタイムコントラクト引用のインストーラーマイグレーション作成ガードレール |
|
||||
| `installer-migration-report.cjs` | インストール/更新統合向けのインストーラーマイグレーションレポートプロジェクションとブロックアクションガード |
|
||||
| `installer-migrations.cjs` | インストーラーマイグレーション計画、アーティファクト分類、インストール状態の永続化、ジャーナル化された適用、ロールバックヘルパー |
|
||||
| `intel.cjs` | `/gsd-map-codebase --query` と `gsd-intel-updater` を支えるコードベースインテルストア |
|
||||
| `learnings.cjs` | `/gsd-extract-learnings` 向けのクロスフェーズ学習抽出 |
|
||||
| `intel.cjs` | `/msd-map-codebase --query` と `msd-intel-updater` を支えるコードベースインテルストア |
|
||||
| `learnings.cjs` | `/msd-extract-learnings` 向けのクロスフェーズ学習抽出 |
|
||||
| `milestone.cjs` | マイルストーンアーカイブ、要件マーキング |
|
||||
| `model-catalog.cjs` | 共有モデルカタログ JSON の CJS アダプター。すべての CLI コンシューマーの標準ランタイムティアデフォルト、エージェントプロファイルマップ、エイリアスマップ、ルーティングメタデータをエクスポート |
|
||||
| `model-profiles.cjs` | `model-catalog.cjs` から派生した後方互換プロファイルヘルパー。独自のモデルテーブルは持たない |
|
||||
| `package-identity.cjs` | GSD の公開パッケージ座標（npm 名、bin 名、リポジトリスラッグ、変更履歴 URL、手動インストールコマンド）の生成された単一ソース。package.json から導出。更新ワーカー、`check-latest-version`、インストーラーが読み込む（#498） |
|
||||
| `phase-command-router.cjs` | `gsd-tools phase` 向けの薄い CJS サブコマンドルーターアダプター |
|
||||
| `package-identity.cjs` | MSD の公開パッケージ座標（npm 名、bin 名、リポジトリスラッグ、変更履歴 URL、手動インストールコマンド）の生成された単一ソース。package.json から導出。更新ワーカー、`check-latest-version`、インストーラーが読み込む（#498） |
|
||||
| `phase-command-router.cjs` | `msd-tools phase` 向けの薄い CJS サブコマンドルーターアダプター |
|
||||
| `phase-lifecycle.cjs` | フェーズライフサイクル SDK ハンドラーから抽出された純粋計算フェーズライフサイクルヘルパー |
|
||||
| `phase.cjs` | フェーズディレクトリ操作、小数番号付け、プランインデックス化 |
|
||||
| `phases-command-router.cjs` | `gsd-tools phases` 向けの薄い CJS サブコマンドルーターアダプター |
|
||||
| `phases-command-router.cjs` | `msd-tools phases` 向けの薄い CJS サブコマンドルーターアダプター |
|
||||
| `plan-scan.cjs` | フラットおよびネストされたレイアウトでプランとサマリーファイルを検出するための標準フェーズプランスキャナー（k014） |
|
||||
| `planning-workspace.cjs` | 計画パス/ワークストリームシーム（`planningDir`、`planningPaths`、アクティブワークストリームルーティング、`.planning/.lock` オーケストレーション） |
|
||||
| `project-root.cjs` | 4 つのヒューリスティック（独自の `.planning/` ガード、`sub_repos` 設定、`multiRepo` フラグ、`.git` ヒューリスティック）を使って開始ディレクトリからプロジェクトルートを解決 |
|
||||
| `profile-output.cjs` | プロファイルレンダリング、USER-PROFILE.md と dev-preferences.md の生成 |
|
||||
| `profile-pipeline.cjs` | ユーザー行動プロファイリングデータパイプライン、セッションファイルスキャン |
|
||||
| `prompt-budget.cjs` | レビュープロンプト向けの純粋なトークンバジェット計算 — トークンを見積もり、決定論的なトリム優先度を適用（PROJECT.md の head 縮小、比例プラン切り捨て、コンテキスト/調査/要件の削除、ハードフェイルガード）。`review.max_prompt_tokens` 向けの構造化メタデータを返す（#3081） |
|
||||
| `review-reviewer-selection.cjs` | `/gsd-review` デフォルトレビュアーポリシーと優先度向けのレビュアー選択/正規化ヘルパー |
|
||||
| `roadmap-command-router.cjs` | `gsd-tools roadmap` 向けの薄い CJS サブコマンドルーターアダプター |
|
||||
| `review-reviewer-selection.cjs` | `/msd-review` デフォルトレビュアーポリシーと優先度向けのレビュアー選択/正規化ヘルパー |
|
||||
| `roadmap-command-router.cjs` | `msd-tools roadmap` 向けの薄い CJS サブコマンドルーターアダプター |
|
||||
| `roadmap-upgrade.cjs` | レガシーの `Phase N` エントリーをマイルストーンプレフィックス付きの `Phase M-NN` 規約に変換するマイグレーションツール。`computeMigrationPlan` + `applyMigration`（デフォルトのドライランとアトミックロールバック付き） |
|
||||
| `roadmap.cjs` | ROADMAP.md 解析、フェーズ抽出、プラン進捗 |
|
||||
| `runtime-artifact-layout.cjs` | ランタイムアーティファクトレイアウトモジュール — サポートされている各ランタイムのアーティファクトディレクトリ形状（コマンド、エージェント、スキル）を解決。ランタイムごとのアーティファクト配置の単一ソース（#3663） |
|
||||
| `runtime-name-policy.cjs` | ランタイム名正規化ポリシー — パス構築と表示に使用されるランタイム識別子の標準トークンサニタイゼーション |
|
||||
| `runtime-homes.cjs` | 標準ランタイム → グローバル設定/スキルディレクトリマッピング。Hermes ネストレイアウトと Cline ルールベース除外を含む全 15 ランタイムの一流サポート（#3126） |
|
||||
| `runtime-slash.cjs` | ランタイム対応スラッシュコマンドフォーマッター — ユーザー向け出力と永続化されたアーティファクトで `/gsd-<cmd>`（スキルベースのランタイム）と `$gsd-<cmd>`（codex）を出力する単一ソース（#3584） |
|
||||
| `runtime-slash.cjs` | ランタイム対応スラッシュコマンドフォーマッター — ユーザー向け出力と永続化されたアーティファクトで `/msd-<cmd>`（スキルベースのランタイム）と `$msd-<cmd>`（codex）を出力する単一ソース（#3584） |
|
||||
| `schema-detect.cjs` | ORM パターンのスキーマドリフト検出（Prisma、Drizzle、Supabase、TypeORM、Payload）。`detectSchemaFiles`、`detectSchemaOrm`、`checkSchemaDrift`、`SCHEMA_PATTERNS`、`ORM_INFO` をエクスポート |
|
||||
| `secrets.cjs` | インテグレーションキー向けのシークレット設定マスキング規約（`****<last-4>`）。`SECRET_CONFIG_KEYS`、`isSecretKey`、`maskSecret`、`maskIfSecret` をエクスポート |
|
||||
| `semver-compare.cjs` | 共有 semver 比較ポリシーヘルパー（`compareSemverCore`、stable-triplet バリデーション、正規化タプル解析）。更新チェックフック、statusline dev-install 検出、changeset 抽出範囲ロジックで使用（#10） |
|
||||
| `security.cjs` | パストラバーサル防止、プロンプトインジェクション検出、安全な JSON/シェルヘルパー |
|
||||
| `shell-command-projection.cjs` | マネージドフック直列化のためのランタイム対応シェルコマンドプロジェクション: ランタイム/プラットフォームによる PowerShell コールオペレーターの使用を決定し、Windows スクリプトパストークンを正規化 |
|
||||
| `state-command-router.cjs` | `gsd-tools state` 向けの薄い CJS サブコマンドルーターアダプター |
|
||||
| `state-command-router.cjs` | `msd-tools state` 向けの薄い CJS サブコマンドルーターアダプター |
|
||||
| `state.cjs` | STATE.md 解析、更新、進行、メトリクス |
|
||||
| `state-document.cjs` | 純粋な STATE.md フィールド抽出、置換、ステータス正規化、進捗計算トランスフォーム |
|
||||
| `surface.cjs` | ランタイムサーフェスモジュール — インストール時プロファイルマーカーとは独立してランタイムの有効/無効サーフェス状態を管理（ADR-0011 フェーズ 2） |
|
||||
| `task-command-router.cjs` | `gsd-tools task` 向けの薄い CJS サブコマンドルーターアダプター |
|
||||
| `task-command-router.cjs` | `msd-tools task` 向けの薄い CJS サブコマンドルーターアダプター |
|
||||
| `template.cjs` | 変数置換によるテンプレート選択と穴埋め |
|
||||
| `uat.cjs` | UAT ファイル解析、検証負債追跡、audit-uat サポート |
|
||||
| `ui-safety-gate.cjs` | シェルフリーのワード境界 UI トークン検出器（#3706、#3718）。フェーズセクションテキストを標準入力から読み込み、0（UI 発見）または 1（UI なし）で終了。GSD インストーラーが `$RUNTIME_DIR` に配布するために `gsd-core/bin/lib/` にもデプロイ（#448） |
|
||||
| `update-context.cjs` | `/gsd-update` 向けの純粋なインストールコンテキストリゾルバー — ランタイム/スコープ/設定ディレクトリ/バージョン検出（LOCAL/GLOBAL/UNKNOWN）。update.md bash からポート。`gsd-tools update-context` を支える（#498） |
|
||||
| `validate-command-router.cjs` | `gsd-tools validate` 向けの薄い CJS サブコマンドルーターアダプター |
|
||||
| `ui-safety-gate.cjs` | シェルフリーのワード境界 UI トークン検出器（#3706、#3718）。フェーズセクションテキストを標準入力から読み込み、0（UI 発見）または 1（UI なし）で終了。MSD インストーラーが `$RUNTIME_DIR` に配布するために `msd-core/bin/lib/` にもデプロイ（#448） |
|
||||
| `update-context.cjs` | `/msd-update` 向けの純粋なインストールコンテキストリゾルバー — ランタイム/スコープ/設定ディレクトリ/バージョン検出（LOCAL/GLOBAL/UNKNOWN）。update.md bash からポート。`msd-tools update-context` を支える（#498） |
|
||||
| `validate-command-router.cjs` | `msd-tools validate` 向けの薄い CJS サブコマンドルーターアダプター |
|
||||
| `validate.cjs` | 純粋なフェーズバリアント正規化ヘルパー（`phaseVariants`、`buildRoadmapPhaseVariants`、`buildNotStartedPhaseVariants`）。`verify.cjs` の W006/W007 チェックで使用。I/O なし、非同期なし |
|
||||
| `verify-command-router.cjs` | `gsd-tools verify` 向けの薄い CJS サブコマンドルーターアダプター |
|
||||
| `verify-command-router.cjs` | `msd-tools verify` 向けの薄い CJS サブコマンドルーターアダプター |
|
||||
| `verify.cjs` | プラン構造、フェーズ完全性、参照、コミットバリデーション |
|
||||
| `workstream-inventory-builder.cjs` | 純粋なワークストリームインベントリプロジェクションビルダー |
|
||||
| `workstream-inventory.cjs` | 共有ワークストリームインベントリプロジェクション: 状態フィールド、フェーズ/プラン/サマリーカウント、ロードマップフェーズカウント、アクティブマーカー — 純粋なプロジェクションを `workstream-inventory-builder.cjs` に委任する薄いオーケストレーター |
|
||||
@@ -464,23 +464,23 @@
|
||||
|
||||
| フック | イベント | 目的 |
|
||||
|--------|---------|------|
|
||||
| `gsd-statusline.js` | `statusLine` | モデル、タスク、ディレクトリ、コンテキスト使用率を表示 |
|
||||
| `gsd-context-monitor.js` | `PostToolUse` / `AfterTool` | 残量 35%/25% でエージェント向けコンテキスト警告を注入 |
|
||||
| `gsd-check-update.js` | `SessionStart` | 新しい GSD バージョンのバックグラウンドチェック |
|
||||
| `gsd-check-update-worker.js` | (worker) | check-update のバックグラウンドワーカーヘルパー |
|
||||
| `gsd-update-banner.js` | `SessionStart` | GSD statusline を使用していない場合に更新の可用性を表示するオプトインバナー（PR #2795） |
|
||||
| `gsd-prompt-guard.js` | `PreToolUse` | `.planning/` への書き込みのプロンプトインジェクションパターンをスキャン（アドバイザリー） |
|
||||
| `gsd-workflow-guard.js` | `PreToolUse` | GSD ワークフローコンテキスト外のファイル編集を検出（アドバイザリー、オプトイン） |
|
||||
| `gsd-read-guard.js` | `PreToolUse` | 未読ファイルへの Edit/Write を防ぐアドバイザリーガード |
|
||||
| `gsd-read-injection-scanner.js` | `PostToolUse` | ツール Read 結果のプロンプトインジェクションパターンをスキャン（v1.36+、PR #2201） |
|
||||
| `gsd-worktree-path-guard.js` | `PreToolUse` | ワークツリールート外の絶対パスを持つ Edit/Write/MultiEdit をハードブロック（PR #579、#260） |
|
||||
| `gsd-agent-isolation-guard.js` | `PreToolUse` | プロジェクトの解決済みディスパッチ分離が `harness-worktree` の場合、ハーネス分離パラメータを欠く executor の `Agent()` ディスパッチをハードブロック（#3045） |
|
||||
| `gsd-write-guard.js` | `PreToolUse` | キュレーションされた `.planning/` アーティファクト（ROADMAP.md、マイルストーンロードマップ、STATE.md）を大幅に縮小するファイル全体の `Write` をハードブロック。使い捨てセンチネル `.planning/.gsd-allow-shrink`（ワークフローステップ）または `GSD_ALLOW_PLANNING_SHRINK=1`（対話時）でオーバーライド（#2255、#973 の修正 3） |
|
||||
| `gsd-secret-read-guard.js` | `PreToolUse` | Read / Grep / Bash による `.env`、`.env.<suffix>`（`.env.example` などのテンプレートは除外）、`.secrets` の読み取りをハードブロック。インストーラが書き込んでいた `Read(.env*)` の deny ルールを置き換える（#4221） |
|
||||
| `gsd-session-state.sh` | `SessionStart` | シェルベースランタイム向けのセッション状態追跡 |
|
||||
| `gsd-validate-commit.sh` | `PreToolUse` | Conventional Commit 適用のためのコミットバリデーション |
|
||||
| `gsd-phase-boundary.sh` | `PostToolUse` | ワークフロー遷移のためのフェーズ境界検出 |
|
||||
| `gsd-graphify-update.sh` | `PostToolUse` | メイン HEAD が進んだ後にナレッジグラフを自動再ビルド（オプトイン、デフォルトオフ — #3347） |
|
||||
| `msd-statusline.js` | `statusLine` | モデル、タスク、ディレクトリ、コンテキスト使用率を表示 |
|
||||
| `msd-context-monitor.js` | `PostToolUse` / `AfterTool` | 残量 35%/25% でエージェント向けコンテキスト警告を注入 |
|
||||
| `msd-check-update.js` | `SessionStart` | 新しい MSD バージョンのバックグラウンドチェック |
|
||||
| `msd-check-update-worker.js` | (worker) | check-update のバックグラウンドワーカーヘルパー |
|
||||
| `msd-update-banner.js` | `SessionStart` | MSD statusline を使用していない場合に更新の可用性を表示するオプトインバナー（PR #2795） |
|
||||
| `msd-prompt-guard.js` | `PreToolUse` | `.planning/` への書き込みのプロンプトインジェクションパターンをスキャン（アドバイザリー） |
|
||||
| `msd-workflow-guard.js` | `PreToolUse` | MSD ワークフローコンテキスト外のファイル編集を検出（アドバイザリー、オプトイン） |
|
||||
| `msd-read-guard.js` | `PreToolUse` | 未読ファイルへの Edit/Write を防ぐアドバイザリーガード |
|
||||
| `msd-read-injection-scanner.js` | `PostToolUse` | ツール Read 結果のプロンプトインジェクションパターンをスキャン（v1.36+、PR #2201） |
|
||||
| `msd-worktree-path-guard.js` | `PreToolUse` | ワークツリールート外の絶対パスを持つ Edit/Write/MultiEdit をハードブロック（PR #579、#260） |
|
||||
| `msd-agent-isolation-guard.js` | `PreToolUse` | プロジェクトの解決済みディスパッチ分離が `harness-worktree` の場合、ハーネス分離パラメータを欠く executor の `Agent()` ディスパッチをハードブロック（#3045） |
|
||||
| `msd-write-guard.js` | `PreToolUse` | キュレーションされた `.planning/` アーティファクト（ROADMAP.md、マイルストーンロードマップ、STATE.md）を大幅に縮小するファイル全体の `Write` をハードブロック。使い捨てセンチネル `.planning/.msd-allow-shrink`（ワークフローステップ）または `MSD_ALLOW_PLANNING_SHRINK=1`（対話時）でオーバーライド（#2255、#973 の修正 3） |
|
||||
| `msd-secret-read-guard.js` | `PreToolUse` | Read / Grep / Bash による `.env`、`.env.<suffix>`（`.env.example` などのテンプレートは除外）、`.secrets` の読み取りをハードブロック。インストーラが書き込んでいた `Read(.env*)` の deny ルールを置き換える（#4221） |
|
||||
| `msd-session-state.sh` | `SessionStart` | シェルベースランタイム向けのセッション状態追跡 |
|
||||
| `msd-validate-commit.sh` | `PreToolUse` | Conventional Commit 適用のためのコミットバリデーション |
|
||||
| `msd-phase-boundary.sh` | `PostToolUse` | ワークフロー遷移のためのフェーズ境界検出 |
|
||||
| `msd-graphify-update.sh` | `PostToolUse` | メイン HEAD が進んだ後にナレッジグラフを自動再ビルド（オプトイン、デフォルトオフ — #3347） |
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# GSD Core ドキュメント
|
||||
# MSD Core ドキュメント
|
||||
|
||||
ドキュメントは 4 つの象限で構成されています。**チュートリアル**は実践で学ぶ、**ハウツーガイド**は特定のタスクを解決する、**リファレンス**は信頼できる情報を示す、**解説**はコンセプトと設計上の決定を探求する。
|
||||
|
||||
@@ -9,7 +9,7 @@
|
||||
## チュートリアル
|
||||
|
||||
- [はじめてのプロジェクト](tutorials/your-first-project.md) — インストールから最初のフェーズ出荷まで、確実な一本道
|
||||
- [既存コードベースのオンボーディング](tutorials/onboarding-an-existing-codebase.md) — ブラウンフィールドのリポジトリに GSD Core を導入する
|
||||
- [既存コードベースのオンボーディング](tutorials/onboarding-an-existing-codebase.md) — ブラウンフィールドのリポジトリに MSD Core を導入する
|
||||
|
||||
---
|
||||
|
||||
@@ -21,17 +21,17 @@
|
||||
- [フェーズを実行する](how-to/execute-a-phase.md) — 新鮮なコンテキストのサブエージェントで並列ウェーブとして計画を実行する
|
||||
- [検証と出荷](how-to/verify-and-ship.md) — 完成した作業を確認し、障害を診断し、PR を作成する
|
||||
- [フェーズを自律的に実行する](how-to/run-phases-autonomously.md) — 無人フェーズ実行に自律モードを使用する
|
||||
- [クイックおよびファストタスクを処理する](how-to/handle-quick-and-fast-tasks.md) — フェーズループ外のアドホック作業に `/gsd-quick` と `/gsd-fast` を使用する
|
||||
- [クイックおよびファストタスクを処理する](how-to/handle-quick-and-fast-tasks.md) — フェーズループ外のアドホック作業に `/msd-quick` と `/msd-fast` を使用する
|
||||
- [モデルプロファイルを設定する](how-to/configure-model-profiles.md) — クオリティ・バランス・バジェットのモデルティア間を切り替える
|
||||
- [クロス AI レビューをセットアップする](how-to/set-up-cross-ai-review.md) — プライマリエージェントが生成したコードをレビューする 2 番目の AI を設定する
|
||||
- [ワークストリームで並列作業する](how-to/work-in-parallel-with-workstreams.md) — ワークストリームを使って独立した作業ラインを同時に実行する
|
||||
- [ワークスペースで作業を隔離する](how-to/isolate-work-with-workspaces.md) — ワークスペースを使って実験的またはリスクのある変更をサンドボックス化する
|
||||
- [失敗した実行をデバッグする](how-to/debug-a-failed-execution.md) — 壊れたまたは不完全なフェーズ実行を診断・回復する
|
||||
- [スパイクとスケッチ](how-to/spike-and-sketch.md) — 計画を確定する前の探索的作業に `/gsd-spike` と `/gsd-sketch` を使用する
|
||||
- [スパイクとスケッチ](how-to/spike-and-sketch.md) — 計画を確定する前の探索的作業に `/msd-spike` と `/msd-sketch` を使用する
|
||||
- [UI フェーズを設計する](how-to/design-a-ui-phase.md) — フロントエンドおよびビジュアル作業に UI フェーズループを使用する
|
||||
- [トラッカーイシューから GSD を動かす](how-to/drive-gsd-from-a-tracker-issue.md) — GitHub、Linear、または Jira のイシューからフェーズを開始する
|
||||
- [GSD 2 から移行する](how-to/migrate-from-gsd-2.md) — 既存の GSD 2 プロジェクトを GSD Core にアップグレードする
|
||||
- [GSD をアップデートする](how-to/update-gsd.md) — インストーラーを再実行して最新リリースを取得する
|
||||
- [トラッカーイシューから MSD を動かす](how-to/drive-msd-from-a-tracker-issue.md) — GitHub、Linear、または Jira のイシューからフェーズを開始する
|
||||
- [GSD 2 から移行する](how-to/migrate-from-gsd-2.md) — 既存の GSD 2 プロジェクトを MSD Core にアップグレードする
|
||||
- [MSD をアップデートする](how-to/update-msd.md) — インストーラーを再実行して最新リリースを取得する
|
||||
- [回復とトラブルシューティング](how-to/recover-and-troubleshoot.md) — よくある問題を修正し、コンテキストを再構築し、アンインストールする
|
||||
|
||||
---
|
||||
@@ -40,7 +40,7 @@
|
||||
|
||||
- [コマンド](COMMANDS.md) — フラグと例を含むすべてのコマンド
|
||||
- [設定](CONFIGURATION.md) — 完全な設定スキーマ、モデルプロファイル、Git ブランチ戦略
|
||||
- [CLI ツール](CLI-TOOLS.md) — ワークフローとエージェント向け `gsd-tools.cjs` プログラマティック API
|
||||
- [CLI ツール](CLI-TOOLS.md) — ワークフローとエージェント向け `msd-tools.cjs` プログラマティック API
|
||||
- [機能](FEATURES.md) — 完全な機能インデックス
|
||||
- [インベントリ](INVENTORY.md) — インストール済みスキルとサーフェスマップ
|
||||
- [STATE.md スキーマ](reference/state-md.md) — `.planning/STATE.md` のフィールド別リファレンス
|
||||
@@ -52,14 +52,14 @@
|
||||
|
||||
## 解説
|
||||
|
||||
- [コンテキストエンジニアリング](explanation/context-engineering.md) — コンテキストの腐敗がどのように形成され、GSD Core がどのように防ぐか
|
||||
- [コンテキストエンジニアリング](explanation/context-engineering.md) — コンテキストの腐敗がどのように形成され、MSD Core がどのように防ぐか
|
||||
- [フェーズループ](explanation/the-phase-loop.md) — Discuss → Plan → Execute → Verify → Ship サイクルの設計理念
|
||||
- [マルチエージェントオーケストレーション](explanation/multi-agent-orchestration.md) — サブエージェントがどのように生成・スコープ設定・調整されるか
|
||||
- [セキュリティモデル](explanation/security-model.md) — 信頼境界、パーミッション、安全な自動化
|
||||
- [アーキテクチャ](ARCHITECTURE.md) — システムアーキテクチャ、エージェントモデル、データフロー
|
||||
- [ディスカスモード](workflow-discuss-mode.md) — `/gsd-discuss-phase` の assumptions モードと interview モード
|
||||
- [ディスカスモード](workflow-discuss-mode.md) — `/msd-discuss-phase` の assumptions モードと interview モード
|
||||
- [コンテキストモニタリング](context-monitor.md) — コンテキストウィンドウ監視フックのアーキテクチャ
|
||||
- [イシュー駆動オーケストレーション](issue-driven-orchestration.md) — 既存のプリミティブを使ってトラッカーイシューから GSD を動かすレシピ
|
||||
- [イシュー駆動オーケストレーション](issue-driven-orchestration.md) — 既存のプリミティブを使ってトラッカーイシューから MSD を動かすレシピ
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# GSD ユーザーガイド
|
||||
# MSD ユーザーガイド
|
||||
|
||||
GSD Core のナラティブ形式の補足ガイドです。まずここで全体像を把握し、各専用ドキュメントへのリンクをたどってください。
|
||||
MSD Core のナラティブ形式の補足ガイドです。まずここで全体像を把握し、各専用ドキュメントへのリンクをたどってください。
|
||||
|
||||
> **GSD Core のドキュメントは [Diataxis](https://diataxis.fr) の体系で整理されています。**
|
||||
> **MSD Core のドキュメントは [Diataxis](https://diataxis.fr) の体系で整理されています。**
|
||||
> 目的別にブラウズ: [チュートリアル](README.md#tutorials) · [ハウツーガイド](README.md#how-to-guides) · [リファレンス](README.md#reference) · [解説](README.md#explanation) · [ドキュメント索引](README.md)
|
||||
|
||||
---
|
||||
@@ -10,7 +10,7 @@ GSD Core のナラティブ形式の補足ガイドです。まずここで全
|
||||
## 目次
|
||||
|
||||
- [スラッシュコマンドの形式](#slash-command-forms-hyphen-vs-colon)
|
||||
- [名前空間ルーティング入門](#namespace-routing-primer-gsdnamespace-v140)
|
||||
- [名前空間ルーティング入門](#namespace-routing-primer-msdnamespace-v140)
|
||||
- [プロジェクトライフサイクル概要](#project-lifecycle-overview)
|
||||
- [ワークフロー図](#workflow-diagrams)
|
||||
- [UI デザインコントラクト](#ui-design-contract)
|
||||
@@ -24,41 +24,41 @@ GSD Core のナラティブ形式の補足ガイドです。まずここで全
|
||||
- [プロジェクトファイル構造](#project-file-structure)
|
||||
- [関連](#related)
|
||||
|
||||
GitHub / Linear / Jira のイシューから GSD を直接操作する方法については、
|
||||
GitHub / Linear / Jira のイシューから MSD を直接操作する方法については、
|
||||
[Issue-driven orchestration](issue-driven-orchestration.md) ガイドを参照してください。
|
||||
トラッカーのイシューを、既存の GSD プリミティブを用いた workspace → discuss → plan →
|
||||
トラッカーのイシューを、既存の MSD プリミティブを用いた workspace → discuss → plan →
|
||||
execute → verify → review → ship ループにマッピングするレシピです。
|
||||
|
||||
---
|
||||
|
||||
## スラッシュコマンドの形式 {#slash-command-forms-hyphen-vs-colon}
|
||||
|
||||
GSD はサポートされているすべてのランタイムに **同一のスキルセット** を提供しており、ハイフン形式のスラッシュ表記を使用します：
|
||||
MSD はサポートされているすべてのランタイムに **同一のスキルセット** を提供しており、ハイフン形式のスラッシュ表記を使用します：
|
||||
|
||||
- **ハイフン形式** — `/gsd-command-name` — Claude Code、Copilot、OpenCode、Kilo、Cursor、Windsurf、Augment、Antigravity、Trae で使用されます。
|
||||
- **ハイフン形式** — `/msd-command-name` — Claude Code、Copilot、OpenCode、Kilo、Cursor、Windsurf、Augment、Antigravity、Trae で使用されます。
|
||||
|
||||
インストーラーが、対象とする各ランタイムのコマンドディレクトリにこの形式を書き込みます。
|
||||
|
||||
## 名前空間ルーティング入門（`gsd:<namespace>`、v1.40） {#namespace-routing-primer-gsdnamespace-v140}
|
||||
## 名前空間ルーティング入門（`msd:<namespace>`、v1.40） {#namespace-routing-primer-msdnamespace-v140}
|
||||
|
||||
v1.40 では、階層的ルーティングへのファーストステージエントリーポイントとして **6 つの名前空間メタスキル** が追加されました。これにより、スキル一覧のトークンコストを低く抑えながら（86 スキルのフラットな列挙の約 2,150 トークンに対し、6 つのルーターで約 120 トークン）、各具体的なサブスキルは直接呼び出し可能なままです。各名前空間ルーターの本文には、ユーザーの意図を正しい具体的サブスキルにマッピングするルーティングテーブルが含まれています。
|
||||
|
||||
| 名前空間 | ルーター | ルーティング先 |
|
||||
|-----------|--------|-----------|
|
||||
| フェーズパイプライン | `/gsd-workflow` | discuss / plan / execute / verify / phase / progress |
|
||||
| プロジェクトライフサイクル | `/gsd-project` | マイルストーン、監査、サマリー |
|
||||
| 品質ゲート | `/gsd-quality` | コードレビュー、デバッグ、監査、セキュリティ、評価、UI |
|
||||
| コードベースインテリジェンス | `/gsd-context` | マップ、グラフ化、ドキュメント、学習内容 |
|
||||
| 管理 | `/gsd-manage` | 設定、ワークスペース、ワークストリーム、スレッド、更新、ship、受信トレイ |
|
||||
| 探索とキャプチャ | `/gsd-ideate` | 探索、スケッチ、スパイク、仕様、キャプチャ |
|
||||
| フェーズパイプライン | `/msd-workflow` | discuss / plan / execute / verify / phase / progress |
|
||||
| プロジェクトライフサイクル | `/msd-project` | マイルストーン、監査、サマリー |
|
||||
| 品質ゲート | `/msd-quality` | コードレビュー、デバッグ、監査、セキュリティ、評価、UI |
|
||||
| コードベースインテリジェンス | `/msd-context` | マップ、グラフ化、ドキュメント、学習内容 |
|
||||
| 管理 | `/msd-manage` | 設定、ワークスペース、ワークストリーム、スレッド、更新、ship、受信トレイ |
|
||||
| 探索とキャプチャ | `/msd-ideate` | 探索、スケッチ、スパイク、仕様、キャプチャ |
|
||||
|
||||
名前空間ルーターを自分でタイプする必要はほぼありません。その価値はモデルが適切なサブスキルを見つけるために使うルーティングレイヤーにあります — システムプロンプトが 86 エントリではなく 6 エントリを列挙できるようにするために存在しています。具体的なコマンドがわかっている場合（例: `/gsd-plan-phase`）は、直接呼び出してください。
|
||||
名前空間ルーターを自分でタイプする必要はほぼありません。その価値はモデルが適切なサブスキルを見つけるために使うルーティングレイヤーにあります — システムプロンプトが 86 エントリではなく 6 エントリを列挙できるようにするために存在しています。具体的なコマンドがわかっている場合（例: `/msd-plan-phase`）は、直接呼び出してください。
|
||||
|
||||
---
|
||||
|
||||
## プロジェクトライフサイクル概要 {#project-lifecycle-overview}
|
||||
|
||||
GSD のコアループは **discuss → plan → execute → verify → ship** であり、フェーズごとに繰り返されます。例示出力、作成されるファイル、使用されるフラグを含むステップバイステップのウォークスルーは専用チュートリアルに記載されています。
|
||||
MSD のコアループは **discuss → plan → execute → verify → ship** であり、フェーズごとに繰り返されます。例示出力、作成されるファイル、使用されるフラグを含むステップバイステップのウォークスルーは専用チュートリアルに記載されています。
|
||||
|
||||
[最初のプロジェクト](tutorials/your-first-project.md) を参照してください。
|
||||
|
||||
@@ -68,12 +68,12 @@ GSD のコアループは **discuss → plan → execute → verify → ship**
|
||||
|
||||
| フラグ | コマンド | 使用場面 |
|
||||
| ---- | ------- | ----------- |
|
||||
| `--auto` | `/gsd-new-project` | インタラクティブな質問をスキップし、PRD ファイルから取り込む |
|
||||
| `--research` | `/gsd-quick` | アドホックタスクにリサーチエージェントを追加する |
|
||||
| `--validate` | `/gsd-quick` | プランチェックと実行後の検証を追加する |
|
||||
| `--chain` | `/gsd-discuss-phase` | discuss → plan → execute を停止なしで自動チェーンする |
|
||||
| `--skip-research` | `/gsd-plan-phase` | ドメインが既知の場合にリサーチエージェントをスキップする |
|
||||
| `--draft` | `/gsd-ship` | レビュー準備完了ではなくドラフト PR を作成する |
|
||||
| `--auto` | `/msd-new-project` | インタラクティブな質問をスキップし、PRD ファイルから取り込む |
|
||||
| `--research` | `/msd-quick` | アドホックタスクにリサーチエージェントを追加する |
|
||||
| `--validate` | `/msd-quick` | プランチェックと実行後の検証を追加する |
|
||||
| `--chain` | `/msd-discuss-phase` | discuss → plan → execute を停止なしで自動チェーンする |
|
||||
| `--skip-research` | `/msd-plan-phase` | ドメインが既知の場合にリサーチエージェントをスキップする |
|
||||
| `--draft` | `/msd-ship` | レビュー準備完了ではなくドラフト PR を作成する |
|
||||
|
||||
すべてのフラグを含む完全なコマンドリファレンスは [`docs/COMMANDS.md`](COMMANDS.md) を、設定オプション（モデルプロファイル、ワークフローエージェント、git ブランチ戦略）は [`docs/CONFIGURATION.md`](CONFIGURATION.md) を参照してください。
|
||||
|
||||
@@ -86,7 +86,7 @@ GSD のコアループは **discuss → plan → execute → verify → ship**
|
||||
```text
|
||||
┌──────────────────────────────────────────────────┐
|
||||
│ NEW PROJECT │
|
||||
│ /gsd-new-project │
|
||||
│ /msd-new-project │
|
||||
│ Questions -> Research -> Requirements -> Roadmap│
|
||||
└─────────────────────────┬────────────────────────┘
|
||||
│
|
||||
@@ -94,27 +94,27 @@ GSD のコアループは **discuss → plan → execute → verify → ship**
|
||||
│ FOR EACH PHASE: │
|
||||
│ │
|
||||
│ ┌────────────────────┐ │
|
||||
│ │ /gsd-discuss-phase │ │ <- Lock in preferences
|
||||
│ │ /msd-discuss-phase │ │ <- Lock in preferences
|
||||
│ └──────────┬─────────┘ │
|
||||
│ │ │
|
||||
│ ┌──────────▼─────────┐ │
|
||||
│ │ /gsd-ui-phase │ │ <- Design contract (frontend)
|
||||
│ │ /msd-ui-phase │ │ <- Design contract (frontend)
|
||||
│ └──────────┬─────────┘ │
|
||||
│ │ │
|
||||
│ ┌──────────▼─────────┐ │
|
||||
│ │ /gsd-plan-phase │ │ <- Research + Plan + Verify
|
||||
│ │ /msd-plan-phase │ │ <- Research + Plan + Verify
|
||||
│ └──────────┬─────────┘ │
|
||||
│ │ │
|
||||
│ ┌──────────▼─────────┐ │
|
||||
│ │ /gsd-execute-phase │ │ <- Parallel execution
|
||||
│ │ /msd-execute-phase │ │ <- Parallel execution
|
||||
│ └──────────┬─────────┘ │
|
||||
│ │ │
|
||||
│ ┌──────────▼─────────┐ │
|
||||
│ │ /gsd-verify-work │ │ <- Manual UAT
|
||||
│ │ /msd-verify-work │ │ <- Manual UAT
|
||||
│ └──────────┬─────────┘ │
|
||||
│ │ │
|
||||
│ ┌──────────▼─────────┐ │
|
||||
│ │ /gsd-ship │ │ <- Create PR (optional)
|
||||
│ │ /msd-ship │ │ <- Create PR (optional)
|
||||
│ └──────────┬─────────┘ │
|
||||
│ │ │
|
||||
│ Next Phase?────────────┘
|
||||
@@ -122,8 +122,8 @@ GSD のコアループは **discuss → plan → execute → verify → ship**
|
||||
└─────────────┼──────────────┘
|
||||
│
|
||||
┌───────────────▼──────────────┐
|
||||
│ /gsd-audit-milestone │
|
||||
│ /gsd-complete-milestone │
|
||||
│ /msd-audit-milestone │
|
||||
│ /msd-complete-milestone │
|
||||
└───────────────┬──────────────┘
|
||||
│
|
||||
Another milestone?
|
||||
@@ -131,14 +131,14 @@ GSD のコアループは **discuss → plan → execute → verify → ship**
|
||||
Yes No -> Done!
|
||||
│
|
||||
┌───────▼──────────────┐
|
||||
│ /gsd-new-milestone │
|
||||
│ /msd-new-milestone │
|
||||
└──────────────────────┘
|
||||
```
|
||||
|
||||
### プランニングエージェントの協調
|
||||
|
||||
```text
|
||||
/gsd-plan-phase N
|
||||
/msd-plan-phase N
|
||||
│
|
||||
├── Phase Researcher (x4 parallel)
|
||||
│ ├── Stack researcher
|
||||
@@ -171,18 +171,18 @@ GSD のコアループは **discuss → plan → execute → verify → ship**
|
||||
|
||||
### バリデーションアーキテクチャ（Nyquist レイヤー）
|
||||
|
||||
プランフェーズのリサーチ中、GSD はコードが書かれる前に各フェーズ要件に対して自動テストカバレッジをマッピングします。リサーチャーは既存のテストインフラを検出し、各要件を特定のテストコマンドにマッピングし、実装開始前に作成しなければならないテスト足場（Wave 0 タスク）を識別します。プランチェッカーはこれを 8 番目の検証ディメンションとして強制します: 自動検証コマンドが不足しているタスクを含むプランは承認されません。
|
||||
プランフェーズのリサーチ中、MSD はコードが書かれる前に各フェーズ要件に対して自動テストカバレッジをマッピングします。リサーチャーは既存のテストインフラを検出し、各要件を特定のテストコマンドにマッピングし、実装開始前に作成しなければならないテスト足場（Wave 0 タスク）を識別します。プランチェッカーはこれを 8 番目の検証ディメンションとして強制します: 自動検証コマンドが不足しているタスクを含むプランは承認されません。
|
||||
|
||||
**出力:** `{phase}-VALIDATION.md` — フェーズのフィードバックコントラクト。
|
||||
|
||||
**無効化:** テストインフラが焦点でないラピッドプロトタイピングフェーズでは、`/gsd-settings` で `workflow.nyquist_validation: false` を設定してください。
|
||||
**無効化:** テストインフラが焦点でないラピッドプロトタイピングフェーズでは、`/msd-settings` で `workflow.nyquist_validation: false` を設定してください。
|
||||
|
||||
### 遡及バリデーション（`/gsd-validate-phase`）
|
||||
### 遡及バリデーション（`/msd-validate-phase`）
|
||||
|
||||
Nyquist バリデーションが存在する前に実行されたフェーズ、またはテストスイートのみを持つ既存のコードベースに対し、カバレッジのギャップを遡及的に監査して補完します。
|
||||
|
||||
```text
|
||||
/gsd-validate-phase N
|
||||
/msd-validate-phase N
|
||||
|
|
||||
+-- Detect state (VALIDATION.md exists? SUMMARY.md exists?)
|
||||
|
|
||||
@@ -204,9 +204,9 @@ Nyquist バリデーションが存在する前に実行されたフェーズ、
|
||||
|
||||
### 前提条件ディスカッションモード
|
||||
|
||||
デフォルトでは、`/gsd-discuss-phase` は実装の好みに関するオープンエンドな質問をします。前提条件モードではこれが逆転します: GSD がまずコードベースを読み込み、フェーズをどのように構築するかについての構造化された前提条件を提示し、修正点のみを尋ねます。
|
||||
デフォルトでは、`/msd-discuss-phase` は実装の好みに関するオープンエンドな質問をします。前提条件モードではこれが逆転します: MSD がまずコードベースを読み込み、フェーズをどのように構築するかについての構造化された前提条件を提示し、修正点のみを尋ねます。
|
||||
|
||||
**有効化:** `/gsd-settings` 経由で `workflow.discuss_mode` を `'assumptions'` に設定してください。
|
||||
**有効化:** `/msd-settings` 経由で `workflow.discuss_mode` を `'assumptions'` に設定してください。
|
||||
|
||||
詳細なディスカッションモードのリファレンスは [docs/workflow-discuss-mode.md](workflow-discuss-mode.md) を参照してください。
|
||||
|
||||
@@ -214,18 +214,18 @@ Nyquist バリデーションが存在する前に実行されたフェーズ、
|
||||
|
||||
ディスカッションフェーズは実装上の意思決定を CONTEXT.md の `<decisions>` ブロック内に番号付き箇条書き（`- **D-01:** …`）として記録します。2 つのゲートによりこれらの意思決定がプランおよびシップされたコードに確実に反映されます。
|
||||
|
||||
**プランフェーズ変換ゲート（ブロッキング）。** プランニング後、GSD はすべての追跡可能な意思決定が少なくとも 1 つのプランの `must_haves`、`truths`、または本文に含まれるまでフェーズ計画済みのマークを拒否します。
|
||||
**プランフェーズ変換ゲート（ブロッキング）。** プランニング後、MSD はすべての追跡可能な意思決定が少なくとも 1 つのプランの `must_haves`、`truths`、または本文に含まれるまでフェーズ計画済みのマークを拒否します。
|
||||
|
||||
**検証フェーズバリデーションゲート（非ブロッキング）。** 検証中、GSD はプラン、SUMMARY.md、変更されたファイル、および直近のコミットメッセージで各追跡可能な意思決定を検索します。見落としは警告セクションとして VERIFICATION.md に記録されますが、検証ステータスは変更されません。
|
||||
**検証フェーズバリデーションゲート（非ブロッキング）。** 検証中、MSD はプラン、SUMMARY.md、変更されたファイル、および直近のコミットメッセージで各追跡可能な意思決定を検索します。見落としは警告セクションとして VERIFICATION.md に記録されますが、検証ステータスは変更されません。
|
||||
|
||||
**意思決定のオプトアウト。** `<decisions>` 内の `### Claude's Discretion` 見出し配下に移動するか、タグを付けてください: `- **D-08 [informational]:** …`、`- **D-09 [folded]:** …`、`- **D-10 [deferred]:** …`。
|
||||
|
||||
**ゲートの無効化。** `.planning/config.json`（または `/gsd-settings` 経由）で `workflow.context_coverage_gate: false` を設定してください。デフォルトは `true` です。
|
||||
**ゲートの無効化。** `.planning/config.json`（または `/msd-settings` 経由）で `workflow.context_coverage_gate: false` を設定してください。デフォルトは `true` です。
|
||||
|
||||
### 実行ウェーブの協調
|
||||
|
||||
```text
|
||||
/gsd-execute-phase N
|
||||
/msd-execute-phase N
|
||||
│
|
||||
├── Analyze plan dependencies
|
||||
│
|
||||
@@ -241,14 +241,14 @@ Nyquist バリデーションが存在する前に実行されたフェーズ、
|
||||
├── Test quality audit (disabled tests, circular patterns, assertion strength)
|
||||
│
|
||||
├── PASS -> VERIFICATION.md (success)
|
||||
└── FAIL -> Issues logged for /gsd-verify-work
|
||||
└── FAIL -> Issues logged for /msd-verify-work
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## UI デザインコントラクト {#ui-design-contract}
|
||||
|
||||
AI が生成するフロントエンドが視覚的に一貫しないのは、Claude Code の UI 能力の問題ではなく、実行前にデザインコントラクトが存在しなかったためです。`/gsd-ui-phase` はプランニング前にデザインコントラクトをロックし、`/gsd-ui-review` は実行後に結果を監査します。
|
||||
AI が生成するフロントエンドが視覚的に一貫しないのは、Claude Code の UI 能力の問題ではなく、実行前にデザインコントラクトが存在しなかったためです。`/msd-ui-phase` はプランニング前にデザインコントラクトをロックし、`/msd-ui-review` は実行後に結果を監査します。
|
||||
|
||||
完全なワークフロー、設定、shadcn の初期化、レジストリ安全ゲートについては [UI フェーズのデザイン](how-to/design-a-ui-phase.md) を参照してください。
|
||||
|
||||
@@ -256,33 +256,33 @@ AI が生成するフロントエンドが視覚的に一貫しないのは、Cl
|
||||
|
||||
| コマンド | 説明 |
|
||||
| -------------------- | -------------------------------------------------------- |
|
||||
| `/gsd-ui-phase [N]` | フロントエンドフェーズ用の UI-SPEC.md デザインコントラクトを生成する |
|
||||
| `/gsd-ui-review [N]` | 実装済み UI の 6 柱ビジュアル監査を遡及的に実行する |
|
||||
| `/msd-ui-phase [N]` | フロントエンドフェーズ用の UI-SPEC.md デザインコントラクトを生成する |
|
||||
| `/msd-ui-review [N]` | 実装済み UI の 6 柱ビジュアル監査を遡及的に実行する |
|
||||
|
||||
| 設定 | デフォルト | 説明 |
|
||||
| ------------------------- | ------- | ----------------------------------------------------------- |
|
||||
| `workflow.ui_phase` | `true` | フロントエンドフェーズ用の UI デザインコントラクトを生成する |
|
||||
| `workflow.ui_safety_gate` | `true` | プランフェーズでフロントエンドフェーズに対し /gsd-ui-phase の実行を促す |
|
||||
| `workflow.ui_safety_gate` | `true` | プランフェーズでフロントエンドフェーズに対し /msd-ui-phase の実行を促す |
|
||||
|
||||
---
|
||||
|
||||
## スパイクとスケッチ {#spiking--sketching}
|
||||
|
||||
プランニング前に技術的な実現可能性を検証するには `/gsd-spike` を、デザイン前にビジュアルの方向性を探るには `/gsd-sketch` を使用してください。どちらもアーティファクトを `.planning/` に保存し、ラップアップコンパニオンを介してプロジェクトスキルシステムと統合されます。
|
||||
プランニング前に技術的な実現可能性を検証するには `/msd-spike` を、デザイン前にビジュアルの方向性を探るには `/msd-sketch` を使用してください。どちらもアーティファクトを `.planning/` に保存し、ラップアップコンパニオンを介してプロジェクトスキルシステムと統合されます。
|
||||
|
||||
完全なワークフローとフロー図は [スパイクとスケッチ](how-to/spike-and-sketch.md) を参照してください。
|
||||
|
||||
**典型的なフロー:**
|
||||
|
||||
```bash
|
||||
/gsd-spike "SSE vs WebSocket" # Validate the approach
|
||||
/gsd-spike --wrap-up # Package learnings
|
||||
/msd-spike "SSE vs WebSocket" # Validate the approach
|
||||
/msd-spike --wrap-up # Package learnings
|
||||
|
||||
/gsd-sketch "real-time feed UI" # Explore the design
|
||||
/gsd-sketch --wrap-up # Package decisions
|
||||
/msd-sketch "real-time feed UI" # Explore the design
|
||||
/msd-sketch --wrap-up # Package decisions
|
||||
|
||||
/gsd-discuss-phase N # Lock in preferences (now informed by spike + sketch)
|
||||
/gsd-plan-phase N # Plan with confidence
|
||||
/msd-discuss-phase N # Lock in preferences (now informed by spike + sketch)
|
||||
/msd-plan-phase N # Plan with confidence
|
||||
```
|
||||
|
||||
---
|
||||
@@ -294,35 +294,35 @@ AI が生成するフロントエンドが視覚的に一貫しないのは、Cl
|
||||
まだアクティブなプランニングの準備ができていないアイデアは、999.x 番号付けを使用してバックログに追加し、アクティブなフェーズシーケンスの外に置きます。
|
||||
|
||||
```bash
|
||||
/gsd-capture --backlog "GraphQL API layer" # Creates 999.1-graphql-api-layer/
|
||||
/gsd-capture --backlog "Mobile responsive" # Creates 999.2-mobile-responsive/
|
||||
/msd-capture --backlog "GraphQL API layer" # Creates 999.1-graphql-api-layer/
|
||||
/msd-capture --backlog "Mobile responsive" # Creates 999.2-mobile-responsive/
|
||||
```
|
||||
|
||||
バックログアイテムは完全なフェーズディレクトリを持つため、`/gsd-discuss-phase 999.1` でアイデアをさらに探索したり、準備ができたら `/gsd-plan-phase 999.1` を使用できます。
|
||||
バックログアイテムは完全なフェーズディレクトリを持つため、`/msd-discuss-phase 999.1` でアイデアをさらに探索したり、準備ができたら `/msd-plan-phase 999.1` を使用できます。
|
||||
|
||||
**レビューとプロモーション** は `/gsd-review-backlog` で行います — すべてのバックログアイテムが表示され、プロモート（アクティブシーケンスに移動）、保持（バックログに残す）、または削除（削除）を選択できます。
|
||||
**レビューとプロモーション** は `/msd-review-backlog` で行います — すべてのバックログアイテムが表示され、プロモート（アクティブシーケンスに移動）、保持（バックログに残す）、または削除（削除）を選択できます。
|
||||
|
||||
### シード
|
||||
|
||||
シードはトリガー条件を持つ将来志向のアイデアです。バックログアイテムと異なり、適切なマイルストーンが来ると自動的に浮上します。
|
||||
|
||||
```bash
|
||||
/gsd-capture --seed "Add real-time collab when WebSocket infra is in place"
|
||||
/msd-capture --seed "Add real-time collab when WebSocket infra is in place"
|
||||
```
|
||||
|
||||
`/gsd-new-milestone` はすべてのシードをスキャンしてマッチを提示します。**保存場所:** `.planning/seeds/SEED-NNN-slug.md`
|
||||
`/msd-new-milestone` はすべてのシードをスキャンしてマッチを提示します。**保存場所:** `.planning/seeds/SEED-NNN-slug.md`
|
||||
|
||||
### 永続コンテキストスレッド
|
||||
|
||||
スレッドは、複数のセッションにまたがるが特定のフェーズに属さない作業のための軽量なクロスセッション知識ストアです。
|
||||
|
||||
```bash
|
||||
/gsd-thread # List all threads
|
||||
/gsd-thread fix-deploy-key-auth # Resume existing thread
|
||||
/gsd-thread "Investigate TCP timeout" # Create new thread
|
||||
/msd-thread # List all threads
|
||||
/msd-thread fix-deploy-key-auth # Resume existing thread
|
||||
/msd-thread "Investigate TCP timeout" # Create new thread
|
||||
```
|
||||
|
||||
スレッドが成熟したら、フェーズ（`/gsd-phase`）またはバックログアイテム（`/gsd-capture --backlog`）に昇格できます。**保存場所:** `.planning/threads/{slug}.md`
|
||||
スレッドが成熟したら、フェーズ（`/msd-phase`）またはバックログアイテム（`/msd-capture --backlog`）に昇格できます。**保存場所:** `.planning/threads/{slug}.md`
|
||||
|
||||
---
|
||||
|
||||
@@ -336,19 +336,19 @@ AI が生成するフロントエンドが視覚的に一貫しないのは、Cl
|
||||
|
||||
| コマンド | 目的 |
|
||||
| ---------------------------------- | ---------------------------------------------------- |
|
||||
| `/gsd-workstreams create <name>` | 分離されたプランニング状態を持つ新しいワークストリームを作成する |
|
||||
| `/gsd-workstreams switch <name>` | アクティブコンテキストを別のワークストリームに切り替える |
|
||||
| `/gsd-workstreams list` | すべてのワークストリームとアクティブなものを表示する |
|
||||
| `/gsd-workstreams complete <name>` | ワークストリームを完了としてマークし状態をアーカイブする |
|
||||
| `/msd-workstreams create <name>` | 分離されたプランニング状態を持つ新しいワークストリームを作成する |
|
||||
| `/msd-workstreams switch <name>` | アクティブコンテキストを別のワークストリームに切り替える |
|
||||
| `/msd-workstreams list` | すべてのワークストリームとアクティブなものを表示する |
|
||||
| `/msd-workstreams complete <name>` | ワークストリームを完了としてマークし状態をアーカイブする |
|
||||
|
||||
```bash
|
||||
# Workspace example — feature branch isolation
|
||||
/gsd-workspace --new --name feature-b --repos .
|
||||
cd ~/gsd-workspaces/feature-b
|
||||
/gsd-new-project
|
||||
/msd-workspace --new --name feature-b --repos .
|
||||
cd ~/msd-workspaces/feature-b
|
||||
/msd-new-project
|
||||
|
||||
/gsd-workspace --list
|
||||
/gsd-workspace --remove feature-b
|
||||
/msd-workspace --list
|
||||
/msd-workspace --remove feature-b
|
||||
```
|
||||
|
||||
---
|
||||
@@ -357,7 +357,7 @@ cd ~/gsd-workspaces/feature-b
|
||||
|
||||
### 多層防御（v1.27）
|
||||
|
||||
GSD は LLM のシステムプロンプトになるマークダウンファイルを生成します。これは、プランニングアーティファクトに流れ込むユーザー制御のテキストが、間接的なプロンプトインジェクションベクターになり得ることを意味します。v1.27 では集中的なセキュリティ強化が導入されました。
|
||||
MSD は LLM のシステムプロンプトになるマークダウンファイルを生成します。これは、プランニングアーティファクトに流れ込むユーザー制御のテキストが、間接的なプロンプトインジェクションベクターになり得ることを意味します。v1.27 では集中的なセキュリティ強化が導入されました。
|
||||
|
||||
**パストラバーサル防止:** ユーザーが指定したファイルパス（`--text-file`、`--prd`）はすべてプロジェクトディレクトリ内で解決されるよう検証されます。macOS の `/var` → `/private/var` シンボリックリンク解決も処理されます。
|
||||
|
||||
@@ -365,8 +365,8 @@ GSD は LLM のシステムプロンプトになるマークダウンファイ
|
||||
|
||||
**ランタイムフック:**
|
||||
|
||||
- `gsd-prompt-guard.js` — `.planning/` への Write/Edit 呼び出しでインジェクションパターンをスキャンする（常時有効、アドバイザリーのみ）
|
||||
- `gsd-workflow-guard.js` — GSD ワークフローコンテキスト外でのファイル編集を警告する（`hooks.workflow_guard` 経由でオプトイン）
|
||||
- `msd-prompt-guard.js` — `.planning/` への Write/Edit 呼び出しでインジェクションパターンをスキャンする（常時有効、アドバイザリーのみ）
|
||||
- `msd-workflow-guard.js` — MSD ワークフローコンテキスト外でのファイル編集を警告する（`hooks.workflow_guard` 経由でオプトイン）
|
||||
|
||||
**CI スキャナー:** `prompt-injection-scan.security.test.cjs` はすべてのエージェント、ワークフロー、コマンドファイルに埋め込まれたインジェクションベクターをスキャンします。
|
||||
|
||||
@@ -396,7 +396,7 @@ AI コーディングツールはパッケージ名を幻覚することがあ
|
||||
|
||||
**正当性の判定:**
|
||||
|
||||
| 判定 | 意味 | GSD のアクション |
|
||||
| 判定 | 意味 | MSD のアクション |
|
||||
|---------|---------|------------|
|
||||
| `[OK]` | すべての正当性チェックに合格 | 進行 — チェックポイントは追加されない |
|
||||
| `[SUS]` | 疑わしいシグナル | フラグ付き; プランナーが `checkpoint:human-verify` を追加 |
|
||||
@@ -411,17 +411,17 @@ AI コーディングツールはパッケージ名を幻覚することがあ
|
||||
フェーズを実行した後、UAT の前に構造化されたコードレビューを実行してください。完全なワークフローは [クロス AI レビューのセットアップ](how-to/set-up-cross-ai-review.md) を参照してください。
|
||||
|
||||
```bash
|
||||
/gsd-code-review 3 # Review all changed files in phase 3
|
||||
/gsd-code-review 3 --depth=deep # Deep cross-file review
|
||||
/gsd-code-review 3 --fix # Fix Critical + Warning findings atomically
|
||||
/gsd-code-review 3 --fix --auto # Fix and re-review until clean (max 3 iterations)
|
||||
/gsd-audit-fix # Audit + classify + fix (medium+ severity, max 5)
|
||||
/msd-code-review 3 # Review all changed files in phase 3
|
||||
/msd-code-review 3 --depth=deep # Deep cross-file review
|
||||
/msd-code-review 3 --fix # Fix Critical + Warning findings atomically
|
||||
/msd-code-review 3 --fix --auto # Fix and re-review until clean (max 3 iterations)
|
||||
/msd-audit-fix # Audit + classify + fix (medium+ severity, max 5)
|
||||
```
|
||||
|
||||
レビューステップは実行後、UAT 前に位置します:
|
||||
|
||||
```text
|
||||
/gsd-execute-phase N -> /gsd-code-review N -> /gsd-code-review N --fix -> /gsd-verify-work N
|
||||
/msd-execute-phase N -> /msd-code-review N -> /msd-code-review N --fix -> /msd-verify-work N
|
||||
```
|
||||
|
||||
---
|
||||
@@ -440,26 +440,26 @@ AI コーディングツールはパッケージ名を幻覚することがあ
|
||||
|
||||
```bash
|
||||
claude --dangerously-skip-permissions
|
||||
/gsd-new-project # Answer questions, configure, approve roadmap
|
||||
/msd-new-project # Answer questions, configure, approve roadmap
|
||||
/clear
|
||||
/gsd-discuss-phase 1 # Lock in your preferences
|
||||
/gsd-ui-phase 1 # Design contract (frontend phases)
|
||||
/gsd-plan-phase 1 # Research + plan + verify
|
||||
/gsd-execute-phase 1 # Parallel execution
|
||||
/gsd-verify-work 1 # Manual UAT
|
||||
/gsd-ship 1 # Create PR from verified work
|
||||
/gsd-ui-review 1 # Visual audit (frontend phases)
|
||||
/msd-discuss-phase 1 # Lock in your preferences
|
||||
/msd-ui-phase 1 # Design contract (frontend phases)
|
||||
/msd-plan-phase 1 # Research + plan + verify
|
||||
/msd-execute-phase 1 # Parallel execution
|
||||
/msd-verify-work 1 # Manual UAT
|
||||
/msd-ship 1 # Create PR from verified work
|
||||
/msd-ui-review 1 # Visual audit (frontend phases)
|
||||
/clear
|
||||
/gsd-progress --next # Auto-detect and run next step
|
||||
/msd-progress --next # Auto-detect and run next step
|
||||
...
|
||||
/gsd-audit-milestone # Check everything shipped
|
||||
/gsd-complete-milestone # Archive, tag, done
|
||||
/gsd-pause-work --report # Generate session summary
|
||||
/msd-audit-milestone # Check everything shipped
|
||||
/msd-complete-milestone # Archive, tag, done
|
||||
/msd-pause-work --report # Generate session summary
|
||||
```
|
||||
|
||||
> [!CAUTION]
|
||||
> **The permissions flag is optional.** It skips per-file confirmation while
|
||||
> GSD's sub-agents read and write files. Use it only in low-stakes or
|
||||
> MSD's sub-agents read and write files. Use it only in low-stakes or
|
||||
> throwaway contexts. To keep confirmations enabled, start with `claude` instead.
|
||||
> For real work, read the [security model](../explanation/security-model.md) first.
|
||||
|
||||
@@ -467,24 +467,24 @@ claude --dangerously-skip-permissions
|
||||
### 既存ドキュメントからの新規プロジェクト
|
||||
|
||||
```bash
|
||||
/gsd-new-project --auto @prd.md # Auto-runs research/requirements/roadmap from your doc
|
||||
/msd-new-project --auto @prd.md # Auto-runs research/requirements/roadmap from your doc
|
||||
/clear
|
||||
/gsd-discuss-phase 1 # Normal flow from here
|
||||
/msd-discuss-phase 1 # Normal flow from here
|
||||
```
|
||||
|
||||
### 既存のコードベース
|
||||
|
||||
```bash
|
||||
/gsd-onboard # Safely map, ingest docs, and initialize planning
|
||||
# Follow printed handoff commands, then rerun /gsd-onboard
|
||||
/msd-onboard # Safely map, ingest docs, and initialize planning
|
||||
# Follow printed handoff commands, then rerun /msd-onboard
|
||||
# (normal phase workflow from here)
|
||||
```
|
||||
|
||||
**実行後のドリフト検出（#2003）。** `/gsd-execute-phase` を実行するたびに、GSD はフェーズが `.planning/codebase/STRUCTURE.md` を古くするほどの構造的変更を導入したかどうかを確認します。次のコマンドで動作を切り替えられます:
|
||||
**実行後のドリフト検出（#2003）。** `/msd-execute-phase` を実行するたびに、MSD はフェーズが `.planning/codebase/STRUCTURE.md` を古くするほどの構造的変更を導入したかどうかを確認します。次のコマンドで動作を切り替えられます:
|
||||
|
||||
```bash
|
||||
/gsd-settings workflow.drift_action auto-remap # remap automatically
|
||||
/gsd-settings workflow.drift_threshold 5 # tune sensitivity
|
||||
/msd-settings workflow.drift_action auto-remap # remap automatically
|
||||
/msd-settings workflow.drift_threshold 5 # tune sensitivity
|
||||
```
|
||||
|
||||
### プランドリフトガード
|
||||
@@ -500,40 +500,40 @@ claude --dangerously-skip-permissions
|
||||
|
||||
**needs-acknowledgement の動作。** ガードが欠損シンボルを発見すると、ハードブロックではなく `needs-acknowledgement` 通知をプランレビュー出力に出力します。承認して続行（シンボルが意図的に新規の場合）するか、プランの修正を要求できます。ガードはプランを自動拒否しません — 人間の判断のためのシグナルを提示します。
|
||||
|
||||
**intel なしでも動作。** デフォルトではガードは `grep`/`ripgrep` を使用してソースファイルを検索します — 事前インデックスは不要です。`intel.enabled: true` で `/gsd-map-codebase` を実行済みの場合、`plan_review.source_grounding_authority: intel` を設定すると、より高速な事前構築済みの `api-map.json` インデックスを使用できます。
|
||||
**intel なしでも動作。** デフォルトではガードは `grep`/`ripgrep` を使用してソースファイルを検索します — 事前インデックスは不要です。`intel.enabled: true` で `/msd-map-codebase` を実行済みの場合、`plan_review.source_grounding_authority: intel` を設定すると、より高速な事前構築済みの `api-map.json` インデックスを使用できます。
|
||||
|
||||
```bash
|
||||
# Enable/disable (default: on)
|
||||
/gsd-settings plan_review.source_grounding true
|
||||
/gsd-settings plan_review.source_grounding false
|
||||
/msd-settings plan_review.source_grounding true
|
||||
/msd-settings plan_review.source_grounding false
|
||||
|
||||
# Switch resolver authority
|
||||
/gsd-settings plan_review.source_grounding_authority grep # live grep (default)
|
||||
/gsd-settings plan_review.source_grounding_authority intel # pre-indexed api-map.json
|
||||
/msd-settings plan_review.source_grounding_authority grep # live grep (default)
|
||||
/msd-settings plan_review.source_grounding_authority intel # pre-indexed api-map.json
|
||||
```
|
||||
|
||||
プロジェクト設定時（`/gsd-new-project` がワークフロー設定中に尋ねます）または `/gsd-settings`（Planning セクション → Drift Guard）経由でいつでも切り替えられます。
|
||||
プロジェクト設定時（`/msd-new-project` がワークフロー設定中に尋ねます）または `/msd-settings`（Planning セクション → Drift Guard）経由でいつでも切り替えられます。
|
||||
|
||||
### クイックバグ修正
|
||||
|
||||
```bash
|
||||
/gsd-quick
|
||||
/msd-quick
|
||||
> "Fix the login button not responding on mobile Safari"
|
||||
```
|
||||
|
||||
### 休憩後の再開
|
||||
|
||||
```bash
|
||||
/gsd-progress # See where you left off and what's next
|
||||
/msd-progress # See where you left off and what's next
|
||||
# or
|
||||
/gsd-resume-work # Full context restoration from last session
|
||||
/msd-resume-work # Full context restoration from last session
|
||||
```
|
||||
|
||||
### リリース準備
|
||||
|
||||
```bash
|
||||
/gsd-audit-milestone # Check requirements coverage, detect stubs
|
||||
/gsd-complete-milestone # Archive, tag, done
|
||||
/msd-audit-milestone # Check requirements coverage, detect stubs
|
||||
/msd-complete-milestone # Archive, tag, done
|
||||
```
|
||||
|
||||
### スピードと品質のプリセット
|
||||
@@ -544,15 +544,15 @@ claude --dangerously-skip-permissions
|
||||
| 通常の開発 | `interactive` | `standard` | `balanced` | on | on | on |
|
||||
| 本番環境 | `interactive` | `fine` | `quality` | on | on | on |
|
||||
|
||||
**自律モードでのディスカッションフェーズのスキップ:** `yolo` モードで実行する場合、`/gsd-settings` で `workflow.skip_discuss: true` を設定してください。
|
||||
**自律モードでのディスカッションフェーズのスキップ:** `yolo` モードで実行する場合、`/msd-settings` で `workflow.skip_discuss: true` を設定してください。
|
||||
|
||||
### マイルストーン途中でのスコープ変更
|
||||
|
||||
```bash
|
||||
/gsd-phase # Append a new phase to the roadmap (default mode)
|
||||
/gsd-phase --insert 3 # Insert urgent work between phases 3 and 4
|
||||
/gsd-phase --remove 7 # Descope phase 7 and renumber
|
||||
/gsd-phase --edit 4 # Edit any field of phase 4 in place
|
||||
/msd-phase # Append a new phase to the roadmap (default mode)
|
||||
/msd-phase --insert 3 # Insert urgent work between phases 3 and 4
|
||||
/msd-phase --remove 7 # Descope phase 7 and renumber
|
||||
/msd-phase --edit 4 # Edit any field of phase 4 in place
|
||||
```
|
||||
|
||||
---
|
||||
@@ -561,29 +561,29 @@ claude --dangerously-skip-permissions
|
||||
|
||||
包括的なトラブルシューティングガイドは [リカバリーとトラブルシューティング](how-to/recover-and-troubleshoot.md) を参照してください。最も一般的な問題を以下に要約します。
|
||||
|
||||
### プログラマティック CLI（`gsd-tools query` vs `gsd-tools.cjs`）
|
||||
### プログラマティック CLI（`msd-tools query` vs `msd-tools.cjs`）
|
||||
|
||||
自動化には、登録済みサブコマンドを使用する **`gsd-tools query`** を推奨します（[CLI-TOOLS.md — SDK とプログラマティックアクセス](CLI-TOOLS.md#sdk-and-programmatic-access) と QUERY-HANDLERS.md を参照）。レガシーの `node $HOME/.claude/gsd-core/bin/gsd-tools.cjs` CLI は引き続きサポートされています。
|
||||
自動化には、登録済みサブコマンドを使用する **`msd-tools query`** を推奨します（[CLI-TOOLS.md — SDK とプログラマティックアクセス](CLI-TOOLS.md#sdk-and-programmatic-access) と QUERY-HANDLERS.md を参照）。レガシーの `node $HOME/.claude/msd-core/bin/msd-tools.cjs` CLI は引き続きサポートされています。
|
||||
|
||||
### STATE.md の同期ずれ
|
||||
|
||||
```bash
|
||||
node "$HOME/.claude/gsd-core/bin/gsd-tools.cjs" state validate # Detect drift
|
||||
node "$HOME/.claude/gsd-core/bin/gsd-tools.cjs" state sync --verify # Preview changes
|
||||
node "$HOME/.claude/gsd-core/bin/gsd-tools.cjs" state sync # Reconstruct STATE.md
|
||||
node "$HOME/.claude/msd-core/bin/msd-tools.cjs" state validate # Detect drift
|
||||
node "$HOME/.claude/msd-core/bin/msd-tools.cjs" state sync --verify # Preview changes
|
||||
node "$HOME/.claude/msd-core/bin/msd-tools.cjs" state sync # Reconstruct STATE.md
|
||||
```
|
||||
|
||||
### 「Spawning...」の後にコマンドがフリーズしているように見える
|
||||
|
||||
GSD サブエージェントは独立したコンテキストウィンドウで実行されます — その作業は進行中は親セッションからは見えません。セッションを中断しないでください。リサーチおよびプランニングエージェントは通常 1〜5 分かかります。結果を待ってください。
|
||||
MSD サブエージェントは独立したコンテキストウィンドウで実行されます — その作業は進行中は親セッションからは見えません。セッションを中断しないでください。リサーチおよびプランニングエージェントは通常 1〜5 分かかります。結果を待ってください。
|
||||
|
||||
### 長いセッション中のコンテキスト劣化
|
||||
|
||||
主要なコマンド間でコンテキストウィンドウをクリアしてください: Claude Code では `/clear`。GSD はフレッシュなコンテキストを前提に設計されています — すべてのサブエージェントはクリーンな 200K ウィンドウを取得します。クリア後に状態を復元するには `/gsd-resume-work` または `/gsd-progress` を使用してください。
|
||||
主要なコマンド間でコンテキストウィンドウをクリアしてください: Claude Code では `/clear`。MSD はフレッシュなコンテキストを前提に設計されています — すべてのサブエージェントはクリーンな 200K ウィンドウを取得します。クリア後に状態を復元するには `/msd-resume-work` または `/msd-progress` を使用してください。
|
||||
|
||||
### プランが間違っているまたは方向性がずれている
|
||||
|
||||
プランニング前に `/gsd-discuss-phase [N]` を実行してください。プランの品質問題のほとんどは、`CONTEXT.md` があれば防げた前提をモデルが立てることから来ています。
|
||||
プランニング前に `/msd-discuss-phase [N]` を実行してください。プランの品質問題のほとんどは、`CONTEXT.md` があれば防げた前提をモデルが立てることから来ています。
|
||||
|
||||
### 実行が失敗するかスタブを生成する
|
||||
|
||||
@@ -591,11 +591,11 @@ GSD サブエージェントは独立したコンテキストウィンドウで
|
||||
|
||||
### どこにいるかわからなくなった
|
||||
|
||||
`/gsd-progress` を実行してください。すべての状態ファイルを読み込み、現在地と次にすべきことを正確に伝えます。
|
||||
`/msd-progress` を実行してください。すべての状態ファイルを読み込み、現在地と次にすべきことを正確に伝えます。
|
||||
|
||||
### モデルコストが高すぎる
|
||||
|
||||
budget プロファイルに切り替えてください: `/gsd-config --profile budget`。ドメインが既知の場合は `/gsd-settings` でリサーチおよびプランチェックエージェントを無効化してください。
|
||||
budget プロファイルに切り替えてください: `/msd-config --profile budget`。ドメインが既知の場合は `/msd-settings` でリサーチおよびプランチェックエージェントを無効化してください。
|
||||
|
||||
### フェーズ別のモデルコスト調整（`models`）— v1.40 追加
|
||||
|
||||
@@ -621,7 +621,7 @@ budget プロファイルに切り替えてください: `/gsd-config --profile
|
||||
{
|
||||
"models": { "research": "sonnet" },
|
||||
"model_overrides": {
|
||||
"gsd-codebase-mapper": "haiku"
|
||||
"msd-codebase-mapper": "haiku"
|
||||
}
|
||||
}
|
||||
```
|
||||
@@ -651,7 +651,7 @@ budget プロファイルに切り替えてください: `/gsd-config --profile
|
||||
|
||||
`model_profile` や `models.<phase_type>` を調整する前に、ハーネスで有効になっている **MCP サーバー** を監査してください。有効になっている各 MCP サーバーはすべてのターンにそのツールスキーマを注入します — 重量級のサーバーはそれぞれ 20k+ トークンかかることがあります。
|
||||
|
||||
これは **ハーネスの設定** であり、GSD の設定ではありません。トグルは `.claude/settings.json` にあります:
|
||||
これは **ハーネスの設定** であり、MSD の設定ではありません。トグルは `.claude/settings.json` にあります:
|
||||
|
||||
```json
|
||||
{
|
||||
@@ -668,13 +668,13 @@ budget プロファイルに切り替えてください: `/gsd-config --profile
|
||||
|
||||
サーバーを無効にすると、以降のすべてのターンからそのスキーマが削除されます。MCP のトリミングは `model_profile` の調整と**複合効果があります** — 両方のレバーは相加的であり、MCP の節約はオーケストレーターが生成するすべてのサブエージェントにわたってすぐに現れます。
|
||||
|
||||
完全な監査、ハーネスリファレンス、`model_profile` との組み合わせに関するノートは、バンドルされた `context-budget.md` リファレンスの [MCP ツールスキーマコスト](../../gsd-core/references/context-budget.md#mcp-tool-schema-cost-harness-concern) を参照してください。
|
||||
完全な監査、ハーネスリファレンス、`model_profile` との組み合わせに関するノートは、バンドルされた `context-budget.md` リファレンスの [MCP ツールスキーマコスト](../../msd-core/references/context-budget.md#mcp-tool-schema-cost-harness-concern) を参照してください。
|
||||
|
||||
### 非 Claude ランタイムの使用（Codex、OpenCode、Antigravity CLI、Kilo）
|
||||
|
||||
> **Codex CLI の最小サポートバージョン: `0.130.0`**（イシュー [#3562](https://github.com/open-gsd/gsd-core/issues/3562)）。
|
||||
|
||||
非 Claude ランタイム向けに GSD をインストールした場合、インストーラーがすでにモデル解決を設定しています。手動設定は不要です — `resolve_model_ids: "omit"` が自動的に設定され、GSD に Anthropic モデル ID の解決をスキップしてランタイムが独自のデフォルトモデルを選ぶよう指示します。
|
||||
非 Claude ランタイム向けに MSD をインストールした場合、インストーラーがすでにモデル解決を設定しています。手動設定は不要です — `resolve_model_ids: "omit"` が自動的に設定され、MSD に Anthropic モデル ID の解決をスキップしてランタイムが独自のデフォルトモデルを選ぶよう指示します。
|
||||
|
||||
非 Claude ランタイムで異なるモデルを割り当てるには:
|
||||
|
||||
@@ -682,9 +682,9 @@ budget プロファイルに切り替えてください: `/gsd-config --profile
|
||||
{
|
||||
"resolve_model_ids": "omit",
|
||||
"model_overrides": {
|
||||
"gsd-planner": "o3",
|
||||
"gsd-executor": "o4-mini",
|
||||
"gsd-debugger": "o3"
|
||||
"msd-planner": "o3",
|
||||
"msd-executor": "o4-mini",
|
||||
"msd-debugger": "o3"
|
||||
}
|
||||
}
|
||||
```
|
||||
@@ -702,9 +702,9 @@ budget プロファイルに切り替えてください: `/gsd-config --profile
|
||||
|
||||
### 手動インストール / Node.js なしのセットアップ
|
||||
|
||||
GSD インストーラーを実行できない場合、`agents/` のソースファイルを直接使用することはできません — これらは Claude Code のネイティブフロントマター形式です。OpenCode では 2 つの変換が必要です:
|
||||
MSD インストーラーを実行できない場合、`agents/` のソースファイルを直接使用することはできません — これらは Claude Code のネイティブフロントマター形式です。OpenCode では 2 つの変換が必要です:
|
||||
|
||||
| フィールド | GSD ソース形式 | OpenCode 対応形式 | アクション |
|
||||
| フィールド | MSD ソース形式 | OpenCode 対応形式 | アクション |
|
||||
|---|---|---|---|
|
||||
| `tools:` | `Read, Bash, Grep`（カンマ区切り文字列） | フロントマターフィールドではない | `tools:` 行を完全に削除する |
|
||||
| `color:` | プレーン CSS カラー名 | 16 進数または OpenCode セマンティック名 | 16 進数に変換するか削除する |
|
||||
@@ -712,26 +712,26 @@ GSD インストーラーを実行できない場合、`agents/` のソースフ
|
||||
**代替案:** Node.js がある任意のマシンでインストーラーを実行します:
|
||||
|
||||
```bash
|
||||
npx @opengsd/gsd-core@latest --opencode --global
|
||||
npx @golem15/msd-core@latest --opencode --global
|
||||
```
|
||||
|
||||
### Cline へのインストール
|
||||
|
||||
```bash
|
||||
npx @opengsd/gsd-core --cline --global # applies to all projects
|
||||
npx @opengsd/gsd-core --cline --local # this project only
|
||||
npx @golem15/msd-core --cline --global # applies to all projects
|
||||
npx @golem15/msd-core --cline --local # this project only
|
||||
```
|
||||
|
||||
### CodeBuddy へのインストール
|
||||
|
||||
```bash
|
||||
npx @opengsd/gsd-core --codebuddy --global
|
||||
npx @golem15/msd-core --codebuddy --global
|
||||
```
|
||||
|
||||
### Qwen Code へのインストール
|
||||
|
||||
```bash
|
||||
npx @opengsd/gsd-core --qwen --global
|
||||
npx @golem15/msd-core --qwen --global
|
||||
```
|
||||
|
||||
### プレリリースエディションへのインストール
|
||||
@@ -739,7 +739,7 @@ npx @opengsd/gsd-core --qwen --global
|
||||
インストーラーを実行する前に、ランタイムの `*_CONFIG_DIR` 環境変数をプレリリースディレクトリに設定してください:
|
||||
|
||||
```bash
|
||||
WINDSURF_CONFIG_DIR=~/.codeium/windsurf-next npx @opengsd/gsd-core@latest --windsurf --global
|
||||
WINDSURF_CONFIG_DIR=~/.codeium/windsurf-next npx @golem15/msd-core@latest --windsurf --global
|
||||
```
|
||||
|
||||
**サポートされているランタイムの環境変数リファレンス:**
|
||||
@@ -762,23 +762,23 @@ WINDSURF_CONFIG_DIR=~/.codeium/windsurf-next npx @opengsd/gsd-core@latest --wind
|
||||
|
||||
### 非 Anthropic プロバイダーでの Claude Code の使用
|
||||
|
||||
`inherit` プロファイルに切り替えてください: `/gsd-config --profile inherit`。これにより、すべてのエージェントが現在のセッションモデルを使用します。
|
||||
`inherit` プロファイルに切り替えてください: `/msd-config --profile inherit`。これにより、すべてのエージェントが現在のセッションモデルを使用します。
|
||||
|
||||
### 機密 / プライベートプロジェクトの作業
|
||||
|
||||
`/gsd-new-project` 中または `/gsd-settings` 経由で `commit_docs: false` を設定してください。`.planning/` を `.gitignore` に追加してください。
|
||||
`/msd-new-project` 中または `/msd-settings` 経由で `commit_docs: false` を設定してください。`.planning/` を `.gitignore` に追加してください。
|
||||
|
||||
### GSD の更新でローカル変更が上書きされた
|
||||
### MSD の更新でローカル変更が上書きされた
|
||||
|
||||
v1.17 以降、インストーラーはローカルで変更されたファイルを `gsd-local-patches/` にバックアップします。変更を元に戻すには `/gsd-update --reapply` を実行してください。
|
||||
v1.17 以降、インストーラーはローカルで変更されたファイルを `msd-local-patches/` にバックアップします。変更を元に戻すには `/msd-update --reapply` を実行してください。
|
||||
|
||||
### npm 経由で更新できない
|
||||
|
||||
手順ごとの手動更新手順は [docs/manual-update.md](../manual-update.md) を参照してください。
|
||||
|
||||
### ワークフロー診断（`/gsd-forensics`）
|
||||
### ワークフロー診断（`/msd-forensics`）
|
||||
|
||||
ワークフローが明らかでない方法で失敗した場合、`/gsd-forensics` を実行して git 履歴の異常、アーティファクトの整合性、状態の不整合を網羅する診断レポートを生成してください。出力は `.planning/forensics/` に保存されます。
|
||||
ワークフローが明らかでない方法で失敗した場合、`/msd-forensics` を実行して git 履歴の異常、アーティファクトの整合性、状態の不整合を網羅する診断レポートを生成してください。出力は `.planning/forensics/` に保存されます。
|
||||
|
||||
### エグゼキューターサブエージェントが Bash コマンドで「Permission denied」になる
|
||||
|
||||
@@ -807,14 +807,14 @@ v1.17 以降、インストーラーはローカルで変更されたファイ
|
||||
|
||||
### 並列実行でビルドロックエラーが発生する
|
||||
|
||||
GSD は v1.26 以降これを自動的に処理します。古いバージョンを使用している場合は、プロジェクトの `CLAUDE.md` に追加してください:
|
||||
MSD は v1.26 以降これを自動的に処理します。古いバージョンを使用している場合は、プロジェクトの `CLAUDE.md` に追加してください:
|
||||
|
||||
```markdown
|
||||
## Git Commit Rules for Agents
|
||||
All subagent/executor commits MUST use `--no-verify`.
|
||||
```
|
||||
|
||||
並列実行を完全に無効にするには: `/gsd-settings` → `parallelization.enabled` を `false` に設定してください。
|
||||
並列実行を完全に無効にするには: `/msd-settings` → `parallelization.enabled` を `false` に設定してください。
|
||||
|
||||
---
|
||||
|
||||
@@ -822,19 +822,19 @@ All subagent/executor commits MUST use `--no-verify`.
|
||||
|
||||
| 問題 | 解決策 |
|
||||
| ------------------------------------ | ------------------------------------------------------------------------ |
|
||||
| コンテキスト喪失 / 新しいセッション | `/gsd-resume-work` または `/gsd-progress` |
|
||||
| コンテキスト喪失 / 新しいセッション | `/msd-resume-work` または `/msd-progress` |
|
||||
| フェーズが失敗した | フェーズのコミットを `git revert` してから再プランする |
|
||||
| スコープを変更する必要がある | `/gsd-phase`（デフォルト）、`/gsd-phase --insert`、または `/gsd-phase --remove` |
|
||||
| 何かが壊れた | `/gsd-debug "description"`（分析のみで修正なしは `--diagnose` を追加） |
|
||||
| スコープを変更する必要がある | `/msd-phase`（デフォルト）、`/msd-phase --insert`、または `/msd-phase --remove` |
|
||||
| 何かが壊れた | `/msd-debug "description"`（分析のみで修正なしは `--diagnose` を追加） |
|
||||
| STATE.md の同期ずれ | `state validate` してから `state sync` |
|
||||
| ワークフロー状態が破損しているように見える | `/gsd-forensics` |
|
||||
| クイックなターゲット修正 | `/gsd-quick` |
|
||||
| プランがビジョンと一致しない | `/gsd-discuss-phase [N]` してから再プランする |
|
||||
| コストが高騰している | `/gsd-config --profile budget` と `/gsd-settings` でエージェントをオフに |
|
||||
| 更新でローカル変更が壊れた | `/gsd-update --reapply` |
|
||||
| ステークホルダー向けセッションサマリーが欲しい | `/gsd-pause-work --report` |
|
||||
| 次のステップがわからない | `/gsd-progress --next` |
|
||||
| 並列実行でビルドエラーが発生する | GSD を更新するか `parallelization.enabled: false` を設定する |
|
||||
| ワークフロー状態が破損しているように見える | `/msd-forensics` |
|
||||
| クイックなターゲット修正 | `/msd-quick` |
|
||||
| プランがビジョンと一致しない | `/msd-discuss-phase [N]` してから再プランする |
|
||||
| コストが高騰している | `/msd-config --profile budget` と `/msd-settings` でエージェントをオフに |
|
||||
| 更新でローカル変更が壊れた | `/msd-update --reapply` |
|
||||
| ステークホルダー向けセッションサマリーが欲しい | `/msd-pause-work --report` |
|
||||
| 次のステップがわからない | `/msd-progress --next` |
|
||||
| 並列実行でビルドエラーが発生する | MSD を更新するか `parallelization.enabled: false` を設定する |
|
||||
|
||||
---
|
||||
|
||||
@@ -848,24 +848,24 @@ All subagent/executor commits MUST use `--no-verify`.
|
||||
STATE.md # Decisions, blockers, session memory
|
||||
config.json # Workflow configuration
|
||||
MILESTONES.md # Completed milestone archive
|
||||
HANDOFF.json # Structured session handoff (from /gsd-pause-work)
|
||||
research/ # Domain research from /gsd-new-project
|
||||
reports/ # Session reports (from /gsd-pause-work --report)
|
||||
HANDOFF.json # Structured session handoff (from /msd-pause-work)
|
||||
research/ # Domain research from /msd-new-project
|
||||
reports/ # Session reports (from /msd-pause-work --report)
|
||||
todos/
|
||||
pending/ # Captured ideas awaiting work
|
||||
completed/ # Completed todos
|
||||
debug/ # Active debug sessions
|
||||
resolved/ # Archived debug sessions
|
||||
spikes/ # Feasibility experiments (from /gsd-spike)
|
||||
spikes/ # Feasibility experiments (from /msd-spike)
|
||||
NNN-name/ # Experiment code + README with verdict
|
||||
MANIFEST.md # Index of all spikes
|
||||
sketches/ # HTML mockups (from /gsd-sketch)
|
||||
sketches/ # HTML mockups (from /msd-sketch)
|
||||
NNN-name/ # index.html (2-3 variants) + README
|
||||
themes/
|
||||
default.css # Shared CSS variables for all sketches
|
||||
MANIFEST.md # Index of all sketches with winners
|
||||
codebase/ # Brownfield codebase mapping (from /gsd-map-codebase or /gsd-onboard)
|
||||
onboarding/ # Brownfield onboarding summary (from /gsd-onboard)
|
||||
codebase/ # Brownfield codebase mapping (from /msd-map-codebase or /msd-onboard)
|
||||
onboarding/ # Brownfield onboarding summary (from /msd-onboard)
|
||||
phases/
|
||||
XX-phase-name/
|
||||
XX-YY-PLAN.md # Atomic execution plans
|
||||
@@ -873,9 +873,9 @@ All subagent/executor commits MUST use `--no-verify`.
|
||||
CONTEXT.md # Your implementation preferences
|
||||
RESEARCH.md # Ecosystem research findings
|
||||
VERIFICATION.md # Post-execution verification results
|
||||
XX-UI-SPEC.md # UI design contract (from /gsd-ui-phase)
|
||||
XX-UI-REVIEW.md # Visual audit scores (from /gsd-ui-review)
|
||||
ui-reviews/ # Screenshots from /gsd-ui-review (gitignored)
|
||||
XX-UI-SPEC.md # UI design contract (from /msd-ui-phase)
|
||||
XX-UI-REVIEW.md # Visual audit scores (from /msd-ui-review)
|
||||
ui-reviews/ # Screenshots from /msd-ui-review (gitignored)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
@@ -19,7 +19,7 @@
|
||||
|-------|-----------|----------------|
|
||||
| Normal | > 35% | 警告なし |
|
||||
| WARNING | <= 35% | 現在のタスクをまとめ、新しい複雑な作業の開始を避ける |
|
||||
| CRITICAL | <= 25% | 即座に停止し、状態を保存する（`/gsd-pause-work`） |
|
||||
| CRITICAL | <= 25% | 即座に停止し、状態を保存する（`/msd-pause-work`） |
|
||||
|
||||
## デバウンス
|
||||
|
||||
@@ -31,13 +31,13 @@
|
||||
## アーキテクチャ
|
||||
|
||||
```
|
||||
Statusline Hook (gsd-statusline.js)
|
||||
Statusline Hook (msd-statusline.js)
|
||||
| writes
|
||||
v
|
||||
/tmp/claude-ctx-{session_id}.json
|
||||
^ reads
|
||||
|
|
||||
Context Monitor (gsd-context-monitor.js, PostToolUse/AfterTool)
|
||||
Context Monitor (msd-context-monitor.js, PostToolUse/AfterTool)
|
||||
| injects
|
||||
v
|
||||
additionalContext -> Agent sees warning
|
||||
@@ -54,15 +54,15 @@ additionalContext -> Agent sees warning
|
||||
}
|
||||
```
|
||||
|
||||
## GSD との統合
|
||||
## MSD との統合
|
||||
|
||||
GSD の `/gsd-pause-work` コマンドは実行状態を保存します。WARNING メッセージはこのコマンドの使用を提案し、CRITICAL メッセージは即座の状態保存を指示します。
|
||||
MSD の `/msd-pause-work` コマンドは実行状態を保存します。WARNING メッセージはこのコマンドの使用を提案し、CRITICAL メッセージは即座の状態保存を指示します。
|
||||
|
||||
## セットアップ
|
||||
|
||||
両フックは `npx @opengsd/gsd-core` のインストール時に自動的に登録されます——通常の状況では手動の手順は不要です。フック設定の詳細、しきい値のオーバーライド、手動登録の例については、[設定](CONFIGURATION.md) を参照してください。
|
||||
両フックは `npx @golem15/msd-core` のインストール時に自動的に登録されます——通常の状況では手動の手順は不要です。フック設定の詳細、しきい値のオーバーライド、手動登録の例については、[設定](CONFIGURATION.md) を参照してください。
|
||||
|
||||
簡単な参考として：ステータスラインフックは `settings.json` に `statusLine` として登録されます；コンテキストモニター（`gsd-context-monitor.js`）は `PostToolUse` フックとして登録されます（Antigravity CLI の場合は `AfterTool`）。どちらのエントリも、インストーラーを実行した Node 実行ファイルの絶対パスを使います。Windows PowerShell では、引用符付きの実行ファイルパスに `&` をプレフィックスしてください。
|
||||
簡単な参考として：ステータスラインフックは `settings.json` に `statusLine` として登録されます；コンテキストモニター（`msd-context-monitor.js`）は `PostToolUse` フックとして登録されます（Antigravity CLI の場合は `AfterTool`）。どちらのエントリも、インストーラーを実行した Node 実行ファイルの絶対パスを使います。Windows PowerShell では、引用符付きの実行ファイルパスに `&` をプレフィックスしてください。
|
||||
|
||||
## 安全性
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# コンテキストエンジニアリング
|
||||
|
||||
> GSD Core が存在する理由、そして解決しようとしている問題。
|
||||
> MSD Core が存在する理由、そして解決しようとしている問題。
|
||||
|
||||
---
|
||||
|
||||
@@ -23,15 +23,15 @@ AI コーディングセッションは常に新鮮な状態から始まりま
|
||||
|
||||
---
|
||||
|
||||
## GSD Core の答え：フレッシュコンテキストサブエージェント
|
||||
## MSD Core の答え：フレッシュコンテキストサブエージェント
|
||||
|
||||
GSD Core の核心的な洞察は、コーディングセッションの作業の *ほとんど* はメインコンテキストで行う必要がそもそもないということです。調査、計画立案、コード作成、検証はそれぞれ独立した、境界が明確なタスクです。それぞれを専門化されたサブエージェントに渡すことができます。そのエージェントはクリーンで慎重にスコープされたコンテキストウィンドウで開始し、結果をスリムなオーケストレーターに報告します。
|
||||
MSD Core の核心的な洞察は、コーディングセッションの作業の *ほとんど* はメインコンテキストで行う必要がそもそもないということです。調査、計画立案、コード作成、検証はそれぞれ独立した、境界が明確なタスクです。それぞれを専門化されたサブエージェントに渡すことができます。そのエージェントはクリーンで慎重にスコープされたコンテキストウィンドウで開始し、結果をスリムなオーケストレーターに報告します。
|
||||
|
||||
これはコンテキスト腐敗への迂回策ではありません。構造的な解決策です。
|
||||
|
||||
オーケストレーター——あなたのメインセッション——はソースファイルに触れません。エージェントを生成し、その結果を収集し、共有状態を更新し、次のステップへとルーティングします。自身がほとんど何もしないため、そのコンテキストウィンドウはゆっくりと予測可能に拡大します。重い作業はそれぞれ新鮮な状態で開始し、タスクに必要なコンテキストだけを受け取り、完了したら終了するエージェントの中で行われます。
|
||||
|
||||
これが実際にどういう意味かを考えてみましょう。`/gsd-plan-phase` を実行すると、オーケストレーターは：
|
||||
これが実際にどういう意味かを考えてみましょう。`/msd-plan-phase` を実行すると、オーケストレーターは：
|
||||
|
||||
1. コンパクトな JSON コンテキストペイロード（プロジェクト概要、フェーズ目標、関連設定）を読み込む。
|
||||
2. 200k トークンのクリーンなウィンドウで調査エージェントを生成する。
|
||||
@@ -44,11 +44,11 @@ GSD Core の核心的な洞察は、コーディングセッションの作業
|
||||
|
||||
## 仕様駆動開発とメタプロンプティング
|
||||
|
||||
コンテキストエンジニアリング単体では不十分です。エージェントが新鮮な状態で開始しても、曖昧な指示を受け取れば、曖昧な出力を生み出します。GSD Core はフレッシュコンテキストサブエージェントと 2 つの補完的な規律を組み合わせています。
|
||||
コンテキストエンジニアリング単体では不十分です。エージェントが新鮮な状態で開始しても、曖昧な指示を受け取れば、曖昧な出力を生み出します。MSD Core はフレッシュコンテキストサブエージェントと 2 つの補完的な規律を組み合わせています。
|
||||
|
||||
**仕様駆動開発** とは、すべてのフェーズが実行開始前に構造化されたアーティファクトを生成することを意味します。`CONTEXT.md` は Discuss ステップでの実装上の決定を記録します。`RESEARCH.md` は調査エージェントが見つけたものを記録します。`PLAN.md` は作業を独立した、依存関係の順序に従ったタスクに分解し、明確な受け入れ基準を持ちます。エグゼキューターエージェントがファイルに触れる時点では、長い会話の再解釈ではなく、正確な仕様から作業します。
|
||||
|
||||
**メタプロンプティング** とは、エージェント定義自体が慎重に設計されたプロンプトであり、アドホックな指示ではないことを意味します。`gsd-core/workflows/` および `agents/` 内のファイルは、タスクのスコープの決め方、何を検証するか、いつ人間のチェックポイントにエスカレートするかについての実践的な知識をエンコードしています。ユーザーはこの知識をセッションごとに再説明する必要はありません。それはシステム自身のプロンプトに組み込まれています。
|
||||
**メタプロンプティング** とは、エージェント定義自体が慎重に設計されたプロンプトであり、アドホックな指示ではないことを意味します。`msd-core/workflows/` および `agents/` 内のファイルは、タスクのスコープの決め方、何を検証するか、いつ人間のチェックポイントにエスカレートするかについての実践的な知識をエンコードしています。ユーザーはこの知識をセッションごとに再説明する必要はありません。それはシステム自身のプロンプトに組み込まれています。
|
||||
|
||||
この組み合わせは意図的です。フレッシュコンテキストは各エージェントが明確に推論することを保証します。仕様駆動のアーティファクトは各エージェントが *正しい* ことについて推論することを保証します。メタプロンプティングは各エージェントが *うまく* 推論する方法を知っていることを保証します。
|
||||
|
||||
@@ -56,7 +56,7 @@ GSD Core の核心的な洞察は、コーディングセッションの作業
|
||||
|
||||
## `.planning/` の役割
|
||||
|
||||
コンテキストエンジニアリングには、知識がコンテキストリセットを超えて生き残ることが必要です。GSD Core はこのためにファイルシステムを使用します。すべての意味のある出力は、人間が読める Markdown または JSON として `.planning/` に書き込まれます。これが意味することは：
|
||||
コンテキストエンジニアリングには、知識がコンテキストリセットを超えて生き残ることが必要です。MSD Core はこのためにファイルシステムを使用します。すべての意味のある出力は、人間が読める Markdown または JSON として `.planning/` に書き込まれます。これが意味することは：
|
||||
|
||||
- セッションを再起動しても（またはモデルがクラッシュしても）作業が失われない。
|
||||
- 後続のエージェントは共有された会話履歴に依存せず、以前のアーティファクトを直接読み取ることができる。
|
||||
@@ -70,11 +70,11 @@ GSD Core の核心的な洞察は、コーディングセッションの作業
|
||||
|
||||
ここではトレードオフについて正直に述べることが重要です。
|
||||
|
||||
**オーバーヘッド。** フェーズループには実際の摩擦があります。`/gsd-discuss-phase`、`/gsd-plan-phase`、`/gsd-execute-phase` を別々のステップとして実行することは、普通のセッションに「この機能を書いて」と入力するよりも多くの経過時間がかかります。小さくてよく理解された変更に対しては、そのオーバーヘッドは正当化されません。
|
||||
**オーバーヘッド。** フェーズループには実際の摩擦があります。`/msd-discuss-phase`、`/msd-plan-phase`、`/msd-execute-phase` を別々のステップとして実行することは、普通のセッションに「この機能を書いて」と入力するよりも多くの経過時間がかかります。小さくてよく理解された変更に対しては、そのオーバーヘッドは正当化されません。
|
||||
|
||||
**レイテンシ。** 新鮮なコンテキストで複数のサブエージェントを生成することは、単一のインコンテキスト編集より遅くなります。調査、計画立案、実行のそれぞれにラウンドトリップのコストが発生します。
|
||||
|
||||
**シンプルなタスクへの過剰な手続き。** 変数名を変更したり、タイポを修正したり、欠落しているインポートを追加したりする場合、フェーズループは過剰です。GSD Core は完全なフェーズを必要としないアドホックな作業のために `/gsd-quick` と `/gsd-fast` を提供します。[クイックタスクとファストタスクの処理](../how-to/handle-quick-and-fast-tasks.md) を参照してください。
|
||||
**シンプルなタスクへの過剰な手続き。** 変数名を変更したり、タイポを修正したり、欠落しているインポートを追加したりする場合、フェーズループは過剰です。MSD Core は完全なフェーズを必要としないアドホックな作業のために `/msd-quick` と `/msd-fast` を提供します。[クイックタスクとファストタスクの処理](../how-to/handle-quick-and-fast-tasks.md) を参照してください。
|
||||
|
||||
フェーズループは、コンテキスト腐敗が本当のリスクになるほど作業が複雑な場合——マルチファイル機能、横断的なリファクタリング、時間やセッションをまたぐ作業——に価値を発揮します。それ以外のすべてには、より軽量なプリミティブを使ってください。
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# GSD Core におけるマルチエージェントオーケストレーション
|
||||
# MSD Core におけるマルチエージェントオーケストレーション
|
||||
|
||||
> **解説** — このドキュメントは、GSD Core がマルチエージェントオーケストレーションを中心に設計されている *理由* と、*各部品がどのように組み合わさるか* を説明します。ステップバイステップのガイドではありません。設定については、[モデルプロファイルの設定](../how-to/configure-model-profiles.md) と [設定リファレンス](../CONFIGURATION.md) を参照してください。完全なエージェントロスターについては、[インベントリ](../INVENTORY.md) を参照してください。
|
||||
> **解説** — このドキュメントは、MSD Core がマルチエージェントオーケストレーションを中心に設計されている *理由* と、*各部品がどのように組み合わさるか* を説明します。ステップバイステップのガイドではありません。設定については、[モデルプロファイルの設定](../how-to/configure-model-profiles.md) と [設定リファレンス](../CONFIGURATION.md) を参照してください。完全なエージェントロスターについては、[インベントリ](../INVENTORY.md) を参照してください。
|
||||
|
||||
---
|
||||
|
||||
@@ -8,23 +8,23 @@
|
||||
|
||||
AI コーディングエージェントは劣化します。モデルが悪くなるからではなく、*コンテキストウィンドウが満杯になる* からです。会話が大きくなるにつれて、以前の決定やコードは中間ステップのノイズによって押し出されるか薄められます。複雑なタスクで 5 番目のファイルを書く頃には、エージェントは最初のメッセージで述べた制約をすでに忘れているかもしれません。これは *コンテキスト腐敗* と呼ばれることがあります。
|
||||
|
||||
GSD Core のマルチエージェント設計はその問題への直接的な応答です。セッション全体を抱える一つの長期実行エージェントの代わりに、薄いオーケストレーターが短命の専門化されたエージェントを生成します。それぞれが **フレッシュな 200K トークンのコンテキストウィンドウ** と、自分の特定の仕事をするために必要な *アーティファクトだけ* を持ちます。オーケストレーターは自分では重い作業をしません。コンテキストを読み込み、適切なエージェントを生成し、結果を収集し、`.planning/` の共有状態を更新します。
|
||||
MSD Core のマルチエージェント設計はその問題への直接的な応答です。セッション全体を抱える一つの長期実行エージェントの代わりに、薄いオーケストレーターが短命の専門化されたエージェントを生成します。それぞれが **フレッシュな 200K トークンのコンテキストウィンドウ** と、自分の特定の仕事をするために必要な *アーティファクトだけ* を持ちます。オーケストレーターは自分では重い作業をしません。コンテキストを読み込み、適切なエージェントを生成し、結果を収集し、`.planning/` の共有状態を更新します。
|
||||
|
||||
---
|
||||
|
||||
## オーケストレーター → エージェントパターン
|
||||
|
||||
`gsd-core/workflows/` のすべてのワークフローは同じ形を持ちます：
|
||||
`msd-core/workflows/` のすべてのワークフローは同じ形を持ちます：
|
||||
|
||||
```text
|
||||
Orchestrator（ワークフロー .md ファイル）
|
||||
│
|
||||
├── コンテキスト読み込み
|
||||
│ gsd-tools.cjs init <workflow> <phase>
|
||||
│ msd-tools.cjs init <workflow> <phase>
|
||||
│ → JSON: プロジェクト情報、設定、状態、フェーズ詳細
|
||||
│
|
||||
├── モデル解決
|
||||
│ gsd-tools.cjs resolve-model <agent-name>
|
||||
│ msd-tools.cjs resolve-model <agent-name>
|
||||
│ → opus | sonnet | haiku | inherit
|
||||
│
|
||||
├── 専門化エージェント生成（Task/SubAgent 呼び出し）
|
||||
@@ -36,25 +36,25 @@ Orchestrator（ワークフロー .md ファイル）
|
||||
├── 結果収集
|
||||
│
|
||||
└── 状態更新
|
||||
gsd-tools.cjs state update / state patch / state advance-plan
|
||||
msd-tools.cjs state update / state patch / state advance-plan
|
||||
```
|
||||
|
||||
オーケストレーターは意図的に薄く保たれています。ドメインについて推論せず、コードを書かず、次のステップへルーティングする以上に結果を解釈しません。この境界により各レイヤーの責任が明確になり、オーケストレーターのコンテキストにドメインノイズが蓄積するのを防ぎます。
|
||||
|
||||
### エージェントロスター
|
||||
|
||||
GSD Core のエージェントは、調査 → 計画 → 実行 → 検証パイプラインにマッピングされる機能カテゴリに分類されます：
|
||||
MSD Core のエージェントは、調査 → 計画 → 実行 → 検証パイプラインにマッピングされる機能カテゴリに分類されます：
|
||||
|
||||
| カテゴリ | エージェント | 典型的な並列性 |
|
||||
|---|---|---|
|
||||
| 調査者 | `gsd-project-researcher`、`gsd-phase-researcher`、`gsd-ui-researcher`、`gsd-advisor-researcher` | 4 並列（スタック、機能、アーキテクチャ、落とし穴） |
|
||||
| 合成者 | `gsd-research-synthesizer` | 調査者完了後、順次実行 |
|
||||
| プランナー | `gsd-planner`、`gsd-roadmapper` | 順次実行 |
|
||||
| チェッカー | `gsd-plan-checker`、`gsd-integration-checker`、`gsd-ui-checker`、`gsd-nyquist-auditor` | 順次実行、最大 3 回の修正反復 |
|
||||
| エグゼキューター | `gsd-executor` | ウェーブ内並列、ウェーブ間順次 |
|
||||
| 検証者 | `gsd-verifier` | すべてのエグゼキューター完了後、順次実行 |
|
||||
| マッパー | `gsd-codebase-mapper` | 4 並列サブプローブ |
|
||||
| 監査者 | `gsd-ui-auditor`、`gsd-security-auditor` | 順次実行 |
|
||||
| 調査者 | `msd-project-researcher`、`msd-phase-researcher`、`msd-ui-researcher`、`msd-advisor-researcher` | 4 並列（スタック、機能、アーキテクチャ、落とし穴） |
|
||||
| 合成者 | `msd-research-synthesizer` | 調査者完了後、順次実行 |
|
||||
| プランナー | `msd-planner`、`msd-roadmapper` | 順次実行 |
|
||||
| チェッカー | `msd-plan-checker`、`msd-integration-checker`、`msd-ui-checker`、`msd-nyquist-auditor` | 順次実行、最大 3 回の修正反復 |
|
||||
| エグゼキューター | `msd-executor` | ウェーブ内並列、ウェーブ間順次 |
|
||||
| 検証者 | `msd-verifier` | すべてのエグゼキューター完了後、順次実行 |
|
||||
| マッパー | `msd-codebase-mapper` | 4 並列サブプローブ |
|
||||
| 監査者 | `msd-ui-auditor`、`msd-security-auditor` | 順次実行 |
|
||||
|
||||
各エージェント定義（`agents/*.md` 内）は、許可されたツールアクセス、目的、ターミナル出力の色を宣言します。ファイルを読み取り、単一の出力ドキュメントを書くだけでよいエージェントには、まさにその権限だけが与えられます——Bash 実行なし、より広い状態へのアクセスなし。この制約は意図的です：エージェントが予期しない動作をした場合の影響範囲を小さく保ちます。
|
||||
|
||||
@@ -64,7 +64,7 @@ GSD Core のエージェントは、調査 → 計画 → 実行 → 検証パ
|
||||
|
||||
## ウェーブベースの並行実行
|
||||
|
||||
マルチエージェント設計の最も目に見える表れは、`/gsd-execute-phase` が互いに依存しあうことのある計画セットをどう処理するかです。
|
||||
マルチエージェント設計の最も目に見える表れは、`/msd-execute-phase` が互いに依存しあうことのある計画セットをどう処理するかです。
|
||||
|
||||
エグゼキューターを生成する前に、オーケストレーターは **ウェーブ分析** を実行します：各 `PLAN.md` ファイルの依存関係宣言を読み取り、計画をウェーブにグループ化します。宣言された依存関係がない計画がウェーブ 1 を形成し、並列に実行されます。ウェーブ 1 に依存する計画がウェーブ 2 を形成し、以下同様です。
|
||||
|
||||
@@ -116,7 +116,7 @@ Plan 05（依存: 03, 04） ─── ウェーブ 3（ウェーブ 2 待ち
|
||||
|
||||
**コンテキストの分離。** 各エージェントは必要なものだけを受け取ります。調査者はプロジェクト説明とドメイン質問を受け取ります；完全な計画履歴は受け取りません。検証者はすべての計画とサマリーを受け取ります；生の調査は受け取りません。分離により各エージェントのコンテキストは他のパイプラインステージのノイズで薄まるのではなく、シグナルで密度が高く保たれます。
|
||||
|
||||
**セッションをまたいだコンテキストの衛生。** すべての状態は（エージェントのコンテキストウィンドウではなく）`.planning/` に人間が読める Markdown と JSON として存在するため、GSD ワークフローはコンテキストリセット（`/clear`）、タブ切り替え、複数日のブレークを超えて生き残ります。次のエージェントは常に、長い会話の再構築された記憶からではなく、永続化され検証されたアーティファクトから開始します。
|
||||
**セッションをまたいだコンテキストの衛生。** すべての状態は（エージェントのコンテキストウィンドウではなく）`.planning/` に人間が読める Markdown と JSON として存在するため、MSD ワークフローはコンテキストリセット（`/clear`）、タブ切り替え、複数日のブレークを超えて生き残ります。次のエージェントは常に、長い会話の再構築された記憶からではなく、永続化され検証されたアーティファクトから開始します。
|
||||
|
||||
---
|
||||
|
||||
@@ -124,11 +124,11 @@ Plan 05（依存: 03, 04） ─── ウェーブ 3（ウェーブ 2 待ち
|
||||
|
||||
マルチエージェントオーケストレーションはタダではありません。
|
||||
|
||||
**調整オーバーヘッド。** 各エージェントの生成はラウンドトリップです：オーケストレーターがプロンプトをフォーマットし、コンテキストを渡し、サブエージェントが完了するまで待ち（通常 1〜5 分）、結果を解析する必要があります。一つのコンテキストで作業する一つの有能なエージェントは、シンプルなタスクをより速く終わらせるでしょう。GSD は依存関係が許す限りデフォルトで並列性を採用することでこれを軽減します——`plan-phase` の 4 人の調査者は順次ではなく同時に実行されます。
|
||||
**調整オーバーヘッド。** 各エージェントの生成はラウンドトリップです：オーケストレーターがプロンプトをフォーマットし、コンテキストを渡し、サブエージェントが完了するまで待ち（通常 1〜5 分）、結果を解析する必要があります。一つのコンテキストで作業する一つの有能なエージェントは、シンプルなタスクをより速く終わらせるでしょう。MSD は依存関係が許す限りデフォルトで並列性を採用することでこれを軽減します——`plan-phase` の 4 人の調査者は順次ではなく同時に実行されます。
|
||||
|
||||
**実行中の不透明性。** サブエージェントの実行中は、その作業は親セッションには見えません。ライブの進捗ストリームはありません。これはフレッシュコンテキスト設計の意図的な帰結です：サブエージェントは自分自身のコンテキストウィンドウで動作しています。オーケストレーターは生成ラインに生存通知を表示します（「サブエージェントで実行中——返ってくるまで出力なし」）で期待値を設定します。
|
||||
|
||||
**コンテキストスティッチングコスト。** 各エージェントに適切なアーティファクトをパッケージ化するには、オーケストレーターがコンテキストペイロードを組み立てて送信するためにトークンを使う必要があります。これが分離のコストです。`gsd-tools.cjs init` ハンドラーは、完全性とトークン予算のバランスを取る JSON ペイロードを生成し、繰り返し呼び出しでキャッシュにヒットするようにペイロードの安定した部分（プロジェクト定義、設定）にキャッシュフレンドリーな順序を適用します。
|
||||
**コンテキストスティッチングコスト。** 各エージェントに適切なアーティファクトをパッケージ化するには、オーケストレーターがコンテキストペイロードを組み立てて送信するためにトークンを使う必要があります。これが分離のコストです。`msd-tools.cjs init` ハンドラーは、完全性とトークン予算のバランスを取る JSON ペイロードを生成し、繰り返し呼び出しでキャッシュにヒットするようにペイロードの安定した部分（プロジェクト定義、設定）にキャッシュフレンドリーな順序を適用します。
|
||||
|
||||
**モデルコストの増幅。** Opus 層で 5 つのエージェントを並行して実行することは、1 つを実行するよりコストがかかります。モデルプロファイルシステム（`model_profiles.md`、`model-profiles.cjs` でエージェントごとに解決）により、重要度の低いエージェントに安価な層を割り当てることができます。`dynamic_routing` 機能は、すべてのエージェントを安価な層で開始し、ソフトフェイラー時にのみエスカレートすることでさらにコストを削減します。詳細なオプションについては [設定](../CONFIGURATION.md) を参照してください。
|
||||
|
||||
|
||||
@@ -1,14 +1,14 @@
|
||||
# GSD Core セキュリティモデル
|
||||
# MSD Core セキュリティモデル
|
||||
|
||||
> **解説** — このドキュメントは、GSD Core がなぜこのようなセキュリティ姿勢を持っているか、そして *各レイヤーがどのように組み合わさるか* を説明します。すべてのフックパラメーターのリファレンスではありません。`/gsd-secure-phase` コマンドとそのオプションについては、[コマンド](../COMMANDS.md) を参照してください。実装レベルのフックアーキテクチャについては、[アーキテクチャ § フックシステム](../ARCHITECTURE.md#hook-system) を参照してください。組織全体のセキュリティベースライン（スキャナー制御、インシデントチェックリスト、所有権モデル）については、[SECURITY.md](../../../SECURITY.md) を参照してください。
|
||||
> **解説** — このドキュメントは、MSD Core がなぜこのようなセキュリティ姿勢を持っているか、そして *各レイヤーがどのように組み合わさるか* を説明します。すべてのフックパラメーターのリファレンスではありません。`/msd-secure-phase` コマンドとそのオプションについては、[コマンド](../COMMANDS.md) を参照してください。実装レベルのフックアーキテクチャについては、[アーキテクチャ § フックシステム](../ARCHITECTURE.md#hook-system) を参照してください。組織全体のセキュリティベースライン（スキャナー制御、インシデントチェックリスト、所有権モデル）については、[SECURITY.md](../../../SECURITY.md) を参照してください。
|
||||
|
||||
---
|
||||
|
||||
## AI 駆動開発が専用のセキュリティ姿勢を必要とする理由
|
||||
|
||||
従来のコードエディターはあなたに代わって任意のパッケージを実行しません。GSD Core は実行します。調査 → 計画 → 実行パイプラインは「パッケージ名を指定する」から「`npm install <package>` を実行する」まで、「計画アーティファクトを書く」から「そのアーティファクトを LLM システムプロンプトとして使う」までの完全なパスを自動化します。各自動化ステップは人間をループから外します——そして各除去は潜在的な攻撃面です。
|
||||
従来のコードエディターはあなたに代わって任意のパッケージを実行しません。MSD Core は実行します。調査 → 計画 → 実行パイプラインは「パッケージ名を指定する」から「`npm install <package>` を実行する」まで、「計画アーティファクトを書く」から「そのアーティファクトを LLM システムプロンプトとして使う」までの完全なパスを自動化します。各自動化ステップは人間をループから外します——そして各除去は潜在的な攻撃面です。
|
||||
|
||||
GSD Core のセキュリティモデルは一つの組織原則の上に構築されています：**多層防御**。単一の制御が完璧だとは想定しません。複数の重複したレイヤーがそれぞれ異なるクラスのリスクを軽減し、合わせて全体を完全に排除することなく攻撃面を実質的に悪用しにくくします。このドキュメントの末尾にある正直な要約は、システムが何に対して保護できないかを説明します。
|
||||
MSD Core のセキュリティモデルは一つの組織原則の上に構築されています：**多層防御**。単一の制御が完璧だとは想定しません。複数の重複したレイヤーがそれぞれ異なるクラスのリスクを軽減し、合わせて全体を完全に排除することなく攻撃面を実質的に悪用しにくくします。このドキュメントの末尾にある正直な要約は、システムが何に対して保護できないかを説明します。
|
||||
|
||||
---
|
||||
|
||||
@@ -18,17 +18,17 @@ GSD Core のセキュリティモデルは一つの組織原則の上に構築
|
||||
|
||||
AI モデルはパッケージ名を幻覚します。これはまれな失敗モードではありません：2025 年の研究では、AI が生成するパッケージ参照のおよそ 20% が正規のパッケージに対応しない幻覚された名前であることが記録されています。これらの幻覚された名前のサブセット——同じ研究でおよそ 43%——はプロンプトをまたいで一貫して繰り返され、攻撃者は AI ツールが一般的に生成する名前を観察し、npm、PyPI、または crates.io でそれらの名前を悪意のあるポストインストールスクリプト付きで事前登録できます。この技術は *スロップスクワッティング* と呼ばれます。
|
||||
|
||||
スロップスクワッティングの陰湿な点は、`npm view` を通過する幻覚された名前が *正当に見える* ことです。レジストリエントリは誰かがその名前を登録したことを証明するだけです——パッケージが AI の言う通りのことをするとも、正規のユーザーがいるとも、インストールスクリプトが安全だとも証明しません。ゲートがなければ、幻覚された名前は GSD の調査者 → プランナー → エグゼキューターパイプラインを検出されずに流れ、最終的にあなたのマシンで `npm install <attacker-package>` として実行されるでしょう。
|
||||
スロップスクワッティングの陰湿な点は、`npm view` を通過する幻覚された名前が *正当に見える* ことです。レジストリエントリは誰かがその名前を登録したことを証明するだけです——パッケージが AI の言う通りのことをするとも、正規のユーザーがいるとも、インストールスクリプトが安全だとも証明しません。ゲートがなければ、幻覚された名前は MSD の調査者 → プランナー → エグゼキューターパイプラインを検出されずに流れ、最終的にあなたのマシンで `npm install <attacker-package>` として実行されるでしょう。
|
||||
|
||||
### ゲートの仕組み
|
||||
|
||||
ゲートは 3 つのパイプラインステージにわたって動作します：
|
||||
|
||||
**調査ステージ。** `gsd-phase-researcher` が外部パッケージを推奨するとき、それぞれに対して `gsd-tools query package-legitimacy check --ecosystem <npm|pypi|crates> <pkgs>` を実行します。評決（`OK|SUS|SLOP`）はライブのレジストリ API から、しきい値 `{ minAgeDays: 30, minWeeklyDownloads: 1000, requireRepo: true }` に基づいて計算され、非存在および疑わしい `postinstall` スクリプトに対する終端ショートサーキットも含まれます。結果は `RESEARCH.md` の `## Package Legitimacy Audit` テーブルに書き込まれます。`[SLOP]`（高信頼度の幻覚または攻撃者登録済み）とタグ付けされたパッケージは、ファイルが保存される前に **`RESEARCH.md` から完全に除去されます**。それらはプランナーに届きません。
|
||||
**調査ステージ。** `msd-phase-researcher` が外部パッケージを推奨するとき、それぞれに対して `msd-tools query package-legitimacy check --ecosystem <npm|pypi|crates> <pkgs>` を実行します。評決（`OK|SUS|SLOP`）はライブのレジストリ API から、しきい値 `{ minAgeDays: 30, minWeeklyDownloads: 1000, requireRepo: true }` に基づいて計算され、非存在および疑わしい `postinstall` スクリプトに対する終端ショートサーキットも含まれます。結果は `RESEARCH.md` の `## Package Legitimacy Audit` テーブルに書き込まれます。`[SLOP]`（高信頼度の幻覚または攻撃者登録済み）とタグ付けされたパッケージは、ファイルが保存される前に **`RESEARCH.md` から完全に除去されます**。それらはプランナーに届きません。
|
||||
|
||||
**計画ステージ。** `gsd-planner` は監査テーブルを読み取ります。`[SUS]`（疑わしい：新規登録、低ダウンロード数、ソースリポジトリなし、または人気パッケージに近い命名パターン）または `[ASSUMED]`（直接レジストリ検証ではなく WebSearch から取得）とタグ付けされたパッケージについて、プランナーはインストールステップの前に **`checkpoint:human-verify` タスクを挿入します**。チェックポイントにはレジストリページへの直接リンクと、確認すべき具体的な事項が含まれます：メンテナー履歴、イシュートラッカーの活動、疑わしいインストールスクリプトがないこと。
|
||||
**計画ステージ。** `msd-planner` は監査テーブルを読み取ります。`[SUS]`（疑わしい：新規登録、低ダウンロード数、ソースリポジトリなし、または人気パッケージに近い命名パターン）または `[ASSUMED]`（直接レジストリ検証ではなく WebSearch から取得）とタグ付けされたパッケージについて、プランナーはインストールステップの前に **`checkpoint:human-verify` タスクを挿入します**。チェックポイントにはレジストリページへの直接リンクと、確認すべき具体的な事項が含まれます：メンテナー履歴、イシュートラッカーの活動、疑わしいインストールスクリプトがないこと。
|
||||
|
||||
**実行ステージ。** インストールが失敗した場合、`gsd-executor` は**チェックポイントを表示して停止します**。それ自体が悪意のある可能性のある代替パッケージ名をサイレントに試みません。これはエグゼキューターの動作における明示的なルールです（エグゼキュータエージェント定義の RULE 3）。
|
||||
**実行ステージ。** インストールが失敗した場合、`msd-executor` は**チェックポイントを表示して停止します**。それ自体が悪意のある可能性のある代替パッケージ名をサイレントに試みません。これはエグゼキューターの動作における明示的なルールです（エグゼキュータエージェント定義の RULE 3）。
|
||||
|
||||
### WebSearch パッケージが常に `[ASSUMED]` である理由
|
||||
|
||||
@@ -56,36 +56,36 @@ WebSearch を通じて発見されたパッケージ名は、`npm view` が成
|
||||
|
||||
### 脅威
|
||||
|
||||
GSD Core は LLM システムプロンプトになる Markdown ファイルを生成します。調査パイプラインは外部ウェブコンテンツを読み取ります；計画パイプラインはユーザー提供のテキスト（`--text-file`、`--prd`）を組み込みます；実行パイプラインは後でエージェントコンテキストとして再読み取りされる計画アーティファクトを書きます。これらのアーティファクトに流れ込む任意のユーザー制御テキストは、潜在的な **間接プロンプトインジェクション** ベクターです——一度システムプロンプトの中に入ると、エージェントの指示を上書きしたり情報を窃取しようとする攻撃者制御の文字列。
|
||||
MSD Core は LLM システムプロンプトになる Markdown ファイルを生成します。調査パイプラインは外部ウェブコンテンツを読み取ります；計画パイプラインはユーザー提供のテキスト（`--text-file`、`--prd`）を組み込みます；実行パイプラインは後でエージェントコンテキストとして再読み取りされる計画アーティファクトを書きます。これらのアーティファクトに流れ込む任意のユーザー制御テキストは、潜在的な **間接プロンプトインジェクション** ベクターです——一度システムプロンプトの中に入ると、エージェントの指示を上書きしたり情報を窃取しようとする攻撃者制御の文字列。
|
||||
|
||||
### 防御の仕組み
|
||||
|
||||
GSD Core はプロンプトインジェクションを 3 つのレベルで対処します。
|
||||
MSD Core はプロンプトインジェクションを 3 つのレベルで対処します。
|
||||
|
||||
**入力検証（`security.cjs`）。** `gsd-core/bin/lib/security.cjs` モジュールは中心的なセキュリティユーティリティです。以下を提供します：
|
||||
**入力検証（`security.cjs`）。** `msd-core/bin/lib/security.cjs` モジュールは中心的なセキュリティユーティリティです。以下を提供します：
|
||||
|
||||
- パストラバーサル防止：ユーザー提供のファイルパス（`--text-file`、`--prd`）はプロジェクトディレクトリ内で解決されることを検証し、macOS の `/var` → `/private/var` シンリンク解決を明示的に処理
|
||||
- プロンプトインジェクション検出：既知のインジェクションパターン（ロールオーバーライド、指示バイパス、システムタグインジェクション）が計画アーティファクトに入る前にユーザー提供テキストをスキャン
|
||||
- 安全な JSON パース：クラフトされた JSON ペイロードによるプロトタイプ汚染攻撃を防ぐラッパー
|
||||
- シェル引数検証：サブシェルコマンドに渡される引数の使用前検証
|
||||
|
||||
**ランタイムフック：`gsd-prompt-guard.js`。** このフックは `.planning/` ファイルを対象とするすべての Write または Edit 呼び出しで発火します。書き込まれるコンテンツを `security.cjs` と同じインジェクションパターンでスキャンします（サブセットがフックの独立性のために直接インライン化されています——フックはモジュールを `require()` しないため、モジュールパスが変わっても実行されます）。検出は **アドバイザリーのみ**：フックは発見をログに記録しますが書き込みをブロックしません。理由は、正当な計画書き込みでの偽陽性ブロックは、セカンダリスキャンレイヤーで見逃したインジェクションより破壊的だからです。
|
||||
**ランタイムフック：`msd-prompt-guard.js`。** このフックは `.planning/` ファイルを対象とするすべての Write または Edit 呼び出しで発火します。書き込まれるコンテンツを `security.cjs` と同じインジェクションパターンでスキャンします（サブセットがフックの独立性のために直接インライン化されています——フックはモジュールを `require()` しないため、モジュールパスが変わっても実行されます）。検出は **アドバイザリーのみ**：フックは発見をログに記録しますが書き込みをブロックしません。理由は、正当な計画書き込みでの偽陽性ブロックは、セカンダリスキャンレイヤーで見逃したインジェクションより破壊的だからです。
|
||||
|
||||
**ランタイムフック：`gsd-read-injection-scanner.js`。** このフックはすべての Read ツール呼び出しの出力で発火します。GSD がエージェントのコンテキストに組み込もうとしているファイルの *読み取ったばかりのコンテンツ* をスキャンし、攻撃者が命令を埋め込んでいるケースをキャッチします。
|
||||
**ランタイムフック：`msd-read-injection-scanner.js`。** このフックはすべての Read ツール呼び出しの出力で発火します。MSD がエージェントのコンテキストに組み込もうとしているファイルの *読み取ったばかりのコンテンツ* をスキャンし、攻撃者が命令を埋め込んでいるケースをキャッチします。
|
||||
|
||||
**CI スキャナー。** `prompt-injection-scan.security.test.cjs` はテストスイートの一部として、すべてのエージェント、ワークフロー、コマンドファイルに埋め込まれたインジェクションベクターをスキャンします。これは GSD ソース自体でのインジェクション試みをキャッチします——たとえば、ワークフローファイルにロールオーバーライド命令を追加するよう変更したサプライチェーン攻撃。
|
||||
**CI スキャナー。** `prompt-injection-scan.security.test.cjs` はテストスイートの一部として、すべてのエージェント、ワークフロー、コマンドファイルに埋め込まれたインジェクションベクターをスキャンします。これは MSD ソース自体でのインジェクション試みをキャッチします——たとえば、ワークフローファイルにロールオーバーライド命令を追加するよう変更したサプライチェーン攻撃。
|
||||
|
||||
### Read Injection Scanner vs Prompt Guard
|
||||
|
||||
2 つのフックは補完的な面をカバーします。`gsd-prompt-guard.js` は *計画アーティファクトへの書き込み* を監視します——植え付けられているインジェクションをキャッチします。`gsd-read-injection-scanner.js` は *任意のファイルの読み取り* を監視します——外部コンテンツ（依存関係の README、サードパーティの設定ファイル、ユーザー提供のドキュメント）から取り込まれるインジェクションをキャッチします。合わせて、取り込み → 保存 → 再読み取りのライフサイクルを括ります。
|
||||
2 つのフックは補完的な面をカバーします。`msd-prompt-guard.js` は *計画アーティファクトへの書き込み* を監視します——植え付けられているインジェクションをキャッチします。`msd-read-injection-scanner.js` は *任意のファイルの読み取り* を監視します——外部コンテンツ（依存関係の README、サードパーティの設定ファイル、ユーザー提供のドキュメント）から取り込まれるインジェクションをキャッチします。合わせて、取り込み → 保存 → 再読み取りのライフサイクルを括ります。
|
||||
|
||||
---
|
||||
|
||||
## レイヤー 3 — リポジトリおよび依存関係の整合性
|
||||
|
||||
GSD のランタイム動作の上流で、`open-gsd` 組織はリポジトリおよびパッケージレベルで制御を強制しています。これらは [`docs/security/baseline.md`](../../security/baseline.md) に完全に記録されており、ここでは完全性のために要約します。
|
||||
MSD のランタイム動作の上流で、`open-gsd` 組織はリポジトリおよびパッケージレベルで制御を強制しています。これらは [`docs/security/baseline.md`](../../security/baseline.md) に完全に記録されており、ここでは完全性のために要約します。
|
||||
|
||||
**依存関係の整合性。** すべてのサードパーティ依存関係は `package-lock.json` でピン留めされ、インストール前に公開されたチェックサムに対して検証されます。`scripts/check-npm-integrity.cjs` ゲートは CI 時に無効なバージョン、欠落パッケージ、余分なパッケージを検出します。これにより GSD 自身の依存関係に対する依存関係混同とタイポスクワッティング攻撃を軽減します。
|
||||
**依存関係の整合性。** すべてのサードパーティ依存関係は `package-lock.json` でピン留めされ、インストール前に公開されたチェックサムに対して検証されます。`scripts/check-npm-integrity.cjs` ゲートは CI 時に無効なバージョン、欠落パッケージ、余分なパッケージを検出します。これにより MSD 自身の依存関係に対する依存関係混同とタイポスクワッティング攻撃を軽減します。
|
||||
|
||||
**シークレットスキャン。** すべてのコミットと PR にはハードコードされたシークレットのスキャンが実施されます。意図的なテストフィクスチャは、プロジェクト標準の除外文法でアノテーションが必要です（アノテーション形式については `SECURITY.md` を参照）。アノテーションなしの抑制は CI を失敗させます。
|
||||
|
||||
@@ -111,7 +111,7 @@ GSD のランタイム動作の上流で、`open-gsd` 組織はリポジトリ
|
||||
|
||||
## Related
|
||||
|
||||
- [コマンド](../COMMANDS.md) — セキュリティ関連フラグを含む `/gsd-secure-phase` と `/gsd-code-review`
|
||||
- [コマンド](../COMMANDS.md) — セキュリティ関連フラグを含む `/msd-secure-phase` と `/msd-code-review`
|
||||
- [アーキテクチャ § フックシステム](../ARCHITECTURE.md#hook-system) — すべてのフック、そのイベントトリガー、安全性プロパティの実装詳細
|
||||
- [SECURITY.md](../../../SECURITY.md) — 脆弱性報告、組織全体のセキュリティベースライン、シークレットスキャン除外ガバナンス、依存関係整合性検証
|
||||
- [ドキュメント索引](../README.md)
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
# フェーズループ
|
||||
|
||||
> GSD Core が作業を整理する方法の核心的なメンタルモデル。
|
||||
> MSD Core が作業を整理する方法の核心的なメンタルモデル。
|
||||
|
||||
---
|
||||
|
||||
## ループとは何か
|
||||
|
||||
GSD Core はすべての開発作業を繰り返すサイクルとして構造化します：
|
||||
MSD Core はすべての開発作業を繰り返すサイクルとして構造化します：
|
||||
|
||||
```text
|
||||
Discuss → (UI デザイン) → Plan → Execute → Verify → Ship
|
||||
@@ -30,7 +30,7 @@ Discuss ステップは意図的に軽量です。それは仕様書を書く演
|
||||
|
||||
### UI デザイン（任意）
|
||||
|
||||
視覚的なコンポーネントを持つフェーズの場合、Discuss と Plan の間にオプションの `/gsd-ui-phase` ステップがあります。これは `UI-SPEC.md` を生成します——コードが書かれる前にレイアウト、インタラクション、視覚的な振る舞いを説明するデザインコントラクトです。デザインの曖昧さが異なる実装上の選択を生む可能性があるほど UI が複雑な場合に、このステップを実行する価値があります。明確なデザインコントラクトは、再実装するよりずっと安く書けます。
|
||||
視覚的なコンポーネントを持つフェーズの場合、Discuss と Plan の間にオプションの `/msd-ui-phase` ステップがあります。これは `UI-SPEC.md` を生成します——コードが書かれる前にレイアウト、インタラクション、視覚的な振る舞いを説明するデザインコントラクトです。デザインの曖昧さが異なる実装上の選択を生む可能性があるほど UI が複雑な場合に、このステップを実行する価値があります。明確なデザインコントラクトは、再実装するよりずっと安く書けます。
|
||||
|
||||
### Plan（計画）
|
||||
|
||||
@@ -87,7 +87,7 @@ Ship ステップはプルリクエストを作成し、フェーズアーティ
|
||||
- 実行が少数の非重複する計画に並行化できる（数十ではなく）。
|
||||
- 検証者がコードベース全体を読まずに確認できる、明確でテスト可能な完了の定義がある。
|
||||
|
||||
具体的には：「HMAC-SHA256 署名検証ミドルウェアを追加する」は良いフェーズスコープです。「認証システムを構築する」は通常そうではありません——ほぼ常に、別々のフェーズの方が良い複数の独立した懸念事項が含まれています。「README のタイポを修正する」はループが価値を加えるしきい値を下回っています；代わりに `/gsd-quick` を使ってください。
|
||||
具体的には：「HMAC-SHA256 署名検証ミドルウェアを追加する」は良いフェーズスコープです。「認証システムを構築する」は通常そうではありません——ほぼ常に、別々のフェーズの方が良い複数の独立した懸念事項が含まれています。「README のタイポを修正する」はループが価値を加えるしきい値を下回っています；代わりに `/msd-quick` を使ってください。
|
||||
|
||||
迷ったら、分割してください。小さいフェーズは速く完了し、より自信を持って検証でき、設計上の決定が誤りとわかった場合に方向修正しやすくなります。
|
||||
|
||||
@@ -113,7 +113,7 @@ Ship ステップはプルリクエストを作成し、フェーズアーティ
|
||||
|
||||
ループがうまく機能すれば、リズムのように感じます：各ステップが前のステップが仕事をしたために明確である、集中した境界を持つ作業のカデンス。オーバーヘッドは現実ですが、前払いです——何時間もの手直しではなく数分の計画として支払われます。
|
||||
|
||||
ループが正当化されるしきい値を下回る作業には、GSD Core はより軽量なプリミティブを提供します。フェーズループは一つのツールであり、唯一のツールではありません。
|
||||
ループが正当化されるしきい値を下回る作業には、MSD Core はより軽量なプリミティブを提供します。フェーズループは一つのツールであり、唯一のツールではありません。
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
## 4 つのプロファイル（`adaptive` と `inherit` も含む）
|
||||
|
||||
`.planning/config.json` または `/gsd-config --profile <name>` で `model_profile` を設定します:
|
||||
`.planning/config.json` または `/msd-config --profile <name>` で `model_profile` を設定します:
|
||||
|
||||
| プロファイル | プランナー | エグゼキュータ | リサーチャー | ベリファイア | 使用場面 |
|
||||
|---------|---------|----------|-------------|----------|----------|
|
||||
@@ -16,15 +16,15 @@
|
||||
| `adaptive` | Opus | Sonnet | Sonnet | Sonnet | ランタイム対応プロファイルで他のティアと同様に解決。ランタイムを頻繁に切り替える場合に使用 |
|
||||
| `inherit` | （セッションモデル） | （セッションモデル） | （セッションモデル） | （セッションモデル） | Anthropic 以外のプロバイダー（OpenRouter、ローカルモデル）— すべてのエージェントが現在のセッションモデルに従う |
|
||||
|
||||
上の表は代表的なサブセットを示しています。出荷済みの全 33 エージェントは `gsd-core/bin/shared/model-catalog.json` にプロファイルごとの明示的なティア割り当てを持っています。完全なテーブルは設定リファレンスの [モデルプロファイル](../CONFIGURATION.md#model-profiles) を参照してください。
|
||||
上の表は代表的なサブセットを示しています。出荷済みの全 33 エージェントは `msd-core/bin/shared/model-catalog.json` にプロファイルごとの明示的なティア割り当てを持っています。完全なテーブルは設定リファレンスの [モデルプロファイル](../CONFIGURATION.md#model-profiles) を参照してください。
|
||||
|
||||
**コマンドによるクイック切り替え:**
|
||||
|
||||
```bash
|
||||
/gsd-config --profile balanced # 通常の開発
|
||||
/gsd-config --profile budget # プロトタイピングまたはコストの高いフェーズ
|
||||
/gsd-config --profile quality # 本番リリース
|
||||
/gsd-config --profile inherit # OpenRouter、ローカルモデル
|
||||
/msd-config --profile balanced # 通常の開発
|
||||
/msd-config --profile budget # プロトタイピングまたはコストの高いフェーズ
|
||||
/msd-config --profile quality # 本番リリース
|
||||
/msd-config --profile inherit # OpenRouter、ローカルモデル
|
||||
```
|
||||
|
||||
**または `.planning/config.json` を直接編集:**
|
||||
@@ -45,20 +45,20 @@
|
||||
{
|
||||
"model_profile": "balanced",
|
||||
"model_overrides": {
|
||||
"gsd-executor": "opus",
|
||||
"gsd-codebase-mapper": "haiku"
|
||||
"msd-executor": "opus",
|
||||
"msd-codebase-mapper": "haiku"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
有効な値: `opus`、`sonnet`、`haiku`、`inherit`、または完全修飾のモデル ID（例: `"openai/o3"`、`"google/gemini-2.5-pro"`）。
|
||||
|
||||
`model_overrides` はプロジェクト単位で `.planning/config.json` に、またはグローバルに `~/.gsd/defaults.json` に設定できます。競合する場合はプロジェクト単位のエントリが優先されます。競合しないグローバルエントリは保持されます。
|
||||
`model_overrides` はプロジェクト単位で `.planning/config.json` に、またはグローバルに `~/.msd/defaults.json` に設定できます。競合する場合はプロジェクト単位のエントリが優先されます。競合しないグローバルエントリは保持されます。
|
||||
|
||||
**Codex と OpenCode に関する重要事項:** これらのランタイムはインストール時に解決済みのモデルを各エージェントの静的設定に埋め込みます。`model_overrides` を編集した後は、変更を反映させるためにインストーラーを再実行してください:
|
||||
|
||||
```bash
|
||||
npx @opengsd/gsd-core@latest --codex --global # または --opencode、--kilo など
|
||||
npx @golem15/msd-core@latest --codex --global # または --opencode、--kilo など
|
||||
```
|
||||
|
||||
---
|
||||
@@ -85,11 +85,11 @@ npx @opengsd/gsd-core@latest --codex --global # または --opencode、--kilo
|
||||
|
||||
| フェーズタイプ | 対象エージェント |
|
||||
|---|---|
|
||||
| `planning` | `gsd-planner`、`gsd-roadmapper`、`gsd-pattern-mapper` |
|
||||
| `research` | `gsd-phase-researcher`、`gsd-project-researcher`、`gsd-research-synthesizer`、`gsd-codebase-mapper`、`gsd-ui-researcher` |
|
||||
| `execution` | `gsd-executor`、`gsd-debugger`、`gsd-doc-writer` |
|
||||
| `verification` | `gsd-verifier`、`gsd-plan-checker`、`gsd-integration-checker`、`gsd-nyquist-auditor`、`gsd-ui-checker`、`gsd-ui-auditor`、`gsd-doc-verifier`、`gsd-code-reviewer` |
|
||||
| `discuss` | `gsd-assumptions-analyzer` |
|
||||
| `planning` | `msd-planner`、`msd-roadmapper`、`msd-pattern-mapper` |
|
||||
| `research` | `msd-phase-researcher`、`msd-project-researcher`、`msd-research-synthesizer`、`msd-codebase-mapper`、`msd-ui-researcher` |
|
||||
| `execution` | `msd-executor`、`msd-debugger`、`msd-doc-writer` |
|
||||
| `verification` | `msd-verifier`、`msd-plan-checker`、`msd-integration-checker`、`msd-nyquist-auditor`、`msd-ui-checker`、`msd-ui-auditor`、`msd-doc-verifier`、`msd-code-reviewer` |
|
||||
| `discuss` | `msd-assumptions-analyzer` |
|
||||
| `completion` | 予約済み — 現在はサブエージェントなし。スキーマの前方互換性のために受け入れられます |
|
||||
|
||||
`models` ブロックはティアエイリアス（`opus`、`sonnet`、`haiku`、`inherit`）のみを受け入れます。特定のエージェントに完全修飾のモデル ID を指定するには `model_overrides` を使用してください。
|
||||
@@ -103,12 +103,12 @@ npx @opengsd/gsd-core@latest --codex --global # または --opencode、--kilo
|
||||
"research": "sonnet"
|
||||
},
|
||||
"model_overrides": {
|
||||
"gsd-codebase-mapper": "haiku"
|
||||
"msd-codebase-mapper": "haiku"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
`gsd-codebase-mapper` が `haiku` に固定されている*以外の*すべてのリサーチエージェントは `sonnet` に解決されます。
|
||||
`msd-codebase-mapper` が `haiku` に固定されている*以外の*すべてのリサーチエージェントは `sonnet` に解決されます。
|
||||
|
||||
---
|
||||
|
||||
@@ -131,7 +131,7 @@ npx @opengsd/gsd-core@latest --codex --global # または --opencode、--kilo
|
||||
}
|
||||
```
|
||||
|
||||
各エージェントはデフォルトのティア（`light`、`standard`、または `heavy`）を持っています。最初の試行では GSD が `tier_models[default_tier]` を選びます。オーケストレータがソフト失敗（検証が不確定、プランチェックがフラグを立てた、など）を検出した場合、エージェントを 1 ティア上で再起動します。`max_escalations` は合計リトライ数の上限です。
|
||||
各エージェントはデフォルトのティア（`light`、`standard`、または `heavy`）を持っています。最初の試行では MSD が `tier_models[default_tier]` を選びます。オーケストレータがソフト失敗（検証が不確定、プランチェックがフラグを立てた、など）を検出した場合、エージェントを 1 ティア上で再起動します。`max_escalations` は合計リトライ数の上限です。
|
||||
|
||||
すでに `heavy` のエージェントはこれ以上エスカレートできません。
|
||||
|
||||
@@ -152,9 +152,9 @@ npx @opengsd/gsd-core@latest --codex --global # または --opencode、--kilo
|
||||
|
||||
---
|
||||
|
||||
## Anthropic 以外のランタイムでの GSD 使用
|
||||
## Anthropic 以外のランタイムでの MSD 使用
|
||||
|
||||
Codex、OpenCode、Antigravity CLI、または Kilo 向けに GSD をインストールした場合、インストーラーはすでに設定に `resolve_model_ids: "omit"` を設定しています。これにより GSD は Anthropic のモデル ID 解決をスキップし、ランタイムが独自のデフォルトモデルを選択できるようにします。基本的なケースでは手動設定は不要です。
|
||||
Codex、OpenCode、Antigravity CLI、または Kilo 向けに MSD をインストールした場合、インストーラーはすでに設定に `resolve_model_ids: "omit"` を設定しています。これにより MSD は Anthropic のモデル ID 解決をスキップし、ランタイムが独自のデフォルトモデルを選択できるようにします。基本的なケースでは手動設定は不要です。
|
||||
|
||||
**Codex でティアードモデルを使用したい場合:**
|
||||
|
||||
@@ -165,7 +165,7 @@ Codex、OpenCode、Antigravity CLI、または Kilo 向けに GSD をインス
|
||||
}
|
||||
```
|
||||
|
||||
GSD はランタイムのティアマップで定義された Codex ネイティブのモデルと推論エフォートに各ティアエイリアスを解決します。
|
||||
MSD はランタイムのティアマップで定義された Codex ネイティブのモデルと推論エフォートに各ティアエイリアスを解決します。
|
||||
|
||||
**Anthropic 以外のランタイムでエージェントごとのモデル ID を使用したい場合:**
|
||||
|
||||
@@ -173,9 +173,9 @@ GSD はランタイムのティアマップで定義された Codex ネイティ
|
||||
{
|
||||
"resolve_model_ids": "omit",
|
||||
"model_overrides": {
|
||||
"gsd-planner": "o3",
|
||||
"gsd-executor": "o4-mini",
|
||||
"gsd-debugger": "o3"
|
||||
"msd-planner": "o3",
|
||||
"msd-executor": "o4-mini",
|
||||
"msd-debugger": "o3"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
**目標:** フェーズ実行が失敗・停止した場合、または不完全な作業が生成された場合に回復し、すでに成功した作業を繰り返すことなく、クリーンな状態で再開する。
|
||||
|
||||
**前提条件:** `/gsd-execute-phase N` を実行したが、`VERIFICATION.md` が書き込まれる前に実行が停止した、または予期しない出力・ファイル不足・スピナーの停止が確認された状態であること。
|
||||
**前提条件:** `/msd-execute-phase N` を実行したが、`VERIFICATION.md` が書き込まれる前に実行が停止した、または予期しない出力・ファイル不足・スピナーの停止が確認された状態であること。
|
||||
|
||||
---
|
||||
|
||||
@@ -12,15 +12,15 @@
|
||||
|
||||
### 「Spawning…」のまま 1〜5 分間出力がない場合
|
||||
|
||||
これはフリーズではなく正常な動作です。GSD のサブエージェントは独立したコンテキストウィンドウで動作します。スポーン行の liveness ノートがこれを確認しています。セッションを中断しないでください。
|
||||
これはフリーズではなく正常な動作です。MSD のサブエージェントは独立したコンテキストウィンドウで動作します。スポーン行の liveness ノートがこれを確認しています。セッションを中断しないでください。
|
||||
|
||||
10 分以上経っても結果が得られない場合は、Claude Code のサイドバーを確認してください。エージェントのタスクが完了と表示されているにもかかわらず出力が表示されない場合、コンテキスト切り替え時に結果が失われた可能性があります。同じコマンドを再実行してください。
|
||||
|
||||
```bash
|
||||
/gsd-execute-phase 1
|
||||
/msd-execute-phase 1
|
||||
```
|
||||
|
||||
GSD はエグゼキューターを dispatching する前に `SUMMARY.md` ファイルを確認します。すでに `SUMMARY.md` があるプランは自動的にスキップされます。
|
||||
MSD はエグゼキューターを dispatching する前に `SUMMARY.md` ファイルを確認します。すでに `SUMMARY.md` があるプランは自動的にスキップされます。
|
||||
|
||||
### 実行がエラーメッセージとともにウェーブの途中で停止した場合
|
||||
|
||||
@@ -34,7 +34,7 @@ git log --oneline -20
|
||||
|
||||
### エグゼキューターがコードをコミットしたが SUMMARY.md を書き込まなかった場合
|
||||
|
||||
GSD は次回の実行時にこれを検出し、3 つの選択肢を持つ安全な再開ゲートを表示します。
|
||||
MSD は次回の実行時にこれを検出し、3 つの選択肢を持つ安全な再開ゲートを表示します。
|
||||
|
||||
- **手動でクローズアウト** — コミットを自分で確認し、`SUMMARY.md` を書いてから再実行する。
|
||||
- **最初からやり直し** — 新しいエグゼキューターを dispatching する前に、部分的なコミットを revert または上書きする。
|
||||
@@ -44,12 +44,12 @@ GSD は次回の実行時にこれを検出し、3 つの選択肢を持つ安
|
||||
|
||||
## 根本原因を診断する
|
||||
|
||||
### `/gsd-debug --diagnose` を実行する
|
||||
### `/msd-debug --diagnose` を実行する
|
||||
|
||||
実行が誤った出力・スタブコード・検証失敗を生成した場合、修正を適用せずに診断のみを行うモードで調査します。
|
||||
|
||||
```bash
|
||||
/gsd-debug --diagnose "Phase 2 executor produced stubs instead of real code"
|
||||
/msd-debug --diagnose "Phase 2 executor produced stubs instead of real code"
|
||||
```
|
||||
|
||||
`--diagnose` はファイルに触れることなく根本原因で停止します。後で調査を再開できるよう、セッションファイルを `.planning/debug/<slug>.md` に作成します。
|
||||
@@ -57,36 +57,36 @@ GSD は次回の実行時にこれを検出し、3 つの選択肢を持つ安
|
||||
修正も含む完全なデバッグセッションを開始するには：
|
||||
|
||||
```bash
|
||||
/gsd-debug "Login middleware not handling 401 correctly after phase 3"
|
||||
/msd-debug "Login middleware not handling 401 correctly after phase 3"
|
||||
```
|
||||
|
||||
GSD は症状を収集し、科学的手法を使って体系的な調査を行い、修正案を提案します。設定で `tdd_mode: true` が有効な場合、修正を適用する前に失敗するテストが必要です。
|
||||
MSD は症状を収集し、科学的手法を使って体系的な調査を行い、修正案を提案します。設定で `tdd_mode: true` が有効な場合、修正を適用する前に失敗するテストが必要です。
|
||||
|
||||
### アクティブなデバッグセッションを確認する
|
||||
|
||||
```bash
|
||||
/gsd-debug list
|
||||
/msd-debug list
|
||||
```
|
||||
|
||||
現在の仮説と次のアクションとともに、すべてのオープンセッションを表示します。特定のセッションを再開するには：
|
||||
|
||||
```bash
|
||||
/gsd-debug continue <slug>
|
||||
/msd-debug continue <slug>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## `/gsd-forensics` でポストモーテムを実行する
|
||||
## `/msd-forensics` でポストモーテムを実行する
|
||||
|
||||
エラー出力から原因が明確でない場合（例：プランが存在しないファイルを参照している、実行が予期しない結果を生成した、状態が破損しているように見える）、フォレンジック調査を実行します。
|
||||
|
||||
```bash
|
||||
/gsd-forensics "Phase 3 execution stalled after wave 1"
|
||||
/msd-forensics "Phase 3 execution stalled after wave 1"
|
||||
```
|
||||
|
||||
GSD は git 履歴、`.planning/` 成果物の完全性、STATE.md の一貫性、未コミットの作業、孤立したワークツリーを分析します。構造化されたレポートを `.planning/forensics/report-<timestamp>.md` に書き込み、推奨される修復手順を提示します。
|
||||
MSD は git 履歴、`.planning/` 成果物の完全性、STATE.md の一貫性、未コミットの作業、孤立したワークツリーを分析します。構造化されたレポートを `.planning/forensics/report-<timestamp>.md` に書き込み、推奨される修復手順を提示します。
|
||||
|
||||
`/gsd-forensics` は読み取り専用です。プロジェクトファイルを変更することはありません。
|
||||
`/msd-forensics` は読み取り専用です。プロジェクトファイルを変更することはありません。
|
||||
|
||||
**検出内容：**
|
||||
|
||||
@@ -103,46 +103,46 @@ GSD は git 履歴、`.planning/` 成果物の完全性、STATE.md の一貫性
|
||||
根本的な問題が解決したら、実行コマンドを再実行します。
|
||||
|
||||
```bash
|
||||
/gsd-execute-phase 1
|
||||
/msd-execute-phase 1
|
||||
```
|
||||
|
||||
GSD はすでに `SUMMARY.md` が存在するプランをスキップし、残りのプランのみにエグゼキューターを dispatch します。
|
||||
MSD はすでに `SUMMARY.md` が存在するプランをスキップし、残りのプランのみにエグゼキューターを dispatch します。
|
||||
|
||||
特定のウェーブだけを再実行する必要がある場合：
|
||||
|
||||
```bash
|
||||
/gsd-execute-phase 1 --wave 2
|
||||
/msd-execute-phase 1 --wave 2
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## `/gsd-undo` でロールバックする
|
||||
## `/msd-undo` でロールバックする
|
||||
|
||||
実行が生成したコードを完全に破棄したい場合は、手動の `git revert` ではなくプランマニフェストを使ってロールバックします。
|
||||
|
||||
### 単一プランをロールバックする
|
||||
|
||||
```bash
|
||||
/gsd-undo --plan 03-02
|
||||
/msd-undo --plan 03-02
|
||||
```
|
||||
|
||||
フェーズ `3` のプラン `02` に関するすべてのコミットを revert します。GSD は変更を書き込む前に確認ゲートを表示します。
|
||||
フェーズ `3` のプラン `02` に関するすべてのコミットを revert します。MSD は変更を書き込む前に確認ゲートを表示します。
|
||||
|
||||
### フェーズ全体をロールバックする
|
||||
|
||||
```bash
|
||||
/gsd-undo --phase 03
|
||||
/msd-undo --phase 03
|
||||
```
|
||||
|
||||
フェーズ `3` に関するすべてのコミットを revert します。GSD は後続フェーズがこのフェーズに依存しているかどうかを確認し、続行前に警告を表示します。
|
||||
フェーズ `3` に関するすべてのコミットを revert します。MSD は後続フェーズがこのフェーズに依存しているかどうかを確認し、続行前に警告を表示します。
|
||||
|
||||
### 直近のコミットからインタラクティブに選ぶ
|
||||
|
||||
```bash
|
||||
/gsd-undo --last 5
|
||||
/msd-undo --last 5
|
||||
```
|
||||
|
||||
最近の 5 件の GSD コミットを表示し、revert するものを選択できます。
|
||||
最近の 5 件の MSD コミットを表示し、revert するものを選択できます。
|
||||
|
||||
---
|
||||
|
||||
@@ -151,7 +151,7 @@ GSD はすでに `SUMMARY.md` が存在するプランをスキップし、残
|
||||
コンテキストリセットや新しいセッションの後にプロジェクトに戻った場合：
|
||||
|
||||
```bash
|
||||
/gsd-resume-work
|
||||
/msd-resume-work
|
||||
```
|
||||
|
||||
最後のハンドオフから完全なセッションコンテキスト（現在のフェーズ、ブロッカー、実行が停止した場所を含む）を復元します。
|
||||
@@ -159,7 +159,7 @@ GSD はすでに `SUMMARY.md` が存在するプランをスキップし、残
|
||||
または、現在の位置を確認して正しい次のステップに自動的に進むには：
|
||||
|
||||
```bash
|
||||
/gsd-progress --next
|
||||
/msd-progress --next
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
@@ -2,13 +2,13 @@
|
||||
|
||||
**目標:** プランナーがタスクを書く前に、スペーシング・カラー・タイポグラフィ・コピーライティングの決定を固定したロック済みの UI デザインコントラクト（`UI-SPEC.md`）を作成し、実行中のアドホックなスタイリング選択による視覚的な一貫性の欠如を防ぐ。
|
||||
|
||||
**前提条件:** `.planning/ROADMAP.md` が存在すること。フェーズにフロントエンドまたは UI 作業が含まれること。事前に `/gsd-discuss-phase N` を実行することを強く推奨します。UI リサーチャーは `CONTEXT.md` を読み込んで、すでに決定済みの事項を再確認しないようにします。
|
||||
**前提条件:** `.planning/ROADMAP.md` が存在すること。フェーズにフロントエンドまたは UI 作業が含まれること。事前に `/msd-discuss-phase N` を実行することを強く推奨します。UI リサーチャーは `CONTEXT.md` を読み込んで、すでに決定済みの事項を再確認しないようにします。
|
||||
|
||||
---
|
||||
|
||||
## このフェーズに UI コントラクトが必要かどうかを判断する
|
||||
|
||||
すべてのフェーズで `/gsd-ui-phase` が必要なわけではありません。以下の場合に使用してください。
|
||||
すべてのフェーズで `/msd-ui-phase` が必要なわけではありません。以下の場合に使用してください。
|
||||
|
||||
- フェーズが新しい UI サーフェス（ページ、フロー、レイアウト）を導入する
|
||||
- 複数のコンポーネントが構築され、視覚的な一貫性が重要
|
||||
@@ -20,22 +20,22 @@
|
||||
- フェーズが純粋にバックエンド、インフラ、またはユーザー向け出力のないデータ作業
|
||||
- 以前のフェーズの UI-SPEC.md がすでに存在し、このフェーズが新しいサーフェスを導入せず同一のビジュアルパターンで構築する
|
||||
|
||||
確信が持てない場合、安全ゲートが促してくれます。`workflow.ui_safety_gate` が有効（デフォルト）な場合、`/gsd-plan-phase` はフロントエンド作業を検出したが UI-SPEC.md がない場合に警告を表示し、先に `/gsd-ui-phase` を実行するかどうかを確認します。
|
||||
確信が持てない場合、安全ゲートが促してくれます。`workflow.ui_safety_gate` が有効（デフォルト）な場合、`/msd-plan-phase` はフロントエンド作業を検出したが UI-SPEC.md がない場合に警告を表示し、先に `/msd-ui-phase` を実行するかどうかを確認します。
|
||||
|
||||
---
|
||||
|
||||
## UI デザインコントラクトを実行する
|
||||
|
||||
```bash
|
||||
/gsd-ui-phase 2
|
||||
/msd-ui-phase 2
|
||||
```
|
||||
|
||||
フェーズ番号を省略した場合、GSD Core は現在のフェーズを対象とします。
|
||||
フェーズ番号を省略した場合、MSD Core は現在のフェーズを対象とします。
|
||||
|
||||
コマンドは 2 つのステージで実行されます。
|
||||
|
||||
1. **`gsd-ui-researcher`** — `CONTEXT.md`、`RESEARCH.md`、`REQUIREMENTS.md` を読み込んで既存の決定事項を確認し、デザインシステムの状態（shadcn の `components.json`、Tailwind 設定、既存トークン）を検出し、スペーシング・カラー・タイポグラフィ・コピーライティング・レジストリ安全性の 5 つの領域で未回答のデザイン問題のみを確認します。
|
||||
2. **`gsd-ui-checker`** — 生成された `UI-SPEC.md` を 7 つの側面で検証します。問題が発見された場合、指摘された項目のみを対象に研究者が再実行されるリビジョンループが起動します（最大 2 回のイテレーション）。
|
||||
1. **`msd-ui-researcher`** — `CONTEXT.md`、`RESEARCH.md`、`REQUIREMENTS.md` を読み込んで既存の決定事項を確認し、デザインシステムの状態（shadcn の `components.json`、Tailwind 設定、既存トークン）を検出し、スペーシング・カラー・タイポグラフィ・コピーライティング・レジストリ安全性の 5 つの領域で未回答のデザイン問題のみを確認します。
|
||||
2. **`msd-ui-checker`** — 生成された `UI-SPEC.md` を 7 つの側面で検証します。問題が発見された場合、指摘された項目のみを対象に研究者が再実行されるリビジョンループが起動します（最大 2 回のイテレーション）。
|
||||
|
||||
**出力:** `.planning/phases/{phase-dir}/` 内の `{padded_phase}-UI-SPEC.md`。
|
||||
|
||||
@@ -69,7 +69,7 @@ React、Next.js、Vite プロジェクトの場合、`components.json` が見つ
|
||||
npx shadcn init --preset <paste>
|
||||
```
|
||||
|
||||
プリセット文字列は GSD Core の計画成果物として第一級の扱いを受け、フェーズとマイルストーンを通じて再現可能です。
|
||||
プリセット文字列は MSD Core の計画成果物として第一級の扱いを受け、フェーズとマイルストーンを通じて再現可能です。
|
||||
|
||||
---
|
||||
|
||||
@@ -82,13 +82,13 @@ npx shadcn view <component> # インストール前にソースを確認する
|
||||
npx shadcn diff <component> # 公式レジストリと比較する
|
||||
```
|
||||
|
||||
レジストリ安全性が対処されていない場合、チェッカーはスペックを BLOCKED としてフラグを立てます。プロジェクトが shadcn を使用していない場合や、別の審査プロセスがある場合は、`/gsd-settings` でゲートを無効化してください。
|
||||
レジストリ安全性が対処されていない場合、チェッカーはスペックを BLOCKED としてフラグを立てます。プロジェクトが shadcn を使用していない場合や、別の審査プロセスがある場合は、`/msd-settings` でゲートを無効化してください。
|
||||
|
||||
---
|
||||
|
||||
## スケッチ知見をヘッドスタートとして使う
|
||||
|
||||
すでに `/gsd-sketch --wrap-up` を実行済みの場合、UI リサーチャーは `.claude/skills/sketch-findings-[project]/` を自動的に読み込みます。事前に検証された決定（レイアウト・パレット・タイポグラフィ・スペーシング）はロック済みとして扱われ、再確認されません。実行開始時に以下のメモが表示されます。
|
||||
すでに `/msd-sketch --wrap-up` を実行済みの場合、UI リサーチャーは `.claude/skills/sketch-findings-[project]/` を自動的に読み込みます。事前に検証された決定（レイアウト・パレット・タイポグラフィ・スペーシング）はロック済みとして扱われ、再確認されません。実行開始時に以下のメモが表示されます。
|
||||
|
||||
```text
|
||||
⚡ Sketch findings detected: .claude/skills/sketch-findings-[project]/SKILL.md
|
||||
@@ -96,20 +96,20 @@ npx shadcn diff <component> # 公式レジストリと比較する
|
||||
as locked — not re-asked.
|
||||
```
|
||||
|
||||
`/gsd-ui-phase` の前に `/gsd-sketch --wrap-up` を実行する主な理由はこれです。会話形式のデザイン探索がコントラクト入力として確定されます。
|
||||
`/msd-ui-phase` の前に `/msd-sketch --wrap-up` を実行する主な理由はこれです。会話形式のデザイン探索がコントラクト入力として確定されます。
|
||||
|
||||
---
|
||||
|
||||
## `/gsd-ui-review` による事後的なビジュアル監査
|
||||
## `/msd-ui-review` による事後的なビジュアル監査
|
||||
|
||||
`/gsd-ui-review` は実行前ではなく実行後に使用します。実装済みのフロントエンドを UI-SPEC（またはスペックがない場合は抽象的な 6 柱標準）に対して監査します。
|
||||
`/msd-ui-review` は実行前ではなく実行後に使用します。実装済みのフロントエンドを UI-SPEC（またはスペックがない場合は抽象的な 6 柱標準）に対して監査します。
|
||||
|
||||
```bash
|
||||
/gsd-ui-review # 現在のフェーズを監査する
|
||||
/gsd-ui-review 3 # フェーズ 3 を監査する
|
||||
/msd-ui-review # 現在のフェーズを監査する
|
||||
/msd-ui-review 3 # フェーズ 3 を監査する
|
||||
```
|
||||
|
||||
フロントエンドコードがあるプロジェクトであれば動作します。GSD プロジェクトの初期化は必要ありません。
|
||||
フロントエンドコードがあるプロジェクトであれば動作します。MSD プロジェクトの初期化は必要ありません。
|
||||
|
||||
**確認内容（6 柱、各 1〜4 点）：**
|
||||
|
||||
@@ -120,24 +120,24 @@ npx shadcn diff <component> # 公式レジストリと比較する
|
||||
5. スペーシング — グリッドの整合、トークンの一貫性
|
||||
6. エクスペリエンスデザイン — ローディング・エラー・空の状態のカバレッジ
|
||||
|
||||
**出力:** スコアと優先度の高い上位 3 件の修正点を含む `{padded_phase}-UI-REVIEW.md`。`gsd-browser` などのブラウザ MCP サーバーが設定されている場合、監査はビジュアルエビデンスとしてスクリーンショットも取得します。
|
||||
**出力:** スコアと優先度の高い上位 3 件の修正点を含む `{padded_phase}-UI-REVIEW.md`。`msd-browser` などのブラウザ MCP サーバーが設定されている場合、監査はビジュアルエビデンスとしてスクリーンショットも取得します。
|
||||
|
||||
**スクリーンショットの保存先:** スクリーンショットは `.planning/ui-reviews/` に保存されます。バイナリファイルが git に含まれないよう、`.gitignore` が自動的に作成されます。スクリーンショットは `/gsd-complete-milestone` 実行時にクリーンアップされます。
|
||||
**スクリーンショットの保存先:** スクリーンショットは `.planning/ui-reviews/` に保存されます。バイナリファイルが git に含まれないよう、`.gitignore` が自動的に作成されます。スクリーンショットは `/msd-complete-milestone` 実行時にクリーンアップされます。
|
||||
|
||||
---
|
||||
|
||||
## フェーズライフサイクルにおける推奨位置
|
||||
|
||||
```text
|
||||
/gsd-discuss-phase N ← 実装方針を固定する
|
||||
/gsd-ui-phase N ← デザインコントラクトを固定する（フロントエンドフェーズ）
|
||||
/gsd-plan-phase N ← リサーチ + 計画（UI-SPEC.md をコンテキストとして読み込む）
|
||||
/gsd-execute-phase N ← 並行実行
|
||||
/gsd-verify-work N ← 手動 UAT
|
||||
/gsd-ui-review N ← 事後的なビジュアル監査（オプションだが推奨）
|
||||
/msd-discuss-phase N ← 実装方針を固定する
|
||||
/msd-ui-phase N ← デザインコントラクトを固定する（フロントエンドフェーズ）
|
||||
/msd-plan-phase N ← リサーチ + 計画（UI-SPEC.md をコンテキストとして読み込む）
|
||||
/msd-execute-phase N ← 並行実行
|
||||
/msd-verify-work N ← 手動 UAT
|
||||
/msd-ui-review N ← 事後的なビジュアル監査（オプションだが推奨）
|
||||
```
|
||||
|
||||
`/gsd-ui-phase` はディスカッションとプランの間に位置します。これはプランナーが `UI-SPEC.md` をデザインコンテキストとして読み込むためです。`PLAN.md` 内のタスクは、スペックが固定したスペーシングトークン・カラー変数・コピーライティング決定を参照します。
|
||||
`/msd-ui-phase` はディスカッションとプランの間に位置します。これはプランナーが `UI-SPEC.md` をデザインコンテキストとして読み込むためです。`PLAN.md` 内のタスクは、スペックが固定したスペーシングトークン・カラー変数・コピーライティング決定を参照します。
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -2,18 +2,18 @@
|
||||
|
||||
**目的:** プランニング開始前にフェーズが必要とする実装上の決定事項を収集します。これにより、リサーチャーとプランナーがあなたに再確認することなく作業を進められます。
|
||||
|
||||
**前提条件:** `.planning/ROADMAP.md` が存在すること。ない場合は先に `/gsd-new-project` を実行してください。
|
||||
**前提条件:** `.planning/ROADMAP.md` が存在すること。ない場合は先に `/msd-new-project` を実行してください。
|
||||
|
||||
---
|
||||
|
||||
## 検討モードを選ぶ
|
||||
|
||||
GSD Core は 2 つのモードを提供します。コードベースへの理解度に応じて選択してください。
|
||||
MSD Core は 2 つのモードを提供します。コードベースへの理解度に応じて選択してください。
|
||||
|
||||
**実装に関する自分の方針を最初に表明したい場合**（インタビューモード、デフォルト）:
|
||||
|
||||
```bash
|
||||
/gsd-discuss-phase 2
|
||||
/msd-discuss-phase 2
|
||||
```
|
||||
|
||||
Claude はフェーズスコープのグレーゾーンを特定し、どこについて議論するかを選択させた後、各エリアについておよそ 4 つの質問に取り組みます。
|
||||
@@ -21,8 +21,8 @@ Claude はフェーズスコープのグレーゾーンを特定し、どこに
|
||||
**コードベースに明確なパターンがすでにあり、ほとんどの質問が自明に感じる場合**（仮定モード）:
|
||||
|
||||
```bash
|
||||
node gsd-tools.cjs config-set workflow.discuss_mode assumptions
|
||||
/gsd-discuss-phase 2
|
||||
node msd-tools.cjs config-set workflow.discuss_mode assumptions
|
||||
/msd-discuss-phase 2
|
||||
```
|
||||
|
||||
Claude はサブエージェント経由でコードベースの関連ファイルを 5〜15 個読み込み、証拠と確信度を添えて仮定を立て、確認または修正のために提示します。通常 2〜4 回のやり取りで済みます（インタビューモードの 15〜20 回と比較して）。
|
||||
@@ -30,7 +30,7 @@ Claude はサブエージェント経由でコードベースの関連ファイ
|
||||
元に戻すには:
|
||||
|
||||
```bash
|
||||
node gsd-tools.cjs config-set workflow.discuss_mode discuss
|
||||
node msd-tools.cjs config-set workflow.discuss_mode discuss
|
||||
```
|
||||
|
||||
各モードの詳細な比較や、どちらが時間を節約しやすいかについては [検討モードの解説](../workflow-discuss-mode.md) を参照してください。
|
||||
@@ -42,7 +42,7 @@ node gsd-tools.cjs config-set workflow.discuss_mode discuss
|
||||
デフォルトでは、Claude はグレーゾーンを提示し、どれをカバーするか選択を求めます。その選択プロンプトなしにすべてを順番に処理したい場合:
|
||||
|
||||
```bash
|
||||
/gsd-discuss-phase 2 --all
|
||||
/msd-discuss-phase 2 --all
|
||||
```
|
||||
|
||||
---
|
||||
@@ -52,7 +52,7 @@ node gsd-tools.cjs config-set workflow.discuss_mode discuss
|
||||
**フェーズが十分に理解されており、プロンプトなしで Claude に推奨デフォルトを選択させたい場合:**
|
||||
|
||||
```bash
|
||||
/gsd-discuss-phase 3 --auto
|
||||
/msd-discuss-phase 3 --auto
|
||||
```
|
||||
|
||||
Claude はすべての質問に対して推奨回答を選択し、その選択を記録します。決定事項のリスクが低い、または以前のフェーズから既に示唆されているフェーズで使用してください。
|
||||
@@ -60,7 +60,7 @@ Claude はすべての質問に対して推奨回答を選択し、その選択
|
||||
**リモートセッションの制約がある場合（TUI メニューが使えない）:**
|
||||
|
||||
```bash
|
||||
/gsd-discuss-phase 2 --text
|
||||
/msd-discuss-phase 2 --text
|
||||
```
|
||||
|
||||
すべてのプロンプトはインタラクティブなセレクターではなく、プレーンテキストの番号付きリストとして表示されます。
|
||||
@@ -72,7 +72,7 @@ Claude はすべての質問に対して推奨回答を選択し、その選択
|
||||
一度に 1 つずつではなく、複数の質問をまとめて回答したい場合:
|
||||
|
||||
```bash
|
||||
/gsd-discuss-phase 2 --batch
|
||||
/msd-discuss-phase 2 --batch
|
||||
```
|
||||
|
||||
Claude は 1 ターンに 2〜5 問をグループにまとめます。
|
||||
@@ -84,7 +84,7 @@ Claude は 1 ターンに 2〜5 問をグループにまとめます。
|
||||
確定する前にオプションの比較表を見たい場合:
|
||||
|
||||
```bash
|
||||
/gsd-discuss-phase 2 --analyze
|
||||
/msd-discuss-phase 2 --analyze
|
||||
```
|
||||
|
||||
---
|
||||
@@ -94,7 +94,7 @@ Claude は 1 ターンに 2〜5 問をグループにまとめます。
|
||||
回答ファイルを準備済みで、すべての決定事項を一度に投入したい場合:
|
||||
|
||||
```bash
|
||||
/gsd-discuss-phase 1 --power
|
||||
/msd-discuss-phase 1 --power
|
||||
```
|
||||
|
||||
---
|
||||
@@ -104,7 +104,7 @@ Claude は 1 ターンに 2〜5 問をグループにまとめます。
|
||||
**インタラクティブなセッションを始める前に Claude が何を仮定するかを確認したい場合** — 検討時間を投資する前にアラインメントを検証するのに役立ちます:
|
||||
|
||||
```bash
|
||||
/gsd-discuss-phase 3 --assumptions
|
||||
/msd-discuss-phase 3 --assumptions
|
||||
```
|
||||
|
||||
Claude は仮定（コードベースの証拠と確信度を添えて）を出力して終了します。`CONTEXT.md` は書き込まれません。出力を確認し、修正が必要な点があれば通常の discuss または仮定モードのセッションを実行してください。
|
||||
@@ -132,9 +132,9 @@ discuss モードと仮定モードはどちらも同じ `{phase}-CONTEXT.md`
|
||||
|
||||
## 決定事項がプランニングにどう反映されるか
|
||||
|
||||
次に `/gsd-plan-phase` を実行すると、プランナーは CONTEXT.md を読み込み、どの決定事項が確定済みかを把握します。ここで既に回答された質問は再確認されません。リサーチャーも最初に CONTEXT.md を読んで調査すべき内容を把握します。
|
||||
次に `/msd-plan-phase` を実行すると、プランナーは CONTEXT.md を読み込み、どの決定事項が確定済みかを把握します。ここで既に回答された質問は再確認されません。リサーチャーも最初に CONTEXT.md を読んで調査すべき内容を把握します。
|
||||
|
||||
**`/gsd-plan-phase` 実行時に CONTEXT.md がない場合**、コンテキストなしで続行する（計画はあなたの設計方針なしにリサーチと要件のみを使用）か、先に `/gsd-discuss-phase` を実行するかの選択を求められます。
|
||||
**`/msd-plan-phase` 実行時に CONTEXT.md がない場合**、コンテキストなしで続行する（計画はあなたの設計方針なしにリサーチと要件のみを使用）か、先に `/msd-discuss-phase` を実行するかの選択を求められます。
|
||||
|
||||
---
|
||||
|
||||
@@ -143,7 +143,7 @@ discuss モードと仮定モードはどちらも同じ `{phase}-CONTEXT.md`
|
||||
discuss-phase をスキップしてプランニングに直接進んでください:
|
||||
|
||||
```bash
|
||||
/gsd-plan-phase 1 --prd path/to/prd.md
|
||||
/msd-plan-phase 1 --prd path/to/prd.md
|
||||
```
|
||||
|
||||
プランナーは PRD から CONTEXT.md を合成し、すべての要件を確定済みの決定事項として扱います。
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# トラッカーイシューから GSD Core を操作する方法
|
||||
# トラッカーイシューから MSD Core を操作する方法
|
||||
|
||||
**目標:** カスタムスクリプトやトラッカー連携なしに、GSD Core に既存のコマンドのみを使って、GitHub・Linear・Jira の単一の適切にスコープされたイシューを分離されたワークスペースからマージ済み PR まで通じたパイプラインで処理する。
|
||||
**目標:** カスタムスクリプトやトラッカー連携なしに、MSD Core に既存のコマンドのみを使って、GitHub・Linear・Jira の単一の適切にスコープされたイシューを分離されたワークスペースからマージ済み PR まで通じたパイプラインで処理する。
|
||||
|
||||
**前提条件:** GSD Core がインストール済みであること。イシューは明確なスコープ、観察可能な受け入れ基準、上流のブロッカーがない状態であること。
|
||||
**前提条件:** MSD Core がインストール済みであること。イシューは明確なスコープ、観察可能な受け入れ基準、上流のブロッカーがない状態であること。
|
||||
|
||||
このパターンの背景にある概念と設計理由については、[イシュー駆動オーケストレーションの説明](../issue-driven-orchestration.md)を参照してください。
|
||||
|
||||
@@ -16,13 +16,13 @@
|
||||
- **イシューがスタンドアロンの新しい作業** → フェーズを追加する：
|
||||
|
||||
```bash
|
||||
/gsd-phase "Description matching the issue title"
|
||||
/msd-phase "Description matching the issue title"
|
||||
```
|
||||
|
||||
- **イシューが緊急で既存フェーズの間に挿入する必要がある** → 小数フェーズを挿入する：
|
||||
|
||||
```bash
|
||||
/gsd-phase --insert 3 "Fix: description from issue"
|
||||
/msd-phase --insert 3 "Fix: description from issue"
|
||||
```
|
||||
|
||||
トラッカーイシューの URL をコピーします。ステップ 3 で `CONTEXT.md` に貼り付けることで、コンテキスト圧縮を経ても追跡可能性が維持されます。
|
||||
@@ -34,13 +34,13 @@
|
||||
すべてのイシューには独自のワークスペース（独立した `.planning/` ディレクトリを持つ git ワークツリー）を用意します。部分的な作業、中断されたプラン、探索的なコミットを `main` の外に保ちます。
|
||||
|
||||
```bash
|
||||
/gsd-workspace --new --name my-issue-slug --repos . --strategy worktree
|
||||
/msd-workspace --new --name my-issue-slug --repos . --strategy worktree
|
||||
```
|
||||
|
||||
続行する前にワークスペースディレクトリに移動します。
|
||||
|
||||
```bash
|
||||
cd ~/gsd-workspaces/my-issue-slug
|
||||
cd ~/msd-workspaces/my-issue-slug
|
||||
```
|
||||
|
||||
---
|
||||
@@ -50,15 +50,15 @@ cd ~/gsd-workspaces/my-issue-slug
|
||||
計画が始まる前に実装上の決定を固定するために discuss-phase を実行します。セッションが開いたら、トラッカーイシューの URL を議論に貼り付けて `CONTEXT.md` に記録します。
|
||||
|
||||
```bash
|
||||
/gsd-discuss-phase N
|
||||
/msd-discuss-phase N
|
||||
```
|
||||
|
||||
GSD はイシューのスコープにある曖昧さ（エラーハンドリング、エッジケース、インターフェースコントラクト、技術選択）について質問します。回答がその後の計画を形作ります。
|
||||
MSD はイシューのスコープにある曖昧さ（エラーハンドリング、エッジケース、インターフェースコントラクト、技術選択）について質問します。回答がその後の計画を形作ります。
|
||||
|
||||
すべての答えがわかっていて素早く進みたい場合：
|
||||
|
||||
```bash
|
||||
/gsd-discuss-phase N --auto
|
||||
/msd-discuss-phase N --auto
|
||||
```
|
||||
|
||||
---
|
||||
@@ -66,22 +66,22 @@ GSD はイシューのスコープにある曖昧さ（エラーハンドリン
|
||||
## ステップ 4: フェーズを計画する
|
||||
|
||||
```bash
|
||||
/gsd-plan-phase N
|
||||
/msd-plan-phase N
|
||||
```
|
||||
|
||||
GSD はリサーチエージェントを起動し、`CONTEXT.md` の決定（イシュー URL を含む）を読み込み、アトミックな `PLAN.md` ファイルを生成します。プランチェッカーが各プランを保存前に検証します。
|
||||
MSD はリサーチエージェントを起動し、`CONTEXT.md` の決定（イシュー URL を含む）を読み込み、アトミックな `PLAN.md` ファイルを生成します。プランチェッカーが各プランを保存前に検証します。
|
||||
|
||||
実行前に外部 AI CLI からのピアレビューが必要な場合（重要な変更には推奨）：
|
||||
|
||||
```bash
|
||||
/gsd-review --phase N
|
||||
/gsd-plan-phase N --reviews
|
||||
/msd-review --phase N
|
||||
/msd-plan-phase N --reviews
|
||||
```
|
||||
|
||||
または、HIGH の懸念事項がなくなるまでプラン・レビュー・収束ループを実行するには：
|
||||
|
||||
```bash
|
||||
/gsd-plan-review-convergence N
|
||||
/msd-plan-review-convergence N
|
||||
```
|
||||
|
||||
---
|
||||
@@ -91,19 +91,19 @@ GSD はリサーチエージェントを起動し、`CONTEXT.md` の決定（イ
|
||||
インタラクティブなフェーズ単位の実行の場合：
|
||||
|
||||
```bash
|
||||
/gsd-execute-phase N
|
||||
/msd-execute-phase N
|
||||
```
|
||||
|
||||
すべての残りのフェーズをハンズオフで実行する場合：
|
||||
|
||||
```bash
|
||||
/gsd-autonomous
|
||||
/msd-autonomous
|
||||
```
|
||||
|
||||
進捗を監視しながらフェーズ全体で作業を dispatch できるインタラクティブなダッシュボードの場合：
|
||||
|
||||
```bash
|
||||
/gsd-manager
|
||||
/msd-manager
|
||||
```
|
||||
|
||||
3 つのアプローチすべてで `STATE.md` を更新し、各タスクをアトミックにコミットし、フェーズ後の検証を実行します。
|
||||
@@ -113,10 +113,10 @@ GSD はリサーチエージェントを起動し、`CONTEXT.md` の決定（イ
|
||||
## ステップ 6: 作業を検証する
|
||||
|
||||
```bash
|
||||
/gsd-verify-work N
|
||||
/msd-verify-work N
|
||||
```
|
||||
|
||||
GSD は（トラッカーイシューを反映した）フェーズゴールからの受け入れ基準を 1 つずつ確認します。何かが失敗した場合、GSD は根本原因を診断して修正プランを作成します。すべてのチェックが通るまで execute と verify を繰り返します。
|
||||
MSD は（トラッカーイシューを反映した）フェーズゴールからの受け入れ基準を 1 つずつ確認します。何かが失敗した場合、MSD は根本原因を診断して修正プランを作成します。すべてのチェックが通るまで execute と verify を繰り返します。
|
||||
|
||||
コードが正しく見えても `verification_failed` はブロッカーとして扱ってください。失敗は通常、元のイシューからの見落とされた受け入れ基準を示しています。
|
||||
|
||||
@@ -127,17 +127,17 @@ GSD は（トラッカーイシューを反映した）フェーズゴールか
|
||||
PR を開く前にコードレビューを実行します。
|
||||
|
||||
```bash
|
||||
/gsd-code-review N
|
||||
/gsd-code-review N --fix
|
||||
/msd-code-review N
|
||||
/msd-code-review N --fix
|
||||
```
|
||||
|
||||
次に PR を作成します。
|
||||
|
||||
```bash
|
||||
/gsd-ship N
|
||||
/msd-ship N
|
||||
```
|
||||
|
||||
GSD は計画成果物（フェーズゴール、変更概要、対応した要件、検証ステータス、主要な決定）から PR ボディを組み立てます。PR がマージされた時にトラッカーイシューが自動的にクローズされるよう、PR ボディに `Closes #NNN` または `Fixes #NNN` を含めます（または `/gsd-config` で設定）。
|
||||
MSD は計画成果物（フェーズゴール、変更概要、対応した要件、検証ステータス、主要な決定）から PR ボディを組み立てます。PR がマージされた時にトラッカーイシューが自動的にクローズされるよう、PR ボディに `Closes #NNN` または `Fixes #NNN` を含めます（または `/msd-config` で設定）。
|
||||
|
||||
---
|
||||
|
||||
@@ -146,12 +146,12 @@ GSD は計画成果物（フェーズゴール、変更概要、対応した要
|
||||
イシューを進める中で関連する作業が見つかることがよくあります。コンテキストを失わずに記録します。
|
||||
|
||||
```bash
|
||||
/gsd-capture "Follow-up: description of discovered work" # Todo として追加
|
||||
/gsd-capture --seed "Idea worth a future phase" # 次のマイルストーン用に保存
|
||||
/gsd-capture --backlog "Not urgent but worth tracking" # バックログに保存
|
||||
/msd-capture "Follow-up: description of discovered work" # Todo として追加
|
||||
/msd-capture --seed "Idea worth a future phase" # 次のマイルストーン用に保存
|
||||
/msd-capture --backlog "Not urgent but worth tracking" # バックログに保存
|
||||
```
|
||||
|
||||
GSD はトラッカーに自動的に投稿しません。記録されたフォローアップからトラッカーイシューを作成するのは手動の別ステップです。これにより人間のレビューをループに保ちます。
|
||||
MSD はトラッカーに自動的に投稿しません。記録されたフォローアップからトラッカーイシューを作成するのは手動の別ステップです。これにより人間のレビューをループに保ちます。
|
||||
|
||||
---
|
||||
|
||||
@@ -159,12 +159,12 @@ GSD はトラッカーに自動的に投稿しません。記録されたフォ
|
||||
|
||||
| 状況 | 対応 |
|
||||
|-----------|-----------|
|
||||
| イシューが非常に小さい（タイポ、設定変更） | ワークスペース + discuss + plan をスキップして `/gsd-quick` を使用する |
|
||||
| イシューに複数の独立したサブタスクがある | `/gsd-manager` を使ってプラン全体で並行実行する |
|
||||
| イシューが別のイシューにブロックされている | 上流のブロッカーが解決されるまで開始しない；GSD には自動的な依存ポーラーがない |
|
||||
| 実行中にイシューのスコープが想定より大きくなった | 停止し `/gsd-phase --insert N` でサブフェーズを追加して続行する |
|
||||
| インタラクティブな議論をスキップしたい | `/gsd-discuss-phase` に `--auto` フラグを使用するか、プロジェクト全体の自動化のために `workflow.skip_discuss: true` を設定する |
|
||||
| 複数のイシューが一貫したリリースを形成する | `/gsd-new-milestone` でグループ化し `/gsd-autonomous` で順番に実行する |
|
||||
| イシューが非常に小さい（タイポ、設定変更） | ワークスペース + discuss + plan をスキップして `/msd-quick` を使用する |
|
||||
| イシューに複数の独立したサブタスクがある | `/msd-manager` を使ってプラン全体で並行実行する |
|
||||
| イシューが別のイシューにブロックされている | 上流のブロッカーが解決されるまで開始しない；MSD には自動的な依存ポーラーがない |
|
||||
| 実行中にイシューのスコープが想定より大きくなった | 停止し `/msd-phase --insert N` でサブフェーズを追加して続行する |
|
||||
| インタラクティブな議論をスキップしたい | `/msd-discuss-phase` に `--auto` フラグを使用するか、プロジェクト全体の自動化のために `workflow.skip_discuss: true` を設定する |
|
||||
| 複数のイシューが一貫したリリースを形成する | `/msd-new-milestone` でグループ化し `/msd-autonomous` で順番に実行する |
|
||||
|
||||
---
|
||||
|
||||
@@ -2,19 +2,19 @@
|
||||
|
||||
**目的:** プランニング済みのフェーズをウェーブベースの並列実行で処理し、各プランをアトミックな git コミットとしてランディングさせます。
|
||||
|
||||
**前提条件:** フェーズに少なくとも 1 つの `PLAN.md` ファイルがあること。プランニングがまだ完了していない場合は、先に `/gsd-plan-phase N` を実行してください — [フェーズのプランニング](plan-a-phase.md) を参照。
|
||||
**前提条件:** フェーズに少なくとも 1 つの `PLAN.md` ファイルがあること。プランニングがまだ完了していない場合は、先に `/msd-plan-phase N` を実行してください — [フェーズのプランニング](plan-a-phase.md) を参照。
|
||||
|
||||
---
|
||||
|
||||
## フェーズ全体を実行する
|
||||
|
||||
```bash
|
||||
/gsd-execute-phase 1
|
||||
/msd-execute-phase 1
|
||||
```
|
||||
|
||||
GSD はフェーズのプランファイルを読み込み、依存関係ウェーブにグループ化し、プランごとに新鮮なエグゼキュータエージェントを起動します。各エグゼキュータは次のウェーブが始まる前にアトミックにコミットします。
|
||||
MSD はフェーズのプランファイルを読み込み、依存関係ウェーブにグループ化し、プランごとに新鮮なエグゼキュータエージェントを起動します。各エグゼキュータは次のウェーブが始まる前にアトミックにコミットします。
|
||||
|
||||
エージェントがディスパッチされる前に、GSD はウェーブテーブルを表示します:
|
||||
エージェントがディスパッチされる前に、MSD はウェーブテーブルを表示します:
|
||||
|
||||
```
|
||||
## Execution Plan
|
||||
@@ -38,24 +38,24 @@ Phase 1: Core middleware — 3 plans across 2 wave(s)
|
||||
ウェーブ 1 の出力を確認してからウェーブ 2 に進むなど、1 つのウェーブのみを実行したい場合は `--wave N` を使用します:
|
||||
|
||||
```bash
|
||||
/gsd-execute-phase 1 --wave 2
|
||||
/msd-execute-phase 1 --wave 2
|
||||
```
|
||||
|
||||
GSD はウェーブ 2 のプランのみを実行します。実行前に前のウェーブがすべて完了しているか確認します。ウェーブ 1 のプランがまだ未完了の場合は、先に前のウェーブを完了するよう指示して停止します。
|
||||
MSD はウェーブ 2 のプランのみを実行します。実行前に前のウェーブがすべて完了しているか確認します。ウェーブ 1 のプランがまだ未完了の場合は、先に前のウェーブを完了するよう指示して停止します。
|
||||
|
||||
---
|
||||
|
||||
## 停止した実行を再開する
|
||||
|
||||
クォータエラー、ネットワーク切断、セッションのクラッシュなどで実行が途中停止した場合、ウェーブレベルの進捗は保持されています。GSD は各プランの `SUMMARY.md` ファイルを確認し、すでに存在するプランは再実行時に自動的にスキップされます:
|
||||
クォータエラー、ネットワーク切断、セッションのクラッシュなどで実行が途中停止した場合、ウェーブレベルの進捗は保持されています。MSD は各プランの `SUMMARY.md` ファイルを確認し、すでに存在するプランは再実行時に自動的にスキップされます:
|
||||
|
||||
```bash
|
||||
/gsd-execute-phase 1
|
||||
/msd-execute-phase 1
|
||||
```
|
||||
|
||||
GSD は `SUMMARY.md` がすでに存在するプランをスキップし、最初の未完了プランから再開します。
|
||||
MSD は `SUMMARY.md` がすでに存在するプランをスキップし、最初の未完了プランから再開します。
|
||||
|
||||
**コミットは存在するが `SUMMARY.md` がない場合**（エグゼキュータはコミットしたが、セッションが終了する前にサマリーを書き込まなかった）、GSD はセーフ再開ゲートを表示し、3 つの選択肢を提示します:
|
||||
**コミットは存在するが `SUMMARY.md` がない場合**（エグゼキュータはコミットしたが、セッションが終了する前にサマリーを書き込まなかった）、MSD はセーフ再開ゲートを表示し、3 つの選択肢を提示します:
|
||||
|
||||
- `close out manually` — コミットを確認し、`SUMMARY.md` を書き込んで再実行する
|
||||
- `re-execute from scratch` — 部分的なコミットを差し戻すか上書きしてから新しいエグゼキュータをディスパッチする
|
||||
@@ -88,13 +88,13 @@ Git の履歴には、各エグゼキュータからのタスクごとのコミ
|
||||
`workflow.cross_ai_command` で設定された外部 AI CLI（Codex、Antigravity など）に実行を委任するには:
|
||||
|
||||
```bash
|
||||
/gsd-execute-phase 2 --cross-ai
|
||||
/msd-execute-phase 2 --cross-ai
|
||||
```
|
||||
|
||||
設定でクロス AI が有効であってもローカル実行を強制するには:
|
||||
|
||||
```bash
|
||||
/gsd-execute-phase 2 --no-cross-ai
|
||||
/msd-execute-phase 2 --no-cross-ai
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# クイックタスクと高速タスクの処理方法
|
||||
|
||||
すべての作業がフェーズの中に収まるわけではありません。GSD は、discuss → plan → execute → verify の完全なループを必要としない作業向けに 2 つの軽量コマンドを提供します。
|
||||
すべての作業がフェーズの中に収まるわけではありません。MSD は、discuss → plan → execute → verify の完全なループを必要としない作業向けに 2 つの軽量コマンドを提供します。
|
||||
|
||||
フェーズパイプライン全体がそのオーバーヘッドに見合うかどうかの判断基準については [コンテキストエンジニアリング](../explanation/context-engineering.md) を参照してください。
|
||||
|
||||
@@ -10,30 +10,30 @@
|
||||
|
||||
| 状況 | コマンド |
|
||||
|-----------|---------|
|
||||
| バグ修正、小さな機能追加、または単一の自明な編集として要約できないタスク | `/gsd-quick` |
|
||||
| タイポ修正、設定値の更新、`.gitignore` へのエントリ追加など、3 ファイル以下でかつ 1 分以内の変更 | `/gsd-fast` |
|
||||
| タスクに未知の要素があり、リサーチが必要、または複数のファイルに影響する場合 | `--research` 付きの `/gsd-quick` |
|
||||
| バグ修正、小さな機能追加、または単一の自明な編集として要約できないタスク | `/msd-quick` |
|
||||
| タイポ修正、設定値の更新、`.gitignore` へのエントリ追加など、3 ファイル以下でかつ 1 分以内の変更 | `/msd-fast` |
|
||||
| タスクに未知の要素があり、リサーチが必要、または複数のファイルに影響する場合 | `--research` 付きの `/msd-quick` |
|
||||
|
||||
**目安:** タスクが自明かどうかを一瞬でも迷ったら `/gsd-quick` を使ってください。`/gsd-fast` はスコープが自明でないと判断した場合、自動的に `/gsd-quick` にリダイレクトします。
|
||||
**目安:** タスクが自明かどうかを一瞬でも迷ったら `/msd-quick` を使ってください。`/msd-fast` はスコープが自明でないと判断した場合、自動的に `/msd-quick` にリダイレクトします。
|
||||
|
||||
---
|
||||
|
||||
## `/gsd-quick` — GSD の品質保証付きアドホックタスク
|
||||
## `/msd-quick` — MSD の品質保証付きアドホックタスク
|
||||
|
||||
`/gsd-quick` はフルフェーズと同じアトミックコミットおよび STATE.md トラッキングの保証付きでプランナーとエグゼキュータを実行しますが、フェーズのオーバーヘッドなしに動きます（ROADMAP エントリなし、discuss-phase なし、複数プランにまたがるウェーブ調整なし）。
|
||||
`/msd-quick` はフルフェーズと同じアトミックコミットおよび STATE.md トラッキングの保証付きでプランナーとエグゼキュータを実行しますが、フェーズのオーバーヘッドなしに動きます（ROADMAP エントリなし、discuss-phase なし、複数プランにまたがるウェーブ調整なし）。
|
||||
|
||||
### 基本的な使い方
|
||||
|
||||
```bash
|
||||
/gsd-quick
|
||||
/msd-quick
|
||||
```
|
||||
|
||||
GSD がタスクの説明を求め、プランニングと実行を行います。成果物は `.planning/quick/` に配置されます。
|
||||
MSD がタスクの説明を求め、プランニングと実行を行います。成果物は `.planning/quick/` に配置されます。
|
||||
|
||||
説明を直接渡すこともできます:
|
||||
|
||||
```bash
|
||||
/gsd-quick "Fix the login button not responding on mobile Safari"
|
||||
/msd-quick "Fix the login button not responding on mobile Safari"
|
||||
```
|
||||
|
||||
### フラグ
|
||||
@@ -50,9 +50,9 @@ GSD がタスクの説明を求め、プランニングと実行を行います
|
||||
フラグは自由に組み合わせられます:
|
||||
|
||||
```bash
|
||||
/gsd-quick --research --validate # リサーチ + プランチェック + 検証（検討なし）
|
||||
/gsd-quick --discuss # プランニング前にグレーゾーンのみ確認
|
||||
/gsd-quick --full # 完全な品質パイプライン
|
||||
/msd-quick --research --validate # リサーチ + プランチェック + 検証（検討なし）
|
||||
/msd-quick --discuss # プランニング前にグレーゾーンのみ確認
|
||||
/msd-quick --full # 完全な品質パイプライン
|
||||
```
|
||||
|
||||
### フラグを追加するタイミング
|
||||
@@ -65,38 +65,38 @@ GSD がタスクの説明を求め、プランニングと実行を行います
|
||||
### クイックタスクの一覧と再開
|
||||
|
||||
```bash
|
||||
/gsd-quick list # すべてのクイックタスクとステータスを表示
|
||||
/gsd-quick status my-task-slug # 特定のタスクのステータスを表示
|
||||
/gsd-quick resume my-task-slug # 中断されたタスクを再開
|
||||
/msd-quick list # すべてのクイックタスクとステータスを表示
|
||||
/msd-quick status my-task-slug # 特定のタスクのステータスを表示
|
||||
/msd-quick resume my-task-slug # 中断されたタスクを再開
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## `/gsd-fast` — インラインでの自明な編集
|
||||
## `/msd-fast` — インラインでの自明な編集
|
||||
|
||||
`/gsd-fast` は現在のコンテキストで直接作業を実行します。サブエージェント、`PLAN.md`、リサーチはありません。自分で 1 分以内に実行できる変更のみに適しています。
|
||||
`/msd-fast` は現在のコンテキストで直接作業を実行します。サブエージェント、`PLAN.md`、リサーチはありません。自分で 1 分以内に実行できる変更のみに適しています。
|
||||
|
||||
```bash
|
||||
/gsd-fast "fix typo in README"
|
||||
/gsd-fast "add .env to .gitignore"
|
||||
/msd-fast "fix typo in README"
|
||||
/msd-fast "add .env to .gitignore"
|
||||
```
|
||||
|
||||
説明を省略すると GSD が求めます。
|
||||
説明を省略すると MSD が求めます。
|
||||
|
||||
`/gsd-fast` は続行前にタスクが実際に自明かどうかを確認します。スコープが大きすぎると判断した場合は停止してリダイレクトします:
|
||||
`/msd-fast` は続行前にタスクが実際に自明かどうかを確認します。スコープが大きすぎると判断した場合は停止してリダイレクトします:
|
||||
|
||||
```text
|
||||
This looks like it needs planning. Use /gsd-quick instead:
|
||||
/gsd-quick "your task description"
|
||||
This looks like it needs planning. Use /msd-quick instead:
|
||||
/msd-quick "your task description"
|
||||
```
|
||||
|
||||
変更後、`/gsd-fast` はアトミックにコミットし、`.planning/STATE.md` に `Quick Tasks Completed` テーブルが存在する場合はその行を追記します。
|
||||
変更後、`/msd-fast` はアトミックにコミットし、`.planning/STATE.md` に `Quick Tasks Completed` テーブルが存在する場合はその行を追記します。
|
||||
|
||||
---
|
||||
|
||||
## `/gsd-quick` が `/gsd-fast` にない機能
|
||||
## `/msd-quick` が `/msd-fast` にない機能
|
||||
|
||||
| 機能 | `/gsd-fast` | `/gsd-quick` |
|
||||
| 機能 | `/msd-fast` | `/msd-quick` |
|
||||
|------------|------------|--------------|
|
||||
| サブエージェントプランナー | なし | あり |
|
||||
| サブエージェントエグゼキュータ | なし | あり |
|
||||
@@ -109,7 +109,7 @@ This looks like it needs planning. Use /gsd-quick instead:
|
||||
| STATE.md トラッキング | テーブルが存在すれば行を追記 | 常に更新 |
|
||||
| `.planning/quick/` 成果物 | なし | あり |
|
||||
|
||||
主な違いはサブエージェントの分離です。`/gsd-quick` は新鮮なプランナーとエグゼキュータを別々のコンテキストウィンドウで起動するため、作業が適切にプランされ、コミットはタスクごとにアトミックになり、オーケストレータが結果を検証できます。`/gsd-fast` は現在のコンテキストウィンドウのみを使用し、それらを必要としないほど自明な変更に意図的に限定されています。
|
||||
主な違いはサブエージェントの分離です。`/msd-quick` は新鮮なプランナーとエグゼキュータを別々のコンテキストウィンドウで起動するため、作業が適切にプランされ、コミットはタスクごとにアトミックになり、オーケストレータが結果を検証できます。`/msd-fast` は現在のコンテキストウィンドウのみを使用し、それらを必要としないほど自明な変更に意図的に限定されています。
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# ランタイムへの GSD Core インストール方法
|
||||
# ランタイムへの MSD Core インストール方法
|
||||
|
||||
GSD Core（`@opengsd/gsd-core`）を普段使いの AI コーディングランタイムにインストールします。このガイドでは、サポートされている各ランタイム向けの標準インストール手順と、Node.js がない環境向けの手動手順を説明します。
|
||||
MSD Core（`@golem15/msd-core`）を普段使いの AI コーディングランタイムにインストールします。このガイドでは、サポートされている各ランタイム向けの標準インストール手順と、Node.js がない環境向けの手動手順を説明します。
|
||||
|
||||
**必要なもの:** Node.js 18 以上と npm（または npx）。Node.js がない場合は [Node.js なしでのインストール](#nodejs-なしでのインストール) へ進んでください。
|
||||
|
||||
@@ -8,7 +8,7 @@ GSD Core（`@opengsd/gsd-core`）を普段使いの AI コーディングラン
|
||||
|
||||
## インストーラーが必要な理由
|
||||
|
||||
GSD Core は Claude Code のネイティブ frontmatter 形式でエージェントファイルとコマンドファイルを提供しています。サポートされている各ランタイムは、異なるスキーマ、ディレクトリ構成、コマンド呼び出し構文を要求します。インストーラーは必要な変換を実行します。たとえば OpenCode 向けのツールリストとカラー値の変換、Codex 向けの TOML エージェントエントリの書き込みなどです。
|
||||
MSD Core は Claude Code のネイティブ frontmatter 形式でエージェントファイルとコマンドファイルを提供しています。サポートされている各ランタイムは、異なるスキーマ、ディレクトリ構成、コマンド呼び出し構文を要求します。インストーラーは必要な変換を実行します。たとえば OpenCode 向けのツールリストとカラー値の変換、Codex 向けの TOML エージェントエントリの書き込みなどです。
|
||||
|
||||
**`agents/` や `commands/` からファイルを直接コピーしないでください。** そうするとこれらの変換がスキップされ、スキーマ検証エラーやコマンドの欠落が発生します。
|
||||
|
||||
@@ -19,7 +19,7 @@ GSD Core は Claude Code のネイティブ frontmatter 形式でエージェン
|
||||
任意のディレクトリからインストーラーを実行します。ランタイムの選択と、グローバル（全プロジェクト）またはローカル（このプロジェクトのみ）のどちらでインストールするかを確認するプロンプトが表示されます。
|
||||
|
||||
```bash
|
||||
npx @opengsd/gsd-core@latest
|
||||
npx @golem15/msd-core@latest
|
||||
```
|
||||
|
||||
新規インストールやランタイムの切り替え後にインストーラーを再実行する場合も、このコマンド 1 つだけで完結します。
|
||||
@@ -31,17 +31,17 @@ npx @opengsd/gsd-core@latest
|
||||
### Claude Code
|
||||
|
||||
```bash
|
||||
npx @opengsd/gsd-core@latest --claude --global
|
||||
npx @golem15/msd-core@latest --claude --global
|
||||
```
|
||||
|
||||
スキルは `~/.claude/` に配置されます。次回の Claude Code セッションからコマンドが `/gsd-*` スラッシュコマンドとして表示されます。反映するには Claude Code を再起動してください。
|
||||
スキルは `~/.claude/` に配置されます。次回の Claude Code セッションからコマンドが `/msd-*` スラッシュコマンドとして表示されます。反映するには Claude Code を再起動してください。
|
||||
|
||||
**`--global` と `--local` の両方のスコープへのインストール。** これはサポートされている構成です（プロジェクトによって異なるカスタマイズが必要になることがあるため）が、Claude Code 自身のトリガー解決ルール——個人スコープがプロジェクトスコープより優先され、スキルは同名のコマンドより優先される——はどちらも同じ方向を指します。つまり、グローバルスキルは常にローカルコマンドより `/gsd-<name>` トリガーで勝ちます。GSD Core はこれを検出し、インストール完了直後にどちらのスコープが勝っているかを表示します（同じ事実は `/gsd-health` の診断コード `W028` としても表示されます）。これは警告であり失敗ではありません——インストール自体は成功します。**グローバル**スコープでは、勝者となったスキルのワークフロー仕様への参照は実行時にまず作業ディレクトリを基準に解決されるため、Claude Code が実際に呼び出すのはグローバルスキルであっても、独自の `.claude/gsd-core/` を持つプロジェクトは自分自身の仕様を取得できます。
|
||||
**`--global` と `--local` の両方のスコープへのインストール。** これはサポートされている構成です（プロジェクトによって異なるカスタマイズが必要になることがあるため）が、Claude Code 自身のトリガー解決ルール——個人スコープがプロジェクトスコープより優先され、スキルは同名のコマンドより優先される——はどちらも同じ方向を指します。つまり、グローバルスキルは常にローカルコマンドより `/msd-<name>` トリガーで勝ちます。MSD Core はこれを検出し、インストール完了直後にどちらのスコープが勝っているかを表示します（同じ事実は `/msd-health` の診断コード `W028` としても表示されます）。これは警告であり失敗ではありません——インストール自体は成功します。**グローバル**スコープでは、勝者となったスキルのワークフロー仕様への参照は実行時にまず作業ディレクトリを基準に解決されるため、Claude Code が実際に呼び出すのはグローバルスキルであっても、独自の `.claude/msd-core/` を持つプロジェクトは自分自身の仕様を取得できます。
|
||||
|
||||
**インストールディレクトリの上書き:**
|
||||
|
||||
```bash
|
||||
CLAUDE_CONFIG_DIR=~/.claude-alt npx @opengsd/gsd-core@latest --claude --global
|
||||
CLAUDE_CONFIG_DIR=~/.claude-alt npx @golem15/msd-core@latest --claude --global
|
||||
```
|
||||
|
||||
---
|
||||
@@ -49,7 +49,7 @@ CLAUDE_CONFIG_DIR=~/.claude-alt npx @opengsd/gsd-core@latest --claude --global
|
||||
### OpenCode
|
||||
|
||||
```bash
|
||||
npx @opengsd/gsd-core@latest --opencode --global
|
||||
npx @golem15/msd-core@latest --opencode --global
|
||||
```
|
||||
|
||||
スキルは `~/.config/opencode/`（XDG）または `~/.opencode/` に配置されます。インストーラーはエージェントの frontmatter を OpenCode のスキーマに変換します（`tools:` フィールドの削除、カラー値の hex 変換）。変更内容の詳細は [Node.js なしでのインストール — OpenCode の変換内容](#opencode--必要な変換) を参照してください。
|
||||
@@ -57,7 +57,7 @@ npx @opengsd/gsd-core@latest --opencode --global
|
||||
**インストールディレクトリの上書き:**
|
||||
|
||||
```bash
|
||||
OPENCODE_CONFIG_DIR=~/.config/opencode-alt npx @opengsd/gsd-core@latest --opencode --global
|
||||
OPENCODE_CONFIG_DIR=~/.config/opencode-alt npx @golem15/msd-core@latest --opencode --global
|
||||
```
|
||||
|
||||
---
|
||||
@@ -65,7 +65,7 @@ OPENCODE_CONFIG_DIR=~/.config/opencode-alt npx @opengsd/gsd-core@latest --openco
|
||||
### Kilo
|
||||
|
||||
```bash
|
||||
npx @opengsd/gsd-core@latest --kilo --global
|
||||
npx @golem15/msd-core@latest --kilo --global
|
||||
```
|
||||
|
||||
スキルは `~/.config/kilo/`（XDG）または `~/.kilo/` に配置されます。OpenCode と同じフラットな Markdown コマンド形式を使用します。
|
||||
@@ -73,7 +73,7 @@ npx @opengsd/gsd-core@latest --kilo --global
|
||||
**インストールディレクトリの上書き:**
|
||||
|
||||
```bash
|
||||
KILO_CONFIG_DIR=~/.config/kilo-alt npx @opengsd/gsd-core@latest --kilo --global
|
||||
KILO_CONFIG_DIR=~/.config/kilo-alt npx @golem15/msd-core@latest --kilo --global
|
||||
```
|
||||
|
||||
---
|
||||
@@ -81,10 +81,10 @@ KILO_CONFIG_DIR=~/.config/kilo-alt npx @opengsd/gsd-core@latest --kilo --global
|
||||
### Codex
|
||||
|
||||
```bash
|
||||
npx @opengsd/gsd-core@latest --codex --global
|
||||
npx @golem15/msd-core@latest --codex --global
|
||||
```
|
||||
|
||||
スキルは `~/.codex/skills/gsd-*/SKILL.md` に配置されます。エージェントは `config.toml` にエージェントごとの TOML エントリとして書き込まれます。インストール後は Codex を再起動（または `codex --reload` を実行）してください。
|
||||
スキルは `~/.codex/skills/msd-*/SKILL.md` に配置されます。エージェントは `config.toml` にエージェントごとの TOML エントリとして書き込まれます。インストール後は Codex を再起動（または `codex --reload` を実行）してください。
|
||||
|
||||
**最低サポートバージョン:** Codex CLI 0.130.0。それより古いバージョンにはスキルルートの追加スキャン処理があり、重複リストが生じることがあります。
|
||||
|
||||
@@ -93,15 +93,15 @@ npx @opengsd/gsd-core@latest --codex --global
|
||||
### GitHub Copilot
|
||||
|
||||
```bash
|
||||
npx @opengsd/gsd-core@latest --copilot --global
|
||||
npx @golem15/msd-core@latest --copilot --global
|
||||
```
|
||||
|
||||
スキルは `~/.copilot/` に配置されます。GSD はエージェント `.md` ファイルとリポジトリ instruction ファイルとしてインストールされます。
|
||||
スキルは `~/.copilot/` に配置されます。MSD はエージェント `.md` ファイルとリポジトリ instruction ファイルとしてインストールされます。
|
||||
|
||||
**インストールディレクトリの上書き:**
|
||||
|
||||
```bash
|
||||
COPILOT_CONFIG_DIR=~/.copilot-alt npx @opengsd/gsd-core@latest --copilot --global
|
||||
COPILOT_CONFIG_DIR=~/.copilot-alt npx @golem15/msd-core@latest --copilot --global
|
||||
```
|
||||
|
||||
---
|
||||
@@ -109,15 +109,15 @@ COPILOT_CONFIG_DIR=~/.copilot-alt npx @opengsd/gsd-core@latest --copilot --globa
|
||||
### Cursor
|
||||
|
||||
```bash
|
||||
npx @opengsd/gsd-core@latest --cursor --global
|
||||
npx @golem15/msd-core@latest --cursor --global
|
||||
```
|
||||
|
||||
スキルは `~/.cursor/` に配置されます。GSD はスキル、エージェント、ルールの参照をインストールします。
|
||||
スキルは `~/.cursor/` に配置されます。MSD はスキル、エージェント、ルールの参照をインストールします。
|
||||
|
||||
**インストールディレクトリの上書き:**
|
||||
|
||||
```bash
|
||||
CURSOR_CONFIG_DIR=~/.cursor-alt npx @opengsd/gsd-core@latest --cursor --global
|
||||
CURSOR_CONFIG_DIR=~/.cursor-alt npx @golem15/msd-core@latest --cursor --global
|
||||
```
|
||||
|
||||
---
|
||||
@@ -125,29 +125,29 @@ CURSOR_CONFIG_DIR=~/.cursor-alt npx @opengsd/gsd-core@latest --cursor --global
|
||||
### Windsurf
|
||||
|
||||
```bash
|
||||
npx @opengsd/gsd-core@latest --windsurf --global
|
||||
npx @golem15/msd-core@latest --windsurf --global
|
||||
```
|
||||
|
||||
スキルは `~/.codeium/windsurf/` に配置されます。GSD はスキル、エージェント、ワークスペースルールをインストールします。
|
||||
スキルは `~/.codeium/windsurf/` に配置されます。MSD はスキル、エージェント、ワークスペースルールをインストールします。
|
||||
|
||||
**インストールディレクトリの上書き:**
|
||||
|
||||
```bash
|
||||
WINDSURF_CONFIG_DIR=~/.codeium/windsurf-alt npx @opengsd/gsd-core@latest --windsurf --global
|
||||
WINDSURF_CONFIG_DIR=~/.codeium/windsurf-alt npx @golem15/msd-core@latest --windsurf --global
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Cline
|
||||
|
||||
Cline はルールベースの統合方式を使用します。GSD はスラッシュコマンドではなく `.clinerules` としてインストールされます。
|
||||
Cline はルールベースの統合方式を使用します。MSD はスラッシュコマンドではなく `.clinerules` としてインストールされます。
|
||||
|
||||
```bash
|
||||
# グローバルインストール（全プロジェクト）
|
||||
npx @opengsd/gsd-core@latest --cline --global
|
||||
npx @golem15/msd-core@latest --cline --global
|
||||
|
||||
# ローカルインストール（このプロジェクトのみ）
|
||||
npx @opengsd/gsd-core@latest --cline --local
|
||||
npx @golem15/msd-core@latest --cline --local
|
||||
```
|
||||
|
||||
グローバルインストールは `~/.cline/` に書き込みます。ローカルインストールは `./.cline/` に書き込みます。ルールは Cline によって自動的に読み込まれます。カスタムのスラッシュコマンドは登録されません。
|
||||
@@ -157,10 +157,10 @@ npx @opengsd/gsd-core@latest --cline --local
|
||||
### CodeBuddy
|
||||
|
||||
```bash
|
||||
npx @opengsd/gsd-core@latest --codebuddy --global
|
||||
npx @golem15/msd-core@latest --codebuddy --global
|
||||
```
|
||||
|
||||
スキルは `~/.codebuddy/skills/gsd-*/SKILL.md` に配置されます。
|
||||
スキルは `~/.codebuddy/skills/msd-*/SKILL.md` に配置されます。
|
||||
|
||||
---
|
||||
|
||||
@@ -169,15 +169,15 @@ npx @opengsd/gsd-core@latest --codebuddy --global
|
||||
Qwen Code は Claude Code 2.1.88 以降と同じオープンスキル標準を使用します。
|
||||
|
||||
```bash
|
||||
npx @opengsd/gsd-core@latest --qwen --global
|
||||
npx @golem15/msd-core@latest --qwen --global
|
||||
```
|
||||
|
||||
スキルは `~/.qwen/skills/gsd-*/SKILL.md` に配置されます。
|
||||
スキルは `~/.qwen/skills/msd-*/SKILL.md` に配置されます。
|
||||
|
||||
**インストールディレクトリの上書き:**
|
||||
|
||||
```bash
|
||||
QWEN_CONFIG_DIR=~/.qwen-alt npx @opengsd/gsd-core@latest --qwen --global
|
||||
QWEN_CONFIG_DIR=~/.qwen-alt npx @golem15/msd-core@latest --qwen --global
|
||||
```
|
||||
|
||||
---
|
||||
@@ -185,17 +185,17 @@ QWEN_CONFIG_DIR=~/.qwen-alt npx @opengsd/gsd-core@latest --qwen --global
|
||||
### Augment Code
|
||||
|
||||
```bash
|
||||
npx @opengsd/gsd-core@latest --augment --global
|
||||
npx @golem15/msd-core@latest --augment --global
|
||||
```
|
||||
|
||||
スキルは `~/.augment/` に配置されます。GSD はスキルとエージェントをインストールします。フックや statusline の管理は行いません。
|
||||
スキルは `~/.augment/` に配置されます。MSD はスキルとエージェントをインストールします。フックや statusline の管理は行いません。
|
||||
|
||||
---
|
||||
|
||||
### Antigravity
|
||||
|
||||
```bash
|
||||
npx @opengsd/gsd-core@latest --antigravity --global
|
||||
npx @golem15/msd-core@latest --antigravity --global
|
||||
```
|
||||
|
||||
インストーラーは Antigravity の設定ディレクトリ（`~/.gemini/antigravity`、`~/.gemini/antigravity-ide`、または `~/.gemini/antigravity-cli`）を自動検出します。Gemini 互換の設定ポリシーを使用します。
|
||||
@@ -203,7 +203,7 @@ npx @opengsd/gsd-core@latest --antigravity --global
|
||||
**インストールディレクトリの上書き:**
|
||||
|
||||
```bash
|
||||
ANTIGRAVITY_CONFIG_DIR=~/.gemini/antigravity-alt npx @opengsd/gsd-core@latest --antigravity --global
|
||||
ANTIGRAVITY_CONFIG_DIR=~/.gemini/antigravity-alt npx @golem15/msd-core@latest --antigravity --global
|
||||
```
|
||||
|
||||
---
|
||||
@@ -211,19 +211,19 @@ ANTIGRAVITY_CONFIG_DIR=~/.gemini/antigravity-alt npx @opengsd/gsd-core@latest --
|
||||
### Trae
|
||||
|
||||
```bash
|
||||
npx @opengsd/gsd-core@latest --trae --global
|
||||
npx @golem15/msd-core@latest --trae --global
|
||||
```
|
||||
|
||||
スキルは `~/.trae/` に配置されます。GSD はスキル、エージェント、ルールの参照をインストールします。
|
||||
スキルは `~/.trae/` に配置されます。MSD はスキル、エージェント、ルールの参照をインストールします。
|
||||
|
||||
---
|
||||
|
||||
## ローカルインストールとグローバルインストール
|
||||
|
||||
上記の例はすべて `--global` を使用しており、ユーザーアカウント全体に GSD を一度インストールします。インストールを単一プロジェクトに限定するには、`--global` を `--local` に置き換えます。
|
||||
上記の例はすべて `--global` を使用しており、ユーザーアカウント全体に MSD を一度インストールします。インストールを単一プロジェクトに限定するには、`--global` を `--local` に置き換えます。
|
||||
|
||||
```bash
|
||||
npx @opengsd/gsd-core@latest --claude --local
|
||||
npx @golem15/msd-core@latest --claude --local
|
||||
```
|
||||
|
||||
ローカルインストールはプロジェクトルートの `.claude/` ディレクトリに書き込みます。両方が存在する場合、ローカルインストールの設定がグローバルの設定より優先されます。
|
||||
@@ -235,10 +235,10 @@ npx @opengsd/gsd-core@latest --claude --local
|
||||
ランタイムのプレリリースエディション（Windsurf Next、Cursor Nightly、VS Code Insiders、Codex preview チャンネルなど）は、隣接する設定ディレクトリから読み込みます。インストーラーを実行する前に対応する `*_CONFIG_DIR` 環境変数を設定してください。
|
||||
|
||||
```bash
|
||||
WINDSURF_CONFIG_DIR=~/.codeium/windsurf-next npx @opengsd/gsd-core@latest --windsurf --global
|
||||
WINDSURF_CONFIG_DIR=~/.codeium/windsurf-next npx @golem15/msd-core@latest --windsurf --global
|
||||
```
|
||||
|
||||
インストーラーのプロンプトでは対応する安定版ランタイムを選択してください。GSD はプレリリースエディションを独立した名前付きランタイムとしては列挙していません。これらは環境変数によるベストエフォートの対応であり、リリース CI では個別にテストされていません。
|
||||
インストーラーのプロンプトでは対応する安定版ランタイムを選択してください。MSD はプレリリースエディションを独立した名前付きランタイムとしては列挙していません。これらは環境変数によるベストエフォートの対応であり、リリース CI では個別にテストされていません。
|
||||
|
||||
---
|
||||
|
||||
@@ -249,11 +249,11 @@ WINDSURF_CONFIG_DIR=~/.codeium/windsurf-next npx @opengsd/gsd-core@latest --wind
|
||||
**選択肢 A — Node.js がある別のマシンを使用する。** WSL、Linux VM、CI ランナー、Docker コンテナなど、Node.js があるマシンであれば何でも使えます。そのマシンでインストーラーを実行し、出力ディレクトリをターゲットマシンにコピーします。OpenCode の場合:
|
||||
|
||||
```bash
|
||||
npx @opengsd/gsd-core@latest --opencode --global
|
||||
npx @golem15/msd-core@latest --opencode --global
|
||||
# その後 ~/.config/opencode/agents/ を Windows マシンにコピー
|
||||
```
|
||||
|
||||
**選択肢 B — ソースファイルを手動で変換する。** エージェントのソースファイルは GSD Core リポジトリの `agents/` に存在し、Claude Code のネイティブ frontmatter 形式になっています。各ランタイムは異なる形式を要求します。ランタイムごとの正確なフィールド変換については、ユーザーガイドの [Manual install / no-Node.js setup](../USER-GUIDE.md#manual-install--no-nodejs-setup) を参照してください。OpenCode の変換内容が詳しく説明されており、他のランタイム向けのインストーラーの `convert*Frontmatter` 関数も案内されています。
|
||||
**選択肢 B — ソースファイルを手動で変換する。** エージェントのソースファイルは MSD Core リポジトリの `agents/` に存在し、Claude Code のネイティブ frontmatter 形式になっています。各ランタイムは異なる形式を要求します。ランタイムごとの正確なフィールド変換については、ユーザーガイドの [Manual install / no-Node.js setup](../USER-GUIDE.md#manual-install--no-nodejs-setup) を参照してください。OpenCode の変換内容が詳しく説明されており、他のランタイム向けのインストーラーの `convert*Frontmatter` 関数も案内されています。
|
||||
|
||||
---
|
||||
|
||||
@@ -262,8 +262,8 @@ npx @opengsd/gsd-core@latest --opencode --global
|
||||
新しいコマンドとエージェントを反映するためにランタイムを再起動してください。その後、新規プロジェクトを開始するか既存リポジトリをオンボーディングします。
|
||||
|
||||
```bash
|
||||
/gsd-new-project # グリーンフィールドプロジェクト
|
||||
/gsd-onboard # 既存コードベース
|
||||
/msd-new-project # グリーンフィールドプロジェクト
|
||||
/msd-onboard # 既存コードベース
|
||||
```
|
||||
|
||||
再起動後もコマンドが見つからない場合は、インストールディレクトリがランタイムの期待する設定パスと一致しているか確認してください。最もよくある不一致については上記のプレリリースエディションのセクションを参照してください。
|
||||
@@ -273,6 +273,6 @@ npx @opengsd/gsd-core@latest --opencode --global
|
||||
## Related
|
||||
|
||||
- [最初のプロジェクト](../tutorials/your-first-project.md)
|
||||
- [GSD Core の更新](update-gsd.md)
|
||||
- [MSD Core の更新](update-msd.md)
|
||||
- [設定](../CONFIGURATION.md)
|
||||
- [ドキュメント索引](../README.md)
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# ワークスペースで作業を分離する方法
|
||||
|
||||
**目標:** 独立した git ワークツリー、独自の `.planning/` ルート、そして必要に応じて複数リポジトリを持つ、完全に分離された GSD 環境をフィーチャーブランチやマルチリポジトリ作業のために作成する。
|
||||
**目標:** 独立した git ワークツリー、独自の `.planning/` ルート、そして必要に応じて複数リポジトリを持つ、完全に分離された MSD 環境をフィーチャーブランチやマルチリポジトリ作業のために作成する。
|
||||
|
||||
**前提条件:** `git` がインストールされており、リポジトリがワークツリーをサポートしていること。マルチリポジトリのワークスペースの場合、対象リポジトリがローカルマシン上に存在するか、パスでアクセス可能であること。
|
||||
|
||||
@@ -14,13 +14,13 @@
|
||||
- メンバーリポジトリを追跡する独自の `WORKSPACE.md` マニフェスト
|
||||
- 指定されたリポジトリの git ワークツリー（デフォルト）またはフルクローン（専用ブランチ `workspace/<name>` でチェックアウト）
|
||||
|
||||
ワークスペースはデフォルトで `~/gsd-workspaces/<name>/` 以下に配置されます。
|
||||
ワークスペースはデフォルトで `~/msd-workspaces/<name>/` 以下に配置されます。
|
||||
|
||||
```
|
||||
~/gsd-workspaces/
|
||||
~/msd-workspaces/
|
||||
└── feature-b/
|
||||
├── WORKSPACE.md ← マニフェスト
|
||||
├── .planning/ ← 完全に独立した GSD 状態
|
||||
├── .planning/ ← 完全に独立した MSD 状態
|
||||
│ ├── PROJECT.md
|
||||
│ ├── ROADMAP.md
|
||||
│ └── ...
|
||||
@@ -35,15 +35,15 @@
|
||||
## 複数リポジトリのワークスペースを作成する
|
||||
|
||||
```bash
|
||||
/gsd-workspace --new --name feature-b --repos hr-ui,ZeymoAPI
|
||||
/msd-workspace --new --name feature-b --repos hr-ui,ZeymoAPI
|
||||
```
|
||||
|
||||
GSD は `~/gsd-workspaces/feature-b/` 内に `hr-ui` と `ZeymoAPI` のワークツリーを作成し、それぞれに `workspace/feature-b` ブランチをチェックアウトし、`WORKSPACE.md` を書き込み、`/gsd-new-project` に備えた空の `.planning/` ディレクトリを作成します。
|
||||
MSD は `~/msd-workspaces/feature-b/` 内に `hr-ui` と `ZeymoAPI` のワークツリーを作成し、それぞれに `workspace/feature-b` ブランチをチェックアウトし、`WORKSPACE.md` を書き込み、`/msd-new-project` に備えた空の `.planning/` ディレクトリを作成します。
|
||||
|
||||
場所をカスタマイズするには：
|
||||
|
||||
```bash
|
||||
/gsd-workspace --new --name feature-b --repos hr-ui,ZeymoAPI --path /projects/feature-b
|
||||
/msd-workspace --new --name feature-b --repos hr-ui,ZeymoAPI --path /projects/feature-b
|
||||
```
|
||||
|
||||
---
|
||||
@@ -53,15 +53,15 @@ GSD は `~/gsd-workspaces/feature-b/` 内に `hr-ui` と `ZeymoAPI` のワーク
|
||||
単一リポジトリでフィーチャーブランチの分離が必要な場合（独立したブランチ、独立した `.planning/`、main からの状態汚染なし）：
|
||||
|
||||
```bash
|
||||
/gsd-workspace --new --name payments-rework --repos .
|
||||
/msd-workspace --new --name payments-rework --repos .
|
||||
```
|
||||
|
||||
`.` は現在のリポジトリのワークツリーを作成するよう GSD に指示します。ワークツリーは `workspace/payments-rework` でチェックアウトされます。
|
||||
`.` は現在のリポジトリのワークツリーを作成するよう MSD に指示します。ワークツリーは `workspace/payments-rework` でチェックアウトされます。
|
||||
|
||||
ワークツリーの代わりにフルクローンを強制するには：
|
||||
|
||||
```bash
|
||||
/gsd-workspace --new --name payments-rework --repos . --strategy clone
|
||||
/msd-workspace --new --name payments-rework --repos . --strategy clone
|
||||
```
|
||||
|
||||
---
|
||||
@@ -69,7 +69,7 @@ GSD は `~/gsd-workspaces/feature-b/` 内に `hr-ui` と `ZeymoAPI` のワーク
|
||||
## ブランチを明示的に指定する
|
||||
|
||||
```bash
|
||||
/gsd-workspace --new --name payments-rework --repos . --branch feature/payments-v2
|
||||
/msd-workspace --new --name payments-rework --repos . --branch feature/payments-v2
|
||||
```
|
||||
|
||||
`--branch` フラグはワークスペース内のすべてのリポジトリのブランチ名を設定します。デフォルトは `workspace/<name>` です。
|
||||
@@ -79,43 +79,43 @@ GSD は `~/gsd-workspaces/feature-b/` 内に `hr-ui` と `ZeymoAPI` のワーク
|
||||
## 対話的な質問をスキップする
|
||||
|
||||
```bash
|
||||
/gsd-workspace --new --name payments-rework --repos . --auto
|
||||
/msd-workspace --new --name payments-rework --repos . --auto
|
||||
```
|
||||
|
||||
GSD はプロンプトなしですべてのデフォルト値を適用します。
|
||||
MSD はプロンプトなしですべてのデフォルト値を適用します。
|
||||
|
||||
---
|
||||
|
||||
## ワークスペース内で GSD を初期化する
|
||||
## ワークスペース内で MSD を初期化する
|
||||
|
||||
ワークスペースを作成したら、その中に移動して GSD プロジェクトを初期化します。
|
||||
ワークスペースを作成したら、その中に移動して MSD プロジェクトを初期化します。
|
||||
|
||||
```bash
|
||||
cd ~/gsd-workspaces/feature-b
|
||||
/gsd-new-project
|
||||
cd ~/msd-workspaces/feature-b
|
||||
/msd-new-project
|
||||
```
|
||||
|
||||
ワークスペース内の `.planning/` ディレクトリは、そのディレクトリから実行されるすべての GSD コマンドのルートとなります。ソースリポジトリ内に存在する `.planning/` とは完全に独立しています。
|
||||
ワークスペース内の `.planning/` ディレクトリは、そのディレクトリから実行されるすべての MSD コマンドのルートとなります。ソースリポジトリ内に存在する `.planning/` とは完全に独立しています。
|
||||
|
||||
---
|
||||
|
||||
## ワークスペースを一覧表示する
|
||||
|
||||
```bash
|
||||
/gsd-workspace --list
|
||||
/msd-workspace --list
|
||||
```
|
||||
|
||||
アクティブなすべての GSD ワークスペースとそのステータスを表示します。
|
||||
アクティブなすべての MSD ワークスペースとそのステータスを表示します。
|
||||
|
||||
---
|
||||
|
||||
## ワークスペースを削除する
|
||||
|
||||
```bash
|
||||
/gsd-workspace --remove feature-b
|
||||
/msd-workspace --remove feature-b
|
||||
```
|
||||
|
||||
GSD は git ワークツリーを削除し、ワークスペースディレクトリをクリーンアップします。リモートのブランチは削除されません。ローカルのワークツリーとワークスペースディレクトリのみが対象です。
|
||||
MSD は git ワークツリーを削除し、ワークスペースディレクトリをクリーンアップします。リモートのブランチは削除されません。ローカルのワークツリーとワークスペースディレクトリのみが対象です。
|
||||
|
||||
---
|
||||
|
||||
@@ -123,15 +123,15 @@ GSD は git ワークツリーを削除し、ワークスペースディレク
|
||||
|
||||
ワークスペースを選ぶべき場合：
|
||||
|
||||
- 1 つの GSD プロジェクトとして連携させる必要がある**複数のリポジトリ**（例：一緒にリリースする API リポジトリと UI リポジトリ）にまたがって作業している
|
||||
- 1 つの MSD プロジェクトとして連携させる必要がある**複数のリポジトリ**（例：一緒にリリースする API リポジトリと UI リポジトリ）にまたがって作業している
|
||||
- フィーチャーごとに独自のブランチ、ロックファイル、ビルド成果物を持つ**独立した git ワークツリー**が必要（あるビルド環境での依存関係インストールが他に影響しない）
|
||||
- メインリポジトリの `.planning/` のサブディレクトリではなく、**完全に独立した `.planning/` ルート**が必要
|
||||
- 各トラッカーイシューをワークスペースにマッピングするイシュー駆動ワークフローを採用している（[トラッカーイシューから GSD を操作する](drive-gsd-from-a-tracker-issue.md)を参照）
|
||||
- 各トラッカーイシューをワークスペースにマッピングするイシュー駆動ワークフローを採用している（[トラッカーイシューから MSD を操作する](drive-msd-from-a-tracker-issue.md)を参照）
|
||||
|
||||
代わりに[ワークストリーム](work-in-parallel-with-workstreams.md)を選ぶべき場合：
|
||||
|
||||
- すべての作業が**1 つのリポジトリ**内にあり、同じ git 履歴を共有している
|
||||
- API、UI、インフラなどの異なる関心領域で `/gsd-plan-phase` や `/gsd-discuss-phase` を並行して実行したいが、各領域の `STATE.md` ファイル間でのコンテキスト汚染を避けたい
|
||||
- API、UI、インフラなどの異なる関心領域で `/msd-plan-phase` や `/msd-discuss-phase` を並行して実行したいが、各領域の `STATE.md` ファイル間でのコンテキスト汚染を避けたい
|
||||
- 関心領域ごとに別のワークツリーは不要で、計画コンテキストの切り替えで十分
|
||||
|
||||
---
|
||||
@@ -139,6 +139,6 @@ GSD は git ワークツリーを削除し、ワークスペースディレク
|
||||
## Related
|
||||
|
||||
- [ワークストリームを使って並行して作業する](work-in-parallel-with-workstreams.md)
|
||||
- [トラッカーイシューから GSD を操作する](drive-gsd-from-a-tracker-issue.md)
|
||||
- [トラッカーイシューから MSD を操作する](drive-msd-from-a-tracker-issue.md)
|
||||
- [コマンドリファレンス](../COMMANDS.md)
|
||||
- [ドキュメント一覧](../README.md)
|
||||
|
||||
@@ -1,22 +1,22 @@
|
||||
# GSD-2 から移行する方法
|
||||
|
||||
**目標:** 古い GSD-2 プロジェクト（`.gsd/` ディレクトリレイアウト）を GSD Core（`.planning/` レイアウト）に移行し、リポジトリ内に存在する ADR、PRD、仕様書などを新しい計画構造に取り込む。
|
||||
**目標:** 古い GSD-2 プロジェクト（`.gsd/` ディレクトリレイアウト）を MSD Core（`.planning/` レイアウト）に移行し、リポジトリ内に存在する ADR、PRD、仕様書などを新しい計画構造に取り込む。
|
||||
|
||||
**前提条件:** GSD Core がインストール済みであること。GSD-2 プロジェクトディレクトリがディスク上にアクセス可能な状態であること。
|
||||
**前提条件:** MSD Core がインストール済みであること。GSD-2 プロジェクトディレクトリがディスク上にアクセス可能な状態であること。
|
||||
|
||||
---
|
||||
|
||||
## 何が移行されるかを理解する
|
||||
|
||||
GSD-2 は計画ルートとして `.gsd/` ディレクトリを使用していました。GSD Core は `.planning/` を使用します。移行はこれを逆転させます。`.gsd/` の成果物を読み込み、すべての GSD Core コマンドが期待する標準的な `.planning/` 構造に書き込みます。
|
||||
GSD-2 は計画ルートとして `.gsd/` ディレクトリを使用していました。MSD Core は `.planning/` を使用します。移行はこれを逆転させます。`.gsd/` の成果物を読み込み、すべての MSD Core コマンドが期待する標準的な `.planning/` 構造に書き込みます。
|
||||
|
||||
| GSD-2 に存在するもの | `/gsd-import --from-gsd2` が生成するもの |
|
||||
| GSD-2 に存在するもの | `/msd-import --from-gsd2` が生成するもの |
|
||||
|----------------------|-----------------------------------------|
|
||||
| `.gsd/PROJECT.md` | `.planning/PROJECT.md` |
|
||||
| `.gsd/ROADMAP.md` | `.planning/ROADMAP.md` |
|
||||
| `.gsd/STATE.md` | `.planning/STATE.md` |
|
||||
| `.gsd/phases/` ディレクトリ | `.planning/phases/` ディレクトリ |
|
||||
| フェーズの `PLAN.md` ファイル | GSD Core の `{NN}-{MM}-PLAN.md` ファイル（名前変更を強制） |
|
||||
| フェーズの `PLAN.md` ファイル | MSD Core の `{NN}-{MM}-PLAN.md` ファイル（名前変更を強制） |
|
||||
|
||||
ファイルが書き込まれる前に競合検出が実行されます。対象ディレクトリにすでに `PROJECT.md` があり、インポートするコンテンツと矛盾する場合、移行は BLOCKER ゲートで停止し、解決すべき競合を一覧表示します。
|
||||
|
||||
@@ -27,15 +27,15 @@ GSD-2 は計画ルートとして `.gsd/` ディレクトリを使用してい
|
||||
### 現在のディレクトリを移行する
|
||||
|
||||
```bash
|
||||
/gsd-import --from-gsd2
|
||||
/msd-import --from-gsd2
|
||||
```
|
||||
|
||||
GSD は現在の作業ディレクトリの `.gsd/` を読み込み、移行した成果物を `.planning/` に書き込みます。
|
||||
MSD は現在の作業ディレクトリの `.gsd/` を読み込み、移行した成果物を `.planning/` に書き込みます。
|
||||
|
||||
### 別のパスから移行する
|
||||
|
||||
```bash
|
||||
/gsd-import --from-gsd2 --path ~/projects/old-project
|
||||
/msd-import --from-gsd2 --path ~/projects/old-project
|
||||
```
|
||||
|
||||
GSD-2 プロジェクトが現在の作業ディレクトリでない場合は `--path` を使用します。
|
||||
@@ -46,7 +46,7 @@ GSD-2 プロジェクトが現在の作業ディレクトリでない場合は `
|
||||
|
||||
競合検出がブロッカーを見つけた場合（例：GSD-2 の技術スタック宣言が既存の `.planning/PROJECT.md` と矛盾する）、競合レポートを表示してファイルを書き込まずに停止します。
|
||||
|
||||
レポートを読み、矛盾を解消（ソース文書または既存の計画成果物を編集）してから、`/gsd-import --from-gsd2` を再実行します。移行はクリーンに通過するまで安全に再実行できます。
|
||||
レポートを読み、矛盾を解消（ソース文書または既存の計画成果物を編集）してから、`/msd-import --from-gsd2` を再実行します。移行はクリーンに通過するまで安全に再実行できます。
|
||||
|
||||
---
|
||||
|
||||
@@ -55,30 +55,30 @@ GSD-2 プロジェクトが現在の作業ディレクトリでない場合は `
|
||||
完全な GSD-2 プロジェクトではなく、スタンドアロンのプランドキュメント（チームの計画ドキュメント、Markdown 仕様、エクスポートされたタスクリスト）がある場合は、代わりに `--from` を使用します。
|
||||
|
||||
```bash
|
||||
/gsd-import --from /tmp/team-plan.md
|
||||
/msd-import --from /tmp/team-plan.md
|
||||
```
|
||||
|
||||
GSD は同じ競合検出パスを実行し、コンテンツを GSD Core の `PLAN.md` 形式に変換し、プランチェッカーで結果を検証します。検証後、対象ファイル名と次のステップが表示されます。
|
||||
MSD は同じ競合検出パスを実行し、コンテンツを MSD Core の `PLAN.md` 形式に変換し、プランチェッカーで結果を検証します。検証後、対象ファイル名と次のステップが表示されます。
|
||||
|
||||
---
|
||||
|
||||
## 既存のドキュメントを取り込む
|
||||
|
||||
リポジトリに ADR（アーキテクチャ決定記録）、PRD、仕様ドキュメントがすでに存在する場合は、移行後に `/gsd-ingest-docs` を使って `.planning/` 構造に統合します。
|
||||
リポジトリに ADR（アーキテクチャ決定記録）、PRD、仕様ドキュメントがすでに存在する場合は、移行後に `/msd-ingest-docs` を使って `.planning/` 構造に統合します。
|
||||
|
||||
### リポジトリ全体をスキャンする（モードを自動検出）
|
||||
|
||||
```bash
|
||||
/gsd-ingest-docs
|
||||
/msd-ingest-docs
|
||||
```
|
||||
|
||||
`.planning/` がすでに存在する場合（例：今実行した移行から）、GSD はデフォルトでマージモードになります。既存のものを上書きするのではなく、インポートしたドキュメントを既存のものと並べて統合します。
|
||||
`.planning/` がすでに存在する場合（例：今実行した移行から）、MSD はデフォルトでマージモードになります。既存のものを上書きするのではなく、インポートしたドキュメントを既存のものと並べて統合します。
|
||||
|
||||
### 特定のディレクトリにスコープを絞る
|
||||
|
||||
```bash
|
||||
/gsd-ingest-docs docs/
|
||||
/gsd-ingest-docs docs/adr/
|
||||
/msd-ingest-docs docs/
|
||||
/msd-ingest-docs docs/adr/
|
||||
```
|
||||
|
||||
### 明示的な優先度マニフェストを使用する
|
||||
@@ -86,7 +86,7 @@ GSD は同じ競合検出パスを実行し、コンテンツを GSD Core の `P
|
||||
ドキュメントのタイプが混在している場合や、競合時にどのドキュメントが優先されるかを制御したい場合：
|
||||
|
||||
```bash
|
||||
/gsd-ingest-docs --manifest ingest.yaml
|
||||
/msd-ingest-docs --manifest ingest.yaml
|
||||
```
|
||||
|
||||
マニフェストはドキュメントごとに `{path, type, precedence?}` を列挙する YAML ファイルです。期待される形式については、[コマンドリファレンス](../COMMANDS.md)の `--manifest` フラグの説明を参照してください。
|
||||
@@ -94,11 +94,11 @@ GSD は同じ競合検出パスを実行し、コンテンツを GSD Core の `P
|
||||
### 特定のモードを強制する
|
||||
|
||||
```bash
|
||||
/gsd-ingest-docs --mode merge # 既存の .planning/ にマージする
|
||||
/gsd-ingest-docs --mode new # 最初から構築する（上書き）
|
||||
/msd-ingest-docs --mode merge # 既存の .planning/ にマージする
|
||||
/msd-ingest-docs --mode new # 最初から構築する（上書き）
|
||||
```
|
||||
|
||||
**出力:** `/gsd-ingest-docs` は常に 3 つのバケット（自動解決済み、競合バリアント、未解決ブロッカー）を含む `INGEST-CONFLICTS.md` を生成します。すべてのインポート実行後にこのファイルを確認してください。ハードストップは LOCKED 対 LOCKED の ADR 矛盾の場合のみ発生します。それ以外はすべて確認のために表示され、サイレントに破棄されることはありません。
|
||||
**出力:** `/msd-ingest-docs` は常に 3 つのバケット（自動解決済み、競合バリアント、未解決ブロッカー）を含む `INGEST-CONFLICTS.md` を生成します。すべてのインポート実行後にこのファイルを確認してください。ハードストップは LOCKED 対 LOCKED の ADR 矛盾の場合のみ発生します。それ以外はすべて確認のために表示され、サイレントに破棄されることはありません。
|
||||
|
||||
---
|
||||
|
||||
@@ -107,19 +107,19 @@ GSD は同じ競合検出パスを実行し、コンテンツを GSD Core の `P
|
||||
移行とドキュメントの取り込みが完了したら、プロジェクト状態の一貫性を確認します。
|
||||
|
||||
```bash
|
||||
/gsd-health
|
||||
/gsd-health --repair
|
||||
/msd-health
|
||||
/msd-health --repair
|
||||
```
|
||||
|
||||
`/gsd-health` は `.planning/` ディレクトリの整合性を確認し、ドリフトを報告します。`--repair` は回復可能な問題を自動修正します。
|
||||
`/msd-health` は `.planning/` ディレクトリの整合性を確認し、ドリフトを報告します。`--repair` は回復可能な問題を自動修正します。
|
||||
|
||||
次に、GSD Core がプロジェクト状態を読み込めることを確認します。
|
||||
次に、MSD Core がプロジェクト状態を読み込めることを確認します。
|
||||
|
||||
```bash
|
||||
/gsd-progress
|
||||
/msd-progress
|
||||
```
|
||||
|
||||
プロジェクトが正常に移行されていれば、現在のフェーズステータスと推奨される次のステップが表示されます。ここから標準的な GSD Core ワークフローが適用されます。
|
||||
プロジェクトが正常に移行されていれば、現在のフェーズステータスと推奨される次のステップが表示されます。ここから標準的な MSD Core ワークフローが適用されます。
|
||||
|
||||
---
|
||||
|
||||
@@ -127,13 +127,13 @@ GSD は同じ競合検出パスを実行し、コンテンツを GSD Core の `P
|
||||
|
||||
| 状況 | 対応 |
|
||||
|-----------|-----------|
|
||||
| `.gsd/` が現在のディレクトリにある | `/gsd-import --from-gsd2` を実行する（`--path` 不要） |
|
||||
| `.gsd/` が現在のディレクトリにある | `/msd-import --from-gsd2` を実行する（`--path` 不要） |
|
||||
| `.gsd/` が別のディレクトリにある | `--path ~/projects/old-project` を使用する |
|
||||
| 完全な GSD-2 プロジェクトではなくスタンドアロンのプランドキュメントがある | `/gsd-import --from /path/to/plan.md` を使用する |
|
||||
| `docs/adr/` に ADR がある | 移行後に `/gsd-ingest-docs docs/adr/` を実行する |
|
||||
| ADR、PRD、仕様の混在がある | リポジトリルートで `/gsd-ingest-docs` を実行する（自動分類） |
|
||||
| 完全な GSD-2 プロジェクトではなくスタンドアロンのプランドキュメントがある | `/msd-import --from /path/to/plan.md` を使用する |
|
||||
| `docs/adr/` に ADR がある | 移行後に `/msd-ingest-docs docs/adr/` を実行する |
|
||||
| ADR、PRD、仕様の混在がある | リポジトリルートで `/msd-ingest-docs` を実行する（自動分類） |
|
||||
| 競合検出がブロッカーを報告する | 一覧表示された矛盾を解消してから再実行する；すべてのブロッカーがクリアになるまでファイルは書き込まれない |
|
||||
| 移行が成功したか不明 | `/gsd-health` と `/gsd-progress` を実行して確認する |
|
||||
| 移行が成功したか不明 | `/msd-health` と `/msd-progress` を実行して確認する |
|
||||
| INGEST-CONFLICTS.md に未解決のブロッカーが残っている | 対象ドキュメントが計画に取り込まれる前に手動での解決が必要 |
|
||||
|
||||
---
|
||||
|
||||
@@ -2,23 +2,23 @@
|
||||
|
||||
**目的:** フェーズの決定事項とリサーチを、実行可能なアトミックかつ検証可能なタスクプランに変換します。
|
||||
|
||||
**前提条件:** `.planning/ROADMAP.md` が存在すること。`/gsd-discuss-phase` で生成した `{phase}-CONTEXT.md` を強く推奨しますが、必須ではありません。
|
||||
**前提条件:** `.planning/ROADMAP.md` が存在すること。`/msd-discuss-phase` で生成した `{phase}-CONTEXT.md` を強く推奨しますが、必須ではありません。
|
||||
|
||||
---
|
||||
|
||||
## 標準的なプランニングフローを実行する
|
||||
|
||||
```bash
|
||||
/gsd-plan-phase 2
|
||||
/msd-plan-phase 2
|
||||
```
|
||||
|
||||
これにより 3 つのステージが順番に実行されます:
|
||||
|
||||
1. **リサーチ** — `gsd-phase-researcher` サブエージェントがドメインを調査し、`{phase}-RESEARCH.md` を書き込みます。
|
||||
2. **プラン** — `gsd-planner` サブエージェントがコンテキスト、リサーチ、要件を読み込み、1 つ以上の `{phase}-{N}-PLAN.md` ファイルを書き込みます。
|
||||
3. **検証** — `gsd-plan-checker` サブエージェントが 8 つの次元でプランの品質を検証し、品質ゲートが通過するまでリビジョンループ（最大 3 回）を実行します。
|
||||
1. **リサーチ** — `msd-phase-researcher` サブエージェントがドメインを調査し、`{phase}-RESEARCH.md` を書き込みます。
|
||||
2. **プラン** — `msd-planner` サブエージェントがコンテキスト、リサーチ、要件を読み込み、1 つ以上の `{phase}-{N}-PLAN.md` ファイルを書き込みます。
|
||||
3. **検証** — `msd-plan-checker` サブエージェントが 8 つの次元でプランの品質を検証し、品質ゲートが通過するまでリビジョンループ（最大 3 回）を実行します。
|
||||
|
||||
フェーズ番号を指定しない場合、GSD Core はロードマップから次の未プランフェーズを対象にします。
|
||||
フェーズ番号を指定しない場合、MSD Core はロードマップから次の未プランフェーズを対象にします。
|
||||
|
||||
---
|
||||
|
||||
@@ -27,34 +27,34 @@
|
||||
**ドメインに習熟しており新規リサーチが不要な場合:**
|
||||
|
||||
```bash
|
||||
/gsd-plan-phase 3 --skip-research
|
||||
/msd-plan-phase 3 --skip-research
|
||||
```
|
||||
|
||||
**RESEARCH.md がすでに存在するが強制的に更新したい場合:**
|
||||
|
||||
```bash
|
||||
/gsd-plan-phase 3 --research
|
||||
/msd-plan-phase 3 --research
|
||||
```
|
||||
|
||||
**リサーチのみ実行したい場合** — RESEARCH.md を書き込んでプランニング前に終了:
|
||||
|
||||
```bash
|
||||
/gsd-plan-phase --research-phase 4
|
||||
/msd-plan-phase --research-phase 4
|
||||
```
|
||||
|
||||
RESEARCH.md がすでに存在する場合、更新・表示・スキップのプロンプトが表示されます。プロンプトなしに強制更新するには:
|
||||
|
||||
```bash
|
||||
/gsd-plan-phase --research-phase 4 --research
|
||||
/msd-plan-phase --research-phase 4 --research
|
||||
```
|
||||
|
||||
既存の RESEARCH.md をリサーチャーを起動せずに標準出力に表示するには:
|
||||
|
||||
```bash
|
||||
/gsd-plan-phase --research-phase 4 --view
|
||||
/msd-plan-phase --research-phase 4 --view
|
||||
```
|
||||
|
||||
注意: `--research-phase <N>` は `/gsd-plan-phase` のフラグです。独立したリサーチフェーズコマンドは存在しません。以前の独立したリサーチコマンドはこのフラグに移行されました。
|
||||
注意: `--research-phase <N>` は `/msd-plan-phase` のフラグです。独立したリサーチフェーズコマンドは存在しません。以前の独立したリサーチコマンドはこのフラグに移行されました。
|
||||
|
||||
---
|
||||
|
||||
@@ -63,7 +63,7 @@ RESEARCH.md がすでに存在する場合、更新・表示・スキップの
|
||||
**技術レイヤー別ではなく、薄いエンドツーエンドスライス**（フィーチャーごとに UI → API → DB）でタスクを整理したい場合:
|
||||
|
||||
```bash
|
||||
/gsd-plan-phase 1 --mvp
|
||||
/msd-plan-phase 1 --mvp
|
||||
```
|
||||
|
||||
以前のフェーズサマリーがない新規プロジェクトのフェーズ 1 では、`--mvp` は `SKELETON.md` も生成します。これはプロジェクトの骨格、ルーティング、実際の DB 読み書き 1 件、実際の UI インタラクション 1 件、開発用デプロイをカバーするウォーキングスケルトンです。
|
||||
@@ -77,13 +77,13 @@ RESEARCH.md がすでに存在する場合、更新・表示・スキップの
|
||||
**TDD 強制**が必要な場合 — 振る舞いを追加する各タスクは実装前に失敗するテストから始まります:
|
||||
|
||||
```bash
|
||||
/gsd-plan-phase 1 --tdd
|
||||
/msd-plan-phase 1 --tdd
|
||||
```
|
||||
|
||||
`--mvp` との組み合わせ:
|
||||
|
||||
```bash
|
||||
/gsd-plan-phase 1 --mvp --tdd
|
||||
/msd-plan-phase 1 --mvp --tdd
|
||||
```
|
||||
|
||||
これにより、振る舞いを追加するすべてのタスクが RED → GREEN → REFACTOR に従う垂直スライスが生成されます。プランナーは対象タスク（ビジネスロジック、API エンドポイント、データ変換）に `type: tdd` を適用し、UI、設定、グルーコードには標準の `type: execute` を使用します。
|
||||
@@ -91,17 +91,17 @@ RESEARCH.md がすでに存在する場合、更新・表示・スキップの
|
||||
TDD モードは設定でも永続化できます:
|
||||
|
||||
```bash
|
||||
node gsd-tools.cjs config-set workflow.tdd_mode true
|
||||
node msd-tools.cjs config-set workflow.tdd_mode true
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## クロス AI レビューのフィードバックを使ってリプランする
|
||||
|
||||
**`/gsd-review --phase N` を実行済みで `REVIEWS.md` が存在する場合:**
|
||||
**`/msd-review --phase N` を実行済みで `REVIEWS.md` が存在する場合:**
|
||||
|
||||
```bash
|
||||
/gsd-plan-phase 3 --reviews
|
||||
/msd-plan-phase 3 --reviews
|
||||
```
|
||||
|
||||
プランナーは `REVIEWS.md` を読み込み、フィードバックに対応するようプランを修正します。`--gaps` との組み合わせはできません。
|
||||
@@ -109,7 +109,7 @@ node gsd-tools.cjs config-set workflow.tdd_mode true
|
||||
**自動ループが必要な場合** — HIGH 懸念がなくなるまでリプランと再レビューを繰り返す:
|
||||
|
||||
```bash
|
||||
/gsd-plan-review-convergence 3
|
||||
/msd-plan-review-convergence 3
|
||||
```
|
||||
|
||||
コンバージェンスループは plan → review → replan → re-review サイクルを（デフォルト最大 3 回）実行します。上限を変更するには `--max-cycles N` を使用します。
|
||||
@@ -121,7 +121,7 @@ node gsd-tools.cjs config-set workflow.tdd_mode true
|
||||
**`VERIFICATION.md` に未解決のギャップが存在し、そのギャップのみを対象にリプランしたい場合:**
|
||||
|
||||
```bash
|
||||
/gsd-plan-phase 3 --gaps
|
||||
/msd-plan-phase 3 --gaps
|
||||
```
|
||||
|
||||
リサーチはスキップされ、プランナーは検証ギャップを直接読み込みます。
|
||||
@@ -133,13 +133,13 @@ node gsd-tools.cjs config-set workflow.tdd_mode true
|
||||
**`workflow.plan_bounce_script` が設定されており、完成したプランに対して外部検証を行いたい場合:**
|
||||
|
||||
```bash
|
||||
/gsd-plan-phase 1 --bounce
|
||||
/msd-plan-phase 1 --bounce
|
||||
```
|
||||
|
||||
設定でバウンスが有効でも実行をスキップするには:
|
||||
|
||||
```bash
|
||||
/gsd-plan-phase 1 --skip-bounce
|
||||
/msd-plan-phase 1 --skip-bounce
|
||||
```
|
||||
|
||||
---
|
||||
@@ -147,7 +147,7 @@ node gsd-tools.cjs config-set workflow.tdd_mode true
|
||||
## インタラクティブな確認を抑制する
|
||||
|
||||
```bash
|
||||
/gsd-plan-phase --auto
|
||||
/msd-plan-phase --auto
|
||||
```
|
||||
|
||||
すべてのプロンプトをスキップします。自動化パイプラインで役立ちます。設定で `research_enabled` が false の場合、リサーチはスキップされます。
|
||||
@@ -171,7 +171,7 @@ node gsd-tools.cjs config-set workflow.tdd_mode true
|
||||
|
||||
### プラン品質の次元
|
||||
|
||||
`gsd-plan-checker` は実行を許可する前に 8 つの次元でプランを検証します:
|
||||
`msd-plan-checker` は実行を許可する前に 8 つの次元でプランを検証します:
|
||||
|
||||
1. タスクのアトミック性 — 各タスクは単一の関心事
|
||||
2. 依存関係の正確性 — ウェーブの順序が一貫している
|
||||
@@ -191,7 +191,7 @@ node gsd-tools.cjs config-set workflow.tdd_mode true
|
||||
フェーズに `status: passed` の `VERIFICATION.md` がある場合、そのフェーズはクローズ済みと見なされます。リプランを試みるとエラーで停止します。クローズが誤っていた場合は `--force` で上書きします:
|
||||
|
||||
```bash
|
||||
/gsd-plan-phase 2 --force
|
||||
/msd-plan-phase 2 --force
|
||||
```
|
||||
|
||||
トランスクリプトおよびコミット済みのプランドキュメントに警告が出力されます。
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
**目標:** コンテキストの喪失や状態の破損からインストール失敗やパーミッションエラーまで、条件分岐レシピ構造を使って一般的な問題を特定して修正する。
|
||||
|
||||
**前提条件:** GSD Core がインストール済みであること。インストールの問題については、[ランタイムへのインストール](install-on-your-runtime.md)を参照してください。
|
||||
**前提条件:** MSD Core がインストール済みであること。インストールの問題については、[ランタイムへのインストール](install-on-your-runtime.md)を参照してください。
|
||||
|
||||
---
|
||||
|
||||
@@ -11,7 +11,7 @@
|
||||
### 現在の位置を見失った場合
|
||||
|
||||
```bash
|
||||
/gsd-progress
|
||||
/msd-progress
|
||||
```
|
||||
|
||||
すべての状態ファイルを読み込み、現在地と次にすべきことを正確に教えてくれます。
|
||||
@@ -19,13 +19,13 @@
|
||||
正しい次のステップに自動的に進むには：
|
||||
|
||||
```bash
|
||||
/gsd-progress --next
|
||||
/msd-progress --next
|
||||
```
|
||||
|
||||
### 新しいセッションを開始してコンテキストを復元する必要がある場合
|
||||
|
||||
```bash
|
||||
/gsd-resume-work
|
||||
/msd-resume-work
|
||||
```
|
||||
|
||||
最後のハンドオフから、現在のフェーズ・計画上の決定・作業が停止した場所を含む完全なセッションコンテキストを復元します。
|
||||
@@ -41,21 +41,21 @@
|
||||
その後、状態を復元します。
|
||||
|
||||
```bash
|
||||
/gsd-resume-work
|
||||
/msd-resume-work
|
||||
```
|
||||
|
||||
GSD は新鮮なコンテキストを前提に設計されています。すべてのサブエージェントはすでにクリーンな 200k ウィンドウを取得します。メインセッションは時間とともに劣化します。プッシュし続けるのではなく、クリアして再開することが正しい対処法です。
|
||||
MSD は新鮮なコンテキストを前提に設計されています。すべてのサブエージェントはすでにクリーンな 200k ウィンドウを取得します。メインセッションは時間とともに劣化します。プッシュし続けるのではなく、クリアして再開することが正しい対処法です。
|
||||
|
||||
### 停止前にコンテキストを保存したい場合
|
||||
|
||||
```bash
|
||||
/gsd-pause-work
|
||||
/msd-pause-work
|
||||
```
|
||||
|
||||
現在の位置を含む `.planning/HANDOFF.json` を作成します。セッション後のサマリーを `.planning/reports/` にも書き込む場合は `--report` を追加します。
|
||||
|
||||
```bash
|
||||
/gsd-pause-work --report
|
||||
/msd-pause-work --report
|
||||
```
|
||||
|
||||
---
|
||||
@@ -65,7 +65,7 @@ GSD は新鮮なコンテキストを前提に設計されています。すべ
|
||||
### `.planning/` の整合性が不確かな場合
|
||||
|
||||
```bash
|
||||
/gsd-health
|
||||
/msd-health
|
||||
```
|
||||
|
||||
エラー、警告、情報ノートにわたるステータスを報告します。
|
||||
@@ -79,7 +79,7 @@ GSD は新鮮なコンテキストを前提に設計されています。すべ
|
||||
自動修復可能な一般的な問題（エラー E004、E005；警告 W003、W008）：
|
||||
|
||||
```bash
|
||||
/gsd-health --repair
|
||||
/msd-health --repair
|
||||
```
|
||||
|
||||
これにより不足している `STATE.md` が再作成され、破損した `config.json` がデフォルトにリセットされ、不足している設定キーが追加されます。`PROJECT.md` や `ROADMAP.md` は上書きされません。
|
||||
@@ -89,40 +89,40 @@ GSD は新鮮なコンテキストを前提に設計されています。すべ
|
||||
これは警告 `W002` を生成します。状態 CLI を使って診断と修復を行います。
|
||||
|
||||
```bash
|
||||
node "$HOME/.claude/gsd-core/bin/gsd-tools.cjs" state validate
|
||||
node "$HOME/.claude/msd-core/bin/msd-tools.cjs" state validate
|
||||
```
|
||||
|
||||
書き込まずに同期で何が変わるかをプレビューします。
|
||||
|
||||
```bash
|
||||
node "$HOME/.claude/gsd-core/bin/gsd-tools.cjs" state sync --verify
|
||||
node "$HOME/.claude/msd-core/bin/msd-tools.cjs" state sync --verify
|
||||
```
|
||||
|
||||
同期を適用します。
|
||||
|
||||
```bash
|
||||
node "$HOME/.claude/gsd-core/bin/gsd-tools.cjs" state sync
|
||||
node "$HOME/.claude/msd-core/bin/msd-tools.cjs" state sync
|
||||
```
|
||||
|
||||
これらのコマンドはディスク上の実際のプロジェクト状態から `STATE.md` を再構築します。手動での `STATE.md` 編集に代わるものです。
|
||||
|
||||
### 「Project already initialised」と表示される場合
|
||||
|
||||
`.planning/PROJECT.md` がすでに存在します。`/gsd-new-project` は安全チェックです。本当に最初からやり直したい場合は、まず `.planning/` ディレクトリを削除します。
|
||||
`.planning/PROJECT.md` がすでに存在します。`/msd-new-project` は安全チェックです。本当に最初からやり直したい場合は、まず `.planning/` ディレクトリを削除します。
|
||||
|
||||
```bash
|
||||
rm -rf .planning/
|
||||
```
|
||||
|
||||
その後 `/gsd-new-project` を再実行します。
|
||||
その後 `/msd-new-project` を再実行します。
|
||||
|
||||
### コンテキストウィンドウの使用率が高い場合
|
||||
|
||||
```bash
|
||||
/gsd-health --context
|
||||
/msd-health --context
|
||||
```
|
||||
|
||||
コンテキストウィンドウ使用率ガードを調査します。60% で警告、70% でクリティカル。警告閾値を超えている場合は、次の主要なコマンドを開始する前に `/clear` を実行してから `/gsd-resume-work` を実行してください。
|
||||
コンテキストウィンドウ使用率ガードを調査します。60% で警告、70% でクリティカル。警告閾値を超えている場合は、次の主要なコマンドを開始する前に `/clear` を実行してから `/msd-resume-work` を実行してください。
|
||||
|
||||
---
|
||||
|
||||
@@ -130,7 +130,7 @@ rm -rf .planning/
|
||||
|
||||
### エグゼキューターが Bash コマンドで「Permission denied」になる場合
|
||||
|
||||
GSD の `gsd-executor` サブエージェントには書き込み可能な Bash アクセスが必要です。`~/.claude/settings.json` の `permissions.allow` に必要なパターンを追加します。最低限：
|
||||
MSD の `msd-executor` サブエージェントには書き込み可能な Bash アクセスが必要です。`~/.claude/settings.json` の `permissions.allow` に必要なパターンを追加します。最低限：
|
||||
|
||||
```json
|
||||
"Bash(git add:*)",
|
||||
@@ -148,17 +148,17 @@ GSD の `gsd-executor` サブエージェントには書き込み可能な Bash
|
||||
プランが過度に野心的でないか確認してください。プランには最大でも 2〜3 個のタスクを含めるべきです。タスクが大きすぎると、単一のコンテキストウィンドウが確実に生成できる範囲を超えます。より小さいスコープでフェーズを再計画します。
|
||||
|
||||
```bash
|
||||
/gsd-plan-phase 1
|
||||
/msd-plan-phase 1
|
||||
```
|
||||
|
||||
何が起きたかを体系的に診断するには、[フェーズ実行の失敗をデバッグする](debug-a-failed-execution.md)を参照してください。
|
||||
|
||||
### 並行実行がビルドロックエラーやプリコミットフック失敗を引き起こす場合
|
||||
|
||||
これは複数のエージェントが同時にビルドツールをトリガーすることで発生します。GSD は v1.26 以降、これを自動的に処理します。古いバージョンを使用している場合、またはまだ競合が見られる場合は、並行実行を無効にします。
|
||||
これは複数のエージェントが同時にビルドツールをトリガーすることで発生します。MSD は v1.26 以降、これを自動的に処理します。古いバージョンを使用している場合、またはまだ競合が見られる場合は、並行実行を無効にします。
|
||||
|
||||
```bash
|
||||
/gsd-settings
|
||||
/msd-settings
|
||||
```
|
||||
|
||||
`parallelization.enabled` を `false` に設定します。
|
||||
@@ -171,7 +171,7 @@ GSD の `gsd-executor` サブエージェントには書き込み可能な Bash
|
||||
git log --oneline -10
|
||||
```
|
||||
|
||||
Claude Code の既知の分類バグで、作業が成功したのに失敗と報告される場合があります。GSD のオーケストレーターは実際の出力をスポットチェックしますが、不一致が見られる場合はコミットが真実です。
|
||||
Claude Code の既知の分類バグで、作業が成功したのに失敗と報告される場合があります。MSD のオーケストレーターは実際の出力をスポットチェックしますが、不一致が見られる場合はコミットが真実です。
|
||||
|
||||
---
|
||||
|
||||
@@ -179,31 +179,31 @@ Claude Code の既知の分類バグで、作業が成功したのに失敗と
|
||||
|
||||
### プランが意図と異なる、または整合していない場合
|
||||
|
||||
計画前に `/gsd-discuss-phase N` を実行します。プランの品質問題のほとんどは、`CONTEXT.md` があれば防げた前提から生じます。
|
||||
計画前に `/msd-discuss-phase N` を実行します。プランの品質問題のほとんどは、`CONTEXT.md` があれば防げた前提から生じます。
|
||||
|
||||
```bash
|
||||
/gsd-discuss-phase 1
|
||||
/msd-discuss-phase 1
|
||||
```
|
||||
|
||||
完全なセッションを開始せずに GSD が現在行っている前提を確認するには：
|
||||
完全なセッションを開始せずに MSD が現在行っている前提を確認するには：
|
||||
|
||||
```bash
|
||||
/gsd-discuss-phase 3 --assumptions
|
||||
/msd-discuss-phase 3 --assumptions
|
||||
```
|
||||
|
||||
### 実行後に何かを変更する必要がある場合
|
||||
|
||||
`/gsd-execute-phase` を再実行しないでください。対象を絞った修正には `/gsd-quick` を使用します。
|
||||
`/msd-execute-phase` を再実行しないでください。対象を絞った修正には `/msd-quick` を使用します。
|
||||
|
||||
```bash
|
||||
/gsd-quick "Fix the login button not responding on mobile Safari"
|
||||
/msd-quick "Fix the login button not responding on mobile Safari"
|
||||
```
|
||||
|
||||
または `/gsd-verify-work N` を使って UAT を通じて体系的に問題を特定・修正します。
|
||||
または `/msd-verify-work N` を使って UAT を通じて体系的に問題を特定・修正します。
|
||||
|
||||
### コマンドが「Spawning…」でフリーズしているように見える場合
|
||||
|
||||
待ってください。GSD サブエージェントは別のコンテキストウィンドウで動作します。その作業は進行中の間、親セッションからは見えません。スポーン行の liveness ノートがこれが期待される動作であることを確認しています。リサーチと計画エージェントは通常 1〜5 分かかります。大きなフェーズでは検証エージェントがさらに時間がかかる場合があります。
|
||||
待ってください。MSD サブエージェントは別のコンテキストウィンドウで動作します。その作業は進行中の間、親セッションからは見えません。スポーン行の liveness ノートがこれが期待される動作であることを確認しています。リサーチと計画エージェントは通常 1〜5 分かかります。大きなフェーズでは検証エージェントがさらに時間がかかる場合があります。
|
||||
|
||||
セッションを中断しないでください。セッションを終了すると進行中のサブエージェント作業が破棄されます。
|
||||
|
||||
@@ -216,56 +216,56 @@ Claude Code の既知の分類バグで、作業が成功したのに失敗と
|
||||
### ワークフローが破損しているか、状態が一貫していない場合
|
||||
|
||||
```bash
|
||||
/gsd-forensics
|
||||
/msd-forensics
|
||||
```
|
||||
|
||||
または説明を添えて：
|
||||
|
||||
```bash
|
||||
/gsd-forensics "Phase 3 execution stalled after wave 1"
|
||||
/msd-forensics "Phase 3 execution stalled after wave 1"
|
||||
```
|
||||
|
||||
`/gsd-forensics` はポストモーテム調査を実行します：git 履歴の異常、成果物の整合性、STATE.md の一貫性、未コミットの作業、孤立したワークツリー。レポートを `.planning/forensics/` に書き込み、推奨される修復手順を提示します。読み取り専用であり、プロジェクトファイルを変更することはありません。
|
||||
`/msd-forensics` はポストモーテム調査を実行します：git 履歴の異常、成果物の整合性、STATE.md の一貫性、未コミットの作業、孤立したワークツリー。レポートを `.planning/forensics/` に書き込み、推奨される修復手順を提示します。読み取り専用であり、プロジェクトファイルを変更することはありません。
|
||||
|
||||
### フェーズまたはプランをロールバックする必要がある場合
|
||||
|
||||
```bash
|
||||
/gsd-undo --phase 03 # フェーズ 3 のすべてのコミットをロールバックする
|
||||
/gsd-undo --plan 03-02 # フェーズ 3 のプラン 02 のコミットをロールバックする
|
||||
/gsd-undo --last 5 # 最近の 5 件の GSD コミットからインタラクティブに選ぶ
|
||||
/msd-undo --phase 03 # フェーズ 3 のすべてのコミットをロールバックする
|
||||
/msd-undo --plan 03-02 # フェーズ 3 のプラン 02 のコミットをロールバックする
|
||||
/msd-undo --last 5 # 最近の 5 件の MSD コミットからインタラクティブに選ぶ
|
||||
```
|
||||
|
||||
`/gsd-undo` はロールバック前に依存するフェーズを確認し、常に確認ゲートを表示します。
|
||||
`/msd-undo` はロールバック前に依存するフェーズを確認し、常に確認ゲートを表示します。
|
||||
|
||||
---
|
||||
|
||||
## インストールとアップデートの問題
|
||||
|
||||
### インストール後に GSD が認識されない場合
|
||||
### インストール後に MSD が認識されない場合
|
||||
|
||||
ランタイムを再起動してください。GSD はランタイムのコマンドディレクトリ（例：`~/.claude/commands/gsd/`）にスラッシュコマンドをインストールします。ほとんどのランタイムは起動時にのみ新しいコマンドを検出します。
|
||||
ランタイムを再起動してください。MSD はランタイムのコマンドディレクトリ（例：`~/.claude/commands/msd/`）にスラッシュコマンドをインストールします。ほとんどのランタイムは起動時にのみ新しいコマンドを検出します。
|
||||
|
||||
問題が続く場合はインストールを確認します。
|
||||
|
||||
```bash
|
||||
npx @opengsd/gsd-core@latest --claude --local
|
||||
npx @golem15/msd-core@latest --claude --local
|
||||
```
|
||||
|
||||
ランタイム固有のインストールパスとトラブルシューティングについては、[ランタイムへのインストール](install-on-your-runtime.md)を参照してください。
|
||||
|
||||
### アップデートがローカルの変更を上書きした場合
|
||||
|
||||
v1.17 以降、インストーラはローカルで変更されたファイルを `gsd-local-patches/` にバックアップします。変更を再適用します。
|
||||
v1.17 以降、インストーラはローカルで変更されたファイルを `msd-local-patches/` にバックアップします。変更を再適用します。
|
||||
|
||||
```bash
|
||||
/gsd-update --reapply
|
||||
/msd-update --reapply
|
||||
```
|
||||
|
||||
### npm 経由でアップデートできない場合
|
||||
|
||||
npm の障害やネットワーク制限のために `npx @opengsd/gsd-core` が失敗する場合は、`docs/manual-update.md` に npm アクセスなしで動作するステップバイステップの手動アップデート手順があります。
|
||||
npm の障害やネットワーク制限のために `npx @golem15/msd-core` が失敗する場合は、`docs/manual-update.md` に npm アクセスなしで動作するステップバイステップの手動アップデート手順があります。
|
||||
|
||||
定期的なアップデートについては、[GSD のアップデート](update-gsd.md)を参照してください。
|
||||
定期的なアップデートについては、[MSD のアップデート](update-msd.md)を参照してください。
|
||||
|
||||
---
|
||||
|
||||
@@ -276,13 +276,13 @@ npm の障害やネットワーク制限のために `npx @opengsd/gsd-core` が
|
||||
バジェットプロファイルに切り替えます。
|
||||
|
||||
```bash
|
||||
/gsd-config --profile budget
|
||||
/msd-config --profile budget
|
||||
```
|
||||
|
||||
ドメインが慣れ親しんだものであれば、設定でリサーチとプランチェックのエージェントを無効にします。
|
||||
|
||||
```bash
|
||||
/gsd-settings
|
||||
/msd-settings
|
||||
```
|
||||
|
||||
また、有効になっている MCP サーバーを監査してください。有効な MCP サーバーはそれぞれのツールスキーマをすべてのターンに注入します。ブラウザとプラットフォーム固有のツールはそれぞれ 20,000 トークン以上かかる場合があります。現在のフェーズに不要なものは `.claude/settings.json` で無効にしてください。
|
||||
@@ -299,19 +299,19 @@ npm の障害やネットワーク制限のために `npx @opengsd/gsd-core` が
|
||||
|
||||
| 問題 | 解決策 |
|
||||
|---------|---------|
|
||||
| コンテキストを失った、または新しいセッション | `/gsd-resume-work` または `/gsd-progress` |
|
||||
| 次のステップがわからない | `/gsd-progress --next` |
|
||||
| フェーズがうまくいかなかった | `/gsd-undo --phase NN`、その後再計画する |
|
||||
| 何かが壊れた | `/gsd-debug "description"`（修正なしの分析は `--diagnose` を追加） |
|
||||
| コンテキストを失った、または新しいセッション | `/msd-resume-work` または `/msd-progress` |
|
||||
| 次のステップがわからない | `/msd-progress --next` |
|
||||
| フェーズがうまくいかなかった | `/msd-undo --phase NN`、その後再計画する |
|
||||
| 何かが壊れた | `/msd-debug "description"`（修正なしの分析は `--diagnose` を追加） |
|
||||
| STATE.md が同期していない | `state validate` その後 `state sync` |
|
||||
| `.planning/` の整合性が不確か | `/gsd-health`、その後 `/gsd-health --repair` |
|
||||
| ワークフロー状態が破損しているように見える | `/gsd-forensics` |
|
||||
| 対象を絞った素早い修正 | `/gsd-quick` |
|
||||
| プランがビジョンと一致しない | `/gsd-discuss-phase N` その後再計画する |
|
||||
| コストが高くなっている | `/gsd-config --profile budget` と `/gsd-settings` でエージェントをオフにする |
|
||||
| アップデートがローカルの変更を壊した | `/gsd-update --reapply` |
|
||||
| セッションのサマリーが必要 | `/gsd-pause-work --report` |
|
||||
| 並行実行のビルドエラー | GSD をアップデートするか `parallelization.enabled: false` を設定する |
|
||||
| `.planning/` の整合性が不確か | `/msd-health`、その後 `/msd-health --repair` |
|
||||
| ワークフロー状態が破損しているように見える | `/msd-forensics` |
|
||||
| 対象を絞った素早い修正 | `/msd-quick` |
|
||||
| プランがビジョンと一致しない | `/msd-discuss-phase N` その後再計画する |
|
||||
| コストが高くなっている | `/msd-config --profile budget` と `/msd-settings` でエージェントをオフにする |
|
||||
| アップデートがローカルの変更を壊した | `/msd-update --reapply` |
|
||||
| セッションのサマリーが必要 | `/msd-pause-work --report` |
|
||||
| 並行実行のビルドエラー | MSD をアップデートするか `parallelization.enabled: false` を設定する |
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# フェーズを自律的に実行する方法
|
||||
|
||||
残りのすべてのフェーズ、または限定した範囲のフェーズを無人で実行します。GSD がすべてのステップを自分でドライブすることなく、各フェーズの discuss → plan → execute を処理します。
|
||||
残りのすべてのフェーズ、または限定した範囲のフェーズを無人で実行します。MSD がすべてのステップを自分でドライブすることなく、各フェーズの discuss → plan → execute を処理します。
|
||||
|
||||
自律実行中にフェーズループが何をしているかの背景については [フェーズループ](../explanation/the-phase-loop.md) を参照してください。
|
||||
|
||||
@@ -10,17 +10,17 @@
|
||||
|
||||
- `.planning/ROADMAP.md` と `.planning/STATE.md` が存在するアクティブなプロジェクト
|
||||
- 実行したいすべてのフェーズが自律モードで処理できる状態（pending または in-progress; 完了済みでない）
|
||||
- 重要な設計上の決定事項は `PROJECT.md` に記載済みか、事前の `/gsd-discuss-phase` で記録済みであること。自律モードは `--interactive` を使用した場合のみグレーゾーンをインタラクティブに確認できます
|
||||
- 重要な設計上の決定事項は `PROJECT.md` に記載済みか、事前の `/msd-discuss-phase` で記録済みであること。自律モードは `--interactive` を使用した場合のみグレーゾーンをインタラクティブに確認できます
|
||||
|
||||
---
|
||||
|
||||
## 残りのすべてのフェーズを実行する
|
||||
|
||||
```bash
|
||||
/gsd-autonomous
|
||||
/msd-autonomous
|
||||
```
|
||||
|
||||
GSD は `ROADMAP.md` を読み込み、数値順で未完了のすべてのフェーズを見つけ、それぞれについて discuss → plan → execute を実行します。すべてのフェーズが完了すると、マイルストーンライフサイクル（audit → complete → cleanup）を自動的に実行します。
|
||||
MSD は `ROADMAP.md` を読み込み、数値順で未完了のすべてのフェーズを見つけ、それぞれについて discuss → plan → execute を実行します。すべてのフェーズが完了すると、マイルストーンライフサイクル（audit → complete → cleanup）を自動的に実行します。
|
||||
|
||||
---
|
||||
|
||||
@@ -29,15 +29,15 @@ GSD は `ROADMAP.md` を読み込み、数値順で未完了のすべてのフ
|
||||
`--from` と `--to` を使用して実行範囲を限定します。両フラグは小数のフェーズ番号（例: `3.1`）を受け入れます。
|
||||
|
||||
```bash
|
||||
/gsd-autonomous --from 3 # フェーズ 3、4、5 …（完了済みのフェーズ 1、2 はスキップ）
|
||||
/gsd-autonomous --to 5 # フェーズ 5 まで（5 を含む）
|
||||
/gsd-autonomous --from 3 --to 5 # フェーズ 3、4、5 のみ
|
||||
/msd-autonomous --from 3 # フェーズ 3、4、5 …（完了済みのフェーズ 1、2 はスキップ）
|
||||
/msd-autonomous --to 5 # フェーズ 5 まで（5 を含む）
|
||||
/msd-autonomous --from 3 --to 5 # フェーズ 3、4、5 のみ
|
||||
```
|
||||
|
||||
`--to` に達するとライフサイクルステップはスキップされます。マイルストーンのすべてのフェーズが完了していないためです。完了バナーに再開方法が表示されます:
|
||||
|
||||
```text
|
||||
Resume with: /gsd-autonomous --from 6
|
||||
Resume with: /msd-autonomous --from 6
|
||||
```
|
||||
|
||||
---
|
||||
@@ -47,11 +47,11 @@ Resume with: /gsd-autonomous --from 6
|
||||
デフォルトでは、自律モードはスマート discuss（バッチテーブル提案）を使って検討の質問に自動的に回答します。プランと実行をメインコンテキスト外に保ちながら設計上の質問に自分で回答したい場合:
|
||||
|
||||
```bash
|
||||
/gsd-autonomous --interactive
|
||||
/msd-autonomous --interactive
|
||||
```
|
||||
|
||||
インタラクティブモードでは:
|
||||
- `/gsd-discuss-phase` はインラインで実行され、あなたの回答を待機します
|
||||
- `/msd-discuss-phase` はインラインで実行され、あなたの回答を待機します
|
||||
- プランニングと実行はバックグラウンドエージェントとしてディスパッチされるため、現在のフェーズがビルドされている間に次のフェーズについて検討できます
|
||||
- メインコンテキストはリーンに保たれ — 検討の会話のみが蓄積されます
|
||||
|
||||
@@ -59,7 +59,7 @@ Resume with: /gsd-autonomous --from 6
|
||||
|
||||
## 適用されるセーフティゲート
|
||||
|
||||
自律モードは GSD の品質パイプラインをバイパスしません。各フェーズは引き続き:
|
||||
自律モードは MSD の品質パイプラインをバイパスしません。各フェーズは引き続き:
|
||||
|
||||
- 実行前にプランチェッカーを実行します
|
||||
- 実行後に `VERIFICATION.md` を読み込み、結果に応じてルーティングします
|
||||
@@ -74,15 +74,15 @@ Resume with: /gsd-autonomous --from 6
|
||||
|
||||
## 自律モードを使用しない場合
|
||||
|
||||
`/gsd-autonomous` を使用しないケース:
|
||||
`/msd-autonomous` を使用しないケース:
|
||||
|
||||
- **フェーズに未解決の設計上の決定事項がある場合。** `/gsd-discuss-phase` を実行しておらず、`PROJECT.md` にあなたの方針が記載されていない場合、スマート discuss はあなたが同意しない自律的な選択をする可能性があります。先にインタラクティブで discuss を実行するか、`--interactive` を使用してください。
|
||||
- **フェーズに未解決の設計上の決定事項がある場合。** `/msd-discuss-phase` を実行しておらず、`PROJECT.md` にあなたの方針が記載されていない場合、スマート discuss はあなたが同意しない自律的な選択をする可能性があります。先にインタラクティブで discuss を実行するか、`--interactive` を使用してください。
|
||||
|
||||
- **単一フェーズを細かく制御する必要がある場合。** 1 つのフェーズであれば、`/gsd-execute-phase N` で段階的な出力を確認しながら続行前に対応できます。自律モードは大規模な無人実行向けに設計されています。
|
||||
- **単一フェーズを細かく制御する必要がある場合。** 1 つのフェーズであれば、`/msd-execute-phase N` で段階的な出力を確認しながら続行前に対応できます。自律モードは大規模な無人実行向けに設計されています。
|
||||
|
||||
- **フェーズに新規性の高い、またはリスクの高い作業が含まれる場合。** 自律モードはブロッカーに当たらない限り一時停止をスキップします。予期しない事態が想定されるフェーズでは、手動実行でループに留まってください。
|
||||
|
||||
- **部分的な実行が済んでいる途中フェーズの場合。** 自律モードは未完了フェーズを引き継ぎますが、部分的に実行されたウェーブは再開しません。すでに進行中のフェーズを完了させるには `/gsd-execute-phase N` を使用してください。
|
||||
- **部分的な実行が済んでいる途中フェーズの場合。** 自律モードは未完了フェーズを引き継ぎますが、部分的に実行されたウェーブは再開しません。すでに進行中のフェーズを完了させるには `/msd-execute-phase N` を使用してください。
|
||||
|
||||
実行が途中で停止した場合、何が問題だったかの診断方法については [実行失敗のデバッグ](debug-a-failed-execution.md) を参照してください。
|
||||
|
||||
@@ -93,13 +93,13 @@ Resume with: /gsd-autonomous --from 6
|
||||
自律モードは各フェーズの前に進捗バナーを表示します:
|
||||
|
||||
```text
|
||||
GSD ► AUTONOMOUS ▸ Phase 3/7: Auth Middleware [████░░░░] 28%
|
||||
MSD ► AUTONOMOUS ▸ Phase 3/7: Auth Middleware [████░░░░] 28%
|
||||
```
|
||||
|
||||
セッション途中で実行状況を確認する必要がある場合は、別のターミナルを開いて次を実行します:
|
||||
|
||||
```bash
|
||||
/gsd-progress
|
||||
/msd-progress
|
||||
```
|
||||
|
||||
---
|
||||
@@ -109,10 +109,10 @@ Resume with: /gsd-autonomous --from 6
|
||||
ブロッカープロンプトで「Stop autonomous mode」を選択した場合、またはセッションが中断された場合は、停止した場所から再開します:
|
||||
|
||||
```bash
|
||||
/gsd-autonomous --from 4 # 4 を最初の未完了フェーズ番号に置き換える
|
||||
/msd-autonomous --from 4 # 4 を最初の未完了フェーズ番号に置き換える
|
||||
```
|
||||
|
||||
GSD は完了済みのフェーズを自動的にスキップするため、停止した場所が不明な場合は早めのフェーズ番号から安全に再実行できます。
|
||||
MSD は完了済みのフェーズを自動的にスキップするため、停止した場所が不明な場合は早めのフェーズ番号から安全に再実行できます。
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
|
||||
## 使用するレビュアーを決める
|
||||
|
||||
GSD Core は Claude（別セッション）、Codex CLI、CodeRabbit、OpenCode、Qwen Code、Cursor、Antigravity CLI、Ollama、LM Studio、llama.cpp の任意の組み合わせにレビューリクエストをルーティングできます。
|
||||
MSD Core は Claude（別セッション）、Codex CLI、CodeRabbit、OpenCode、Qwen Code、Cursor、Antigravity CLI、Ollama、LM Studio、llama.cpp の任意の組み合わせにレビューリクエストをルーティングできます。
|
||||
|
||||
各レビュアーは `PLAN.md` ファイルに対して同じ構造化プロンプトを独立して実行します。モデルによって盲点が異なるため、複数レビュアーのコンセンサスは単一レビュアーよりも多くの問題を検出できます。
|
||||
|
||||
@@ -26,18 +26,18 @@ npm install -g @openai/codex
|
||||
|
||||
## デフォルトレビュアーを設定する（オプション）
|
||||
|
||||
デフォルトでは `/gsd-review` は検出されたすべての CLI を実行します。プロジェクトのデフォルトとして特定のサブセットを固定するには:
|
||||
デフォルトでは `/msd-review` は検出されたすべての CLI を実行します。プロジェクトのデフォルトとして特定のサブセットを固定するには:
|
||||
|
||||
```bash
|
||||
/gsd-config --integrations
|
||||
/msd-config --integrations
|
||||
```
|
||||
|
||||
インテグレーションウィザードは API キー、コードレビュー CLI のルーティング、`review.default_reviewers` リストをカバーします。フラグなしのデフォルトとして使用したいレビュアーのリストを設定します。例: `["codex","claude"]`。
|
||||
|
||||
または `gsd-tools` で直接設定することもできます:
|
||||
または `msd-tools` で直接設定することもできます:
|
||||
|
||||
```bash
|
||||
gsd config-set review.default_reviewers '["codex","claude"]'
|
||||
msd config-set review.default_reviewers '["codex","claude"]'
|
||||
```
|
||||
|
||||
インテグレーション設定スキーマの全体（API キー、レビュアーごとのモデルオーバーライド、ローカルサーバーのホストアドレス）については [設定](../CONFIGURATION.md) を参照してください。
|
||||
@@ -49,17 +49,17 @@ gsd config-set review.default_reviewers '["codex","claude"]'
|
||||
### 標準レビュー（設定済みのデフォルトまたは検出されたすべての CLI を使用）
|
||||
|
||||
```bash
|
||||
/gsd-review --phase 3
|
||||
/msd-review --phase 3
|
||||
```
|
||||
|
||||
GSD は各レビュアーを順番に呼び出し、構造化されたフィードバック（サマリー、強み、HIGH/MEDIUM/LOW の懸念事項、提案、リスク評価）を収集し、結合された出力を `.planning/phases/03-.../03-REVIEWS.md` に書き込みます。
|
||||
MSD は各レビュアーを順番に呼び出し、構造化されたフィードバック（サマリー、強み、HIGH/MEDIUM/LOW の懸念事項、提案、リスク評価）を収集し、結合された出力を `.planning/phases/03-.../03-REVIEWS.md` に書き込みます。
|
||||
|
||||
### 1 回限りの実行で特定のレビュアーを選ぶ
|
||||
|
||||
```bash
|
||||
/gsd-review --phase 3 --agy
|
||||
/gsd-review --phase 3 --codex
|
||||
/gsd-review --phase 3 --cursor
|
||||
/msd-review --phase 3 --agy
|
||||
/msd-review --phase 3 --codex
|
||||
/msd-review --phase 3 --cursor
|
||||
```
|
||||
|
||||
明示的なフラグはその実行に限り `--all` のデフォルトと `review.default_reviewers` の両方を上書きします。
|
||||
@@ -67,7 +67,7 @@ GSD は各レビュアーを順番に呼び出し、構造化されたフィー
|
||||
### 利用可能なすべてのレビュアーを並列実行する
|
||||
|
||||
```bash
|
||||
/gsd-review --phase 3 --all
|
||||
/msd-review --phase 3 --all
|
||||
```
|
||||
|
||||
`--all` は設定を常に上書きし、設定済みのローカルモデルサーバー（Ollama、LM Studio、llama.cpp）を含む、検出されたすべてのセットを実行します。
|
||||
@@ -77,11 +77,11 @@ GSD は各レビュアーを順番に呼び出し、構造化されたフィー
|
||||
Ollama または LM Studio をローカルで実行している場合、サーバーに到達可能であれば `--all` で自動的に含まれます。明示的に指定することもできます:
|
||||
|
||||
```bash
|
||||
/gsd-review --phase 3 --ollama
|
||||
/gsd-review --phase 3 --lm-studio
|
||||
/msd-review --phase 3 --ollama
|
||||
/msd-review --phase 3 --lm-studio
|
||||
```
|
||||
|
||||
デフォルト（`localhost:11434` / `localhost:1234`）が合わない場合は、`/gsd-config --integrations` で `review.*` キーの下にホストアドレスとモデル選択を設定してください。
|
||||
デフォルト（`localhost:11434` / `localhost:1234`）が合わない場合は、`/msd-config --integrations` で `review.*` キーの下にホストアドレスとモデル選択を設定してください。
|
||||
|
||||
---
|
||||
|
||||
@@ -100,7 +100,7 @@ Ollama または LM Studio をローカルで実行している場合、サー
|
||||
出力を確認したら、フィードバックを取り込んでリプランします:
|
||||
|
||||
```bash
|
||||
/gsd-plan-phase 3 --reviews
|
||||
/msd-plan-phase 3 --reviews
|
||||
```
|
||||
|
||||
プランナーは `REVIEWS.md` を読み込み、懸念事項に対応するようプランを調整してから保存します。
|
||||
@@ -112,7 +112,7 @@ Ollama または LM Studio をローカルで実行している場合、サー
|
||||
HIGH 重大度の懸念事項がすべて解決されるまで反復したい場合はコンバージェンスループを使用します:
|
||||
|
||||
```bash
|
||||
/gsd-plan-review-convergence 3
|
||||
/msd-plan-review-convergence 3
|
||||
```
|
||||
|
||||
これは `plan-phase → review → replan → re-review` を最大 3 サイクル（デフォルト）実行します。HIGH 懸念事項のカウントがゼロになるとループが終了します。
|
||||
@@ -120,17 +120,17 @@ HIGH 重大度の懸念事項がすべて解決されるまで反復したい場
|
||||
### 特定のレビュアーとのコンバージェンス
|
||||
|
||||
```bash
|
||||
/gsd-plan-review-convergence 3 --codex
|
||||
/gsd-plan-review-convergence 3 --agy
|
||||
/msd-plan-review-convergence 3 --codex
|
||||
/msd-plan-review-convergence 3 --agy
|
||||
```
|
||||
|
||||
### すべてのレビュアーと高いサイクル上限でのコンバージェンス
|
||||
|
||||
```bash
|
||||
/gsd-plan-review-convergence 3 --all --max-cycles 5
|
||||
/msd-plan-review-convergence 3 --all --max-cycles 5
|
||||
```
|
||||
|
||||
**ストール検知:** サイクルをまたいで HIGH 懸念事項のカウントが減少していない場合、GSD は警告します。サイクル上限に達しても HIGH 懸念事項が残っている場合、エスカレーションゲートが表示され、続行するか手動でレビューするかを確認します。
|
||||
**ストール検知:** サイクルをまたいで HIGH 懸念事項のカウントが減少していない場合、MSD は警告します。サイクル上限に達しても HIGH 懸念事項が残っている場合、エスカレーションゲートが表示され、続行するか手動でレビューするかを確認します。
|
||||
|
||||
---
|
||||
|
||||
@@ -143,8 +143,8 @@ HIGH 重大度の懸念事項がすべて解決されるまで反復したい場
|
||||
| プロジェクトが OpenAI 中心 | OpenAI モデルの観点のために `--codex` を追加 |
|
||||
| GitHub Copilot のモデルが欲しい | `--opencode` を追加 |
|
||||
| API コストを完全に避けたい | Ollama にローカルモデルを設定して `--ollama` を使用 |
|
||||
| リリース前に最大限のカバレッジが必要 | `/gsd-plan-review-convergence N --all` |
|
||||
| 素早く反復して高速なフィードバックが欲しい | 1 つの CLI を選ぶ: `/gsd-review --phase N --agy` |
|
||||
| リリース前に最大限のカバレッジが必要 | `/msd-plan-review-convergence N --all` |
|
||||
| 素早く反復して高速なフィードバックが欲しい | 1 つの CLI を選ぶ: `/msd-review --phase N --agy` |
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
**目標:** フェーズを特定のアプローチに確定する前に、集中的な実現可能性実験（スパイク）と使い捨ての HTML モックアップによるビジュアル方向探索（スケッチ）を通じて、実装のリスクを軽減する。
|
||||
|
||||
**前提条件:** なし。`/gsd-spike` と `/gsd-sketch` は独自のストレージディレクトリを作成し、初期化済みの GSD プロジェクトは必要ありません。
|
||||
**前提条件:** なし。`/msd-spike` と `/msd-sketch` は独自のストレージディレクトリを作成し、初期化済みの MSD プロジェクトは必要ありません。
|
||||
|
||||
---
|
||||
|
||||
@@ -10,8 +10,8 @@
|
||||
|
||||
| 答えたい問い | 使用するもの |
|
||||
|---|---|
|
||||
| 「この技術的アプローチは実際に機能するか？」 | `/gsd-spike` |
|
||||
| 「このレイアウト / インタラクション / ビジュアル処理は適切か？」 | `/gsd-sketch` |
|
||||
| 「この技術的アプローチは実際に機能するか？」 | `/msd-spike` |
|
||||
| 「このレイアウト / インタラクション / ビジュアル処理は適切か？」 | `/msd-sketch` |
|
||||
| 「適切な技術的アプローチは何で、どのように見えるべきか？」 | 両方、順番に：スパイク先行、次にスケッチ |
|
||||
|
||||
スパイクは実行可能なコードと VALIDATED / INVALIDATED / PARTIAL の判定で、二項対立の実現可能性問題に答えます。スケッチはブラウザで比較可能な 2〜3 種類の HTML バリアントで、ビジュアルの問いに答えます。両者は補完的です。スパイクはアプローチの構築可能性を証明し、スケッチはデザインの構築する価値を証明します。
|
||||
@@ -23,21 +23,21 @@
|
||||
### インタラクティブな受付（デフォルト）
|
||||
|
||||
```bash
|
||||
/gsd-spike
|
||||
/msd-spike
|
||||
```
|
||||
|
||||
GSD は技術的な問いについて質問し、それを **Given / When / Then** 形式の仮説として 2〜5 個の独立した実験に分解し、構築前に確認を求めます。
|
||||
MSD は技術的な問いについて質問し、それを **Given / When / Then** 形式の仮説として 2〜5 個の独立した実験に分解し、構築前に確認を求めます。
|
||||
|
||||
### アイデアを直接指定する
|
||||
|
||||
```bash
|
||||
/gsd-spike "can we stream LLM tokens through SSE"
|
||||
/msd-spike "can we stream LLM tokens through SSE"
|
||||
```
|
||||
|
||||
### 受付をスキップしてすぐに実行する
|
||||
|
||||
```bash
|
||||
/gsd-spike --quick "websocket vs SSE latency"
|
||||
/msd-spike --quick "websocket vs SSE latency"
|
||||
```
|
||||
|
||||
`--quick` は分解の会話をスキップし、引数を単一のスパイク質問として扱います。問いがすでに精度が高く、絞り込みなしに実行できる場合に使用してください。
|
||||
@@ -59,10 +59,10 @@ GSD は技術的な問いについて質問し、それを **Given / When / Then
|
||||
シグナルが得られたら、今後のセッションで自動的に読み込まれるプロジェクトローカルスキルとして知見をまとめます。
|
||||
|
||||
```bash
|
||||
/gsd-spike --wrap-up
|
||||
/msd-spike --wrap-up
|
||||
```
|
||||
|
||||
これにより `.claude/skills/spike-findings-[project]/` が書き込まれます。このスキルは自動的に検出され、後続の `/gsd-sketch`、`/gsd-ui-phase`、`/gsd-plan-phase` の実行時に読み込まれます。明示的に参照する必要はありません。
|
||||
これにより `.claude/skills/spike-findings-[project]/` が書き込まれます。このスキルは自動的に検出され、後続の `/msd-sketch`、`/msd-ui-phase`、`/msd-plan-phase` の実行時に読み込まれます。明示的に参照する必要はありません。
|
||||
|
||||
---
|
||||
|
||||
@@ -71,21 +71,21 @@ GSD は技術的な問いについて質問し、それを **Given / When / Then
|
||||
### ムードの受付（デフォルト）
|
||||
|
||||
```bash
|
||||
/gsd-sketch
|
||||
/msd-sketch
|
||||
```
|
||||
|
||||
GSD は、コードを書く前に、雰囲気、ビジュアルリファレンス、コアユーザーアクションを探る短い会話を開きます。一度に 1 つの質問をして、「実行してください」と言った時点でのみ構築を開始します。
|
||||
MSD は、コードを書く前に、雰囲気、ビジュアルリファレンス、コアユーザーアクションを探る短い会話を開きます。一度に 1 つの質問をして、「実行してください」と言った時点でのみ構築を開始します。
|
||||
|
||||
### デザイン方向を直接指定する
|
||||
|
||||
```bash
|
||||
/gsd-sketch "dashboard layout"
|
||||
/msd-sketch "dashboard layout"
|
||||
```
|
||||
|
||||
### ムードの受付をスキップしてすぐに実行する
|
||||
|
||||
```bash
|
||||
/gsd-sketch --quick "sidebar navigation"
|
||||
/msd-sketch --quick "sidebar navigation"
|
||||
```
|
||||
|
||||
`--quick` は受付の会話を完全にスキップし、引数をデザイン方向として使用します。
|
||||
@@ -93,7 +93,7 @@ GSD は、コードを書く前に、雰囲気、ビジュアルリファレン
|
||||
### Claude 以外のランタイム（Codex、Antigravity CLI など）
|
||||
|
||||
```bash
|
||||
/gsd-sketch --text "onboarding flow"
|
||||
/msd-sketch --text "onboarding flow"
|
||||
```
|
||||
|
||||
`--text` はインタラクティブなプロンプトをプレーンテキストの番号付きリストに置き換えます。ランタイムが `AskUserQuestion` をサポートしていない場合に使用してください。
|
||||
@@ -115,10 +115,10 @@ GSD は、コードを書く前に、雰囲気、ビジュアルリファレン
|
||||
バリアントを選択したら、ビジュアル決定をプロジェクトローカルスキルとして記録します。
|
||||
|
||||
```bash
|
||||
/gsd-sketch --wrap-up
|
||||
/msd-sketch --wrap-up
|
||||
```
|
||||
|
||||
これにより `.claude/skills/sketch-findings-[project]/` が書き込まれます。このスキルは `/gsd-ui-phase` によって自動的に読み込まれ、事前に検証された決定（レイアウト、カラーパレット、タイポグラフィ、スペーシング）はロック済みとして扱われ、再確認されません。
|
||||
これにより `.claude/skills/sketch-findings-[project]/` が書き込まれます。このスキルは `/msd-ui-phase` によって自動的に読み込まれ、事前に検証された決定（レイアウト、カラーパレット、タイポグラフィ、スペーシング）はロック済みとして扱われ、再確認されません。
|
||||
|
||||
---
|
||||
|
||||
@@ -127,26 +127,26 @@ GSD は、コードを書く前に、雰囲気、ビジュアルリファレン
|
||||
技術的な実現可能性とビジュアル方向の両方が不確かな場合、以下の順序が推奨されます。
|
||||
|
||||
```bash
|
||||
/gsd-spike "SSE vs WebSocket for real-time feed"
|
||||
/gsd-spike --wrap-up
|
||||
/msd-spike "SSE vs WebSocket for real-time feed"
|
||||
/msd-spike --wrap-up
|
||||
|
||||
/gsd-sketch "real-time feed UI"
|
||||
/gsd-sketch --wrap-up
|
||||
/msd-sketch "real-time feed UI"
|
||||
/msd-sketch --wrap-up
|
||||
|
||||
/gsd-discuss-phase N
|
||||
/gsd-plan-phase N
|
||||
/msd-discuss-phase N
|
||||
/msd-plan-phase N
|
||||
```
|
||||
|
||||
スパイク知見はスケッチに反映されます（実際のデータ形状、実際のインタラクション状態、現実的な制約）。両方の wrap-up は決定を永続化し、プランナーと UI リサーチャーが自動的に読み込みます。そのため、`/gsd-discuss-phase` や `/gsd-ui-phase` 中に選択内容を再説明する必要はありません。
|
||||
スパイク知見はスケッチに反映されます（実際のデータ形状、実際のインタラクション状態、現実的な制約）。両方の wrap-up は決定を永続化し、プランナーと UI リサーチャーが自動的に読み込みます。そのため、`/msd-discuss-phase` や `/msd-ui-phase` 中に選択内容を再説明する必要はありません。
|
||||
|
||||
---
|
||||
|
||||
## スパイクまたはスケッチがフェーズにどう組み込まれるか
|
||||
|
||||
スパイクとスケッチの成果物は手動で参照する必要はありません。GSD は 2 つのタイミングで自動的に読み込みます。
|
||||
スパイクとスケッチの成果物は手動で参照する必要はありません。MSD は 2 つのタイミングで自動的に読み込みます。
|
||||
|
||||
1. **`/gsd-sketch`** — モックアップ構築前に `.claude/skills/spike-findings-*/` を読み込み、バリアントが証明済みの制約（ストリーミング状態、実際のフィールド名など）を反映するようにする
|
||||
2. **`/gsd-ui-phase N`** — UI デザインコントラクト生成前に `.claude/skills/sketch-findings-*/` を読み込み、事前検証済みのデザイン決定をロック済みとして扱う
|
||||
1. **`/msd-sketch`** — モックアップ構築前に `.claude/skills/spike-findings-*/` を読み込み、バリアントが証明済みの制約（ストリーミング状態、実際のフィールド名など）を反映するようにする
|
||||
2. **`/msd-ui-phase N`** — UI デザインコントラクト生成前に `.claude/skills/sketch-findings-*/` を読み込み、事前検証済みのデザイン決定をロック済みとして扱う
|
||||
|
||||
プランナーも `spike-findings-*` スキルが存在する場合はスパイク知見を読み込むため、検証済みの技術的選択（ライブラリ、プロトコル、データ形式）が繰り返しの説明なしに直接タスクプランに反映されます。
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# GSD Core をアップデートする方法
|
||||
# MSD Core をアップデートする方法
|
||||
|
||||
既存の GSD Core インストールを最新リリースに更新し、コミット前に変更履歴をプレビューし、アップデートによって上書きされるローカルカスタマイズを回復します。
|
||||
既存の MSD Core インストールを最新リリースに更新し、コミット前に変更履歴をプレビューし、アップデートによって上書きされるローカルカスタマイズを回復します。
|
||||
|
||||
**必要なもの:** GSD がインストールされているのと同じランタイム。アップデートコマンドは内部でインストーラを再実行するため、Node.js と npx が利用可能である必要があります（元のインストールと同じ要件）。
|
||||
**必要なもの:** MSD がインストールされているのと同じランタイム。アップデートコマンドは内部でインストーラを再実行するため、Node.js と npx が利用可能である必要があります（元のインストールと同じ要件）。
|
||||
|
||||
---
|
||||
|
||||
@@ -11,19 +11,19 @@
|
||||
AI ランタイム内から以下を実行します。
|
||||
|
||||
```bash
|
||||
/gsd-update
|
||||
/msd-update
|
||||
```
|
||||
|
||||
GSD は以下を実行します。
|
||||
MSD は以下を実行します。
|
||||
|
||||
1. インストール済みバージョンとインストールスコープ（グローバルまたはローカル）を検出する。
|
||||
2. `@opengsd/gsd-core` の最新リリースを npm で確認する。
|
||||
2. `@golem15/msd-core` の最新リリースを npm で確認する。
|
||||
3. 変更履歴を取得し、インストール済みバージョンと最新バージョンの差分を表示する。
|
||||
4. 何も触れる前に確認を求める。
|
||||
5. GSD 管理ディレクトリ内に見つかったユーザーが追加したファイルを `gsd-user-files-backup/` にバックアップする。
|
||||
6. インストーラを実行する（`npx @opengsd/gsd-core@latest --<runtime> --<scope>`）。
|
||||
5. MSD 管理ディレクトリ内に見つかったユーザーが追加したファイルを `msd-user-files-backup/` にバックアップする。
|
||||
6. インストーラを実行する（`npx @golem15/msd-core@latest --<runtime> --<scope>`）。
|
||||
7. アップデートチェックキャッシュをクリアしてステータスラインのインジケーターをリセットする。
|
||||
8. ローカルで変更された GSD ファイルが `gsd-local-patches/` にバックアップされたかどうかを報告する。
|
||||
8. ローカルで変更された MSD ファイルが `msd-local-patches/` にバックアップされたかどうかを報告する。
|
||||
|
||||
アップデート後にランタイムを再起動して、新しいコマンドとエージェントを読み込んでください。
|
||||
|
||||
@@ -33,22 +33,22 @@ GSD は以下を実行します。
|
||||
|
||||
| フラグ | 動作 |
|
||||
|------|--------------|
|
||||
| `--sync` | アップデート後に GSD レジストリからスキルを同期する |
|
||||
| `--reapply` | アップデート後に `gsd-local-patches/` からローカルで変更された GSD ファイルをマージして戻す |
|
||||
| `--sync` | アップデート後に MSD レジストリからスキルを同期する |
|
||||
| `--reapply` | アップデート後に `msd-local-patches/` からローカルで変更された MSD ファイルをマージして戻す |
|
||||
|
||||
```bash
|
||||
/gsd-update --sync # アップデートしてスキルを同期する
|
||||
/gsd-update --reapply # アップデートしてローカルパッチを再適用する
|
||||
/msd-update --sync # アップデートしてスキルを同期する
|
||||
/msd-update --reapply # アップデートしてローカルパッチを再適用する
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## アップデート前に変更履歴を確認する
|
||||
|
||||
`/gsd-update` は確認を求める前に、インストール済みバージョンと最新バージョン間の変更履歴差分を常に表示します。GitHub を別途確認する必要はありません。出力は以下のようになります。
|
||||
`/msd-update` は確認を求める前に、インストール済みバージョンと最新バージョン間の変更履歴差分を常に表示します。GitHub を別途確認する必要はありません。出力は以下のようになります。
|
||||
|
||||
```text
|
||||
## GSD Update Available
|
||||
## MSD Update Available
|
||||
|
||||
Installed: 1.39.0
|
||||
Latest: 1.41.0
|
||||
@@ -70,47 +70,47 @@ Proceed with update? [Yes, update now / No, cancel]
|
||||
|
||||
## ローカルカスタマイズの回復
|
||||
|
||||
### GSD 管理ディレクトリ内に追加したファイル
|
||||
### MSD 管理ディレクトリ内に追加したファイル
|
||||
|
||||
GSD が所有するディレクトリ内にカスタムファイルを配置した場合（例：`gsd-` プレフィックスのカスタムエージェント、`commands/gsd/` への追加ファイル）、インストーラはそれらを検出し、ディレクトリを削除する前に `gsd-user-files-backup/` にコピーします。アップデート後、そのバックアップ場所から手動で復元してください。
|
||||
MSD が所有するディレクトリ内にカスタムファイルを配置した場合（例：`msd-` プレフィックスのカスタムエージェント、`commands/msd/` への追加ファイル）、インストーラはそれらを検出し、ディレクトリを削除する前に `msd-user-files-backup/` にコピーします。アップデート後、そのバックアップ場所から手動で復元してください。
|
||||
|
||||
GSD 管理ディレクトリの外に配置したファイル（`gsd-` プレフィックスのないカスタムエージェント、`commands/gsd/` 外のカスタムコマンド、`CLAUDE.md` ファイル、カスタムフック）はインストーラによって一切変更されません。
|
||||
MSD 管理ディレクトリの外に配置したファイル（`msd-` プレフィックスのないカスタムエージェント、`commands/msd/` 外のカスタムコマンド、`CLAUDE.md` ファイル、カスタムフック）はインストーラによって一切変更されません。
|
||||
|
||||
### GSD がインストールしたファイルへの直接変更
|
||||
### MSD がインストールしたファイルへの直接変更
|
||||
|
||||
GSD がインストールしたファイルを編集した場合（例：エージェントのシステムプロンプトの調整）、インストーラはマニフェストのハッシュ比較で変更を検出し、ファイルを `gsd-local-patches/` にバックアップしてから新しいバージョンで置き換えます。アップデート後：
|
||||
MSD がインストールしたファイルを編集した場合（例：エージェントのシステムプロンプトの調整）、インストーラはマニフェストのハッシュ比較で変更を検出し、ファイルを `msd-local-patches/` にバックアップしてから新しいバージョンで置き換えます。アップデート後：
|
||||
|
||||
```bash
|
||||
/gsd-update --reapply
|
||||
/msd-update --reapply
|
||||
```
|
||||
|
||||
これにより、新しくインストールされたファイルに `gsd-local-patches/` からの変更がマージして戻されます。
|
||||
これにより、新しくインストールされたファイルに `msd-local-patches/` からの変更がマージして戻されます。
|
||||
|
||||
以前のアップデート後に `--reapply` をスキップしてパッチを今すぐ適用したい場合：
|
||||
|
||||
```bash
|
||||
/gsd-update --reapply
|
||||
/msd-update --reapply
|
||||
```
|
||||
|
||||
`--reapply` は新しいダウンロードをトリガーせずに単独で実行しても安全です。すでに最新バージョンであれば、GSD はインストールステップをスキップして直接パッチの再適用に進みます。
|
||||
`--reapply` は新しいダウンロードをトリガーせずに単独で実行しても安全です。すでに最新バージョンであれば、MSD はインストールステップをスキップして直接パッチの再適用に進みます。
|
||||
|
||||
---
|
||||
|
||||
## npm が利用できない場合
|
||||
|
||||
ネットワーク制限、npm の障害、またはソースリポジトリから作業しているため `npx @opengsd/gsd-core@latest` が失敗する場合は、[docs/manual-update.md](../../manual-update.md) の手動アップデート手順を使用してください。そのドキュメントには、最新コミットの取得、フックの dist のビルド、`node bin/install.js` の直接実行が記載されています。
|
||||
ネットワーク制限、npm の障害、またはソースリポジトリから作業しているため `npx @golem15/msd-core@latest` が失敗する場合は、[docs/manual-update.md](../../manual-update.md) の手動アップデート手順を使用してください。そのドキュメントには、最新コミットの取得、フックの dist のビルド、`node bin/install.js` の直接実行が記載されています。
|
||||
|
||||
---
|
||||
|
||||
## すでに最新バージョンの場合
|
||||
|
||||
`/gsd-update` は確認メッセージとともに早期終了します。ダウンロード、インストール、再起動は不要です。
|
||||
`/msd-update` は確認メッセージとともに早期終了します。ダウンロード、インストール、再起動は不要です。
|
||||
|
||||
---
|
||||
|
||||
## インストーラの移行
|
||||
|
||||
各 GSD リリースには、管理ファイルの名前変更、移動、廃止を行うインストーラ移行が含まれる場合があります。移行レイヤーは新しいパッケージペイロードが書き込まれる前に自動的に実行されます。変更したファイルに影響する移行はサイレントに実行されず、確認が求められます。設計の詳細とランタイム設定コントラクトレジストリについては、[docs/installer-migrations.md](../../installer-migrations.md) を参照してください。
|
||||
各 MSD リリースには、管理ファイルの名前変更、移動、廃止を行うインストーラ移行が含まれる場合があります。移行レイヤーは新しいパッケージペイロードが書き込まれる前に自動的に実行されます。変更したファイルに影響する移行はサイレントに実行されず、確認が求められます。設計の詳細とランタイム設定コントラクトレジストリについては、[docs/installer-migrations.md](../../installer-migrations.md) を参照してください。
|
||||
|
||||
---
|
||||
|
||||
@@ -9,36 +9,36 @@
|
||||
## ユーザー受け入れテストを実行する
|
||||
|
||||
```bash
|
||||
/gsd-verify-work 1
|
||||
/msd-verify-work 1
|
||||
```
|
||||
|
||||
GSD はフェーズの `SUMMARY.md` ファイルを読み込み、ユーザーが観察できる成果物を抽出して、それらを一つずつ確認します。各チェックポイントで、*起こるべきこと*を提示し、実際にそうなっているかを尋ねます。
|
||||
MSD はフェーズの `SUMMARY.md` ファイルを読み込み、ユーザーが観察できる成果物を抽出して、それらを一つずつ確認します。各チェックポイントで、*起こるべきこと*を提示し、実際にそうなっているかを尋ねます。
|
||||
|
||||
- `yes` / `y` / 空白 → 合格、次のテストへ
|
||||
- それ以外 → 問題として記録され、あなたの説明から重要度が推定されます
|
||||
|
||||
重要度を分類する必要はありません — GSD があなたの言葉から推定します（「クラッシュする」→ ブロッカー、「動かない」→ メジャー、「見た目がおかしい」→ コスメティック）。
|
||||
重要度を分類する必要はありません — MSD があなたの言葉から推定します（「クラッシュする」→ ブロッカー、「動かない」→ メジャー、「見た目がおかしい」→ コスメティック）。
|
||||
|
||||
進捗は `.planning/phases/01-<name>/01-UAT.md` に書き込まれ、`/clear` 後も保持されます。セッションが中断された場合は `/gsd-verify-work 1` を再実行すると、最後のチェックポイントから再開するかどうか確認されます。
|
||||
進捗は `.planning/phases/01-<name>/01-UAT.md` に書き込まれ、`/clear` 後も保持されます。セッションが中断された場合は `/msd-verify-work 1` を再実行すると、最後のチェックポイントから再開するかどうか確認されます。
|
||||
|
||||
---
|
||||
|
||||
## 失敗が見つかった場合: 自動診断と修正プランニング
|
||||
|
||||
テストで問題が報告された場合、GSD は自動的に次を実行します:
|
||||
テストで問題が報告された場合、MSD は自動的に次を実行します:
|
||||
|
||||
1. **根本原因を診断** — 問題ごとに並列デバッグエージェントを起動し、`UAT.md` に根本原因を追記します。
|
||||
2. **ギャップ修正をプランニング** — `gsd-planner` をギャップ修正モードで起動し、（診断を含む）`UAT.md` を読み込んで新しい `PLAN.md` ファイルを書き込みます。
|
||||
3. **修正プランを検証** — `gsd-plan-checker` を起動してプランが実行可能かを確認します。問題があれば、プランナーとチェッカーが最大 3 回反復します。
|
||||
2. **ギャップ修正をプランニング** — `msd-planner` をギャップ修正モードで起動し、（診断を含む）`UAT.md` を読み込んで新しい `PLAN.md` ファイルを書き込みます。
|
||||
3. **修正プランを検証** — `msd-plan-checker` を起動してプランが実行可能かを確認します。問題があれば、プランナーとチェッカーが最大 3 回反復します。
|
||||
4. **次のステップを提示** — プランがチェッカーを通過すると:
|
||||
|
||||
```
|
||||
Plans verified and ready for execution.
|
||||
|
||||
`/clear` then `/gsd-execute-phase 1 --gaps-only`
|
||||
`/clear` then `/msd-execute-phase 1 --gaps-only`
|
||||
```
|
||||
|
||||
提示されたコマンドを実行して修正を適用し、`/gsd-verify-work 1` を再実行してすべてが合格することを確認してください。
|
||||
提示されたコマンドを実行して修正を適用し、`/msd-verify-work 1` を再実行してすべてが合格することを確認してください。
|
||||
|
||||
---
|
||||
|
||||
@@ -47,14 +47,14 @@ Plans verified and ready for execution.
|
||||
すべての UAT テストが合格した場合（または最初の実行で問題が見つからなかった場合）、フェーズは `ROADMAP.md` と `STATE.md` で自動的に完了としてマークされます。
|
||||
|
||||
```bash
|
||||
/gsd-ship 1
|
||||
/msd-ship 1
|
||||
```
|
||||
|
||||
GSD はプリフライトチェック（検証状態、クリーンなワーキングツリー、ブランチ、リモート、`gh` CLI 認証）を実行し、ブランチをプッシュして PR を作成します:
|
||||
MSD はプリフライトチェック（検証状態、クリーンなワーキングツリー、ブランチ、リモート、`gh` CLI 認証）を実行し、ブランチをプッシュして PR を作成します:
|
||||
|
||||
```bash
|
||||
/gsd-ship 1 # レビュー準備完了の PR
|
||||
/gsd-ship 1 --draft # ドラフト PR — 後続フェーズが続く場合に便利
|
||||
/msd-ship 1 # レビュー準備完了の PR
|
||||
/msd-ship 1 --draft # ドラフト PR — 後続フェーズが続く場合に便利
|
||||
```
|
||||
|
||||
PR の本文はプランニング成果物から自動的に組み立てられます:
|
||||
@@ -71,19 +71,19 @@ PR の本文はプランニング成果物から自動的に組み立てられ
|
||||
|
||||
## オプション: シッピング前後のコードレビュー
|
||||
|
||||
`/gsd-ship` はコードレビューを自動的に実行しませんが、任意のタイミングで挿入できます:
|
||||
`/msd-ship` はコードレビューを自動的に実行しませんが、任意のタイミングで挿入できます:
|
||||
|
||||
**検証前**（UAT 前に問題を検出）:
|
||||
|
||||
```bash
|
||||
/gsd-code-review 1 # 標準レビュー
|
||||
/gsd-code-review 1 --fix # レビュー後に Critical + Warning の発見事項を自動修正
|
||||
/msd-code-review 1 # 標準レビュー
|
||||
/msd-code-review 1 --fix # レビュー後に Critical + Warning の発見事項を自動修正
|
||||
```
|
||||
|
||||
**PR オープン後**（マージ前に品質をゲート）:
|
||||
|
||||
```bash
|
||||
/gsd-code-review 1 --depth=deep # インポートグラフを含むクロスファイル分析
|
||||
/msd-code-review 1 --depth=deep # インポートグラフを含むクロスファイル分析
|
||||
```
|
||||
|
||||
サイクルの早い段階でのプランレビューに Antigravity、Codex、その他のレビュアーを設定するには [クロス AI レビューの設定](set-up-cross-ai-review.md) を参照してください。
|
||||
@@ -95,11 +95,11 @@ PR の本文はプランニング成果物から自動的に組み立てられ
|
||||
ブランチにレビュアーに見せたくない `.planning/` のコミットが含まれている場合:
|
||||
|
||||
```bash
|
||||
/gsd-pr-branch # main に対してフィルタリング
|
||||
/gsd-pr-branch develop # develop に対してフィルタリング
|
||||
/msd-pr-branch # main に対してフィルタリング
|
||||
/msd-pr-branch develop # develop に対してフィルタリング
|
||||
```
|
||||
|
||||
`/gsd-pr-branch` はコードの変更のみを含む新しいブランチを作成します。プランニング成果物のコミットは除外されます。チームのレビューポリシーでプランニングのノイズを除外する場合は、`/gsd-ship` の前にこれを実行してください。
|
||||
`/msd-pr-branch` はコードの変更のみを含む新しいブランチを作成します。プランニング成果物のコミットは除外されます。チームのレビューポリシーでプランニングのノイズを除外する場合は、`/msd-ship` の前にこれを実行してください。
|
||||
|
||||
---
|
||||
|
||||
@@ -108,11 +108,11 @@ PR の本文はプランニング成果物から自動的に組み立てられ
|
||||
これがマイルストーンの最後のフェーズだった場合は、マイルストーンの監査とアーカイブを実行します:
|
||||
|
||||
```bash
|
||||
/gsd-audit-milestone # すべての要件がシップされたかを確認
|
||||
/gsd-complete-milestone # アーカイブ、git タグの作成
|
||||
/msd-audit-milestone # すべての要件がシップされたかを確認
|
||||
/msd-complete-milestone # アーカイブ、git タグの作成
|
||||
```
|
||||
|
||||
`/gsd-complete-milestone` は PR マージ後の自然な次のステップです。検証とシッピングがプロジェクト全体のライフサイクルにどう組み込まれるかについては [フェーズループ](../explanation/the-phase-loop.md) を参照してください。
|
||||
`/msd-complete-milestone` は PR マージ後の自然な次のステップです。検証とシッピングがプロジェクト全体のライフサイクルにどう組み込まれるかについては [フェーズループ](../explanation/the-phase-loop.md) を参照してください。
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
**目標:** バックエンド API、フロントエンドダッシュボード、インフラなど、異なるマイルストーン領域を並行して作業する際に、各領域の計画状態が互いに干渉しないようにする。
|
||||
|
||||
**前提条件:** GSD Core プロジェクトが有効な状態（`.planning/ROADMAP.md` が存在する）であること。存在しない場合は、まず `/gsd-new-project` を実行してください。
|
||||
**前提条件:** MSD Core プロジェクトが有効な状態（`.planning/ROADMAP.md` が存在する）であること。存在しない場合は、まず `/msd-new-project` を実行してください。
|
||||
|
||||
---
|
||||
|
||||
@@ -28,24 +28,24 @@
|
||||
└── phases/
|
||||
```
|
||||
|
||||
ワークストリームがアクティブな間、すべての GSD コマンド（`/gsd-progress`、`/gsd-discuss-phase`、`/gsd-plan-phase`、`/gsd-execute-phase`）はそのワークストリームのディレクトリを読み書き対象とします。ワークストリームを切り替えると、ソースツリーに触れることなく、これらすべてのコマンドが別のサブツリーを対象とするようになります。
|
||||
ワークストリームがアクティブな間、すべての MSD コマンド（`/msd-progress`、`/msd-discuss-phase`、`/msd-plan-phase`、`/msd-execute-phase`）はそのワークストリームのディレクトリを読み書き対象とします。ワークストリームを切り替えると、ソースツリーに触れることなく、これらすべてのコマンドが別のサブツリーを対象とするようになります。
|
||||
|
||||
---
|
||||
|
||||
## ワークストリームを作成する
|
||||
|
||||
```bash
|
||||
/gsd-workstreams create backend-api
|
||||
/msd-workstreams create backend-api
|
||||
```
|
||||
|
||||
GSD は `.planning/workstreams/backend-api/` 以下にワークストリームディレクトリを作成し、`STATE.md` と `ROADMAP.md` の雛形を生成します。ワークストリームは自動的にアクティブ化されません。明示的に切り替えを行う必要があります。
|
||||
MSD は `.planning/workstreams/backend-api/` 以下にワークストリームディレクトリを作成し、`STATE.md` と `ROADMAP.md` の雛形を生成します。ワークストリームは自動的にアクティブ化されません。明示的に切り替えを行う必要があります。
|
||||
|
||||
---
|
||||
|
||||
## ワークストリームを一覧表示する
|
||||
|
||||
```bash
|
||||
/gsd-workstreams list
|
||||
/msd-workstreams list
|
||||
```
|
||||
|
||||
すべてのワークストリームと、現在のセッションでアクティブなワークストリームを表示します。
|
||||
@@ -55,26 +55,26 @@ GSD は `.planning/workstreams/backend-api/` 以下にワークストリーム
|
||||
## ワークストリームに切り替える
|
||||
|
||||
```bash
|
||||
/gsd-workstreams switch backend-api
|
||||
/msd-workstreams switch backend-api
|
||||
```
|
||||
|
||||
これ以降、すべての GSD ワークフローコマンドは `backend-api` コンテキストで動作します。切り替えはセッションスコープで行われます。同じリポジトリで複数の Claude Code ターミナルが開いている場合、各セッションで異なるアクティブワークストリームを保持でき、互いに干渉しません。
|
||||
これ以降、すべての MSD ワークフローコマンドは `backend-api` コンテキストで動作します。切り替えはセッションスコープで行われます。同じリポジトリで複数の Claude Code ターミナルが開いている場合、各セッションで異なるアクティブワークストリームを保持でき、互いに干渉しません。
|
||||
|
||||
切り替え後は、通常のフェーズワークフローを進めてください。
|
||||
|
||||
```bash
|
||||
/gsd-discuss-phase 1
|
||||
/gsd-plan-phase 1
|
||||
/gsd-execute-phase 1
|
||||
/gsd-verify-work 1
|
||||
/msd-discuss-phase 1
|
||||
/msd-plan-phase 1
|
||||
/msd-execute-phase 1
|
||||
/msd-verify-work 1
|
||||
```
|
||||
|
||||
別の領域を作業する場合は、2 つ目のターミナルでワークストリームを切り替えます。
|
||||
|
||||
```bash
|
||||
/gsd-workstreams switch frontend-dash
|
||||
/gsd-discuss-phase 1
|
||||
/gsd-plan-phase 1
|
||||
/msd-workstreams switch frontend-dash
|
||||
/msd-discuss-phase 1
|
||||
/msd-plan-phase 1
|
||||
```
|
||||
|
||||
---
|
||||
@@ -82,7 +82,7 @@ GSD は `.planning/workstreams/backend-api/` 以下にワークストリーム
|
||||
## すべてのワークストリームの進捗を確認する
|
||||
|
||||
```bash
|
||||
/gsd-workstreams progress
|
||||
/msd-workstreams progress
|
||||
```
|
||||
|
||||
すべてのワークストリームのフェーズ状態、現在位置、残作業をクロスワークストリームでまとめて表示します。切り替えなしで確認できます。
|
||||
@@ -90,7 +90,7 @@ GSD は `.planning/workstreams/backend-api/` 以下にワークストリーム
|
||||
特定のワークストリームの詳細なステータスを確認する場合は：
|
||||
|
||||
```bash
|
||||
/gsd-workstreams status backend-api
|
||||
/msd-workstreams status backend-api
|
||||
```
|
||||
|
||||
---
|
||||
@@ -100,10 +100,10 @@ GSD は `.planning/workstreams/backend-api/` 以下にワークストリーム
|
||||
コンテキストリセットや新しいセッションの後に、作業位置を復元します。
|
||||
|
||||
```bash
|
||||
/gsd-workstreams resume backend-api
|
||||
/msd-workstreams resume backend-api
|
||||
```
|
||||
|
||||
このコマンドはワークストリームをアクティブ化し、最後の既知の位置を復元します。手動で切り替えてから `/gsd-resume-work` を実行するのと同等です。
|
||||
このコマンドはワークストリームをアクティブ化し、最後の既知の位置を復元します。手動で切り替えてから `/msd-resume-work` を実行するのと同等です。
|
||||
|
||||
---
|
||||
|
||||
@@ -112,10 +112,10 @@ GSD は `.planning/workstreams/backend-api/` 以下にワークストリーム
|
||||
ワークストリームのマイルストーン作業が完了したら：
|
||||
|
||||
```bash
|
||||
/gsd-workstreams complete backend-api
|
||||
/msd-workstreams complete backend-api
|
||||
```
|
||||
|
||||
GSD はワークストリームをアーカイブ済みとしてマークし、アクティブ一覧から除外します。計画成果物は監査目的のため `.planning/workstreams/backend-api/` 以下に保持されます。
|
||||
MSD はワークストリームをアーカイブ済みとしてマークし、アクティブ一覧から除外します。計画成果物は監査目的のため `.planning/workstreams/backend-api/` 以下に保持されます。
|
||||
|
||||
---
|
||||
|
||||
@@ -124,8 +124,8 @@ GSD はワークストリームをアーカイブ済みとしてマークし、
|
||||
セッションのアクティブコンテキストを変更せず、特定のワークストリームに対して 1 つのコマンドだけを実行したい場合は、`--ws` フラグを使用します。
|
||||
|
||||
```bash
|
||||
/gsd-progress --ws frontend-dash
|
||||
/gsd-plan-phase 2 --ws backend-api
|
||||
/msd-progress --ws frontend-dash
|
||||
/msd-plan-phase 2 --ws backend-api
|
||||
```
|
||||
|
||||
`--ws` は解決順序で最高優先度を持ち、セッションスコープのポインタは変更しません。
|
||||
@@ -145,7 +145,7 @@ GSD はワークストリームをアーカイブ済みとしてマークし、
|
||||
|
||||
- **複数のリポジトリ**（例：`hr-ui` と `ZeymoAPI`）にまたがって作業している
|
||||
- フィーチャーごとに**独立した git ワークツリー**やクローンが必要（独立したブランチ、ロックファイル、ビルド成果物）
|
||||
- 各ワークスペースで `/gsd-new-project` を独立して実行し、メインリポジトリの `.planning/` のサブディレクトリではなく、完全に独立した `.planning/` ルートを持ちたい
|
||||
- 各ワークスペースで `/msd-new-project` を独立して実行し、メインリポジトリの `.planning/` のサブディレクトリではなく、完全に独立した `.planning/` ルートを持ちたい
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -1,52 +1,52 @@
|
||||
# GSD によるイシュー駆動オーケストレーション
|
||||
# MSD によるイシュー駆動オーケストレーション
|
||||
|
||||
**ステータス：** 安定したワークフローガイド
|
||||
**対象：** GitHub Issues、Linear、Jira、または類似のイシュートラッカーで作業を追跡し、GSD の既存プリミティブを通じて AI 支援実装を推進したい開発者。
|
||||
**対象：** GitHub Issues、Linear、Jira、または類似のイシュートラッカーで作業を追跡し、MSD の既存プリミティブを通じて AI 支援実装を推進したい開発者。
|
||||
|
||||
## このガイドについて
|
||||
|
||||
GSD がすでに提供するコマンドをイシュートラッカー → ワークスペース → 計画/実行 → 検証/レビュー → PR ループに組み合わせるためのレシピです。これはドキュメントのみです。新しいコマンドなし、デーモンなし、トラッカー統合なし——以下で参照するすべてのコマンドは今日の GSD に既に存在します。
|
||||
MSD がすでに提供するコマンドをイシュートラッカー → ワークスペース → 計画/実行 → 検証/レビュー → PR ループに組み合わせるためのレシピです。これはドキュメントのみです。新しいコマンドなし、デーモンなし、トラッカー統合なし——以下で参照するすべてのコマンドは今日の MSD に既に存在します。
|
||||
|
||||
この形は OpenAI のオープンソース [Symphony オーケストレーションリファレンス](https://openai.com/index/open-source-codex-orchestration-symphony/)（[リポジトリ](https://github.com/openai/symphony)）にインスパイアされています。GSD は Symphony をベンダリングまたはラッピングしません。オーケストレーションの *概念* は GSD がすでに公開しているプリミティブにきれいにマッピングされます；このガイドはグルーコードを書いたり GSD の安全ゲートを回避したりせずにパターンを採用できるようにマッピングを説明するだけです。
|
||||
この形は OpenAI のオープンソース [Symphony オーケストレーションリファレンス](https://openai.com/index/open-source-codex-orchestration-symphony/)（[リポジトリ](https://github.com/openai/symphony)）にインスパイアされています。MSD は Symphony をベンダリングまたはラッピングしません。オーケストレーションの *概念* は MSD がすでに公開しているプリミティブにきれいにマッピングされます；このガイドはグルーコードを書いたり MSD の安全ゲートを回避したりせずにパターンを採用できるようにマッピングを説明するだけです。
|
||||
|
||||
## なぜこれが存在するか
|
||||
|
||||
GSD にはイシュー駆動 AI 開発のビルディングブロックがあります——`/gsd-workspace --new`、`/gsd-manager`、`/gsd-autonomous`、`/gsd-verify-work`、`/gsd-review`、`/gsd-ship`、さらに `STATE.md` とフェーズアーティファクトスイート——しかし、カスタムオーケストレーションスクリプトを書かずに単一のトラッカーイシューから端から端まで動かす方法を説明するガイドがありませんでした。そのガイドなしでは失敗モードは：
|
||||
MSD にはイシュー駆動 AI 開発のビルディングブロックがあります——`/msd-workspace --new`、`/msd-manager`、`/msd-autonomous`、`/msd-verify-work`、`/msd-review`、`/msd-ship`、さらに `STATE.md` とフェーズアーティファクトスイート——しかし、カスタムオーケストレーションスクリプトを書かずに単一のトラッカーイシューから端から端まで動かす方法を説明するガイドがありませんでした。そのガイドなしでは失敗モードは：
|
||||
|
||||
- 過少使用：開発者が discuss/plan/execute を手動で実行し、作業パターンが合致しているときでも `/gsd-manager` や `/gsd-autonomous` に手を出さない。
|
||||
- 過少使用：開発者が discuss/plan/execute を手動で実行し、作業パターンが合致しているときでも `/msd-manager` や `/msd-autonomous` に手を出さない。
|
||||
- 回避策スクリプト：開発者がトラッカーと `claude` 呼び出しの間にアドホックなシェルループを配線し、`STATE.md`、フェーズマニフェスト、検証ゲートを迂回する。
|
||||
|
||||
このガイドは正規ループを発見しやすくします。
|
||||
|
||||
## 概念マッピング
|
||||
|
||||
各行は Symphony スタイルのオーケストレーション概念を、それをすでに提供する GSD プリミティブにマッピングします。Symphony のドキュメント、ブログ投稿、サードパーティのオーケストレーション記事を読む際の変換キーとしてこのテーブルを使ってください。
|
||||
各行は Symphony スタイルのオーケストレーション概念を、それをすでに提供する MSD プリミティブにマッピングします。Symphony のドキュメント、ブログ投稿、サードパーティのオーケストレーション記事を読む際の変換キーとしてこのテーブルを使ってください。
|
||||
|
||||
| Symphony の概念 | GSD プリミティブ |
|
||||
| Symphony の概念 | MSD プリミティブ |
|
||||
|---|---|
|
||||
| `WORKFLOW.md`（トップレベルの意図） | `ROADMAP.md`（プロジェクトの意図）、`STATE.md`（ライブステータス）、フェーズ `CONTEXT.md`（フェーズごとのスコープ）、フェーズ `PLAN.md`（実行可能なステップ） |
|
||||
| タスクごとの分離されたエージェントワークスペース | `/gsd-workspace --new --strategy worktree` |
|
||||
| エージェントのディスパッチと並列性 | `/gsd-manager`（インタラクティブダッシュボード）、`/gsd-autonomous`（非同期） |
|
||||
| フェーズごとの計画と議論ステップ | `/gsd-discuss-phase` → `/gsd-plan-phase` → `/gsd-execute-phase` |
|
||||
| 作業の証明 / テスト証拠 | `/gsd-verify-work`（`/clear` をまたいで永続する UAT.md） |
|
||||
| 対立的レビュー | `/gsd-review`（計画のクロス AI ピアレビュー） |
|
||||
| ヒューマンマージゲート | `/gsd-ship`（PR を作成し、オプションのコードレビュー、マージ準備） |
|
||||
| フォローアップキャプチャ | `/gsd-capture`、`/gsd-capture --seed`、`/gsd-new-milestone`、または手動で開いたトラッカーイシュー |
|
||||
| タスクごとの分離されたエージェントワークスペース | `/msd-workspace --new --strategy worktree` |
|
||||
| エージェントのディスパッチと並列性 | `/msd-manager`（インタラクティブダッシュボード）、`/msd-autonomous`（非同期） |
|
||||
| フェーズごとの計画と議論ステップ | `/msd-discuss-phase` → `/msd-plan-phase` → `/msd-execute-phase` |
|
||||
| 作業の証明 / テスト証拠 | `/msd-verify-work`（`/clear` をまたいで永続する UAT.md） |
|
||||
| 対立的レビュー | `/msd-review`（計画のクロス AI ピアレビュー） |
|
||||
| ヒューマンマージゲート | `/msd-ship`（PR を作成し、オプションのコードレビュー、マージ準備） |
|
||||
| フォローアップキャプチャ | `/msd-capture`、`/msd-capture --seed`、`/msd-new-milestone`、または手動で開いたトラッカーイシュー |
|
||||
| 並列性制御 | マネージャー / バックグラウンドエージェントのセマンティクス（常時オンのポーラーなし） |
|
||||
|
||||
このマッピングは一方向です：GSD が安全ゲート（検証、ヒューマンレビュー、フォローアップ作成の明示的確認）を所有します。Symphony の「継続的オーケストレーション」フレーミングは意図的に採用していません——[非目標](#non-goals) を参照してください。
|
||||
このマッピングは一方向です：MSD が安全ゲート（検証、ヒューマンレビュー、フォローアップ作成の明示的確認）を所有します。Symphony の「継続的オーケストレーション」フレーミングは意図的に採用していません——[非目標](#non-goals) を参照してください。
|
||||
|
||||
## エンドツーエンドフロー
|
||||
|
||||
単一のトラッカーイシューから端から端まで実行できるように書かれた、正規のイシュー → PR ループ。実行前に括弧内のプレースホルダーを置き換えてください。
|
||||
|
||||
1. **トラッカーイシューを選ぶ。** トラッカー（GitHub、Linear など）から、自律的な実装に十分な範囲があるイシューを一つ選びます——境界が明確なスコープ、観察可能な受け入れ基準、実行をブロックする上流の依存関係なし。
|
||||
2. **GSD フェーズにマッピングする。** イシューが `ROADMAP.md` の既存フェーズにマッピングされる場合はそれを選択します。そうでない場合は、関連イシューの新しいマイルストーンのために `/gsd-new-milestone` を実行するか、`/gsd-phase` / `/gsd-phase --insert` でフェーズを開きます。フェーズの `CONTEXT.md` にトラッカーイシューの URL を記録し、圧縮後もトレーサビリティが維持されるようにします。
|
||||
3. **分離されたワークスペースを作成する。** `/gsd-workspace --new --strategy worktree <slug>` を実行して、独立した `.planning/` ディレクトリを持つ git ワークツリーを立ち上げます。ワークツリーは安全境界です：探索、部分的なコミット、中断された計画はすべて `main` の外に留まります。
|
||||
4. **GSD を通じて discuss → plan → execute を実行する。** ワークスペース内から、`/gsd-discuss-phase` で曖昧さを明確にし、`/gsd-plan-phase` で `PLAN.md` を生成し、`/gsd-manager`（インタラクティブダッシュボード）または `/gsd-execute-phase` / `/gsd-autonomous`（非同期）で実装します。GSD の外から生の `claude` 呼び出しを直接動かすことは避けてください——それは `STATE.md` の更新とフェーズマニフェストを迂回します。
|
||||
5. **作業の証明を要求する。** `/gsd-verify-work` を実行して、フェーズの受け入れ基準に対して UAT をユーザーに案内します。テスト、スクリーンショット、ログキャプチャ、設定差分はすべて `UAT.md` に記録され、`/clear` をまたいで永続し、検証でミスしたスコープが発見されたときに `/gsd-plan-phase --gaps` にフィードされます。
|
||||
6. **レビューと出荷ゲートを通過する。** `/gsd-review` を実行して独立した AI CLI からの対立的ピアレビューを受け（モデルごとのブラインドスポットをキャッチ）、次に `/gsd-ship` で計画アーティファクトから組み立てたリッチなボディ付きで PR を開きます。どちらのゲートもリモートに何かが届く前に人間の決定を必要とします。
|
||||
7. **フォローアップ作業を明示的にキャプチャする。** インラインメモには `/gsd-capture` を、将来のフェーズの価値があるアイデアには `/gsd-capture --seed` を、一貫したフォローアップグループには `/gsd-new-milestone` を使います。発見されたフォローアップからトラッカーイシューを作成するには、明示的なユーザー確認が必要です——GSD はリモートトラッカーに自動投稿しません。
|
||||
2. **MSD フェーズにマッピングする。** イシューが `ROADMAP.md` の既存フェーズにマッピングされる場合はそれを選択します。そうでない場合は、関連イシューの新しいマイルストーンのために `/msd-new-milestone` を実行するか、`/msd-phase` / `/msd-phase --insert` でフェーズを開きます。フェーズの `CONTEXT.md` にトラッカーイシューの URL を記録し、圧縮後もトレーサビリティが維持されるようにします。
|
||||
3. **分離されたワークスペースを作成する。** `/msd-workspace --new --strategy worktree <slug>` を実行して、独立した `.planning/` ディレクトリを持つ git ワークツリーを立ち上げます。ワークツリーは安全境界です：探索、部分的なコミット、中断された計画はすべて `main` の外に留まります。
|
||||
4. **MSD を通じて discuss → plan → execute を実行する。** ワークスペース内から、`/msd-discuss-phase` で曖昧さを明確にし、`/msd-plan-phase` で `PLAN.md` を生成し、`/msd-manager`（インタラクティブダッシュボード）または `/msd-execute-phase` / `/msd-autonomous`（非同期）で実装します。MSD の外から生の `claude` 呼び出しを直接動かすことは避けてください——それは `STATE.md` の更新とフェーズマニフェストを迂回します。
|
||||
5. **作業の証明を要求する。** `/msd-verify-work` を実行して、フェーズの受け入れ基準に対して UAT をユーザーに案内します。テスト、スクリーンショット、ログキャプチャ、設定差分はすべて `UAT.md` に記録され、`/clear` をまたいで永続し、検証でミスしたスコープが発見されたときに `/msd-plan-phase --gaps` にフィードされます。
|
||||
6. **レビューと出荷ゲートを通過する。** `/msd-review` を実行して独立した AI CLI からの対立的ピアレビューを受け（モデルごとのブラインドスポットをキャッチ）、次に `/msd-ship` で計画アーティファクトから組み立てたリッチなボディ付きで PR を開きます。どちらのゲートもリモートに何かが届く前に人間の決定を必要とします。
|
||||
7. **フォローアップ作業を明示的にキャプチャする。** インラインメモには `/msd-capture` を、将来のフェーズの価値があるアイデアには `/msd-capture --seed` を、一貫したフォローアップグループには `/msd-new-milestone` を使います。発見されたフォローアップからトラッカーイシューを作成するには、明示的なユーザー確認が必要です——MSD はリモートトラッカーに自動投稿しません。
|
||||
|
||||
PR がマージされると、ループが閉じます。PR ボディのオートクローズキーワード（`Closes #NNN` / `Fixes #NNN`）がマージ時にトラッカーイシューを閉じます。
|
||||
|
||||
@@ -54,30 +54,30 @@ PR がマージされると、ループが閉じます。PR ボディのオー
|
||||
|
||||
このループが安全なのは、4 つの不変条件が設計上成立するからです：
|
||||
|
||||
- **分離されたワークツリー。** すべてのイシューが `/gsd-workspace --new` ワークツリーで実行されるため、部分的な作業、中断された計画、探索的なコミットは `main` に触れません。`gsd-local-patches/` は、ワークツリーの手動編集をアップデートをまたいで持ち戻す必要がある場合の回復面です。
|
||||
- **明示的な人間によるレビュー。** `/gsd-review` と `/gsd-ship` はどちらも人間の承認で停止します。オートマージはなく、実行からの自動 PR パスもありません。特定のリポジトリで人間ゲートを削除したい場合は、それはブランチ保護 / マージキューポリシーの決定であり、GSD があなたに代わってオプトインするものではありません。
|
||||
- **自動公開投稿なし。** GSD は明示的なユーザー起動コマンドなしにトラッカーイシューを開いたり、コメントしたり、閉じたりしません。フォローアップキャプチャはデフォルトでローカルアーティファクト（メモ、シード、マイルストーン）になります；トラッカーに押し戻すことは別の手動ステップです。
|
||||
- **出荷前の検証。** `/gsd-verify-work` の UAT.md は `/gsd-ship` が実行される前に証拠を記録しなければなりません。推奨される規律は、実装が正しく見えるときでも `verification_failed` をブロッカーとして扱うことです——失敗は通常フラキーなテストではなく、ミスした受け入れ基準を表面化します。
|
||||
- **分離されたワークツリー。** すべてのイシューが `/msd-workspace --new` ワークツリーで実行されるため、部分的な作業、中断された計画、探索的なコミットは `main` に触れません。`msd-local-patches/` は、ワークツリーの手動編集をアップデートをまたいで持ち戻す必要がある場合の回復面です。
|
||||
- **明示的な人間によるレビュー。** `/msd-review` と `/msd-ship` はどちらも人間の承認で停止します。オートマージはなく、実行からの自動 PR パスもありません。特定のリポジトリで人間ゲートを削除したい場合は、それはブランチ保護 / マージキューポリシーの決定であり、MSD があなたに代わってオプトインするものではありません。
|
||||
- **自動公開投稿なし。** MSD は明示的なユーザー起動コマンドなしにトラッカーイシューを開いたり、コメントしたり、閉じたりしません。フォローアップキャプチャはデフォルトでローカルアーティファクト（メモ、シード、マイルストーン）になります；トラッカーに押し戻すことは別の手動ステップです。
|
||||
- **出荷前の検証。** `/msd-verify-work` の UAT.md は `/msd-ship` が実行される前に証拠を記録しなければなりません。推奨される規律は、実装が正しく見えるときでも `verification_failed` をブロッカーとして扱うことです——失敗は通常フラキーなテストではなく、ミスした受け入れ基準を表面化します。
|
||||
|
||||
これらの不変条件のいずれかが迂回された場合（例：ワークツリーに直接 `claude` を実行する、`/gsd-verify-work` をスキップする、またはユーザー確認なしにトラッカー API を通じてイシュー作成をスクリプト化する）、このガイドの保証は適用されません。
|
||||
これらの不変条件のいずれかが迂回された場合（例：ワークツリーに直接 `claude` を実行する、`/msd-verify-work` をスキップする、またはユーザー確認なしにトラッカー API を通じてイシュー作成をスクリプト化する）、このガイドの保証は適用されません。
|
||||
|
||||
## 非目標 {#non-goals}
|
||||
|
||||
このガイドは意図的に以下のいずれも提案しません。将来のコントリビューターがコードレビューで再論争しないように、ここにリストされています：
|
||||
|
||||
- **Symphony コードのベンダリングまたはコピーなし。** GSD は独自のプリミティブを再利用します。上記のマッピングは概念的です；Symphony 由来のソースはこのリポジトリに同梱されません。
|
||||
- **常時実行デーモンなし。** GSD は GitHub や Linear をポーリングしません。マネージャーと自律ワークフローは、デーモンではなくバックグラウンドエージェントのセマンティクスを通じて並列性を処理します。
|
||||
- **必須のトラッカー依存関係なし。** このループはトラッカー統合なしで機能します。「トラッカーイシュー」ステップは *人間の入力* です——URL は `CONTEXT.md` に入ります。GSD はあなたが使用するトラッカーについても、トラッカーを使用するかどうかについても意見を持ちません。
|
||||
- **検証、レビュー、または人間の決定ゲートの迂回なし。** `/gsd-autonomous` を実行する場合でも、検証とレビューゲートは依然として発火します。「自律的」ラベルはフェーズからフェーズへの進行を指し、人間の承認をスキップすることではありません。
|
||||
- **Symphony コードのベンダリングまたはコピーなし。** MSD は独自のプリミティブを再利用します。上記のマッピングは概念的です；Symphony 由来のソースはこのリポジトリに同梱されません。
|
||||
- **常時実行デーモンなし。** MSD は GitHub や Linear をポーリングしません。マネージャーと自律ワークフローは、デーモンではなくバックグラウンドエージェントのセマンティクスを通じて並列性を処理します。
|
||||
- **必須のトラッカー依存関係なし。** このループはトラッカー統合なしで機能します。「トラッカーイシュー」ステップは *人間の入力* です——URL は `CONTEXT.md` に入ります。MSD はあなたが使用するトラッカーについても、トラッカーを使用するかどうかについても意見を持ちません。
|
||||
- **検証、レビュー、または人間の決定ゲートの迂回なし。** `/msd-autonomous` を実行する場合でも、検証とレビューゲートは依然として発火します。「自律的」ラベルはフェーズからフェーズへの進行を指し、人間の承認をスキップすることではありません。
|
||||
- **デフォルトのスキル / コマンド面の拡張なし。** このガイドで参照するすべてのコマンドはすでに存在します。このガイドはドキュメント面であり、機能面ではありません。
|
||||
|
||||
## 将来のフォローアップの可能性
|
||||
|
||||
このループでのメンテナーの経験がそれを正当化するなら、別の承認済み拡張として後で *最小限の* トラッカーブリッジを追加できます：
|
||||
|
||||
- 一つの GitHub または Linear イシューを GSD ワークスペース / フェーズにインポートする。
|
||||
- 一つの GitHub または Linear イシューを MSD ワークスペース / フェーズにインポートする。
|
||||
- `UAT.md` 証拠をソースイシューのコメントとしてエクスポートする。
|
||||
- `/gsd-capture --seed` の出力からフォローアップトラッカーイシューを生成する。
|
||||
- `/msd-capture --seed` の出力からフォローアップトラッカーイシューを生成する。
|
||||
|
||||
これらはそれぞれ統合面と継続的なメンテナンス負担を追加するため、それぞれ独自の拡張提案になります。このガイドのスコープ外です。
|
||||
|
||||
@@ -85,8 +85,8 @@ PR がマージされると、ループが閉じます。PR ボディのオー
|
||||
|
||||
- [フェーズループ](explanation/the-phase-loop.md) — discuss → plan → execute → verify → ship が繰り返すサイクルとしてどう組み合わさるか。
|
||||
- [ワークスペース how-to](how-to/work-in-parallel-with-workstreams.md) — 並列ワークツリーの作成と管理のステップバイステップガイド。
|
||||
- [ドキュメント索引](README.md) — GSD Core ドキュメントの完全な目次。
|
||||
- [ドキュメント索引](README.md) — MSD Core ドキュメントの完全な目次。
|
||||
- [docs/USER-GUIDE.md](./USER-GUIDE.md) — 上で参照した個々のコマンドのタスク指向のウォークスルー。
|
||||
- [docs/COMMANDS.md](COMMANDS.md) — `/gsd-*` コマンドの完全なリファレンス。
|
||||
- [docs/COMMANDS.md](COMMANDS.md) — `/msd-*` コマンドの完全なリファレンス。
|
||||
- [docs/FEATURES.md](FEATURES.md) — 機能レベルの能力マトリクス（ワークスペース、マネージャー、自律、検証、レビュー、出荷）。
|
||||
- [docs/ARCHITECTURE.md](ARCHITECTURE.md) — フェーズアーティファクトのライフサイクルと `STATE.md` の仕組み。
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# CONTEXT.md スキーマリファレンス
|
||||
|
||||
フェーズごとの `CONTEXT.md` は、`/gsd-discuss-phase` 中に収集された実装上の意思決定を格納する GSD Core のキャリアファイルです。リサーチエージェントとプランニングエージェントの両方にとって主要な上流インプットです。このページではそのスキーマを説明します。[ドキュメントインデックス](../../README.md) も参照してください。
|
||||
フェーズごとの `CONTEXT.md` は、`/msd-discuss-phase` 中に収集された実装上の意思決定を格納する MSD Core のキャリアファイルです。リサーチエージェントとプランニングエージェントの両方にとって主要な上流インプットです。このページではそのスキーマを説明します。[ドキュメントインデックス](../../README.md) も参照してください。
|
||||
|
||||
---
|
||||
|
||||
@@ -14,7 +14,7 @@
|
||||
|
||||
例: `.planning/phases/03-post-feed/03-CONTEXT.md`
|
||||
|
||||
このファイルは `gsd-core/workflows/discuss-phase.md` の `write_context`（または PRD / ADR インジェストのエクスプレスパス）によって生成されます。通常の運用中は手動で編集されません — discuss-phase ワークフローが書き込み、下流エージェントが封印された信頼できる情報源として読み取ります。
|
||||
このファイルは `msd-core/workflows/discuss-phase.md` の `write_context`（または PRD / ADR インジェストのエクスプレスパス）によって生成されます。通常の運用中は手動で編集されません — discuss-phase ワークフローが書き込み、下流エージェントが封印された信頼できる情報源として読み取ります。
|
||||
|
||||
---
|
||||
|
||||
@@ -39,12 +39,12 @@
|
||||
|
||||
| ブロック | 用途 | 設定元 | 参照先 |
|
||||
|---|---|---|---|
|
||||
| `<domain>` | フェーズの境界を示します — このフェーズが何を提供し、何が明示的にスコープ外かを述べます。プランニングと実行を通じてスコープガードレールを固定します。 | `discuss-phase`（ROADMAP.md のフェーズゴールから） | `gsd-planner`、`gsd-plan-checker`（スコープ準拠） |
|
||||
| `<spec_lock>` | `check_spec` ステップが `*-SPEC.md` を発見した場合のみ存在します。ロックされた要件数とスコープ境界をリストします。エージェントは完全な要件を得るために直接 `SPEC.md` を読むよう指示されます。 | `discuss-phase`（条件付き） | `gsd-planner`（要件をここで再読みせず SPEC.md を読む） |
|
||||
| `<decisions>` | ディスカッションから収集された実装上の意思決定。`D-NN` 識別子でキー付け。カテゴリは固定の分類ではなく実際に議論された内容から生まれます。ユーザーが委任した領域のための `Claude's Discretion` サブセクションを含みます。 | `discuss-phase`（インタラクティブなディスカッション） | `gsd-planner`（ロックされた決定は必ず実装する）、`gsd-plan-checker`（ディメンション7準拠） |
|
||||
| `<canonical_refs>` | このフェーズに関連するすべての仕様、ADR、機能ドキュメント、設計ドキュメントへの完全な相対パス。必須 — すべての CONTEXT.md にこのセクションが必要です。エージェントはプランニングまたは実装の前にリストされたファイルを読む必要があります。 | `discuss-phase`（ROADMAP.md の参照 + ディスカッション中のユーザー参照 + コードベーススカウトから集積） | `gsd-phase-researcher`、`gsd-planner` |
|
||||
| `<code_context>` | `scout_codebase` ステップで発見された再利用可能なアセット、確立されたパターン、統合ポイント。エージェントを再実装ではなく既存コードに向けるためのガイダンス。 | `discuss-phase`（コードベーススカウト） | `gsd-planner`、`gsd-phase-researcher` |
|
||||
| `<specifics>` | ディスカッション中に verbatim で収集された「こんな感じにしたい」という具体的な参照、製品比較、特定の例。 | `discuss-phase`（自由形式のユーザー入力） | `gsd-planner` |
|
||||
| `<domain>` | フェーズの境界を示します — このフェーズが何を提供し、何が明示的にスコープ外かを述べます。プランニングと実行を通じてスコープガードレールを固定します。 | `discuss-phase`（ROADMAP.md のフェーズゴールから） | `msd-planner`、`msd-plan-checker`（スコープ準拠） |
|
||||
| `<spec_lock>` | `check_spec` ステップが `*-SPEC.md` を発見した場合のみ存在します。ロックされた要件数とスコープ境界をリストします。エージェントは完全な要件を得るために直接 `SPEC.md` を読むよう指示されます。 | `discuss-phase`（条件付き） | `msd-planner`（要件をここで再読みせず SPEC.md を読む） |
|
||||
| `<decisions>` | ディスカッションから収集された実装上の意思決定。`D-NN` 識別子でキー付け。カテゴリは固定の分類ではなく実際に議論された内容から生まれます。ユーザーが委任した領域のための `Claude's Discretion` サブセクションを含みます。 | `discuss-phase`（インタラクティブなディスカッション） | `msd-planner`（ロックされた決定は必ず実装する）、`msd-plan-checker`（ディメンション7準拠） |
|
||||
| `<canonical_refs>` | このフェーズに関連するすべての仕様、ADR、機能ドキュメント、設計ドキュメントへの完全な相対パス。必須 — すべての CONTEXT.md にこのセクションが必要です。エージェントはプランニングまたは実装の前にリストされたファイルを読む必要があります。 | `discuss-phase`（ROADMAP.md の参照 + ディスカッション中のユーザー参照 + コードベーススカウトから集積） | `msd-phase-researcher`、`msd-planner` |
|
||||
| `<code_context>` | `scout_codebase` ステップで発見された再利用可能なアセット、確立されたパターン、統合ポイント。エージェントを再実装ではなく既存コードに向けるためのガイダンス。 | `discuss-phase`（コードベーススカウト） | `msd-planner`、`msd-phase-researcher` |
|
||||
| `<specifics>` | ディスカッション中に verbatim で収集された「こんな感じにしたい」という具体的な参照、製品比較、特定の例。 | `discuss-phase`（自由形式のユーザー入力） | `msd-planner` |
|
||||
| `<deferred>` | ディスカッション中に浮上したが別のフェーズに属するアイデア。失われないよう保存されます。Todos がレビューされたがスコープに含まれなかった場合は `Reviewed Todos` サブセクションを含みます。 | `discuss-phase`（スコープクリープのリダイレクト） | 自動化されたエージェントには使用されない; 人間の参照のみ |
|
||||
|
||||
---
|
||||
@@ -107,7 +107,7 @@ No external specs — requirements fully captured in decisions above
|
||||
|
||||
## SPEC.md との統合
|
||||
|
||||
フェーズをディスカッションする前に `/gsd-spec-phase` が実行された場合、`check_spec` ステップが `*-SPEC.md` ファイルを見つけ `<spec_lock>` を有効にします：
|
||||
フェーズをディスカッションする前に `/msd-spec-phase` が実行された場合、`check_spec` ステップが `*-SPEC.md` ファイルを見つけ `<spec_lock>` を有効にします：
|
||||
|
||||
```markdown
|
||||
<spec_lock>
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# PLAN.md スキーマリファレンス
|
||||
|
||||
フェーズごとの `PLAN.md` は GSD Core の実行可能な作業単位です — エグゼキューターエージェントに何を構築し、正しく構築されたことをどのように検証するかを正確に伝える構造化ドキュメントです。このページではそのスキーマを説明します。[ドキュメントインデックス](../../README.md) も参照してください。
|
||||
フェーズごとの `PLAN.md` は MSD Core の実行可能な作業単位です — エグゼキューターエージェントに何を構築し、正しく構築されたことをどのように検証するかを正確に伝える構造化ドキュメントです。このページではそのスキーマを説明します。[ドキュメントインデックス](../../README.md) も参照してください。
|
||||
|
||||
---
|
||||
|
||||
@@ -14,7 +14,7 @@
|
||||
|
||||
例: `.planning/phases/03-post-feed/03-02-PLAN.md`（フェーズ3、プラン2）。
|
||||
|
||||
プランは `gsd-planner` エージェント（`/gsd-plan-phase` によって起動）が生成し、`execute-phase` が使用します。通常、フェーズには1〜4つのプランが含まれます。フェーズ内のプランは実行ウェーブに割り当てられ、独立した作業が並行して実行されます。
|
||||
プランは `msd-planner` エージェント（`/msd-plan-phase` によって起動）が生成し、`execute-phase` が使用します。通常、フェーズには1〜4つのプランが含まれます。フェーズ内のプランは実行ウェーブに割り当てられ、独立した作業が並行して実行されます。
|
||||
|
||||
---
|
||||
|
||||
@@ -66,7 +66,7 @@ must_haves:
|
||||
| `phase` | はい | string | フェーズ識別子。例: `03-post-feed`。 |
|
||||
| `plan` | はい | string | フェーズ内のプラン番号。例: `02`。 |
|
||||
| `type` | はい | `execute` または `tdd` | 標準プランは `execute`; テスト駆動プラン（実装前にテストを書く）は `tdd`。 |
|
||||
| `wave` | はい | integer | 実行ウェーブ。ウェーブ1のプランは並行実行されます（依存なし）。ウェーブ2以降のプランは前のウェーブのすべてのプランが完了するまで待機します。`gsd-planner` がプランニング時に事前計算します。 |
|
||||
| `wave` | はい | integer | 実行ウェーブ。ウェーブ1のプランは並行実行されます（依存なし）。ウェーブ2以降のプランは前のウェーブのすべてのプランが完了するまで待機します。`msd-planner` がプランニング時に事前計算します。 |
|
||||
| `depends_on` | はい | プラン ID の配列 | このプランが待機する必要があるプランの一覧。空配列 = ウェーブ1。例: `["03-01"]` はこのプランがフェーズ3のプラン01の後に実行されることを意味します。 |
|
||||
| `files_modified` | はい | パスの配列 | このプランが作成または変更するすべてのファイル。プランチェッカーが同一ウェーブのファイル競合を検出するため、および execute-phase がマージ追跡のために使用します。 |
|
||||
| `autonomous` | はい | boolean | すべてのタスクが `auto` タイプの場合に `true`。プランに人間の操作が必要な `checkpoint:*` タスクが含まれる場合は `false`。 |
|
||||
@@ -78,7 +78,7 @@ must_haves:
|
||||
|
||||
## `must_haves` フィールド
|
||||
|
||||
`must_haves` はフェーズゴールを達成するために観察可能に真でなければならないことを記録します。プランニング中に導出され、実行後に `gsd-verifier` エージェントによって検証されます。
|
||||
`must_haves` はフェーズゴールを達成するために観察可能に真でなければならないことを記録します。プランニング中に導出され、実行後に `msd-verifier` エージェントによって検証されます。
|
||||
|
||||
### サブフィールド
|
||||
|
||||
@@ -122,8 +122,8 @@ Output: PostFeed and PostCard components wired to /api/feed.
|
||||
|
||||
```xml
|
||||
<execution_context>
|
||||
@~/.claude/gsd-core/workflows/execute-plan.md
|
||||
@~/.claude/gsd-core/templates/summary.md
|
||||
@~/.claude/msd-core/workflows/execute-plan.md
|
||||
@~/.claude/msd-core/templates/summary.md
|
||||
</execution_context>
|
||||
```
|
||||
|
||||
@@ -194,7 +194,7 @@ Output: PostFeed and PostCard components wired to /api/feed.
|
||||
|
||||
## プラン品質ディメンション
|
||||
|
||||
`gsd-plan-checker` エージェントは実行開始前に12のディメンションにわたってすべての PLAN.md をレビューします。BLOCKER 深刻度のチェックに失敗したプランは `gsd-planner` に差し戻されます（最大3回のイテレーション）：
|
||||
`msd-plan-checker` エージェントは実行開始前に12のディメンションにわたってすべての PLAN.md をレビューします。BLOCKER 深刻度のチェックに失敗したプランは `msd-planner` に差し戻されます（最大3回のイテレーション）：
|
||||
|
||||
| ディメンション | チェック内容 |
|
||||
|---|---|
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# プランニングアーティファクト リファレンス
|
||||
|
||||
`.planning/` ディレクトリはプロジェクトの GSD Core 共有メモリです。すべてのワークフローはここから読み取り、書き込み、意思決定の監査可能な証跡を残します。このページではすべてのファイル、その目的、どのコマンドが生成・使用するかをマッピングします。[ドキュメントインデックス](../../README.md) も参照してください。
|
||||
`.planning/` ディレクトリはプロジェクトの MSD Core 共有メモリです。すべてのワークフローはここから読み取り、書き込み、意思決定の監査可能な証跡を残します。このページではすべてのファイル、その目的、どのコマンドが生成・使用するかをマッピングします。[ドキュメントインデックス](../../README.md) も参照してください。
|
||||
|
||||
---
|
||||
|
||||
@@ -50,32 +50,32 @@
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | プロジェクトの正規アイデンティティ: 概要、対象ユーザー、コアバリュー、要件、制約、主要な意思決定。プロダクトの進化に伴いプロジェクトライフサイクル全体を通じて更新されます。 |
|
||||
| **生成元** | `/gsd-new-project`（初回作成、`/gsd-onboard` のハンドオフを含む）; 意思決定が検証されると `/gsd-complete-milestone` によって更新されます。 |
|
||||
| **参照先** | すべてのプランニングワークフロー; `gsd-phase-researcher`、`gsd-planner`（コンテキスト）; `discuss-phase`（過去の意思決定）; `gsd-plan-checker`（プロジェクト制約）。 |
|
||||
| **生成元** | `/msd-new-project`（初回作成、`/msd-onboard` のハンドオフを含む）; 意思決定が検証されると `/msd-complete-milestone` によって更新されます。 |
|
||||
| **参照先** | すべてのプランニングワークフロー; `msd-phase-researcher`、`msd-planner`（コンテキスト）; `discuss-phase`（過去の意思決定）; `msd-plan-checker`（プロジェクト制約）。 |
|
||||
|
||||
### `ROADMAP.md`
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | マイルストーンおよびフェーズ一覧。ゴール、要件 ID、成功基準、フェーズごとの正規リファレンスを含みます。プロジェクトが何をどの順序で構築するかに関する唯一の信頼できる情報源です。 |
|
||||
| **生成元** | `/gsd-new-project`（初回作成、`/gsd-onboard` のハンドオフを含む）; `/gsd-phase --insert` および `/gsd-complete-milestone` によって更新されます。 |
|
||||
| **参照先** | `/gsd-discuss-phase`、`/gsd-plan-phase`、`/gsd-execute-phase`; フェーズ情報を必要とするすべてのオーケストレーションコマンド; `gsd-planner`、`gsd-plan-checker`、`gsd-phase-researcher`。 |
|
||||
| **生成元** | `/msd-new-project`（初回作成、`/msd-onboard` のハンドオフを含む）; `/msd-phase --insert` および `/msd-complete-milestone` によって更新されます。 |
|
||||
| **参照先** | `/msd-discuss-phase`、`/msd-plan-phase`、`/msd-execute-phase`; フェーズ情報を必要とするすべてのオーケストレーションコマンド; `msd-planner`、`msd-plan-checker`、`msd-phase-researcher`。 |
|
||||
|
||||
### `REQUIREMENTS.md`
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | 番号付きのチェック可能な受け入れ基準。各要件はロードマップフェーズにマッピングされる ID（例: `AUTH-01`）を持ちます。フェーズが実行されると要件を完了済みとしてマークします。 |
|
||||
| **生成元** | `/gsd-new-project`（初回作成、`/gsd-onboard` のハンドオフを含む）; `execute-phase` によって要件が完了済みとしてマークされます。 |
|
||||
| **参照先** | `gsd-planner`（プランはすべてのフェーズ要件 ID に対処しなければならない）; `gsd-plan-checker` ディメンション1（要件カバレッジ）; `discuss-phase`（過去の要件）。 |
|
||||
| **生成元** | `/msd-new-project`（初回作成、`/msd-onboard` のハンドオフを含む）; `execute-phase` によって要件が完了済みとしてマークされます。 |
|
||||
| **参照先** | `msd-planner`（プランはすべてのフェーズ要件 ID に対処しなければならない）; `msd-plan-checker` ディメンション1（要件カバレッジ）; `discuss-phase`（過去の要件）。 |
|
||||
|
||||
### `STATE.md`
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | 現在地を追跡するリビングドキュメント — 現在のフェーズとプラン、進捗指標、蓄積された意思決定、セッション継続性ノート。すべてのワークフロー実行の開始時に読み込まれます。重要なアクションのたびに更新されます。 |
|
||||
| **生成元** | `/gsd-new-project`（初回作成、`/gsd-onboard` のハンドオフを含む）; すべてのフェーズワークフロー、`/gsd-pause-work`、`/gsd-resume-work` によって継続的に更新されます。 |
|
||||
| **参照先** | すべてのオーケストレーションワークフロー; `/gsd-progress`; `/gsd-quick` 経由のアドホックタスク実行; `gsd-planner` および `gsd-phase-researcher`（プロジェクトの意思決定）。 |
|
||||
| **生成元** | `/msd-new-project`（初回作成、`/msd-onboard` のハンドオフを含む）; すべてのフェーズワークフロー、`/msd-pause-work`、`/msd-resume-work` によって継続的に更新されます。 |
|
||||
| **参照先** | すべてのオーケストレーションワークフロー; `/msd-progress`; `/msd-quick` 経由のアドホックタスク実行; `msd-planner` および `msd-phase-researcher`（プロジェクトの意思決定）。 |
|
||||
|
||||
完全なフィールドリファレンスは [STATE.md スキーマ](state-md.md) を参照してください。
|
||||
|
||||
@@ -84,8 +84,8 @@
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | ワークフロー設定: モデルプロファイル、リサーチおよびプランチェッカーのトグル、Git ブランチング戦略、Nyquist バリデーション、並列化設定、エージェントごとのモデルオーバーライド。 |
|
||||
| **生成元** | `/gsd-new-project`（初回作成）; `/gsd-settings`（インタラクティブ編集）。 |
|
||||
| **参照先** | すべてのワークフローとサブエージェント — `gsd-tools query config-get` 経由で初期化時に読み込まれます。 |
|
||||
| **生成元** | `/msd-new-project`（初回作成）; `/msd-settings`（インタラクティブ編集）。 |
|
||||
| **参照先** | すべてのワークフローとサブエージェント — `msd-tools query config-get` 経由で初期化時に読み込まれます。 |
|
||||
|
||||
完全なスキーマは [CONFIGURATION](../../CONFIGURATION.md) を参照してください。
|
||||
|
||||
@@ -93,17 +93,17 @@
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | ブラウンフィールドオンボーディングの索引。アーティファクト状態、コードベースマッピングの完了状況、初回セットアップ後に推奨される次の GSD コマンドを記録します。 |
|
||||
| **生成元** | `PROJECT.md`、`REQUIREMENTS.md`、`ROADMAP.md`、`STATE.md` がすべて存在した後の `/gsd-onboard`。 |
|
||||
| **参照先** | 初回セットアップを確認する人間、および既存オンボーディング状態を確認する今後の `/gsd-onboard` 実行。 |
|
||||
| **用途** | ブラウンフィールドオンボーディングの索引。アーティファクト状態、コードベースマッピングの完了状況、初回セットアップ後に推奨される次の MSD コマンドを記録します。 |
|
||||
| **生成元** | `PROJECT.md`、`REQUIREMENTS.md`、`ROADMAP.md`、`STATE.md` がすべて存在した後の `/msd-onboard`。 |
|
||||
| **参照先** | 初回セットアップを確認する人間、および既存オンボーディング状態を確認する今後の `/msd-onboard` 実行。 |
|
||||
|
||||
### `MILESTONES.md`（オプション）
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | 完了したマイルストーンの履歴記録。各マイルストーンのクローズ時に追記されます。何がいつリリースされたかのアーカイブスナップショットを提供します。 |
|
||||
| **生成元** | `/gsd-complete-milestone`。 |
|
||||
| **参照先** | `/gsd-audit-milestone`; 人間によるレビュー。 |
|
||||
| **生成元** | `/msd-complete-milestone`。 |
|
||||
| **参照先** | `/msd-audit-milestone`; 人間によるレビュー。 |
|
||||
|
||||
### `DECISIONS-INDEX.md`（オプション）
|
||||
|
||||
@@ -118,8 +118,8 @@
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | 作業が中断されたときに書き込まれる機械可読な一時停止状態。再開ポイント、進行中のコンテキスト、継続指示を含みます。再開時に一度だけ使用されます。 |
|
||||
| **生成元** | `/gsd-pause-work`。 |
|
||||
| **参照先** | `/gsd-resume-work`。 |
|
||||
| **生成元** | `/msd-pause-work`。 |
|
||||
| **参照先** | `/msd-resume-work`。 |
|
||||
|
||||
---
|
||||
|
||||
@@ -132,8 +132,8 @@
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | プランニング開始前に収集された実装上の意思決定。フェーズ境界（`<domain>`）、`D-NN` 識別子付きのロックされた意思決定（`<decisions>`）、正規のドキュメント参照（`<canonical_refs>`）、既存のコードのインサイト（`<code_context>`）、具体的な参考例（`<specifics>`）、延期されたアイデア（`<deferred>`）を含みます。 |
|
||||
| **生成元** | `/gsd-discuss-phase`（インタラクティブなディスカッションまたは PRD/ADR エクスプレスパス）。 |
|
||||
| **参照先** | `gsd-phase-researcher`（調査すべき内容）; `gsd-planner`（ロックされた意思決定）; `gsd-plan-checker` ディメンション7（コンテキスト準拠）。 |
|
||||
| **生成元** | `/msd-discuss-phase`（インタラクティブなディスカッションまたは PRD/ADR エクスプレスパス）。 |
|
||||
| **参照先** | `msd-phase-researcher`（調査すべき内容）; `msd-planner`（ロックされた意思決定）; `msd-plan-checker` ディメンション7（コンテキスト準拠）。 |
|
||||
|
||||
完全なフィールドリファレンスは [CONTEXT.md スキーマ](context-md.md) を参照してください。
|
||||
|
||||
@@ -142,7 +142,7 @@
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | discuss-phase セッションの人間可読な監査証跡: 議論された領域、提示されたオプション、行われた選択、延期されたアイデア、Claude の裁量に任せられた項目。自動化されたワークフローには使用されません。 |
|
||||
| **生成元** | `/gsd-discuss-phase`（`git_commit` ステップ）。 |
|
||||
| **生成元** | `/msd-discuss-phase`（`git_commit` ステップ）。 |
|
||||
| **参照先** | 人間によるレビュー; 振り返り。 |
|
||||
|
||||
### `<NN>-RESEARCH.md`
|
||||
@@ -150,32 +150,32 @@
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | プランニング前に生成される技術リサーチの所見。「このフェーズをうまくプランニングするために何を知る必要があるか？」という問いに答えます — ドメイン分析、パターン、リスク、Architectural Responsibility Map、Validation Architecture セクション（Nyquist ゲートで使用）をカバーします。 |
|
||||
| **生成元** | `/gsd-plan-phase`（`gsd-phase-researcher` エージェント経由）。 |
|
||||
| **参照先** | `gsd-planner`（プランニングインプット）; `gsd-plan-checker` ディメンション7c（ティア準拠）、ディメンション8（Nyquist）、ディメンション11（リサーチ解決）; `gsd-pattern-mapper`（ファイルリストのソース）。 |
|
||||
| **生成元** | `/msd-plan-phase`（`msd-phase-researcher` エージェント経由）。 |
|
||||
| **参照先** | `msd-planner`（プランニングインプット）; `msd-plan-checker` ディメンション7c（ティア準拠）、ディメンション8（Nyquist）、ディメンション11（リサーチ解決）; `msd-pattern-mapper`（ファイルリストのソース）。 |
|
||||
|
||||
### `<NN>-VALIDATION.md`
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | RESEARCH.md の `## Validation Architecture` セクションから導出された Nyquist インスパイアのバリデーション戦略。プランが遵守しなければならない自動テストカバレッジ要件を指定します。 |
|
||||
| **生成元** | `/gsd-plan-phase`（ステップ5.5、`workflow.nyquist_validation` が有効で RESEARCH.md に Validation Architecture セクションが含まれる場合）。 |
|
||||
| **参照先** | `gsd-plan-checker` ディメンション8（チェック8e ゲート — Nyquist チェック進行前に存在しなければならない）; `gsd-verifier`。 |
|
||||
| **生成元** | `/msd-plan-phase`（ステップ5.5、`workflow.nyquist_validation` が有効で RESEARCH.md に Validation Architecture セクションが含まれる場合）。 |
|
||||
| **参照先** | `msd-plan-checker` ディメンション8（チェック8e ゲート — Nyquist チェック進行前に存在しなければならない）; `msd-verifier`。 |
|
||||
|
||||
### `<NN>-PATTERNS.md`
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | `gsd-pattern-mapper` によって生成されたコードベースアナログマップ。このフェーズで作成または変更される各ファイルに対して、最も近い既存のアナログを特定し、ファイルの役割とデータフローを分類し、具体的なコード抜粋を抽出します。プランナーを一貫したパターンに向けます。 |
|
||||
| **生成元** | `/gsd-plan-phase`（`gsd-pattern-mapper` エージェント経由、オプション; `workflow.pattern_mapper: false` の場合はスキップ）。 |
|
||||
| **参照先** | `gsd-planner`（パターンガイダンス）; `gsd-plan-checker` ディメンション12（パターン準拠）。 |
|
||||
| **用途** | `msd-pattern-mapper` によって生成されたコードベースアナログマップ。このフェーズで作成または変更される各ファイルに対して、最も近い既存のアナログを特定し、ファイルの役割とデータフローを分類し、具体的なコード抜粋を抽出します。プランナーを一貫したパターンに向けます。 |
|
||||
| **生成元** | `/msd-plan-phase`（`msd-pattern-mapper` エージェント経由、オプション; `workflow.pattern_mapper: false` の場合はスキップ）。 |
|
||||
| **参照先** | `msd-planner`（パターンガイダンス）; `msd-plan-checker` ディメンション12（パターン準拠）。 |
|
||||
|
||||
### `<NN>-<PP>-PLAN.md`
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | フェーズ内の単一作業単位の実行可能プラン。YAML フロントマター（ウェーブ、依存関係、ファイル、要件、`must_haves`）、目的、コンテキスト参照、`<read_first>`、`<action>`、`<verify>`、`<acceptance_criteria>` フィールドを持つ XML 構造化タスク、検証基準を含みます。 |
|
||||
| **生成元** | `/gsd-plan-phase`（`gsd-planner` エージェント経由）。プランごとに1ファイル — 例: `03-02-PLAN.md` はフェーズ3、プラン2。 |
|
||||
| **参照先** | `/gsd-execute-phase`（エグゼキューターエージェントがプランを読んでタスクを実行）; `gsd-plan-checker`（実行前の品質レビュー）; `gsd-verifier`（実行後の検証のために `must_haves` を読む）。 |
|
||||
| **生成元** | `/msd-plan-phase`（`msd-planner` エージェント経由）。プランごとに1ファイル — 例: `03-02-PLAN.md` はフェーズ3、プラン2。 |
|
||||
| **参照先** | `/msd-execute-phase`（エグゼキューターエージェントがプランを読んでタスクを実行）; `msd-plan-checker`（実行前の品質レビュー）; `msd-verifier`（実行後の検証のために `must_haves` を読む）。 |
|
||||
|
||||
完全なフィールドリファレンスは [PLAN.md スキーマ](plan-md.md) を参照してください。
|
||||
|
||||
@@ -185,30 +185,30 @@
|
||||
|---|---|
|
||||
| **用途** | プラン完了後に書き込まれる実行記録。構築された内容、プランからの逸脱、受け入れ基準に対するセルフチェック、フェーズの依存グラフを記録します。 |
|
||||
| **生成元** | `execute-phase` エグゼキューターエージェント（各プランの実行終了時に書き込まれます）。 |
|
||||
| **参照先** | `/gsd-progress`（フェーズステータス）; `gsd-planner`（後続のプランが以前のプラン出力への真の依存を持つ場合）; `milestone-summary`。 |
|
||||
| **参照先** | `/msd-progress`（フェーズステータス）; `msd-planner`（後続のプランが以前のプラン出力への真の依存を持つ場合）; `milestone-summary`。 |
|
||||
|
||||
### `<NN>-VERIFICATION.md`
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | フェーズゴール検証レポート。実行後に実際のコードベースに対してすべてのプランの `must_haves.truths`、`must_haves.artifacts`、`must_haves.key_links` を確認します。`status: passed | gaps_found | human_needed` を記録します。 |
|
||||
| **生成元** | `/gsd-verify-work`（または `/gsd-execute-phase` 内の検証ステップ）。 |
|
||||
| **参照先** | `plan-phase` クローズドフェーズゲート（`status: passed` の VERIFICATION.md はフェーズを `Complete` としてマークし、`--force` なしの再プランニングをブロックする）; `/gsd-progress`; 人間によるレビュー。 |
|
||||
| **生成元** | `/msd-verify-work`（または `/msd-execute-phase` 内の検証ステップ）。 |
|
||||
| **参照先** | `plan-phase` クローズドフェーズゲート（`status: passed` の VERIFICATION.md はフェーズを `Complete` としてマークし、`--force` なしの再プランニングをブロックする）; `/msd-progress`; 人間によるレビュー。 |
|
||||
|
||||
### `<NN>-UAT.md`
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | 永続的な UAT セッション追跡。ライブ UAT セッション全体を通じて各テストケース、期待される観察可能な動作、結果、開発者のレスポンスを記録します。YAML フロントマター（`status`、`phase`、`source`、タイムスタンプ）を持ちます。 |
|
||||
| **生成元** | `/gsd-audit-uat`（インタラクティブな UAT セッション）。 |
|
||||
| **参照先** | `/gsd-audit-uat`（以前の UAT セッションの再開）。 |
|
||||
| **生成元** | `/msd-audit-uat`（インタラクティブな UAT セッション）。 |
|
||||
| **参照先** | `/msd-audit-uat`（以前の UAT セッションの再開）。 |
|
||||
|
||||
### `.continue-here.md`
|
||||
|
||||
| | |
|
||||
|---|---|
|
||||
| **用途** | フェーズの作業が一時停止されたときに書き込まれる人間可読な再開指示。再開エージェントのためのコンテキストを含みます: 重要なアンチパターン、ブロッキング問題、必要な参照、再開するための正確なコマンド。 |
|
||||
| **生成元** | `/gsd-pause-work`。 |
|
||||
| **生成元** | `/msd-pause-work`。 |
|
||||
| **参照先** | フェーズで開始するすべてのワークフロー — `discuss-phase` と `plan-phase` は両方ともエントリ時にこのファイルを確認し、処理を進める前にエージェントが `blocking` アンチパターンへの理解を示すことを要求します。 |
|
||||
|
||||
---
|
||||
|
||||
@@ -1,14 +1,14 @@
|
||||
# STATE.md スキーマリファレンス
|
||||
|
||||
`STATE.md` は GSD Core のプロジェクト記憶ファイルです — プロジェクトの現在地、直近の作業内容、次に実行すべきコマンドを記録する単一の Markdown ドキュメントです。このページではそのスキーマを説明します。[ドキュメントインデックス](../../README.md) も参照してください。
|
||||
`STATE.md` は MSD Core のプロジェクト記憶ファイルです — プロジェクトの現在地、直近の作業内容、次に実行すべきコマンドを記録する単一の Markdown ドキュメントです。このページではそのスキーマを説明します。[ドキュメントインデックス](../../README.md) も参照してください。
|
||||
|
||||
---
|
||||
|
||||
## 概要
|
||||
|
||||
GSD Core で管理するプロジェクトはすべて `.planning/STATE.md` に `STATE.md` を1つ保持します。このファイルはすべてのワークフロー開始時に読み込まれ、重要なアクションのたびに書き込まれます。ファイルは以下を組み合わせた構成です：
|
||||
MSD Core で管理するプロジェクトはすべて `.planning/STATE.md` に `STATE.md` を1つ保持します。このファイルはすべてのワークフロー開始時に読み込まれ、重要なアクションのたびに書き込まれます。ファイルは以下を組み合わせた構成です：
|
||||
|
||||
- **YAML フロントマター** — ステータスラインフック（`parseStateMd`）および `gsd-tools state` コマンドが読み取る機械可読フィールド。
|
||||
- **YAML フロントマター** — ステータスラインフック（`parseStateMd`）および `msd-tools state` コマンドが読み取る機械可読フィールド。
|
||||
- **Markdown 本文** — 現在の進捗、蓄積されたコンテキスト、セッション継続性、パフォーマンス指標を記述する人間可読なセクション。
|
||||
|
||||
ファイルは意図的にコンパクトに保たれています（目標: 100行以内）。プロジェクト状態のダイジェストであり、アーカイブではありません。
|
||||
@@ -17,13 +17,13 @@ GSD Core で管理するプロジェクトはすべて `.planning/STATE.md` に
|
||||
|
||||
## YAML フロントマター
|
||||
|
||||
フロントマターはファイルの先頭にある `---` デリミタの間に記述します。`gsd_state_version` と `status` 以外のフィールドはすべてオプションで、データが未取得の場合は省略できます。
|
||||
フロントマターはファイルの先頭にある `---` デリミタの間に記述します。`msd_state_version` と `status` 以外のフィールドはすべてオプションで、データが未取得の場合は省略できます。
|
||||
|
||||
### 注釈付きサンプル
|
||||
|
||||
```yaml
|
||||
---
|
||||
gsd_state_version: '1.0'
|
||||
msd_state_version: '1.0'
|
||||
milestone: v2.0
|
||||
milestone_name: Code Quality
|
||||
status: executing
|
||||
@@ -56,7 +56,7 @@ paused_at: null
|
||||
|
||||
| フィールド | 型 | 設定タイミング | 用途 |
|
||||
|---|---|---|---|
|
||||
| `gsd_state_version` | string (`'1.0'`) | 常時 | スキーマバージョン。`syncStateFrontmatter` が最初の `state.*` 呼び出し時に書き込む。 |
|
||||
| `msd_state_version` | string (`'1.0'`) | 常時 | スキーマバージョン。`syncStateFrontmatter` が最初の `state.*` 呼び出し時に書き込む。 |
|
||||
| `milestone` | string (例: `v2.0`) | マイルストーン設定時 | 現在のマイルストーンバージョン。プロジェクト設定から読み取る。 |
|
||||
| `milestone_name` | string | マイルストーン設定時 | 人間可読なマイルストーンラベル (例: `Code Quality`)。 |
|
||||
| `status` | string | 常時 | 現在のライフサイクルステージ。`normalizeStateStatus()` によって正規化される — [ステータス値](#ステータス値) 参照。 |
|
||||
@@ -83,7 +83,7 @@ paused_at: null
|
||||
|
||||
| フィールド | 多重度 |
|
||||
|---|---|
|
||||
| `gsd_state_version` | one |
|
||||
| `msd_state_version` | one |
|
||||
| `milestone` | optional |
|
||||
| `milestone_name` | optional |
|
||||
| `current_phase` | optional |
|
||||
@@ -105,7 +105,7 @@ paused_at: null
|
||||
|
||||
### ステータス値
|
||||
|
||||
`gsd-core/bin/lib/state-document.cjs` の `normalizeStateStatus()` が本文の生テキストを以下の正規値にマッピングします：
|
||||
`msd-core/bin/lib/state-document.cjs` の `normalizeStateStatus()` が本文の生テキストを以下の正規値にマッピングします：
|
||||
|
||||
| 正規値 | マッチするテキスト（大文字小文字不問） |
|
||||
|---|---|
|
||||
@@ -121,10 +121,10 @@ paused_at: null
|
||||
|
||||
| コマンド | 実行中の `status` |
|
||||
|---|---|
|
||||
| `/gsd-discuss-phase` | `discussing` |
|
||||
| `/gsd-plan-phase` | `planning` |
|
||||
| `/gsd-execute-phase` | `executing` |
|
||||
| `/gsd-verify-work` | `verifying` |
|
||||
| `/msd-discuss-phase` | `discussing` |
|
||||
| `/msd-plan-phase` | `planning` |
|
||||
| `/msd-execute-phase` | `executing` |
|
||||
| `/msd-verify-work` | `verifying` |
|
||||
|
||||
<!-- STATE-MD-SCHEMA:START:status-lifecycle — generated by scripts/gen-state-md-docs.cjs from src/state-md-schema.cts; do not edit by hand -->
|
||||
### ステータスライフサイクル (ADR-2207)
|
||||
@@ -145,7 +145,7 @@ Phase-completion verbs never write `Milestone complete` (the overloaded bare val
|
||||
|
||||
## ステータスライン描画シーン
|
||||
|
||||
`hooks/gsd-statusline.js` の `formatGsdState()` がパース済みフロントマターを読み取り、**最初にマッチしたシーン** を出力します。新しいライフサイクルフィールドが適用されない場合は、v1.38.x から一切変更なくオリジナルのフォーマットにフォールスルーします。
|
||||
`hooks/msd-statusline.js` の `formatMsdState()` がパース済みフロントマターを読み取り、**最初にマッチしたシーン** を出力します。新しいライフサイクルフィールドが適用されない場合は、v1.38.x から一切変更なくオリジナルのフォーマットにフォールスルーします。
|
||||
|
||||
| シーン | トリガー | 表示例 |
|
||||
|---|---|---|
|
||||
@@ -154,7 +154,7 @@ Phase-completion verbs never write `Milestone complete` (the overloaded bare val
|
||||
| **3. マイルストーン完了** | `percent` が `100` または `completed_phases == total_phases` | `v2.0 [██████████] 100% · milestone complete` |
|
||||
| **4. デフォルトフォールバック** | 上記のいずれにも該当しない | `v1.9 Code Quality · executing · ph 1/5`（既存フォーマット） |
|
||||
|
||||
**シーン優先度:** `active_phase` と `next_action` が両方設定されている場合、シーン1が優先されます — オーケストレーターが実行中であるため「次の推奨」は誤解を招くためです。この優先度は `formatGsdState()` のチェック順序によって強制され、`tests/gsd-statusline.test.cjs` の `"scene priority"` スイートでカバーされています。
|
||||
**シーン優先度:** `active_phase` と `next_action` が両方設定されている場合、シーン1が優先されます — オーケストレーターが実行中であるため「次の推奨」は誤解を招くためです。この優先度は `formatMsdState()` のチェック順序によって強制され、`tests/msd-statusline.test.cjs` の `"scene priority"` スイートでカバーされています。
|
||||
|
||||
進捗バー（`[██░░░░░░░░] 20%`）はフロントマターに `progress.percent` が存在する場合のみマイルストーンセグメントに追加されます。不在の場合はバーは表示されません。
|
||||
|
||||
@@ -162,7 +162,7 @@ Phase-completion verbs never write `Milestone complete` (the overloaded bare val
|
||||
|
||||
## フロントマターパースの制約
|
||||
|
||||
ステータスラインフックは正規表現ベースのパース（完全な YAML ライブラリを使用しない）を使用するため、以下の制約が適用されます。これらは `tests/gsd-statusline.test.cjs` でテストされています。
|
||||
ステータスラインフックは正規表現ベースのパース（完全な YAML ライブラリを使用しない）を使用するため、以下の制約が適用されます。これらは `tests/msd-statusline.test.cjs` でテストされています。
|
||||
|
||||
1. **フロントマターはファイルの先頭文字から始まる必要があります。** コメントを含む何かが開始 `---` の前にあると、マッチが無効になります。開始 `---` 行は末尾のスペースなしで正確にそれだけである必要があります。
|
||||
|
||||
@@ -176,7 +176,7 @@ Phase-completion verbs never write `Milestone complete` (the overloaded bare val
|
||||
|
||||
## Markdown 本文セクション
|
||||
|
||||
本文（末尾の `---` 以降のすべて）は `gsd-core/templates/state.md` のテンプレートに従います。標準セクションは以下の通りです：
|
||||
本文（末尾の `---` 以降のすべて）は `msd-core/templates/state.md` のテンプレートに従います。標準セクションは以下の通りです：
|
||||
|
||||
### Project Reference
|
||||
|
||||
@@ -200,7 +200,7 @@ Phase-completion verbs never write `Milestone complete` (the overloaded bare val
|
||||
|
||||
進捗の*履歴*はここには属しません。それは、増えていくように設計されたセクションである以下の [`### Performance Metrics`](#performance-metrics) に蓄積されます。
|
||||
|
||||
このセクションの `Status:` および `Last activity:` フィールドは、既存の値が既知のテンプレートデフォルト値の場合に GSD ハンドラーによって更新されます（クヌース不変式: エグゼキューター作成値は保存されます）。既知のハンドラーデフォルト値の完全なリストは `gsd-core/bin/lib/state-document.cjs` の `KNOWN_TEMPLATE_DEFAULTS` に記載されています。
|
||||
このセクションの `Status:` および `Last activity:` フィールドは、既存の値が既知のテンプレートデフォルト値の場合に MSD ハンドラーによって更新されます（クヌース不変式: エグゼキューター作成値は保存されます）。既知のハンドラーデフォルト値の完全なリストは `msd-core/bin/lib/state-document.cjs` の `KNOWN_TEMPLATE_DEFAULTS` に記載されています。
|
||||
|
||||
### Performance Metrics
|
||||
|
||||
@@ -213,11 +213,11 @@ Phase-completion verbs never write `Milestone complete` (the overloaded bare val
|
||||
|
||||
### Accumulated Context
|
||||
|
||||
**Decisions** — 現在の作業に影響する最近の意思決定のサマリー（完全なログは `PROJECT.md` に保存）。`gsd-tools state add-decision` で追加。
|
||||
**Decisions** — 現在の作業に影響する最近の意思決定のサマリー（完全なログは `PROJECT.md` に保存）。`msd-tools state add-decision` で追加。
|
||||
|
||||
**Pending Todos** — 件数と `.planning/todos/pending/` への参照。`/gsd-capture` で取得。
|
||||
**Pending Todos** — 件数と `.planning/todos/pending/` への参照。`/msd-capture` で取得。
|
||||
|
||||
**Blockers/Concerns** — 今後の作業に影響する課題。起点フェーズのプレフィックス付き。`gsd-tools state add-blocker` で追加し、`gsd-tools state resolve-blocker` で解決。
|
||||
**Blockers/Concerns** — 今後の作業に影響する課題。起点フェーズのプレフィックス付き。`msd-tools state add-blocker` で追加し、`msd-tools state resolve-blocker` で解決。
|
||||
|
||||
### Session Continuity
|
||||
|
||||
@@ -236,7 +236,7 @@ Phase-completion verbs never write `Milestone complete` (the overloaded bare val
|
||||
- ライフサイクルフィールドの追加はオプトインです — フィールドが不在の場合レンダラーはグレースフルに縮退します。
|
||||
- 進捗バーは `progress` ブロックが存在する場合でもオプトインです: バーをトリガーするのは `progress.percent` のみで、`total_phases` と `completed_phases` だけではトリガーされません。
|
||||
|
||||
`tests/gsd-statusline.test.cjs` の `formatGsdState #2833 backward compatibility` テストスイートがこの保証を固定しています。レガシー `STATE.md` 描画を壊す変更があればスイートが失敗します。
|
||||
`tests/msd-statusline.test.cjs` の `formatMsdState #2833 backward compatibility` テストスイートがこの保証を固定しています。レガシー `STATE.md` 描画を壊す変更があればスイートが失敗します。
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -2,11 +2,11 @@
|
||||
|
||||
> **エージェント型ワーカー向け:** 必須サブスキル: superpowers:subagent-driven-development（推奨）または superpowers:executing-plans を使用して、このプランをタスクごとに実装してください。各ステップはチェックボックス（`- [ ]`）構文で進捗を追跡します。
|
||||
|
||||
**目標:** `/gsd-new-project` が `.planning/config.json` を作成する際、ユーザーが選択した6つのキーだけでなく、すべての有効なデフォルト値を含むファイルを生成する。これにより、開発者はソースコードを読まなくてもすべての設定を確認できるようになる。
|
||||
**目標:** `/msd-new-project` が `.planning/config.json` を作成する際、ユーザーが選択した6つのキーだけでなく、すべての有効なデフォルト値を含むファイルを生成する。これにより、開発者はソースコードを読まなくてもすべての設定を確認できるようになる。
|
||||
|
||||
**アーキテクチャ:** `config.cjs` に単一の JS 関数 `buildNewProjectConfig(cwd, userChoices)` を追加し、新規プロジェクトの完全な設定の唯一の信頼できる情報源とする。これを CLI コマンド `config-new-project` として公開する。`new-project.md` ワークフローを更新し、部分的な JSON をインラインで書き込む代わりにこのコマンドを呼び出すようにする。
|
||||
|
||||
**技術スタック:** Node.js/CommonJS、既存の gsd-tools CLI、テストには `node:test` を使用。
|
||||
**技術スタック:** Node.js/CommonJS、既存の msd-tools CLI、テストには `node:test` を使用。
|
||||
|
||||
---
|
||||
|
||||
@@ -27,8 +27,8 @@
|
||||
- `search_gitignored: false`
|
||||
- `brave_search: false`（または環境検出による `true`）
|
||||
- `git.branching_strategy: "none"`
|
||||
- `git.phase_branch_template: "gsd/phase-{phase}-{slug}"`
|
||||
- `git.milestone_branch_template: "gsd/{milestone}-{slug}"`
|
||||
- `git.phase_branch_template: "msd/phase-{phase}-{slug}"`
|
||||
- `git.milestone_branch_template: "msd/{milestone}-{slug}"`
|
||||
|
||||
最初から存在すべき完全な設定:
|
||||
|
||||
@@ -43,8 +43,8 @@
|
||||
"brave_search": false,
|
||||
"git": {
|
||||
"branching_strategy": "none",
|
||||
"phase_branch_template": "gsd/phase-{phase}-{slug}",
|
||||
"milestone_branch_template": "gsd/{milestone}-{slug}"
|
||||
"phase_branch_template": "msd/phase-{phase}-{slug}",
|
||||
"milestone_branch_template": "msd/{milestone}-{slug}"
|
||||
},
|
||||
"workflow": {
|
||||
"research": true,
|
||||
@@ -62,7 +62,7 @@
|
||||
| ファイル | 操作 | 目的 |
|
||||
|------|--------|---------|
|
||||
| `get-shit-done/bin/lib/config.cjs` | 変更 | `buildNewProjectConfig()` + `cmdConfigNewProject()` を追加 |
|
||||
| `get-shit-done/bin/gsd-tools.cjs` | 変更 | `config-new-project` の case を登録 + usage 文字列を更新 |
|
||||
| `get-shit-done/bin/msd-tools.cjs` | 変更 | `config-new-project` の case を登録 + usage 文字列を更新 |
|
||||
| `get-shit-done/workflows/new-project.md` | 変更 | ステップ 2a + 5: インライン JSON 書き込みを CLI 呼び出しに置換 |
|
||||
| `tests/config.test.cjs` | 変更 | `config-new-project` テストスイートを追加 |
|
||||
|
||||
@@ -101,7 +101,7 @@ describe('config-new-project command', () => {
|
||||
model_profile: 'balanced',
|
||||
workflow: { research: true, plan_check: true, verifier: true, nyquist_validation: true },
|
||||
});
|
||||
const result = runGsdTools(['config-new-project', choices], tmpDir);
|
||||
const result = runMsdTools(['config-new-project', choices], tmpDir);
|
||||
assert.ok(result.success, `Command failed: ${result.error}`);
|
||||
|
||||
const config = readConfig(tmpDir);
|
||||
@@ -120,8 +120,8 @@ describe('config-new-project command', () => {
|
||||
// git セクションが3つのキーすべてを持つ
|
||||
assert.ok(config.git && typeof config.git === 'object', 'git section should exist');
|
||||
assert.strictEqual(config.git.branching_strategy, 'none');
|
||||
assert.strictEqual(config.git.phase_branch_template, 'gsd/phase-{phase}-{slug}');
|
||||
assert.strictEqual(config.git.milestone_branch_template, 'gsd/{milestone}-{slug}');
|
||||
assert.strictEqual(config.git.phase_branch_template, 'msd/phase-{phase}-{slug}');
|
||||
assert.strictEqual(config.git.milestone_branch_template, 'msd/{milestone}-{slug}');
|
||||
|
||||
// workflow セクションが4つのキーすべてを持つ
|
||||
assert.ok(config.workflow && typeof config.workflow === 'object', 'workflow section should exist');
|
||||
@@ -140,7 +140,7 @@ describe('config-new-project command', () => {
|
||||
model_profile: 'quality',
|
||||
workflow: { research: false, plan_check: false, verifier: true, nyquist_validation: false },
|
||||
});
|
||||
const result = runGsdTools(['config-new-project', choices], tmpDir);
|
||||
const result = runMsdTools(['config-new-project', choices], tmpDir);
|
||||
assert.ok(result.success, `Command failed: ${result.error}`);
|
||||
|
||||
const config = readConfig(tmpDir);
|
||||
@@ -159,7 +159,7 @@ describe('config-new-project command', () => {
|
||||
});
|
||||
|
||||
test('works with empty choices — all defaults materialized', () => {
|
||||
const result = runGsdTools(['config-new-project', '{}'], tmpDir);
|
||||
const result = runMsdTools(['config-new-project', '{}'], tmpDir);
|
||||
assert.ok(result.success, `Command failed: ${result.error}`);
|
||||
|
||||
const config = readConfig(tmpDir);
|
||||
@@ -176,13 +176,13 @@ describe('config-new-project command', () => {
|
||||
test('is idempotent — returns already_exists if config exists', () => {
|
||||
// 1回目の呼び出し: 作成
|
||||
const choices = JSON.stringify({ mode: 'yolo', granularity: 'fine' });
|
||||
const first = runGsdTools(['config-new-project', choices], tmpDir);
|
||||
const first = runMsdTools(['config-new-project', choices], tmpDir);
|
||||
assert.ok(first.success, `First call failed: ${first.error}`);
|
||||
const firstOut = JSON.parse(first.output);
|
||||
assert.strictEqual(firstOut.created, true);
|
||||
|
||||
// 2回目の呼び出し: 冪等性の確認
|
||||
const second = runGsdTools(['config-new-project', choices], tmpDir);
|
||||
const second = runMsdTools(['config-new-project', choices], tmpDir);
|
||||
assert.ok(second.success, `Second call failed: ${second.error}`);
|
||||
const secondOut = JSON.parse(second.output);
|
||||
assert.strictEqual(secondOut.created, false);
|
||||
@@ -200,7 +200,7 @@ describe('config-new-project command', () => {
|
||||
granularity: 'standard',
|
||||
workflow: { research: true, plan_check: true, verifier: true, nyquist_validation: true, auto_advance: true },
|
||||
});
|
||||
const result = runGsdTools(['config-new-project', choices], tmpDir);
|
||||
const result = runMsdTools(['config-new-project', choices], tmpDir);
|
||||
assert.ok(result.success, `Command failed: ${result.error}`);
|
||||
|
||||
const config = readConfig(tmpDir);
|
||||
@@ -208,14 +208,14 @@ describe('config-new-project command', () => {
|
||||
});
|
||||
|
||||
test('rejects invalid JSON choices', () => {
|
||||
const result = runGsdTools(['config-new-project', '{not-json}'], tmpDir);
|
||||
const result = runMsdTools(['config-new-project', '{not-json}'], tmpDir);
|
||||
assert.strictEqual(result.success, false);
|
||||
assert.ok(result.error.includes('Invalid JSON'), `Expected "Invalid JSON" in: ${result.error}`);
|
||||
});
|
||||
|
||||
test('output JSON has created:true on success', () => {
|
||||
const choices = JSON.stringify({ mode: 'interactive', granularity: 'standard' });
|
||||
const result = runGsdTools(['config-new-project', choices], tmpDir);
|
||||
const result = runMsdTools(['config-new-project', choices], tmpDir);
|
||||
assert.ok(result.success, `Command failed: ${result.error}`);
|
||||
const out = JSON.parse(result.output);
|
||||
assert.strictEqual(out.created, true);
|
||||
@@ -243,7 +243,7 @@ node --test tests/config.test.cjs 2>&1 | grep -E "config-new-project|FAIL|Error"
|
||||
*
|
||||
* 以下の優先順位（昇順）でマージする:
|
||||
* 1. ハードコードされたデフォルト値
|
||||
* 2. ~/.gsd/defaults.json のユーザーレベルデフォルト（存在する場合）
|
||||
* 2. ~/.msd/defaults.json のユーザーレベルデフォルト（存在する場合）
|
||||
* 3. userChoices（new-project 時にユーザーが明示的に選択した設定）
|
||||
*
|
||||
* プレーンオブジェクトを返す — ファイルの書き込みは行わない。
|
||||
@@ -253,11 +253,11 @@ function buildNewProjectConfig(cwd, userChoices) {
|
||||
const homedir = require('os').homedir();
|
||||
|
||||
// Brave Search API キーの利用可能性を検出
|
||||
const braveKeyFile = path.join(homedir, '.gsd', 'brave_api_key');
|
||||
const braveKeyFile = path.join(homedir, '.msd', 'brave_api_key');
|
||||
const hasBraveSearch = !!(process.env.BRAVE_API_KEY || fs.existsSync(braveKeyFile));
|
||||
|
||||
// ~/.gsd/defaults.json からユーザーレベルのデフォルトを読み込む（存在する場合）
|
||||
const globalDefaultsPath = path.join(homedir, '.gsd', 'defaults.json');
|
||||
// ~/.msd/defaults.json からユーザーレベルのデフォルトを読み込む（存在する場合）
|
||||
const globalDefaultsPath = path.join(homedir, '.msd', 'defaults.json');
|
||||
let userDefaults = {};
|
||||
try {
|
||||
if (fs.existsSync(globalDefaultsPath)) {
|
||||
@@ -284,8 +284,8 @@ function buildNewProjectConfig(cwd, userChoices) {
|
||||
brave_search: hasBraveSearch,
|
||||
git: {
|
||||
branching_strategy: 'none',
|
||||
phase_branch_template: 'gsd/phase-{phase}-{slug}',
|
||||
milestone_branch_template: 'gsd/{milestone}-{slug}',
|
||||
phase_branch_template: 'msd/phase-{phase}-{slug}',
|
||||
milestone_branch_template: 'msd/{milestone}-{slug}',
|
||||
},
|
||||
workflow: {
|
||||
research: true,
|
||||
@@ -316,9 +316,9 @@ function buildNewProjectConfig(cwd, userChoices) {
|
||||
/**
|
||||
* コマンド: 新規プロジェクト用の完全展開された .planning/config.json を作成する。
|
||||
*
|
||||
* ユーザーが選択した設定を JSON 文字列として受け取る（/gsd-new-project 時に
|
||||
* ユーザーが選択した設定を JSON 文字列として受け取る（/msd-new-project 時に
|
||||
* ユーザーが明示的に設定したキー）。残りのキーはハードコードされたデフォルトと
|
||||
* オプションの ~/.gsd/defaults.json から補完される。
|
||||
* オプションの ~/.msd/defaults.json から補完される。
|
||||
*
|
||||
* 冪等: config.json が既に存在する場合は { created: false } を返す。
|
||||
*/
|
||||
@@ -383,13 +383,13 @@ git commit -m "feat: add config-new-project command for full config materializat
|
||||
|
||||
---
|
||||
|
||||
## タスク 2: gsd-tools.cjs に `config-new-project` を登録する
|
||||
## タスク 2: msd-tools.cjs に `config-new-project` を登録する
|
||||
|
||||
**ファイル:**
|
||||
|
||||
- 変更: `get-shit-done/bin/gsd-tools.cjs`
|
||||
- 変更: `get-shit-done/bin/msd-tools.cjs`
|
||||
|
||||
- [ ] **ステップ 2.1: gsd-tools.cjs の switch 文に case を追加する**
|
||||
- [ ] **ステップ 2.1: msd-tools.cjs の switch 文に case を追加する**
|
||||
|
||||
`config-get` の case の後（401行目付近）に以下を追加する:
|
||||
|
||||
@@ -409,12 +409,12 @@ git commit -m "feat: add config-new-project command for full config materializat
|
||||
|
||||
```bash
|
||||
cd /Users/diego/Dev/get-shit-done
|
||||
node get-shit-done/bin/gsd-tools.cjs config-new-project '{"mode":"interactive","granularity":"standard"}' --cwd /tmp/gsd-smoke-$(date +%s)
|
||||
node get-shit-done/bin/msd-tools.cjs config-new-project '{"mode":"interactive","granularity":"standard"}' --cwd /tmp/msd-smoke-$(date +%s)
|
||||
```
|
||||
|
||||
期待結果: `{"created":true,"path":".planning/config.json"}` （または類似の出力）が表示される。
|
||||
|
||||
クリーンアップ: `rm -rf /tmp/gsd-smoke-*`
|
||||
クリーンアップ: `rm -rf /tmp/msd-smoke-*`
|
||||
|
||||
- [ ] **ステップ 2.3: フルテストスイートを実行する**
|
||||
|
||||
@@ -429,8 +429,8 @@ node --test tests/config.test.cjs 2>&1 | tail -10
|
||||
|
||||
```bash
|
||||
cd /Users/diego/Dev/get-shit-done
|
||||
git add get-shit-done/bin/gsd-tools.cjs
|
||||
git commit -m "feat: register config-new-project in gsd-tools CLI router"
|
||||
git add get-shit-done/bin/msd-tools.cjs
|
||||
git commit -m "feat: register config-new-project in msd-tools CLI router"
|
||||
```
|
||||
|
||||
---
|
||||
@@ -470,7 +470,7 @@ Create `.planning/config.json` using the CLI (fills in all defaults automaticall
|
||||
|
||||
```bash
|
||||
mkdir -p .planning
|
||||
node "$HOME/.claude/get-shit-done/bin/gsd-tools.cjs" config-new-project "$(cat <<'CHOICES'
|
||||
node "$HOME/.claude/get-shit-done/bin/msd-tools.cjs" config-new-project "$(cat <<'CHOICES'
|
||||
{
|
||||
"mode": "yolo",
|
||||
"granularity": "[selected: coarse|standard|fine]",
|
||||
@@ -516,7 +516,7 @@ Create `.planning/config.json` using the CLI (fills in all defaults automaticall
|
||||
|
||||
```bash
|
||||
mkdir -p .planning
|
||||
node "$HOME/.claude/get-shit-done/bin/gsd-tools.cjs" config-new-project "$(cat <<'CHOICES'
|
||||
node "$HOME/.claude/get-shit-done/bin/msd-tools.cjs" config-new-project "$(cat <<'CHOICES'
|
||||
{
|
||||
"mode": "[selected: yolo|interactive]",
|
||||
"granularity": "[selected: coarse|standard|fine]",
|
||||
@@ -578,10 +578,10 @@ TMP=$(mktemp -d)
|
||||
cd "$TMP"
|
||||
|
||||
# ステップ 1 のシミュレーション: init new-project の実行結果
|
||||
node /Users/diego/Dev/get-shit-done/get-shit-done/bin/gsd-tools.cjs init new-project --cwd "$TMP"
|
||||
node /Users/diego/Dev/get-shit-done/get-shit-done/bin/msd-tools.cjs init new-project --cwd "$TMP"
|
||||
|
||||
# ステップ 5 のシミュレーション: 完全な設定を作成
|
||||
node /Users/diego/Dev/get-shit-done/get-shit-done/bin/gsd-tools.cjs config-new-project '{
|
||||
node /Users/diego/Dev/get-shit-done/get-shit-done/bin/msd-tools.cjs config-new-project '{
|
||||
"mode": "interactive",
|
||||
"granularity": "standard",
|
||||
"parallelization": true,
|
||||
@@ -611,11 +611,11 @@ rm -rf "$TMP"
|
||||
TMP=$(mktemp -d)
|
||||
CHOICES='{"mode":"yolo","granularity":"coarse"}'
|
||||
|
||||
node /Users/diego/Dev/get-shit-done/get-shit-done/bin/gsd-tools.cjs config-new-project "$CHOICES" --cwd "$TMP"
|
||||
node /Users/diego/Dev/get-shit-done/get-shit-done/bin/msd-tools.cjs config-new-project "$CHOICES" --cwd "$TMP"
|
||||
FIRST=$(cat "$TMP/.planning/config.json")
|
||||
|
||||
# 2回目の呼び出しは何も変更しないはず
|
||||
node /Users/diego/Dev/get-shit-done/get-shit-done/bin/gsd-tools.cjs config-new-project "$CHOICES" --cwd "$TMP"
|
||||
node /Users/diego/Dev/get-shit-done/get-shit-done/bin/msd-tools.cjs config-new-project "$CHOICES" --cwd "$TMP"
|
||||
SECOND=$(cat "$TMP/.planning/config.json")
|
||||
|
||||
[ "$FIRST" = "$SECOND" ] && echo "IDEMPOTENT: OK" || echo "IDEMPOTENT: FAIL"
|
||||
@@ -628,17 +628,17 @@ rm -rf "$TMP"
|
||||
|
||||
```bash
|
||||
TMP=$(mktemp -d)
|
||||
node /Users/diego/Dev/get-shit-done/get-shit-done/bin/gsd-tools.cjs config-new-project '{
|
||||
node /Users/diego/Dev/get-shit-done/get-shit-done/bin/msd-tools.cjs config-new-project '{
|
||||
"mode":"yolo","granularity":"standard","parallelization":true,"commit_docs":true,
|
||||
"model_profile":"balanced",
|
||||
"workflow":{"research":true,"plan_check":false,"verifier":true,"nyquist_validation":true}
|
||||
}' --cwd "$TMP"
|
||||
|
||||
# loadConfig が正しく plan_check（workflow.plan_check としてネスト）を読み取るか
|
||||
node /Users/diego/Dev/get-shit-done/get-shit-done/bin/gsd-tools.cjs config-get workflow.plan_check --cwd "$TMP"
|
||||
node /Users/diego/Dev/get-shit-done/get-shit-done/bin/msd-tools.cjs config-get workflow.plan_check --cwd "$TMP"
|
||||
# 期待値: false
|
||||
|
||||
node /Users/diego/Dev/get-shit-done/get-shit-done/bin/gsd-tools.cjs config-get git.branching_strategy --cwd "$TMP"
|
||||
node /Users/diego/Dev/get-shit-done/get-shit-done/bin/msd-tools.cjs config-get git.branching_strategy --cwd "$TMP"
|
||||
# 期待値: "none"
|
||||
|
||||
rm -rf "$TMP"
|
||||
@@ -661,7 +661,7 @@ node --test tests/ 2>&1 | grep -E "pass|fail|error" | tail -5
|
||||
feat: materialize all config defaults at new-project initialization
|
||||
|
||||
**問題:**
|
||||
`/gsd-new-project` はオンボーディング時にユーザーが明示的に選択した6つのキーのみで
|
||||
`/msd-new-project` はオンボーディング時にユーザーが明示的に選択した6つのキーのみで
|
||||
`.planning/config.json` を作成する。5つの追加キー
|
||||
（`search_gitignored`、`brave_search`、`git.branching_strategy`、
|
||||
`git.phase_branch_template`、`git.milestone_branch_template`）は実行時に
|
||||
@@ -670,11 +670,11 @@ feat: materialize all config defaults at new-project initialization
|
||||
これにより2つの問題が生じる:
|
||||
1. **発見可能性**: ユーザーがソースコードを読まない限り `git.branching_strategy` を
|
||||
確認・理解できない — 設定ファイルに表示されない。
|
||||
2. **暗黙的な拡張**: `/gsd-settings` や `config-set` が初めて設定に書き込む際にも、
|
||||
2. **暗黙的な拡張**: `/msd-settings` や `config-set` が初めて設定に書き込む際にも、
|
||||
これらのキーは追加されない。設定ファイルは実効設定のごく一部しか反映しない。
|
||||
|
||||
**解決策:**
|
||||
`gsd-tools.cjs` に `config-new-project` CLI コマンドを追加する。このコマンドは:
|
||||
`msd-tools.cjs` に `config-new-project` CLI コマンドを追加する。このコマンドは:
|
||||
- ユーザーが選択した値を JSON として受け取る
|
||||
- すべてのランタイムデフォルト（環境検出される `brave_search` を含む）とマージする
|
||||
- 完全に展開された設定を一度に書き込む
|
||||
@@ -694,6 +694,6 @@ JSON テンプレートの書き込みの代わりにこのコマンドを呼び
|
||||
|
||||
**発見可能性が向上する理由:**
|
||||
初めて `.planning/config.json` を開いた開発者が `git.branching_strategy: "none"` を
|
||||
見て、GSD のソースコードを読まなくてもブランチ戦略機能が利用可能で設定変更できることを
|
||||
見て、MSD のソースコードを読まなくてもブランチ戦略機能が利用可能で設定変更できることを
|
||||
即座に理解できるようになる。
|
||||
```
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# マルチプロジェクトワークスペース (`/gsd-workspace --new`)
|
||||
# マルチプロジェクトワークスペース (`/msd-workspace --new`)
|
||||
|
||||
**Issue:** #1241
|
||||
**Date:** 2026-03-20
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
## 課題
|
||||
|
||||
GSD は作業ディレクトリごとに1つの `.planning/` ディレクトリに紐づいています。複数の独立したプロジェクトを持つユーザー（20以上の子リポジトリを含むモノレポ構成など）や、同一リポジトリ内でフィーチャーブランチの分離が必要なユーザーは、手動でのクローンや状態管理なしに並行して GSD セッションを実行することができません。
|
||||
MSD は作業ディレクトリごとに1つの `.planning/` ディレクトリに紐づいています。複数の独立したプロジェクトを持つユーザー（20以上の子リポジトリを含むモノレポ構成など）や、同一リポジトリ内でフィーチャーブランチの分離が必要なユーザーは、手動でのクローンや状態管理なしに並行して MSD セッションを実行することができません。
|
||||
|
||||
## 解決策
|
||||
|
||||
@@ -18,13 +18,13 @@ GSD は作業ディレクトリごとに1つの `.planning/` ディレクトリ
|
||||
|
||||
## コマンド
|
||||
|
||||
### `/gsd-workspace --new`
|
||||
### `/msd-workspace --new`
|
||||
|
||||
リポジトリのコピーと独自の `.planning/` を持つワークスペースディレクトリを作成します。
|
||||
|
||||
```bash
|
||||
/gsd-workspace --new --name feature-b --repos hr-ui,ZeymoAPI --path ~/workspaces/feature-b
|
||||
/gsd-workspace --new --name feature-b --repos . --strategy worktree # same-repo isolation
|
||||
/msd-workspace --new --name feature-b --repos hr-ui,ZeymoAPI --path ~/workspaces/feature-b
|
||||
/msd-workspace --new --name feature-b --repos . --strategy worktree # same-repo isolation
|
||||
```
|
||||
|
||||
**引数:**
|
||||
@@ -33,26 +33,26 @@ GSD は作業ディレクトリごとに1つの `.planning/` ディレクトリ
|
||||
|------|----------|---------|-------------|
|
||||
| `--name` | はい | — | ワークスペース名 |
|
||||
| `--repos` | いいえ | 対話的な選択 | カンマ区切りのリポジトリパスまたは名前 |
|
||||
| `--path` | いいえ | `~/gsd-workspaces/<name>` | 出力先ディレクトリ |
|
||||
| `--path` | いいえ | `~/msd-workspaces/<name>` | 出力先ディレクトリ |
|
||||
| `--strategy` | いいえ | `worktree` | `worktree`（軽量、.git を共有）または `clone`（完全に独立） |
|
||||
| `--branch` | いいえ | `workspace/<name>` | チェックアウトするブランチ |
|
||||
| `--auto` | いいえ | false | 対話的な質問をスキップし、デフォルト値を使用 |
|
||||
|
||||
### `/gsd-workspace --list`
|
||||
### `/msd-workspace --list`
|
||||
|
||||
`~/gsd-workspaces/*/WORKSPACE.md` をスキャンしてワークスペースマニフェストを検索します。名前、パス、リポジトリ数、GSD ステータス（PROJECT.md の有無、現在のフェーズ）をテーブル形式で表示します。
|
||||
`~/msd-workspaces/*/WORKSPACE.md` をスキャンしてワークスペースマニフェストを検索します。名前、パス、リポジトリ数、MSD ステータス（PROJECT.md の有無、現在のフェーズ）をテーブル形式で表示します。
|
||||
|
||||
### `/gsd-workspace --remove`
|
||||
### `/msd-workspace --remove`
|
||||
|
||||
確認後にワークスペースディレクトリを削除します。worktree 戦略の場合、まず各メンバーリポジトリに対して `git worktree remove` を実行します。コミットされていない変更があるリポジトリがある場合は削除を拒否します。
|
||||
|
||||
## ディレクトリ構造
|
||||
|
||||
```
|
||||
~/gsd-workspaces/feature-b/ # workspace root
|
||||
~/msd-workspaces/feature-b/ # workspace root
|
||||
├── WORKSPACE.md # manifest
|
||||
├── .planning/ # independent GSD planning directory
|
||||
│ ├── PROJECT.md # (if user ran /gsd-new-project)
|
||||
├── .planning/ # independent MSD planning directory
|
||||
│ ├── PROJECT.md # (if user ran /msd-new-project)
|
||||
│ ├── STATE.md
|
||||
│ └── config.json
|
||||
├── hr-ui/ # git worktree of source repo
|
||||
@@ -64,7 +64,7 @@ GSD は作業ディレクトリごとに1つの `.planning/` ディレクトリ
|
||||
主要な特性：
|
||||
- `.planning/` はワークスペースのルートに配置され、個々のリポジトリ内には配置されない
|
||||
- 各リポジトリはワークスペースルート直下の対等なディレクトリ
|
||||
- `WORKSPACE.md` はルートにある唯一の GSD 固有ファイル（`.planning/` を除く）
|
||||
- `WORKSPACE.md` はルートにある唯一の MSD 固有ファイル（`.planning/` を除く）
|
||||
- `--strategy clone` の場合も同じ構造だが、リポジトリは完全なクローンとなる
|
||||
|
||||
## WORKSPACE.md のフォーマット
|
||||
@@ -89,7 +89,7 @@ Strategy: worktree
|
||||
|
||||
## ワークフロー
|
||||
|
||||
### `/gsd-workspace --new` のワークフロー手順
|
||||
### `/msd-workspace --new` のワークフロー手順
|
||||
|
||||
1. **セットアップ** — `init new-workspace` を呼び出し、JSON コンテキストを解析する
|
||||
2. **入力の収集** — `--name`/`--repos`/`--path` が指定されていない場合、対話的に質問する。リポジトリの選択時は、カレントディレクトリ内の子 `.git` ディレクトリを選択肢として表示する
|
||||
@@ -100,7 +100,7 @@ Strategy: worktree
|
||||
- Clone: `git clone <source> <workspace>/<repo-name>`
|
||||
6. **WORKSPACE.md の書き込み** — ソースパス、戦略、ブランチを含むマニフェスト
|
||||
7. **.planning/ の初期化** — `mkdir -p <workspace>/.planning`
|
||||
8. **/gsd-new-project の提案** — 新しいワークスペースでプロジェクト初期化を実行するか確認する
|
||||
8. **/msd-new-project の提案** — 新しいワークスペースでプロジェクト初期化を実行するか確認する
|
||||
9. **コミット** — commit_docs が有効な場合、WORKSPACE.md のアトミックコミット
|
||||
10. **完了** — ワークスペースのパスと次のステップを表示する
|
||||
|
||||
@@ -111,7 +111,7 @@ Strategy: worktree
|
||||
- 出力先パスが既に存在するかどうか
|
||||
- ソースリポジトリにコミットされていない変更があるかどうか
|
||||
- `git worktree` が利用可能かどうか
|
||||
- デフォルトのワークスペースベースディレクトリ (`~/gsd-workspaces/`)
|
||||
- デフォルトのワークスペースベースディレクトリ (`~/msd-workspaces/`)
|
||||
|
||||
ワークフローの分岐制御用フラグを含む JSON を返します。
|
||||
|
||||
@@ -137,7 +137,7 @@ Strategy: worktree
|
||||
|
||||
### List-Workspaces のエッジケース
|
||||
|
||||
- **`~/gsd-workspaces/` が存在しない場合** — 「ワークスペースが見つかりません」
|
||||
- **`~/msd-workspaces/` が存在しない場合** — 「ワークスペースが見つかりません」
|
||||
- **WORKSPACE.md は存在するが、内部のリポジトリがなくなっている場合** — ワークスペースを表示し、リポジトリを欠落としてマークする
|
||||
|
||||
## テスト
|
||||
@@ -163,23 +163,23 @@ Strategy: worktree
|
||||
|
||||
| コンポーネント | パス |
|
||||
|-----------|------|
|
||||
| コマンド: new-workspace | `commands/gsd/new-workspace.md` |
|
||||
| コマンド: list-workspaces | `commands/gsd/list-workspaces.md` |
|
||||
| コマンド: remove-workspace | `commands/gsd/remove-workspace.md` |
|
||||
| ワークフロー: new-workspace | `gsd-core/workflows/new-workspace.md` |
|
||||
| ワークフロー: list-workspaces | `gsd-core/workflows/list-workspaces.md` |
|
||||
| ワークフロー: remove-workspace | `gsd-core/workflows/remove-workspace.md` |
|
||||
| Init 関数 | `gsd-core/bin/lib/init.cjs`（`cmdInitNewWorkspace`、`cmdInitListWorkspaces`、`cmdInitRemoveWorkspace` を追加） |
|
||||
| ルーティング | `gsd-core/bin/gsd-tools.cjs`（init switch にケースを追加） |
|
||||
| コマンド: new-workspace | `commands/msd/new-workspace.md` |
|
||||
| コマンド: list-workspaces | `commands/msd/list-workspaces.md` |
|
||||
| コマンド: remove-workspace | `commands/msd/remove-workspace.md` |
|
||||
| ワークフロー: new-workspace | `msd-core/workflows/new-workspace.md` |
|
||||
| ワークフロー: list-workspaces | `msd-core/workflows/list-workspaces.md` |
|
||||
| ワークフロー: remove-workspace | `msd-core/workflows/remove-workspace.md` |
|
||||
| Init 関数 | `msd-core/bin/lib/init.cjs`（`cmdInitNewWorkspace`、`cmdInitListWorkspaces`、`cmdInitRemoveWorkspace` を追加） |
|
||||
| ルーティング | `msd-core/bin/msd-tools.cjs`（init switch にケースを追加） |
|
||||
| テスト | `tests/workspace.test.cjs` |
|
||||
|
||||
## 設計上の決定
|
||||
|
||||
| 決定事項 | 根拠 |
|
||||
|----------|-----------|
|
||||
| 論理的なレジストリではなく物理ディレクトリを採用 | ファイルシステムを信頼の源とする — GSD の既存の cwd ベースの検出パターンと一致する |
|
||||
| 論理的なレジストリではなく物理ディレクトリを採用 | ファイルシステムを信頼の源とする — MSD の既存の cwd ベースの検出パターンと一致する |
|
||||
| Worktree をデフォルト戦略とする | 軽量（.git オブジェクトを共有）、作成が高速、クリーンアップが容易 |
|
||||
| `.planning/` をワークスペースルートに配置 | 個々のリポジトリの planning から完全に分離できる。各ワークスペースは独立した GSD プロジェクトとなる |
|
||||
| `.planning/` をワークスペースルートに配置 | 個々のリポジトリの planning から完全に分離できる。各ワークスペースは独立した MSD プロジェクトとなる |
|
||||
| 中央レジストリを使用しない | 状態の乖離を回避する。`list-workspaces` はファイルシステムを直接スキャンする |
|
||||
| ケース B を A の特殊ケースとする | `--repos .` で同じ仕組みを再利用し、フィーチャーブランチ専用のコードが不要 |
|
||||
| デフォルトパスを `~/gsd-workspaces/<name>` とする | `list-workspaces` がスキャンしやすい予測可能な場所に配置し、ワークスペースをソースリポジトリの外に保つ |
|
||||
| デフォルトパスを `~/msd-workspaces/<name>` とする | `list-workspaces` がスキャンしやすい予測可能な場所に配置し、ワークスペースをソースリポジトリの外に保つ |
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
# 既存コードベースのオンボーディング
|
||||
|
||||
このチュートリアルでは、すでにコードが存在するリポジトリに GSD Core を導入します。コードベースをマッピングし、*追加する*内容を説明するプロジェクトを作成して、小さな変更に対して最初の議論・計画サイクルを実行します。最終的に、GSD Core の計画パイプラインがあなたのスタック、規約、懸念事項を把握し、計画するたびにその知識を活用できる状態になります。
|
||||
このチュートリアルでは、すでにコードが存在するリポジトリに MSD Core を導入します。コードベースをマッピングし、*追加する*内容を説明するプロジェクトを作成して、小さな変更に対して最初の議論・計画サイクルを実行します。最終的に、MSD Core の計画パイプラインがあなたのスタック、規約、懸念事項を把握し、計画するたびにその知識を活用できる状態になります。
|
||||
|
||||
---
|
||||
|
||||
## 作るもの
|
||||
|
||||
既存の Express アプリケーションに `GET /health` エンドポイントを1つ追加します。変更は小さく、本来のレッスン — GSD Core が計画前にコードベースを学習する仕組み — から注意がそれることはありません。
|
||||
既存の Express アプリケーションに `GET /health` エンドポイントを1つ追加します。変更は小さく、本来のレッスン — MSD Core が計画前にコードベースを学習する仕組み — から注意がそれることはありません。
|
||||
|
||||
---
|
||||
|
||||
@@ -18,12 +18,12 @@
|
||||
|
||||
---
|
||||
|
||||
## ステップ 1 — GSD Core のインストール
|
||||
## ステップ 1 — MSD Core のインストール
|
||||
|
||||
リポジトリのルートで以下を実行します:
|
||||
|
||||
```bash
|
||||
npx @opengsd/gsd-core@latest
|
||||
npx @golem15/msd-core@latest
|
||||
```
|
||||
|
||||
プロンプトが表示されたら **Claude Code** と **local** を選択してください。以下が表示されます:
|
||||
@@ -31,7 +31,7 @@ npx @opengsd/gsd-core@latest
|
||||
```text
|
||||
✓ Installed 86 skills to .claude/commands/
|
||||
✓ Installed agents to .claude/agents/
|
||||
✓ GSD Core ready — run /gsd-new-project to start
|
||||
✓ MSD Core ready — run /msd-new-project to start
|
||||
```
|
||||
|
||||
---
|
||||
@@ -44,7 +44,7 @@ claude --dangerously-skip-permissions
|
||||
|
||||
> [!CAUTION]
|
||||
> **The permissions flag is optional.** It skips per-file confirmation while
|
||||
> GSD's sub-agents read and write files. Use it only in low-stakes or
|
||||
> MSD's sub-agents read and write files. Use it only in low-stakes or
|
||||
> throwaway contexts. To keep confirmations enabled, start with `claude` instead.
|
||||
> For real work, read the [security model](../explanation/security-model.md) first.
|
||||
|
||||
@@ -53,13 +53,13 @@ claude --dangerously-skip-permissions
|
||||
|
||||
## ステップ 3 — Brownfield オンボーディングの開始
|
||||
|
||||
プロジェクトを作成する前に、GSD Core にリポジトリ状態を確認させ、安全な次のトップレベルコマンドを表示させます。これにより、コードベースコンテキストの取りこぼしや既存 planning ファイルの上書きを防げます。
|
||||
プロジェクトを作成する前に、MSD Core にリポジトリ状態を確認させ、安全な次のトップレベルコマンドを表示させます。これにより、コードベースコンテキストの取りこぼしや既存 planning ファイルの上書きを防げます。
|
||||
|
||||
```text
|
||||
/gsd-onboard
|
||||
/msd-onboard
|
||||
```
|
||||
|
||||
オンボーディングがコードベースマップ不足を示したら、推奨オプションを選び、表示された `/gsd-map-codebase` ハンドオフを実行してから `/gsd-onboard` を再実行します。`/gsd-onboard --fast` は軽量な初回パスには使えますが、`/gsd-new-project` の前には完全なマップが必要です。`/gsd-map-codebase` が4つの並行マッパーサブエージェントを生成します（「Spawning 4 parallel codebase mapper agents…」という通知が表示されます。1〜5分かかりますので中断しないでください）。各エージェントはそれぞれ異なる観点に注目します:
|
||||
オンボーディングがコードベースマップ不足を示したら、推奨オプションを選び、表示された `/msd-map-codebase` ハンドオフを実行してから `/msd-onboard` を再実行します。`/msd-onboard --fast` は軽量な初回パスには使えますが、`/msd-new-project` の前には完全なマップが必要です。`/msd-map-codebase` が4つの並行マッパーサブエージェントを生成します（「Spawning 4 parallel codebase mapper agents…」という通知が表示されます。1〜5分かかりますので中断しないでください）。各エージェントはそれぞれ異なる観点に注目します:
|
||||
|
||||
| エージェント | 観点 |
|
||||
|-------|-------|
|
||||
@@ -83,9 +83,9 @@ Created .planning/codebase/:
|
||||
- CONCERNS.md (33 lines) - Technical debt and issues
|
||||
```
|
||||
|
||||
`.planning/codebase/STACK.md` を開いてください。GSD Core が検出した言語、ランタイム、フレームワークのバージョン、主要な依存関係が表示されます。これは推測ではなく、実際に読み込んだファイルに基づいています。
|
||||
`.planning/codebase/STACK.md` を開いてください。MSD Core が検出した言語、ランタイム、フレームワークのバージョン、主要な依存関係が表示されます。これは推測ではなく、実際に読み込んだファイルに基づいています。
|
||||
|
||||
`.planning/codebase/CONVENTIONS.md` を開いてください。ソースコードから観察した命名規則、エラーハンドリングパターン、コードスタイルのルールが表示されます。このリポジトリで GSD Core が生成するすべてのプランは、これらの規約に自動的に従います。
|
||||
`.planning/codebase/CONVENTIONS.md` を開いてください。ソースコードから観察した命名規則、エラーハンドリングパターン、コードスタイルのルールが表示されます。このリポジトリで MSD Core が生成するすべてのプランは、これらの規約に自動的に従います。
|
||||
|
||||
`.planning/codebase/CONCERNS.md` を開いてください。新機能の作業前に読む最も有用なファイルです。計画に影響しうる技術的負債や脆弱なエリアが表面化されています。
|
||||
|
||||
@@ -99,15 +99,15 @@ Created .planning/codebase/:
|
||||
/clear
|
||||
```
|
||||
|
||||
`/gsd-onboard` をもう一度実行します。GSD Core が ADR、PRD、spec、RFC、またはルートレベルの要件ドキュメントを検出した場合は、先に推奨される `/gsd-ingest-docs` ハンドオフを実行し、その後 `/gsd-onboard` を再実行してください。コンテキストが整うと、オンボーディングはプロジェクト初期化のハンドオフを表示します:
|
||||
`/msd-onboard` をもう一度実行します。MSD Core が ADR、PRD、spec、RFC、またはルートレベルの要件ドキュメントを検出した場合は、先に推奨される `/msd-ingest-docs` ハンドオフを実行し、その後 `/msd-onboard` を再実行してください。コンテキストが整うと、オンボーディングはプロジェクト初期化のハンドオフを表示します:
|
||||
|
||||
```text
|
||||
/gsd-new-project
|
||||
/msd-new-project
|
||||
```
|
||||
|
||||
前のステップで GSD Core が既存のコードを見つけているため、`/gsd-new-project` はこれがブラウンフィールドプロジェクトだと分かっています。質問は既存のものを再説明するのではなく、*追加する*内容に焦点を当てます:
|
||||
前のステップで MSD Core が既存のコードを見つけているため、`/msd-new-project` はこれがブラウンフィールドプロジェクトだと分かっています。質問は既存のものを再説明するのではなく、*追加する*内容に焦点を当てます:
|
||||
|
||||
GSD Core が何を作りたいかを尋ねます。コードベース全体の説明ではなく、追加する機能で答えてください:
|
||||
MSD Core が何を作りたいかを尋ねます。コードベース全体の説明ではなく、追加する機能で答えてください:
|
||||
|
||||
```text
|
||||
Add a GET /health endpoint to the Express app. It should return
|
||||
@@ -115,7 +115,7 @@ Add a GET /health endpoint to the Express app. It should return
|
||||
health checks.
|
||||
```
|
||||
|
||||
GSD Core が少数の確認質問をした後、要件とロードマップの作成に進みます。すでに `ARCHITECTURE.md` と `STACK.md` を読み込んでいるため、既存の機能を `PROJECT.md` の **Validated** セクションに自動的にマッピングします。既存の API サーフェスを説明する必要はありません。
|
||||
MSD Core が少数の確認質問をした後、要件とロードマップの作成に進みます。すでに `ARCHITECTURE.md` と `STACK.md` を読み込んでいるため、既存の機能を `PROJECT.md` の **Validated** セクションに自動的にマッピングします。既存の API サーフェスを説明する必要はありません。
|
||||
|
||||
すべてのワークフロー設定は推奨デフォルトを選択してください。
|
||||
|
||||
@@ -133,7 +133,7 @@ Proposed Roadmap
|
||||
|
||||
ロードマップを承認してください。
|
||||
|
||||
プロジェクト設定が完了したら、もう一度 `/gsd-onboard` を実行します。`PROJECT.md`、`REQUIREMENTS.md`、`ROADMAP.md`、`STATE.md` がすべて存在するため、オンボーディングは `.planning/onboarding/SUMMARY.md` を作成または確認します。
|
||||
プロジェクト設定が完了したら、もう一度 `/msd-onboard` を実行します。`PROJECT.md`、`REQUIREMENTS.md`、`ROADMAP.md`、`STATE.md` がすべて存在するため、オンボーディングは `.planning/onboarding/SUMMARY.md` を作成または確認します。
|
||||
|
||||
**`.planning/` に作成されるファイル:**
|
||||
|
||||
@@ -148,7 +148,7 @@ Proposed Roadmap
|
||||
codebase/ ← ステップ 3 の7つのマップファイル
|
||||
```
|
||||
|
||||
`.planning/codebase/` はすでにステップ 3 から存在しています。GSD Core は `PROJECT.md` を書く際にこれらのファイルを読み込んでいるため、あなたが説明しなくても Validated 要件を入力できたのです。
|
||||
`.planning/codebase/` はすでにステップ 3 から存在しています。MSD Core は `PROJECT.md` を書く際にこれらのファイルを読み込んでいるため、あなたが説明しなくても Validated 要件を入力できたのです。
|
||||
|
||||
---
|
||||
|
||||
@@ -159,10 +159,10 @@ Proposed Roadmap
|
||||
```
|
||||
|
||||
```text
|
||||
/gsd-discuss-phase 1
|
||||
/msd-discuss-phase 1
|
||||
```
|
||||
|
||||
GSD Core があなたの `CONVENTIONS.md` と `ARCHITECTURE.md` を読み込んでいるため、質問は汎用的なアドバイスではなく、実際のコードベースに基づいています。以下のような内容が表示される場合があります:
|
||||
MSD Core があなたの `CONVENTIONS.md` と `ARCHITECTURE.md` を読み込んでいるため、質問は汎用的なアドバイスではなく、実際のコードベースに基づいています。以下のような内容が表示される場合があります:
|
||||
|
||||
```text
|
||||
> Your routes are registered in src/routes/index.js. Should the health
|
||||
@@ -177,7 +177,7 @@ GSD Core があなたの `CONVENTIONS.md` と `ARCHITECTURE.md` を読み込ん
|
||||
process.uptime() is fine.
|
||||
```
|
||||
|
||||
議論が終了すると、GSD Core が以下のファイルを書き込みます:
|
||||
議論が終了すると、MSD Core が以下のファイルを書き込みます:
|
||||
|
||||
```text
|
||||
.planning/phases/01-health-endpoint/CONTEXT.md
|
||||
@@ -190,7 +190,7 @@ GSD Core があなたの `CONVENTIONS.md` と `ARCHITECTURE.md` を読み込ん
|
||||
## ステップ 6 — フェーズ 1 の計画
|
||||
|
||||
```text
|
||||
/gsd-plan-phase 1
|
||||
/msd-plan-phase 1
|
||||
```
|
||||
|
||||
4つのリサーチサブエージェントが並行して実行されます（1〜5分）。完了すると、プランナーが `CONTEXT.md`、リサーチ結果、コードベースマップを読み込み、あなたの規約に合ったタスクプランを作成します。
|
||||
@@ -204,7 +204,7 @@ GSD Core があなたの `CONVENTIONS.md` と `ARCHITECTURE.md` を読み込ん
|
||||
01-02-PLAN.md ← タスク: src/routes/index.js へのヘルスルートの登録
|
||||
```
|
||||
|
||||
`01-01-PLAN.md` を開いてください。`<files>` タグが `src/routes/health.js` を参照していることに注目してください。これは議論で指定した正確なパスであり、GSD Core がコードベースマップで観察したルーティングパターンと一致しています。これがコードベースマップの効果です。
|
||||
`01-01-PLAN.md` を開いてください。`<files>` タグが `src/routes/health.js` を参照していることに注目してください。これは議論で指定した正確なパスであり、MSD Core がコードベースマップで観察したルーティングパターンと一致しています。これがコードベースマップの効果です。
|
||||
|
||||
---
|
||||
|
||||
@@ -213,21 +213,21 @@ GSD Core があなたの `CONVENTIONS.md` と `ARCHITECTURE.md` を読み込ん
|
||||
コードベースマップ、議論の意思決定記録、検証済みタスクプランが揃ったプロジェクトができました。すべてが実際のコードに基づいています。ここからのワークフローはグリーンフィールドプロジェクトと同じです:
|
||||
|
||||
```text
|
||||
/gsd-execute-phase 1
|
||||
/gsd-verify-work 1
|
||||
/gsd-ship 1
|
||||
/msd-execute-phase 1
|
||||
/msd-verify-work 1
|
||||
/msd-ship 1
|
||||
```
|
||||
|
||||
今後の機能追加ごとに、構造が大幅に変わった際は `/gsd-map-codebase` を再実行してコードベースマップを最新の状態に保ってください。
|
||||
今後の機能追加ごとに、構造が大幅に変わった際は `/msd-map-codebase` を再実行してコードベースマップを最新の状態に保ってください。
|
||||
|
||||
---
|
||||
|
||||
## 学んだこと
|
||||
|
||||
- `/gsd-onboard` が対話型コマンドをネストしたり既存 planning ファイルを上書きしたりせずに、ブラウンフィールド設定を安全に順序付ける仕組み。
|
||||
- `/gsd-map-codebase` が4つの並行エージェントを実行して `.planning/codebase/` に `STACK.md`、`ARCHITECTURE.md`、`CONVENTIONS.md`、`CONCERNS.md`、`STRUCTURE.md`、`TESTING.md`、`INTEGRATIONS.md` を生成する仕組み。
|
||||
- ブラウンフィールドリポジトリで `/gsd-new-project` を実行すると、*追加する*内容に焦点を当てた質問がされ、既存コードから Validated 要件が自動入力される仕組み。
|
||||
- コードベースマップが `/gsd-discuss-phase` のすべての質問を形成する方法 — ファイルパス、パターン、規約が実際のコードから導出される。
|
||||
- `/msd-onboard` が対話型コマンドをネストしたり既存 planning ファイルを上書きしたりせずに、ブラウンフィールド設定を安全に順序付ける仕組み。
|
||||
- `/msd-map-codebase` が4つの並行エージェントを実行して `.planning/codebase/` に `STACK.md`、`ARCHITECTURE.md`、`CONVENTIONS.md`、`CONCERNS.md`、`STRUCTURE.md`、`TESTING.md`、`INTEGRATIONS.md` を生成する仕組み。
|
||||
- ブラウンフィールドリポジトリで `/msd-new-project` を実行すると、*追加する*内容に焦点を当てた質問がされ、既存コードから Validated 要件が自動入力される仕組み。
|
||||
- コードベースマップが `/msd-discuss-phase` のすべての質問を形成する方法 — ファイルパス、パターン、規約が実際のコードから導出される。
|
||||
- プランナーが `CONTEXT.md` と `CONVENTIONS.md` を読み込んでリポジトリのスタイルに合ったプランを生成する仕組み。
|
||||
|
||||
---
|
||||
@@ -235,5 +235,5 @@ GSD Core があなたの `CONVENTIONS.md` と `ARCHITECTURE.md` を読み込ん
|
||||
## Related
|
||||
|
||||
- [はじめてのプロジェクト](your-first-project.md) — インストールから PR まで完全なグリーンフィールドループ
|
||||
- [コマンドによるコードベースマッピング](../COMMANDS.md) — `/gsd-map-codebase` のすべてのフラグとサブコマンド
|
||||
- [コマンドによるコードベースマッピング](../COMMANDS.md) — `/msd-map-codebase` のすべてのフラグとサブコマンド
|
||||
- [ドキュメントインデックス](../README.md)
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# はじめてのプロジェクト
|
||||
|
||||
このチュートリアルでは、GSD Core をインストールし、シンプルなコマンドライン To-Do アプリをゼロから作成します。1フェーズ、1プルリクエスト、完全なループを体験します。終わる頃には、コアフェーズループのすべてのコマンドを少なくとも一度は実行し、各コマンドが生成する計画アーティファクトを確認しているはずです。
|
||||
このチュートリアルでは、MSD Core をインストールし、シンプルなコマンドライン To-Do アプリをゼロから作成します。1フェーズ、1プルリクエスト、完全なループを体験します。終わる頃には、コアフェーズループのすべてのコマンドを少なくとも一度は実行し、各コマンドが生成する計画アーティファクトを確認しているはずです。
|
||||
|
||||
---
|
||||
|
||||
@@ -16,16 +16,16 @@ To-Do アイテムをローカルの JSON ファイルに保存し、追加・
|
||||
- **Claude Code** — 使用するプロジェクトディレクトリで開いていること。
|
||||
- 初回インストール用のインターネット接続。
|
||||
|
||||
他のツールは不要です。GSD Core 自体は次のステップでインストールします。
|
||||
他のツールは不要です。MSD Core 自体は次のステップでインストールします。
|
||||
|
||||
---
|
||||
|
||||
## ステップ 1 — GSD Core のインストール
|
||||
## ステップ 1 — MSD Core のインストール
|
||||
|
||||
プロジェクトディレクトリでターミナルを開き、以下を実行します:
|
||||
|
||||
```bash
|
||||
npx @opengsd/gsd-core@latest
|
||||
npx @golem15/msd-core@latest
|
||||
```
|
||||
|
||||
インストーラーが、使用している AI コーディングランタイムとグローバルインストールかカレントプロジェクトへのインストールかを確認します。今は **Claude Code** と **local**（このプロジェクトのみ）を選択してください。
|
||||
@@ -35,10 +35,10 @@ npx @opengsd/gsd-core@latest
|
||||
```text
|
||||
✓ Installed 86 skills to .claude/commands/
|
||||
✓ Installed agents to .claude/agents/
|
||||
✓ GSD Core ready — run /gsd-new-project to start
|
||||
✓ MSD Core ready — run /msd-new-project to start
|
||||
```
|
||||
|
||||
プロジェクト内に `.claude/` ディレクトリが作成されます。これが GSD Core のコマンドとエージェントの格納場所です。
|
||||
プロジェクト内に `.claude/` ディレクトリが作成されます。これが MSD Core のコマンドとエージェントの格納場所です。
|
||||
|
||||
> ローカルとグローバルの違いについて: ローカルインストールはスキルのバージョンをこのプロジェクトに固定します。グローバルインストールを行う場合は、[ランタイムへのインストール](../how-to/install-on-your-runtime.md) を参照してください。
|
||||
|
||||
@@ -46,7 +46,7 @@ npx @opengsd/gsd-core@latest
|
||||
|
||||
## ステップ 2 — 権限フラグ付きで Claude Code を起動
|
||||
|
||||
GSD Core は、ファイルの読み書きを行うサブエージェントを生成します。すべてのファイル操作に対して確認を求められないよう、権限フラグを付けて Claude Code を起動してください:
|
||||
MSD Core は、ファイルの読み書きを行うサブエージェントを生成します。すべてのファイル操作に対して確認を求められないよう、権限フラグを付けて Claude Code を起動してください:
|
||||
|
||||
```bash
|
||||
claude --dangerously-skip-permissions
|
||||
@@ -61,10 +61,10 @@ claude --dangerously-skip-permissions
|
||||
Claude Code のプロンプトで以下のスラッシュコマンドを入力します:
|
||||
|
||||
```text
|
||||
/gsd-new-project
|
||||
/msd-new-project
|
||||
```
|
||||
|
||||
GSD Core が会話を開始し、最初に1つの質問をします:
|
||||
MSD Core が会話を開始し、最初に1つの質問をします:
|
||||
|
||||
```text
|
||||
What do you want to build?
|
||||
@@ -78,13 +78,13 @@ A Node.js CLI tool for managing to-do items. Users run `todo add "buy milk"`,
|
||||
No external dependencies — Node built-ins only.
|
||||
```
|
||||
|
||||
GSD Core がいくつかの確認事項について質問します。自然に答えてください。1つのプランも書く前に、あなたの意図を理解しようとしています。
|
||||
MSD Core がいくつかの確認事項について質問します。自然に答えてください。1つのプランも書く前に、あなたの意図を理解しようとしています。
|
||||
|
||||
質問が終わると、ドメインリサーチの実行を提案します。この規模のプロジェクトであればリサーチをスキップできます。プロンプトが表示されたら **Skip research** を選択してください。
|
||||
|
||||
次に GSD Core がワークフロー設定（モード、粒度、リサーチエージェント）を選択するよう求めます。それぞれ推奨デフォルトを選択してください。これらの設定は `.planning/config.json` に書き込まれます。
|
||||
次に MSD Core がワークフロー設定（モード、粒度、リサーチエージェント）を選択するよう求めます。それぞれ推奨デフォルトを選択してください。これらの設定は `.planning/config.json` に書き込まれます。
|
||||
|
||||
最後に、ロードマッパーのサブエージェントが実行されます（「Spawning roadmapper…」という通知が表示されますが、これは正常です。約1分かかります）。完了すると、GSD Core が提案するロードマップを提示します。単一フェーズのプロジェクトでは次のようになります:
|
||||
最後に、ロードマッパーのサブエージェントが実行されます（「Spawning roadmapper…」という通知が表示されますが、これは正常です。約1分かかります）。完了すると、MSD Core が提案するロードマップを提示します。単一フェーズのプロジェクトでは次のようになります:
|
||||
|
||||
```text
|
||||
Proposed Roadmap
|
||||
@@ -115,7 +115,7 @@ Proposed Roadmap
|
||||
|
||||
## ステップ 4 — コンテキストをクリアしてフェーズ 1 を議論
|
||||
|
||||
GSD Core はフレッシュなコンテキストを前提に設計されています。各フェーズの前にメインセッションウィンドウをクリアしてください:
|
||||
MSD Core はフレッシュなコンテキストを前提に設計されています。各フェーズの前にメインセッションウィンドウをクリアしてください:
|
||||
|
||||
```text
|
||||
/clear
|
||||
@@ -124,10 +124,10 @@ GSD Core はフレッシュなコンテキストを前提に設計されてい
|
||||
次に、フェーズ 1 の議論を開始します:
|
||||
|
||||
```text
|
||||
/gsd-discuss-phase 1
|
||||
/msd-discuss-phase 1
|
||||
```
|
||||
|
||||
GSD Core がフェーズのゴールを読み取り、実装の方針について質問します。これは「何を」作るかではなく、「どのように」作るかを決める質問です。会話の例:
|
||||
MSD Core がフェーズのゴールを読み取り、実装の方針について質問します。これは「何を」作るかではなく、「どのように」作るかを決める質問です。会話の例:
|
||||
|
||||
```text
|
||||
> How should done items be stored — mark them in place or move them?
|
||||
@@ -140,7 +140,7 @@ GSD Core がフェーズのゴールを読み取り、実装の方針につい
|
||||
Create it silently on first add.
|
||||
```
|
||||
|
||||
議論が終了すると、GSD Core が以下のファイルを書き込みます:
|
||||
議論が終了すると、MSD Core が以下のファイルを書き込みます:
|
||||
|
||||
```text
|
||||
.planning/phases/01-core-cli/CONTEXT.md
|
||||
@@ -153,7 +153,7 @@ GSD Core がフェーズのゴールを読み取り、実装の方針につい
|
||||
## ステップ 5 — フェーズ 1 の計画
|
||||
|
||||
```text
|
||||
/gsd-plan-phase 1
|
||||
/msd-plan-phase 1
|
||||
```
|
||||
|
||||
4つのリサーチサブエージェントが並行して実行されます（「Spawning 4 researchers…」という通知が表示されます。1〜5分かかります。中断しないでください）。
|
||||
@@ -169,17 +169,17 @@ GSD Core がフェーズのゴールを読み取り、実装の方針につい
|
||||
01-02-PLAN.md ← タスク: add / list / done コマンドの実装
|
||||
```
|
||||
|
||||
`01-01-PLAN.md` を開いてください。タスク名、対象ファイル、アクションステップ、検証コマンド、完了条件が含まれた `<task>` ブロックがあります。`<verify>` タグに注目してください。GSD Core のエグゼキューターはコードを書いた後にそのコマンドを実行します。
|
||||
`01-01-PLAN.md` を開いてください。タスク名、対象ファイル、アクションステップ、検証コマンド、完了条件が含まれた `<task>` ブロックがあります。`<verify>` タグに注目してください。MSD Core のエグゼキューターはコードを書いた後にそのコマンドを実行します。
|
||||
|
||||
---
|
||||
|
||||
## ステップ 6 — フェーズ 1 の実行
|
||||
|
||||
```text
|
||||
/gsd-execute-phase 1
|
||||
/msd-execute-phase 1
|
||||
```
|
||||
|
||||
GSD Core はプランをウェーブ（独立したプランが並行実行される単位）にグループ化し、プランごとに新しい 200k コンテキストのエグゼキューターを生成し、各タスクをアトミックにコミットします。
|
||||
MSD Core はプランをウェーブ（独立したプランが並行実行される単位）にグループ化し、プランごとに新しい 200k コンテキストのエグゼキューターを生成し、各タスクをアトミックにコミットします。
|
||||
|
||||
以下のような出力が表示されます:
|
||||
|
||||
@@ -215,17 +215,17 @@ node todo.js done 1
|
||||
node todo.js list
|
||||
```
|
||||
|
||||
アイテムが表示され、完了マークを付けた後にアイテム 1 がデフォルトリストから消えているはずです。これが GSD Core によって実現された最初の成果です。
|
||||
アイテムが表示され、完了マークを付けた後にアイテム 1 がデフォルトリストから消えているはずです。これが MSD Core によって実現された最初の成果です。
|
||||
|
||||
---
|
||||
|
||||
## ステップ 7 — 成果物の検証
|
||||
|
||||
```text
|
||||
/gsd-verify-work 1
|
||||
/msd-verify-work 1
|
||||
```
|
||||
|
||||
GSD Core がフェーズの成功基準を抽出し、それぞれについて確認します:
|
||||
MSD Core がフェーズの成功基準を抽出し、それぞれについて確認します:
|
||||
|
||||
```text
|
||||
[1/3] Can you run `node todo.js add "buy milk"` without errors?
|
||||
@@ -240,7 +240,7 @@ GSD Core がフェーズの成功基準を抽出し、それぞれについて
|
||||
All 3 checks passed. Phase 1 verified.
|
||||
```
|
||||
|
||||
いずれかのチェックが失敗した場合、GSD Core が根本原因を診断して修正プランを作成します。`/gsd-execute-phase 1` を再度実行して修正を適用し、その後 `/gsd-verify-work 1` を再実行してください。
|
||||
いずれかのチェックが失敗した場合、MSD Core が根本原因を診断して修正プランを作成します。`/msd-execute-phase 1` を再度実行して修正を適用し、その後 `/msd-verify-work 1` を再実行してください。
|
||||
|
||||
**作成されるファイル:**
|
||||
|
||||
@@ -253,10 +253,10 @@ All 3 checks passed. Phase 1 verified.
|
||||
## ステップ 8 — リリース
|
||||
|
||||
```text
|
||||
/gsd-ship 1
|
||||
/msd-ship 1
|
||||
```
|
||||
|
||||
GSD Core が自動生成された本文付きのプルリクエストを作成します。PR の本文には常に Summary、Changes、Requirements Addressed、Verification、Key Decisions が含まれます。
|
||||
MSD Core が自動生成された本文付きのプルリクエストを作成します。PR の本文には常に Summary、Changes、Requirements Addressed、Verification、Key Decisions が含まれます。
|
||||
|
||||
以下のような出力が表示されます:
|
||||
|
||||
@@ -272,15 +272,15 @@ Title: feat(phase-1): core CLI — add / list / done commands
|
||||
|
||||
## 学んだこと
|
||||
|
||||
- `npx @opengsd/gsd-core@latest` を使った GSD Core のインストール方法。
|
||||
- `/gsd-new-project` が会話を `.planning/` アーティファクトに裏付けられたロードマップに変換する仕組み。
|
||||
- `/gsd-discuss-phase` が計画前に実装の意思決定を記録する仕組み。
|
||||
- `/gsd-plan-phase` が並行リサーチャーを生成してアトミックなタスクプランを作成する仕組み。
|
||||
- `/gsd-execute-phase` がプランを並行ウェーブで実行し各タスクをコミットする仕組み。
|
||||
- `/gsd-verify-work` が成功基準を確認し、必要に応じて修正プランを生成する仕組み。
|
||||
- `/gsd-ship` が検証済みフェーズをプルリクエストに変換する仕組み。
|
||||
- `npx @golem15/msd-core@latest` を使った MSD Core のインストール方法。
|
||||
- `/msd-new-project` が会話を `.planning/` アーティファクトに裏付けられたロードマップに変換する仕組み。
|
||||
- `/msd-discuss-phase` が計画前に実装の意思決定を記録する仕組み。
|
||||
- `/msd-plan-phase` が並行リサーチャーを生成してアトミックなタスクプランを作成する仕組み。
|
||||
- `/msd-execute-phase` がプランを並行ウェーブで実行し各タスクをコミットする仕組み。
|
||||
- `/msd-verify-work` が成功基準を確認し、必要に応じて修正プランを生成する仕組み。
|
||||
- `/msd-ship` が検証済みフェーズをプルリクエストに変換する仕組み。
|
||||
|
||||
マルチフェーズプロジェクトの場合は、各フェーズでステップ 4〜8 を繰り返し、`/gsd-progress --next` を実行して GSD Core に次のステップを自動検出させてください。
|
||||
マルチフェーズプロジェクトの場合は、各フェーズでステップ 4〜8 を繰り返し、`/msd-progress --next` を実行して MSD Core に次のステップを自動検出させてください。
|
||||
|
||||
---
|
||||
|
||||
@@ -288,4 +288,4 @@ Title: feat(phase-1): core CLI — add / list / done commands
|
||||
|
||||
- [フェーズループ](../explanation/the-phase-loop.md) — ループがこの形状である理由
|
||||
- [ハウツーガイド](../README.md#how-to-guides) — 特定の状況に対応したタスク重視のレシピ
|
||||
- [既存コードベースのオンボーディング](onboarding-an-existing-codebase.md) — ブラウンフィールドリポジトリへの GSD Core の導入
|
||||
- [既存コードベースのオンボーディング](onboarding-an-existing-codebase.md) — ブラウンフィールドリポジトリへの MSD Core の導入
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# ディスカッションモード：仮定 vs インタビュー
|
||||
|
||||
GSD Core のディスカッションフェーズは、計画を開始する前に実装コンテキストを収集するための 2 つのモードを提供します。どちらを使用するかを理解することで、質疑応答から確定した `CONTEXT.md` へとより少ない往復でたどり着けます。
|
||||
MSD Core のディスカッションフェーズは、計画を開始する前に実装コンテキストを収集するための 2 つのモードを提供します。どちらを使用するかを理解することで、質疑応答から確定した `CONTEXT.md` へとより少ない往復でたどり着けます。
|
||||
|
||||
どちらのモードを実行するかのステップバイステップの手順については、[フェーズ議論の how-to](how-to/discuss-a-phase.md) を参照してください。
|
||||
|
||||
@@ -26,10 +26,10 @@ GSD Core のディスカッションフェーズは、計画を開始する前
|
||||
|
||||
```bash
|
||||
# assumptions モードを有効にする
|
||||
node gsd-tools.cjs config-set workflow.discuss_mode assumptions
|
||||
node msd-tools.cjs config-set workflow.discuss_mode assumptions
|
||||
|
||||
# インタビューモードに戻す
|
||||
node gsd-tools.cjs config-set workflow.discuss_mode discuss
|
||||
node msd-tools.cjs config-set workflow.discuss_mode discuss
|
||||
```
|
||||
|
||||
この設定はプロジェクトごとです（`.planning/config.json` に保存されます）。両方のモードが生成するファイルの完全な構造については、[CONTEXT.md スキーマ](reference/context-md.md) を参照してください。
|
||||
@@ -69,7 +69,7 @@ node gsd-tools.cjs config-set workflow.discuss_mode discuss
|
||||
|
||||
## Related
|
||||
|
||||
- [フェーズの議論](how-to/discuss-a-phase.md) — どちらのモードでも `/gsd-discuss-phase` を実行するためのステップバイステップの how-to。
|
||||
- [フェーズの議論](how-to/discuss-a-phase.md) — どちらのモードでも `/msd-discuss-phase` を実行するためのステップバイステップの how-to。
|
||||
- [CONTEXT.md スキーマ](reference/context-md.md) — 両方のモードが生成するファイルの完全なフィールドリファレンス。
|
||||
- [フェーズループ](explanation/the-phase-loop.md) — discuss がより広い discuss → plan → execute → verify → ship サイクルにどう組み込まれるか。
|
||||
- [ドキュメント索引](README.md) — GSD Core ドキュメントの完全な目次。
|
||||
- [ドキュメント索引](README.md) — MSD Core ドキュメントの完全な目次。
|
||||
|
||||
Reference in New Issue
Block a user