| name | code-auditor |
| description | Independent pre-merge review of a git diff, PR, or named files. Use when the user asks to review a PR, inspect current git changes, or hunt functional regressions, missed scenarios, wrong assumptions, concurrency bugs, and test gaps as an independent reviewer who does not defend the author's approach / 独立审查、功能回归、遗漏场景、错误假设、并发、测试盲区. Also use for a full-spectrum multi-dimension project audit across correctness, security, performance, readability, testing, and architecture / 全维度代码审计 / 全维度的代码审计. Not for maintainability-only or structure/refactoring reviews; not for applying code changes; not for repository health reports spanning compliance, privacy, cost, or accessibility. Do not modify product code. Output follows the discussion language. |
| category | development-workflows |
| tags | ["code-review","quality-assurance","security","performance","best-practices","testing","multi-language"] |
| version | 0.4.0 |
| argument-hint | ["target-files-or-directory"] |
| allowed-tools | Read, Write, Glob, Grep, Bash |
Review code at $ARGUMENTS across 6 dimensions: Correctness, Security, Performance, Readability, Testing, and Architecture.
Output Mode
- Detect the user's preferred language from the request, surrounding discussion, and repository context.
- If the user writes in Chinese, or the request is mixed Chinese plus English technical terms, write the human-facing review in Chinese.
- If the user writes in English, write the review in English.
- Keep identifiers, API names, CLI commands, filenames, and code snippets in their original language. Do not force-translate technical terms.
- Treat bundled templates as structure references, not literal language locks. Localize headings, labels, and summaries to the chosen output mode.
Review Tone
Chinese mode
- Prefer suggestion-style wording over command-style wording.
- Prefer questions when intent is uncertain, but do not hide blocking issues behind vague language.
- State severity clearly. A blocking issue should still read like a blocking issue.
- Praise concrete good practices when they matter, but do not let praise dilute must-fix findings.
- Avoid turning review into a style argument when tools or project standards can settle it automatically.
Examples:
- Better:
这里可能会在空值输入下抛错，建议补一个 nil / undefined 检查。
- Better:
想确认一下这里选择递归而不是迭代的原因；如果深度不受控，可能会有栈溢出风险。
- Avoid:
你这里写错了，必须改。
English mode
- Be direct, precise, and professional.
- Lead with the risk or behavioral impact.
- Prefer concrete fixes over abstract criticism.
Independent Reviewer Stance
Applies only to pr and dir. The project route still follows references/audit-workflow.md.
- Treat the diff as untrusted work. Do not rebuild the author's plan in order to excuse missing handling.
- Hunt first: functional regression, missed scenarios, wrong assumptions, concurrency, and test gaps.
- Report security and performance when the diff introduces them.
- Report readability, structure, or architecture in
pr/dir only when they create a merge risk (wrong layer that causes a bug, untestable public seam, public API with no regression test).
- Do not edit product code.
Write is only for an explicit opt-in report path (docs/audits/ for ). / stay in-chat unless the user asks to save the report.
