タスクを完遂する: メタプロンプティング、コンテキストエンジニアリング、仕様駆動型開発システム

45日前原文(github.com)

概要

get-shit-done-cc（GSD）は、Claude CodeやCopilotなど多様なAIコーディング環境で使える軽量・強力なメタプロンプト/コンテキストエンジニアリング/仕様駆動開発システム
コンテキストロット（文脈劣化）問題を解決し、高品質なコード生成を維持
エンジニアリング劇や複雑なワークフロー不要で、少人数や個人開発者でも最大効果を発揮
Amazon、Google、Shopify、Webflowのエンジニアも信頼して利用
インストールや利用手順がシンプルで、各種AIエージェントに対応

get-shit-done-cc（GSD）とは

Claude Code、OpenCode、Gemini CLI、Codex、Copilot、Antigravityなど主要AIコーディングツールに対応した仕様駆動開発支援ツール
メタプロンプト設計・コンテキスト管理・サブエージェント制御・状態管理を自動化
シンプルなコマンドだけで複雑なシステムを構築可能
**「やりたいことを明確に伝えれば、AIが実現してくれる」**という思想
SpecKitやOpenSpec、Taskmaster経験者も高評価

GSDを開発した理由

個人開発者視点で設計し、エンタープライズ向けの無駄な儀式や複雑なワークフローを排除
本質的な開発体験を重視し、仕様理解と文脈保持に注力
裏側で複雑な処理を隠蔽し、ユーザーには「ただ動く」コマンド体験を提供

GSDが解決する課題

AIによるコード生成の一貫性・品質劣化（コンテキストロット）問題
大規模組織向けの複雑なプロセスを不要にし、創造的な個人・少人数チーム向けに最適化
「Vibecoding（雰囲気コーディング）」の信頼性向上

対象ユーザー

明確な要件を伝え、確実に実装してほしい個人開発者・小規模チーム
50人規模のエンジニア組織をシミュレートしたくない人向け

インストール方法

npx get-shit-done-cc@latestでインストール
対応ランタイム選択（Claude Code、OpenCode、Gemini、Codex、Copilot、Antigravity、または全対応）
グローバル/ローカル設置選択（全プロジェクト or 現在のプロジェクトのみ）
各AI環境ごとのコマンドでヘルプ表示可能
- Claude Code/Gemini：/gsd:help
- OpenCode：/gsd-help
- Codex：$gsd-help
- Copilot：/gsd:help
- Antigravity：/gsd:help
DockerやCI用の非対話インストールもサポート
--global（-g）、--local（-l）、--claude、--opencode等のフラグでプロンプト省略可能

開発・検証のためのインストール

リポジトリクローン & ローカルインストールでカスタマイズやテストが容易
claude --dangerously-skip-permissionsで自動化を最大化
細かい権限管理もsettings.jsonで設定可能

GSDのワークフロー

/gsd:map-codebase：既存コードベースの自動解析
/gsd:new-project：新規プロジェクト初期化
- 目標・制約・技術選定・エッジケース等をヒアリング
- 並列エージェントによるリサーチ
- バージョンごとの要件抽出
- フェーズ単位のロードマップ作成
- PROJECT.md、REQUIREMENTS.md、ROADMAP.md、STATE.md等を自動生成
/gsd:discuss-phase n：各フェーズの詳細要件・好み・グレーゾーンを深掘り
- フェーズごとのCONTEXT.md生成
/gsd:plan-phase n：リサーチ＆プランニング
- CONTEXT.mdを元に実装手法やタスク分割を自動化
- XML構造のタスクプランを2-3個生成
/gsd:execute-phase n：プラン実行
- 依存関係に基づく「ウェーブ」方式で並列/順次タスク実行
- 各タスクごとにクリーンなコミット
- 実装内容の検証
/gsd:verify-work n：動作検証・ユーザー受け入れテスト（UAT）
- テスト可能な成果物を抽出し、対話的に確認
- 問題があれば自動的に修正プランを生成
/gsd:complete-milestone / /gsd:new-milestone：マイルストーンの完了・新規開始
- 各マイルストーンごとに定義→開発→出荷のサイクル

クイックモード（/gsd:quick）

小規模なタスクや即時対応に最適
アトミックコミット・状態管理は維持しつつ高速化
--discuss、--research、--full等のフラグで柔軟にカスタマイズ可能
.planning/quick/以下でタスク管理

なぜGSDは機能するのか

コンテキストエンジニアリングによるAIへの最適情報提供
**各種ファイル（PROJECT.md、REQUIREMENTS.md、ROADMAP.md、STATE.md、PLAN.md等）**による明確な文脈・状態管理
常に最新・正確な文脈でAIが動作し、品質劣化を防止
タスク分割・並列化・自動検証によりスケーラブルで堅牢な開発支援

GSDは、「AIに本当にやってほしいこと」を明確に伝え、誰でも一貫して高品質なアウトプットを得られる、現代的なAI開発のための最適なツール

Hackerたちの意見

https://github.com/obra/superpowersを使った経験は良かったよ。見た目は似てるけど、両方試した人、比較してくれない？

└

構造があるとすごく助かるよね。似たようなプロンプトのスキャフォールドを使ったことがあるけど、違いがすごく分かる。もう一つの良いテクニックは、リポジトリにこれらの構造を使って、AIにターゲットプロジェクトのベストプラクティスを使ってフレームワークを見直させること。創作、ヒューマナイジング、作曲、技術・科学分野などにすごく役立つよ。エージェントと組み合わせると、これらは本当にいい感じ。これは一時的なものになると思うけど、いくつかのモデルリリースまでの便利さを高めるハックだね。十分な成功事例がトレーニングデータに入れば、モデルはこういうことを余計なプロンプトなしでうまくやれるようになると思う。使うのが楽しいよ。

└

両方使ったことがあるけど、私の経験では、gsdは過剰に設計されたソフトウェアで、残念ながら何も進まないし、時間がかかる。クイックモードはあまり役に立たないし、gsdのポイントを殺しちゃう。アドホックでフルソフトウェアを構築するのは無理だよ。以前はプレーンなマークダウンプランを使ってたけど、制限があってあまり安定してなかった。superpowersはいい中間地点に見えるね。

└

両方試したことがあるけど、それぞれに長所と短所があるね。superpowersの嫌なところは、すべてのコードを実装プランに書き込んで、サブエージェントがそのコードをファイルに戻すだけってところ。それに、複数のセッションで作業したい場合、進捗を追うためにClaudeにprogress.mdファイルを作成させなきゃいけない。GSDはこれらの問題をほぼ解決してくれたけど、GSDの欠点は、何かを終わらせるのに時間がかかりすぎることだね。

└

なんで人々がこれにCLIラッパーを必要としてるのか分からない。Claudeのスキルを使って、必要なものを全部作れないの？

└

そうそう、個人的にはSuperpowersの方が「やるべきことをちゃんとやる」には向いてると思う。「やるべきことを片付ける」は、インフルエンサーが明日のTikTok投稿のために一晩でPotemkin SaaSを作る時には最適だけど。

└

現在のプロジェクトでSuperpowersを試してみたよ。ブログをHugoからAstro（AstroPaperテーマ）に移行する作業ね。メインの仕様書は2つの方法で書いたんだ。1) 新しいブログに何が欲しいかの小さなリストから始めて、エージェントと一緒にそれを広げていく方法（いわゆるコラボレーション仕様）と、2) Superpowersに仕様書と計画を作成してもらう方法。どちらもブログのリポジトリの作業ディレクトリから行ったから、エージェントはコードとコンテンツに完全にアクセスできた。結果はこうだった：1. Superpowersが作成した仕様書はすごく詳細で（特定のフォントやカラーパレットが記載されてた）、設定ファイルやコミットメッセージの正確な内容も含まれてた。でも、分析やRSSフィードなど、いくつかの重要な要素が抜けてた。2. Superpowersは仕様書と計画を2つの別々の文書として書いたから、コラボレーション方式よりも良かった。コラボレーション方式は両方を1つの文書にまとめてたから。3. Superpowersはブログのインプレース移行を推奨したけど、コラボレーション仕様はHugoとAstroが共存できるように並行ブランチを提案した。その他の違いについては[0]に書いてあるよ。全体的には、仕様を議論を通じて発展させるという点が気に入った。一発で決めるんじゃなくて、思い出したことを追加できる感じが良かった。初めての時に全てを正しくする必要がない、より反復的な発見プロセスのように感じた。ただの個人的な好みかもしれないけど。この作業の最後に、Claudeに両方の仕様書を詳しくレビューしてもらったら、両方の仕様書が見落としてた点（SEOやロールバックプランなど）をいくつか見つけて、全てを統合した最終仕様書を作成してくれた。[0] https://annjose.com/redesign/#two-specs-one-project

openspecが好きなんだ。自分好みにワークフローを調整できるし、邪魔にならないのがいい。最初は標準のspecフローで始めたけど、自信がついてきたら自分好みにシンプルにしていった。結局、spec駆動のフレームワークの目的は、自分でワークフローを持つことだと思う。そうすれば、自分の条件でコード生成を制約できるからね。

└

openspecも好きだな。こういうシステム（gsd/superpowers）はちょっと意見が強すぎると思う。機能しないわけじゃないけど、変化の速い時代に本当に対応するには、こういう超意見的なワークフローに縛られない方がいいと思う。だからopenspecの上にオーケストレーターライブラリを作ってるんだ。

これとsuperpowersを使ってたけど、最終的にはプランモードで十分になったし、Claude Codeを自分で操るのが好きになった。これらのフレームワークは、特にリサーチが関わるタスクにはいいけど、私の経験では10倍トークンを消費する。結果に対して明確な利益がないのに、いつもMaxプランの制限に引っかかってた。でも、これは人それぞれの作業スタイルによって大きく変わると思う。

└

最近、純粋なプランモードからsuperpowersにシフトしたんだ。最新バージョンの発表で思い出した。私の確認バイアスかもしれないけど、似たような問題に対してプランモードよりも良い結果が出てる気がする。これは多層のクロスチェックと自己レビューのおかげだと思ってる。もちろん手作業でもできるけど、superpowersが私がやろうとしてたことを自動化してくれてる感じがする。

└

なんでClaude Codeを使ってるのにCLIラッパーを使ってるの？Codexみたいなものが必要なのは分かるけど、今日サブエージェントがリリースされたから、もしかしたらそれも必要ないかもね。Claude Codeには余計なラッパーだと思う。

└

プラグインをちょっと触ってみたけど、言った通り、プランモードは大体うまくやってくれるね。Claudeでいろんなワークフローを試してみたけど、CCがカスタムスキルやエージェントを作ってくれるおかげで、80%はうまくいってる。Claudeファイルがそれらを参照するだけで、全体のワークフローを定義しようとするよりもずっと楽だし。たまに忘れちゃうこともあるけど、そんなに大きな問題じゃない。少なくとも、手動でスラッシュコマンドを覚えるよりは自然に使えるから、十分だよ。

└

他の90%はどうなってるの？

└

Gryphの開発にはしばらくの間、スーパーパワーを使ってるよ。ブレインストーミングや探求が楽しいんだ。トークンの使い方はあんまり比べてないけど、何かしら役に立ってるよ。

└

結局、スーパーパワーからブレインストーム、デザイン、実装計画のスキルを取り入れて、実装計画が完成したら自分の入力を求めないRalphベースの実装レイヤーに移植したよ。危険な権限設定のせいでDockerサンドボックスで動かさなきゃいけないけど、それはそれでいいアイデアだと思う。うまく動いてるし、生産性も高くて楽しんでるけど、実際の目的地というよりは旅の一歩って感じ。これからこの旅がどこに行くのか楽しみだよ。

Superpowersと従来のPRD→タスク生成器を比較したんだけど、少ない方がいいって確信したよ。少なくとも今はね。gsdはうまく機能したけど、分かるのに何時間もかかった。PRDを作成するためのシンプルな説明の後に、少し技術的なタスクリストを提示した方がずっと良かった。grdやsuperpowersが解決策を見つけられなかったわけじゃなくて、ただそれをするのに時間がかかりすぎて、もっと多くの助けが必要だっただけ。私にとっての教訓は、ワークフローが変わったってこと。古いプロジェクト開発のパラダイムをこの新しい/異質な技術に適用できないってことだね。新しいマニュアルがあって、古いものに基づいてない。

一度試したことがあるけど、すごく冗長で、信じられないくらいのファイルを生成したんだ。ユーザーとのインタラクションで新しい要件が出てくると、迅速かつ安価に、かつ堅牢に更新するのが難しくなるんじゃないかと思って使うのをやめた。今のところ、プロジェクト要件文書から始めて、次にステップバイステップの実装計画を求めて、各ステップを進めるって方法が一番いい。しかも、各ステップの戦略を承認した後にだけ行動するようにしてる。最小限でモジュール化された機能的なステートレスコードを指定することも忘れない。

「私はすごく生産的な人で、ただやるべきことをやりたいだけ」ってプロフィール見たら、面白いことを何もやってないし、ただ「やるべきことを片付ける」ための製品を宣伝してるだけだった。これって、TODOリスト本の達人たちが生産性について書いてるのと同じだね。

└

GitHubのプロフィールを5秒見ただけで、音楽関連のものがたくさんあって、私たちには何かわからないプライベートリポジトリへの貢献もたくさんあるのが見えた。生産性の達人のアンチパターンは理解できるけど、正直言って、あなたがこの反射的な個人攻撃をするほどの何を見ているのかがわからない。

自分が使ってるAIシステムがあるんだけど、他の人にも使ってもらえるように公開したいなって思ってる。でも、全部自分用にカスタマイズしてるから、他の人向けにバージョンを作ると、そのメンテナンスもしなきゃいけなくなるんだよね。同じような状況の人いる？リリースされてるのを見ると、あんまり複雑じゃないものが多い気がするけど、自分のシステムの使い方をどうやって伝えればいいのか分からない。誰かに自分のシステムを使ってほしいわけじゃなくて、ただ自分のAIシステムに指示して、何か価値のあるものを自分のシステムに追加できるか聞いてほしいだけなんだ。人のためにメンテナンスしたくないし、魔法のような治療法として売り込みたくもない。ただ、他の人が使えるパターンを見せたいだけ。

└

メンテナンスしなくても大丈夫だよ。特にAIの時代では、人にインスピレーションを与えたり、何か感じてもらうだけで十分だし、感謝されるよ。

これを1週間試してみたけど、諦めちゃった。往復が多すぎて、トークンも消費しすぎたし、人間の介入が必要すぎた。だから、実際にはあんまり良い名前じゃないと思う。むしろ「プランニング・シット」って呼ぶべきだね。これを使ってる間にやってたことの80%以上はそれだったし。物事を進める時には全然必要なかったし、計画もまあまあだったよ。

コーディングスロットマシンを使う時は、何かがうまくいかなかったらすぐにやり直すのが好きだな。いくつかの反復で使ったトークンの量は、GSDのようなもっと計画的なシステムを使うのと似てるかもしれない。

これは、プロンプトからファイルやワークフローにコンテキストを移す感じだね。整合性を保つためには理にかなってるけど、問題が変わるよね。実際のコードベースとそのアーティファクトを時間をかけてどうやって同期させるの？

ハクソク