implement-spec

implement-spec is a skill for Claude Code, Codex from dogganidhal/noddde. It costs 39 tokens per session (967 once invoked), scanned A, original, MIT.

A procedure for turning a written software specification into working code when the tests are already prepared and failing. It is one step in a six-step development process and does not create tests.

In plain words
What is it for?
It is for implementing a specification in an existing project, after running `/generate-tests` and before later validation steps.
Why use it?
It prevents implementation from starting before the specification and required tests are ready, and keeps test creation separate from code writing.

Skill for Claude CodeCodex

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add skills/dogganidhal/noddde/implement-spec
Any agent
npx skills add dogganidhal/noddde --skill implement-spec
Clone the repo
git clone --depth 1 https://github.com/dogganidhal/noddde

Made for: Claude Code, Codex.

Wrote this? Show the measurements

A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.

agentmods badge for implement-spec

README.md
[![agentmods](https://agentmods.dev/badge/skills/dogganidhal/noddde/implement-spec.svg)](https://agentmods.dev/skills/dogganidhal/noddde/implement-spec)
Your own site
<a href="https://agentmods.dev/skills/dogganidhal/noddde/implement-spec"><img src="https://agentmods.dev/badge/skills/dogganidhal/noddde/implement-spec.svg" alt="Measured on agentmods" height="20"></a>
Per session 39 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 967 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00039 $0.00967
Opus 5 $0.00019 $0.00483
Sonnet 5 $0.00008 $0.00193
Haiku 4.5 $0.00004 $0.00097

Measured 4d ago against content hash d5855bf1ee7c, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

implement-spec scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 4d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

.claude/skills/implement-spec/SKILL.md · 97 lines

How it starts

The opening of the file, as written. The whole thing — 97 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Step 3: Implement the Spec (Code Only)

Turn a behavioral specification into working code. Tests already exist and are RED — your job is to make them GREEN.

Pipeline step 3 of 6. Called by the /spec orchestrator after step 2 (test generation).

Key principle: This step writes ONLY implementation code. It does NOT generate tests — that was step 2. If tests don't exist yet, stop and tell the developer to run /generate-tests first.

Step 1: Verify Prerequisites

  1. Read the spec at the provided path
  2. Check status is ready or implementing — if draft, ask the developer to promote it first
  3. Check that tests exist: Look for the test file at the expected path:
    • specs/core/<path>/<name>.spec.mdpackages/core/src/__tests__/<path>/<name>.test.ts
    • specs/integration/<name>.spec.mdpackages/core/src/__tests__/integration/<name>.test.ts
  4. If tests don't exist: STOP. Tell the developer:
    ⚠️  No test file found at <expected-path>.
    Tests must be generated before implementation (RED-GREEN workflow).
    Run `/generate-tests <spec-path>` first.
    

Step 2: Read Everything

  1. Read the spec completely — all sections
  2. Read the source file at source_file from frontmatter
  3. Read the existing test file — understand what the tests expect
  4. Read dependency specs listed in depends_on — understand input types and contracts
  5. Read dependency source files — understand what's already implemented
  6. Read sample usage if relevant — search packages/samples/src/ for usage of the module

Step 3: Set Status

Update the spec frontmatter: status: implementing

Step 4: Implement

Replace throw new Error("Not implemented") stubs with working code.

Order: Implement behavioral requirements in their numbered order. Each requirement should be satisfiable independently.

Follow these conventions (from CLAUDE.md):

  • Functional style: no classes for domain concepts
  • Strict TypeScript: strict: true, noUncheckedIndexedAccess: true
  • JSDoc on all public exports
  • No decorators, no DI containers, no base classes for domain concepts
  • Handler signatures must match exactly:
    • Decide handlers: (command, state, infrastructure) => Event | Event[] | Promise<Event | Event[]>
    • Evolve handlers: (event.payload, state) => newState — pure, sync
    • Event handlers: (event.payload, infrastructure) => void | Promise<void>
    • Saga handlers: (event, state, infrastructure & CQRSInfrastructure) => SagaReaction | Promise<SagaReaction>
    • Query handlers: (query.payload, infrastructure) => Result | Promise<Result>
    • Projection reducers: (event, view) => view | Promise<view>

Read the full file on GitHub · 97 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 4d ago First seen · 97 lines · 39 tokens per session scan A d5855bf1ee7c

Subscribe to this mod's changes

implement-spec is a skill published in the GitHub repository dogganidhal/noddde (48 stars, last pushed 4d ago), licensed MIT. It adds 39 tokens to every session and 967 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.

Related

Other skills, from other repositories

package-design

乱雑なコードベースを、明確なパッケージ/モジュール構造に再設計するための指針。 対象は (1) 乱雑なコードの再整理、(2) 単一巨大モジュールの分割、 (3) パッケージ境界のレビュー、(4) 新規プロジェクトのモジュール階層設計。 トリガー:「パッケージ構造を見直したい」「モジュールの依存関係が複雑」 「ファイル配置を整理したい」「循環依存を解消したい」といった構造改善リクエストで起動。.

j5ik2o/event-store-adapter-js · 157 tokens

gh-issue-organizer

GitHub Issue の棚卸し・整理を体系的に実行するスキル。オープンイシューの分類、 グルーピング、クローズ判定、優先度付け、バッチ化を行う。 CodeRabbit 自動生成イシューと手動報告イシューの区別、根本原因別グルーピング、 完了済みイシューの特定とクローズ提案を含む。 トリガー:「イシューを整理して」「issue を棚卸し」「GitHub issue をトリアージ」 「stale issue をクローズ」「issue の優先度付け」 といった GitHub Issue 整理関連リクエストで起動。.

j5ik2o/event-store-adapter-js · 171 tokens

law-of-demeter

デメテルの法則(最小知識の原則)に基づくコードレビューと設計支援。オブジェクトの連鎖呼び出し (Train Wreck)を検出し、直接の友人とのみ会話する設計へ変換する。結合度の低減と 変更容易性の向上を促進する。コードレビュー、新規実装、リファクタリング時に オブジェクト間の結合が深い場合に使用。 対象言語: Java, Kotlin, Scala, TypeScript, Python, Ruby, Go, Rust。 トリガー:「デメテルの法則」「連鎖呼び出しを減らしたい」「Train Wreckを直して」 「結合度を下げたい」「ドット連鎖が多い」「最小知識の原則」「Law of Demeter」…

j5ik2o/event-store-adapter-js · 223 tokens

intent-based-dedup

字面の同一性ではなく意図(目的)の同一性に基づいてコードの共通化を判断するスキル。 DRY原則の誤適用(字面が同じだが意図が異なるコードの共通化)を検出し、正しい共通化判定を 支援する。コードレビュー、リファクタリング、新規実装時に重複コードの扱いを判断する場合に使用。 対象言語: 言語非依存(Rust, Java, TypeScript, Go, Python, Kotlin, Scala等すべて)。 トリガー:「重複コードを共通化したい」「DRYに従いたい」「似たコードがある」 「この2つの関数をまとめたい」「コードの重複を減らしたい」「共通化すべきか」…

j5ik2o/event-store-adapter-js · 237 tokens

parse-dont-validate

「Parse, don't validate」原則に基づくコードレビューと設計支援。validateパターン(チェックして結果を捨てる) をparseパターン(チェック結果を型で保持)に変換し、型システムで不変式を強制する設計を促進する。 コードレビュー、新規実装、リファクタリング時にvalidation関数の改善が必要な場合に使用。 対象言語: Rust, Haskell, TypeScript, Scala, Java, Go, Python。 トリガー:「バリデーションを改善して」「型で保証したい」「shotgun parsingを直して」…

j5ik2o/event-store-adapter-js · 185 tokens

tell-dont-ask

「Tell, Don't Ask」原則に基づくコードレビューと設計支援。オブジェクトの状態を問い合わせて 外部で判断するパターンを、オブジェクトに直接命じるパターンに変換する。カプセル化を強化し、 責任をデータを持つオブジェクトに集約する設計を促進する。コードレビュー、新規実装、 リファクタリング時にgetterの乱用やFeature Envyの改善が必要な場合に使用。 対象言語: Java, Kotlin, Scala, TypeScript, Python, Ruby, Go, Rust。 トリガー:「getterを減らしたい」「カプセル化を改善して」「Feature Envyを直して」…

j5ik2o/event-store-adapter-js · 212 tokens