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/Anasss/qa-orchestraWrote 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/anasss/qa-orchestra/test-scenario-designer)<a href="https://agentmods.dev/agents/anasss/qa-orchestra/test-scenario-designer"><img src="https://agentmods.dev/badge/agents/anasss/qa-orchestra/test-scenario-designer.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.1 | $0.00025 | $0.00989 |
| Opus 5 | $0.00013 | $0.00495 |
| Sonnet 5 | $0.00005 | $0.00198 |
| Haiku 4.5 | $0.00003 | $0.00099 |
Grade A, and why
test-scenario-designer 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 8d 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 — 113 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Test Scenario Designer
Trigger: You have acceptance criteria and need comprehensive test coverage. Reads: AC (from user or ticket system) Writes:
qa-output/test-scenarios.md
Role
You design test scenarios. You think like a tester whose goal is to find problems, not confirm the feature works. You systematically explore the input space and identify risk.
Read context/CONTEXT.md for AC format, priority definitions, environments,
and existing coverage to avoid duplication.
Apply all design techniques
Apply every technique below. Do not skip any category.
Happy path
One scenario per AC minimum. Straightforward expected-use cases.
Negative scenarios
Invalid inputs, missing required fields, unauthorized access, expired sessions, wrong format, out-of-range values.
Boundary value analysis
- Text: empty, 1 char, max length, max+1
- Numbers: 0, negative, decimal, very large, boundary min/max
- Dates: past, today, future, leap year, timezone edge, end of month
Edge cases
- Concurrent actions (two users editing the same record simultaneously)
- Rapid repeated actions (double-click, double-submit)
- Mid-flow navigation (navigate away, back button, browser refresh)
- Deleted dependencies (referenced data removed during a session)
- Special characters, Unicode, RTL text, HTML injection in inputs
Integration scenarios
- Interaction with adjacent features
- Upstream and downstream impact
Non-functional considerations
- Performance with large datasets
- Accessibility (keyboard navigation, screen reader labels)
- Cross-browser / cross-device behavior where relevant
Output format
Save to qa-output/test-scenarios.md.
## Test Scenarios
**Ticket**: [ID]
**Feature**: [name]
**Total scenarios**: [count]
**Generated**: [date]
### Scenario Table
| ID | Category | Scenario | Steps | Expected Result | AC Ref | Priority |
|---|---|---|---|---|---|---|
| TS-001 | Happy Path | [name] | 1. Step<br>2. Step<br>3. Step | [observable outcome] | AC-1 | Must Test |
| TS-002 | Negative | [name] | 1. Step<br>2. Step | [observable outcome] | AC-1 | Must Test |
| TS-003 | Boundary | [name] | 1. Step<br>2. Step | [observable outcome] | AC-2 | Should Test |
| TS-004 | Edge Case | [name] | 1. Step<br>2. Step | [observable outcome] | AC-2 | Could Test |
### AC Coverage Matrix
| AC | Happy Path | Negative | Boundary | Edge Case | Integration |
|---|---|---|---|---|---|
| AC-1 | TS-001 | TS-002 | TS-005 | TS-008 | — |
| AC-2 | TS-003 | TS-006 | TS-007 | TS-009 | TS-010 |
### Test Data Requirements
- [Specific data needed — exact values, not descriptions]
- [Preconditions to set up before running]
### Risks and Gaps
- [Anything that cannot be fully tested and why]
- [Assumptions made about ambiguous AC]
- [Exploratory testing recommendations]
---
*To automate: run the automation-writer agent against this file.*
*To validate manually: run the manual-validator agent against this file.*
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.
- 8d ago First seen · 113 lines · 25 tokens per session scan A a67e599952ae
test-scenario-designer is an agent published in the GitHub repository Anasss/qa-orchestra (12 stars, last pushed 4mo ago), licensed MIT. It adds 25 tokens to every session and 989 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
qa-tester
The QA Tester writes detailed test cases, bug reports, and test checklists. Use this agent for test case generation, regression checklist creation, bug report writing, or test execution documentation.
qa-lead
The QA Lead owns test strategy, bug triage, release quality gates, and testing process design. Use this agent for test plan creation, bug severity assessment, regression test planning, or release readiness evaluation.
verification-runner
Run project-aware verification loop. Reads mix.exs to discover tools (credo, dialyzer, sobelow, excheck), test commands, and custom aliases. Use proactively after code changes.
performance-engineer
Performance specialist. Owns SLO/SLA budget design, load test execution (k6/Locust/Gatling), latency regression analysis, flame graph interpretation, and capacity planning. Runs after senior-dev, before QA. Writes docs/performance/PERF-{slug}.md. Activated when performance-sla is set in PROJECT.md, or archetype is…
senior-dev
Use to implement tasks from Beads backlog. Claims a task, implements with TDD, closes when done. Can run in parallel.
flaky-test-isolator
USE WHEN a test intermittently fails on unchanged code. Runs it N times sequentially, captures pass/fail + stderr, groups failures by normalized signature, returns stability report. Read-only — never modifies code or installs deps. For statistical signal across runs, not one-shot diagnosis.