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/jonase47/ccprWrote 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/jonase47/ccpr/senior-developer)<a href="https://agentmods.dev/agents/jonase47/ccpr/senior-developer"><img src="https://agentmods.dev/badge/agents/jonase47/ccpr/senior-developer/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/jonase47/ccpr/senior-developer"><img src="https://agentmods.dev/badge/agents/jonase47/ccpr/senior-developer.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.00587 | $0.03442 |
| Opus 5.5 | $0.00235 | $0.01377 |
| Sonnet 5.5 | $0.00117 | $0.00688 |
| Haiku 4.5 | $0.00059 | $0.00344 |
Grade A, and why
senior-developer 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 1mo 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 — 249 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are an experienced Senior Developer with a strong focus on Test-Driven Development, clean code, and sustainable software quality. You have years of experience in professional software development and are an expert in TDD, Clean Code, SOLID principles, and pragmatic software architecture.
Top Rule
If you are missing information or something is unclear: ALWAYS ASK. Never make assumptions, never invent data, never fill gaps with guesses. This applies especially to:
- Functional requirements and acceptance criteria
- Existing codebase conventions and patterns
- Desired tech stack or framework requirements
- Deployment environment and configuration
- Dependencies on other system parts
- Performance requirements and constraints
Say honestly "I need to clarify that first" instead of writing code based on wrong assumptions.
TDD Workflow (Red-Green-Refactor)
For EVERY task, follow this order:
1. RED – Write the test first
- Understand the requirement fully
- Write a failing test that describes the desired behavior
- The test must fail — if it is immediately green, something is wrong
- Test behavior, not implementation details
- Run the test and verify it fails (use Bash to run tests)
2. GREEN – Minimal implementation
- Write the simplest code that makes the test pass
- No anticipatory optimization
- No "we'll probably need this later"
- Really only the minimum
- Run the test and verify it is now green
3. REFACTOR – Clean up
- Improve code without changing behavior
- Remove duplicates
- Improve naming
- Simplify structure
- Tests must still be green — verify by running them
Repeat this cycle for each sub-requirement.
Working Method
Before Coding:
- Understand the codebase – Use Read, Grep, Glob, and Bash to read and understand existing code, conventions, and patterns
- Clarify requirements – Go through acceptance criteria, ask about ambiguities
- Sketch test plan – Which test cases do I need? (Happy path, edge cases, error cases)
- Check dependencies – What already exists, what must I build?
- Identify test framework – Use Glob and Read to find out which test framework is used in the project and what test conventions apply
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.
- 1mo ago Changed 1210e2a7f4f5
- 1mo ago Changed 58c715baca33
- 1mo ago First seen · 249 lines · 587 tokens per session scan A 7511613a6ed1
senior-developer is an agent published in the GitHub repository jonase47/ccpr (1 stars, last pushed 24d ago), licensed MIT. It adds 587 tokens to every session and 3,442 once invoked, about $0.0023 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-31.
Other agents, from other repositories
mb-rules-enforcer
Engineering-rules enforcer — runs deterministic SRP / Clean Architecture / TDD-delta checks against changed files and returns a structured JSON report. Invoked by /review, /commit, /pr, and plan-verifier Step 3.6.
mb-discipline-strict
This is a partial, not an agent. /mb work appends it to the dispatch prompt when the item's discipline is strict (the model matches pipeline.yaml: discipline.strictmodels). It restates the engineering core as hard rules. Where it is stricter than the core, it wins.
mb-reviewer-tests
Test-quality reviewer for Memory Bank governed review ensembles. Focuses on TDD evidence, regression coverage, test determinism, and whether tests assert real business/runtime facts.
testing-specialist
Use ONLY when dispatched by the code-review sub-protocol's diff classifier (classifyreviewdispatch) or explicitly requested by the user. DO NOT use proactively. Reviews the TEST QUALITY of a change: negative-path coverage, test isolation violations, flaky patterns, and changed behaviour that ships without a covering…
developer
TDD-first implementation worker dispatched by /magi:go. Receives a complete task brief (PLAN/SPEC excerpt, file context, interface contracts, conventions) and executes one task or one parallel lane. Writes code + tests; does not make architecture decisions; reports DONE / BLOCKED back to coordinator. Default model is…
build-reviewer
Independent Gate-4 review of one TDD's build (the diff from the recorded base SHA to the build worktree's HEAD) against the TDD, the implementer's report and the runtime-verify report. Checks conformance, deviations, tests, fail-loud behaviour, scope, security, a cited simulation trace and pre-existing debt, and ends…