Design a verification strategy for specific components to unlock more autonomy. Trigger phrases: "design verification strategy", "what verification do I need", "verification plan", "how to verify this component", "unlock autonomy for this module", "what tests should I add"
How this skill is triggered — by the user, by Claude, or both
Slash command
/software-verification:design-strategy [component-name-or-path] (defaults to full codebase)[component-name-or-path] (defaults to full codebase)This skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Design a tailored verification strategy for specific components or the full codebase. Produces a `verification-strategy.md` with per-component recommendations, oracle strategies, evidence pipeline design, and an implementation roadmap.
references/eval-framework-operations.mdreferences/eval-framework.mdreferences/fitness-functions-implementation.mdreferences/fitness-functions.mdreferences/gate-design-patterns.mdreferences/generator-evaluator.mdreferences/harness-architecture.mdreferences/hybrid-strategies.mdreferences/oracle-patterns.mdreferences/safe-evolution.mdreferences/strategy-report-template.mdreferences/toolchain-catalog-ecosystems.mdreferences/toolchain-catalog.mdreferences/traceability-design.mdDesign a tailored verification strategy for specific components or the full codebase. Produces a verification-strategy.md with per-component recommendations, oracle strategies, evidence pipeline design, and an implementation roadmap.
Search for verification-report.md in the codebase. If it exists, read the component breakdown, maturity tier, and identified gaps.
If no report exists, perform a lightweight discovery:
Load references/hybrid-strategies.md for archetype-to-stack mappings.
Load references/toolchain-catalog.md and references/toolchain-catalog-ecosystems.md for ecosystem-specific tool recommendations.
For each target component:
Load references/oracle-patterns.md.
For each component, recommend the best oracle type:
| Component type | Recommended oracle approach |
|---|---|
| Pure functions | Exact expected output + property-based |
| User-facing behavior | Executable acceptance criteria (Gherkin/BDD) linked to requirements |
| API endpoints | Schema validation + contract tests |
| Data pipelines | Metamorphic relations + replay |
| ML models | Differential + statistical + human |
| State machines | Model checking + replay |
| UI components | Snapshot + visual regression + human |
For each recommendation, specify:
Load references/fitness-functions.md and references/fitness-functions-implementation.md for types, tools, and maturity levels.
For each target component, identify architectural invariants that should be automated:
For each recommended fitness function, specify:
Calibrate deliberately (see "Calibration and execution cost" in the implementation reference): start permissive and tighten on observed violations; fitness functions enforce decisions already made, they do not replace architectural judgment.
Load references/harness-architecture.md for the five-lane model, interface schemas, and harness metrics.
Recommend how verification evidence should flow through CI/CD:
Per risk level:
Promotion policies:
Load ../assess-verification/references/feedback-loop-model.md for feedback loop maturity levels and assessment criteria.
If verification-report.md exists, read the Feedback Loop Completeness section. Otherwise, do a lightweight check:
For each verification method at Level 0-1, recommend how to close the loop:
| Current state | Recommended action | Tools/config |
|---|---|---|
| Plain text logs only | Add structured reporter | JUnit XML, SARIF, JSON formatter |
| Structured output not stored | Add artifact upload step | actions/upload-artifact, S3, GCS |
| Artifacts not accessible to agents | Expose via API or webhook | GitHub Checks API, CI notification |
| No re-execution trigger | Add dispatch or retry mechanism | workflow_dispatch, retry-on-failure |
For each recommendation, specify the concrete config change or tool addition needed.
Load ../assess-verification/references/shift-left-model.md for the tier model.
If verification-report.md exists, read the Shift-Left Assessment section. Otherwise, check whether
type checking / linting run only in CI (should be per-file via pre-commit or hooks), whether pre-commit
hooks exist (.pre-commit-config.yaml, .husky/, lefthook.yml), and whether focused/affected-only
test runs are available.
For each check running later than its ideal tier, recommend how to shift it earlier:
| Check | Current | Target | Action |
|---|---|---|---|
| Type checking | T3 (CI only) | T1 (per-file) | Add pre-commit hook or agent post-write hook running tsc --noEmit |
| Linting | T3 (CI only) | T1 (per-file) | Add pre-commit hook; configure agent to run linter after each write |
| Secret scanning | T3 (CI) | T1 (pre-commit) | Add detect-secrets or gitleaks pre-commit hook |
| Focused / affected tests | T3 (full suite) | T2 (per-module) | Run changed-files tests only; add TIA (pytest-testmon, Jest --onlyChanged, Launchable) |
For each recommendation, specify the concrete tool and config to add.
Load references/gate-design-patterns.md.
If verification-report.md exists, read the Workflow Gate Assessment section. Otherwise, identify gates from:
.github/settings.yml, repo settings)Recommend gate consolidation toward the three-checkpoint model:
For each recommendation:
Load references/eval-framework.md and references/eval-framework-operations.md for eval components, measurement dimensions, and building strategy.
Recommend an eval framework appropriate for the codebase:
For each recommended eval task:
Load references/generator-evaluator.md for pattern variants and application guidance.
For high-criticality components, recommend whether generator-evaluator patterns apply:
| Variant | Apply when | Cost |
|---|---|---|
| Generator + Test-Writer | New features with clear specs | 2x |
| Generator + Critic | Security-sensitive or complex changes | 1.5x |
| Generator + Mutant | Assessing test adequacy | 2-3x |
| N-of-M Consensus | Critical, well-specified components | Nx |
For each recommended application:
If verification-report.md exists, read the Documentation Verification section. Otherwise, check:
Recommend documentation-as-code practices based on current gaps:
| Current state | Recommendation | Tools |
|---|---|---|
| No auto-generated docs | Add doc generation from code annotations | TypeDoc, Sphinx autodoc, rustdoc, springdoc |
| Docs exist but not in CI | Add strict doc build + link checking to CI | mkdocs build --strict, markdown-link-check |
| Examples not tested | Add doctest or tested snippet pipeline | pytest --doctest-modules, cargo test (doc examples) |
| No schema-doc sync | Validate API spec against implementation | schemathesis, openapi-diff, prism mock validation |
| Docs not updated with code | Add freshness enforcement (co-change requirements) | CODEOWNERS on docs, CI check for doc-alongside-code |
For each recommendation, specify the concrete tool and config needed. Priority: schema-doc sync (prevents fabrication) > example testing (catches drift) > freshness enforcement (process-level).
Order recommendations by priority:
For each item specify: action, component, effort, dependencies, tools to install.
Load references/traceability-design.md. Read the report's Requirement Traceability section if present;
otherwise check for stable requirement IDs, executable acceptance criteria (Gherkin/BDD), PR→issue links,
and a requirement-coverage report. Recommend the next maturity step plus three explicit deliverables:
Load-bearing constraint: the gap check must be a deterministic script that parses IDs/tags — not an agent re-reading the spec. An agent re-reading the spec to "verify" the trace reintroduces the exact indeterminism the RTM exists to remove (an agent verifying agents). Make this explicit in the recommendation.
For components facing breaking or large-scale change (renames, API/schema reshapes, convention
migrations), load references/safe-evolution.md and recommend a staged approach instead of a one-shot
diff — the failure mode agents default to.
Recommend this wherever the assessment flagged a large refactor, migration, or cross-cutting rename. Tie the gate back to the evidence pipeline (Step 6): each incremental step passes the same checks.
Load references/strategy-report-template.md. Write verification-strategy.md following the template, covering all sections from Steps 1-15 (component strategies through roadmap, plus traceability and safe-evolution).
npx claudepluginhub krokoko/cairn --plugin software-verificationProvides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.