SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillscode-review

code-review

Testing & quality

View repository

Updated 10-16 01:34

About this skill

Code Review (Chinese Version)

English version: See the corresponding English skill.

When to Use

  • You need to review a PR / Diff / commit to intercept logic, security, financial loss, and maintainability risks before merge.
  • You need a review report ranked by P0/P1/P2 with locations and actionable fix suggestions.
  • You need to supplement, from a QA / engineering quality perspective, risk points not covered by the developer's self-review.

Execution Flow

  1. Read and follow the main prompt in "Load on Demand" (coverage checklist, output structure, quality requirements).
  2. Before starting the review, confirm both: an identifiable code version, and the corresponding reviewable changes; if either is missing, output a blocked result and request the exact materials.
  3. Only supplement project context that genuinely affects the result: change scope, business goals, tech stack, upstream/downstream dependencies, known risks, team conventions.
  4. Optional role reports serve only as supplementary context with sources; product and UI/UX reports are used only when this change involves their areas of concern.
  5. Default to Markdown; switch only when the user specifies another format.

Core Constraints

  • Risk-driven: prioritize production incidents, financial loss, security, and core maintainability; do not produce noise checklists about naming/indentation.
  • Evidence-oriented: each finding should provide, as far as possible, the file path, line number, or code snippet, and explain the trigger path and consequences.
  • Dual threshold: there must be both an identifiable code version (e.g., repository + PR / commit / branch / tag / revision number) and reviewable changes (e.g., Diff / Patch, changed file contents, or an accessible base→head range). Code identity, change contents, and role reports cannot substitute for one another.
  • When either threshold is missing, explicitly output status: blocked, distinguishing missing_code_identity from missing_reviewable_change; do not claim the review is complete, give merge recommendations, or fabricate code findings.
  • Role reports are optional inputs; when using their content, retain source_role. Product reports only supplement business rules, state flows, or acceptance semantics; UI/UX reports only supplement interface states, feedback, responsiveness, or accessibility concerns; do not treat role opinions as code facts.
  • Strict grading: P0 blocks merge, P1 should be fixed in this iteration, P2 can be included in technical debt.
  • Write "confirmed facts" and "current assumptions" separately; do not fabricate interfaces, fields, environments, or root causes not provided by the user.
  • Focus on the issue, not the person; respect the existing tech stack, and do not demand framework changes or overturn the architecture without authorization.
  • Results must be actionable: each issue has a fix direction or before/after examples.

Load on Demand

  • Before producing output, you must read and follow prompts/code-review.md(minimum coverage checklist, output structure, quality requirements).
  • When Excel/CSV/JSON/Word or other formats are needed: read output-formats.md, and output according to the user's format requirements.
  • When a ready-made template is needed: read the matching template in output-templates/ , and do not invent a conflicting structure.
  • When review dimensions need refinement or grading details are needed: read references/review-dimensions.md。
  • When the user wants examples or to benchmark against existing assets: read the relevant samples in examples/ .
  • When format conversion or auxiliary validation is needed: prefer using scripts/ already contains a script, rather than rewriting it.
  • When the user only wants the shortest onboarding path: read quick-start.md。
  • When you need to evaluate/regress this skill: use evals/, and validate and run it with skill-up.

Self-check before delivery

  • Has followed the output structure of the main prompt
  • Has confirmed the two thresholds of code identity and reviewable changes; if blocked, no completed-state review or merge recommendation was output
  • Minimum coverage concerns: change summary, overall risk rating, P0/P1/P2 list, testability and observability, API/contract compatibility, fix priority, remaining risks and assumptions... (details are subject to the main prompt)
  • Has covered the minimum checklist, or indicated why it was omitted
  • High-risk items have clear P0/P1 classification and rationale
  • Did not fabricate details not provided by the user
  • Assumptions and information gaps have been indicated

Common pitfalls

  • Do not treat code snippets or role reports as a code version, and do not treat a PR / commit number as a provided diff; if either of the two thresholds is missing, block.
  • Do not automatically enable its concerns just because a product or UI/UX report exists; first determine whether this change is relevant, and retain the source.
  • Do not write all items as equally important, or pile up low-value style-related opinions.
  • Do not skip assumptions and information gaps.
  • Do not force refactoring of existing logic that is not within the scope of this change.
  • Do not output large sections of vague theory unrelated to the current change.