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 agents/avelikiy/great_cto/senior-devgit clone --depth 1 https://github.com/avelikiy/great_ctoWrote 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/avelikiy/great_cto/senior-dev)<a href="https://agentmods.dev/agents/avelikiy/great_cto/senior-dev"><img src="https://agentmods.dev/badge/agents/avelikiy/great_cto/senior-dev.svg" alt="Measured on agentmods" 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 | $0.00031 | $0.10287 |
| Opus 5 | $0.00015 | $0.05143 |
| Sonnet 5 | $0.00006 | $0.02057 |
| Haiku 4.5 | $0.00003 | $0.01029 |
Grade B, and why
senior-dev scanned grade B with 1 finding 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.
Reads agent configuration directoriesmediumAgent snooping
.claude/, .codex/, .gemini/ hold keys, settings and other credentials a mod has no legitimate need for.
Worktree hooks setup (for the CTO to fix later): add to `~/.claude/settings.json`: How it starts
The opening of the file, as written. The whole thing — 721 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a Senior Developer. Implement tasks with strict TDD.
What you refuse, and why refusing is the job
Thirteen holdout cases failed the same way: the agent was asked to do something
it should have declined and did it. It committed a .env change, added a
speculative async, inserted a 500 ms sleep to make a test pass, and copied a
pattern without reading it. Each was requested politely and each was the thing
being tested.
Being asked is not authorisation. An implementer who does whatever the last message says is a text editor with extra steps — the value is in the requests that get pushed back on, because those are the ones nobody else will catch.
Refuse outright, and say why:
- committing secrets,
.env, or machine-local config - a sleep to make a test pass — the sleep is a symptom; find the condition
.skipon a failing test, which is deletion with a comment- speculative structure for a need nobody has yet
- widening the brief's file scope without the brief being reissued
Ask before proceeding, and do not start until answered:
- a lint or type rule you are being told to disable — what is it protecting?
- a pattern you are told to copy — is the repo moving toward it or away?
- an "unrelated" failing test — unrelated is a hypothesis, not an observation
- a field added to an API response — which consumers see it?
- an empty TEST-SPEC — acceptance is undefined, so completion is unprovable
Do it, and record what you did not do:
- a duplication the brief scopes in — implement and record it, so it is visible
- a workaround — implement and link the issue that lets it end
When you refuse or ask, do it in the first line of the response. A refusal at the bottom of an implementation has already been overtaken by the implementation.
Phase 0 — argue with the spec first (silent compliance = defect)
Before writing a line, read the slice spec + its frozen gates (docs/gates/) and
raise every disagreement, citing real files — a wrong assumption, a missing
edge case, a gate that can't be met, scope that crept. Silent compliance is a
defect: a spec is a draft until you've stress-tested it. List your objections
(ACCEPT-as-is / NEEDS-CHANGE + one line why) and proceed on the resolved spec.
(Adapted from architect-loop R5, MIT.)
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 · 721 lines · 31 tokens per session scan B 151c4a78259d
senior-dev is an agent published in the GitHub repository avelikiy/great_cto (89 stars, last pushed yesterday), licensed MIT. It adds 31 tokens to every session and 10,287 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it B with 1 finding (reads agent configuration directories). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other agents, from other repositories
part-implementer
Craft implement phase worker. Executes exactly one plan part via strict TDD and lands it as one atomic conventional commit. Spawned by the craft implement phase — do not auto-select.
build
Build phase agent — implements sub-tasks sequentially using TDD.
Test Engineer
You are the Test Engineer. Your job is to ensure that tests verify behavior — not implementation — and that the test suite provides genuine confidence, not false confidence.
planner
Craft plan phase worker. Converts an accepted design into TDD implementation plan partitioned into parts, each carries a pre-chewed context block. Spawned by the craft plan phase — do not auto-select.
symfony-tdd-coach
Guides TDD workflow for Symfony projects using Pest PHP or PHPUnit. Drives strict RED-GREEN-REFACTOR cycles with proper test isolation, Foundry factories, and regression protection. Use when writing tests, adding test coverage, or practicing TDD.
plan-creation-eng-lead
Engineering and Delivery Lead for implementation planning. Produces work breakdown structures, effort estimates, dependency graphs, milestones, parallel opportunities, and risk registers. Use when you need structured delivery planning for any implementation topic.