Skill: quality-gates

Purpose

Use this skill as a lightweight control layer for non-trivial engineering work. It keeps agent output evidence-bound, task execution lifecycle-aware, reviewable, and resistant to Engineering Bible drift.

This skill does not replace language, security, UI, documentation, or review skills. It composes with them.

Author Verification Provider

For workflow completion, resolve superpowers.verification-before-completion with be skills route superpowers.verification-before-completion --json and read the complete exposed author skill and its required references. Its procedure remains upstream. The evidence, release and library-drift rules below are Bible's separate owner policy. Reuse compatible native providers, install missing reviewed dependencies through the selected profile, and report pending exposure. Do not replace the author procedure with this policy checklist.

Required References

Read only the references needed for the task:

• ../../engineering/35_evidence_contract.md for claims, facts, validation, and uncertainty.
• ../../engineering/36_task_lifecycle_gates.md for task scope, inspection, planning, validation, and reporting.
• ../../engineering/37_review_regression_gates.md for diff-risk review and regression coverage.
• ../../engineering/38_library_drift_audit.md for repository integrity and portable-tree drift.

When To Use

Use this skill when a request is non-trivial and involves any of:

• code changes;
• repository structure changes;
• installer or CLI behavior;
• docs that define behavior or process;
• validation, CI, test, or review workflows;
• multi-step debugging or refactoring;
• claims about current code, runtime state, test results, or external behavior.

For trivial read-only answers, apply the evidence contract without loading every reference document.

Operating Rules

• Important factual claims need evidence: file path, command output, test result, or explicit uncertainty.
• Do not claim validation passed unless the exact command was run.
• Inspect relevant files before changing them.
• Keep task gates proportional to task risk.
• Review behavior changes before completion.
• Add or update regression coverage when a defect class is fixed.
• Treat library drift as a repository bug, not as documentation polish.

Optional Test-Strength Check

For explicitly selected critical logic or a suspected weak test, use Targeted Mutation Testing. Select a small verified source/test allowlist and human-reviewed replacements. The Python helper executes baseline and mutant tests in separate temporary copies; those copies are not a sandbox for untrusted test code. Require a passing baseline and retain raw outputs and original exits. Assertion failures can kill a mutant; syntax, import and execution errors or timeouts cannot. A surviving mutant needs a concrete test-strength assessment, not a claimed passing gate. Do not run campaigns on every edit, install a framework implicitly, or mutate the working source. Select project-native Stryker separately for TypeScript.

Output

When this skill materially affects the work, report:

• evidence used;
• lifecycle gates completed;
• validation commands and results;
• review or regression reasoning;
• remaining risks.