Detailed specs decay, a new study warns. 4 Claude Code SDD skills compared
A new arXiv paper studied how developers really use spec-driven development (SDD) with coding agents. Implementation detail in a spec may help the agent, but it makes the spec prone to decay, and people mostly compare spec and code when a change is finished. Among the four Claude Code SDD skills we rank, one enforces that comparison with scripts.
What did the spec-driven development study find?
The paper is Spec-Driven Development as Prescribed and as Practiced (arXiv 2608.25202), by Shyam Agarwal, Anmol Singhal, Andrew Macvean, Bogdan Vasilescu and Travis Breaux. It was first posted on August 25, 2026, and the current version (v4) is dated October 15, 2026.
The authors note that most evidence about SDD so far comes from tool vendors. So they went to practitioners instead: a thematic analysis of Reddit discussions, interviews with 21 practitioners (eight of whom build SDD tools), and a look at 266 active, popular repositories. Those repos come from SpecMine, a corpus of 470,795 spec files from 73,030 public GitHub repositories, which the authors release with the paper.
The abstract reports five things that matter for agent skills:
- Practitioners agree a spec should capture intent, but many specs also carry implementation details.
- SDD gets used selectively, mostly for new features.
- People see more reliable agent behavior, and pay for it with more planning and review time.
- Implementation detail may help agents while making specs prone to decay.
- Participants described spec-code checks "mainly when changes are completed rather than over time."
We maintain a guide to spec-driven development skills for Claude Code, so we reread the SKILL.md of each of the four skills it ranks against those findings. Install counts below are from the skills.sh registry as of October 23, 2026.
Should a spec for a coding agent include implementation details?
The four skills disagree, and the disagreement lines up with the paper's trade-off.
spec-driven-development skill by addyosmani (GitHub: addyosmani/agent-skills) is the most installed, at 63,637 installs. Its spec has six required areas: objective, commands, project structure, code style, testing strategy and boundaries. Half of those describe how the thing gets built. You give the agent exact build and test commands with flags, a directory layout, and a real code snippet that shows your style. That is the "detail helps the agent" side of the trade-off.
spec-driven-implementation skill by warpdotdev (GitHub: warpdotdev/common-skills), at 28,685 installs, splits the two concerns into files. PRODUCT.md stays behavior-oriented and light on implementation. TECH.md holds the how, and gets written when warranted, for example when the work spans multiple subsystems, when architecture or extensibility matters, when there are real tradeoffs to document, or when reviewers gain more from the plan than from the raw code.
spec-driven-development skill from jasonkneen/kiro (GitHub: jasonkneen/kiro), at 426 installs, lists implementation details in requirements as a pitfall. Requirements say what, the separate design document says how.
If the paper's decay finding matches what you've seen in your own repo, the warpdotdev split is the practical takeaway: a product spec that rarely needs edits, and a tech spec you expect to churn.
When should you skip spec-driven development?
The study found SDD used selectively, mostly for new features. Every one of these skills tells the agent to do exactly that:
- warpdotdev's skill names an expected implementation of about 1,000 lines or more as a reason to write specs. It calls them often unnecessary for small, local bug fixes, straightforward refactors and narrow UI tweaks.
- addyosmani's skill excludes single-line fixes, typo corrections and changes whose requirements are already unambiguous.
- tlc-spec-driven sizes itself. A change that touches three files or fewer and fits in one sentence gets a one-line inline spec and skips the Design and Tasks phases.
- kiro's skill marks simple bug fixes, rapid prototypes and urgent hotfixes as less suitable.
So when practitioners say they only use SDD sometimes, that is the intended behavior, and the skill authors wrote it down.
How do SDD skills handle the extra planning and review cost?
The paper links SDD to more reliable agents and to higher planning and review cost. The skills pay that cost in different places.
addyosmani's skill pays it up front. Before writing the spec, the agent lists its assumptions so you can correct them. After saving the spec, it summarizes it, lists open questions and ends its turn. Planning starts only after you approve in a later turn, and a human reviews after each of Specify, Plan, Tasks and Implement. Its boundaries come in three tiers (Always, Ask first, Never), so decisions like schema changes or new dependencies are settled once in the spec instead of argued in every review. Tasks are capped at about 5 changed files each, which keeps each review small.
kiro's skill makes review cheaper per item. Each acceptance criterion uses EARS notation:
WHEN [event] THEN [system] SHALL [response]
A criterion in that shape turns straight into a test, and each task carries references back to the requirements it implements. Pair it with a test-first flow like the one in our TDD skill guide for Claude Code.
Which Claude Code skill checks the spec against the code?
tlc-spec-driven skill by tech-leads-club (GitHub: tech-leads-club/agent-skills), at 1,185 installs, is the one that hands the check to code. It ships Python scripts that validate the spec (EARS criteria, requirement IDs), the task list and each commit message. It requires one atomic commit per task. Every acceptance criterion gets a check with the test command that proves it. After the last task, a script runs all of those proofs at HEAD, and then a fresh verifier sub-agent, which never wrote the code, tries mutations to find rules that would stay green when they shouldn't.
Look at the timing, though. The proofs run once, after the last task. That is the pattern the paper describes: checks at completion, not over time. tlc has one partial answer. When you resume in a new session, it reconciles its .specs/ files against git, and the git evidence wins over a note.
warpdotdev and addyosmani treat decay as a process problem. warpdotdev's skill wants PRODUCT.md and TECH.md updated in the same PR as the code that changed them. When a spec cites code, it pins the commit SHA and links the exact lines, so a stale reference is easy to spot. addyosmani's skill says to update the spec before you implement a changed decision, commit the spec, and link the relevant spec section from each PR.
None of the four runs a continuous spec-versus-code check on every push. That is the gap the paper points at. tlc's scripts need only the Python 3.8+ standard library, which makes them the obvious place to start if you want to try it. We haven't wired them into CI ourselves.
How do you install these spec-driven development skills?
npx skills add https://github.com/addyosmani/agent-skills --skill spec-driven-development
npx skills add https://github.com/warpdotdev/common-skills --skill spec-driven-implementation
npx skills add https://github.com/jasonkneen/kiro --skill spec-driven-development
npx skills add https://github.com/tech-leads-club/agent-skills --skill tlc-spec-driven
If your team already uses GitHub's Spec Kit, there are two more options. The speckit-plan skill from dceoy/speckit-agent-skills (GitHub: dceoy/speckit-agent-skills) has 2,443 installs. The spec-kit-skill by feiskyer (GitHub: feiskyer/claude-code-settings, 665 installs) checks for the specify CLI and guides setup.
Which one should you pick?
Start with addyosmani's skill for a gated default. Move to warpdotdev's when your team writes specs per ticket and you want product intent kept apart from implementation detail. Pick tlc-spec-driven when you want scripts to hold the gates and run the final spec-code check. After the spec is approved, a pattern like subagent-driven development for Claude Code can take over execution.
For the wider field, see the best skills for docs and planning ranking, the docs and planning category, or the full list of Skillselion guides.
Disclosure: we run Skillselion, the directory these install counts come from. It's a live catalog, refreshed daily from skills.sh, GitHub and MCP registries, ranked by real installs. We are not affiliated with Anthropic, OpenAI or Cursor, or with the paper's authors.
Mentions
Claude Codeの仕様駆動開発スキルはEARS要件をどう書くか: Kiro流スキルとcc-sddのSKILL.mdを読み比べる Claude Codeで仕様駆動開発(SDD)を回すなら、要件はEARS記法で書かせるのが一番テストに落としやすいです。Kiro流の要件をそのまま使いたいなら jasonkneen/kiro の requirements-engineering スキル、日本語で要件を書きたいなら gotalab/cc-sdd が向いています。ゲート付きの汎用フローが欲しい場合は、インストール数最多の addyosmani/agent-skills の spec-driven-development が無難な起点です。 最終更新: 2026年10月28日 ! 筆者はSkillselionを運営しています。 この記事で触れるインストール数は、skills.sh・GitHub・MCPレジストリから毎日更新し実際のインストール数で並べているライブカタログの値で、2026年10月28日時点のものです。英語版の全体像は仕様駆動開発スキルのランキングガイドにまとめています。この記事は、そのうち「要件をどう書かせるか」に絞って各スキルのSKILL.mdを読んだ記録です。 仕様駆動開発スキルは何をしてくれるのか SDDスキルの仕事は、エージェントにいきなりコードを書かせず「要件 → 設計 → タスク」の順に文書を作らせ、人間の承認を挟むことです。どのスキルもこの骨格は同じで、違いが出るのは次の3点でした。 要件(受け入れ基準)をどの書式で書かせるか プロジェクト全体の前提(ステアリング)をどこに置くか タスクをどの粒度で切り、要件とどう紐づけるか 以下、この3点に沿って見ていきます。 EARS記法で要件を書かせるには EARS(Easy Approach to Requirements Syntax)は、要件を「条件 + 主語 + 応答」の決まった型で書く記法です。曖昧な「速くする」「使いやすくする」を、テストケースにそのまま変換できる文に置き換えるのが目的です。 jasonkneen/kiro の書き方: WHEN ... THEN ... SHALL Kiro流の要件定義スキル requirements-engineering(GitHub)は、KiroのSDDをClaude Code向けのスキルに切り出したものです。インストール数は330です。SKILL.mdが基本形として示すのはこの型です。 WHEN [triggering event] THEN [system] SHALL [required response] ほかに IF [precondition is met] THEN [system] SHALL ... の条件型、AND/ORで条件を足す複合型、状態・性能・セキュリティ向けの応用型が並びます。実用的なのは「よくある間違い」の節で、たとえば実装詳細を要件に書く例として "System shall use Redis for caching" を悪い例に挙げ、キャッシュ済みの結果を返すという振る舞いで書き直させています。要件に技術選定が混ざる事故は人間のレビューでも見落としやすいので、エージェント側でこの区別をしてくれるのはありがたいところです。 エッジケースの洗い出しも型になっていて、空入力、境界値、失敗時、未認可、同時操作の5つを毎回問うよう指示しています。 gotalab/cc-sdd の書き方: When ..., the [system] shall ... 日本の開発者には gotalab/cc-sdd のほうが馴染みがあるかもしれません。GitHubスター数は3,746(2026年10月28日時点、GitHub API)で、Claude Code、Codex、Cursor、Copilotなど複数のエージェント向けにAgent Skillsを生成するSDDハーネスです。なお2026年10月28日時点では、cc-sddはSkillselionのカタログにまだ載っていません。 cc-sddの kiro-spec-requirements スキルは、共有ルール ears-format.md を読んでから要件を書きます。こちらは本来のEARSに近い形で、型が5つあります。 型 パターン イベント駆動 When [event], the [system] shall [response/action] 状態駆動 While [precondition], the [system] shall [response/action] 異常系 If [trigger], the [system] shall [response/action] オプション機能 Where [feature is included], the [system] shall [response/action] 常時 The [system] shall [response/action] jasonkneen版との一番大きな違いは While(状態)と Where(オプション機能)、それに条件なしの常時要件が独立した型として用意されている点です。「決済処理中はローディングを出す」のような状態依存の要件を、WHENで無理に書かずに済みます。 主語の選び方にも指示があり、ソフトウェアなら「Checkout Service」のように具体的なサービス名を使え、と書かれています。「システムは」で全部済ませると、マイクロサービス構成でどこの責務か分からなくなるので、これは効きます。 日本語で要件を書くときに何が変わるか ここが日本の開発者にとって実際に差が出るところです。cc-sddの ears-format.md には、トリガーのキーワードと定型句(When、If、While、Where、The [system] shall)は英語のまま残し、[event] や [response/action] などの可変部分だけを対象言語に訳す、というルールが明記されています。インストールも npx cc-sdd@latest --lang ja のように言語を指定できます。 つまり、要件はこういう書き方になります(cc-sddの ears-format.md にある例を、ルールどおり可変部分だけ日本語にしたものです)。 When ユーザーが購入ボタンを押す, the Checkout Service shall カートの内容を検証する While 決済処理中, the Checkout Service shall ローディング表示を出す 一見ちぐはぐですが、キーワードが英語で固定されているので、grepや簡単なスクリプトで型ごとに要件を数えたり、テストケースに機械的に変換したりできます。全文を日本語にすると「〜したとき」「〜の場合」の揺れで、このあたりが崩れがちです。 jasonkneen/kiroのスキルには言語の指定がなく、例文もすべて英語です。日本語で書かせることはできますが、キーワードを英語で固定するかどうかは自分でプロンプトかステアリングに書く必要があります。 もう一つ、cc-sddのrequirementsスキルには判定基準として「技術に触れずに書ける受け入れ基準は要件、技術選定が要るものは設計」という一文があります。jasonkneen版のRedisの例と同じ考え方を、1行のリトマス試験にしたものです。 ステアリングファイルには何を書くのか ステアリングは、スペックごとではなくプロジェクト全体で毎回エージェントに読ませる前提知識です。CLAUDE.mdに近い役割で、ファイルを分けて読み込み条件を付けられます(Claude Code側でも .claude/rules/ でファイル種別ごとにルールを分けられるので、考え方は近いです)。 Kiro流のステアリング生成スキル create-steering-documents(GitHub)は .kiro/steering/ 配下にファイルを作ります。インストール数は83です。読み込み方は3種類あります。 front-matterなし: 毎回のやり取りに常に含める inclusion: fileMatch: 特定のファイルがコンテキストにあるときだけ含める(例では '.tsx|.jsx|.vue|.svelte') inclusion: manual: 明示的に参照したときだけ含める フロントエンド規約は .tsx を触るときだけ、API設計ガイドは必要なときだけ、という切り分けができるので、コンテキストを無駄に食いません。#[[file:path]] でOpenAPI仕様やDBスキーマを参照させる書き方も載っています。 cc-sddの kiro-steering は考え方が少し違い、ステアリングを「永続的なプロジェクトメモリ」として扱います。中核は product.md、tech.md、structure.md の3ファイルで、初回はコードベースから生成し(Bootstrap)、以降はコードとのずれを検出して追記する(Sync)という2モードで動きます。SKILL.mdには、ユーザーが手で書いたカスタマイズは尊重し更新は追記で行う、という方針が書かれています。既存リポジトリに後から入れるなら、こちらのほうが手間が少ないはずです。 タスク分解はどの粒度で切るのか Kiro流のタスク分解スキル task-breakdown(GitHub)(インストール数97)は、2階層のチェックリストでタスクを書かせます。各タスクの末尾に _Requirements: 1.2, 2.1_ のように要件番号を付けるのが特徴で、どのタスクがどのEARS要件を満たすのかを後から追えます。適切な粒度は「集中して2〜4時間の作業」とされ、「Build user stuff」のような中身のないタスクは悪い例として挙げられています。 cc-sddの kiro-spec-tasks は、並列実行できるタスクに (P) マーカーを付けます。並列に見えても安全でないタスクには、(P) を付けない理由として依存関係を明記させる指示もあります。サブエージェントで並列に実装を回す前提なら、この情報があるかどうかで事故の起きやすさが変わります。並列実装の進め方はサブエージェント駆動開発スキルのガイドでも扱っています。 この3つ(要件・設計・タスク)を一つにまとめたのがKiro流SDDスキル spec-driven-development(GitHub)で、インストール数は428です。要件を終えてから設計、設計を終えてからタスク、とフェーズを飛ばさないことを繰り返し求めています。 Kiro系以外のSDDスキルはどう違うのか EARSにこだわらないなら、インストール数で見た上位はこの3つです(2026年10月28日時点)。 addyosmaniの仕様駆動開発スキル(GitHub): インストール数65,697。Specify、Plan、Tasks、Implementの4フェーズで、スペックを保存したら "STOP YOUR TURN IMMEDIATELY." と書かれており、承認前に計画やコードへ進ませません。境界を Always do / Ask first / Never do の3段で書かせるのも、チームの暗黙ルールを明文化するのに便利です。 warpdotdevのスペック駆動実装スキル(GitHub): インストール数28,729。specs/<linear-ticket-number>/ の下に PRODUCT.md を先に書き、必要なときだけ TECH.md を足します。チケット単位で仕様を管理するチーム向けです。 tech-leads-clubのtlc-spec-drivenスキル(GitHub): インストール数1,209。validate_spec.py、validate_tasks.py、check_commit.py などのPythonスクリプトでゲートを検証します。validate_spec.py はEARS形式の受け入れ基準もチェックします。モデルの記憶ではなくコードで仕様を守らせたい場合の選択肢です。 addyosmani版のSpecifyフェーズにEARS形式の受け入れ基準を書かせる、という組み合わせも十分ありです。EARS要件はそのままテストに変換できるので、TDDスキルのガイドで紹介しているテストファーストの流れとも相性が良いです。 結局どれを入れればいいか やりたいこと 候補 日本語で要件を書き、キーワードは英語で固定したい gotalab/cc-sdd(--lang ja) Kiroの書式をClaude Codeでそのまま再現したい jasonkneen/kiro の各スキル 承認ゲートが堅い汎用フローが欲しい addyosmani/agent-skills の spec-driven-development チケットごとにPRODUCT.md / TECH.mdを残したい warpdotdev/common-skills の spec-driven-implementation ゲートをスクリプトで検証したい tech-leads-club/agent-skills の tlc-spec-driven jasonkneen版はスキル単位で入れられるので、要件定義だけ試すことも可能です。 npx skills add jasonkneen/kiro --skill requirements-engineering 設計書や計画系のスキルをもっと比べたい場合は、ドキュメント・計画系スキルのランキングとドキュメント・計画カテゴリの一覧にまとめています。 よくある質問 Q. EARSのキーワードは日本語に訳さないほうがいいですか? cc-sddのルールでは、When や shall などの定型句は英語のまま、可変部分だけを日本語にします。キーワードが固定されていると、要件を型ごとに集計したりテストに変換したりする処理が単純になります。 Q. ステアリングとCLAUDE.mdは何が違いますか? どちらもプロジェクトの前提を書く場所ですが、Kiro流のステアリングはファイルを分け、inclusion: fileMatch や inclusion: manual で読み込む条件を付けられます。常時読ませる情報と、特定のファイルを触るときだけ読ませる情報を分けられるのが利点です。 Q. 小さなバグ修正にもSDDは必要ですか? warpdotdevのスキルは、小さく局所的なバグ修正ではスペックが不要なことが多いとしています。tlc-spec-drivenも小さな機能では設計とタスクのフェーズを省略します。 各スキルの最新のインストール数と順位は、Claude Code向け仕様駆動開発スキルの比較ページで確認できます。
Detailed specs decay, a new study warns. 4 Claude Code SDD skills compared A new arXiv paper studied how developers really use spec-driven development (SDD) with coding agents. Implementation detail in a spec may help the agent, but it makes the spec prone to decay, and people mostly compare spec and code when a change is finished. Among the four Claude Code SDD skills we rank, one enforces that comparison with scripts. What did the spec-driven development study find? The paper is Spec-Driven Development as Prescribed and as Practiced (arXiv 2608.25202), by Shyam Agarwal, Anmol Singhal, Andrew Macvean, Bogdan Vasilescu and Travis Breaux. It was first posted on August 25, 2026, and the current version (v4) is dated October 15, 2026. The authors note that most evidence about SDD so far comes from tool vendors. So they went to practitioners instead: a thematic analysis of Reddit discussions, interviews with 21 practitioners (eight of whom build SDD tools), and a look at 266 active, popular repositories. Those repos come from SpecMine, a corpus of 470,795 spec files from 73,030 public GitHub repositories, which the authors release with the paper. The abstract reports five things that matter for agent skills: - Practitioners agree a spec should capture intent, but many specs also carry implementation details. - SDD gets used selectively, mostly for new features. - People see more reliable agent behavior, and pay for it with more planning and review time. - Implementation detail may help agents while making specs prone to decay. - Participants described spec-code checks "mainly when changes are completed rather than over time." We maintain a guide to spec-driven development skills for Claude Code, so we reread the SKILL.md of each of the four skills it ranks against those findings. Install counts below are from the skills.sh registry as of October 23, 2026. Should a spec for a coding agent include implementation details? The four skills disagree, and the disagreement lines up with the paper's trade-off. spec-driven-development skill by addyosmani (GitHub: addyosmani/agent-skills) is the most installed, at 63,637 installs. Its spec has six required areas: objective, commands, project structure, code style, testing strategy and boundaries. Half of those describe how the thing gets built. You give the agent exact build and test commands with flags, a directory layout, and a real code snippet that shows your style. That is the "detail helps the agent" side of the trade-off. spec-driven-implementation skill by warpdotdev (GitHub: warpdotdev/common-skills), at 28,685 installs, splits the two concerns into files. PRODUCT.md stays behavior-oriented and light on implementation. TECH.md holds the how, and gets written when warranted, for example when the work spans multiple subsystems, when architecture or extensibility matters, when there are real tradeoffs to document, or when reviewers gain more from the plan than from the raw code. spec-driven-development skill from jasonkneen/kiro (GitHub: jasonkneen/kiro), at 426 installs, lists implementation details in requirements as a pitfall. Requirements say what, the separate design document says how. If the paper's decay finding matches what you've seen in your own repo, the warpdotdev split is the practical takeaway: a product spec that rarely needs edits, and a tech spec you expect to churn. When should you skip spec-driven development? The study found SDD used selectively, mostly for new features. Every one of these skills tells the agent to do exactly that: - warpdotdev's skill names an expected implementation of about 1,000 lines or more as a reason to write specs. It calls them often unnecessary for small, local bug fixes, straightforward refactors and narrow UI tweaks. - addyosmani's skill excludes single-line fixes, typo corrections and changes whose requirements are already unambiguous. - tlc-spec-driven sizes itself. A change that touches three files or fewer and fits in one sentence gets a one-line inline spec and skips the Design and Tasks phases. - kiro's skill marks simple bug fixes, rapid prototypes and urgent hotfixes as less suitable. So when practitioners say they only use SDD sometimes, that is the intended behavior, and the skill authors wrote it down. How do SDD skills handle the extra planning and review cost? The paper links SDD to more reliable agents and to higher planning and review cost. The skills pay that cost in different places. addyosmani's skill pays it up front. Before writing the spec, the agent lists its assumptions so you can correct them. After saving the spec, it summarizes it, lists open questions and ends its turn. Planning starts only after you approve in a later turn, and a human reviews after each of Specify, Plan, Tasks and Implement. Its boundaries come in three tiers (Always, Ask first, Never), so decisions like schema changes or new dependencies are settled once in the spec instead of argued in every review. Tasks are capped at about 5 changed files each, which keeps each review small. kiro's skill makes review cheaper per item. Each acceptance criterion uses EARS notation: WHEN [event] THEN [system] SHALL [response] A criterion in that shape turns straight into a test, and each task carries references back to the requirements it implements. Pair it with a test-first flow like the one in our TDD skill guide for Claude Code. Which Claude Code skill checks the spec against the code? tlc-spec-driven skill by tech-leads-club (GitHub: tech-leads-club/agent-skills), at 1,185 installs, is the one that hands the check to code. It ships Python scripts that validate the spec (EARS criteria, requirement IDs), the task list and each commit message. It requires one atomic commit per task. Every acceptance criterion gets a check with the test command that proves it. After the last task, a script runs all of those proofs at HEAD, and then a fresh verifier sub-agent, which never wrote the code, tries mutations to find rules that would stay green when they shouldn't. Look at the timing, though. The proofs run once, after the last task. That is the pattern the paper describes: checks at completion, not over time. tlc has one partial answer. When you resume in a new session, it reconciles its .specs/ files against git, and the git evidence wins over a note. warpdotdev and addyosmani treat decay as a process problem. warpdotdev's skill wants PRODUCT.md and TECH.md updated in the same PR as the code that changed them. When a spec cites code, it pins the commit SHA and links the exact lines, so a stale reference is easy to spot. addyosmani's skill says to update the spec before you implement a changed decision, commit the spec, and link the relevant spec section from each PR. None of the four runs a continuous spec-versus-code check on every push. That is the gap the paper points at. tlc's scripts need only the Python 3.8+ standard library, which makes them the obvious place to start if you want to try it. We haven't wired them into CI ourselves. How do you install these spec-driven development skills? npx skills add https://github.com/addyosmani/agent-skills --skill spec-driven-development npx skills add https://github.com/warpdotdev/common-skills --skill spec-driven-implementation npx skills add https://github.com/jasonkneen/kiro --skill spec-driven-development npx skills add https://github.com/tech-leads-club/agent-skills --skill tlc-spec-driven If your team already uses GitHub's Spec Kit, there are two more options. The speckit-plan skill from dceoy/speckit-agent-skills (GitHub: dceoy/speckit-agent-skills) has 2,443 installs. The spec-kit-skill by feiskyer (GitHub: feiskyer/claude-code-settings, 665 installs) checks for the specify CLI and guides setup. Which one should you pick? Start with addyosmani's skill for a gated default. Move to warpdotdev's when your team writes specs per ticket and you want product intent kept apart from implementation detail. Pick tlc-spec-driven when you want scripts to hold the gates and run the final spec-code check. After the spec is approved, a pattern like subagent-driven development for Claude Code can take over execution. For the wider field, see the best skills for docs and planning ranking, the docs and planning category, or the full list of Skillselion guides. Disclosure: we run Skillselion, the directory these install counts come from. It's a live catalog, refreshed daily from skills.sh, GitHub and MCP registries, ranked by real installs. We are not affiliated with Anthropic, OpenAI or Cursor, or with the paper's authors.