Get Shit Done - メタプロンプト・仕様ベース開発システム
(github.com/gsd-build)- Claude Code などで 仕様ベース開発（SDD） を自動化する軽量システムで、複雑なワークフローなしにプロジェクトを完成できるよう支援
- コンテキストエンジニアリング と XMLベースのプロンプト構造化、マルチエージェントオーケストレーション により、AIコード品質の劣化（context rot）を防止
/gsd:new-project,/gsd:plan-phase,/gsd:execute-phaseなどのコマンドで、アイデア定義 → 計画 → 実行 → 検証 の開発ライフサイクル全体を自動化- 各作業単位ごとの アトミックな Git コミット と並列実行（wave execution）により、追跡性と効率を確保
- Amazon, Google, Shopify, Webflow のエンジニアが利用するツールで、AIベース開発の信頼性と生産性を高めるシステム
概要
- Get Shit Done（GSD） は、Claude Code, OpenCode, Gemini CLI, Codex, Copilot, Antigravity などさまざまな AI 開発環境で動作する 軽量メタプロンプトおよびコンテキスト管理システム
- AI がコード作成中に文脈品質が低下する context rot の問題を解決し、仕様ベースで一貫した結果を生成
- Mac, Windows, Linux のすべてで動作し、
npx get-shit-done-cc@latestコマンドでインストール可能
制作背景（Why I Built This）
- 大規模組織向けツールが不要に複雑な手順を要求する問題を解決するために制作
- GSD は 複雑さはシステム内部に、ワークフローはシンプルに という設計
- 内部では コンテキストエンジニアリング、XML プロンプト整形、サブエージェントオーケストレーション、状態管理 を実行
- ユーザーはシンプルなコマンドだけでプロジェクトを完成できる
主な機能とワークフロー（How It Works）
-
開発プロセス全体は 6段階 で構成
- プロジェクト初期化: アイデア、制約、技術スタックなどを質問し、
PROJECT.md,ROADMAP.mdなどを生成 - ディスカッション段階: 実装の詳細を定義して
CONTEXT.mdを生成 - 計画段階: 並列リサーチと計画策定を行い、XML 構造の作業単位を生成
- 実行段階: 依存関係ベースの wave 並列実行、各作業ごとのコミットと検証
- 検証段階: 自動テストとユーザー確認を行い、失敗時は自動修正計画を生成
- 反復とマイルストーン完了: 各段階を繰り返した後にリリースタグ付け
- プロジェクト初期化: アイデア、制約、技術スタックなどを質問し、
-
Quick Mode は単一タスクを素早く処理し、
--discuss,--research,--fullフラグで詳細制御が可能
中核技術（Why It Works）
- コンテキストエンジニアリング: プロジェクト全体の文脈をファイル単位で管理（
PROJECT.md,REQUIREMENTS.md,STATE.mdなど） - XML プロンプト整形: 各作業を明確に定義し、検証手順を含める
- マルチエージェントオーケストレーション: リサーチ・計画・実行・検証の各段階ごとに専門エージェントを並列運用
- アトミックな Git コミット: 各作業単位ごとのコミットで追跡性と復旧のしやすさを確保
- モジュール設計: 段階の追加・挿入・修正が自由で、柔軟なプロジェクト管理が可能
コマンド体系（Commands）
- 中核ワークフロー:
/gsd:new-project,/gsd:plan-phase,/gsd:execute-phase,/gsd:verify-work - UI 設計支援:
/gsd:ui-phase,/gsd:ui-review - コードベース分析:
/gsd:map-codebase - プロジェクト管理:
/gsd:add-phase,/gsd:insert-phase,/gsd:complete-milestone - ユーティリティ:
/gsd:quick,/gsd:health,/gsd:stats,/gsd:debug,/gsd:noteなど
設定と構成（Configuration）
- 設定ファイル
.planning/config.jsonで モード、段階の細分化、モデルプロファイル、ワークフローエージェント、並列化、Git ブランチ戦略 などを制御 - モデルプロファイルは
quality,balanced,budget,inheritから選択可能 workflow.research,workflow.plan_check,workflow.verifierなどのトグルで品質・速度を調整可能
セキュリティとトラブルシューティング（Security & Troubleshooting）
.env,secrets/,*.pem,*.keyなどの機密ファイルは Claude Code の deny list に追加してアクセスを遮断- インストール後にコマンド認識エラーが起きた場合は、ランタイム再起動または再インストールを推奨
- Docker 環境では
CLAUDE_CONFIG_DIRの設定でパス問題を解決 --uninstallオプションですべての構成要素を削除可能
コミュニティとライセンス
- OpenCode, Gemini CLI, Codex 向けのコミュニティ移植版をサポート
- MIT ライセンス で公開
- “Claude Code is powerful. GSD makes it reliable.” — Claude Code の信頼性を高めるツール
1件のコメント
Hacker News のコメント
以前は Plan mode と Superpowers を併用していたが、結局 Plan mode だけで十分だと感じた。
こうしたフレームワークは、リサーチが必要な fire-and-forget 作業 には向いているが、トークン消費が 10 倍以上になる感覚だった。
出力品質の差もそれほど大きくなく、Max plan の上限に頻繁に引っかかった。
実装計画が終わると入力を求めずに自動で進行するが、Docker sandbox の中で実行する必要がある。
危険な権限設定が理由だが、そのほうがむしろ安全だと思っている。
今のところうまく動いていて生産性も高いが、これはまだ旅の途中の段階という感じだ。
最新版の発表を見てまた試してみたところ、cross-check と self-review が多層になっていて、結果がより安定していた。
手動でもできるが、Superpowers がその工程を自動化してくれるのでずっと楽だった。
GSD はプロジェクト全体の文脈を考慮したコードで、Plan Mode は MVP レベル で必要最小限だけを実装していた。
ワークフローや作業規模によって長所と短所がはっきり分かれる。
出力が冗長になり、細部はむしろ曖昧になった。
「design」「figure out」といった段階だけが増え、後続の質問もなくそのまま実装に進んでしまう。
テストをいじったり、とんちんかんな結果を出したりもした。
結局は自分で 手動でガイド しながら MVP を仕上げたが、そのほうがはるかに効率的だった。
最近はこうした meta フレームワーク が多すぎるが、実際に生産性を証明したものはほとんど見たことがない。
大半はトークンの浪費であり、context window の汚染 を招くだけだ。
結局のところ、シンプルに必要な情報だけを与え、Plan → Code → Verify の順で回すのが一番良かった。
Claude 単独で出した誤りを Codex が見つけるのを見ると、単一エージェントに全面的に任せるのは無理だと感じる。
アプリの画面フローを画像で設計し、それを構造化された markdown に書き出すと、LLM が画面単位で文脈を理解する。
テキストベースのスペックよりも、抜けている状態やエラーフロー を事前に捉えやすい。
作った本人には便利でも、他人には役に立たないと感じられる。
自分は Spec-Driven システム は失敗する運命にあると思っている。
英語で書かれたスペックでは、実際のコードと挙動を結びつけられない。
この問題はすでに 自動テスト で解決済みだ。
システムの振る舞いは、実行可能なテストとしてエンコードすべきだ。
LLM が実装を生成する場合でも、まずテストを書き、mutation testing で一貫性を検証すべきだ。
関連内容は この記事 と GitHub の例 にまとめてある。
結局はコードの形で表現される必要がある。
リンク 参照。
スペックはテストよりもはるかに広い領域を扱う。
LLM がテストを無視したり、勝手に修正したりすることも多い。
個人用の AI システム を使っているが、公開するか悩んでいる。
自分の作業に合わせてカスタマイズされているので、公開版を別途保守するのが負担だ。
他人にそのまま使ってもらうより、自分のシステムを参考にして パターンだけ共有 したい。
AI 時代では、単に インスピレーションやアイデア を共有するだけでも十分価値がある。
チームのハッカソンで GSD を使ってみたが、コードベースの理解に時間がかかりすぎ、トークン消費 も激しかった。
エージェントのトランスクリプト生成中にもエラーが頻発した。
小さな機能をいくつか作るには大げさすぎるツールだった。
学んだことはシンプルで、良いスペックを書くこと + Plan mode を繰り返すこと のほうがずっと効率的だった。
Beads の設計上の制約が窮屈だったので、似たツールを自作した。
自分のバージョンは SQLite ベース で、GitHub との双方向同期機能を追加してある。
核心は、まずモデルと対話しながら 明確なスペックファイル を作ることだ。
ファイルがあればモデルは忘れず、細部が多いほど出力品質も高くなる。
Claude を使って長年温めていたアイデアをプロトタイプにしたが、期待以上によくできた。
モデルは依然として 確率的システム なので、完全な記憶は不可能だ。
まるで新しい秘訣を発見したかのように見せるのは大げさだ。
Superpowers を使ったことがあり、今回の GSD も似て見えたので比較が気になった。
Quick mode は本来の目的を見失わせ、Superpowers はその中間地点として悪くなかった。
こうしたフレームワークをリポジトリに入れ、AI に フレームワーク自体を改善 させれば、創造的な作業にも有用だ。
ただし、こうした構造は一時的なハックにすぎず、モデルが十分に学習すれば自然に消えていく気がする。
GSD はこの問題を解決しているが、段階が多すぎて 速度が遅い。
Superpowers が作ったスペックは詳細だったが、一部の機能（例: RSS、分析）が抜けており、並列移行 を提案した協調的なスペックのほうが柔軟だった。
最終的には Claude に 2 つのスペックを比較・統合させて完成版を作った。
詳細比較 参照。
Claude skills だけでも十分実装できそうだ。
GSD を 3 か月間集中的に使ってきたが、以前使っていた speckit よりはるかに完成度が高い。
複雑な作業でも 95% までは自動で処理してくれる。
残り 5% は手動テストで仕上げる。
これで SaaS 製品（whiteboar.it） まで出せた。
モデル自体の進歩もあるが、生産性向上 は確かだった。
FreshBooks の購読料がもったいなくて、GSD で macOS Swift アプリ を自作した。
領収書の自動抽出やカテゴリ分類まで Anthropic API で実装した。
Web アプリから始めたが、カメラ連携などの機能を追加するうちに完全なデスクトップアプリに発展した。
GSD のおかげで個人用の会計アプリを完成できた。
結局、本当に必要なのは トークンを節約するツール だ。
だが、まだそういうものはない。
Claude Code も大規模プロジェクトではトークンを使いすぎる。
「この Markdown ファイルの束」という名前があまりに こそばゆい。