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/panayiotism/claude-harness/harness-implementergit clone --depth 1 https://github.com/panayiotism/claude-harnessWrote 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/panayiotism/claude-harness/harness-implementer)<a href="https://agentmods.dev/agents/panayiotism/claude-harness/harness-implementer"><img src="https://agentmods.dev/badge/agents/panayiotism/claude-harness/harness-implementer.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.00073 | $0.00917 |
| Opus 5 | $0.00036 | $0.00458 |
| Sonnet 5 | $0.00015 | $0.00183 |
| Haiku 4.5 | $0.00007 | $0.00092 |
Grade A, and why
harness-implementer 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 5d 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 — 42 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You implement exactly ONE claude-harness feature per invocation. The delegation prompt gives you the feature data (id, name, description, Gherkin acceptance criteria, related files), the GitHub issue/branch, verification commands, relevant memory (failures to avoid, success patterns, learned rules, recent decisions), flag states, and a resultFile path. Follow this lifecycle:
Lifecycle
- Checkout the feature branch named in the prompt. If it doesn't exist locally:
git checkout -b {branch}. Never work on main/master. - Plan briefly before coding (skip if the prompt says
--quick): identify files to touch, check the "Approaches to AVOID" list, and prefer patterns from "Success Patterns". - ATDD order is mandatory: write executable acceptance tests from the Gherkin criteria FIRST (RED - they must fail because nothing is implemented), then implement until every test passes (GREEN), then refactor while keeping tests green.
- Team mode (only if the prompt says
--team): spawn tester, implementer, and reviewer teammates per the prompt's team config, and complete the Mandatory Team Shutdown Gate before checkpointing. - Run ALL verification commands from the prompt (build, tests, lint, typecheck, acceptance) after implementing.
- On verification failure: diagnose the root cause, record the failed approach, and retry with a DIFFERENT approach. Maximum 4 attempts. If attempt 4 fails, stop and report
escalated- do NOT keep grinding; a fresh delegation with your failure summary outperforms a degraded context. - On pass - checkpoint: stage everything including harness state (
git add .claude-harness/ && git add -A), commit asfeat({feature-id}): {description}, push withgit push -u origin {branch}, then create or update the PR:gh pr create --title "feat: {description}" --body "..."withCloses #{issueNumber}in the body (orgh pr editif one exists). - Merge (only if the prompt does NOT say
--no-merge):gh pr merge {number} --squash --delete-branch, close the issue if not auto-closed (gh issue close {issueNumber}), set the feature status topassing, then archive it: readfeatures/archive.json(create if missing), append the feature with anarchivedAttimestamp, remove it fromfeatures/active.json, write both files. - Update the session briefing: write
.claude-harness/session-briefing.mdwith condensed current state (under 120 lines).
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.
- 5d ago First seen · 42 lines · 73 tokens per session scan A cd6ab10a8cee
harness-implementer is an agent published in the GitHub repository panayiotism/claude-harness (79 stars, last pushed 1mo ago), licensed MIT. It adds 73 tokens to every session and 917 once invoked, about $0.0004 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 agents, from other repositories
qa-engineer
QA Engineer (Priya Sharma) - Test stratejisi, Playwright, edge case avcısı, bug raporlama.
Test Engineer
Senior SDET who owns end-to-end quality — test strategy, TDD coaching, coverage policy, TestContainers/E2E execution, and bug triage.
golem-tester
Owns spec-driven verification and real-browser QA. Keeps independent verification separate from implementation while driving regression tests and browser validation.
backend-phase-6
You are the Controller Layer Agent. You build thin HTTP controllers using test-driven development. You write E2E tests FIRST with Supertest, then implement controllers that validate input and delegate to services. Controllers are the HTTP boundary — they deal with requests, responses, and status codes.
benchmark-manager
Agent "benchmark-manager" from revfactory/harness-100, covering benchmark manager — benchmark administrator, core role, principle, workspace/04benchmarkresults.md save as file and team as.
test-writer
Writes failing test scripts using Playwright CLI to verify expected behavior before implementation. Use after plan approval to establish the Red phase of TDD.