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 skills add makifbaysal/tasktrooper --skill test-scenario-designgit clone --depth 1 https://github.com/makifbaysal/tasktrooperWrote 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/makifbaysal/tasktrooper/test-scenario-design)<a href="https://agentmods.dev/skills/makifbaysal/tasktrooper/test-scenario-design"><img src="https://agentmods.dev/badge/skills/makifbaysal/tasktrooper/test-scenario-design/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/skills/makifbaysal/tasktrooper/test-scenario-design"><img src="https://agentmods.dev/badge/skills/makifbaysal/tasktrooper/test-scenario-design.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.00039 | $0.00995 |
| Opus 5.5 | $0.00016 | $0.00398 |
| Sonnet 5.5 | $0.00008 | $0.00199 |
| Haiku 4.5 | $0.00004 | $0.00100 |
Grade A, and why
test-scenario-design 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 — 49 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Test Case Design
Write each case as Given (preconditions), When (action via the real endpoint or UI), Then (the observable result). The Then is the expected field: state it before you run anything, or you will be judging the output against whatever it turns out to be.
Two sources, in this order
- What was asked for. At least one case per acceptance criterion, linked with
criterion_id. - What it implies. The behaviour a reasonable person expects from the request even though nobody wrote it down. These are the cases with no
criterion_id, and they are where defects actually live.
Techniques for finding the implied cases
- Equivalence partitioning: group inputs into classes that should behave alike (valid email / invalid-format email / empty), then test one representative per class instead of guessing randomly.
- Boundary value analysis, 3-value: for every limit, test min−1, min, min+1, max−1, max, max+1 — off-by-one errors live exactly at these six points.
- Decision table: when a result depends on several conditions combined (role × state × flag), write the table and test the combinations that differ in outcome, not just each condition alone.
- State transition: model the valid states and the moves between them, then test the invalid moves too — cancel a completed item, edit after archive, submit twice.
- Zero-One-Many / Some-None-All: for anything list-shaped, test zero items, one item, many items; for anything that can apply to a set, test it applying to none, some, all.
- Interrupt and repeat: double-click a submit button, use the back button mid-flow, open the same record in two tabs, refresh mid-flow.
- "Is this actually a bug?" oracles: compare the observed behaviour against the product's own history (did it used to work differently), its own other screens (image), comparable products, the explicit claims in the task/docs, what a reasonable user would expect, the stated purpose of the feature, and plain consistency with itself — an oddity that fails none of these is a style choice, not a defect.
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 · 49 lines · 39 tokens per session scan A 1e49d3e3b4ad
test-scenario-design is a skill published in the GitHub repository makifbaysal/tasktrooper (113 stars, last pushed yesterday), licensed Apache-2.0. It adds 39 tokens to every session and 995 once invoked, about $0.0002 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-10-05.
Other skills, from other repositories
qa-acceptance
Produce QA acceptance criteria and a manual validation plan for a feature change — golden path, edge cases, error states, performance limits, and explicit pass/fail evidence.
rudder
Use locally captured coding-session intent to resolve a device-local behavioral spec, generate focused tests from that spec, implement the smallest production changes through red-green TDD, and verify coverage with the repository's native tooling. Use when the user asks to run Rudder, create or regenerate tests for…
C31-coding-discipline
A disciplined workflow for coding tasks that requires a failing test before production code, a plan, isolated work for larger changes, review, and final verification. TDD, or test-driven development, means writing the failing test first, then making it pass.
tdd
Use this skill to practice test-driven development — writing tests before implementation, using tests to drive design, and validating implementation against pre-written tests. Activates when implementing new functionality, refactoring code, or fixing bugs where regression coverage is needed.
tdd
Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development.
build-test
Run the project's build / typecheck / lint / test commands and emit the build.passing + tests.passing signals devloop convergence reads.