stress-test

Extract decisions, assumptions, dependencies, and interfaces from technical plans for adversarial review.

157|12|Updated Feb 2, 2026
One-click install
npx skills add https://github.com/dcosson/h2 --skill stress-test-dcosson
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: stress-test
Source: https://github.com/dcosson/h2/tree/main/internal/config/templates/styles/opinionated/skills/stress-test
Command: npx skills add https://github.com/dcosson/h2 --skill stress-test-dcosson

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill provides a structured, adversarial review workflow that deliberately stresses a technical plan to reveal gaps, assumptions, and potential failure modes.

Core Features & Use Cases

  • Structured Phase-based review to expose decisions, assumptions, dependencies, interfaces, and ordering.
  • Automated verification via parallel sub-agent checks and a minimal POC workspace under .poc-stress-test.
  • Evidence-backed risk reporting with actionable recommendations.

Quick Start

Run an adversarial review workflow against the current plan by creating the .poc-stress-test directory, generating minimal POC tests, and reporting findings.

Frequently Asked Questions about stress-test

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I adversarially review a technical plan to expose hidden gaps and assumptions?

Adversarial plan review extracts decisions, assumptions, dependencies, interfaces, and ordering from your technical plan, then verifies them via parallel sub-agent checks to expose gaps and report evidence-backed findings.

What is stress testing a technical plan and when do I need it?

Stress testing a technical plan is a structured, adversarial review workflow that deliberately stresses your architecture to reveal failure modes and hidden assumptions, needed before committing to complex implementations.

How do I verify technical plan dependencies and interfaces automatically?

Automated plan verification runs parallel sub-agent checks against extracted dependencies and interfaces, generating minimal POC tests in a .poc-stress-test workspace to validate assumptions with evidence.

Can I use automated risk analysis for proof of concept testing without external dependencies?

Automated risk analysis for POC testing requires no external dependencies, operating within a controlled .poc-stress-test directory to generate minimal tests and document structured findings.

What's the best way to document risk findings from a plan verification workflow?

Plan verification documentation captures evidence-backed risk findings with actionable recommendations, structuring results from parallel sub-agent checks across domains into comprehensive reports.

What are the limitations of automated adversarial review for complex technical plans?

Adversarial review limitations include reliance on the completeness of extracted decisions and assumptions from source plans, with POC testing confined to the .poc-stress-test workspace scope.