The goal is to let the OCR or host reviewer know "what this change must preserve", rather than stuffing a generalized requirement into the prompt. Suitable for cross-module APIs, state machines, persistence structures, permission boundaries, or compatibility changes; ordinary single-file format changes do not need to invoke it.
When to use it and capability boundaries
Use when the review conclusion depends on "why the change was made" and cross-file behavior; if you are only checking formatting, compilation, or dependency vulnerabilities, hand off to CodeGuard. When there is no formal specification, you can still organize the observable behavior in the code, but you must not fabricate acceptance criteria.
- Input: the user's explicit review goal, candidate diff, relevant specs/tests, and project context. Read-only analysis; when the goal is missing, first point out the scope that can be determined, and do not guess requirements.
- Output: a traceable context summary, impact paths, behavioral assumptions that need review, and unknowns. Impacts without evidence can only be marked as "to be verified".
- In
codereview-pluginin the pre-commit flow, only analyze theauthorized snapshotit provides; do not directly read the live workspace and pass it off as staged content. When there is no snapshot, first return to the plugin-specificcodereview-harnessskill. - Upstream
ocr review --background/--background-fileis the input interface for manual OCR review. If the pre-commit plugin has no safe context injection interface, only show the summary to the reviewer; do not bypass the plugin and directly runocr review。 - Do not call models, install tools, send code externally, modify source files, or decide whether to commit. Reading source code and specs is still limited by the scope the user has disclosed.
Workflow / Workflow
Step 1 — Pin down the review target
Distinguish the workspace, branch range, single commit, full-file scan, and plugin candidate snapshot. Record the baseline and target; different targets must not be mixed.
Step 2 — Extract intent
Look first at the user's current request and the formal specification, then at design, tasks, and tests. Old READMEs and comments can only serve as clues; when they conflict, explain the conflict.
Step 3 — Locate impact
Trace backward from changed entry points, public APIs, callers, data reads and writes, permission checks, async/concurrency boundaries, and tests. If the repository has .codegraph/ , use CodeGraph first; otherwise use read-only search. Do not initialize an index for this skill.
Step 4 — Compress and validate the context
List the observable behaviors and negative cases that must be preserved, and compress them into purpose, change boundaries, the three most important invariants, affected paths, and missing evidence. The context must correspond to the current candidate; for external-send mode, first show the context and the recipient, and do not expand the original authorization scope.
If you need field styles and typical misuse, read Context and Impact Template。
Delivery format
审查对象：<类型、基线、候选标识>
业务目的：<一句话；出处>
必须保持：<行为 + 出处；最多三项>
影响路径：<入口 → 调用方/数据/外部契约；逐项证据>
重点风险：<可证伪的问题，不作结论>
未知与覆盖：<未读到的模块、测试、运行证据>
When formal requirements are missing, you can continue to provide "code observable behavior" context, but it must be marked as inference; you must not claim that the requirements have been accepted.
Gotchas / Common pitfalls
- With partial staging, the workspace differs from the candidate code: use only the version corresponding to the review target.
- Reachability in the call graph does not equal actual execution: conditions, feature flags, and dynamic dispatch need a second check.
- Test names are not requirement facts: mark them as implementation evidence, and look for formal acceptance grounds.
- When a critical path is missing, first deliver the limited context and the evidence to be supplied, rather than generalizing that it "may affect all modules."