Module quality reviewer

Module Quality Reviewer

Use a two-pass workflow for reviewing a substantial feature or module without forcing the user to describe information that can be discovered from the repository.

Required input

Require only one of these:

• module or feature name;
• directory or file path;
• natural-language description of the feature.

Treat business goals, rules, constraints, documents, and known risks as optional context. Compare supplied intent with documentation, tests, and actual behavior rather than trusting any one source unconditionally.

If the repository is accessible, locate the module autonomously. Ask a question only when the repository is unavailable or the requested module cannot be identified after reasonable searching.

Select the review mode

Choose one mode from the user's request:

1. First pass — discovery and risk finding

   • Use by default for ordinary, comprehensive, or deep reviews when no prior report or finding set exists.
   • Read references/first-pass.md.
   • Produce a module map, evidence-backed findings, and a prioritized second-pass queue.

2. Second pass — high-risk verification

   • Use only when the user explicitly asks to verify, re-test, or follow up on prior findings or supplies a prior report or finding set.
   • Read references/deep-review.md.
   • Re-test the earlier conclusions; confirm, downgrade, reject, or escalate them and produce implementable remediation plans.

3. Both passes

   • Run both only when explicitly requested.
   • Complete the first pass before the second. Keep the first-pass findings as hypotheses until verified.

For the standard report structure, read references/report-format.md. For prompts usable outside ChatGPT Skills, read references/portable-prompts.md only when the user asks for Claude Code, Codex CLI, or a copyable prompt.

Non-negotiable behavior

• Start by mapping the module before judging it.
• Inspect necessary callers, callees, tests, configuration, data models, migrations, messages, external integrations, and documentation; do not review only the named file.
• Prioritize business correctness and runtime risk over style or lint observations.
• Adapt the review dimensions to the module; do not mechanically enumerate a generic checklist.
• Focus first on data corruption, authorization failures, incorrect business outcomes, concurrency and recovery defects, compatibility breaks, and defects hidden from current tests.
• Support findings with repository evidence: paths, symbols, line ranges when available, call paths, commands, test output, or minimal reproductions.
• Separate fact from inference. Label each finding with severity and confidence.
• Do not invent issues to fill a quota.
• Do not claim a test or check passed unless it actually ran successfully.
• State unexecuted checks and the uncertainty they leave.
• Group unresolved business or architecture questions in a dedicated section near the end instead of interrupting the review repeatedly.

Safety and modification policy

Default to read-only review:

• do not modify production code;
• do not create commits;
• do not mutate production data or resources;
• do not send real external requests;
• do not run destructive commands.

Safe compilation, static checks, local tests, and read-only repository inspection are allowed when available.

Read-only means no mutation of the target working tree, production resource, or external system. When a reproduction needs files, use an operating-system temporary directory or isolated copy outside the target working tree. Record the temporary location, clean it afterward, and verify that the target working tree is unchanged. Never add or edit a target-repository test without explicit authorization. If isolation cannot represent the suspected behavior, leave the check unexecuted and state the uncertainty.

Modify formal code only after explicit user authorization, and keep remediation separate from the review report.

Finding classification

Classify every material item on three independent axes.

Use these finding kinds:

• Defect: current behavior is proven incorrect.
• Risk: a plausible failure with material impact.
• Improvement: a worthwhile change without evidence of current incorrectness.
• Decision: a human choice or missing fact that changes the conclusion.

Use these severity levels:

• Blocker: unsafe to release; severe data, security, or core-business impact.
• High: important business, consistency, reliability, security, or compatibility failure.
• Medium: conditional defect or substantial maintainability and extension risk.
• Low: limited local impact.

Use these confidence levels:

• Confirmed: proven by code, tests, tool output, or an explicit rule.
• Highly likely: strong evidence but missing some runtime or business context.
• Needs confirmation: depends on an unresolved requirement, deployment fact, or product decision.

When responding in Chinese, translate kind, severity, and confidence labels while preserving their meanings.