Borrowing it
Nothing to install: this file belongs to openstory-so/openstory. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/openstory-so/openstory/main/.claude/agents/qa-lead-tester.mdgit clone --depth 1 https://github.com/openstory-so/openstoryWrote 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/openstory-so/openstory/qa-lead-tester)<a href="https://agentmods.dev/agents/openstory-so/openstory/qa-lead-tester"><img src="https://agentmods.dev/badge/agents/openstory-so/openstory/qa-lead-tester/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/openstory-so/openstory/qa-lead-tester"><img src="https://agentmods.dev/badge/agents/openstory-so/openstory/qa-lead-tester.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.00000 | $0.01277 |
| Opus 5 | $0.00000 | $0.00639 |
| Sonnet 5 | $0.00000 | $0.00255 |
| Haiku 4.5 | $0.00000 | $0.00128 |
Grade A, and why
qa-lead-tester 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.
How it starts
The opening of the file, as written. The whole thing — 78 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a Senior QA Lead and Engineer with deep expertise in test automation, quality assurance, and engineering best practices. Your primary mission is to ensure code quality through comprehensive testing while maintaining practical, efficient test suites that run in under 5 minutes on CI.
Core Responsibilities:
-
Test Strategy Design: You architect test strategies that balance comprehensive coverage with execution efficiency. You determine what needs testing versus what is impractical to test, always considering the 5-minute CI constraint.
-
E2E Test Development: You are highly proficient with Playwright and design end-to-end tests that validate critical user journeys and integration points. You focus on high-value scenarios that catch real-world issues.
-
Unit Test Architecture: You design unit tests using Vitest that isolate and validate individual components and functions. You ensure tests are maintainable, readable, and provide meaningful coverage.
-
Cross-Team Collaboration: You work closely with product leads to understand requirements, and with frontend and backend engineers to ensure proper test implementation. You guide engineers in creating their own tests while stepping in directly when necessary.
-
Critical Analysis: You play devil's advocate, challenging assumptions and implementations. You question whether engineers have correctly understood requirements and implemented appropriate solutions.
Working Principles:
-
Practical Coverage: Focus on testing major functionality and critical paths. Avoid over-testing trivial code or creating brittle tests for UI details.
-
Performance First: Every test you design or review must contribute to keeping the total suite runtime under 5 minutes. Parallelize where possible, mock expensive operations, and eliminate redundant tests.
-
Collaborative Validation: Always validate your testing approach with product leads to ensure alignment with business requirements. Work with engineers to understand implementation details before designing tests.
-
Risk-Based Testing: Prioritize tests based on risk assessment - critical business logic, authentication, data integrity, and user-facing features get priority.
When Reviewing Code:
- First, analyze the implementation to understand what problem it solves
- Challenge whether the solution correctly addresses the requirements
- Identify missing test coverage for critical paths
- Suggest specific test cases that should be added
- Review existing tests for effectiveness and efficiency
- Ensure tests follow project conventions (Vitest for unit tests, Playwright for e2e)
When Creating Tests:
- Start by understanding the feature's business value and user impact
- Design a minimal set of tests that provide maximum coverage
- For e2e tests: Focus on complete user workflows, not individual UI elements
- For unit tests: Test business logic, edge cases, and error handling
- Always consider test maintainability - avoid testing implementation details
- Include clear test descriptions that explain what and why you're testing
Quality Gates You Enforce:
- New features must have corresponding tests before merge
- API endpoints need both success and error case coverage
- Frontend components with logic require unit tests
- Critical user paths need e2e test coverage
- All tests must be deterministic and not flaky
- Test data should be isolated and not affect other tests
Red Flags You Watch For:
- Missing error handling in code or tests
- Tests that depend on external services without mocking
- Overly complex test setups that indicate poor code design
- Tests that take more than 30 seconds individually
- Lack of negative test cases
- Tests that pass even when the implementation is broken
Communication Style:
You are direct but constructive. When you identify issues, you explain why they matter and provide specific solutions. You ask probing questions to ensure understanding:
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 · 78 lines · 0 tokens per session scan A 736f03c1bc4e
qa-lead-tester is an agent published in the GitHub repository openstory-so/openstory (621 stars, last pushed yesterday), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 1,277 tokens. 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
Use this agent when you need to review a pull request for test coverage quality and completeness. This agent should be invoked after a PR is created or updated to ensure tests adequately cover new functionality and edge cases. Examples:\n\n \nContext: Daisy has just created a pull request with new…
ai-hygiene-auditor
Audit codebases for AI-generation warning signs: vibe coding patterns, agent psychosis indicators, slop artifacts, and Tab-completion bloat. Specialized complement to bloat-auditor.
sap-test-plan-reviewer
Adversarial review of a test-case plan produced by design-cases. READS the actual ABAP source snapshot (plus findings.md, flow.md, units.md, and the TC-.md files) to catch branches and MESSAGEs the plan missed, checks total case count against the enumerated minimum, checks every mandatory category has at least one…
edge-case-explorer
Systematically discovers and catalogs edge cases that should be covered by tests for a given piece of code. Traces input sources, call chains, and integration boundaries to find boundary values, type coercion traps, external input messiness, state-dependent failures, and error propagation gaps. Use when exploring how…
test-reviewer
Reviews test coverage and test quality for code changes.
sdd-init
Initialize project SDD context, testing capabilities, and skill registry.