Get Shit Done（GSD）は、Claude Code とともに使うための、メタプロンプティング、コンテキストエンジニアリング、仕様駆動開発 の軽量なシステムを名乗っている。独自のプラットフォームを定義するのではなく、エージェントの上に重なるコマンドと規約のレイヤーとして動作し、モデルに与えるコンテキストを構造化すること、そして大まかな要求を仕様と実行可能なステップに変えることに重点を置いている。プロンプトからプロセスへ：AI ソフトウェア開発エージェントを支援するフレームワークのプロセス分類法と比較評価 で評価された 6 つのフレームワークの 1 つである。
機能
GSD を特徴づける手法は、コンテキストの構築を明示的なエンジニアリング作業として扱うことである。エージェントが行動する前に、何を、どの順序で、どのような枠組みのもとで読むべきかを決める。評価を行った研究は、この重視の姿勢を、仕様駆動開発の文献におけるグラウンディング用フックに関する研究と結びつけている。その文献は、大規模なリポジトリではエージェントがコンテキストを見失う（コンテキスト盲目に陥る）ことがあると報告している。
採用とエコシステム
6 次元プロセス分類法 のもとで、GSD はコンテキストで 2、仕様で 1、ロール・検証・ポータビリティで 0、実行で 1 と評価されている。合計は 12 点中 4 点で、評価された 6 つのフレームワークの中で最も低く、3 つの次元で 0 点となった唯一のフレームワークである。GSD はこの研究が最もコンテキストに重点を置いていると述べるフレームワークであり、この研究は 6 つの次元を互いに重ならない区分ではなく相補的な読み解きのレンズとして扱っているため、1 つの機能が複数の次元で点数を得ることもある。これらの点数は独立した実証的測定ではなく、公式ドキュメントに基づく研究著者の判断を表しており、独立した第二の評価者を置かずに単一の評価者によって付けられたものである。
2 つの限界が挙げられている。GSD は特定のエージェントと強く結びついているため、そのポータビリティは GitHub Spec Kit や OpenSpec よりも限られており、その有効性はチームが採用するプロンプト規約の質に左右される。また研究は、リポジトリが新しい組織へのメンテナンス移管を告知したことにも触れ、これを最近のコミュニティ製フレームワークに典型的な不安定さの例として挙げている。この不安定さは、インストール可能なコマンドキットやエージェント規約がもたらすサプライチェーン上のリスクと並んで、研究がこの分野で繰り返し現れるリスクとして挙げているものでもある。