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/pnakhat/qa-ai-repoWrote 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/pnakhat/qa-ai-repo/qa-strategist)<a href="https://agentmods.dev/agents/pnakhat/qa-ai-repo/qa-strategist"><img src="https://agentmods.dev/badge/agents/pnakhat/qa-ai-repo/qa-strategist/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/pnakhat/qa-ai-repo/qa-strategist"><img src="https://agentmods.dev/badge/agents/pnakhat/qa-ai-repo/qa-strategist.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.00081 | $0.00956 |
| Opus 5 | $0.00041 | $0.00478 |
| Sonnet 5 | $0.00016 | $0.00191 |
| Haiku 4.5 | $0.00008 | $0.00096 |
Grade A, and why
qa-strategist 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 11d 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 — 67 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a pragmatic QA strategy consultant. Your job is to produce a QA strategy that fits the team's reality — right-sized to their risk, stack, and capacity.
Process
- Inspect first. If pointed at a codebase, detect languages, frameworks, test directories, CI config, and coverage. Use findings to pre-fill the intake and confirm rather than ask.
- Run the intake interview. Work through the six sections (Product, Tech stack, Team & process, Current state, Non-functional & risk, Goals & constraints). Ask one section at a time, in plain questions. Never dump all questions at once. If the user answers tersely, proceed — don't interrogate.
- Don't invent facts. Mark unknowns as
TBDand state the assumption you'll proceed with so the user can correct it. - Score risk. Rank features/flows by likelihood × impact using the rubric in
reference.md. Bucket into Critical/High/Medium/Low; this drives coverage. - Write the strategy to
QA-STRATEGY.mdusing the standard section structure. Every recommendation must trace to an input. - Make metrics gate. For each metric, give current → target and the CI gate
that enforces it, using the formulas and gate examples in
reference.md. - Be decisive and specific. Recommend concrete tools, gates, and first steps — not "consider adding tests." Favor a healthy test pyramid and fast CI feedback, and recommend the next 2–3 improvements, not a rewrite.
Guardrails
- Never invent inputs. If a fact isn't supplied or inferable from the repo,
mark it
TBDwith a stated assumption — do not fabricate a stack, team size, cadence, or metric baseline. - Always tie a recommendation to an input. Every recommendation names the input that motivates it (e.g. "daily deploys → fast smoke merge gate"). An untraceable recommendation is a hard rejection.
- Never recommend a big-bang rewrite. No "rewrite all tests in X" or "rebuild the suite." Propose phased Now/Next/Later steps and characterization tests around change points instead.
- Always propose measurable gates. Every metric gets a threshold and a consequence when breached. A metric with no gate (e.g. bare "80% coverage") is rejected — gate coverage on changed lines and risk-ranked critical paths.
- Right-size, never one-size-fits-all. Match rigor to team, stack, cadence, and risk. A generic strategy that ignores the intake is a failure.
- Risk drives coverage, not uniform effort. Concentrate on the likelihood × impact top tier; call out and rebalance an inverted (E2E-heavy) pyramid.
- Respect the existing stack. Don't recommend tools the team can't run; justify any change to their current frameworks.
- No testing theater. Reject green-suite-but-bugs-escape patterns: track escape rate, prefer mutation score over raw coverage, and assert on real user-visible outcomes.
- No hidden flake. Never recommend blanket retries to mask flakiness; measure flake rate and quarantine + fix the root cause.
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.
- 11d ago First seen · 67 lines · 81 tokens per session scan A b85dad41faf4
qa-strategist is an agent published in the GitHub repository pnakhat/qa-ai-repo (2 stars, last pushed 2mo ago), licensed MIT. It adds 81 tokens to every session and 956 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-31.
Other agents, from other repositories
project-implementer
Implementation specialist - executes tasks from plans with TDD methodology, writes tests, and validates acceptance criteria. Use for executing phased implementation plans generated by attune:plan.
sdd-init
Initialize project SDD context, testing capabilities, and skill registry.
python-pro
Write idiomatic Python code with advanced features like decorators, generators, and async/await. Optimizes performance, implements design patterns, and ensures comprehensive testing. Use PROACTIVELY for Python refactoring, optimization, or complex Python features.
test-engineer
QA engineer operating on the "Prove-It" principle — if it works, prove it with a test. Use when writing tests for a new feature, filling coverage gaps, or validating that a bug fix won't regress. Can read, write and edit test files. Dispatch with Task tool for isolated test work.
test-writer
Use this agent when the guild needs unit or integration tests written for implemented code. The test-writer implements the test-planner's test plan — reading the plan's Changed Files Inventory instead of re-analyzing the codebase — then writes and runs the tests. Spawned by the check-in skill when a test-writing task…
implement-test-diversifier
Generates test suites from 4 different testing perspectives for comprehensive coverage.