GSD 実践ガイド

はじめに

前回の記事では、GSD のコア原理 ── コンテキストエンジニアリング、サブエージェントオーケストレーション、ゴール逆算型プランニング、アトミックコミット ── を深く理解しました。これらの理念は美しく聞こえますが、「原理を理解する」から「実際にプロジェクトを動かす」までの間には多くの操作上のディテールがあります。

この記事では、実際に手を動かしていきます。GSD の完全なコマンド体系、設定オプション、出力ファイル構造、そしてゼロから完全な機能を納品する方法を学びます。

インストールと設定

インストール

npx get-shit-done-cc@latest

インストーラーは以下の選択を求めます：

1. ランタイム ── Claude Code、OpenCode、Gemini CLI、または全て
2. スコープ ── グローバル（全プロジェクト）またはローカル（現在のプロジェクト）

インストール後、ランタイムで /gsd:help と入力してインストール成功を確認してください。

推奨：パーミッションスキップモード

GSD は摩擦のない自動化のために設計されています。Claude Code の推奨実行方法は以下の通りです：

claude --dangerously-skip-permissions

このフラグを使いたくない場合は、.claude/settings.json で細かい権限を設定できます。

アップデート

/gsd:update

GSD のアップデートは非常に頻繁です（TÂCHES はほぼ毎日15〜20回の更新をプッシュしています）。最新バージョンを維持するために、定期的にこのコマンドを実行することをお勧めします。

完全コマンドリファレンス

GSD のすべてのインタラクションは /gsd: プレフィックス付きのスラッシュコマンドで行います。以下に機能別の完全なリファレンスを示します。

コアワークフローコマンド

この5つのコマンドが GSD のメインループを構成し、順番に使用します。

[N] はオプションパラメータです ── 省略するとシステムが現在のフェーズを自動検出します。<N> は必須パラメータです。

マイルストーン管理

フェーズ管理

Quick Mode とツール

セッションと設定管理

設定詳細

モデルプロファイル

GSD は3つのモデルプロファイルをサポートしており、/gsd:set-profile で切り替えられます：

コア設定

/gsd:settings で以下の設定を表示・変更できます：

ワークフロートグル

以下のエージェントは個別にオン・オフを切り替えられ、速度と品質のトレードオフが可能です：

research と plan_check を無効にすると大幅な高速化が可能ですが、プランニング品質が低下する可能性があります。プロジェクトに慣れてから無効化を検討することをお勧めします。

出力ファイル構造

GSD のすべての状態と出力は .planning/ ディレクトリに保存されます。この構造を理解しておくと、デバッグや手動介入に役立ちます。

プロジェクトレベルファイル

フェーズレベルファイル

各フェーズは以下のファイルを生成します（フェーズ1を例として）：

ディレクトリ構造例

.planning/
├── PROJECT.md
├── REQUIREMENTS.md
├── ROADMAP.md
├── STATE.md
├── research/
│   ├── tech-stack.md
│   ├── features.md
│   ├── architecture.md
│   └── pitfalls.md
├── 01-CONTEXT.md
├── 01-RESEARCH.md
├── 01-01-PLAN.md
├── 01-02-PLAN.md
├── 01-01-SUMMARY.md
├── 01-02-SUMMARY.md
├── 01-VERIFICATION.md
├── 01-UAT.md
├── 02-CONTEXT.md
├── 02-RESEARCH.md
├── 02-01-PLAN.md
│   ...
└── todos.md

実戦ワークフローデモ

以下では「ブログシステムにコメント機能を追加する」を例に、初期化から納品までの完全なフローを紹介します。

Step 1: プロジェクトの初期化

/gsd:new-project

システムが継続的に質問を始めます：

> 何を構築したいですか？
「Next.js ブログにコメント機能を追加したいです。匿名とログインの両方のコメント、
 Markdown レンダリング、管理パネルをサポート。技術スタックは Prisma + PostgreSQL。」

説明が詳細であればあるほど、システムからの追加質問は少なくなります。TÂCHES のアドバイスは：大まかなビジョンドキュメントを準備して、何が欲しいかを説明すること ── 技術的な詳細を知っている必要はありません。

システムが完了すると4つのファイルを生成し、ロードマップの承認を求めます。承認後、構築フェーズに入ります。

既存のコードベースがある場合は？ まず /gsd:map-codebase を実行してください。システムが既存のアーキテクチャとコーディング規約を分析し、その後 new-project が既存のコードに基づいてプランニングできるようになります。

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

/gsd:discuss-phase 1

システムがグレーゾーンを特定し、一つずつ質問します：

> コメントのネスト：多階層ネストをサポートしますか、それとも1階層のリプライのみですか？
> 匿名コメント：CAPTCHA を要求しますか、それとも直接投稿ですか？
> 管理パネル：一括操作が必要ですか、それとも1件ずつの審査ですか？

ここでの一つ一つの決定が、その後のプランニング品質に直接影響します。不確かな場合はシステムにデフォルト値を使わせることもできますが、深い議論をすることで実行フェーズでの手戻りが大幅に減少します。

Step 3: プランニングフェーズ

/gsd:plan-phase 1

システムは以下を行います：

1. Prisma + PostgreSQL でコメントシステムを実装する方法をリサーチ
2. 2〜3個のアトミックタスク計画を作成（例：データモデル、API ルート、フロントエンドコンポーネント）
3. 計画が全ての要件をカバーしているか自動検証

各計画は、一つの新しいコンテキストウィンドウ内で完了できるほど小さく設計されています。

Step 4: 実行フェーズ

/gsd:execute-phase 1

システムがウェーブ実行を開始します：

• Wave 1（依存関係なし）：データベーススキーマ、Prisma モデル ── 並列実行
• Wave 2（Wave 1 に依存）：API ルート、コメント CRUD ── 並列実行
• Wave 3（Wave 2 に依存）：フロントエンドコメントコンポーネント ── 独立実行

各タスクは新しい 200k tokens のコンテキストで実行され、独立した git commit が作成されます。

Step 5: 検証フェーズ

/gsd:verify-work 1

システムが一つずつ確認を案内します：

> ✅ データベーステーブルが作成されました
> ✅ API ルートが正しいステータスコードを返しています
> ❓ ブログ記事の下にコメント入力欄が表示されていますか？ [はい/いいえ/問題を説明]
> ❓ コメント投稿後、ページがリアルタイムに更新されますか？ [はい/いいえ/問題を説明]

失敗した項目がある場合、システムが自動的に診断して修正計画を作成します。再度 /gsd:execute-phase 1 を実行すれば修正が実行されます。

よくある操作シナリオ

緊急フェーズの挿入：要件が変更され、現在のフェーズの前に新しい作業を挿入する必要がある場合。

/gsd:insert-phase 2

後続のフェーズは自動的に再ナンバリングされます（元の Phase 2 が Phase 3 に、以下同様）。

一時停止と再開：他の作業を処理するために中断する必要がある場合。

/gsd:pause-work    # 現在の状態を保存
# ... 他の作業を処理 ...
/gsd:resume-work   # 中断した箇所から再開

不満な結果のロールバック：

git reset --hard HEAD~3    # 実行前の状態に戻る

/gsd:remove-phase 2        # このフェーズの全出力ファイルをカスケード削除

TÂCHES はライブ配信でこの操作を何度も実演しています ── 気に入らなければロールバック、潔く明快です。

デバッグワークフロー

検証で問題が見つかったとき、または開発中にバグに遭遇したとき、GSD は専用のデバッグフローを提供します。

/gsd:debug コメント投稿後にページがリアルタイム更新されない

システムは隔離されたデバッグサブエージェントを起動し、以下のワークフローで対処します：

1. 仮説 ── 問題の説明に基づいて複数の根本原因の仮説を生成
2. 証拠収集 ── 仮説を一つずつ検証し、コード、ログ、ネットワークリクエストをチェック
3. 解決 ── 根本原因を特定した後、修正計画を作成

主要な特徴：

• コンテキスト隔離：デバッグエージェントは独自のコンテキストウィンドウを持ち、メインの開発コンテキストを汚染しません
• ドキュメント追跡：調査プロセス全体を記録する独立したデバッグドキュメントを作成
• 修正計画：診断完了後、直接実行可能な修正計画を出力

これはメインコンテキストで直接デバッグするよりもはるかに効率的です ── デバッグ情報がメインウィンドウに蓄積されません。

実戦から得た知見

TÂCHES のライブ配信と Chase AI の使用体験を総合した、実戦的なアドバイスをご紹介します。

急がば回れ

TÂCHES は、GSD を使い始めた当初は「速く、速く、速く」というマインドセットだったと率直に語っていますが、後になってリサーチとディスカッションフェーズに時間をかけるほうが、実行フェーズでの手戻りが減ることに気づきました。新しいバージョンの GSD に research-project と define-requirements のステップが追加されたのは、まさにコードを書く前に方向性を正しく定めるためです。

"I was definitely when I first started doing things with GSD, I was very much like move fast, move fast, move fast. But I'm just finding that taking these extra steps... I think you're going to really really love to see the results."

—— TÂCHES

フェーズ間でコンテキストをクリア

TÂCHES の習慣は、フェーズごとに clear を実行することで、メインコンテキストをスリムに保つことです。彼は Warp ターミナルを使用し、各ウィンドウをフルスクリーン（Command+Shift+Enter）にして、一つのウィンドウで現在のフェーズを実行しながら、別のウィンドウで次のフェーズのリサーチを行っています。

Token コストのトレードオフ

GSD のサブエージェント方式は、Claude Code を直接使用するよりも確かに多くの token を消費します。しかし Chase AI は説得力のある論点を提示しています：「plan twice, prompt once（2回計画して、1回プロンプト）」は、「1回プロンプトして、パッチの繰り返し」よりも長期的にはコスト効率が良いということです。新鮮なコンテキストで一発で正しく仕上げるほうが、劣化したコンテキストで繰り返し修正するよりもはるかに効率的です。

不満な結果への対処

フェーズの結果に満足できない場合は、git reset --hard してから /gsd:remove-phase でそのフェーズの全出力ファイルをカスケード削除できます。TÂCHES はライブ配信でこの操作を実演しています ── ある視覚効果が気に入らず、前の満足できる状態まで直接ロールバックしました。潔く明快です。

To-Do システム

/gsd:add-todo を使えば、ロードマップを変更することなく、いつでもアイデアを To-Do リストに記録できます。これらのアイデアは /gsd:discuss-milestone の際に取り出され、次のマイルストーンのインプットとして活用できます。TÂCHES の戦略は「まず機能を作り、マイルストーン2で UI を磨く」です。

FAQ とベストプラクティス

ベストプラクティス

詳細な初期説明を提供しましょう。 /gsd:new-project の品質は、あなたのインプットの品質に依存します。大まかなビジョンドキュメントを準備してください ── 目標、ユーザー、コア機能、既知の制約を記述します。説明が正確であればあるほど、システムからの追加質問は少なくなり、プランニングの精度が上がります。

フェーズ間でコンテキストをクリアしましょう。 各フェーズ完了後、clear または /compact を実行してメインコンテキストウィンドウをスリムに保ちます。TÂCHES の習慣は、メインコンテキストを30〜40%に維持することです。

まず Quick Mode でテストしましょう。 不確かな小さな機能には、まず /gsd:quick で試してみましょう。うまくいけば、正式なロードマップに組み込みます。

既存プロジェクトではまず map-codebase を実行しましょう。 既存のコードベースで GSD を使用する前に、/gsd:map-codebase を実行してください。システムが技術スタック、アーキテクチャ、コーディング規約を分析し、その後のプランニングが既存コードにより適合したものになります。

FAQ

Q: GSD はどのランタイムに対応していますか？

A: Claude Code、OpenCode、Gemini CLI です。インストール時に単体または全てを選択できます。

Q: Quick Mode と通常モードの違いは何ですか？

A: Quick Mode は GSD の基本的な保護機能（アトミックコミット、状態追跡）を提供しますが、リサーチ、計画チェック、検証のステップをスキップします。完全なプランニングが不要なバグ修正、小さな機能追加、設定変更などに最適です。

Q: 実行中に一時停止できますか？

A: はい。/gsd:pause-work で現在の状態を STATE.md に保存します。次回 /gsd:resume-work を実行すると、システムは中断した箇所から続行します。

Q: Token コストはどう制御しますか？

A: 3つの方法があります ── (1) budget プロファイルに切り替える：/gsd:set-profile budget、(2) research や plan_check エージェントを無効にする、(3) シンプルなタスクには /gsd:quick を使用する。

Q: GSD と Ralph は一緒に使えますか？

A: はい。GSD と Ralph は異なる問題を解決します ── GSD はプランニングと構造化された実行を担当し、Ralph は自律的なループ実行を担当します。GSD の new-project と plan-phase で完全な計画を生成し、人間の介入が不要なフェーズは Ralph ループで実行するという使い方ができます。

Q: 複数人でのコラボレーションはどうすればいいですか？

A: .planning/ ディレクトリを Git にコミットできます。複数人がそれぞれ異なるフェーズを実行し、Git でマージすることが可能です。ただし、同じフェーズを同時に実行することは避けてください。

まとめ

GSD のコアバリューは、複雑さをシステム内に隠し、ユーザーにはシンプルさを提供することにあります。必要なコマンドはわずか ── new-project、discuss-phase、plan-phase、execute-phase、verify-work ── で、システムが裏側で全てのコンテキスト管理、サブエージェントオーケストレーション、品質検証を処理します。

インストールから納品まで、GSD は明確なパスを提供します：何が欲しいかを記述 → 実装の詳細を議論 → アトミック計画を生成 → 並列実行 → 成果物を検証。すべてのステップであなたが介入する機会があり、すべてのステップがドキュメントに記録されます。

これは「ボタンを一つ押せば全て完了」という魔法ではありません。あなたの参加が必要ですが、認知的負荷の大部分を引き受けてくれるシステムです。TÂCHES が言うように：あなたは上級プロジェクトマネージャーであり、GSD はあなたの実行チームです。

関連記事：

• GSD 深掘り解析 ── コア原理、ワークフロー、技術アーキテクチャ
• Ralph Wiggum 深掘り解析 ── Context Rot と Ralph の方法論
• snarktank/ralph 実戦ガイド ── Ralph のインストール、PRD の書き方と実戦
• スペック駆動開発とは ── Vibe Coding からスペック駆動開発へ
• Speckit 実践ガイド ── Speckit コマンド詳解と完全な事例