Menu
Contract integrity preflight — verify the work contract is truthful, consistent, and non-contradictory before reading the diff.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
α role in CDD. Implements the selected change, produces the review-ready artifact set, and writes α close-out.
β role in CDD. Reviews the change, merges on approval, and writes β close-out. δ owns the release boundary (tag/deploy/disconnect).
Compatibility pointer. Cross-repo handoff doctrine has moved to cnos.handoff/skills/handoff/cross-repo/SKILL.md as of cnos#416 (Sub 2 of cnos#404 handoff extraction).
δ role-skill. Owns the two-sided coherence-cell membrane (outward boundary decision on receipt + V verdict; inward implementation-contract enrichment at dispatch) and the override authority that compose with V's verdict per RECEIPT-VALIDATION.md.
Produce the design artifact for a substantial change: incoherence, challenged assumption, impact graph, acceptance criteria, and leverage.
ε role in CDD — the CDD-specific instantiation of the generic ε doctrine. Reads receipt streams across cycles, surfaces `cdd-*-gap` findings, applies MCA discipline, and writes `cdd-iteration.md` when the cycle's receipt has `protocol_gap_count > 0`.
| name | review/contract |
| description | Contract integrity preflight — verify the work contract is truthful, consistent, and non-contradictory before reading the diff. |
| artifact_class | skill |
| kata_surface | external |
| governing_question | How does β verify that the work contract is truthful, scoped, sourced, and non-contradictory before inspecting implementation? |
| visibility | internal |
| parent | review |
| triggers | ["review contract"] |
| scope | task-local |
| inputs | ["issue","PR body","branch summary"] |
| outputs | ["contract integrity table (yes/no/n/a per check)"] |
| requires | ["review orchestrator loaded"] |
| calls | [] |
GATE: Complete this phase before reading the diff. A branch can be locally well-implemented and still not review-ready if the contract it claims to satisfy is contradictory, stale, or overclaims shipped behavior.
Fill the Contract Integrity table. If any row is "no," the review cannot approve unless the row is explicitly out of scope and the reviewer names why it does not affect merge readiness.
## §2.0.0 Contract Integrity
| Check | Result | Notes |
|---|---|---|
| Status truth preserved | yes / no / n/a | |
| Canonical sources/paths verified | yes / no / n/a | |
| Scope/non-goals consistent | yes / no / n/a | |
| Constraint strata consistent | yes / no / n/a | |
| Exceptions field-specific/reasoned | yes / no / n/a | |
| Path resolution base explicit | yes / no / n/a | |
| Proof shape adequate | yes / no / n/a | |
| Cross-surface projections updated | yes / no / n/a | |
| No witness theater / false closure | yes / no / n/a | |
| PR body matches branch files | yes / no / n/a | |
Verify that the issue, PR body, branch artifacts, and docs distinguish:
Findings:
D if the branch claims runtime enforcement that does not exist.
C if draft/target state is described as current but the diff does not rely on it.
mechanical if the status label is plainly stale across docs/README/source map.
❌ "CTB enforces witnessed close-outs" when only the v0.2 draft defines them.
✅ "CTB v0.2 draft defines witnessed close-outs; ctb-check/runtime enforcement is not shipped."
For every load-bearing claim in the issue or PR body, verify the canonical source. Check:
If paths changed, grep old paths across live docs and code.
docs/alpha/essays/MANIFESTO.md.Check whether any AC, implementation note, PR claim, or output artifact contradicts the non-goals.
Findings:
D if an out-of-scope behavior is implemented or claimed as shipped.
C if the PR body implies out-of-scope work but files do not.
mechanical if the contradiction is textual and deterministic.
❌ Non-goal: "do not implement runtime enforcement." PR body: "runtime now enforces CTB v0.2."
✅ PR body: "adds structural checker issue; runtime enforcement remains out of scope."
If the issue defines required/optional/exception-backed fields or rules, verify that examples and implementation obey the strata. Check:
hard gates are not exception-backed;
exception-backed fields have field-specific exceptions;
optional/defaulted fields name defaults;
validated-if-present fields are actually checked when present;
deferred fields are not silently enforced or claimed.
❌ Hard gate: scope. Exception example: "allowed_missing": ["scope"].
✅ Exception example only lists exception-backed fields such as artifact_class or kata_surface.
Exceptions are debt, not blanket permission. Verify:
exceptions are field-specific;
each exception has a reason;
JSON exceptions do not rely on comments;
exceptions do not exempt hard gates;
cleanup/removal condition is named where appropriate.
❌ { "path": "...", "ignore": true }
✅ { "path": "...", "allowed_missing": ["artifact_class"], "reason": "legacy skill migration pending" }
If the issue or implementation validates paths, verify the resolution base. Check whether paths are:
Require at least one concrete example when path validation is part of the change.
alpha/SKILL.md with calls: design/SKILL.md resolves to src/packages/cnos.cdd/skills/cdd/design/SKILL.md.For checker, schema, parser, runtime, CI, and validation issues, verify that the branch includes:
Existing CI passing is the floor, not the proof.
When the diff adds or changes a status, checker, command, CI job, source map, schema, or runtime surface, verify every projection that should expose it.
Examples:
CI job added → notify aggregation updated.
README source map changed → docs README changed.
Schema added → schema README / fixtures / CI invocation added.
Runtime status changed → help / doctor / status / docs agree.
Upstream formal source added → source map and further-reading sections agree.
❌ Add CI job I5 but leave Telegram/notify aggregation unaware of I5.
✅ I5 is added and notify job result summary includes I5.
If the change adds witnesses, close-outs, review artifacts, checker outputs, debt records, or governance structure, verify that the structure is accountable to evidence. Ask:
Findings:
D if the branch claims enforcement but only adds prose.
C if the structure is useful but lacks the promised rejection mechanism.
B if the rejection mechanism is correctly deferred but the deferral could be clearer.
❌ 10-field close-out shape exists, but no checker or issue says which fields are required.
✅ Spec names required fields; checker issue requires invalid fixtures and diagnostics.
Verify that the PR description still matches the corrected branch files. After fix rounds, PR bodies can describe an older state.
├─ architecture.If all rows are "yes" or "n/a," proceed to Phase 2 (implementation review).
If any row is "no," file findings immediately. The implementation review may still proceed, but verdict must account for the contract-level findings.
Return to orchestrator (review/SKILL.md) → Load Phase 2 starting with review/issue-contract/SKILL.md.