Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Advanced architecture stress analysis methodology for designing systems that survive unknown stresses. Load when --residuality flag is used or when designing high-uncertainty, mission-critical systems.
.claude/skills/nwave-ai-nw-stress-analysis/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-02 | ✗→✓ | ▲ Improved | 18% | 0% |
| case-06 | ✗→✓ | ▲ Improved | 4% | 0% |
| case-07 | ✗→✓ | ▲ Improved | 21% | 0% |
| case-11 | ✗→✓ | ▲ Improved | 29% | 0% |
| case-14 | ✗→✓ | ▲ Improved | 63% | 0% |
Complexity science-based approach for architectures surviving unknown future stresses. Based on residuality theory by Barry M. O'Reilly (Former Microsoft Chief Architect, PhD Complexity Science).
Core paradigm: "Architectures should be trained, not designed."
Use for: high-uncertainty environments | mission-critical systems | complex socio-technical systems | innovative products | rapidly evolving markets
Skip for: well-understood stable domains | short-lived MVPs | simple few-component systems | resource-constrained environments
Unexpected events challenging operation. Categories: technical (failures, scaling, breaches) | business model (pricing shifts, competitive disruption) | economic (funding, market crashes) | organizational (restructuring, skill gaps) | regulatory (compliance changes) | environmental (infrastructure failures)
Brainstorm extreme and diverse. Goal = discovery, not risk assessment.
Design elements surviving after breakdown. Ask: "What's left when stressor] hits?"
Example -- e-commerce under payment outage: residue = browsing, cart, wishlist. Lost: checkout, payment. Stress-informed: allow "reserve order, pay later."
States systems naturally tend toward under stress. Differ from designed intent. Discovered through testing, not predicted.
Example -- social media under growth: designed = proportional scaling, actual attractor = read-heavy CDN mode (reads survive, writes queue/fail). Design for this.
Straightforward solution for functional requirements. No speculative resilience. Document as baseline.
Brainstorm 20-50 across all categories. Include extremes. Engage domain experts. Prioritize by impact (not probability).
Walk each stressor with experts. Ask "What actually happens?" Identify emergent behaviors. Recognize cross-stressor patterns.
Per attractor: which components remain? Critical vs non-critical? Stress-only dependencies?
Reduce coupling, add degradation modes, introduce redundancy, apply resilience patterns (circuit breakers, queues, caching). Target coupling ratio < 2.0.
Generate second (different) stressor set. Apply to both naive and modified. Modified must survive more unforeseen stressors. Prevents overfitting.
Rows: stressors. Columns: components. Mark affected cells. Reveals: vulnerable components (high column count) | high-impact stressors (high row count) | coupling indicators.
Rows/columns: components. Mark direct connections. Coupling ratio = K/N. Target: <1.5 (loose) | 1.5-3.0 (moderate) | >3.0 (tight, cascade risk).
Model as directed graph. Simulate failure. Trace cascade. Identify SPOFs. Add circuit breakers, timeouts, fallbacks.
Select stressor, walk behavior step-by-step with team, identify attractors/residues, propose modification, re-walk to validate, repeat.
Traditional: predict and prevent specific failures. This: design for survival against any stress. Question shifts from "What risks to prepare for?" to "What happens when ANY stress hits?"
Other measured skills in the registry, with their headline benchmark lift.