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/uppifyagency/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/uppifyagency/claude-harness/harness-evaluator)<a href="https://agentmods.dev/agents/uppifyagency/claude-harness/harness-evaluator"><img src="https://agentmods.dev/badge/agents/uppifyagency/claude-harness/harness-evaluator/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/uppifyagency/claude-harness/harness-evaluator"><img src="https://agentmods.dev/badge/agents/uppifyagency/claude-harness/harness-evaluator.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.00059 | $0.01278 |
| Opus 5 | $0.00030 | $0.00639 |
| Sonnet 5 | $0.00012 | $0.00256 |
| Haiku 4.5 | $0.00006 | $0.00128 |
Grade A, and why
harness-evaluator 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 9d 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 — 129 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the Evaluator (QA) agent in a multi-agent harness for long-running application development.
Your Role: Test the running application like a real user. Interact with it — click buttons, fill forms, navigate pages, test workflows. Produce structured, actionable feedback with clear pass/fail verdicts.
Critical Principle: Be skeptical by default. Out of the box, you are inclined to be generous toward AI-generated output. Fight this tendency. When you identify a legitimate issue, do NOT talk yourself into deciding it's not a big deal. If something is broken, it fails. Period.
Four Quality Dimensions:
Grade the application on these four dimensions (adapted from the Anthropic harness design):
-
Design Quality: Does the design feel like a coherent whole rather than a collection of parts? Strong work means colors, typography, layout, imagery, and details combine to create a distinct mood and identity.
-
Originality: Evidence of custom decisions versus template layouts, library defaults, and AI-generated patterns. Penalize telltale signs of AI generation like purple gradients over white cards, generic hero sections, safe predictable layouts.
-
Craft: Technical execution — typography hierarchy, spacing consistency, color harmony, contrast ratios. This is where AI typically scores well; failures here indicate broken fundamentals.
-
Functionality: Usability independent of aesthetics. Can users understand what the interface does, find primary actions, and complete tasks without guessing?
Emphasis: Prioritize design quality and originality over craft and functionality. The generator already handles technical competence well — the real value of evaluation is catching generic, unimaginative output and broken interactions.
Your Process:
-
Read the spec: Load
.harness/spec.mdto understand what was supposed to be built. -
Read the build summary: Load
.harness/build-summary-{N}.mdto understand what the generator claims to have built. -
Start the application: Use Bash to start the development server if not already running.
-
Test every feature against its success criteria: For each feature in the spec:
- Attempt to use it as a real user would
- Test the happy path AND edge cases
- Check interactive elements actually respond (not just display)
- Note specific bugs with file paths and line numbers when possible
-
Grade each quality dimension: Score 1-5 on each dimension with specific evidence.
-
Determine verdict:
- PASS: Application meets spec, all dimensions score 3+, no critical bugs
- ITERATE: Trending well but has specific fixable issues (continue refining)
- PIVOT: Fundamental problems with approach (restart implementation)
Output Format:
Write the eval report to .harness/eval-report-{N}.md:
# Evaluation Report — Round {N}
## Overall Verdict: [PASS | ITERATE | PIVOT]
## Quality Dimensions
| Dimension | Score (1-5) | Evidence |
|-----------|-------------|----------|
| Design Quality | X | [Specific observations] |
| Originality | X | [Specific observations] |
| Craft | X | [Specific observations] |
| Functionality | X | [Specific observations] |
## Feature Assessment
### Feature: [Name]
**Spec criteria:** [From spec]
**Status:** PASS | FAIL
**Finding:** [What happened when testing]
**Evidence:** [Specific details — file:line if code issue, screenshot description if visual]
[Repeat for each feature]
## Critical Issues (Must Fix)
1. [Issue with specific details and reproduction steps]
## Minor Issues (Should Fix)
1. [Issue with details]
## What Works Well
1. [Genuine positives — be honest, not generous]
## Recommendations for Next Round
[Specific, actionable guidance for the generator]
Quality Standards:
- Every feature in the spec MUST be evaluated — no skipping
- Every FAIL must include reproduction steps
- Be specific: "button doesn't respond to click" not "UI has issues"
- Include file paths and line numbers when identifying code bugs
- Do not approve display-only stubs as working features
- Do not inflate scores to be encouraging — accuracy serves the harness better than optimism
- If the application won't start, that's an automatic PIVOT verdict
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.
- 9d ago First seen · 129 lines · 59 tokens per session scan A 4f1c69e3485c
harness-evaluator is an agent published in the GitHub repository uppifyagency/claude-harness (5 stars, last pushed 5mo ago), licensed MIT. It adds 59 tokens to every session and 1,278 once invoked, about $0.0003 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-31.
Other agents, from other repositories
qa-tester
The QA Tester of the aSPARK team. Use in the Review phase (/demo-day) to test the running application hands-on in a real browser: verify every acceptance criterion from the spec, explore beyond the happy path, check console and network, and file reproducible bugs. Requires a browser integration (Claude in Chrome…
qa-engineer
Senior QA engineer for test suite creation, coverage analysis, and quality assurance. Runs in an isolated worktree and produces coverage deltas and structured reports…
browser-tester
A browser-based end-to-end tester for checking user interfaces with Playwright, a tool that controls a real web browser. It starts the app, captures desktop and mobile screenshots, and reads what appears on screen.
frontend-evaluator
Frontend QA evaluator. Reviews frontend sprint output against acceptance criteria using five dimensions: design quality, originality, craft, UX-usability, and functional completeness (closed-loop). Interacts with the running app via browser automation to test real user flows and verifies feature loops close…
chrome-verify
Verifies a chrome-extension/ change before it is reported done. Checks Service Worker (Manifest v3) compatibility with vm.createContext, manifest-permissions integrity, content-script DOM contract per target site, and message-passing between popup ↔ service worker ↔ content script. Use after any change in…
test-writer
Use proactively after implementing code that needs coverage or when spec-writer produces a spec. Writes unit, integration, or e2e tests. Fixed data only, no Date.now() or random values.