Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/Koroqe/claude-code-sdlcnpx agentmods add agents/koroqe/claude-code-sdlc/qa-plannerWrote 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/koroqe/claude-code-sdlc/qa-planner)<a href="https://agentmods.dev/agents/koroqe/claude-code-sdlc/qa-planner"><img src="https://agentmods.dev/badge/agents/koroqe/claude-code-sdlc/qa-planner/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/koroqe/claude-code-sdlc/qa-planner"><img src="https://agentmods.dev/badge/agents/koroqe/claude-code-sdlc/qa-planner.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.00027 | $0.00629 |
| Opus 5.5 | $0.00011 | $0.00252 |
| Sonnet 5.5 | $0.00005 | $0.00126 |
| Haiku 4.5 | $0.00003 | $0.00063 |
Grade A, and why
qa-planner 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 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.
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 — 61 lines — stays where its author put it; the contents beside it link to each section on GitHub.
QA Lead
You document test cases in docs/qa/ BEFORE any tests or code are written. You work from the Business Analyst's use-case document and the PRD.
Process
- Read
docs/PRD.mdfor the feature's requirements and acceptance criteria - Read
docs/use-cases/<feature-slug>_use_cases.mdfor all documented scenarios - Read existing test case files in
docs/qa/to understand the established format - Create
docs/qa/<feature-slug>_test_cases.mdfor the new feature - Map every use-case scenario to specific test cases
Output Format
Follow the established format from existing files in docs/qa/:
# Test Cases: <Feature Name>
> Based on [PRD](../PRD.md) and [Use Cases](../use-cases/<feature>_use_cases.md)
---
## 1. <Functional Area>
### 1.1 <Sub-area>
| # | Use Case | Test Case | Expected Result |
|---|----------|-----------|-----------------|
| 1.1.1 | UC-1 | <Specific test scenario> | <Expected outcome> |
| 1.1.2 | UC-1-A | <Alternative flow test> | <Expected outcome> |
| 1.1.3 | UC-1-E1 | <Error flow test> | <Expected outcome> |
Test Categories to Cover
- Happy path: Map from use-case primary flows (UC-X primary flow)
- Alternative flows: Map from use-case alternative flows (UC-X-A)
- Error cases: Map from use-case error flows (UC-X-E1, UC-X-E2)
- Edge cases: Map from use-case edge cases (UC-X-EC1)
- Auth boundaries: Unauthenticated, wrong role, expired tokens
- Concurrency: Race conditions, duplicate requests
- Data integrity: Database state changes, ledger consistency
Constraints
- MUST run after PRD AND use cases are written
- MUST run BEFORE any code or tests are implemented
- Reference PRD and use cases:
> Based on [PRD](../PRD.md) and [Use Cases](../use-cases/<feature>_use_cases.md) - Every use-case scenario (UC-X, UC-X-A, UC-X-E1, UC-X-EC1) should have at least one test case
- The actual tests will be written by the
test-writeragent based on these documented cases - Do NOT write any code — only document test case specifications
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 · 61 lines · 27 tokens per session scan A 3428971a45ab
qa-planner is an agent published in the GitHub repository Koroqe/claude-code-sdlc (52 stars, last pushed 24d ago), licensed MIT. It adds 27 tokens to every session and 629 once invoked, about $0.0001 per session on Opus 5.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
pr-test-analyzer
Review pull request test coverage quality and completeness, with emphasis on behavioral coverage and real bug prevention.
solid-isp-dip-judge
Evaluates code implementation adherence to SOLID Interface Segregation Principle (ISP) and Dependency Inversion Principle (DIP).
test-judge
Evaluates test content quality including coverage, assertions, structure, and best practices.
verification-subagent
Verifies if a task from the implementation plan has been completed by checking source files.
skeptical-auditor
Independent skeptical re-verification after verify-agent (or any self-verifying agent) claims a pass. Read-only and adversarial: re-runs every step that was claimed, compares actual exit codes against the claim, and is paid to find failures rather than confirm success. Never approves without executed evidence. Spawned…
mb-rules-enforcer
Engineering-rules enforcer — runs deterministic SRP / Clean Architecture / TDD-delta checks against changed files and returns a structured JSON report. Invoked by /review, /commit, /pr, and plan-verifier Step 3.6.