Verification Before Completion

Verification before completion

Verify the requested result using observed commands and actual artifacts. Match checks to the affected behavior and repository requirements.

Instructions

1. Inspect git status --short and git diff to include modified, staged, and untracked files. Read the changed code; check imports, error handling, compatibility, and unintended edits.
2. Run the repository's required tests, build, lint, and format checks. Start with relevant tests; run the full affected suite when required or when shared behavior changed. Do not substitute syntax checks for behavior tests.
3. Check generated artifacts at their expected paths. For integrations, verify all four levels: EXISTS on disk, SUBSTANTIVE implementation, WIRED into callers, and real DATA FLOWS through it. Trace inputs and results; an unused file or hardcoded empty result is not a working feature.
4. Inspect the diff for accidental debug code, secrets, placeholders, and unfinished work. Review matches in context: an intentional pass or empty result is not automatically a stub. Resolve missing implementations and wiring before claiming completion.
5. Fix failures within the authorized task and rerun affected checks. A failed required build or test blocks a success claim. Do not repeat unchanged passing checks without a reason.
6. Report commands, observed status, relevant counts, and remaining limitations. Retain full logs; include actionable failure excerpts and log paths instead of every passing test name. Distinguish automated checks, manual checks, and checks not run.

Use project commands first. Defaults when no project command exists:

Reuse check evidence

Reuse a passing result when it covers the current task and checked files, dependencies, configuration, and relevant environment. Keep its command, scope, revision or file state, result, and log path when available. A phase change or new worker alone does not require a rerun.

After edits, rerun affected checks. Rerun when evidence is missing, the checked state cannot be established, shared dependencies or environment changed, or failures leave uncertainty. Refresh mutable external state such as CI and deployment status before acting on it. Required CI and release checks still apply to the commit or artifact being delivered; an earlier local pass does not replace them.

For inherited results, cite their source and check their applicability. Do not claim you ran them. Review roster and review reuse belong to skills/process/pr-workflow/references/pr-risk-policy.md; this skill owns check evidence and completion claims.

Recovery

• No tests: perform suitable manual checks and state the coverage gap. Add a regression test when the task warrants one; do not imply manual inspection proves behavior.
• Missing dependencies: use the repository environment; report the missing tool and any narrower checks performed. Unrun checks are not passes.
• Build or test failure: retain the failing command and diagnostic, identify the cause, fix it, and rerun. Separate unrelated failures with evidence.
• Missing wiring or data flow: name the caller or call site where integration stops and repair it.

Reference loading table

Load only when the signal applies; files are under references/.

For code-review artifacts, use python3 scripts/validate-review-output.py --type {systematic|parallel|sapcc-review|sapcc-audit} <file.md>. Exit codes: 0 valid, 1 schema errors, 2 unparseable, 3 missing jsonschema (pip install jsonschema). Systematic and parallel review validate on return and retry once before stopping. A valid schema verifies structure, not the truth of review findings.