agentmods.dev

build

A command that implements one planned task using test-driven development, or TDD: write a failing test, make it pass, then improve the code.

In plain words
What is it for?
Use it to build backend or frontend tasks from the project's task list while updating the implementation log and TDD state.
Why use it?
It keeps implementation tied to the planned task and records progress through each coding phase.

Command for Claude Code

57 2mo ago A scan 17 tokens original MIT
View the source file loiane/specs-driven-development-spring-angular
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 commands/loiane/specs-driven-development-spring-angular/build
Clone the repo
git clone --depth 1 https://github.com/loiane/specs-driven-development-spring-angular

Made for: Claude Code.

Per session 17 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 1,095 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.00017 $0.01095
Opus 5 $0.00009 $0.00548
Sonnet 5 $0.00003 $0.00219
Haiku 4.5 $0.00002 $0.00110

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

Security

Grade A, and why

build 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 yesterday.

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/commands/build.md · 61 lines

How it starts

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

/build

Phase: 4 — build (TDD) Owning agent: .claude/agents/spring-implementer.md (collaborates with spring-test-engineer) Skills used: tdd-red-green-refactor, spring-boot-4-conventions, clarity-over-cleverness, junit5-testcontainers-patterns, spring-task-decomposition

Stack routing

Task type Red step agent Green/refactor/simplify agent
Backend (src/main/java/**, src/test/java/**) spring-test-engineer spring-implementer (this agent)
Frontend (src/**/*.ts, src/**/*.html, src/**/*.scss) angular-test-engineer angular-implementer

Determine the task type from its files_in_scope in 04-tasks.md. If all files are frontend paths, delegate to the Angular agents. If mixed, split into sub-steps: backend first (Spring agents), then frontend (Angular agents).

Purpose

Execute one task end-to-end through the four TDD phases (red → green → refactor → simplify), updating .tdd-state.json and appending a block to 05-implementation-log.md after each phase.

Inputs

  • <task-id> (e.g. T-001). Required.

Reads

  • .specs/<feature-id>/04-tasks.md
  • .specs/<feature-id>/03-design.md
  • .specs/<feature-id>/.tdd-state.json
  • .claude/skills/tdd-red-green-refactor/SKILL.md (authoritative)

Writes

  • src/test/** and src/main/** files listed in tasks[<task-id>].files_in_scope.
  • .specs/<feature-id>/.tdd-state.json (phase transitions).
  • .specs/<feature-id>/05-implementation-log.md (one ### <task-id> — <phase> block per phase).

Process

For the supplied <task-id>:

  1. Pre-flight commit check. Run git status. If there are uncommitted changes from any prior task, refuse to start. List the changed files and remind: git commit → /build <task-id>.
  2. Activate. Set .tdd-state.json active_task = <task-id>. Refuse if any other task is phase: red|green|refactor|simplify (one task in flight at a time).
  3. Red. Write the smallest test that captures the next AC slice. Run it. Capture the failure message into tasks[<task-id>].red_failure_excerpt. Set phase: "red". Append log block.
  4. Green. Write the minimum production code under files_in_scope to pass the test. Run only the new test, then run all tests. Set phase: "green". Append log block.
  5. Refactor. Improve structure without changing behavior. Re-run all tests. Set phase: "refactor". Append log block.
  6. Simplify. Apply clarity-over-cleverness (untangle ternaries, inline once-used helpers, kill dead options, name domain concepts, extract repeated literals). Re-run all tests. Set phase: "simplify". Append log block.
  7. Done. Set phase: "done", clear active_task. If more ACs in this task remain uncovered, immediately re-run from step 2 with the next slice (do not declare done early).
  8. STOP — commit reminder. Surface: files changed (git status), tests passing, suggested commit message. Recommend: git status → git commit → /build <next-task-id>. Do not auto-start the next task unless the user explicitly requests chaining.

Read the full file on GitHub · 61 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. yesterday First seen · 61 lines · 17 tokens per session scan A b1ad88041ee3

Subscribe to this mod's changes

build is a command published in the GitHub repository loiane/specs-driven-development-spring-angular (57 stars, last pushed 2mo ago), licensed MIT. It adds 17 tokens to every session and 1,095 once invoked, about $0.0001 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.

Backend and APIsFrontendTestingangulargithub-copilotjavaspec-driven-developmentspring-boottdd
Related

Other commands, from other repositories

devkit.refactor

Provides guided code refactoring capability with deep codebase understanding, compatibility options, and comprehensive verification. Use when restructuring or improving existing code.

giuseppe-trisciuoglio/developer-kit · 27 tokens

spec-kitty.analyze

Spec-Driven Development for serious software developers. Spec Coding with with Claude, Cursor, Gemini, Codex. Kanban dashboard, git worktrees, auto-merge and more.

Priivacy-ai/spec-kitty · 0 tokens

devkit.verify-skill

Validates a skill against DevKit standards (requirements, template, dependencies). Use when you need to verify a skill before publishing or after modifications.

giuseppe-trisciuoglio/developer-kit · 29 tokens

devkit.prompt-optimize

Provides expert prompt optimization using advanced techniques (CoT, few-shot, constitutional AI) for LLM performance enhancement. Use when you need to improve prompt quality or optimize LLM interactions.

giuseppe-trisciuoglio/developer-kit · 37 tokens

sdd-plan

Turn a spec into a persisted baby-step plan file — research, resume, impact analysis.

GregorBiswanger/featherspec · 18 tokens

sdd-architecture-update

Detect architecture drift and sync the snapshot + Memory Bank (with confirmation).

GregorBiswanger/featherspec · 14 tokens