mirror of
https://github.com/glittercowboy/get-shit-done
synced 2026-04-25 17:25:23 +02:00
docs: update localized documentation for v1.32.0 release
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
@@ -1,6 +1,6 @@
|
||||
# GSD エージェントリファレンス
|
||||
|
||||
> 全18種の専門エージェント — 役割、ツール、スポーンパターン、相互関係。アーキテクチャの詳細は[アーキテクチャ](ARCHITECTURE.md)を参照してください。
|
||||
> 全18種の専門エージェント(v1.32 現在) — 役割、ツール、スポーンパターン、相互関係。アーキテクチャの詳細は[アーキテクチャ](ARCHITECTURE.md)を参照してください。
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -21,7 +21,7 @@
|
||||
|
||||
## システム概要
|
||||
|
||||
GSDは、ユーザーとAIコーディングエージェント(Claude Code、Gemini CLI、OpenCode、Kilo、Codex、Copilot、Antigravity)の間に位置する**メタプロンプティングフレームワーク**です。以下の機能を提供します:
|
||||
GSDは、ユーザーとAIコーディングエージェント(Claude Code、Gemini CLI、OpenCode、Kilo、Codex、Copilot、Antigravity、Trae、Cline、Augment Code)の間に位置する**メタプロンプティングフレームワーク**です。以下の機能を提供します:
|
||||
|
||||
1. **コンテキストエンジニアリング** — タスクごとにAIが必要とするすべてを提供する構造化アーティファクト
|
||||
2. **マルチエージェントオーケストレーション** — 専門エージェントをフレッシュなコンテキストウィンドウで起動する軽量オーケストレーター
|
||||
|
||||
@@ -101,6 +101,8 @@
|
||||
| `--auto` | すべての質問で推奨デフォルトを自動選択 |
|
||||
| `--batch` | 質問を一つずつではなくバッチ取り込みでグループ化 |
|
||||
| `--analyze` | ディスカッション中にトレードオフ分析を追加 |
|
||||
| `--chain` | discuss → plan → execute を1つのフローで自動チェーン (v1.31) |
|
||||
| `--power` | 準備済み回答ファイルから一括入力で質問に回答 (v1.32) |
|
||||
|
||||
**前提条件:** `.planning/ROADMAP.md` が存在すること
|
||||
**生成物:** `{phase}-CONTEXT.md`、`{phase}-DISCUSSION-LOG.md`(監査証跡)
|
||||
@@ -482,7 +484,21 @@
|
||||
- 1つのターミナルから複数フェーズの作業を並列化するパワーユーザー向け
|
||||
|
||||
```bash
|
||||
/gsd-manager # コマンドセンターダッシュボードを開く
|
||||
/gsd-manager # コ<EFBFBD><EFBFBD>ンドセンターダッシュボードを開く
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### `/gsd-analyze-dependencies`
|
||||
|
||||
フェーズ依存関係を検出し、ROADMAP.md に `Depends on` エントリを提案します。(v1.32)
|
||||
|
||||
**前提<E5898D><E68F90><EFBFBD>件:** `.planning/ROADMAP.md` が存在すること
|
||||
**検出方法:** ファイルオーバーラップ、セマンティック依存関係(API/スキーマのプロデューサーとコンシューマー)、データフロー依存関係
|
||||
**動作:** 依存関係提案テーブルを表示し、ユーザー確認後に ROADMAP.md の `Depends on` フィールドを更新します。
|
||||
|
||||
```bash
|
||||
/gsd-analyze-dependencies # 依存関係の分析と提案
|
||||
```
|
||||
|
||||
---
|
||||
@@ -525,10 +541,16 @@ GSDの保証付きでアドホックタスクを実行します。
|
||||
| フラグ | 説明 |
|
||||
|------|-------------|
|
||||
| `--from N` | 特定のフェーズ番号から開始 |
|
||||
| `--to N` | フェーズ N 完了後に自律実行を停止 (v1.32) |
|
||||
| `--only N` | 指定された単一フェーズのみを自律的に実行 (v1.31) |
|
||||
| `--interactive` | 各フェーズのディスカスステップでユーザー確認を要求 |
|
||||
|
||||
```bash
|
||||
/gsd-autonomous # 残りの全フェーズを実行
|
||||
/gsd-autonomous --from 3 # フェーズ3から開始
|
||||
/gsd-autonomous --to 5 # フェーズ5まで実行
|
||||
/gsd-autonomous --from 3 --to 5 # フェーズ3〜5の範囲を実行
|
||||
/gsd-autonomous --only 4 # フェーズ4のみを自律実行
|
||||
```
|
||||
|
||||
### `/gsd-do`
|
||||
@@ -567,8 +589,13 @@ GSDの保証付きでアドホックタスクを実行します。
|
||||
|----------|----------|-------------|
|
||||
| `description` | いいえ | バグの説明 |
|
||||
|
||||
| フラグ | 説明 |
|
||||
|------|-------------|
|
||||
| `--diagnose` | 修正を試みず調査のみを行う診断専用モード (v1.32) |
|
||||
|
||||
```bash
|
||||
/gsd-debug "Login button not responding on mobile Safari"
|
||||
/gsd-debug --diagnose "API returning 500 on /users endpoint"
|
||||
```
|
||||
|
||||
### `/gsd-add-todo`
|
||||
|
||||
@@ -33,7 +33,8 @@ GSD はプロジェクト設定を `.planning/config.json` に保存します。
|
||||
"research_before_questions": false,
|
||||
"discuss_mode": "discuss",
|
||||
"skip_discuss": false,
|
||||
"text_mode": false
|
||||
"text_mode": false,
|
||||
"use_worktrees": true
|
||||
},
|
||||
"hooks": {
|
||||
"context_warnings": true,
|
||||
@@ -100,6 +101,7 @@ GSD はプロジェクト設定を `.planning/config.json` に保存します。
|
||||
| `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.text_mode` | boolean | `false` | AskUserQuestion の TUI メニューをプレーンテキストの番号付きリストに置き換えます。TUI メニューが表示されない Claude Code リモートセッション(`/rc` モード)で必要です。discuss-phase で `--text` フラグを使用してセッションごとに設定することもできます。v1.28 で追加 |
|
||||
@@ -228,7 +230,27 @@ quick タスクのブランチ設定例:
|
||||
| 設定 | 型 | デフォルト | 説明 |
|
||||
|------|-----|-----------|------|
|
||||
| `safety.always_confirm_destructive` | boolean | `true` | 破壊的操作(削除、上書き)の確認 |
|
||||
| `safety.always_confirm_external_services` | boolean | `true` | 外部サービスとのやり取りの確認 |
|
||||
| `safety.always_confirm_external_services` | boolean | `true` | 外部サービ<EFBFBD><EFBFBD>とのやり取りの確認 |
|
||||
|
||||
---
|
||||
|
||||
## セキュリティ設定 (v1.31)
|
||||
|
||||
| 設定 | 型 | <20><>フォルト | 説明 |
|
||||
|------|-----|-----------|------|
|
||||
| `security_enforcement` | boolean | `true` | 脅威モデルセキュリティ検証を有効化 |
|
||||
| `security_asvs_level` | number (1-3) | `1` | OWASP ASVS 検証レベル |
|
||||
| `security_block_on` | string | `"high"` | フェーズ進行をブロックする最小重大度 |
|
||||
|
||||
---
|
||||
|
||||
## レスポンス言語設定 (v1.32)
|
||||
|
||||
| 設定 | 型 | デフォルト | 説明 |
|
||||
|------|-----|-----------|------|
|
||||
| `response_language` | string | (なし) | エージェントレスポンスの言語コード(例: `"pt"`、`"ko"`、`"ja"`) |
|
||||
|
||||
`response_language` が設定されると、すべてのフェーズおよびスポーンされたエージェントで一貫した言語出力が保証されます。
|
||||
|
||||
---
|
||||
|
||||
@@ -330,6 +352,7 @@ GSD が非 Claude ランタイム向けにインストールされると、イ
|
||||
| `CLAUDE_CONFIG_DIR` | デフォルトの設定ディレクトリ(`~/.claude/`)をオーバーライド |
|
||||
| `GEMINI_API_KEY` | コンテキストモニターがフックイベント名を切り替えるために検出 |
|
||||
| `WSL_DISTRO_NAME` | インストーラーが WSL のパス処理のために検出 |
|
||||
| `GSD_SKIP_SCHEMA_CHECK` | スキーマドリフト検出をバイパス (v1.31) |
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -70,6 +70,40 @@
|
||||
- [Assumptions ディスカッションモード](#53-assumptions-ディスカッションモード)
|
||||
- [UI フェーズ自動検出](#54-ui-フェーズ自動検出)
|
||||
- [マルチランタイムインストーラー選択](#55-マルチランタイムインストーラー選択)
|
||||
- [v1.29 の機能](#v129-の機能)
|
||||
- [Windsurf ランタイムサポート](#56-windsurf-ランタイムサポート)
|
||||
- [国際化ドキュメント](#57-国際化ドキュメント)
|
||||
- [v1.30 の機能](#v130-の機能)
|
||||
- [GSD SDK](#58-gsd-sdk)
|
||||
- [v1.31 の機能](#v131-の機能)
|
||||
- [スキーマドリフト検出](#59-スキーマドリフト検出)
|
||||
- [セキュリティエンフォースメント](#60-セキュリティエンフォースメント)
|
||||
- [ドキュメント生成](#61-ドキュメント生成)
|
||||
- [ディスカスチェーンモード](#62-ディスカスチェーンモード)
|
||||
- [単一フェーズ自律モード](#63-単一フェーズ自律モード)
|
||||
- [スコープ削減検出](#64-スコープ削減検出)
|
||||
- [クレーム出所タグ付け](#65-クレーム出所タグ付け)
|
||||
- [Worktree トグル](#66-worktree-トグル)
|
||||
- [プロジェクトコードプレフィックス](#67-プロジェクトコードプレフィックス)
|
||||
- [Claude Code スキルマイグレーション](#68-claude-code-スキルマイグレーション)
|
||||
- [v1.32 の機能](#v132-の機能)
|
||||
- [STATE.md 整合性ゲート](#69-statemd-整合性ゲート)
|
||||
- [自律モード `--to N` フラグ](#70-自律モード---to-n-フラグ)
|
||||
- [リサーチゲート](#71-リサーチゲート)
|
||||
- [ベリファイヤーマイルストーンスコープフィルタリング](#72-ベリファイヤーマイルストーンスコープフィルタリング)
|
||||
- [Read-Before-Edit ガードフック](#73-read-before-edit-ガードフック)
|
||||
- [コンテキスト削減](#74-コンテキスト削減)
|
||||
- [ディスカスフェーズ `--power` フラグ](#75-ディスカスフェーズ---power-フラグ)
|
||||
- [デバッグ `--diagnose` フラグ](#76-デバッグ---diagnose-フラグ)
|
||||
- [フェーズ依存関係分析](#77-フェーズ依存関係分析)
|
||||
- [アンチパターン重大度レベル](#78-アンチパターン重大度レベル)
|
||||
- [メソドロジーアーティファクトタイプ](#79-メソドロジーアーティファクトタイプ)
|
||||
- [プランナー到達可能性チェック](#80-プランナー到達可能性チェック)
|
||||
- [Playwright-MCP UI 検証](#81-playwright-mcp-ui-検証)
|
||||
- [Pause-Work 拡張](#82-pause-work-拡張)
|
||||
- [レスポンス言語設定](#83-レスポンス言語設定)
|
||||
- [手動アップデート手順](#84-手動アップデート手順)
|
||||
- [新規ランタイムサポート (Trae, Cline, Augment Code)](#85-新規ランタイムサポート-trae-cline-augment-code)
|
||||
|
||||
---
|
||||
|
||||
@@ -1288,3 +1322,522 @@ Claude が GSD ワークフローコンテキスト外でファイル編集を
|
||||
1. **検出** — システム上で利用可能な AI CLI ランタイムを特定
|
||||
2. **プロンプト** — ランタイム選択のためのマルチセレクトインターフェースを提示
|
||||
3. **インストール** — 1回のセッションで選択されたすべてのランタイムに対して GSD を設定
|
||||
|
||||
---
|
||||
|
||||
## v1.29 の機能
|
||||
|
||||
### 56. Windsurf ランタイムサポート
|
||||
|
||||
**対象:** `npx get-shit-done-cc`
|
||||
|
||||
**目的:** Windsurf AI IDE のサポートを追加します。
|
||||
|
||||
**要件:**
|
||||
- REQ-WINDSURF-01: インストーラーは `--windsurf` フラグによる Windsurf インストールをサポートしなければならない
|
||||
- REQ-WINDSURF-02: Windsurf ルール形式に対応したプロンプトファイルを生成しなければならない
|
||||
|
||||
**プロセス:**
|
||||
1. **検出** — Windsurf のインストール状態を確認
|
||||
2. **変換** — GSD プロンプトを Windsurf ルール形式に変換
|
||||
3. **インストール** — Windsurf 設定ディレクトリに GSD を設定
|
||||
|
||||
---
|
||||
|
||||
### 57. 国際化ドキュメント
|
||||
|
||||
**対象:** `docs/` ディレクトリ
|
||||
|
||||
**目的:** GSD ドキュメントをポルトガル語、韓国語、日本語で提供します。
|
||||
|
||||
**要件:**
|
||||
- REQ-I18N-01: ドキュメントはポルトガル語(pt)、韓国語(ko)、日本語(ja)で提供されなければならない
|
||||
- REQ-I18N-02: 翻訳は英語のソースドキュメントと同期を維持しなければならない
|
||||
|
||||
**プロセス:**
|
||||
1. **翻訳** — コアドキュメントを対象言語に変換
|
||||
2. **公開** — 翻訳されたドキュメントを英語版と並んでアクセス可能にする
|
||||
|
||||
---
|
||||
|
||||
## v1.30 の機能
|
||||
|
||||
### 58. GSD SDK
|
||||
|
||||
**コマンド:** プログラマティック API(ヘッドレス)
|
||||
|
||||
**目的:** CLI セッションなしでプログラムから GSD ワークフローを実行するためのヘッドレス TypeScript SDK。
|
||||
|
||||
**要件:**
|
||||
- REQ-SDK-01: SDK は GSD ワークフロー操作を TypeScript 関数として公開しなければならない
|
||||
- REQ-SDK-02: SDK はインタラクティブプロンプトなしのヘッドレス実行をサポートしなければならない
|
||||
- REQ-SDK-03: SDK は CLI 駆動ワークフローと同一のアーティファクトを生成しなければならない
|
||||
|
||||
**プロセス:**
|
||||
1. **インポート** — GSD SDK を TypeScript/JavaScript プロジェクトにインポート
|
||||
2. **設定** — プロジェクトパスとワークフローオプションをプログラムから設定
|
||||
3. **実行** — API コールで GSD フェーズ(discuss、plan、execute)を実行
|
||||
|
||||
---
|
||||
|
||||
## v1.31 の機能
|
||||
|
||||
### 59. スキーマドリフト検出
|
||||
|
||||
**コマンド:** `/gsd-execute-phase` 実行時に自動
|
||||
|
||||
**目的:** ORM スキーマファイルが対応するマイグレーションまたは push コマンドなしに変更された場合を検出し、誤検知の検証を防止します。
|
||||
|
||||
**要件:**
|
||||
- REQ-SCHEMA-01: システムは ORM スキーマファイル(Prisma、Drizzle、Payload、Sanity、Mongoose)の変更を検出しなければならない
|
||||
- REQ-SCHEMA-02: スキーマ変更が検出された場合、対応するマイグレーション/push コマンドの存在を確認しなければならない
|
||||
- REQ-SCHEMA-03: 二層防御を実装しなければならない: 計画時注入と実行時ゲート
|
||||
- REQ-SCHEMA-04: 検出をオーバーライドする `GSD_SKIP_SCHEMA_CHECK` 環境変数をサポートしなければならない
|
||||
- REQ-SCHEMA-05: マイグレーションなしのスキーマ変更時に誤検知の検証を防止しなければならない
|
||||
|
||||
**プロセス:**
|
||||
1. **検出** — 計画実行中の ORM スキーマファイルの変更を監視
|
||||
2. **確認** — 計画に対応するマイグレーション/push コマンドが含まれていることを確認
|
||||
3. **ゲート** — マイグレーションなしのスキーマドリフトが検出された場合、実行をブロック(実行時ゲート)
|
||||
4. **注入** — 計画生成中にマイグレーションリマインダーを追加(計画時注入)
|
||||
|
||||
**設定:** `GSD_SKIP_SCHEMA_CHECK` 環境変数で検出をバイパス。
|
||||
|
||||
---
|
||||
|
||||
### 60. セキュリティエンフォースメント
|
||||
|
||||
**コマンド:** `/gsd-secure-phase <N>`
|
||||
|
||||
**目的:** フェーズ実装に対する脅威モデルアンカードのセキュリティ検証。
|
||||
|
||||
**要件:**
|
||||
- REQ-SEC-01: システムは脅威モデルアンカードの検証(ブラインドスキャンではない)を実行しなければならない
|
||||
- REQ-SEC-02: 設定可能な OWASP ASVS 検証レベル(1-3)をサポートしなければならない
|
||||
- REQ-SEC-03: 設定可能な重大度しきい値に基づいてフェーズ進行をブロックしなければならない
|
||||
- REQ-SEC-04: 分析のために `gsd-security-auditor` エージェントを起動しなければならない
|
||||
|
||||
**生成物:**
|
||||
| 成果物 | 説明 |
|
||||
|--------|------|
|
||||
| セキュリティ監査レポート | 重大度分類付きの脅威モデルアンカードの発見事項 |
|
||||
|
||||
**プロセス:**
|
||||
1. **モデル** — フェーズ実装コンテキストから脅威モデルを構築
|
||||
2. **監査** — `gsd-security-auditor` を起動して脅威モデルに対して検証
|
||||
3. **ゲート** — 発見事項が `security_block_on` 重大度以上の場合、フェーズ進行をブロック
|
||||
|
||||
**設定:**
|
||||
| 設定 | 型 | デフォルト | 説明 |
|
||||
|------|-----|-----------|------|
|
||||
| `security_enforcement` | boolean | `true` | 脅威モデルセキュリティ検証を有効化 |
|
||||
| `security_asvs_level` | number (1-3) | `1` | OWASP ASVS 検証レベル |
|
||||
| `security_block_on` | string | `"high"` | フェーズ進行をブロックする最小重大度 |
|
||||
|
||||
---
|
||||
|
||||
### 61. ドキュメント生成
|
||||
|
||||
**コマンド:** `/gsd-docs-update`
|
||||
|
||||
**目的:** 正確性チェック付きのプロジェクトドキュメントを生成・検証します。
|
||||
|
||||
**要件:**
|
||||
- REQ-DOCS-01: システムはドキュメント生成のために `gsd-doc-writer` エージェントを起動しなければならない
|
||||
- REQ-DOCS-02: システムは正確性チェックのために `gsd-doc-verifier` エージェントを起動しなければならない
|
||||
- REQ-DOCS-03: システムは生成されたドキュメントを実際の実装に対して検証しなければならない
|
||||
|
||||
**生成物:**
|
||||
| 成果物 | 説明 |
|
||||
|--------|------|
|
||||
| 更新されたプロジェクトドキュメント | 生成および検証されたドキュメントファイル |
|
||||
|
||||
**プロセス:**
|
||||
1. **生成** — `gsd-doc-writer` を起動して実装からドキュメントを作成・更新
|
||||
2. **検証** — `gsd-doc-verifier` を起動してコードベースに対するドキュメント正確性をチェック
|
||||
3. **出力** — 正確性アノテーション付きの検証済みドキュメントを生成
|
||||
|
||||
---
|
||||
|
||||
### 62. ディスカスチェーンモード
|
||||
|
||||
**フラグ:** `/gsd-discuss-phase <N> --chain`
|
||||
|
||||
**目的:** 手動のコマンド連続実行を削減するため、discuss、plan、execute フェーズを1つのフローで自動チェーンします。
|
||||
|
||||
**要件:**
|
||||
- REQ-CHAIN-01: `--chain` フラグが提供された場合、システムは discuss → plan → execute を自動チェーンしなければならない
|
||||
- REQ-CHAIN-02: チェーンされたフェーズ間のすべてのゲート設定を尊重しなければならない
|
||||
- REQ-CHAIN-03: いずれかのフェーズが失敗した場合、チェーンを停止しなければならない
|
||||
|
||||
**プロセス:**
|
||||
1. **ディスカス** — コンテキスト収集のためにディスカスフェーズを実行
|
||||
2. **プラン** — 収集されたコンテキストでプランフェーズを自動的に呼び出し
|
||||
3. **エクセキュート** — 生成されたプランでエクセキュートフェーズを自動的に呼び出し
|
||||
|
||||
---
|
||||
|
||||
### 63. 単一フェーズ自律モード
|
||||
|
||||
**フラグ:** `/gsd-autonomous --only N`
|
||||
|
||||
**目的:** 全残りフェーズではなく、1つのフェーズだけを自律的に実行します。
|
||||
|
||||
**要件:**
|
||||
- REQ-ONLY-01: `--only N` が提供された場合、システムは指定されたフェーズ番号のみを実行しなければならない
|
||||
- REQ-ONLY-02: フル自律モードと同じ discuss → plan → execute フローに従わなければならない
|
||||
- REQ-ONLY-03: 指定されたフェーズが完了した後に停止しなければならない
|
||||
|
||||
**プロセス:**
|
||||
1. **選択** — `--only N` 引数からターゲットフェーズを特定
|
||||
2. **実行** — そのフェーズに対してフル自律フロー(discuss → plan → execute)を実行
|
||||
3. **停止** — 次のフェーズに進まず、フェーズ完了後に停止
|
||||
|
||||
---
|
||||
|
||||
### 64. スコープ削減検出
|
||||
|
||||
**対象:** `/gsd-plan-phase`
|
||||
|
||||
**目的:** 三層防御により、計画生成中のサイレントな要件削除を防止します。
|
||||
|
||||
**要件:**
|
||||
- REQ-SCOPE-01: プランナーは明示的な正当化なしにスコープを削減することを禁止されなければならない
|
||||
- REQ-SCOPE-02: プランチェッカーは要件ディメンションカバレッジを検証しなければならない
|
||||
- REQ-SCOPE-03: オーケストレーターは削除された要件を回復して再注入しなければならない
|
||||
- REQ-SCOPE-04: 三層防御を実装しなければならない: プランナー禁止、チェッカーディメンション、オーケストレーター回復
|
||||
|
||||
**プロセス:**
|
||||
1. **禁止** — プランナー指示でスコープ削減を明示的に禁止
|
||||
2. **チェック** — プランチェッカーがすべてのフェーズ要件が計画でカバーされていることを確認
|
||||
3. **回復** — オーケストレーターが削除された要件を検出してプランニングループに再注入
|
||||
|
||||
---
|
||||
|
||||
### 65. クレーム出所タグ付け
|
||||
|
||||
**対象:** `/gsd-research-phase`
|
||||
|
||||
**目的:** リサーチのクレームにソースエビデンスのタグを付け、仮定を別途記録します。
|
||||
|
||||
**要件:**
|
||||
- REQ-PROVENANCE-01: リサーチャーはクレームにソースエビデンス参照をマークしなければならない
|
||||
- REQ-PROVENANCE-02: 仮定はソース付きクレームとは別に記録されなければならない
|
||||
- REQ-PROVENANCE-03: システムはエビデンス付き事実と推論された仮定を区別しなければならない
|
||||
|
||||
**プロセス:**
|
||||
1. **リサーチ** — リサーチャーがコードベースとドメインソースから情報を収集
|
||||
2. **タグ** — 各クレームにソース(ファイルパス、ドキュメント、API レスポンス)をアノテーション
|
||||
3. **分離** — 直接的なエビデンスのない仮定を別セクションに記録
|
||||
|
||||
---
|
||||
|
||||
### 66. Worktree トグル
|
||||
|
||||
**設定:** `workflow.use_worktrees: false`
|
||||
|
||||
**目的:** 順次実行を好むユーザーのために git worktree 分離を無効化します。
|
||||
|
||||
**要件:**
|
||||
- REQ-WORKTREE-01: システムは分離戦略を決定する際に `workflow.use_worktrees` 設定を尊重しなければならない
|
||||
- REQ-WORKTREE-02: 後方互換性のためにデフォルトは `true`(worktree 有効)でなければならない
|
||||
- REQ-WORKTREE-03: worktree が無効な場合、順次実行にフォールバックしなければならない
|
||||
|
||||
**設定:**
|
||||
| 設定 | 型 | デフォルト | 説明 |
|
||||
|------|-----|-----------|------|
|
||||
| `workflow.use_worktrees` | boolean | `true` | `false` の場合、git worktree 分離を無効化 |
|
||||
|
||||
---
|
||||
|
||||
### 67. プロジェクトコードプレフィックス
|
||||
|
||||
**設定:** `project_code: "ABC"`
|
||||
|
||||
**目的:** マルチプロジェクトの曖昧さ解消のためにフェーズディレクトリ名にプロジェクトコードをプレフィックスします。
|
||||
|
||||
**要件:**
|
||||
- REQ-PREFIX-01: 設定された場合、システムはフェーズディレクトリにプロジェクトコードをプレフィックスしなければならない(例: `ABC-01-setup/`)
|
||||
- REQ-PREFIX-02: `project_code` が設定されていない場合、標準命名を使用しなければならない
|
||||
- REQ-PREFIX-03: すべてのフェーズ操作で一貫してプレフィックスを適用しなければならない
|
||||
|
||||
**設定:**
|
||||
| 設定 | 型 | デフォルト | 説明 |
|
||||
|------|-----|-----------|------|
|
||||
| `project_code` | string | (なし) | フェーズディレクトリ名のプレフィックス |
|
||||
|
||||
---
|
||||
|
||||
### 68. Claude Code スキルマイグレーション
|
||||
|
||||
**対象:** `npx get-shit-done-cc`
|
||||
|
||||
**目的:** GSD コマンドを Claude Code 2.1.88+ のスキル形式に後方互換性を維持してマイグレーションします。
|
||||
|
||||
**要件:**
|
||||
- REQ-SKILLS-01: インストーラーは Claude Code 2.1.88+ 向けに `skills/gsd-*/SKILL.md` を書き込まなければならない
|
||||
- REQ-SKILLS-02: インストーラーはレガシー `commands/gsd/` ディレクトリを自動クリーンしなければならない
|
||||
- REQ-SKILLS-03: Gemini パスを通じて古い Claude Code バージョンとの後方互換性を維持しなければならない
|
||||
|
||||
**プロセス:**
|
||||
1. **検出** — Claude Code のバージョンをチェックしてスキルサポートを判定
|
||||
2. **マイグレーション** — 各 GSD コマンドに対して `skills/gsd-*/SKILL.md` ファイルを書き込み
|
||||
3. **クリーン** — スキルがインストールされた場合、レガシー `commands/gsd/` ディレクトリを削除
|
||||
4. **フォールバック** — 古い Claude Code バージョンのために Gemini パス互換性を維持
|
||||
|
||||
---
|
||||
|
||||
## v1.32 の機能
|
||||
|
||||
### 69. STATE.md 整合性ゲート
|
||||
|
||||
**コマンド:** `state validate`、`state sync [--verify]`、`state planned-phase --phase N --plans N`
|
||||
|
||||
**目的:** STATE.md と実際のファイルシステム間のドリフトを検出・修復し、古い状態からのカスケードエラーを防止します。
|
||||
|
||||
**要件:**
|
||||
- REQ-STATE-01: `state validate` は STATE.md フィールドとファイルシステムの実態間のドリフトを検出しなければならない
|
||||
- REQ-STATE-02: `state sync` はディスク上の実際のプロジェクト状態から STATE.md を再構築しなければならない
|
||||
- REQ-STATE-03: `state sync --verify` は書き込みなしで提案される変更を表示するドライランを実行しなければならない
|
||||
- REQ-STATE-04: `state planned-phase` はプランフェーズ完了後の状態遷移を記録しなければならない(Planned/Ready to execute)
|
||||
|
||||
**生成物:**
|
||||
| 成果物 | 説明 |
|
||||
|--------|------|
|
||||
| 更新された `STATE.md` | ファイルシステムの実態を反映した修正済み状態 |
|
||||
|
||||
**プロセス:**
|
||||
1. **検証** — STATE.md フィールドをファイルシステム(フェーズディレクトリ、計画ファイル、サマリー)と比較
|
||||
2. **同期** — ドリフトが検出された場合、ディスクから STATE.md を再構築
|
||||
3. **遷移** — エクセキュートフェーズの準備状態として計画数付きのポストプランニング状態を記録
|
||||
|
||||
---
|
||||
|
||||
### 70. 自律モード `--to N` フラグ
|
||||
|
||||
**フラグ:** `/gsd-autonomous --to N`
|
||||
|
||||
**目的:** 特定のフェーズ完了後に自律実行を停止し、部分的な自律実行を可能にします。
|
||||
|
||||
**要件:**
|
||||
- REQ-TO-01: システムは指定されたフェーズ番号の完了後に実行を停止しなければならない
|
||||
- REQ-TO-02: N までの各フェーズに対して同じ discuss → plan → execute フローに従わなければならない
|
||||
- REQ-TO-03: `--to N` は境界付き自律範囲のために `--from N` と組み合わせ可能でなければならない
|
||||
|
||||
**プロセス:**
|
||||
1. **境界設定** — `--to N` 引数から上限フェーズを設定
|
||||
2. **実行** — フェーズ N まで(含む)の各フェーズに対して自律フローを実行
|
||||
3. **停止** — フェーズ N の完了後に停止
|
||||
|
||||
---
|
||||
|
||||
### 71. リサーチゲート
|
||||
|
||||
**対象:** `/gsd-plan-phase`
|
||||
|
||||
**目的:** RESEARCH.md に未解決のオープンクエスチョンがある場合にプランニングをブロックし、不完全な情報に基づく計画を防止します。
|
||||
|
||||
**要件:**
|
||||
- REQ-RESGATE-01: プランニング開始前に RESEARCH.md の未解決オープンクエスチョンをスキャンしなければならない
|
||||
- REQ-RESGATE-02: オープンクエスチョンが存在する場合、プランフェーズのエントリをブロックしなければならない
|
||||
- REQ-RESGATE-03: 具体的な未解決クエスチョンをユーザーに表示しなければならない
|
||||
|
||||
**プロセス:**
|
||||
1. **スキャン** — RESEARCH.md のオープンクエスチョンセクションで未解決項目をチェック
|
||||
2. **ゲート** — 未解決クエスチョンが見つかった場合、プランニングをブロック
|
||||
3. **表示** — 解決が必要な具体的なオープンクエスチョンを表示
|
||||
|
||||
---
|
||||
|
||||
### 72. ベリファイヤーマイルストーンスコープフィルタリング
|
||||
|
||||
**対象:** `/gsd-execute-phase`(ベリファイヤーステップ)
|
||||
|
||||
**目的:** 真のギャップと後続フェーズに延期された項目を区別し、検証の偽陰性を削減します。
|
||||
|
||||
**要件:**
|
||||
- REQ-VSCOPE-01: ベリファイヤーはギャップが後続マイルストーンフェーズで対処されるかチェックしなければならない
|
||||
- REQ-VSCOPE-02: 後続フェーズで対処されるギャップは「ギャップ」ではなく「延期」とマークされなければならない
|
||||
- REQ-VSCOPE-03: 真のギャップ(将来のフェーズでもカバーされない)のみが失敗として報告されなければならない
|
||||
|
||||
**プロセス:**
|
||||
1. **検証** — 標準的なゴール逆行検証を実行
|
||||
2. **フィルター** — 検出されたギャップを後続マイルストーンフェーズとクロスリファレンス
|
||||
3. **分類** — 延期された項目を真のギャップとは別にマーク
|
||||
|
||||
---
|
||||
|
||||
### 73. Read-Before-Edit ガードフック
|
||||
|
||||
**対象:** フック(`PreToolUse`)
|
||||
|
||||
**目的:** ファイルが編集前に読み込まれることを確認し、非 Claude ランタイムでの無限リトライループを防止します。
|
||||
|
||||
**要件:**
|
||||
- REQ-RBE-01: フックはセッションで以前に読み込まれていないファイルを対象とする Edit/Write ツールコールを検出しなければならない
|
||||
- REQ-RBE-02: フックはまずファイルを読み込むよう勧告しなければならない(勧告的、非ブロッキング)
|
||||
- REQ-RBE-03: フックは組み込みの read-before-edit 強制のないランタイムで一般的な無限リトライループを防止しなければならない
|
||||
|
||||
---
|
||||
|
||||
### 74. コンテキスト削減
|
||||
|
||||
**対象:** GSD SDK プロンプトアセンブリ
|
||||
|
||||
**目的:** Markdown 切り詰めとキャッシュフレンドリーなプロンプト順序により、コンテキストプロンプトサイズを削減します。
|
||||
|
||||
**要件:**
|
||||
- REQ-CTXRED-01: システムはコンテキスト予算内に収まるよう、大きすぎる Markdown アーティファクトを切り詰めなければならない
|
||||
- REQ-CTXRED-02: キャッシュフレンドリーなアセンブリのためにプロンプトを順序付けなければならない(安定したプレフィックスを先頭に)
|
||||
- REQ-CTXRED-03: 削減は必須情報(見出し、要件、タスク構造)を保持しなければならない
|
||||
|
||||
**プロセス:**
|
||||
1. **計測** — ワークフローの総プロンプトサイズを計算
|
||||
2. **切り詰め** — 大きすぎるアーティファクトに Markdown 対応の切り詰めを適用
|
||||
3. **順序付け** — KV キャッシュ再利用の最適化のためにプロンプトセクションを配置
|
||||
|
||||
---
|
||||
|
||||
### 75. ディスカスフェーズ `--power` フラグ
|
||||
|
||||
**フラグ:** `/gsd-discuss-phase --power`
|
||||
|
||||
**目的:** ディスカスフェーズのファイルベースの一括質問回答で、準備済み回答ファイルからのバッチ入力を可能にします。
|
||||
|
||||
**要件:**
|
||||
- REQ-POWER-01: システムはディスカッション質問への事前記述済み回答を含むファイルを受け付けなければならない
|
||||
- REQ-POWER-02: システムは回答を対応するグレーエリア質問にマッピングしなければならない
|
||||
- REQ-POWER-03: システムはインタラクティブなディスカスフェーズと同一の CONTEXT.md を生成しなければならない
|
||||
|
||||
---
|
||||
|
||||
### 76. デバッグ `--diagnose` フラグ
|
||||
|
||||
**フラグ:** `/gsd-debug --diagnose`
|
||||
|
||||
**目的:** 修正を試みず調査のみを行う診断専用モード。
|
||||
|
||||
**要件:**
|
||||
- REQ-DIAG-01: システムは完全なデバッグ調査(仮説、エビデンス、根本原因)を実行しなければならない
|
||||
- REQ-DIAG-02: システムはコード変更を一切行ってはならない
|
||||
- REQ-DIAG-03: システムは発見事項と推奨修正を含む診断レポートを生成しなければならない
|
||||
|
||||
---
|
||||
|
||||
### 77. フェーズ依存関係分析
|
||||
|
||||
**コマンド:** `/gsd-analyze-dependencies`
|
||||
|
||||
**目的:** フェーズ依存関係を検出し、`/gsd-manager` 実行前に ROADMAP.md への `Depends on` エントリを提案します。
|
||||
|
||||
**要件:**
|
||||
- REQ-DEP-01: システムはフェーズ間のファイルオーバーラップを検出しなければならない
|
||||
- REQ-DEP-02: システムはセマンティック依存関係(API/スキーマのプロデューサーとコンシューマー)を検出しなければならない
|
||||
- REQ-DEP-03: システムはデータフロー依存関係(出力プロデューサーとリーダー)を検出しなければならない
|
||||
- REQ-DEP-04: システムは依存関係エントリを提案し、書き込み前にユーザー確認を要求しなければならない
|
||||
|
||||
**生成物:** 依存関係提案テーブル;オプションで ROADMAP.md の `Depends on` フィールドを更新
|
||||
|
||||
---
|
||||
|
||||
### 78. アンチパターン重大度レベル
|
||||
|
||||
**対象:** `/gsd-resume-work`
|
||||
|
||||
**目的:** 重大度ベースのアンチパターン強制によるリジューム時の必須理解チェック。
|
||||
|
||||
**要件:**
|
||||
- REQ-ANTI-01: システムはアンチパターンを重大度レベルで分類しなければならない
|
||||
- REQ-ANTI-02: システムはセッションリジューム時に必須の理解チェックを強制しなければならない
|
||||
- REQ-ANTI-03: より高い重大度のアンチパターンは承認されるまでワークフロー進行をブロックしなければならない
|
||||
|
||||
---
|
||||
|
||||
### 79. メソドロジーアーティファクトタイプ
|
||||
|
||||
**対象:** プランニングアーティファクト
|
||||
|
||||
**目的:** メソドロジードキュメントの消費メカニズムを定義し、エージェントによって正しく消費されることを確保します。
|
||||
|
||||
**要件:**
|
||||
- REQ-METHOD-01: システムはメソドロジーを独自のアーティファクトタイプとしてサポートしなければならない
|
||||
- REQ-METHOD-02: メソドロジーアーティファクトはエージェント向けの定義された消費メカニズムを持たなければならない
|
||||
|
||||
---
|
||||
|
||||
### 80. プランナー到達可能性チェック
|
||||
|
||||
**対象:** `/gsd-plan-phase`
|
||||
|
||||
**目的:** 実行にコミットする前にプランステップが達成可能であることを検証します。
|
||||
|
||||
**要件:**
|
||||
- REQ-REACH-01: プランナーは各プランステップが到達可能なファイルと API を参照していることを検証しなければならない
|
||||
- REQ-REACH-02: 到達不可能なステップは実行中ではなくプランニング中にフラグ付けされなければならない
|
||||
|
||||
---
|
||||
|
||||
### 81. Playwright-MCP UI 検証
|
||||
|
||||
**対象:** `/gsd-verify-work`(オプション)
|
||||
|
||||
**目的:** ベリファイフェーズ中の Playwright-MCP を使用した自動ビジュアル検証。
|
||||
|
||||
**要件:**
|
||||
- REQ-PLAY-01: システムはベリファイフェーズ中のオプションの Playwright-MCP ビジュアル検証をサポートしなければならない
|
||||
- REQ-PLAY-02: ビジュアル検証はオプトインであり、必須であってはならない
|
||||
- REQ-PLAY-03: システムは UI-SPEC.md の期待値に対してビジュアル状態をキャプチャ・比較しなければならない
|
||||
|
||||
---
|
||||
|
||||
### 82. Pause-Work 拡張
|
||||
|
||||
**対象:** `/gsd-pause-work`
|
||||
|
||||
**目的:** よりリッチなハンドオフデータで非フェーズコンテキストをサポートし、pause-work の適用範囲を拡大します。
|
||||
|
||||
**要件:**
|
||||
- REQ-PAUSE-01: システムは非フェーズコンテキスト(クイックタスク、デバッグセッション、スレッド)でのポーズをサポートしなければならない
|
||||
- REQ-PAUSE-02: ハンドオフデータは現在の作業タイプに適切なよりリッチなコンテキストを含まなければならない
|
||||
|
||||
---
|
||||
|
||||
### 83. レスポンス言語設定
|
||||
|
||||
**設定:** `response_language`
|
||||
|
||||
**目的:** 非英語ユーザーのためのクロスフェーズ言語一貫性。
|
||||
|
||||
**要件:**
|
||||
- REQ-LANG-01: システムはすべてのフェーズとエージェントで `response_language` 設定を尊重しなければならない
|
||||
- REQ-LANG-02: 設定はすべてのスポーンされたエージェントに伝播し、一貫した言語出力を確保しなければならない
|
||||
|
||||
**設定:**
|
||||
| 設定 | 型 | デフォルト | 説明 |
|
||||
|------|-----|-----------|------|
|
||||
| `response_language` | string | (なし) | エージェントレスポンスの言語コード(例: `"pt"`、`"ko"`、`"ja"`) |
|
||||
|
||||
---
|
||||
|
||||
### 84. 手動アップデート手順
|
||||
|
||||
**対象:** `docs/manual-update.md`
|
||||
|
||||
**目的:** `npx` が利用不可または npm パブリッシュに障害が発生している環境のための手動アップデートパスを文書化します。
|
||||
|
||||
**要件:**
|
||||
- REQ-MANUAL-01: ドキュメントはステップバイステップの手動アップデート手順を記述しなければならない
|
||||
- REQ-MANUAL-02: 手順は npm アクセスなしで機能しなければならない
|
||||
|
||||
---
|
||||
|
||||
### 85. 新規ランタイムサポート (Trae, Cline, Augment Code)
|
||||
|
||||
**対象:** `npx get-shit-done-cc`
|
||||
|
||||
**目的:** Trae IDE、Cline、Augment Code ランタイムへの GSD インストールを拡張します。
|
||||
|
||||
**要件:**
|
||||
- REQ-TRAE-01: インストーラーは Trae IDE インストールのための `--trae` フラグをサポートしなければならない
|
||||
- REQ-CLINE-01: インストーラーは `.clinerules` 設定を通じて Cline をサポートしなければならない
|
||||
- REQ-AUGMENT-01: インストーラーはスキル変換と設定管理で Augment Code をサポートしなければならない
|
||||
|
||||
@@ -11,14 +11,14 @@ Get Shit Done(GSD)フレームワークの包括的なドキュメントで
|
||||
| [コマンドリファレンス](COMMANDS.md) | 全ユーザー | 全コマンドの構文、フラグ、オプション、使用例 |
|
||||
| [設定リファレンス](CONFIGURATION.md) | 全ユーザー | 設定スキーマ、ワークフロートグル、モデルプロファイル、Git ブランチ |
|
||||
| [CLI ツールリファレンス](CLI-TOOLS.md) | コントリビューター、エージェント作成者 | `gsd-tools.cjs` のプログラマティック API(ワークフローおよびエージェント向け) |
|
||||
| [エージェントリファレンス](AGENTS.md) | コントリビューター、上級ユーザー | 全15種の専門エージェント — 役割、ツール、スポーンパターン |
|
||||
| [エージェントリファレンス](AGENTS.md) | コントリビューター、上級ユーザー | 全18種の専門エージェント — 役割、ツール、スポーンパターン |
|
||||
| [ユーザーガイド](USER-GUIDE.md) | 全ユーザー | ワークフローのウォークスルー、トラブルシューティング、リカバリー |
|
||||
| [コンテキストモニター](context-monitor.md) | 全ユーザー | コンテキストウィンドウ監視フックのアーキテクチャ |
|
||||
| [ディスカスモード](workflow-discuss-mode.md) | 全ユーザー | discuss フェーズにおける assumptions モードと interview モード |
|
||||
|
||||
## クイックリンク
|
||||
|
||||
- **v1.28 の新機能:** フォレンジクス、マイルストーンサマリー、ワークストリーム、assumptions モード、UI 自動検出、マネージャーダッシュボード
|
||||
- **v1.32 の新機能:** STATE.md 整合性ゲート、`--to N` 自律モード、リサーチゲート、ベリファイヤーマイルストーンスコープフィルタリング、read-before-edit ガード、コンテキスト削減、新規ランタイム(Trae, Cline, Augment Code)、レスポンス言語設定、`--power`/`--diagnose` フラグ、`/gsd-analyze-dependencies`
|
||||
- **はじめに:** [README](../README.md) → インストール → `/gsd-new-project`
|
||||
- **ワークフロー完全ガイド:** [ユーザーガイド](USER-GUIDE.md)
|
||||
- **コマンド一覧:** [コマンドリファレンス](COMMANDS.md)
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# GSD 에이전트 레퍼런스
|
||||
|
||||
> 18개의 전문화된 에이전트 — 역할, 도구, 생성 패턴, 관계를 모두 포함합니다. 아키텍처 맥락은 [Architecture](ARCHITECTURE.md)를 참조하세요.
|
||||
> 18개의 전문화된 에이전트 (v1.32 기준) — 역할, 도구, 생성 패턴, 관계를 모두 포함합니다. 아키텍처 맥락은 [Architecture](ARCHITECTURE.md)를 참조하세요.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -21,7 +21,7 @@
|
||||
|
||||
## 시스템 개요
|
||||
|
||||
GSD는 사용자와 AI 코딩 에이전트(Claude Code, Gemini CLI, OpenCode, Kilo, Codex, Copilot, Antigravity) 사이에 위치하는 **메타 프롬프팅 프레임워크**입니다. 다음을 제공합니다.
|
||||
GSD는 사용자와 AI 코딩 에이전트(Claude Code, Gemini CLI, OpenCode, Kilo, Codex, Copilot, Antigravity, Trae, Cline, Augment Code) 사이에 위치하는 **메타 프롬프팅 프레임워크**입니다. 다음을 제공합니다.
|
||||
|
||||
1. **컨텍스트 엔지니어링** — 작업별로 AI에게 필요한 모든 것을 제공하는 구조화된 아티팩트
|
||||
2. **멀티 에이전트 오케스트레이션** — 새로운 컨텍스트 윈도우로 전문화된 에이전트를 생성하는 가벼운 오케스트레이터
|
||||
|
||||
@@ -101,6 +101,8 @@
|
||||
| `--auto` | 모든 질문에 추천 기본값을 자동으로 선택합니다 |
|
||||
| `--batch` | 질문을 하나씩 처리하는 대신 일괄 입력 방식으로 그룹화합니다 |
|
||||
| `--analyze` | 토론 중 트레이드오프 분석을 추가합니다 |
|
||||
| `--chain` | discuss → plan → execute를 하나의 플로우로 자동 체인합니다 (v1.31) |
|
||||
| `--power` | 준비된 답변 파일에서 일괄 입력으로 질문에 답변합니다 (v1.32) |
|
||||
|
||||
**사전 조건:** `.planning/ROADMAP.md`가 존재해야 합니다.
|
||||
**생성 파일:** `{phase}-CONTEXT.md`, `{phase}-DISCUSSION-LOG.md` (감사 추적)
|
||||
@@ -487,6 +489,20 @@ Nyquist 검증 갭을 소급하여 감사하고 보완합니다.
|
||||
|
||||
---
|
||||
|
||||
### `/gsd-analyze-dependencies`
|
||||
|
||||
페이즈 의존성을 감지하고 ROADMAP.md에 `Depends on` 항목을 제안합니다. (v1.32)
|
||||
|
||||
**사전 조건:** `.planning/ROADMAP.md`가 존재해야 합니다.
|
||||
**감지 방법:** 파일 겹침, 의미적 의존성(API/스키마 생산자-소비자), 데이터 흐름 의존성
|
||||
**동작 방식:** 의존성 제안 테이블을 표시하고 사용자 확인 후 ROADMAP.md의 `Depends on` 필드를 업데이트합니다.
|
||||
|
||||
```bash
|
||||
/gsd-analyze-dependencies # 의존성 분석 및 제안
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### `/gsd-help`
|
||||
|
||||
모든 명령어와 사용 가이드를 표시합니다.
|
||||
@@ -525,10 +541,16 @@ GSD 보증을 갖춘 임시 작업을 실행합니다.
|
||||
| 플래그 | 설명 |
|
||||
|--------|------|
|
||||
| `--from N` | 특정 페이즈 번호부터 시작합니다 |
|
||||
| `--to N` | 페이즈 N 완료 후 자율 실행을 중단합니다 (v1.32) |
|
||||
| `--only N` | 지정된 단일 페이즈만 자율적으로 실행합니다 (v1.31) |
|
||||
| `--interactive` | 각 페이즈의 discuss 단계에서 사용자 확인을 요청합니다 |
|
||||
|
||||
```bash
|
||||
/gsd-autonomous # 남은 모든 페이즈 실행
|
||||
/gsd-autonomous --from 3 # 페이즈 3부터 시작
|
||||
/gsd-autonomous --to 5 # 페이즈 5까지만 실행
|
||||
/gsd-autonomous --from 3 --to 5 # 페이즈 3~5 범위 실행
|
||||
/gsd-autonomous --only 4 # 페이즈 4만 자율 실행
|
||||
```
|
||||
|
||||
### `/gsd-do`
|
||||
@@ -567,8 +589,13 @@ GSD 보증을 갖춘 임시 작업을 실행합니다.
|
||||
|------|----------|------|
|
||||
| `description` | 아니오 | 버그 설명 |
|
||||
|
||||
| 플래그 | 설명 |
|
||||
|--------|------|
|
||||
| `--diagnose` | 수정 없이 조사만 수행하는 진단 전용 모드 (v1.32) |
|
||||
|
||||
```bash
|
||||
/gsd-debug "Login button not responding on mobile Safari"
|
||||
/gsd-debug --diagnose "API returning 500 on /users endpoint"
|
||||
```
|
||||
|
||||
### `/gsd-add-todo`
|
||||
|
||||
@@ -33,7 +33,8 @@ GSD는 프로젝트 설정을 `.planning/config.json`에 저장합니다. `/gsd-
|
||||
"research_before_questions": false,
|
||||
"discuss_mode": "discuss",
|
||||
"skip_discuss": false,
|
||||
"text_mode": false
|
||||
"text_mode": false,
|
||||
"use_worktrees": true
|
||||
},
|
||||
"hooks": {
|
||||
"context_warnings": true,
|
||||
@@ -100,6 +101,7 @@ GSD는 프로젝트 설정을 `.planning/config.json`에 저장합니다. `/gsd-
|
||||
| `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'` (기본값)는 질문을 하나씩 합니다. `'assumptions'`는 코드베이스를 먼저 읽고 신뢰도 수준이 있는 구조화된 가정을 생성하여 틀린 부분만 수정하도록 요청합니다. v1.28에서 추가 |
|
||||
| `workflow.skip_discuss` | boolean | `false` | `true`로 설정하면 `/gsd-autonomous`가 discuss 단계를 완전히 건너뛰고 ROADMAP 단계 목표로부터 최소한의 CONTEXT.md를 작성합니다. 개발자 선호사항이 PROJECT.md/REQUIREMENTS.md에 모두 캡처된 프로젝트에 유용합니다. v1.28에서 추가 |
|
||||
| `workflow.text_mode` | boolean | `false` | AskUserQuestion TUI 메뉴를 일반 텍스트 번호 목록으로 대체합니다. TUI 메뉴가 렌더링되지 않는 Claude Code 원격 세션 (`/rc` 모드)에 필요합니다. discuss 단계에서 `--text` 플래그로 세션별 설정도 가능합니다. v1.28에서 추가 |
|
||||
@@ -232,6 +234,26 @@ quick 태스크 브랜칭 예시:
|
||||
|
||||
---
|
||||
|
||||
## 보안 설정 (v1.31)
|
||||
|
||||
| 설정 | 타입 | 기본값 | 설명 |
|
||||
|------|------|--------|------|
|
||||
| `security_enforcement` | boolean | `true` | 위협 모델 보안 검증 활성화 |
|
||||
| `security_asvs_level` | number (1-3) | `1` | OWASP ASVS 검증 레벨 |
|
||||
| `security_block_on` | string | `"high"` | 페이즈 진행을 차단하는 최소 심각도 |
|
||||
|
||||
---
|
||||
|
||||
## 응답 언어 설정 (v1.32)
|
||||
|
||||
| 설정 | 타입 | 기본값 | 설명 |
|
||||
|------|------|--------|------|
|
||||
| `response_language` | string | (없음) | 에이전트 응답의 언어 코드 (예: `"pt"`, `"ko"`, `"ja"`) |
|
||||
|
||||
`response_language`가 설정되면 모든 페이즈와 스폰된 에이전트에서 일관된 언어 출력을 보장합니다.
|
||||
|
||||
---
|
||||
|
||||
## 훅 설정
|
||||
|
||||
| 설정 | 타입 | 기본값 | 설명 |
|
||||
@@ -330,6 +352,7 @@ quick 태스크 브랜칭 예시:
|
||||
| `CLAUDE_CONFIG_DIR` | 기본 설정 디렉토리 재정의 (`~/.claude/`) |
|
||||
| `GEMINI_API_KEY` | context monitor가 훅 이벤트 이름을 전환하기 위해 감지 |
|
||||
| `WSL_DISTRO_NAME` | 인스톨러가 WSL 경로 처리를 위해 감지 |
|
||||
| `GSD_SKIP_SCHEMA_CHECK` | 스키마 드리프트 감지 바이패스 (v1.31) |
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -70,6 +70,40 @@
|
||||
- [가정 논의 모드](#53-assumptions-discussion-mode)
|
||||
- [UI 페이즈 자동 감지](#54-ui-phase-auto-detection)
|
||||
- [멀티 런타임 설치 선택](#55-multi-runtime-installer-selection)
|
||||
- [v1.29 기능](#v129-기능)
|
||||
- [Windsurf 런타임 지원](#56-windsurf-런타임-지원)
|
||||
- [국제화 문서](#57-국제화-문서)
|
||||
- [v1.30 기능](#v130-기능)
|
||||
- [GSD SDK](#58-gsd-sdk)
|
||||
- [v1.31 기능](#v131-기능)
|
||||
- [스키마 드리프트 감지](#59-스키마-드리프트-감지)
|
||||
- [보안 시행](#60-보안-시행)
|
||||
- [문서 생성](#61-문서-생성)
|
||||
- [디스커스 체인 모드](#62-디스커스-체인-모드)
|
||||
- [단일 페이즈 자율 모드](#63-단일-페이즈-자율-모드)
|
||||
- [범위 축소 감지](#64-범위-축소-감지)
|
||||
- [주장 출처 태깅](#65-주장-출처-태깅)
|
||||
- [Worktree 토글](#66-worktree-토글)
|
||||
- [프로젝트 코드 접두사](#67-프로젝트-코드-접두사)
|
||||
- [Claude Code 스킬 마이그레이션](#68-claude-code-스킬-마이그레이션)
|
||||
- [v1.32 기능](#v132-기능)
|
||||
- [STATE.md 일관성 게이트](#69-statemd-일관성-게이트)
|
||||
- [자율 모드 `--to N` 플래그](#70-자율-모드---to-n-플래그)
|
||||
- [리서치 게이트](#71-리서치-게이트)
|
||||
- [검증자 마일스톤 범위 필터링](#72-검증자-마일스톤-범위-필터링)
|
||||
- [Read-Before-Edit 가드 훅](#73-read-before-edit-가드-훅)
|
||||
- [컨텍스트 축소](#74-컨텍스트-축소)
|
||||
- [디스커스 페이즈 `--power` 플래그](#75-디스커스-페이즈---power-플래그)
|
||||
- [디버그 `--diagnose` 플래그](#76-디버그---diagnose-플래그)
|
||||
- [페이즈 의존성 분석](#77-페이즈-의존성-분석)
|
||||
- [안티패턴 심각도 레벨](#78-안티패턴-심각도-레벨)
|
||||
- [방법론 아티팩트 유형](#79-방법론-아티팩트-유형)
|
||||
- [플래너 도달 가능성 검사](#80-플래너-도달-가능성-검사)
|
||||
- [Playwright-MCP UI 검증](#81-playwright-mcp-ui-검증)
|
||||
- [Pause-Work 확장](#82-pause-work-확장)
|
||||
- [응답 언어 설정](#83-응답-언어-설정)
|
||||
- [수동 업데이트 절차](#84-수동-업데이트-절차)
|
||||
- [신규 런타임 지원 (Trae, Cline, Augment Code)](#85-신규-런타임-지원-trae-cline-augment-code)
|
||||
|
||||
---
|
||||
|
||||
@@ -1288,3 +1322,522 @@ Claude가 GSD 워크플로우 컨텍스트 밖에서 파일 편집을 시도하
|
||||
1. **감지** — 시스템에서 사용 가능한 AI CLI 런타임 식별
|
||||
2. **프롬프트** — 런타임 선택을 위한 다중 선택 인터페이스 표시
|
||||
3. **설치** — 단일 세션에서 선택된 모든 런타임에 GSD 구성
|
||||
|
||||
---
|
||||
|
||||
## v1.29 기능
|
||||
|
||||
### 56. Windsurf 런타임 지원
|
||||
|
||||
**대상:** `npx get-shit-done-cc`
|
||||
|
||||
**목적:** Windsurf AI IDE 지원을 추가합니다.
|
||||
|
||||
**요구사항.**
|
||||
- REQ-WINDSURF-01: 설치 프로그램은 `--windsurf` 플래그를 통한 Windsurf 설치를 지원해야 합니다.
|
||||
- REQ-WINDSURF-02: Windsurf 규칙 형식에 맞는 프롬프트 파일을 생성해야 합니다.
|
||||
|
||||
**프로세스.**
|
||||
1. **감지** — Windsurf 설치 상태 확인
|
||||
2. **변환** — GSD 프롬프트를 Windsurf 규칙 형식으로 변환
|
||||
3. **설치** — Windsurf 구성 디렉토리에 GSD 설정
|
||||
|
||||
---
|
||||
|
||||
### 57. 국제화 문서
|
||||
|
||||
**대상:** `docs/` 디렉토리
|
||||
|
||||
**목적:** GSD 문서를 포르투갈어, 한국어, 일본어로 제공합니다.
|
||||
|
||||
**요구사항.**
|
||||
- REQ-I18N-01: 문서는 포르투갈어(pt), 한국어(ko), 일본어(ja)로 제공되어야 합니다.
|
||||
- REQ-I18N-02: 번역은 영어 원본 문서와 동기화를 유지해야 합니다.
|
||||
|
||||
**프로세스.**
|
||||
1. **번역** — 핵심 문서를 대상 언어로 변환
|
||||
2. **게시** — 번역된 문서를 영어 원본과 함께 접근 가능하게 제공
|
||||
|
||||
---
|
||||
|
||||
## v1.30 기능
|
||||
|
||||
### 58. GSD SDK
|
||||
|
||||
**명령어:** 프로그래매틱 API (헤드리스)
|
||||
|
||||
**목적:** CLI 세션 없이 프로그래밍 방식으로 GSD 워크플로우를 실행하기 위한 헤드리스 TypeScript SDK.
|
||||
|
||||
**요구사항.**
|
||||
- REQ-SDK-01: SDK는 GSD 워크플로우 작업을 TypeScript 함수로 노출해야 합니다.
|
||||
- REQ-SDK-02: SDK는 대화형 프롬프트 없이 헤드리스 실행을 지원해야 합니다.
|
||||
- REQ-SDK-03: SDK는 CLI 기반 워크플로우와 동일한 아티팩트를 생성해야 합니다.
|
||||
|
||||
**프로세스.**
|
||||
1. **임포트** — TypeScript/JavaScript 프로젝트에 GSD SDK 임포트
|
||||
2. **구성** — 프로젝트 경로와 워크플로우 옵션을 프로그래밍 방식으로 설정
|
||||
3. **실행** — API 호출로 GSD 페이즈(discuss, plan, execute) 실행
|
||||
|
||||
---
|
||||
|
||||
## v1.31 기능
|
||||
|
||||
### 59. 스키마 드리프트 감지
|
||||
|
||||
**명령어:** `/gsd-execute-phase` 실행 시 자동
|
||||
|
||||
**목적:** ORM 스키마 파일이 대응하는 마이그레이션 또는 push 명령 없이 수정된 경우를 감지하여 오탐 검증을 방지합니다.
|
||||
|
||||
**요구사항.**
|
||||
- REQ-SCHEMA-01: 시스템은 ORM 스키마 파일(Prisma, Drizzle, Payload, Sanity, Mongoose) 수정을 감지해야 합니다.
|
||||
- REQ-SCHEMA-02: 스키마 변경이 감지되면 대응하는 마이그레이션/push 명령의 존재를 확인해야 합니다.
|
||||
- REQ-SCHEMA-03: 이중 방어를 구현해야 합니다: 계획 시점 주입 및 실행 시점 게이트.
|
||||
- REQ-SCHEMA-04: 감지를 재정의하는 `GSD_SKIP_SCHEMA_CHECK` 환경 변수를 지원해야 합니다.
|
||||
- REQ-SCHEMA-05: 마이그레이션 없는 스키마 변경 시 오탐 검증을 방지해야 합니다.
|
||||
|
||||
**프로세스.**
|
||||
1. **감지** — 계획 실행 중 ORM 스키마 파일 수정 모니터링
|
||||
2. **확인** — 계획에 대응하는 마이그레이션/push 명령이 포함되어 있는지 확인
|
||||
3. **게이트** — 마이그레이션 없는 스키마 드리프트가 감지되면 실행 차단(실행 시점 게이트)
|
||||
4. **주입** — 계획 생성 중 마이그레이션 리마인더 추가(계획 시점 주입)
|
||||
|
||||
**구성:** `GSD_SKIP_SCHEMA_CHECK` 환경 변수로 감지 바이패스.
|
||||
|
||||
---
|
||||
|
||||
### 60. 보안 시행
|
||||
|
||||
**명령어:** `/gsd-secure-phase <N>`
|
||||
|
||||
**목적:** 페이즈 구현에 대한 위협 모델 기반 보안 검증.
|
||||
|
||||
**요구사항.**
|
||||
- REQ-SEC-01: 시스템은 위협 모델 기반 검증(블라인드 스캔이 아닌)을 수행해야 합니다.
|
||||
- REQ-SEC-02: 구성 가능한 OWASP ASVS 검증 레벨(1-3)을 지원해야 합니다.
|
||||
- REQ-SEC-03: 구성 가능한 심각도 임계값에 따라 페이즈 진행을 차단해야 합니다.
|
||||
- REQ-SEC-04: 분석을 위해 `gsd-security-auditor` 에이전트를 스폰해야 합니다.
|
||||
|
||||
**생성 산출물.**
|
||||
| 산출물 | 설명 |
|
||||
|----------|-------------|
|
||||
| 보안 감사 보고서 | 심각도 분류가 포함된 위협 모델 기반 발견 사항 |
|
||||
|
||||
**프로세스.**
|
||||
1. **모델** — 페이즈 구현 컨텍스트에서 위협 모델 구축
|
||||
2. **감사** — `gsd-security-auditor`를 스폰하여 위협 모델에 대해 검증
|
||||
3. **게이트** — 발견 사항이 `security_block_on` 심각도 이상이면 페이즈 진행 차단
|
||||
|
||||
**구성:**
|
||||
| 설정 | 유형 | 기본값 | 설명 |
|
||||
|------|------|--------|------|
|
||||
| `security_enforcement` | boolean | `true` | 위협 모델 보안 검증 활성화 |
|
||||
| `security_asvs_level` | number (1-3) | `1` | OWASP ASVS 검증 레벨 |
|
||||
| `security_block_on` | string | `"high"` | 페이즈 진행을 차단하는 최소 심각도 |
|
||||
|
||||
---
|
||||
|
||||
### 61. 문서 생성
|
||||
|
||||
**명령어:** `/gsd-docs-update`
|
||||
|
||||
**목적:** 정확성 검사가 포함된 프로젝트 문서를 생성하고 검증합니다.
|
||||
|
||||
**요구사항.**
|
||||
- REQ-DOCS-01: 시스템은 문서 생성을 위해 `gsd-doc-writer` 에이전트를 스폰해야 합니다.
|
||||
- REQ-DOCS-02: 시스템은 정확성 검사를 위해 `gsd-doc-verifier` 에이전트를 스폰해야 합니다.
|
||||
- REQ-DOCS-03: 시스템은 생성된 문서를 실제 구현에 대해 검증해야 합니다.
|
||||
|
||||
**생성 산출물.**
|
||||
| 산출물 | 설명 |
|
||||
|----------|-------------|
|
||||
| 업데이트된 프로젝트 문서 | 생성 및 검증된 문서 파일 |
|
||||
|
||||
**프로세스.**
|
||||
1. **생성** — `gsd-doc-writer`를 스폰하여 구현에서 문서 생성 또는 업데이트
|
||||
2. **검증** — `gsd-doc-verifier`를 스폰하여 코드베이스에 대한 문서 정확성 검사
|
||||
3. **출력** — 정확성 주석이 포함된 검증된 문서 생성
|
||||
|
||||
---
|
||||
|
||||
### 62. 디스커스 체인 모드
|
||||
|
||||
**플래그:** `/gsd-discuss-phase <N> --chain`
|
||||
|
||||
**목적:** 수동 명령어 연속 실행을 줄이기 위해 discuss, plan, execute 페이즈를 하나의 플로우로 자동 체인합니다.
|
||||
|
||||
**요구사항.**
|
||||
- REQ-CHAIN-01: `--chain` 플래그가 제공되면 시스템은 discuss → plan → execute를 자동 체인해야 합니다.
|
||||
- REQ-CHAIN-02: 체인된 페이즈 간의 모든 게이트 설정을 준수해야 합니다.
|
||||
- REQ-CHAIN-03: 어떤 페이즈든 실패하면 체인을 중단해야 합니다.
|
||||
|
||||
**프로세스.**
|
||||
1. **디스커스** — 컨텍스트 수집을 위해 디스커스 페이즈 실행
|
||||
2. **플랜** — 수집된 컨텍스트로 플랜 페이즈 자동 호출
|
||||
3. **실행** — 생성된 계획으로 실행 페이즈 자동 호출
|
||||
|
||||
---
|
||||
|
||||
### 63. 단일 페이즈 자율 모드
|
||||
|
||||
**플래그:** `/gsd-autonomous --only N`
|
||||
|
||||
**목적:** 모든 남은 페이즈가 아닌 하나의 페이즈만 자율적으로 실행합니다.
|
||||
|
||||
**요구사항.**
|
||||
- REQ-ONLY-01: `--only N`이 제공되면 시스템은 지정된 페이즈 번호만 실행해야 합니다.
|
||||
- REQ-ONLY-02: 전체 자율 모드와 동일한 discuss → plan → execute 플로우를 따라야 합니다.
|
||||
- REQ-ONLY-03: 지정된 페이즈가 완료되면 중단해야 합니다.
|
||||
|
||||
**프로세스.**
|
||||
1. **선택** — `--only N` 인수에서 대상 페이즈 식별
|
||||
2. **실행** — 해당 페이즈에 대해 전체 자율 플로우(discuss → plan → execute) 실행
|
||||
3. **중단** — 다음 페이즈로 진행하지 않고 페이즈 완료 후 중단
|
||||
|
||||
---
|
||||
|
||||
### 64. 범위 축소 감지
|
||||
|
||||
**대상:** `/gsd-plan-phase`
|
||||
|
||||
**목적:** 삼중 방어로 계획 생성 중 요구사항의 무단 삭제를 방지합니다.
|
||||
|
||||
**요구사항.**
|
||||
- REQ-SCOPE-01: 플래너는 명시적 정당화 없이 범위를 축소하는 것이 금지되어야 합니다.
|
||||
- REQ-SCOPE-02: 플랜 체커는 요구사항 차원 커버리지를 검증해야 합니다.
|
||||
- REQ-SCOPE-03: 오케스트레이터는 삭제된 요구사항을 복구하고 재주입해야 합니다.
|
||||
- REQ-SCOPE-04: 삼중 방어를 구현해야 합니다: 플래너 금지, 체커 차원, 오케스트레이터 복구.
|
||||
|
||||
**프로세스.**
|
||||
1. **금지** — 플래너 지시에서 범위 축소를 명시적으로 금지
|
||||
2. **검사** — 플랜 체커가 모든 페이즈 요구사항이 계획에 포함되어 있는지 확인
|
||||
3. **복구** — 오케스트레이터가 삭제된 요구사항을 감지하고 계획 루프에 재주입
|
||||
|
||||
---
|
||||
|
||||
### 65. 주장 출처 태깅
|
||||
|
||||
**대상:** `/gsd-research-phase`
|
||||
|
||||
**목적:** 연구 주장에 출처 증거를 태깅하고 가정을 별도로 기록합니다.
|
||||
|
||||
**요구사항.**
|
||||
- REQ-PROVENANCE-01: 연구자는 주장에 출처 증거 참조를 표시해야 합니다.
|
||||
- REQ-PROVENANCE-02: 가정은 출처가 있는 주장과 별도로 기록되어야 합니다.
|
||||
- REQ-PROVENANCE-03: 시스템은 증거가 있는 사실과 추론된 가정을 구분해야 합니다.
|
||||
|
||||
**프로세스.**
|
||||
1. **연구** — 연구자가 코드베이스 및 도메인 소스에서 정보 수집
|
||||
2. **태그** — 각 주장에 출처(파일 경로, 문서, API 응답)를 주석으로 추가
|
||||
3. **분리** — 직접적 증거가 없는 가정을 별도 섹션에 기록
|
||||
|
||||
---
|
||||
|
||||
### 66. Worktree 토글
|
||||
|
||||
**구성:** `workflow.use_worktrees: false`
|
||||
|
||||
**목적:** 순차적 실행을 선호하는 사용자를 위해 git worktree 격리를 비활성화합니다.
|
||||
|
||||
**요구사항.**
|
||||
- REQ-WORKTREE-01: 시스템은 격리 전략 결정 시 `workflow.use_worktrees` 설정을 준수해야 합니다.
|
||||
- REQ-WORKTREE-02: 하위 호환성을 위해 기본값은 `true`(worktree 활성화)여야 합니다.
|
||||
- REQ-WORKTREE-03: worktree가 비활성화되면 순차적 실행으로 폴백해야 합니다.
|
||||
|
||||
**구성:**
|
||||
| 설정 | 유형 | 기본값 | 설명 |
|
||||
|------|------|--------|------|
|
||||
| `workflow.use_worktrees` | boolean | `true` | `false`이면 git worktree 격리 비활성화 |
|
||||
|
||||
---
|
||||
|
||||
### 67. 프로젝트 코드 접두사
|
||||
|
||||
**구성:** `project_code: "ABC"`
|
||||
|
||||
**목적:** 다중 프로젝트 구분을 위해 페이즈 디렉토리 이름에 프로젝트 코드를 접두사로 추가합니다.
|
||||
|
||||
**요구사항.**
|
||||
- REQ-PREFIX-01: 구성된 경우 시스템은 페이즈 디렉토리에 프로젝트 코드를 접두사로 추가해야 합니다(예: `ABC-01-setup/`).
|
||||
- REQ-PREFIX-02: `project_code`가 설정되지 않은 경우 표준 명명을 사용해야 합니다.
|
||||
- REQ-PREFIX-03: 모든 페이즈 작업에서 일관되게 접두사를 적용해야 합니다.
|
||||
|
||||
**구성:**
|
||||
| 설정 | 유형 | 기본값 | 설명 |
|
||||
|------|------|--------|------|
|
||||
| `project_code` | string | (없음) | 페이즈 디렉토리 이름의 접두사 |
|
||||
|
||||
---
|
||||
|
||||
### 68. Claude Code 스킬 마이그레이션
|
||||
|
||||
**대상:** `npx get-shit-done-cc`
|
||||
|
||||
**목적:** GSD 명령어를 하위 호환성을 유지하면서 Claude Code 2.1.88+ 스킬 형식으로 마이그레이션합니다.
|
||||
|
||||
**요구사항.**
|
||||
- REQ-SKILLS-01: 설치 프로그램은 Claude Code 2.1.88+ 용 `skills/gsd-*/SKILL.md`를 작성해야 합니다.
|
||||
- REQ-SKILLS-02: 설치 프로그램은 레거시 `commands/gsd/` 디렉토리를 자동 정리해야 합니다.
|
||||
- REQ-SKILLS-03: Gemini 경로를 통해 이전 Claude Code 버전과의 하위 호환성을 유지해야 합니다.
|
||||
|
||||
**프로세스.**
|
||||
1. **감지** — Claude Code 버전을 확인하여 스킬 지원 여부 판단
|
||||
2. **마이그레이션** — 각 GSD 명령어에 대해 `skills/gsd-*/SKILL.md` 파일 작성
|
||||
3. **정리** — 스킬이 설치되면 레거시 `commands/gsd/` 디렉토리 제거
|
||||
4. **폴백** — 이전 Claude Code 버전을 위한 Gemini 경로 호환성 유지
|
||||
|
||||
---
|
||||
|
||||
## v1.32 기능
|
||||
|
||||
### 69. STATE.md 일관성 게이트
|
||||
|
||||
**명령어:** `state validate`, `state sync [--verify]`, `state planned-phase --phase N --plans N`
|
||||
|
||||
**목적:** STATE.md와 실제 파일 시스템 간의 드리프트를 감지하고 복구하여 오래된 상태에서 발생하는 연쇄 오류를 방지합니다.
|
||||
|
||||
**요구사항.**
|
||||
- REQ-STATE-01: `state validate`는 STATE.md 필드와 파일 시스템 실제 상태 간의 드리프트를 감지해야 합니다.
|
||||
- REQ-STATE-02: `state sync`는 디스크의 실제 프로젝트 상태에서 STATE.md를 재구성해야 합니다.
|
||||
- REQ-STATE-03: `state sync --verify`는 쓰기 없이 제안된 변경 사항을 표시하는 드라이 런을 수행해야 합니다.
|
||||
- REQ-STATE-04: `state planned-phase`는 플랜 페이즈 완료 후 상태 전환을 기록해야 합니다(Planned/Ready to execute).
|
||||
|
||||
**생성 산출물.**
|
||||
| 산출물 | 설명 |
|
||||
|----------|-------------|
|
||||
| 업데이트된 `STATE.md` | 파일 시스템 실제 상태를 반영하는 수정된 상태 |
|
||||
|
||||
**프로세스.**
|
||||
1. **검증** — STATE.md 필드를 파일 시스템(페이즈 디렉토리, 계획 파일, 요약)과 비교
|
||||
2. **동기화** — 드리프트가 감지되면 디스크에서 STATE.md 재구성
|
||||
3. **전환** — 실행 페이즈 준비 상태로 계획 수와 함께 포스트 플래닝 상태 기록
|
||||
|
||||
---
|
||||
|
||||
### 70. 자율 모드 `--to N` 플래그
|
||||
|
||||
**플래그:** `/gsd-autonomous --to N`
|
||||
|
||||
**목적:** 특정 페이즈 완료 후 자율 실행을 중단하여 부분적 자율 실행을 가능하게 합니다.
|
||||
|
||||
**요구사항.**
|
||||
- REQ-TO-01: 시스템은 지정된 페이즈 번호 완료 후 실행을 중단해야 합니다.
|
||||
- REQ-TO-02: N까지의 각 페이즈에 대해 동일한 discuss → plan → execute 플로우를 따라야 합니다.
|
||||
- REQ-TO-03: `--to N`은 경계가 있는 자율 범위를 위해 `--from N`과 결합할 수 있어야 합니다.
|
||||
|
||||
**프로세스.**
|
||||
1. **경계 설정** — `--to N` 인수에서 상한 페이즈 설정
|
||||
2. **실행** — 페이즈 N까지(포함) 각 페이즈에 대해 자율 플로우 실행
|
||||
3. **중단** — 페이즈 N 완료 후 중단
|
||||
|
||||
---
|
||||
|
||||
### 71. 리서치 게이트
|
||||
|
||||
**대상:** `/gsd-plan-phase`
|
||||
|
||||
**목적:** RESEARCH.md에 미해결 오픈 질문이 있을 때 계획을 차단하여 불완전한 정보에 기반한 계획을 방지합니다.
|
||||
|
||||
**요구사항.**
|
||||
- REQ-RESGATE-01: 계획 시작 전 RESEARCH.md에서 미해결 오픈 질문을 스캔해야 합니다.
|
||||
- REQ-RESGATE-02: 오픈 질문이 존재하면 플랜 페이즈 진입을 차단해야 합니다.
|
||||
- REQ-RESGATE-03: 구체적인 미해결 질문을 사용자에게 표시해야 합니다.
|
||||
|
||||
**프로세스.**
|
||||
1. **스캔** — RESEARCH.md의 오픈 질문 섹션에서 미해결 항목 확인
|
||||
2. **게이트** — 미해결 질문이 발견되면 계획 차단
|
||||
3. **표시** — 해결이 필요한 구체적인 오픈 질문 표시
|
||||
|
||||
---
|
||||
|
||||
### 72. 검증자 마일스톤 범위 필터링
|
||||
|
||||
**대상:** `/gsd-execute-phase` (검증자 단계)
|
||||
|
||||
**목적:** 진정한 갭과 후속 페이즈로 연기된 항목을 구분하여 검증의 오탐을 줄입니다.
|
||||
|
||||
**요구사항.**
|
||||
- REQ-VSCOPE-01: 검증자는 갭이 후속 마일스톤 페이즈에서 다뤄지는지 확인해야 합니다.
|
||||
- REQ-VSCOPE-02: 후속 페이즈에서 다뤄지는 갭은 "갭"이 아닌 "연기"로 표시되어야 합니다.
|
||||
- REQ-VSCOPE-03: 진정한 갭(어떤 미래 페이즈에서도 다뤄지지 않는)만 실패로 보고되어야 합니다.
|
||||
|
||||
**프로세스.**
|
||||
1. **검증** — 표준 목표 역추적 검증 실행
|
||||
2. **필터** — 감지된 갭을 후속 마일스톤 페이즈와 교차 참조
|
||||
3. **분류** — 연기된 항목을 진정한 갭과 별도로 표시
|
||||
|
||||
---
|
||||
|
||||
### 73. Read-Before-Edit 가드 훅
|
||||
|
||||
**대상:** 훅 (`PreToolUse`)
|
||||
|
||||
**목적:** 파일이 편집 전에 읽혀지도록 하여 비-Claude 런타임에서의 무한 재시도 루프를 방지합니다.
|
||||
|
||||
**요구사항.**
|
||||
- REQ-RBE-01: 훅은 세션에서 이전에 읽히지 않은 파일을 대상으로 하는 Edit/Write 도구 호출을 감지해야 합니다.
|
||||
- REQ-RBE-02: 훅은 먼저 파일을 읽도록 권고해야 합니다(권고적, 비차단).
|
||||
- REQ-RBE-03: 훅은 내장 read-before-edit 강제가 없는 런타임에서 일반적인 무한 재시도 루프를 방지해야 합니다.
|
||||
|
||||
---
|
||||
|
||||
### 74. 컨텍스트 축소
|
||||
|
||||
**대상:** GSD SDK 프롬프트 어셈블리
|
||||
|
||||
**목적:** Markdown 절삭 및 캐시 친화적 프롬프트 순서를 통해 컨텍스트 프롬프트 크기를 줄입니다.
|
||||
|
||||
**요구사항.**
|
||||
- REQ-CTXRED-01: 시스템은 컨텍스트 예산 내에 맞도록 과대 Markdown 아티팩트를 절삭해야 합니다.
|
||||
- REQ-CTXRED-02: 캐시 친화적 어셈블리를 위해 프롬프트를 순서화해야 합니다(안정적 접두사 우선).
|
||||
- REQ-CTXRED-03: 축소는 필수 정보(제목, 요구사항, 작업 구조)를 보존해야 합니다.
|
||||
|
||||
**프로세스.**
|
||||
1. **측정** — 워크플로우의 총 프롬프트 크기 계산
|
||||
2. **절삭** — 과대 아티팩트에 Markdown 인식 절삭 적용
|
||||
3. **순서화** — KV 캐시 재사용 최적화를 위해 프롬프트 섹션 배치
|
||||
|
||||
---
|
||||
|
||||
### 75. 디스커스 페이즈 `--power` 플래그
|
||||
|
||||
**플래그:** `/gsd-discuss-phase --power`
|
||||
|
||||
**목적:** 디스커스 페이즈의 파일 기반 대량 질문 답변으로, 준비된 답변 파일에서 일괄 입력을 가능하게 합니다.
|
||||
|
||||
**요구사항.**
|
||||
- REQ-POWER-01: 시스템은 토론 질문에 대한 사전 작성된 답변이 포함된 파일을 수락해야 합니다.
|
||||
- REQ-POWER-02: 시스템은 답변을 해당 그레이 영역 질문에 매핑해야 합니다.
|
||||
- REQ-POWER-03: 시스템은 대화형 디스커스 페이즈와 동일한 CONTEXT.md를 생성해야 합니다.
|
||||
|
||||
---
|
||||
|
||||
### 76. 디버그 `--diagnose` 플래그
|
||||
|
||||
**플래그:** `/gsd-debug --diagnose`
|
||||
|
||||
**목적:** 수정을 시도하지 않고 조사만 수행하는 진단 전용 모드.
|
||||
|
||||
**요구사항.**
|
||||
- REQ-DIAG-01: 시스템은 완전한 디버그 조사(가설, 증거, 근본 원인)를 수행해야 합니다.
|
||||
- REQ-DIAG-02: 시스템은 어떤 코드 변경도 시도해서는 안 됩니다.
|
||||
- REQ-DIAG-03: 시스템은 발견 사항 및 권장 수정 사항이 포함된 진단 보고서를 생성해야 합니다.
|
||||
|
||||
---
|
||||
|
||||
### 77. 페이즈 의존성 분석
|
||||
|
||||
**명령어:** `/gsd-analyze-dependencies`
|
||||
|
||||
**목적:** 페이즈 의존성을 감지하고 `/gsd-manager` 실행 전 ROADMAP.md에 `Depends on` 항목을 제안합니다.
|
||||
|
||||
**요구사항.**
|
||||
- REQ-DEP-01: 시스템은 페이즈 간 파일 겹침을 감지해야 합니다.
|
||||
- REQ-DEP-02: 시스템은 의미적 의존성(API/스키마 생산자와 소비자)을 감지해야 합니다.
|
||||
- REQ-DEP-03: 시스템은 데이터 흐름 의존성(출력 생산자와 리더)을 감지해야 합니다.
|
||||
- REQ-DEP-04: 시스템은 의존성 항목을 제안하고 쓰기 전 사용자 확인을 요구해야 합니다.
|
||||
|
||||
**생성 산출물:** 의존성 제안 테이블; 선택적으로 ROADMAP.md의 `Depends on` 필드 업데이트
|
||||
|
||||
---
|
||||
|
||||
### 78. 안티패턴 심각도 레벨
|
||||
|
||||
**대상:** `/gsd-resume-work`
|
||||
|
||||
**목적:** 심각도 기반 안티패턴 강제를 통한 재개 시 필수 이해 검사.
|
||||
|
||||
**요구사항.**
|
||||
- REQ-ANTI-01: 시스템은 안티패턴을 심각도 레벨로 분류해야 합니다.
|
||||
- REQ-ANTI-02: 시스템은 세션 재개 시 필수 이해 검사를 강제해야 합니다.
|
||||
- REQ-ANTI-03: 높은 심각도의 안티패턴은 인정될 때까지 워크플로우 진행을 차단해야 합니다.
|
||||
|
||||
---
|
||||
|
||||
### 79. 방법론 아티팩트 유형
|
||||
|
||||
**대상:** 계획 아티팩트
|
||||
|
||||
**목적:** 방법론 문서의 소비 메커니즘을 정의하여 에이전트에 의해 올바르게 소비되도록 보장합니다.
|
||||
|
||||
**요구사항.**
|
||||
- REQ-METHOD-01: 시스템은 방법론을 고유한 아티팩트 유형으로 지원해야 합니다.
|
||||
- REQ-METHOD-02: 방법론 아티팩트는 에이전트를 위한 정의된 소비 메커니즘을 가져야 합니다.
|
||||
|
||||
---
|
||||
|
||||
### 80. 플래너 도달 가능성 검사
|
||||
|
||||
**대상:** `/gsd-plan-phase`
|
||||
|
||||
**목적:** 실행에 커밋하기 전에 계획 단계가 달성 가능한지 검증합니다.
|
||||
|
||||
**요구사항.**
|
||||
- REQ-REACH-01: 플래너는 각 계획 단계가 도달 가능한 파일과 API를 참조하는지 검증해야 합니다.
|
||||
- REQ-REACH-02: 도달 불가능한 단계는 실행 중이 아닌 계획 중에 플래그되어야 합니다.
|
||||
|
||||
---
|
||||
|
||||
### 81. Playwright-MCP UI 검증
|
||||
|
||||
**대상:** `/gsd-verify-work` (선택 사항)
|
||||
|
||||
**목적:** 검증 페이즈 중 Playwright-MCP를 사용한 자동 시각적 검증.
|
||||
|
||||
**요구사항.**
|
||||
- REQ-PLAY-01: 시스템은 검증 페이즈 중 선택적 Playwright-MCP 시각적 검증을 지원해야 합니다.
|
||||
- REQ-PLAY-02: 시각적 검증은 옵트인이어야 하며 필수가 아니어야 합니다.
|
||||
- REQ-PLAY-03: 시스템은 UI-SPEC.md 기대치에 대해 시각적 상태를 캡처하고 비교해야 합니다.
|
||||
|
||||
---
|
||||
|
||||
### 82. Pause-Work 확장
|
||||
|
||||
**대상:** `/gsd-pause-work`
|
||||
|
||||
**목적:** 더 풍부한 핸드오프 데이터로 비페이즈 컨텍스트를 지원하여 pause-work의 적용 범위를 확대합니다.
|
||||
|
||||
**요구사항.**
|
||||
- REQ-PAUSE-01: 시스템은 비페이즈 컨텍스트(빠른 작업, 디버그 세션, 스레드)에서의 일시 정지를 지원해야 합니다.
|
||||
- REQ-PAUSE-02: 핸드오프 데이터는 현재 작업 유형에 적절한 더 풍부한 컨텍스트를 포함해야 합니다.
|
||||
|
||||
---
|
||||
|
||||
### 83. 응답 언어 설정
|
||||
|
||||
**구성:** `response_language`
|
||||
|
||||
**목적:** 비영어권 사용자를 위한 크로스 페이즈 언어 일관성.
|
||||
|
||||
**요구사항.**
|
||||
- REQ-LANG-01: 시스템은 모든 페이즈와 에이전트에서 `response_language` 설정을 준수해야 합니다.
|
||||
- REQ-LANG-02: 설정은 모든 스폰된 에이전트에 전파되어 일관된 언어 출력을 보장해야 합니다.
|
||||
|
||||
**구성:**
|
||||
| 설정 | 유형 | 기본값 | 설명 |
|
||||
|------|------|--------|------|
|
||||
| `response_language` | string | (없음) | 에이전트 응답의 언어 코드 (예: `"pt"`, `"ko"`, `"ja"`) |
|
||||
|
||||
---
|
||||
|
||||
### 84. 수동 업데이트 절차
|
||||
|
||||
**대상:** `docs/manual-update.md`
|
||||
|
||||
**목적:** `npx`가 사용 불가하거나 npm 퍼블리시에 장애가 발생한 환경을 위한 수동 업데이트 경로를 문서화합니다.
|
||||
|
||||
**요구사항.**
|
||||
- REQ-MANUAL-01: 문서는 단계별 수동 업데이트 절차를 설명해야 합니다.
|
||||
- REQ-MANUAL-02: 절차는 npm 접근 없이 작동해야 합니다.
|
||||
|
||||
---
|
||||
|
||||
### 85. 신규 런타임 지원 (Trae, Cline, Augment Code)
|
||||
|
||||
**대상:** `npx get-shit-done-cc`
|
||||
|
||||
**목적:** Trae IDE, Cline, Augment Code 런타임으로 GSD 설치를 확장합니다.
|
||||
|
||||
**요구사항.**
|
||||
- REQ-TRAE-01: 설치 프로그램은 Trae IDE 설치를 위한 `--trae` 플래그를 지원해야 합니다.
|
||||
- REQ-CLINE-01: 설치 프로그램은 `.clinerules` 구성을 통해 Cline을 지원해야 합니다.
|
||||
- REQ-AUGMENT-01: 설치 프로그램은 스킬 변환 및 구성 관리를 통해 Augment Code를 지원해야 합니다.
|
||||
|
||||
@@ -13,14 +13,14 @@ Get Shit Done (GSD) 프레임워크의 종합 문서입니다. GSD는 AI 코딩
|
||||
| [Command Reference](COMMANDS.md) | 전체 사용자 | 모든 명령어의 구문, 플래그, 옵션 및 예제 |
|
||||
| [Configuration Reference](CONFIGURATION.md) | 전체 사용자 | 전체 설정 스키마, 워크플로우 토글, 모델 프로필, git 브랜칭 |
|
||||
| [CLI Tools Reference](CLI-TOOLS.md) | 기여자, 에이전트 작성자 | 워크플로우 및 에이전트를 위한 `gsd-tools.cjs` 프로그래매틱 API |
|
||||
| [Agent Reference](AGENTS.md) | 기여자, 고급 사용자 | 15개 전문 에이전트의 역할, 도구, 스폰 패턴 |
|
||||
| [Agent Reference](AGENTS.md) | 기여자, 고급 사용자 | 18개 전문 에이전트의 역할, 도구, 스폰 패턴 |
|
||||
| [User Guide](USER-GUIDE.md) | 전체 사용자 | 워크플로우 안내, 문제 해결, 복구 방법 |
|
||||
| [Context Monitor](context-monitor.md) | 전체 사용자 | 컨텍스트 윈도우 모니터링 훅 아키텍처 |
|
||||
| [Discuss Mode](workflow-discuss-mode.md) | 전체 사용자 | discuss 단계의 assumptions 모드와 interview 모드 |
|
||||
|
||||
## 빠른 링크
|
||||
|
||||
- **v1.28의 새로운 기능:** Forensics, milestone 요약, workstream, assumptions 모드, UI 자동 감지, manager 대시보드
|
||||
- **v1.32의 새로운 기능:** STATE.md 일관성 게이트, `--to N` 자율 모드, 리서치 게이트, 검증자 마일스톤 범위 필터링, read-before-edit 가드, 컨텍스트 축소, 신규 런타임(Trae, Cline, Augment Code), 응답 언어 설정, `--power`/`--diagnose` 플래그, `/gsd-analyze-dependencies`
|
||||
- **시작하기:** [README](../README.md) → 설치 → `/gsd-new-project`
|
||||
- **전체 워크플로우 안내:** [User Guide](USER-GUIDE.md)
|
||||
- **모든 명령어 한눈에 보기:** [Command Reference](COMMANDS.md)
|
||||
|
||||
@@ -41,8 +41,10 @@ Cada agente tem responsabilidade clara, entradas/saídas definidas e contexto de
|
||||
|
||||
### Diagnóstico
|
||||
|
||||
- **Debugger**: identifica causa-raiz quando há falhas
|
||||
- **Debugger**: identifica causa-raiz quando há falhas (`--diagnose` para modo somente diagnóstico, v1.32)
|
||||
- **Forensics**: investiga inconsistências de estado/artefatos/histórico
|
||||
- **Security auditor**: verificação de segurança por threat model (v1.31)
|
||||
- **Doc writer / Doc verifier**: geração e validação de documentação (v1.31)
|
||||
|
||||
## Padrões operacionais
|
||||
|
||||
|
||||
@@ -62,6 +62,10 @@ Entrada (/gsd-comando)
|
||||
- hooks de guarda para escrita/edição sensível
|
||||
- scanner CI para padrões de risco
|
||||
|
||||
## Runtimes suportados (v1.32)
|
||||
|
||||
Claude Code, Gemini CLI, OpenCode, Kilo, Codex, Copilot, Antigravity, Trae, Cline, Augment Code.
|
||||
|
||||
## Extensibilidade
|
||||
|
||||
GSD suporta evolução por:
|
||||
|
||||
@@ -10,7 +10,7 @@ Para detalhes completos de flags avançadas e mudanças recentes, consulte tamb
|
||||
| Comando | Finalidade | Quando usar |
|
||||
|---------|------------|-------------|
|
||||
| `/gsd-new-project` | Inicialização completa: perguntas, pesquisa, requisitos e roadmap | Início de projeto |
|
||||
| `/gsd-discuss-phase [N]` | Captura decisões de implementação | Antes do planejamento |
|
||||
| `/gsd-discuss-phase [N]` | Captura decisões de implementação (`--chain`, `--power`) | Antes do planejamento |
|
||||
| `/gsd-ui-phase [N]` | Gera contrato de UI (`UI-SPEC.md`) | Fases com frontend |
|
||||
| `/gsd-plan-phase [N]` | Pesquisa + planejamento + verificação | Antes de executar uma fase |
|
||||
| `/gsd-execute-phase <N>` | Executa planos em ondas paralelas | Após planejamento aprovado |
|
||||
@@ -27,6 +27,7 @@ Para detalhes completos de flags avançadas e mudanças recentes, consulte tamb
|
||||
| `/gsd-resume-work` | Retoma contexto da sessão anterior |
|
||||
| `/gsd-pause-work` | Salva handoff estruturado |
|
||||
| `/gsd-session-report` | Gera resumo da sessão |
|
||||
| `/gsd-autonomous` | Executa todas as fases restantes de forma autônoma (`--from N`, `--to N`, `--only N`) |
|
||||
| `/gsd-help` | Lista comandos e uso |
|
||||
| `/gsd-update` | Atualiza o GSD |
|
||||
|
||||
@@ -46,7 +47,8 @@ Para detalhes completos de flags avançadas e mudanças recentes, consulte tamb
|
||||
|---------|------------|
|
||||
| `/gsd-map-codebase` | Mapeia base existente antes de novo projeto |
|
||||
| `/gsd-quick` | Tarefas ad-hoc com garantias do GSD |
|
||||
| `/gsd-debug [desc]` | Debug sistemático com estado persistente |
|
||||
| `/gsd-debug [desc]` | Debug sistemático com estado persistente (`--diagnose` para modo diagnóstico) |
|
||||
| `/gsd-analyze-dependencies` | Detecta dependências entre fases e sugere `Depends on` no ROADMAP.md (v1.32) |
|
||||
| `/gsd-forensics` | Diagnóstico de falhas no workflow |
|
||||
| `/gsd-settings` | Configuração de agentes, perfil e toggles |
|
||||
| `/gsd-set-profile <perfil>` | Troca rápida de perfil de modelo |
|
||||
|
||||
@@ -82,3 +82,20 @@ Troca rápida:
|
||||
```bash
|
||||
/gsd-set-profile budget
|
||||
```
|
||||
|
||||
## Novidades de configuração v1.31--v1.32
|
||||
|
||||
| Chave | Tipo | Padrão | Descrição |
|
||||
|------|------|--------|-----------|
|
||||
| `workflow.use_worktrees` | boolean | `true` | Desativa isolamento por git worktree quando `false` (v1.31) |
|
||||
| `security_enforcement` | boolean | `true` | Ativa verificação de segurança ancorada em threat model (v1.31) |
|
||||
| `security_asvs_level` | number (1-3) | `1` | Nível de verificação OWASP ASVS (v1.31) |
|
||||
| `security_block_on` | string | `"high"` | Severidade mínima para bloquear avanço de fase (v1.31) |
|
||||
| `response_language` | string | (nenhum) | Código de idioma para saída dos agentes (ex: `"pt"`, `"ko"`, `"ja"`) (v1.32) |
|
||||
| `project_code` | string | (nenhum) | Prefixo para diretórios de fase (ex: `"ABC"` -> `ABC-01-setup/`) (v1.31) |
|
||||
|
||||
**Variáveis de ambiente adicionais:**
|
||||
|
||||
| Variável | Finalidade |
|
||||
|----------|------------|
|
||||
| `GSD_SKIP_SCHEMA_CHECK` | Desativa detecção de schema drift (v1.31) |
|
||||
|
||||
@@ -39,6 +39,27 @@ Para catálogo completo e detalhamento exaustivo, consulte [FEATURES.md em ingl
|
||||
- **Diagnóstico forense** com `/gsd-forensics`
|
||||
- **Relatório de sessão** com `/gsd-session-report`
|
||||
|
||||
## Novidades v1.31--v1.32
|
||||
|
||||
- **Schema drift detection** — detecta alterações em ORM schema sem migração correspondente
|
||||
- **Security enforcement** — verificação de segurança ancorada em threat model (`/gsd-secure-phase`)
|
||||
- **Discuss chain mode** — encadeia discuss → plan → execute com `--chain`
|
||||
- **Single-phase autonomous** — executa apenas uma fase com `--only N`
|
||||
- **Scope reduction detection** — defesa em 3 camadas contra remoção silenciosa de requisitos
|
||||
- **Worktree toggle** — desativa isolamento via `workflow.use_worktrees: false`
|
||||
- **STATE.md consistency gates** — detecta/repara drift entre STATE.md e filesystem (v1.32)
|
||||
- **Autonomous `--to N`** — para execução autônoma após fase N (v1.32)
|
||||
- **Research gate** — bloqueia planejamento quando RESEARCH.md tem questões abertas (v1.32)
|
||||
- **Verifier milestone scope filtering** — distingue gaps reais de itens deferidos (v1.32)
|
||||
- **Read-before-edit guard** — hook que previne loops infinitos de retry (v1.32)
|
||||
- **Context reduction** — truncamento de markdown e ordenação cache-friendly (v1.32)
|
||||
- **`--power` flag** — respostas em batch via arquivo para discuss-phase (v1.32)
|
||||
- **`--diagnose` flag** — modo diagnóstico sem modificações no `/gsd-debug` (v1.32)
|
||||
- **`/gsd-analyze-dependencies`** — detecta dependências entre fases (v1.32)
|
||||
- **Response language config** — `response_language` para saída consistente em idioma (v1.32)
|
||||
- **Novos runtimes** — Trae IDE, Cline, Augment Code (v1.32)
|
||||
- **Manual update** — procedimento de atualização sem npm (v1.32)
|
||||
|
||||
---
|
||||
|
||||
## Atalhos recomendados por cenário
|
||||
|
||||
@@ -18,6 +18,10 @@ Documentação abrangente do framework Get Shit Done (GSD) — um sistema de met
|
||||
| [Referências](references/) | Todos os usuários | Guias complementares de decisão, verificação e padrões |
|
||||
| [Superpowers](superpowers/) | Contribuidores | Planos e specs avançadas do projeto |
|
||||
|
||||
## Novidades v1.32
|
||||
|
||||
STATE.md consistency gates, `--to N` para execução autônoma parcial, research gate, verifier milestone scope filtering, read-before-edit guard, context reduction, novos runtimes (Trae, Cline, Augment Code), `response_language`, `--power`/`--diagnose` flags, `/gsd-analyze-dependencies`.
|
||||
|
||||
## Links rápidos
|
||||
|
||||
- **Começar rápido:** [README principal](../../README.pt-BR.md) -> instalação -> `/gsd-new-project`
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
# GET SHIT DONE
|
||||
|
||||
**一个轻量级且强大的元提示、上下文工程和规格驱动开发系统,支持 Claude Code、OpenCode、Gemini CLI、Kilo、Codex、Copilot、Cursor、Windsurf、Antigravity 和 Augment。**
|
||||
**一个轻量级且强大的元提示、上下文工程和规格驱动开发系统,支持 Claude Code、OpenCode、Gemini CLI、Kilo、Codex、Copilot、Cursor、Windsurf、Antigravity、Augment、Trae 和 Cline。**
|
||||
|
||||
**解决上下文衰减 —— 即 Claude 填充上下文窗口时发生的质量退化问题。**
|
||||
|
||||
@@ -484,7 +484,7 @@ lmn012o feat(08-02): 创建注册端点
|
||||
| 命令 | 作用 |
|
||||
|---------|--------------|
|
||||
| `/gsd-new-project [--auto]` | 完整初始化:提问 → 研究 → 需求 → 路线图 |
|
||||
| `/gsd-discuss-phase [N] [--auto] [--chain]` | 在规划前捕获实现决策(`--chain` 自动链式执行规划+执行) |
|
||||
| `/gsd-discuss-phase [N] [--auto] [--chain] [--power]` | 在规划前捕获实现决策(`--chain` 自动链式执行规划+执行,`--power` 文件批量输入) |
|
||||
| `/gsd-plan-phase [N] [--auto]` | 阶段的研究 + 规划 + 验证 |
|
||||
| `/gsd-execute-phase <N>` | 在并行波次中执行所有计划,完成后验证 |
|
||||
| `/gsd-verify-work [N]` | 手动用户验收测试 ¹ |
|
||||
@@ -516,6 +516,8 @@ lmn012o feat(08-02): 创建注册端点
|
||||
| `/gsd-remove-phase [N]` | 删除未来阶段,重新编号 |
|
||||
| `/gsd-list-phase-assumptions [N]` | 规划前查看 Claude 的预期方法 |
|
||||
| `/gsd-plan-milestone-gaps` | 创建阶段以填补审计发现的差距 |
|
||||
| `/gsd-autonomous [--from N] [--to N] [--only N]` | 自主执行所有剩余阶段(`--to N` 执行到阶段 N 停止,`--only N` 只执行单个阶段) |
|
||||
| `/gsd-analyze-dependencies` | 检测阶段间依赖关系并建议 ROADMAP.md 的 `Depends on` 条目 |
|
||||
|
||||
### 会话
|
||||
|
||||
@@ -532,7 +534,7 @@ lmn012o feat(08-02): 创建注册端点
|
||||
| `/gsd-set-profile <profile>` | 切换模型配置文件(quality/balanced/budget) |
|
||||
| `/gsd-add-todo [desc]` | 捕获想法留待后用 |
|
||||
| `/gsd-check-todos` | 列出待处理事项 |
|
||||
| `/gsd-debug [desc]` | 带持久状态的系统化调试 |
|
||||
| `/gsd-debug [desc] [--diagnose]` | 带持久状态的系统化调试(`--diagnose` 仅诊断不修复) |
|
||||
| `/gsd-quick [--full] [--discuss] [--research]` | 用 GSD 保证执行临时任务(`--full` 启用全部阶段,`--discuss` 先收集上下文,`--research` 规划前调查方法) |
|
||||
| `/gsd-health [--repair]` | 验证 `.planning/` 目录完整性,用 `--repair` 自动修复 |
|
||||
|
||||
@@ -578,6 +580,9 @@ GSD 在 `.planning/config.json` 中存储项目设置。在 `/gsd-new-project`
|
||||
| `workflow.plan_check` | `true` | 执行前验证计划是否达到阶段目标 |
|
||||
| `workflow.verifier` | `true` | 执行后确认必须项已交付 |
|
||||
| `workflow.auto_advance` | `false` | 自动链式执行 讨论 → 规划 → 执行 |
|
||||
| `workflow.use_worktrees` | `true` | `false` 时禁用 git worktree 隔离 |
|
||||
| `security_enforcement` | `true` | 启用威胁模型安全验证 |
|
||||
| `response_language` | (无) | 代理响应的语言代码(如 `"zh"`、`"ja"`、`"ko"`) |
|
||||
|
||||
使用 `/gsd-settings` 切换这些,或每次调用时覆盖:
|
||||
- `/gsd-plan-phase --skip-research`
|
||||
|
||||
@@ -182,7 +182,7 @@
|
||||
|---------|---------|-------------|
|
||||
| `/gsd-new-project` | 完整项目初始化:提问、研究、需求、路线图 | 新项目开始时 |
|
||||
| `/gsd-new-project --auto @idea.md` | 从文档自动初始化 | 有现成的 PRD 或想法文档 |
|
||||
| `/gsd-discuss-phase [N]` | 捕获实现决策 | 规划前,塑造构建方式 |
|
||||
| `/gsd-discuss-phase [N] [--chain] [--power]` | 捕获实现决策(`--chain` 自动链式,`--power` 文件批量输入) | 规划前,塑造构建方式 |
|
||||
| `/gsd-plan-phase [N]` | 研究 + 规划 + 验证 | 执行阶段前 |
|
||||
| `/gsd-execute-phase <N>` | 在并行波次中执行所有计划 | 规划完成后 |
|
||||
| `/gsd-verify-work [N]` | 带自动诊断的手动 UAT | 执行完成后 |
|
||||
@@ -211,6 +211,8 @@
|
||||
| `/gsd-list-phase-assumptions [N]` | 预览 Claude 的预期方法 | 规划前,验证方向 |
|
||||
| `/gsd-plan-milestone-gaps` | 为审计缺口创建阶段 | 审计发现缺失项后 |
|
||||
| `/gsd-research-phase [N]` | 仅深度生态研究 | 复杂或不熟悉的领域 |
|
||||
| `/gsd-autonomous [--from N] [--to N] [--only N]` | 自主执行剩余阶段(`--to N` 到阶段 N 停止) | 批量自动处理 |
|
||||
| `/gsd-analyze-dependencies` | 检测阶段间依赖关系 | `/gsd-manager` 前分析 |
|
||||
|
||||
### 现有代码库和工具
|
||||
|
||||
@@ -218,7 +220,7 @@
|
||||
|---------|---------|-------------|
|
||||
| `/gsd-map-codebase` | 分析现有代码库 | 在现有代码上运行 `/gsd-new-project` 之前 |
|
||||
| `/gsd-quick` | 带 GSD 保证的临时任务 | Bug 修复、小功能、配置更改 |
|
||||
| `/gsd-debug [desc]` | 带持久状态的系统化调试 | 出问题时 |
|
||||
| `/gsd-debug [desc] [--diagnose]` | 带持久状态的系统化调试(`--diagnose` 仅诊断) | 出问题时 |
|
||||
| `/gsd-add-todo [desc]` | 捕获想法留待后用 | 会话期间想到什么 |
|
||||
| `/gsd-check-todos` | 列出待处理事项 | 查看捕获的想法 |
|
||||
| `/gsd-settings` | 配置工作流开关和模型配置 | 更改模型、切换代理 |
|
||||
|
||||
Reference in New Issue
Block a user