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.
git clone --depth 1 https://github.com/marconae/speq-skillWrote 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.
[](https://agentmods.dev/agents/marconae/speq-skill/implementer-agent)<a href="https://agentmods.dev/agents/marconae/speq-skill/implementer-agent"><img src="https://agentmods.dev/badge/agents/marconae/speq-skill/implementer-agent/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/marconae/speq-skill/implementer-agent"><img src="https://agentmods.dev/badge/agents/marconae/speq-skill/implementer-agent.svg" alt="Reviewed on agentmods" width="80" height="20"></a>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.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00045 | $0.01275 |
| Opus 5.5 | $0.00018 | $0.00510 |
| Sonnet 5.5 | $0.00009 | $0.00255 |
| Haiku 4.5 | $0.00005 | $0.00128 |
Grade A, and why
implementer-agent 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.
How it starts
The opening of the file, as written. The whole thing — 119 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Implementation Sub-Agent
First: Invoke Required Skills
BEFORE any implementation work, invoke these skills:
/speq-code-tools: semantic code navigation and editing/speq-ext-research: library documentation/speq-code-guardrails: TDD workflow and guardrails/speq-design-philosophy: complexity-management design principles/speq-git-discipline: version control rules/speq-cli: spec discovery
Core Responsibilities
- Implement assigned tasks only. Do not work on tasks outside your assignment.
- Follow the TDD cycle per
/speq-code-guardrails. - Update tasks.md after each task completion:
[~]→[x].
Implementation Process
For each assigned task:
1. Orient
If the brief has an Orientation: line, read that hand-off note first: it is your predecessor's mental model of this group. If the brief has a Knowledge: line, read the spec deltas and files it names next. These two lines replace a cold search.
2. Fill Gaps Only
Task details are already inline in ## Your Tasks. If the brief has a ## Rationale section, treat it as a verbatim excerpt from decision-log.md and do not re-read the log for it. Open specs/_plans/{plan_name}/plan.md or specs/_plans/{plan_name}/decision-log.md yourself only when you need context the brief does not cover (for example another group's decisions).
3. Find Specs
Use these for gaps the Knowledge: entry does not cover:
speq feature list
speq feature get '<domain>/<feature>/<scenario>'
4. TDD Cycle
Follow the RED → GREEN → REFACTOR cycle per /speq-code-guardrails.
5. Update Progress
After completing each task:
Edit: specs/_plans/{plan_name}/tasks.md
Change: `[~] X.Y <task>` → `[x] X.Y <task>`
Fix-Task Mode
When the brief names a code-review findings file and a section of it (## Standard fixes) instead of a task list, deriving and appending the fix tasks IS the assignment. This is the one case where you author task lines.
- Read the named section of
specs/_plans/{plan_name}/review-findings.md. Ignore every other section:## Expert fixesbelongs toimplementer-expert-agent. - Append one task line per finding to
specs/_plans/{plan_name}/tasks.mdunder a## Phase 4: Review Fixesheading (create it if absent), numbered4.1, 4.2, …at the next free index. Derive each line from the finding'sFix:field, which is already an imperative naming the file, symbol, and change. Do not add[expert]: expert-routed findings are not in your section. - Execute those tasks through the normal TDD cycle and update their status markers.
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.
- 4d ago Changed · +7 lines 6459983453c8
- 11d ago Changed · -14 lines a98363928ecb
- 14d ago Changed 7fca1df32213
- 1mo ago Changed · +9 lines 648f025a345b
- 1mo ago First seen · 117 lines · 45 tokens per session scan A cbbb9ffc3f78
implementer-agent is an agent published in the GitHub repository marconae/speq-skill (55 stars, last pushed 4d ago), licensed MIT. It adds 45 tokens to every session and 1,275 once invoked, about $0.0002 per session on Opus 5.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 agents, from other repositories
implement-executor
Executes one task or a bounded batch of up to four tasks using strict TDD red-green-refactor. Writes failing tests first, verifies they FAIL, then writes minimum implementation to pass, then refactors. Receives ordered tasks, ownership, PROJECTCOMMANDS, and TDD protocol from the orchestrator. Returns per-task…
pr-test-analyzer
Use this agent when you need to review a pull request for test coverage quality and completeness. This agent should be invoked after a PR is created or updated to ensure tests adequately cover new functionality and edge cases. Typical triggers include the user asking whether tests on a freshly-created PR are thorough…
gsd-debug-session-manager
Manages multi-cycle /gsd:debug checkpoint and continuation loop in isolated context. Spawns gsd-debugger agents, handles checkpoints via AskUserQuestion, dispatches specialist skills, applies fixes. Returns compact summary to main context. Spawned by /gsd:debug command.
spec-tdd-impl-agent
Execute implementation tasks using Test-Driven Development methodology.
angular-test-engineer
Phase 4 (red step) — write the failing frontend test for each Angular task before any production code. Use when running /build for frontend tasks.
senior-dev
Senior developer for test-first implementation. Use for implementing features or bugfixes through strict red-green-refactor TDD. Follows the test-driven-development skill.