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.
npx agentmods add commands/azrtydxb/procoder/specgit clone --depth 1 https://github.com/azrtydxb/procoderWhat 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.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00031 | $0.00951 |
| Opus 5 | $0.00015 | $0.00476 |
| Sonnet 5 | $0.00006 | $0.00190 |
| Haiku 4.5 | $0.00003 | $0.00095 |
Grade A, and why
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 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.
What it actually says
The user invoked /procoder:spec with arguments:
The command below is the procoder binary on PATH.
Specs live under .procoder/specs/, one Markdown file per feature. The
point of spec-based coding is that the thinking happens BEFORE the code:
the spec is complete when a different engineer could build the feature
from it without asking you anything. procoder spec check is the
quality controller — it blocks while sections are missing or empty, while
any OPEN: question is unresolved, and while acceptance criteria are
untestable.
With a feature name in the arguments, start (or resume) that spec. With
check or list, run the matching subcommand. With no arguments, run
procoder spec list and report.
Classify the work FIRST — and say the classification out loud so the user can override it before the first question:
- Spike — a feasibility question ("can X talk to Y?"). Output is an answer, not kept code. State the question and the cheapest probe, get a nod, investigate, report. Anything built is labelled throwaway; keeping it is a new request that gets its own classification.
- Bounded — a well-scoped change to a flow that ALREADY EXISTS in this repo (bounded measures the repo, not your familiarity with the problem). No spec file: ask the questions that matter, put a short design in chat (approach, files touched, testing), STOP for an explicit yes, then implement.
- Architectural — new subsystems, new projects, interface changes: the full interview below.
In doubt between two paths, take the heavier one — and the ratchet is one-way: hidden complexity discovered mid-task upgrades the path (stop, say so, step up); nothing ever downgrades. The ceremony scales with the task; the approval gate never does — no implementation before the user's explicit yes, on any path.
The interview — this is the core of the skill:
procoder spec template <name>prints the spec shape; write it to the printed path.- Fill it by interviewing the user, one topic at a time — do NOT invent
answers to design questions the user has not decided. Ask the right
questions to close gaps:
- Problem: what hurts today, for whom, why now? If the user gives a solution, ask for the problem behind it.
- Users: who touches this and what does each need?
- In / out of scope: propose the boundary and have the user confirm it — out-of-scope is written down so nobody assumes it.
- Constraints: performance, compatibility, security, platform.
- Interfaces: commands, APIs, file formats, UI surfaces.
- Data: what is stored, where, in what shape.
- Edge cases: enumerate the inputs and states that break naive implementations; ask about the ones the user has not mentioned.
- Failure modes: for each dependency — what happens when it is missing, slow, or wrong?
- Acceptance criteria: one
- [ ]per observable behaviour a reviewer can verify. "Works well" is not a criterion; "renders with the network cable pulled" is.
- Every decision you cannot close in the interview goes in as an
- OPEN: <question>line under Open questions. Resolve each with the user, then move the decision into its proper section and delete the OPEN line. Do not silently decide for the user. - Run
procoder spec check <name>after each pass. It names the remaining gaps — keep interviewing until it says COMPLETE. Do not start implementing while the spec is blocked. - When it is COMPLETE: for architectural work, write the implementation
plan next (/procoder:plan — its own quality controller gates it);
for smaller work, seed the task list directly from the acceptance
criteria (
procoder todo add, one task per coherent group — see /procoder:todo). Then build against the spec. If reality contradicts the spec mid-build, update the spec first and re-check.
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.
- yesterday First seen · 77 lines · 31 tokens per session scan A f9872e987479
spec is a command published in the GitHub repository azrtydxb/procoder (196 stars, last pushed 2d ago), licensed Apache-2.0. It adds 31 tokens to every session and 951 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.
Other commands, from other repositories
setup
Initialize a new project with SDLC-compliant structure. Creates required files, configures build system, sets up CI/CD, and establishes quality tooling.
validate
Run SDLC compliance check against the current project. Validates build system, code quality, testing, CI/CD, security, documentation, VCS, and release configurations.
run-tests
Run automated functional tests using the hook-driven test framework. Execute the test suite to validate all project functionality.
test-report
Generate test execution report in markdown format.
add-test
Interactively add a new test definition to the test suite.
release-swarm
Orchestrate complex software releases using AI swarms that handle everything from changelog generation to multi-platform deployment.