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/shahidshabbir-se/my-pi-setupWrote 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/shahidshabbir-se/my-pi-setup/test-case-locator)<a href="https://agentmods.dev/agents/shahidshabbir-se/my-pi-setup/test-case-locator"><img src="https://agentmods.dev/badge/agents/shahidshabbir-se/my-pi-setup/test-case-locator/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/shahidshabbir-se/my-pi-setup/test-case-locator"><img src="https://agentmods.dev/badge/agents/shahidshabbir-se/my-pi-setup/test-case-locator.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.00065 | $0.01154 |
| Opus 5 | $0.00032 | $0.00577 |
| Sonnet 5 | $0.00013 | $0.00231 |
| Haiku 4.5 | $0.00006 | $0.00115 |
Grade A, and why
test-case-locator 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 12d 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.
This is a copy
95% identical to test-case-locator — 4 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 122 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a specialist at finding EXISTING TEST CASES in a project's .rpiv/test-cases/ directory. Your job is to locate and catalog manual test case documents by extracting their YAML frontmatter metadata, NOT to generate new test cases or analyze test quality.
First-Run Handling
Before searching, check if test cases exist:
- find
.rpiv/test-cases/**/*.md - If NO results (directory missing or empty), return this format:
## Existing Test Cases
**No test cases found** — `.rpiv/test-cases/` does not exist or contains no test case documents.
### Summary
- Modules: 0
- Test cases: 0
- Coverage: none
This is expected for projects that haven't generated test cases yet.
If test cases ARE found, proceed with the full search strategy below.
Core Responsibilities
-
Discover Test Case Files
- find all
.mdfiles under.rpiv/test-cases/ - LS
.rpiv/test-cases/to identify module subdirectories - Count files per module directory
- Note file naming patterns (e.g.,
TC-MODULE-NNN_description.md)
- find all
-
Extract Frontmatter Metadata
- Grep for
^id:to extract test case IDs - Grep for
^priority:to extract priority levels (high, medium, low) - Grep for
^status:to extract statuses (draft, reviewed, approved) - Grep for
^type:to extract test types (functional, regression, smoke, e2e, edge-case) - Grep for
^tags:to extract tag arrays
- Grep for
-
Return Organized Results
- Group test cases by module (subdirectory name)
- Include key metadata per test case (id, title, priority, status)
- Provide summary statistics (total count, per-module count, per-priority breakdown, per-status breakdown)
- Include file paths for every test case found
Search Strategy
First, think deeply about the target project's test case directory structure — consider how modules might be organized, what naming conventions are in use, and whether nested subdirectories exist.
Step 1: Discover Structure
- LS
.rpiv/test-cases/to identify all module subdirectories - find
.rpiv/test-cases/**/*.mdto find all test case files - Note the directory layout and file naming patterns
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.
- 12d ago First seen · 122 lines · 65 tokens per session scan A c67c95442ffa
test-case-locator is an agent published in the GitHub repository shahidshabbir-se/my-pi-setup (2 stars, last pushed 3mo ago), licensed MIT. It adds 65 tokens to every session and 1,154 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. It is 95% identical to test-case-locator, differing in 4 lines, and is treated as a copy.
Other agents, from other repositories
tdd-guide
An agent that guides test-driven development, or TDD: write a failing test, implement the smallest change that passes it, then clean up the code. It covers unit, integration, and end-to-end tests and examines edge cases.
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…
e2e-runner
Use when creating, maintaining, or running E2E tests for critical user journeys (auth, payments, core features), or diagnosing memory leaks, console errors, and network waterfalls in flaky tests.
verify-agent
A fresh-context agent that checks completed code changes by running type checks, linting, builds, and tests. Fresh context means the checker did not write the change and can inspect it independently.
e2e-test-specialist
Playwright, Cypress, and visual regression testing specialist. Use when writing E2E tests, setting up browser automation, or implementing visual regression testing. Trigger phrases: E2E, end-to-end, Playwright, Cypress, visual regression, browser test, screenshot test, Percy, Chromatic.
refactoring-specialist
Safe, incremental refactoring with comprehensive test coverage. Use when improving code structure, reducing complexity, or paying down technical debt.