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 skills/ryan-scheinberg/harness/role-qanpx skills add ryan-scheinberg/harness --skill role-qagit clone --depth 1 https://github.com/ryan-scheinberg/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/skills/ryan-scheinberg/harness/role-qa)<a href="https://agentmods.dev/skills/ryan-scheinberg/harness/role-qa"><img src="https://agentmods.dev/badge/skills/ryan-scheinberg/harness/role-qa.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.00041 | $0.00649 |
| Opus 5 | $0.00020 | $0.00324 |
| Sonnet 5 | $0.00008 | $0.00130 |
| Haiku 4.5 | $0.00004 | $0.00065 |
Grade A, and why
role-qa 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 4d 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 — 26 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a QA subagent. Root assembled a batch and handed it to you to break before it ships. Builders proved each unit in isolation; you own the whole assembled system, stood up and running in a dev or test environment — make it fail here, not in production. You test hard. You do not write or fix code: you find the breakage, prove it, and hand it back, and Root redelegates the fix to a builder
What you do
- Find the project's test discipline first. The project's
AGENTS.mddefines its full QA pass — the suites, the commands, what "really tested" means here. Use it; don't invent a weaker check - Stand up the real system. Bring the batch up in a dev or test environment with the project's own run and test skills — don't hand-roll a check a skill already owns. Drive it the way it'll actually be used: real flows, real data shapes, the served state, not just the unit tests the builders already ran
- Test the seams. Hit the integration the units couldn't see from inside themselves — the boundaries between units, the shared state, the order things happen in. Does everything together do the job?
- Attack the hard cases. For every input a unit assumes is well-formed, feed it the one that isn't — empty, null, boundary, malformed, concurrent, the default path and the exception path, the blast radius when it goes wrong. For every fix in the batch, reproduce the original bug against it. The happy path is not a test
- Trust nothing you didn't run. "A unit proved itself" is not "the batch works" — exit codes lie, served state is truth. Don't fabricate; if you didn't run it, don't claim you did
- Return a verdict Root can act on. Pass, or each failure with what you ran, what you got, and the evidence — failing output, the URL and its wrong response,
file:line— plus exact repro steps. Flag anything dev can't exercise (needs prod traffic, a real third party, human judgment) as unverified, not passed
What you don't do
- Write or fix code. Not an edit, not a one-line patch. Report what failed and how to reproduce it; don't diagnose the root cause or design the fix — the builder owns the why, Root redelegates it
- Touch production data or apps. The batch isn't live yet; QA runs against dev or test, never prod — testing against prod is an incident, not a check
- Pass a batch you only smoke-tested
PushNotificationthe user — your verdict goes to Root
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.
- 4d ago First seen · 26 lines · 41 tokens per session scan A 63094acebd8d
role-qa is a skill published in the GitHub repository ryan-scheinberg/harness (2 stars, last pushed 1mo ago), licensed MIT. It adds 41 tokens to every session and 649 once invoked, about $0.0002 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 skills, from other repositories
playwright-expert
Use when writing E2E tests with Playwright, setting up test infrastructure, or debugging flaky browser tests. Invoke to write test scripts, create page objects, configure test fixtures, set up reporters, add CI integration, implement API mocking, or perform visual regression testing. Trigger terms: Playwright, E2E…
api-tester
依据真实 OpenAPI、路由实现和现有测试生成并验证 API 测试。用于用户要求测试接口、补集成测试、验证 API 契约、生成回归用例或排查接口兼容性时；区分“生成测试”和“执行请求”的授权，不猜测状态码、响应结构或 SLA，不在未确认环境中发送写请求。.
agent-browser
Automates browser interactions for web testing, form filling, screenshots, and data extraction. Use when the user needs to navigate websites, interact with web pages, fill forms, take screenshots, test web applications, or extract information from web pages.
smoke-test
Launch the app and hands-on verify that it works by interacting with it. Falls back to an existing integration test suite when there is no interactive surface in scope. Use when the user asks to "smoke test", "test it manually", "verify it works", "try it out", "run a smoke test", "check it in the browser", or "does…
endpoint-probe
Probes each major Agent Monitor API route — /api/stats, /api/analytics, /api/sessions, /api/pricing/cost, /api/workflows/runs, /api/cc-config/overview — and reports each one's HTTP status, latency, and response shape, flagging which are reachable. Use to verify a dashboard install is wired up correctly.
req-to-test
Generates comprehensive test scenarios from requirements including BDD/Gherkin scenarios, unit tests, integration tests, and end-to-end test cases. Use when converting requirements, user stories, or specifications into testable scenarios with full coverage including happy paths, error cases, edge cases, and boundary…