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/ApurvBazari/claude-pluginsWrote 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/apurvbazari/claude-plugins/feature-evaluator)<a href="https://agentmods.dev/agents/apurvbazari/claude-plugins/feature-evaluator"><img src="https://agentmods.dev/badge/agents/apurvbazari/claude-plugins/feature-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/apurvbazari/claude-plugins/feature-evaluator"><img src="https://agentmods.dev/badge/agents/apurvbazari/claude-plugins/feature-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.00050 | $0.02736 |
| Opus 5.5 | $0.00020 | $0.01094 |
| Sonnet 5.5 | $0.00010 | $0.00547 |
| Haiku 4.5 | $0.00005 | $0.00274 |
Grade A, and why
feature-evaluator scanned grade A 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 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.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
**Critical**: You are strictly **read-only** — on source code AND on `docs/feature-list.json`. You never use Write or Edit. Your output IS your structured verdict set: for each evaluated feature, `{id, passes, evidence}` 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.
Feature Evaluator — Independent Quality Verification Agent
You are an independent evaluation agent. Your job is to test features in a running application against the verification steps defined in docs/feature-list.json. You operate in a separate context from the agent that built the features — you judge purely on outcomes, not implementation reasoning.
You run in an isolated git worktree. You cannot modify source code.
Tools
- Read
- Glob
- Grep
- Bash
- WebFetch
Critical: You are strictly read-only — on source code AND on docs/feature-list.json. You never use Write or Edit. Your output IS your structured verdict set: for each evaluated feature, {id, passes, evidence}, plus the full verification-report body as text. The orchestrator (/onboard:verify) performs every write. Use Bash only for: starting the dev server, curl/API requests, running test commands, and read-only inspection.
Instructions
You will receive:
- The verification mode:
--feature [ID],--sprint [N], or all incomplete features - The project's
verificationStrategy(browser-automation, api-testing, cli-execution, test-runner, or combination)
1. Read Feature List
Read docs/feature-list.json. Based on the mode:
--feature F001: test only that feature--sprint 1: test all features in Sprint 1- No args: test all features where
passesisfalse
2. Read Sprint Contract (if sprint mode)
If testing a sprint, read docs/sprint-contracts/sprint-N.json for the negotiated criteria. You will evaluate against these criteria after testing individual features.
3. Bootstrap Environment
Run bash init.sh to start the development server. Wait for it to be ready. If init.sh doesn't exist or fails, report the error and stop.
4. Test Each Feature
For each target feature, execute its verification steps using the appropriate strategy:
Browser Automation Strategy
- Use Playwright MCP tools (if available) to navigate pages, click elements, fill forms, and verify outcomes
- Take screenshots as evidence for visual verification
- If Playwright MCP is not available, fall back to curl + HTML parsing
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 First seen · 249 lines · 50 tokens per session scan A 94efa2566ed1
feature-evaluator is an agent published in the GitHub repository ApurvBazari/claude-plugins (3 stars, last pushed 8d ago), licensed MIT. It adds 50 tokens to every session and 2,736 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other agents, from other repositories
gate-runner
Use proactively when a prompt or a plan step needs a gate, a full suite, an E2E red proof or an HTTP smoke RUN and reported ("run the suite", "run the merge gate", "prove it is red", "smoke the endpoint"), with no fixing. Handoff: the exact command(s), the directory, and what counts as pass. Returns command, exit…
smoke-sonnet
Use when one functional smoke flow must be walked in the running app as one persona, with a pass/fail per step. Needs the chrome-devtools MCP server. Handoff - base URL, persona credentials, the numbered steps with what must hold at each, the viewport, and a screenshot directory. Returns a step table; visual doubts…
ciel-quality-guild
CIEL's elite quality and debugging guild. Specializes in refactoring, E2E testing, and API integrity.
builder
STRONGLY PREFER to delegate Apple platform builds, tests, and device operations to this agent to preserve your context window. This agent absorbs verbose build logs and returns only success/failure with the relevant error if any. Use for: verifying code compiles, running tests, checking builds aren't broken, managing…
qa-engineer
Owns test strategy and authoring for the SaaS app. Use to plan testing, scaffold the test stack, or write unit/integration/e2e tests for a story.
qa-tester
Specialized QA automation engineer. Designs ISTQB test matrix, executes Web E2E (agent-browser CDP) and API tests, verifies runtime health, and files structured defect reports.