diff options
| -rw-r--r-- | add-tests/SKILL.md | 5 | ||||
| -rw-r--r-- | five-whys/SKILL.md | 2 | ||||
| -rw-r--r-- | pairwise-tests/SKILL.md | 2 | ||||
| -rw-r--r-- | root-cause-trace/SKILL.md | 2 |
4 files changed, 8 insertions, 3 deletions
diff --git a/add-tests/SKILL.md b/add-tests/SKILL.md index 95e7a2e..3dd91fc 100644 --- a/add-tests/SKILL.md +++ b/add-tests/SKILL.md @@ -1,3 +1,8 @@ +--- +name: add-tests +description: Add test coverage to under-tested code through four phases — Analyze, Propose, Write, Report. Phase 1 inventories code and flags testability-blocked functions (so coupled to UI/framework that testing would mock the code under test). Phase 2 presents a plan and stops for user approval, with per-function pairwise-vs-exhaustive choice for parameter-heavy functions and refactor-or-skip for testability-blocked ones. Phase 3 writes Normal/Boundary/Error tests and diagnoses test-vs-code failures instead of reflexively patching either side. Phase 4 reports test count, coverage change, bugs surfaced. Refactors testability-blocked functions into pure helper + interactive wrapper before testing rather than mocking it. Use when raising coverage on existing code. Do NOT use for TDD on new code (inline), a single failing test (just fix it), characterization snapshot (write directly), or happy-path smoke test. Companion to `/pairwise-tests` and the Normal/Boundary/Error discipline in `testing.md`. +--- + # /add-tests Add test coverage to existing code by analyzing, proposing, writing, and reporting. diff --git a/five-whys/SKILL.md b/five-whys/SKILL.md index 3cfacf4..7d7080d 100644 --- a/five-whys/SKILL.md +++ b/five-whys/SKILL.md @@ -1,6 +1,6 @@ --- name: five-whys -description: Drive iterative "why?" questioning from an observed problem to its actual root cause, then propose fixes that target the root rather than the symptom. Default depth is five, but the real stop condition is reaching a cause that, if eliminated, would prevent every observed symptom in the chain — that may take three whys or eight. Handles branching (multiple contributing causes, each explored separately), validates the chain by working backward from root to symptom, and rejects "human error" as a terminal answer (keep asking why the process allowed that error). Use for process, decision, and organizational failures — missed code reviews, recurring incidents, slow deploys, flaky releases, "we've fixed this three times already" problems. Do NOT use for debugging a stack trace (use root-cause-trace, which walks the call chain), for tactical defect investigation where the fix site is local and obvious, or for blame attribution (the skill refuses to terminate at a person). Companion to root-cause-trace — that's for code execution; this is for process/decision root-causes. Often dispatched from `debug`'s Phase 2 routing when the failure is a process or organizational chain rather than a stack trace. +description: Drive iterative "why?" questioning from an observed problem to its actual root cause, then fix at the root rather than the symptom. Default depth is five, but the real stop is reaching a cause whose removal prevents every symptom in the chain — may take three whys or eight. Handles branching (multiple contributing causes explored separately), validates by working backward from root to symptom, rejects "human error" as terminal (keep asking why the process allowed it). Use for process, decision, and organizational failures — missed code reviews, recurring incidents, slow deploys, flaky releases, "we've fixed this three times already" problems. Do NOT use for stack-trace debugging (use root-cause-trace), tactical defect investigation where the fix site is local and obvious, or blame attribution (refuses to terminate at a person). Companion to root-cause-trace — that walks code-execution chains; this walks process/decision chains. Often dispatched from `debug`'s Phase 2 routing. --- # Five Whys diff --git a/pairwise-tests/SKILL.md b/pairwise-tests/SKILL.md index e7b45a1..5e45b40 100644 --- a/pairwise-tests/SKILL.md +++ b/pairwise-tests/SKILL.md @@ -1,6 +1,6 @@ --- name: pairwise-tests -description: Generate a minimal test matrix covering all pairwise parameter interactions using PICT (Pairwise Independent Combinatorial Testing). Given a function, feature, or configuration space with many input parameters, identifies parameters + value partitions + inter-parameter constraints, builds a PICT model, and produces a small set of test cases (typically 80-99% fewer than exhaustive) that still hits every 2-way combination of parameter values. Empirically catches 60-90% of combinatorial bugs. Use when a function has 3+ parameters with multiple values each and exhaustive testing would explode (feature flag combinations, permission/role matrices, config matrices, multi-field form validation, API parameter spaces). Do NOT use for functions with 1-2 parameters (just write the cases directly), for regulated contexts where provably exhaustive coverage is required (document as an ADR and write all cases), or for testing non-parametric behavior (happy path, single error case, performance regression — use `/add-tests` for those). Output: PICT model, markdown table of generated test cases, expected result per row. See also `/add-tests` for standard test generation and `testing.md` for the Normal/Boundary/Error category discipline. +description: Generate a minimal test matrix covering all pairwise parameter interactions using PICT (Pairwise Independent Combinatorial Testing). Identifies parameters, value partitions, inter-parameter constraints; builds a PICT model; produces a small set of test cases (typically 80-99% fewer than exhaustive) that still hits every 2-way combination. Empirically catches 60-90% of combinatorial bugs. Use when a function has 3+ parameters with multiple values each and exhaustive testing would explode (feature-flag combos, permission/role matrices, config matrices, multi-field form validation, API parameter spaces). Do NOT use for functions with 1-2 parameters (write cases directly), regulated contexts requiring provably exhaustive coverage (document as ADR and write all cases), or non-parametric behavior (happy path, single error, perf regression — use `/add-tests`). Output: PICT model, markdown table, expected result per row. See `/add-tests` and `testing.md`'s Normal/Boundary/Error. --- # Pairwise Tests (PICT) diff --git a/root-cause-trace/SKILL.md b/root-cause-trace/SKILL.md index 74e275d..fad4601 100644 --- a/root-cause-trace/SKILL.md +++ b/root-cause-trace/SKILL.md @@ -1,6 +1,6 @@ --- name: root-cause-trace -description: Given an error that manifests deep in the call stack, trace backward through the call chain to find the original trigger, then fix at the source and add defense-in-depth at each intermediate layer. Covers the backward-trace workflow (observe symptom → identify immediate cause → walk up the chain → find origin → fix + layer defenses), when and how to add instrumentation (stack capture before the dangerous operation, not after), and the bisection pattern for identifying which test pollutes shared state. Use when an error appears in the middle or end of an execution path, when a stack trace shows a long chain, when invalid data has unknown origin, or when a failure reproduces inconsistently across runs. Do NOT use for clear local bugs where the fix site is obvious (just fix it), for design-level root-cause analysis of processes/decisions (use five-whys instead), for performance regressions (different class of investigation), or when there's no symptom yet to trace from. Often dispatched from `debug`'s Phase 2 routing when the bug is a code-execution chain; usable directly when the symptom is already clearly a stack-trace walk. +description: Given an error manifesting deep in the call stack, trace backward through the call chain to the original trigger, fix at the source, and add defense-in-depth at each intermediate layer. Covers the backward-trace workflow (symptom → immediate cause → walk up the chain → origin → fix + layer defenses), when and how to add instrumentation (stack capture before the dangerous operation, not after), and the bisection pattern for finding which test pollutes shared state. Use when an error surfaces mid- or end-execution, a stack trace shows a long chain, invalid data has unknown origin, or a failure reproduces inconsistently across runs. Do NOT use for clear local bugs where the fix is obvious (just fix it), process/decision root-cause analysis (use five-whys), performance regressions (different investigation class), or when there's no concrete symptom yet. Often dispatched from `debug`'s Phase 2 routing for code-execution chains; usable directly when the symptom is already a stack-trace walk. --- # Root-Cause Trace |