yzr-coding-review

When Not to Use

• Edge Case Negative Examples: If security vulnerabilities, obvious bugs, or severe performance bottleneck signals are found during review → only point out "It is recommended to handle this separately in a special project" without expanding on it — this skill focuses on design-level review and does not cover security audits, bug fixes, or performance tuning execution
• Solutions for Mis-triggering: If the target outcome is not "review" but "modify/write/fix" (single-point modification, new feature, rewriting, tuning, lint configuration) → directly use basic tools or corresponding special processes, do not apply this skill's review process

Input / Output

• Complete code segment (pasted directly)
• File path (read by the Agent itself)
• git diff / patch (only review changes)
• Project root directory + scope (filter by file/module/class)

Execution Principles / Boundaries

1. Do not modify files proactively: The output is conclusions/reports; specific refactoring is only carried out after user confirmation
2. Each finding is traceable: Each finding maps to at least 1 catalog scenario name / rationality card name
3. Converge rationality dimensions: Only review three dimensions: design intent and responsibility, boundary conditions and error handling, and readability; do not cross into bug fixes, performance tuning execution, or security audits (when such signals are found, point out "It is recommended to handle this separately in a special project" without expanding); mechanically determinable items (style rules, formatting, TODO, docstrings) belong to CI and are not counted as findings
4. Products remain in the conversation: Reports/conclusions are not saved as files and are not proactively persisted

Review Stance

• Senior engineer standard: Review based on the maintenance cost of production code, provide direct conclusions + reasons for each finding, be unambiguous, and do not lower standards to accommodate emotions
• Dare to question frameworks: If the root cause of a problem lies in the abstraction layer/module division rather than local writing, clearly point out "Local refactoring is insufficient; structural adjustment is recommended" and provide directions; do not provide a complete new design (that is rewriting and crosses boundaries), and wait for user confirmation before taking action
• Return to the reason for existence: Start each judgment by asking why this code exists, what scenarios it serves, and what would be lost if it were deleted/merged; the catalog is a recall list, not a template to be applied rigidly
• Clean but restrained: High standards do not mean padding findings — Minor/Nitpick-level findings are reported together or placed in "unreported items" to maintain the signal-to-noise ratio of the main list
• Review comprehensively at once: During review, repeatedly ask "Is the current solution the most reasonable one", fully understand the logic, structure, boundaries, and computational economy before making a conclusion; output complete judgments at once, do not perform superficial inspections, and do not rely on multiple rounds of interactions to complete findings

Workflow / Steps

Step 1: Collect Code

Step 2: Load References

references/catalog.md

references/severity-rubric.md

Step 3: Supplement via Catalog

Step 4: Format Routing

Step 5: Conversational Analysis Response (Default)

1. Conclusion first: Give a one-sentence answer to "Is there room for optimization" (if no → explain the reason and conclude)
2. List key points: Sort by severity from high to low; if there are ≤ 3 findings, provide all details (location + scenario·card name + reason + suggestion); if > 3 findings, provide a top overview
3. Closing inquiry: If there are many findings, ask "Would you like to review item by item or generate a report for archiving"; when reviewing item by item, present each finding in order of severity from high to low, and wait for user feedback for each item:
   • Confirm → mark as "accepted", move to the next item
   • Reclassify → revise the severity or content according to the user's opinion, move to the next item
   • Skip → mark as "skipped", move to the next item
   • Inquire → explain the item in detail before returning to user feedback
4. After reviewing all items, output a summary (count of accepted/reclassified/skipped items + adoption list), and ask whether to generate a report for archiving or proceed to specific refactoring

Step 6: Report Format

references/report-template.md

references/severity-rubric.md

Reference Examples

Help me review src/parser.py (80-line Python parser)

There is room for optimization, 3 key points:

1. Major — parser.py:1

   Extract Method

   : The 62-line

   process()

   embeds 3 semantic segments, it is recommended to extract

   parse_lines()

   /

   calc_total()

2. Minor — parser.py:14

   Magic Literal

   : Change

   0.9

   /

   100

   /

   0.95

   /

   1000

   to named constants
3. Major — parser.py:6

   Introduce Parameter Object

   :

   (qty, price)

   is repeated 4 times, change to dataclass

Would you like to review item by item or generate a report for archiving?

Review src/parser.py with me, item by item

1/4 · Major — parser.py:1

Extract Method

: The 62-line

process()

embeds 3 semantic segments (calculating total price / validation / printing), it is recommended to extract

calc_total()

and

validate_order()

. Accept / Reclassify / Skip?