Input and output
- Output: inspection delivers only an in-conversation report and modification plan
Execution principles
Rule set
Stance: judge by the maintenance cost of production code; when the root cause lies in structure rather than local expression, explicitly state that local patching is insufficient and give a direction. Write code per the rule set; for cases not covered by the rules, use the stance to decide; inspection uses only the rule set as the basis for findings and does not report issues outside it.
- Naming and signatures: names express meaning, the same concept has the same name throughout, no vague abbreviations or single letters; function names match behavior
- Function granularity: extract a named function when a function exceeds 50 lines or contains multiple semantic segments; for hard-to-read expressions use named local variables first; inline when the name carries no more information than the function body
- Parameters and interfaces: when parameters exceed 5 or the same group of parameters repeatedly clusters across functions, encapsulate into a struct; split bool parameters that control branches into named functions; when similar functions differ only in literals, lift the difference into a parameter
- Responsibility and ownership: one unit, one reason to change; delete intermediate layers that only forward and add no value
- Conditional logic: extract a named function when nesting exceeds 3 levels; return early on the normal path, do not bury it deep in else; consolidate checks for the same special value scattered in multiple places into one place
- Dead code: delete uncalled variables, functions, classes, commented-out code, unreachable branches; for public exports first confirm there are no external calls
- Duplicate code: when identical or near-identical blocks repeat, extract a shared implementation and parameterize the differences; do not report coincidental similarity that evolves independently, or short blocks of only two occurrences and no more than 5 lines
- Magic values: lift bare literals carrying business meaning into named constants; business configuration goes through configuration, not hardcoded in code
- Comments: by default do not write; keep only the why and external contracts that would cause pitfalls if deleted; delete restatements of code, narration of the change process, section-header banners, and docstrings that repeat signatures
- Error handling: no empty catch, no swallowing error return values, no logging-only-then-continue; use a unified error propagation mechanism within the same module
- Boundaries and validation: validate external input at the entry point, fail fast on invalid input; do not re-validate what is already validated internally
- Interface semantics: return values can distinguish key states; not found and already invalid are two different results; statistics and results go through return values, not print-only; do not expose mutable data directly for external read/write
Workflow
To write or modify code, use write code; to only check without modifying, use inspection.
Write code
- Clarify requirement boundaries and delivery location; list decision points left open by the requirements to the user first, then continue with the most reasonable default
- Write per the rule set
- Before delivery, self-check item by item against the rule set
Inspection
When the user explicitly requests multi-model / cross-review, review findings are instead produced bymulti-model orchestration, and the report and confirmation steps remain unchanged.
- Read through the target code; when the input is a git diff / patch, limit findings to the changed scope, and read context when necessary; For more than 500 lines, multiple files, or the whole repository, first confirm the batching granularity with the user (by file / by class / by function), and present the findings in batches
- If the project has lint configured, run it first to get mechanical hits; treat hits only as background; for numeric thresholds such as line count, parameter count, and nesting depth, first use grep or quick AST counting to get the counts, do not rely on visual estimation; then fill in design-level findings one by one against the rule set
- Produce the report: start with a 2-4 sentence restatement of understanding (what the code is doing and how the structure flows; mark anything uncertain as doubtful); each finding includes the rule name, location, and suggestion; Mechanical items and trivial items that lint can determine (individual naming preferences, single-line style) do not go into the list; out-of-scope issues such as suspected correctness, performance, and security get a separate line, directing to a separate specialized review, without expanding on the fix; for behavior changes or breaking changes to published APIs, note the impact
- Deliver the report to the user; after approval, make changes according to the confirmed plan