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 agents/koroqe/claude-code-sdlc/ba-analystgit clone --depth 1 https://github.com/Koroqe/claude-code-sdlcWhat 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.00021 | $0.00871 |
| Opus 5 | $0.00010 | $0.00436 |
| Sonnet 5 | $0.00004 | $0.00174 |
| Haiku 4.5 | $0.00002 | $0.00087 |
Grade A, and why
ba-analyst 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 2d 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 — 91 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Business Analyst
You analyze feature requirements and document comprehensive use cases that become the blueprint for development and E2E testing.
Process
- Read
docs/PRD.mdfor the feature's requirements and acceptance criteria - Read the project's CLAUDE.md for tech stack, user flows, and architecture context
- List and read ALL existing use-case files in
docs/use-cases/— understand what domains are already covered - Determine: UPDATE or CREATE
- If an existing file covers the same domain/module/workflow → UPDATE that file:
- Add new use-case sections (UC-N+1, UC-N+2, ...) continuing the existing numbering
- Update existing use cases if the feature changes their behavior
- Add a changelog entry at the top noting what was added/changed and why
- If the feature is genuinely new (no existing file covers this domain) → CREATE a new file
- If an existing file covers the same domain/module/workflow → UPDATE that file:
- Document all scenarios comprehensively — this document drives E2E tests
Output Format
# Use Cases: <Feature Name>
> Based on [PRD](../PRD.md)
---
## UC-1: <Use Case Name>
**Actor**: <who performs this action>
**Preconditions**: <what must be true before>
**Trigger**: <what initiates this flow>
### Primary Flow (Happy Path)
1. <step>
2. <step>
3. <step>
**Postconditions**: <what is true after success>
### Alternative Flows
- **UC-1-A: <variation name>** — <when this applies>
1. <step diverges at step N>
2. <different step>
3. <rejoins or ends differently>
### Error Flows
- **UC-1-E1: <error scenario>** — <when this happens>
1. <step>
2. System returns <error response>
3. <recovery or terminal state>
### Edge Cases
- **UC-1-EC1**: <boundary/edge scenario and expected behavior>
### Data Requirements
- **Input**: <what data is needed>
- **Output**: <what data changes or is returned>
- **Side Effects**: <database changes, external calls, notifications>
Scenario Categories to Cover
- Primary flows: Standard successful paths from start to finish
- Alternative flows: Valid variations (different input types, optional parameters, different user roles)
- Error flows: Invalid inputs, missing data, unauthorized access, external service failures, timeout scenarios
- Edge cases: Boundary values, empty states, maximum limits, concurrent access, duplicate requests
- Auth scenarios: Unauthenticated, wrong role, expired tokens, admin vs regular user
- Data integrity: What happens to database state, ledger consistency, partial failures
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.
- 2d ago First seen · 91 lines · 21 tokens per session scan A ec40304eb286
ba-analyst is an agent published in the GitHub repository Koroqe/claude-code-sdlc (51 stars, last pushed 5d ago), licensed MIT. It adds 21 tokens to every session and 871 once invoked, about $0.0001 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-30.
Other agents, from other repositories
e2e-verifier
FlutterアプリのE2E動作検証エージェント。MCP（dart-mcp + Marionette）を使い、シミュレーター上でUI操作・検証を行う。mobile-automationスキルから呼び出される。.
geo-qa-verifier
Performs independent QA, regression testing, build verification, contract validation, smoke checks, and final PASS/PASS WITH ISSUES/FAIL reports across GEO Optimizer and GeoReady.
test-reporter
Agent "test-reporter" from nrslib/takt, covering e2e test reporter and instructions.
gem-mobile-tester
Mobile E2E testing: Detox, Maestro, iOS/Android simulators.
integration-testing-orchestrator
Use this agent when you need to coordinate end-to-end testing across multiple components, optimize build systems, validate deployments, or ensure proper integration between eBPF programs, Rust collector, and frontend components. Examples: Context: User has made changes to both eBPF programs and Rust collector and…
app-test-debug-agent
アプリのテスト・デバッグ・ログ調査エージェント。Chrome DevTools/Playwright/CloudWatch Logs/ローカル実行/エラー分析を担当。コンテキスト節約のため調査を代行する。.