English · Português · 简体中文 · 日本語
Claude Code、OpenCode、Gemini CLI、Kilo、Codex、Copilot、Cursor、Windsurf、Antigravity、Augment、Trae、Cline向けの軽量かつ強力なメタプロンプティング、コンテキストエンジニアリング、仕様駆動開発システム。
コンテキストロット(Claudeがコンテキストウィンドウを消費するにつれ品質が劣化する現象)を解決します。
npx get-shit-done-cc@latestMac、Windows、Linuxで動作します。
「自分が何を作りたいか明確に分かっていれば、これが確実に作ってくれる。嘘じゃない。」
「SpecKit、OpenSpec、Taskmasterを試してきたが、これが一番良い結果を出してくれた。」
「Claude Codeへの最強の追加ツール。過剰な設計は一切なし。文字通り、やるべきことをやってくれる。」
Amazon、Google、Shopify、Webflowのエンジニアに信頼されています。
私はソロ開発者です。コードは自分で書きません — Claude Codeが書きます。
仕様駆動開発ツールは他にもあります。BMAD、Spekkitなど。しかしどれも必要以上に複雑にしているように見えます(スプリントセレモニー、ストーリーポイント、ステークホルダーとの同期、振り返り、Jiraワークフローなど)。あるいは、何を作ろうとしているのかの全体像を本当には理解していません。私は50人規模のソフトウェア会社ではありません。エンタープライズごっこをしたいわけではありません。ただ、うまく動く素晴らしいものを作りたいクリエイティブな人間です。
だからGSDを作りました。複雑さはシステムの中にあり、ワークフローの中にはありません。裏側では、コンテキストエンジニアリング、XMLプロンプトフォーマッティング、サブエージェントのオーケストレーション、状態管理が動いています。あなたが目にするのは、ただ動くいくつかのコマンドだけです。
このシステムは、Claudeが仕事をし、かつ検証するために必要なすべてを提供します。私はこのワークフローを信頼しています。ちゃんといい仕事をしてくれます。
これがGSDです。エンタープライズごっこは一切なし。Claude Codeを使って一貫してクールなものを作るための、非常に効果的なシステムです。
— TÂCHES
バイブコーディングは評判が悪い。やりたいことを説明し、AIがコードを生成し、スケールすると崩壊する一貫性のないゴミが出来上がる。
GSDはそれを解決します。Claude Codeを信頼性の高いものにするコンテキストエンジニアリングレイヤーです。アイデアを説明し、システムに必要なすべてを抽出させ、Claude Codeに仕事をさせましょう。
やりたいことを説明するだけで正しく構築してほしい人 — 50人のエンジニア組織を運営しているふりをせずに。
ビルトインの品質ゲートが本当の問題を検出します:スキーマドリフト検出はマイグレーション漏れのORM変更をフラグし、セキュリティ強制は検証を脅威モデルに紐付け、スコープ削減検出はプランナーが要件を暗黙的に落とすのを防止します。
- STATE.md整合性ゲート —
state validateがSTATE.mdとファイルシステムの差分を検出、state syncが実際のプロジェクト状態から再構築 --to Nフラグ — 自律実行を特定のフェーズ完了後に停止- リサーチゲート — RESEARCH.mdに未解決の質問がある場合、計画をブロック
- 検証マイルストーンスコープフィルタリング — 後のフェーズで対処されるギャップは「ギャップ」ではなく「延期」としてマーク
- 読み取り後編集ガード — 非Claudeランタイムでの無限リトライループを防止するアドバイザリーフック
- コンテキスト削減 — Markdownのトランケーションとキャッシュフレンドリーなプロンプト順序でトークン使用量を削減
- 4つの新ランタイム — Trae、Kilo、Augment、Cline(合計12ランタイム)
npx get-shit-done-cc@latestインストーラーが以下の選択を求めます:
- ランタイム — Claude Code、OpenCode、Gemini、Kilo、Codex、Copilot、Cursor、Windsurf、Antigravity、Augment、Trae、Cline、またはすべて(インタラクティブ複数選択 — 1回のインストールセッションで複数のランタイムを選択可能)
- インストール先 — グローバル(全プロジェクト)またはローカル(現在のプロジェクトのみ)
確認方法:
- Claude Code / Gemini / Copilot / Antigravity:
/gsd-help - OpenCode / Kilo / Augment / Trae:
/gsd-help - Codex:
$gsd-help - Cline: GSDは
.clinerules経由でインストール —.clinerulesの存在を確認
Note
Claude Code 2.1.88+とCodexはスキル(skills/gsd-*/SKILL.md)としてインストールされます。Clineは.clinerulesを使用します。インストーラーがすべての形式を自動的に処理します。
Tip
ソースベースのインストールやnpmが利用できない環境については、**docs/manual-update.md**を参照してください。
GSDは急速に進化しています。定期的にアップデートしてください:
npx get-shit-done-cc@latest非インタラクティブインストール(Docker、CI、スクリプト)
# Claude Code
npx get-shit-done-cc --claude --global # ~/.claude/ にインストール
npx get-shit-done-cc --claude --local # ./.claude/ にインストール
# OpenCode
npx get-shit-done-cc --opencode --global # ~/.config/opencode/ にインストール
# Gemini CLI
npx get-shit-done-cc --gemini --global # ~/.gemini/ にインストール
# Kilo
npx get-shit-done-cc --kilo --global # ~/.config/kilo/ にインストール
npx get-shit-done-cc --kilo --local # ./.kilo/ にインストール
# Codex
npx get-shit-done-cc --codex --global # ~/.codex/ にインストール
npx get-shit-done-cc --codex --local # ./.codex/ にインストール
# Copilot
npx get-shit-done-cc --copilot --global # ~/.github/ にインストール
npx get-shit-done-cc --copilot --local # ./.github/ にインストール
# Cursor CLI
npx get-shit-done-cc --cursor --global # ~/.cursor/ にインストール
npx get-shit-done-cc --cursor --local # ./.cursor/ にインストール
# Antigravity
npx get-shit-done-cc --antigravity --global # ~/.gemini/antigravity/ にインストール
npx get-shit-done-cc --antigravity --local # ./.agent/ にインストール
# Augment
npx get-shit-done-cc --augment --global # ~/.augment/ にインストール
npx get-shit-done-cc --augment --local # ./.augment/ にインストール
# Trae
npx get-shit-done-cc --trae --global # ~/.trae/ にインストール
npx get-shit-done-cc --trae --local # ./.trae/ にインストール
# Cline
npx get-shit-done-cc --cline --global # ~/.cline/ にインストール
npx get-shit-done-cc --cline --local # ./.clinerules にインストール
# 全ランタイム
npx get-shit-done-cc --all --global # すべてのディレクトリにインストール--global(-g)または --local(-l)でインストール先の質問をスキップできます。
--claude、--opencode、--gemini、--kilo、--codex、--copilot、--cursor、--windsurf、--antigravity、--augment、--trae、--cline、または --all でランタイムの質問をスキップできます。
開発用インストール
リポジトリをクローンしてインストーラーをローカルで実行します:
git clone https://github.com/gsd-build/get-shit-done.git
cd get-shit-done
node bin/install.js --claude --localコントリビュートする前に変更をテストするため、./.claude/ にインストールされます。
GSDは摩擦のない自動化のために設計されています。Claude Codeを以下のように実行してください:
claude --dangerously-skip-permissionsTip
これがGSDの意図された使い方です — date や git commit を50回も承認するために止まっていては目的が台無しです。
代替案:詳細なパーミッション設定
このフラグを使いたくない場合は、プロジェクトの .claude/settings.json に以下を追加してください:
{
"permissions": {
"allow": [
"Bash(date:*)",
"Bash(echo:*)",
"Bash(cat:*)",
"Bash(ls:*)",
"Bash(mkdir:*)",
"Bash(wc:*)",
"Bash(head:*)",
"Bash(tail:*)",
"Bash(sort:*)",
"Bash(grep:*)",
"Bash(tr:*)",
"Bash(git add:*)",
"Bash(git commit:*)",
"Bash(git status:*)",
"Bash(git log:*)",
"Bash(git diff:*)",
"Bash(git tag:*)"
]
}
}既存のコードがある場合は? まず
/gsd-map-codebaseを実行してください。並列エージェントが起動し、スタック、アーキテクチャ、規約、懸念点を分析します。その後/gsd-new-projectがコードベースを把握した状態で動作し、質問は追加する内容に焦点を当て、計画時にはパターンが自動的に読み込まれます。
/gsd-new-project
1つのコマンド、1つのフロー。システムが以下を行います:
- 質問 — アイデアを完全に理解するまで質問します(目標、制約、技術的な好み、エッジケース)
- リサーチ — 並列エージェントが起動しドメインを調査します(オプションですが推奨)
- 要件定義 — v1、v2、スコープ外を抽出します
- ロードマップ — 要件に紐づくフェーズを作成します
ロードマップを承認します。これでビルドの準備が整いました。
作成されるファイル: PROJECT.md、REQUIREMENTS.md、ROADMAP.md、STATE.md、.planning/research/
/gsd-discuss-phase 1
ここで実装の方向性を決めます。
ロードマップには各フェーズにつき1〜2文しかありません。あなたが想像する通りに構築するには十分なコンテキストではありません。このステップでは、リサーチや計画の前にあなたの好みを記録します。
システムがフェーズを分析し、構築内容に基づいてグレーゾーンを特定します:
- ビジュアル機能 → レイアウト、密度、インタラクション、空状態
- API/CLI → レスポンス形式、フラグ、エラーハンドリング、詳細度
- コンテンツシステム → 構造、トーン、深さ、フロー
- 整理タスク → グルーピング基準、命名、重複、例外
選択した各領域について、あなたが満足するまで質問します。出力される CONTEXT.md は、次の2つのステップに直接反映されます:
- リサーチャーが読む — どんなパターンを調査すべきかを把握(「ユーザーはカードレイアウトを希望」→ カードコンポーネントライブラリを調査)
- プランナーが読む — どの決定が確定済みかを把握(「無限スクロールに決定」→ スクロール処理を計画に含める)
ここで深く掘り下げるほど、システムはあなたが本当に望むものを構築します。スキップすれば妥当なデフォルトが使われます。活用すればあなたのビジョンが反映されます。
作成されるファイル: {phase_num}-CONTEXT.md
前提モード: 質問よりもコードベース分析を優先したい場合は、
/gsd-settingsでworkflow.discuss_modeをassumptionsに設定してください。システムがコードを読み、何をなぜそうするかを提示し、間違っている部分だけ修正を求めます。詳しくはディスカスモードをご覧ください。
/gsd-plan-phase 1
システムが以下を行います:
- リサーチ — CONTEXT.mdの決定事項をもとに、このフェーズの実装方法を調査します
- 計画 — XML構造で2〜3個のアトミックなタスクプランを作成します
- 検証 — プランを要件と照合し、合格するまでループします
各プランは新しいコンテキストウィンドウで実行できるほど小さくなっています。品質の劣化も「もっと簡潔にしますね」もありません。
作成されるファイル: {phase_num}-RESEARCH.md、{phase_num}-{N}-PLAN.md
/gsd-execute-phase 1
システムが以下を行います:
- ウェーブでプランを実行 — 可能な限り並列、依存関係がある場合は逐次
- プランごとにフレッシュなコンテキスト — 実装に200kトークンをフル活用、蓄積されたゴミはゼロ
- タスクごとにコミット — 各タスクが独自のアトミックコミットを取得
- 目標に対して検証 — コードベースがフェーズの約束を果たしているか確認
席を離れて、戻ってきたらクリーンなgit履歴とともに完了した作業が待っています。
ウェーブ実行の仕組み:
プランは依存関係に基づいて「ウェーブ」にグループ化されます。各ウェーブ内のプランは並列実行されます。ウェーブは逐次実行されます。
┌────────────────────────────────────────────────────────────────────┐
│ PHASE EXECUTION │
├────────────────────────────────────────────────────────────────────┤
│ │
│ WAVE 1 (parallel) WAVE 2 (parallel) WAVE 3 │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Plan 01 │ │ Plan 02 │ → │ Plan 03 │ │ Plan 04 │ → │ Plan 05 │ │
│ │ │ │ │ │ │ │ │ │ │ │
│ │ User │ │ Product │ │ Orders │ │ Cart │ │ Checkout│ │
│ │ Model │ │ Model │ │ API │ │ API │ │ UI │ │
│ └─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │
│ │ │ ↑ ↑ ↑ │
│ └───────────┴──────────────┴───────────┘ │ │
│ Dependencies: Plan 03 needs Plan 01 │ │
│ Plan 04 needs Plan 02 │ │
│ Plan 05 needs Plans 03 + 04 │ │
│ │
└────────────────────────────────────────────────────────────────────┘
ウェーブが重要な理由:
- 独立したプラン → 同じウェーブ → 並列実行
- 依存するプラン → 後のウェーブ → 依存関係を待つ
- ファイル競合 → 逐次プランまたは同一プラン内
これが「バーティカルスライス」(Plan 01: ユーザー機能をエンドツーエンド)が「ホリゾンタルレイヤー」(Plan 01: 全モデル、Plan 02: 全API)より並列化に適している理由です。
作成されるファイル: {phase_num}-{N}-SUMMARY.md、{phase_num}-VERIFICATION.md
/gsd-verify-work 1
ここで実際に動作するか確認します。
自動検証はコードの存在とテストの合格を確認します。しかし、その機能は期待通りに動作していますか?ここはあなたが実際に使ってみる場です。
システムが以下を行います:
- テスト可能な成果物を抽出 — 今できるようになっているはずのこと
- 1つずつ案内 — 「メールでログインできますか?」はい/いいえ、または何が問題かを説明
- 障害を自動診断 — デバッグエージェントが起動し根本原因を特定
- 検証済みの修正プランを作成 — 即座に再実行可能
すべてパスすれば次に進みます。何か壊れていれば、手動でデバッグする必要はありません — 作成された修正プランで /gsd-execute-phase を再度実行するだけです。
作成されるファイル: {phase_num}-UAT.md、問題が見つかった場合は修正プラン
/gsd-discuss-phase 2
/gsd-plan-phase 2
/gsd-execute-phase 2
/gsd-verify-work 2
/gsd-ship 2 # 検証済みの作業からPRを作成
...
/gsd-complete-milestone
/gsd-new-milestone
またはGSDに次のステップを自動判定させます:
/gsd-next # 次のステップを自動検出して実行
discuss → plan → execute → verify → ship のループをマイルストーン完了まで繰り返します。
ディスカッション中のインプットを速くしたい場合は、/gsd-discuss-phase <n> --batch で1つずつではなく小さなグループにまとめた質問に一括で回答できます。--chain を使うと、ディスカッションからプラン+実行まで途中で止まらずに自動チェインできます。
各フェーズであなたのインプット(discuss)、適切なリサーチ(plan)、クリーンな実行(execute)、人間による検証(verify)が行われます。コンテキストは常にフレッシュ。品質は常に高い。
すべてのフェーズが完了したら、/gsd-complete-milestone でマイルストーンをアーカイブしリリースをタグ付けします。
次に /gsd-new-milestone で次のバージョンを開始します — new-project と同じフローですが既存のコードベース向けです。次に構築したいものを説明し、システムがドメインを調査し、要件をスコーピングし、新しいロードマップを作成します。各マイルストーンはクリーンなサイクルです:定義 → 構築 → シップ。
/gsd-quick
フル計画が不要なアドホックタスク向け。
クイックモードはGSDの保証(アトミックコミット、状態トラッキング)をより速いパスで提供します:
- 同じエージェント — プランナー + エグゼキューター、同じ品質
- オプションステップをスキップ — デフォルトではリサーチ、プランチェッカー、ベリファイアなし
- 別トラッキング —
.planning/quick/に保存、フェーズとは別管理
--discuss フラグ: 計画前にグレーゾーンを洗い出す軽量ディスカッション。
--research フラグ: 計画前にフォーカスされたリサーチャーを起動。実装アプローチ、ライブラリの選択肢、落とし穴を調査します。タスクへのアプローチが不明な場合に使用してください。
--full フラグ: 全フェーズを有効化 — ディスカッション + リサーチ + プランチェック + 検証。クイックタスク形式のフルGSDパイプライン。
--validate フラグ: プランチェック + 実行後の検証のみを有効化(以前の --full の動作)。
フラグは組み合わせ可能:--discuss --research --validate でディスカッション + リサーチ + プランチェック + 検証が行われます。
/gsd-quick
> What do you want to do? "Add dark mode toggle to settings"
作成されるファイル: .planning/quick/001-add-dark-mode-toggle/PLAN.md、SUMMARY.md
Claude Codeは必要なコンテキストを与えれば非常に強力です。ほとんどの人はそれをしていません。
GSDがそれを代わりに処理します:
| ファイル | 役割 |
|---|---|
PROJECT.md |
プロジェクトビジョン、常に読み込まれる |
research/ |
エコシステムの知識(スタック、機能、アーキテクチャ、落とし穴) |
REQUIREMENTS.md |
フェーズとのトレーサビリティを持つスコープ済みv1/v2要件 |
ROADMAP.md |
進む方向、完了済みの作業 |
STATE.md |
決定事項、ブロッカー、現在地 — セッション間のメモリ |
PLAN.md |
XML構造のアトミックタスク、検証ステップ付き |
SUMMARY.md |
何が起きたか、何が変わったか、履歴にコミット |
todos/ |
後で取り組むアイデアやタスクのキャプチャ |
threads/ |
セッションをまたぐ作業のための永続コンテキストスレッド |
seeds/ |
適切なマイルストーンで浮上する将来志向のアイデア |
サイズ制限はClaudeの品質が劣化するポイントに基づいています。制限内に収まれば、一貫した高品質が得られます。
すべてのプランはClaude向けに最適化された構造化XMLです:
<task type="auto">
<name>Create login endpoint</name>
<files>src/app/api/auth/login/route.ts</files>
<action>
<!-- CommonJSの問題があるため、jsonwebtokenではなくjoseをJWTに使用。 -->
<!-- usersテーブルに対して認証情報を検証。 -->
<!-- 成功時にhttpOnly cookieを返す。 -->
Use jose for JWT (not jsonwebtoken - CommonJS issues).
Validate credentials against users table.
Return httpOnly cookie on success.
</action>
<verify>curl -X POST localhost:3000/api/auth/login returns 200 + Set-Cookie</verify>
<done>Valid credentials return cookie, invalid return 401</done>
</task>正確な指示。推測なし。検証が組み込み済み。
すべてのステージで同じパターンを使用します:薄いオーケストレーターが専門エージェントを起動し、結果を収集し、次のステップにルーティングします。
| ステージ | オーケストレーターの役割 | エージェントの役割 |
|---|---|---|
| リサーチ | 調整し、発見事項を提示 | 4つの並列リサーチャーがスタック、機能、アーキテクチャ、落とし穴を調査 |
| プランニング | 検証し、イテレーションを管理 | プランナーがプランを作成、チェッカーが検証、合格するまでループ |
| 実行 | ウェーブにグループ化し、進捗を追跡 | エグゼキューターがフレッシュな200kコンテキストで並列実装 |
| 検証 | 結果を提示し、次にルーティング | ベリファイアがコードベースを目標と照合、デバッガーが障害を診断 |
オーケストレーターは重い処理を行いません。エージェントを起動し、待機し、結果を統合します。
結果: フェーズ全体を実行できます — 深いリサーチ、複数のプランの作成と検証、並列エグゼキューターによる数千行のコード記述、目標に対する自動検証 — そしてメインのコンテキストウィンドウは30〜40%に留まります。処理はフレッシュなサブエージェントコンテキストで行われます。セッションは高速でレスポンシブなままです。
各タスクは完了直後に独自のコミットを取得します:
abc123f docs(08-02): complete user registration plan
def456g feat(08-02): add email confirmation flow
hij789k feat(08-02): implement password hashing
lmn012o feat(08-02): create registration endpointNote
メリット: git bisectで問題のある正確なタスクを特定可能。各タスクを個別にリバート可能。将来のセッションでClaudeに明確な履歴を提供。AI自動化ワークフローにおけるオブザーバビリティの向上。
すべてのコミットは的確で、追跡可能で、意味があります。
- 現在のマイルストーンにフェーズを追加
- フェーズ間に緊急作業を挿入
- マイルストーンを完了して新しく開始
- すべてを再構築せずにプランを調整
ロックインされることはありません。システムが適応します。
| コマンド | 説明 |
|---|---|
/gsd-new-project [--auto] |
フル初期化:質問 → リサーチ → 要件定義 → ロードマップ |
/gsd-discuss-phase [N] [--auto] [--analyze] [--chain] |
計画前に実装の決定事項をキャプチャ(--analyze でトレードオフ分析を追加、--chain でプラン+実行へ自動チェイン) |
/gsd-plan-phase [N] [--auto] [--reviews] |
フェーズのリサーチ + プラン + 検証(--reviews でコードベースレビューの発見事項を読み込み) |
/gsd-execute-phase <N> |
全プランを並列ウェーブで実行し、完了時に検証 |
/gsd-verify-work [N] |
手動ユーザー受入テスト ¹ |
/gsd-ship [N] [--draft] |
検証済みのフェーズ作業から自動生成された本文付きのPRを作成 |
/gsd-next |
次の論理的なワークフローステップに自動的に進む |
/gsd-fast <text> |
インラインの軽微タスク — 計画を完全にスキップし即座に実行 |
/gsd-audit-milestone |
マイルストーンが完了の定義を達成したか検証 |
/gsd-complete-milestone |
マイルストーンをアーカイブし、リリースをタグ付け |
/gsd-new-milestone [name] |
次のバージョンを開始:質問 → リサーチ → 要件定義 → ロードマップ |
/gsd-forensics [desc] |
失敗したワークフロー実行の事後分析(停止ループ、欠落成果物、git異常の診断) |
/gsd-milestone-summary [version] |
チームオンボーディングとレビュー向けの包括的なプロジェクトサマリーを生成 |
| コマンド | 説明 |
|---|---|
/gsd-workstreams list |
全ワークストリームとそのステータスを表示 |
/gsd-workstreams create <name> |
並列マイルストーン作業用の名前空間付きワークストリームを作成 |
/gsd-workstreams switch <name> |
アクティブなワークストリームを切り替え |
/gsd-workstreams complete <name> |
ワークストリームを完了しマージ |
| コマンド | 説明 |
|---|---|
/gsd-new-workspace |
リポジトリのコピー(worktreeまたはクローン)で隔離されたワークスペースを作成 |
/gsd-list-workspaces |
すべてのGSDワークスペースとそのステータスを表示 |
/gsd-remove-workspace |
ワークスペースを削除しworktreeをクリーンアップ |
| コマンド | 説明 |
|---|---|
/gsd-ui-phase [N] |
フロントエンドフェーズ用のUIデザイン契約(UI-SPEC.md)を生成 |
/gsd-ui-review [N] |
実装済みフロントエンドコードの6つの柱によるビジュアル監査(遡及的) |
| コマンド | 説明 |
|---|---|
/gsd-progress |
今どこにいる?次は何? |
/gsd-next |
状態を自動検出し次のステップを実行 |
/gsd-help |
全コマンドと使い方ガイドを表示 |
/gsd-update |
チェンジログプレビュー付きでGSDをアップデート |
/gsd-join-discord |
GSD Discordコミュニティに参加 |
/gsd-manager |
複数フェーズ管理用のインタラクティブコマンドセンター |
| コマンド | 説明 |
|---|---|
/gsd-map-codebase [area] |
new-project前に既存のコードベースを分析 |
| コマンド | 説明 |
|---|---|
/gsd-add-phase |
ロードマップにフェーズを追加 |
/gsd-insert-phase [N] |
フェーズ間に緊急作業を挿入 |
/gsd-remove-phase [N] |
将来のフェーズを削除し番号を振り直し |
/gsd-list-phase-assumptions [N] |
計画前にClaudeの意図するアプローチを確認 |
/gsd-plan-milestone-gaps |
監査で見つかったギャップを埋めるフェーズを作成 |
| コマンド | 説明 |
|---|---|
/gsd-pause-work |
フェーズ途中で停止する際の引き継ぎを作成(HANDOFF.jsonを書き込み) |
/gsd-resume-work |
前回のセッションから復元 |
/gsd-session-report |
実行した作業と結果のセッションサマリーを生成 |
| コマンド | 説明 |
|---|---|
/gsd-workstreams |
並列ワークストリームを管理(list、create、switch、status、progress、complete) |
| コマンド | 説明 |
|---|---|
/gsd-review |
現在のフェーズまたはブランチのクロスAIピアレビュー |
/gsd-pr-branch |
.planning/ コミットをフィルタリングしたクリーンなPRブランチを作成 |
/gsd-audit-uat |
検証負債を監査 — UATが未実施のフェーズを検出 |
| コマンド | 説明 |
|---|---|
/gsd-plant-seed <idea> |
トリガー条件付きの将来志向のアイデアをキャプチャ — 適切なマイルストーンで浮上 |
/gsd-add-backlog <desc> |
バックログのパーキングロットにアイデアを追加(999.xナンバリング、アクティブシーケンス外) |
/gsd-review-backlog |
バックログ項目をレビューし、アクティブマイルストーンに昇格またはstaleエントリを削除 |
/gsd-thread [name] |
永続コンテキストスレッド — 複数セッションにまたがる作業用の軽量クロスセッション知識 |
| コマンド | 説明 |
|---|---|
/gsd-settings |
モデルプロファイルとワークフローエージェントを設定 |
/gsd-set-profile <profile> |
モデルプロファイルを切り替え(quality/balanced/budget/inherit) |
/gsd-add-todo [desc] |
後で取り組むアイデアをキャプチャ |
/gsd-check-todos |
保留中のtodoを一覧表示 |
/gsd-debug [desc] |
永続状態を持つ体系的デバッグ |
/gsd-do <text> |
フリーフォームテキストを適切なGSDコマンドに自動ルーティング |
/gsd-note <text> |
ゼロフリクションのアイデアキャプチャ — ノートの追加、一覧、todoへの昇格 |
/gsd-quick [--full] [--discuss] [--research] |
GSDの保証付きでアドホックタスクを実行(--full で全フェーズを有効化、--discuss で事前にコンテキストを収集、--research で計画前にアプローチを調査) |
/gsd-health [--repair] |
.planning/ ディレクトリの整合性を検証、--repair で自動修復 |
/gsd-stats |
プロジェクト統計を表示 — フェーズ、プラン、要件、gitメトリクス |
/gsd-profile-user [--questionnaire] [--refresh] |
セッション分析から開発者行動プロファイルを生成し、パーソナライズされた応答を提供 |
¹ Redditユーザー OracleGreyBeard による貢献
GSDはプロジェクト設定を .planning/config.json に保存します。/gsd-new-project 実行時に設定するか、後から /gsd-settings で更新できます。完全な設定スキーマ、ワークフロートグル、gitブランチオプション、エージェントごとのモデル内訳については、ユーザーガイドをご覧ください。
| 設定 | オプション | デフォルト | 制御内容 |
|---|---|---|---|
mode |
yolo, interactive |
interactive |
自動承認 vs 各ステップで確認 |
granularity |
coarse, standard, fine |
standard |
フェーズの粒度 — スコープをどれだけ細かく分割するか(フェーズ × プラン) |
各エージェントが使用するClaudeモデルを制御します。品質とトークン消費のバランスを取ります。
| プロファイル | プランニング | 実行 | 検証 |
|---|---|---|---|
quality |
Opus | Opus | Sonnet |
balanced(デフォルト) |
Opus | Sonnet | Sonnet |
budget |
Sonnet | Sonnet | Haiku |
inherit |
Inherit | Inherit | Inherit |
プロファイルの切り替え:
/gsd-set-profile budget
非Anthropicプロバイダー(OpenRouter、ローカルモデル)を使用する場合や、現在のランタイムのモデル選択に従う場合(例:OpenCode /model)は inherit を使用してください。
または /gsd-settings で設定できます。
プランニング/実行時に追加のエージェントを起動します。品質は向上しますが、トークンと時間が追加されます。
| 設定 | デフォルト | 説明 |
|---|---|---|
workflow.research |
true |
各フェーズの計画前にドメインを調査 |
workflow.plan_check |
true |
実行前にプランがフェーズ目標を達成しているか検証 |
workflow.verifier |
true |
実行後に必須項目が提供されたか確認 |
workflow.auto_advance |
false |
discuss → plan → execute を停止せずに自動チェーン |
workflow.research_before_questions |
false |
ディスカッション質問の後ではなく前にリサーチを実行 |
workflow.discuss_mode |
'discuss' |
ディスカッションモード:discuss(インタビュー)、assumptions(コードベースファースト) |
workflow.skip_discuss |
false |
自律モードでdiscuss-phaseをスキップ |
workflow.text_mode |
false |
リモートセッション用のテキスト専用モード(TUIメニューなし) |
これらのトグルには /gsd-settings を使用するか、呼び出し時にオーバーライドできます:
/gsd-plan-phase --skip-research/gsd-plan-phase --skip-verify
| 設定 | デフォルト | 制御内容 |
|---|---|---|
parallelization.enabled |
true |
独立したプランを同時に実行 |
planning.commit_docs |
true |
.planning/ をgitで追跡 |
hooks.context_warnings |
true |
コンテキストウィンドウの使用量警告を表示 |
GSDが実行中にブランチをどう扱うかを制御します。
| 設定 | オプション | デフォルト | 説明 |
|---|---|---|---|
git.branching_strategy |
none, phase, milestone |
none |
ブランチ作成戦略 |
git.phase_branch_template |
string | gsd/phase-{phase}-{slug} |
フェーズブランチのテンプレート |
git.milestone_branch_template |
string | gsd/{milestone}-{slug} |
マイルストーンブランチのテンプレート |
戦略:
none— 現在のブランチにコミット(デフォルトのGSD動作)phase— フェーズごとにブランチを作成し、フェーズ完了時にマージmilestone— マイルストーン全体で1つのブランチを作成し、完了時にマージ
マイルストーン完了時、GSDはスカッシュマージ(推奨)または履歴付きマージを提案します。
GSDはv1.27以降、多層防御セキュリティを備えています:
- パストラバーサル防止 — ユーザー提供のすべてのファイルパス(
--text-file、--prd)がプロジェクトディレクトリ内に解決されるか検証 - プロンプトインジェクション検出 — 集中型
security.cjsモジュールが計画成果物に入る前にユーザー提供テキストのインジェクションパターンをスキャン - PreToolUseプロンプトガードフック —
gsd-prompt-guardが.planning/への書き込みに埋め込まれたインジェクションベクトルをスキャン(アドバイザリー、ブロッキングではない) - 安全なJSON解析 — 不正な
--fields引数が状態を破損する前にキャッチ - シェル引数バリデーション — シェル補間前にユーザーテキストをサニタイズ
- CI対応インジェクションスキャナー —
prompt-injection-scan.test.cjsが全エージェント/ワークフロー/コマンドファイルの埋め込みインジェクションベクトルをスキャン
Note
GSDはLLMシステムプロンプトとなるマークダウンファイルを生成するため、計画成果物に流入するユーザー制御テキストは潜在的な間接プロンプトインジェクションベクトルとなります。これらの保護は、そのようなベクトルを複数のレイヤーで捕捉するように設計されています。
GSDのコードベースマッピングおよび分析コマンドは、プロジェクトを理解するためにファイルを読み取ります。シークレットを含むファイルを保護するには、Claude Codeの拒否リストに追加してください:
- Claude Code設定(
.claude/settings.jsonまたはグローバル)を開きます - 機密ファイルパターンを拒否リストに追加します:
{
"permissions": {
"deny": [
"Read(.env)",
"Read(.env.*)",
"Read(**/secrets/*)",
"Read(**/*credential*)",
"Read(**/*.pem)",
"Read(**/*.key)"
]
}
}これにより、どのコマンドを実行しても、Claudeがこれらのファイルを完全に読み取ることを防ぎます。
Important
GSDにはシークレットのコミットに対する組み込み保護がありますが、多層防御がベストプラクティスです。防御の第一線として、機密ファイルへの読み取りアクセスを拒否してください。
インストール後にコマンドが見つからない?
- ランタイムを再起動してコマンド/スキルを再読み込みしてください
~/.claude/commands/gsd/(グローバル)または./.claude/commands/gsd/(ローカル)にファイルが存在するか確認してください- Codexの場合、
~/.codex/skills/gsd-*/SKILL.md(グローバル)または./.codex/skills/gsd-*/SKILL.md(ローカル)にスキルが存在するか確認してください
コマンドが期待通りに動作しない?
/gsd-helpを実行してインストールを確認してくださいnpx get-shit-done-ccを再実行して再インストールしてください
最新バージョンへのアップデート?
npx get-shit-done-cc@latestDockerまたはコンテナ化環境を使用している?
チルダパス(~/.claude/...)でファイル読み取りが失敗する場合、インストール前に CLAUDE_CONFIG_DIR を設定してください:
CLAUDE_CONFIG_DIR=/home/youruser/.claude npx get-shit-done-cc --globalこれにより、コンテナ内で正しく展開されない可能性がある ~ の代わりに絶対パスが使用されます。
GSDを完全に削除するには:
# グローバルインストール
npx get-shit-done-cc --claude --global --uninstall
npx get-shit-done-cc --opencode --global --uninstall
npx get-shit-done-cc --gemini --global --uninstall
npx get-shit-done-cc --kilo --global --uninstall
npx get-shit-done-cc --codex --global --uninstall
npx get-shit-done-cc --copilot --global --uninstall
npx get-shit-done-cc --cursor --global --uninstall
npx get-shit-done-cc --antigravity --global --uninstall
npx get-shit-done-cc --trae --global --uninstall
# ローカルインストール(現在のプロジェクト)
npx get-shit-done-cc --claude --local --uninstall
npx get-shit-done-cc --opencode --local --uninstall
npx get-shit-done-cc --gemini --local --uninstall
npx get-shit-done-cc --kilo --local --uninstall
npx get-shit-done-cc --codex --local --uninstall
npx get-shit-done-cc --copilot --local --uninstall
npx get-shit-done-cc --cursor --local --uninstall
npx get-shit-done-cc --antigravity --local --uninstall
npx get-shit-done-cc --trae --local --uninstallこれにより、他の設定を保持しながら、すべてのGSDコマンド、エージェント、フック、設定が削除されます。
OpenCode、Gemini CLI、Kilo、Codexは npx get-shit-done-cc でネイティブサポートされています。
以下のコミュニティポートがマルチランタイムサポートの先駆けとなりました:
| プロジェクト | プラットフォーム | 説明 |
|---|---|---|
| gsd-opencode | OpenCode | オリジナルのOpenCode対応版 |
| gsd-gemini(アーカイブ済み) | Gemini CLI | uberfuzzyによるオリジナルのGemini対応版 |
MITライセンス。詳細は LICENSE をご覧ください。
Claude Codeは強力です。GSDはそれを信頼性の高いものにします。