skills/shape-handbook/references/checks.md

# Shape independent checks

A check states an evaluable expectation for work. It applies on its own whenever
its conditions hold, including work with no Playbook. Verification may require
judgment; an executable test is optional support.

Inspect existing checks, relevant practices, and authoritative requirements for the work.
Write or revise `checks/<name>.md` with a portable lowercase hyphenated name and
headings suited to its expectation. Preserve:

- **Applicability:** the work, stage, conditions, and relevant exclusions.
- **Requirement:** the specific expectation to evaluate.
- **Verification:** evidence to inspect, comparisons or reasoning to perform, and limits.
- **Outcomes:** pass, fail, unable, and not applicable with meaningful reasons and responses.

Pass requires adequate evidence for the expectation. Fail requires evidence of an
unmet expectation. Unable means missing access, evidence, or interpretive clarity
prevents a supported conclusion. Not applicable means the conditions for applying
the check do not hold. Tailor these meanings to the check rather than relying on labels alone.

Keep the work's requirements and actual review findings in their authoritative
files. For example, a check can ask whether a research summary supports its claims
with sources. The research notes still hold the observations, and the summary's
review records any unsupported claims it finds. Link relevant practices for
rationale and authoritative requirements for exact meaning.

Describe where authorized saved findings belong without requiring an extra report
for a task that requests findings in the response. A storage convention does not
expand the ordinary task's requested outputs or write permissions.

A precise open question may satisfy draft completeness while the underlying decision
remains unresolved. Distinguish adequate documentation of uncertainty from resolution
or readiness. Reading a check, filling a template, and passing a structural validator
do not perform semantic verification.

Combine overlapping checks when their applicability and failure meaning cannot be
distinguished. Keep independently meaningful expectations separate. Coordinate
related practice or template changes when the requested refinement needs them.
Explicit owner direction can establish an expectation; keep consequential inferred
requirements visibly proposed until adopted.

Adapt [the check starter](../assets/check.md) or an applicable handbook template.
Add local templates only for useful reuse. Check whether a future reviewer could
explain each outcome from evidence. A bounded example can expose ambiguity in the
definition; it does not authorize reviewing the actual work or changing its
findings while shaping the handbook.