testability-analysis ยท diff
git:20260829.175e380 to git:20260914.ba5cf40
5 added, 2 removed. Audit A to A.
---
name: testability-analysis
description: Use this skill when you need to assess whether a requirement or design can be efficiently and reliably tested; triggers include testability analysis.
---
# Testability Analysis
## When to Use
- Use this skill when you need to assess requirements and systems for controllability, observability, isolation, and reproducibility.
- Use it to review an existing plan, result, or evidence set and produce actionable improvements.
- Use it when context is incomplete but a bounded first pass is still valuable.
## Output Format Options
- Default to Markdown for review, execution, and incremental refinement.
- When the user requests tables, CSV, JSON, or ticket fields, preserve risk, evidence, priority, and boundary information.
- For machine-consumed output, confirm the schema, enums, and required fields first.
## How to Use
1. Read and follow `prompts/testability-analysis.md`, including its input contract, execution rules, minimum coverage, and output order.
2. Add only context that changes the decision: scope, environment, version, constraints, evidence, and success criteria.
3. Audit the input, then separate confirmed facts, working assumptions, and open questions.
- 4. Rank by risk and evidence strength, and produce an artifact that can be executed or reviewed directly.
- 5. If information is missing, deliver a bounded first pass and state which conclusions remain unsupported.
+ 4. When the task requests `architecture-testability-review` or `architecture` mode, start from architecture artifacts, dependency topology, asynchronous boundaries, test seams, substitute strategy, fault-injection entry points, and environment reproduction while retaining the generic testability dimensions.
+ 5. Rank by risk and evidence strength, and produce an artifact that can be executed or reviewed directly.
+ 6. If information is missing, deliver a bounded first pass and state which conclusions remain unsupported.
## Reference Files
- Always read `prompts/testability-analysis.md`; it is the complete execution specification for this skill.
- For evaluation or regression, read `evals/eval.yaml` and the relevant cases under `evals/cases/`.
- Load `references/`, `examples/`, `scripts/`, or `output-formats.md` only when those directories exist and the task needs them.
+ - To regress `architecture-testability-review`, use the `architecture-*` Evals and local trigger data while retaining this physical Skill directory; do not create an alias directory.
## Core Constraints
- do not confuse framework choice with testability
- state value and cost for each improvement
- never expose unsafe backdoors for testing
+ - In `architecture` mode, bind seam, substitute, isolation, and fault-injection judgments to architecture-level sources; a framework name is not testability evidence.
- Never invent system behavior, fields, data, metrics, or root causes absent from the evidence.
- Link important conclusions to evidence; mark unsupported conclusions as hypotheses with a verification method.
- Explain priority using business impact, likelihood, or detectability.
## Delivery Checklist
- [ ] Covered: observability, controllability, isolation, determinism, data setup, fault injection, environment parity, automation interfaces.
- [ ] Separated facts, assumptions, gaps, and recommendations.
- [ ] Gave high-risk items a priority, evidence basis, owner or next action.
- [ ] Defined verifiable decision criteria instead of generic advice.
- [ ] Performed no unauthorized production writes or destructive actions.
## Common Pitfalls
- Listing checks without preconditions, expected outcomes, or evidence.
- Marking everything high priority and avoiding tradeoffs.
- Substituting tool names or generic theory for domain reasoning.
- Refusing incomplete input, or pretending incomplete evidence supports certainty.
## Best Practices
- Start with paths most likely to cause business loss, safety issues, or release blockage.
- Reduce uncertainty through the smallest verifiable experiment and record reproduction conditions.
- Make the artifact executable and independently reviewable by another engineer.