jacob-checkpoint

name

jacob-checkpoint

description

Run a Jacob-style final checkpoint on completed or nearly completed implementations. Use when Codex has changed code, config, schema, API, behavior, or important implementation-facing docs and must verify preference fit and correctness before finalizing. Trigger on requests such as "final checkpoint", "review as Jacob", "check preference fit and correctness", or when global instructions require a post-implementation gate. Do not use for pure planning, pure exploration, or discussion-only turns.

Jacob Checkpoint

Overview

Use this skill as the last gate before claiming implementation is done. Reconstruct the requested contract, inspect the real implementation and verification evidence, then return an honest verdict aligned to Jacob's standards.

Load these references before reviewing:

• references/jacob-preference-profile.md
• references/jacob-checkpoint-rubric.md

When To Run

Run this skill after tasks that changed:

• code or behavior
• config, schema, or API contracts
• implementation-facing docs, examples, or setup instructions

Do not run it for:

• pure planning
• pure exploration
• discussion-only turns
• unchanged repositories with no implementation to inspect

If the gate is not applicable, say so plainly and stop instead of forcing a verdict.

Review Workflow

1. Lock the contract.

• Restate the requested behavior, explicit constraints, and out-of-scope boundaries.
• Include repo or global AGENTS instructions when they materially constrain the work.

2. Inspect the implementation.

• Check the current diff, changed files, and the actual shape of the code.
• Verify that the implementation matches the requested layer boundaries and interface design.
• Review only. Do not patch files, do not "fix it quickly", and do not expand scope while running this checkpoint.

3. Inspect the evidence.

• Collect the tests, builds, manual verification steps, screenshots, logs, or command outputs that support correctness.
• If relevant verification is missing and cheap to run safely, run the smallest useful checks before deciding.

4. Apply the hard gates.

• Correctness proof: behavior-changing work must have direct evidence, not just plausible code.
• Verification coverage: missing relevant verification cannot receive PASS.
• No hidden tech debt: block new fallback, legacy, compatibility, dual-path, or speculative future-version logic unless explicitly requested.
• Interface cleanliness: block wrong-layer logic, leaky abstractions, or temporary versioning that should not exist yet.
• Docs/spec alignment: when behavior or public usage changes, relevant docs, examples, and setup notes must stay aligned.
• Scope compliance: block edits that drift outside the requested scope or quietly broaden the solution.

5. Choose the verdict honestly.

• Use PASS only when the implementation clears the hard gates and has evidence to support correctness.
• Use BLOCK when there is a clear mismatch, an unresolved high-risk issue, or a hard-gate violation.
• Use NEEDS_CHECK when the result may be acceptable but proof is still insufficient.
• If there is no implementation to inspect yet, use NEEDS_CHECK and explicitly say the checkpoint is not applicable yet because no code/config/schema/API/behavior change exists.
• Never upgrade uncertainty into confidence.

Output Contract

Use Traditional Chinese sentences under these exact section headers:

Verdict: PASS|BLOCK|NEEDS_CHECK

Preference Fit
- ...

Correctness
- ...

Evidence Run
- ...

Scope/Architecture
- ...

Required Fixes
- ...

Keep the output direct and concrete:

• findings before summary
• no filler or reassurance
• no pretending missing evidence exists
• no vague "應該可以" language

For PASS, write - None. under Required Fixes.

Review Priorities

Prioritize these questions in order:

1. Is it actually correct?
2. Is that correctness supported by evidence?
3. Did the implementation stay within scope?
4. Did it keep the architecture and interfaces clean?
5. Did it avoid fallback, legacy, and premature compatibility baggage?
6. Are the relevant docs and examples still true?

Failure Patterns To Flag

Block or downgrade aggressively when you see:

• unverified fallback or compatibility branches
• behavior changes without meaningful tests or verification
• code placed in the wrong layer even if it "works"
• public or user-facing docs that no longer match the implementation
• hidden scope creep or over-engineering
• future-version naming (v2, next, dual schema/version branches) without a real release need

Resource Map

• references/jacob-preference-profile.md: distilled persona and hard preferences derived from recent Codex usage plus global AGENTS.
• references/jacob-checkpoint-rubric.md: executable gate for deciding PASS, BLOCK, or NEEDS_CHECK.