stress-test-skill
An agent skill that stress-tests technical plans before you build them.
Models are lazy about verification. They'll write a plan that says "use SQLite for concurrent writes" or "Y.js supports persistence out of the box" and move on without checking. These unchecked assumptions become mid-build surprises that force architectural pivots, messy workarounds, and wasted context.
This skill forces the model to actually verify its claims — searching real docs, ranking evidence quality, running proof-of-concept code when search is not enough, and fixing the plan before implementation starts. Each verification runs in a fresh sub-agent context, so there's less confirmation bias from the planning conversation — fewer hidden assumptions, less mid-build churn, and a clearer line between what's confirmed and what's still risk.
In action
A plan claimed bash + sqlite3 would be fast enough for git hooks. The skill spun up parallel agents to research alternatives and run an actual latency POC:
The POC disproved the assumption — bash was 4-5x slower than estimated — and surfaced the real tradeoffs across runtimes:
Install
npx skills add gbasin/stress-test-skill --all -gWorks with Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, Windsurf, and other supported agents.
How it works
Six phases, each building on the last:
1. Decompose — Extracts decisions, assumptions, dependencies, interfaces, invariants, recovery paths, and observability gaps. Activates the relevant risk lenses for the plan. 2. Verify — Launches parallel sub-agents to search docs, repos, and the web for evidence, while ranking source quality and tracking contradictions instead of smoothing them over. 3. Triage — Separates what's resolved by evidence from what needs hands-on testing. Drafts minimal POC specs for unresolved items. 4. Approve — Presents proposed POCs and lets you choose which to run, skip, or modify. Any runtime validation requires approval first. 5. Test — Runs approved POCs in parallel in an isolated .poc-stress-test/ directory using the smallest representative setup in the most production-like environment available. 6. Update — Buckets results into Confirmed, Unresolved, and Accepted Risks; walks through plan-changing findings individually; applies approved updates inline; and cleans up after itself.
When to use it
- After writing a technical plan or architecture doc, before you start building
- When evaluating a new library, framework, or integration approach
- Before committing to decisions that are expensive to reverse
- Anytime a plan has claims you haven't personally verified
