yzr-coding-review

yzr-coding-review

Constrain code review intotraceable findings, executable conclusionsartifacts

Input and Output

Input(any form): code snippet / file path / git diff / patch (the latter two only review the changes) / project root + scope

Output: two forms (conversational analysis answer / report form) + go through the sub-loop item by item, routing see Step 3

Execution Principles

1. Do not proactively modify files: the output is conclusions / reports; only after the user nods do you proceed to the specific refactoring
2. Every finding is traceable: every finding maps to at least 1 catalog rule name
3. Review boundary convergence: do not cross the boundary into bug fixing / performance tuning execution / security auditing (when these signals are found, point out "suggest handling separately as a dedicated effort" and do not expand); mechanically decidable items (style rules / formatting / TODO / missing docstring) belong to CI and do not occupy finding items
4. Artifacts stay within the conversation: reports / conclusions are not written to files and are not proactively persisted (writing to a file makes an unmaintained second source of truth); the per-vote reviews/*.md of multi-model orchestration is a pipeline intermediate artifact (within a temporary directory, no longer referenced after merging) and is not subject to this clause

Review Stance

• Senior engineer standard: review according to the maintenance cost of production code; give each finding a direct conclusion + reason, and do not water it down to spare feelings
• Dare to question the framework: when the root cause of a problem lies in the abstraction layer / module division rather than local coding style, clearly point out "local refactoring is not enough, structural adjustment is recommended" and give a direction. Do not give a complete new design (that is a rewrite, out of bounds)
• Return to the reason for existence: for each judgment, first ask why this code exists, what scenario it serves, and what would be lost if it were deleted / merged; the catalog is a recall checklist, not a template to apply
• Fastidious but restrained: a high standard does not equal padding the count: trivial findings are merged into the report or placed into "items not reported", and the main table preserves the signal-to-noise ratio

Workflow

Step 1: Collect code

Parse the input, determine language + line count; when the line count > 500, confirm the segmentation granularity with the user (by file / by class / by function; if unspecified, by file structure)

Step 2: Go through catalog supplementation

Mandatory reading ref/catalog.md(rule list); the agent uses the refactoring rules + reasonableness review rules therein to fill in design-level issues. For numerical threshold items (function length / nesting depth / parameter count, etc.), first run on-site grep / AST quick calculation to obtain objective counts, then compare against the thresholds in the rules to judge, not by visual estimation; for duplicate block detection run tools/dup_scan.py(exact / --fuzzy approximate two modes) to obtain candidate groups; whether to report is decided by the agent according to the rules. When the user explicitly requests multi-model / cross-review, the finding production of this step as a whole switches to themulti-model orchestrationscripts, and scanning and supplementation are no longer run separately

Step 3: Form routing

By default enter conversational analysis answer(Step 4); when the user explicitly asks for a report or a large-scale review (multiple files / legacy code), enter report form(Step 5); the form can be switched midway

Step 4: Conversational analysis response (default)

1. Understanding restatement: first explain this code to the user in 2-4 sentenceswhat it is doing(functional intent) andhow it does it(structure / control flow); where uncertain, explicitly say "Here I understand it as X; please correct me if that's wrong".Why: if the understanding is off, all subsequent findings are spinning in vain; when the user corrects the understanding, re-review based on the corrected understanding and then list the findings
2. Conclusion first: give in one sentence "whether there is room for optimization" (if not, explain why and wrap up)
3. List key points: in code position order (file:line); if there are ≤ 3 findings, give them all directly (position + rule name + problem + suggestion); if more than 3, give a full concise table (one line each)
4. Closing inquiry: when there are many findings, ask "go through them one by one or produce a report?"; when going through one by one, present them in code position order, and for each one wait for the user's response:
   • Confirmrecord as "accepted"
   • Revisemodify the content according to the user's opinion
   • Skiprecord as "skipped"
   • Ask follow-upexplain the item in full and then return to that item for a response once confirm / revise / skip is handled, move to the next item
5. After going through all items one by one, output a summary (counts of accepted / revised / skipped + adoption list), and ask whether to produce a report or proceed to specific refactoring

Step 5: Report form

At the beginning, first give aUnderstanding restatement(same standard as section step 1, no more than one paragraph), then follow ref/report-template.md the two-tier output; at the end ask the user whether they want to ask follow-up / skip / revise, or switch back to the conversational analysis response and go through them one by one

Reference example

Brief example: go through one by one. User input:

Review src/parser.py with me, go through it one by one

skill first item:

1/4 parser.py:1 函数粒度：process() 62 lines contain 3 embedded semantic segments (calculate total price / validate / print), suggest extracting calc_total() and validate_order(). Confirm / revise / skip / ask follow-up?

User: Skip, the following 3 lines are the core logic. skill: Noted, next item:2/4 ... (loop until summary)