failure-mode-analysis

Enumerates eight failure-mode categories before writing tests in TDD workflows.

1|Updated Apr 3, 2026
One-click install
npx skills add https://github.com/TierOne-Studio/spa-velocity --skill failure-mode-analysis-tierone-studio
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: failure-mode-analysis
Source: https://github.com/TierOne-Studio/spa-velocity/tree/main/.ruler/skills/failure-mode-analysis
Command: npx skills add https://github.com/TierOne-Studio/spa-velocity --skill failure-mode-analysis-tierone-studio

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Tests written without upfront failure analysis miss realistic edge cases, letting silent corruption, race conditions, and swallowed errors reach production. This Skill forces a structured 60-second enumeration of failure modes before the first failing test is written. ## Core Features & Use Cases - Eight-Category Checklist: Walks null/missing, empty/zero, boundary, very large, malformed, concurrent/partial, external failure, and locale/time categories with one bullet each. - Test Selection Decision Rule: Decides which categories deserve tests based on realism, non-obvious failure risk, and trust boundaries, with mandatory reasons for N/A entries. - Workflow Integration: Runs inside tdd-workflow between requirements gathering and the failing test, reducing the gap list qa-validator finds later. - Use Case: Before implementing a paginated API endpoint, enumerate failure modes to discover you need tests for empty result sets, cursor-at-end boundaries, and concurrent writes. ## Quick Start Run failure-mode analysis on this change before writing any tests and list which categories need test coverage.

Frequently Asked Questions about failure-mode-analysis

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

FAQPage Schema
How do I decide which edge cases to test before writing code?

Walk eight failure-mode categories — null, empty, boundary, very large, malformed, concurrent, external failure, and locale — writing one bullet per category. Write tests only for categories that are realistic, cause non-obvious failures, or cross a trust boundary.

When should failure-mode analysis run in a TDD workflow?

Run it after the requirements gate and before writing the first failing test. Skip it for type-only changes, single-line trivial edits, and documentation or config changes without behavior impact.

What failure modes do developers usually miss in testing?

Commonly missed modes include concurrency windows between async read and write, partial commits where the database succeeded but downstream failed, empty result sets, and locale or timezone differences from the server.

Does failure-mode analysis replace design review or QA validation?

No. Failure-mode analysis enumerates failure modes before tests are written, while design review checks design principles and qa-validator finds gaps after implementation. They are complementary lenses, not substitutes.

When should I skip failure-mode analysis?

Skip it for trivial single-line edits, type-only changes, and documentation work. Also avoid writing tests for impossible-by-contract failure modes that the type system already prevents.