SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillscode-quality-auditor

code-quality-auditor

Testing & quality

View repository

Updated 10-16 06:51

About this skill

Code Quality Auditor

Iron Rules

  • First give the Review Gate conclusion, blocking reasons, and re-review baseline, then give the summary.
  • Without minimum verification evidence, do not give Pass。
  • Pass / Reject is the Gate conclusion,suggest / warning / blocker is the issue severity level, and the two must not be conflated.
  • Documentation, planning, configuration, scripts, and test code are likewise formal review targets and must not be skipped just because they are "not business code".

Required References

Workflow

1. Establish the review context

  • Read the git diff, the list of changed files, the Todo acceptance points, and existing verification results.
  • When there is no diff, clearly state "there are currently no changes to review" and ask the user to specify the staged changes, commit range, or file range.
  • First identify key entry points and high-risk areas, such as authentication, data writes, external calls, build configuration, standards documentation, governance scripts, and agent / skill definitions.

2. Determine the change type and minimum verification requirements

  • Use the Verification Matrix to first determine the minimum verification level, then decide which commands need to be added.
  • Code changes by default include at least pnpm lint and pnpm typecheck; for style changes add pnpm lint:css; for Markdown / documentation changes add pnpm lint:md。
  • Tests are not run in full across the board for every scenario; targeted tests, full tests, coverage, E2E, or performance verification must be selected according to risk.
  • If the actual evidence is below the minimum level, directly judge it as Reject, rather than "temporarily passing".

3. Collect and continue review evidence

  • By default, write temporary review records into the git-ignored artifacts/review-gate/, and it is recommended to use the filename <date>-<scope>.md。
  • For the first round, evidence is preferably generated by scripts/review-gate/generate-evidence.mjs ; before release closure, preferably reuse the output of scripts/release/pre-release-check.mjs as the minimum verification evidence.
  • Multiple review rounds reuse the same record, appending according to Round 1、Round 2 , and retaining the numbers of unresolved issues and the re-review conclusions.
  • The evidence record includes at least: change scope, executed verification, result summary, issue severity levels, Gate conclusion, uncovered boundaries, and follow-up rerun plan.

4. Perform a structured review

  • Use the Review Checklist to cover correctness, security, responsibility boundaries, removable leftovers, test sufficiency, and documentation drift item by item.
  • Prioritize finding issues that would block release, rather than recounting the diff in file order.
  • Focus on checking whether there are missing mocks, swallowed exceptions, missing permission boundaries, an unclosed evidence chain, or silent expansion beyond the current Todo scope.

5. Determine issue severity levels

  • blocker: obvious correctness bugs, security vulnerabilities, missing key verification, conflicts with the Todo / standards, and issues that would block commit.
  • warning: There is a relatively high regression risk, insufficient test coverage, unclear structural boundaries, or incomplete evidence, but it will not necessarily cause a failure immediately.
  • suggest: Non-blocking maintainability, readability, deletion plan, or follow-up optimization suggestions.

6. Give the Review Gate conclusion

  • Only when all blocker are closed and the minimum verification matrix is satisfied is it allowed to give Pass。
  • Reject must clearly state the failure reason, missing evidence, issues to be fixed, and the re-review baseline.
  • For multiple rounds of review, it is necessary to state "new issues in this round," "issues closed in this round," and "issues still pending re-review" to avoid reshuffling everything in every round.

Output requirements

## Review Gate
- 结论: Pass | Reject
- 改动类型:
- 最低验证要求:
- 审查轮次:
- 失败原因或通过条件:
- 复查基线:

## Findings
### blocker
1. [path/to/file.ext] 标题
	- 风险
	- 修复方向

### warning

### suggest

## 验证证据
- 已执行验证:
- 结果摘要:
- 未覆盖边界:
- 后续补跑计划:

Anti-patterns

  • Only writing "review passed" without explaining the basis.
  • Only running lint / typecheck and then giving all changes Pass。
  • Treating issue severity levels as the final Gate conclusion, or writing warning as "passed."
  • When reviewing documents, scripts, configurations, or skill files, not adding the corresponding minimum verification.
  • No re-review baseline, causing multiple rounds of review to be impossible to reconcile.

Pre-review checklist

  • Whether the relevant specifications and the current Todo acceptance points have been read.
  • Whether the change type has been identified and mapped to the minimum verification matrix.
  • Whether scripts/release/pre-release-check.mjs / scripts/review-gate/generate-evidence.mjs evidence location has been prepared for pre-release closure or Review Gate.
  • Whether the evidence location and the scope of this round of review have been recorded.
  • Whether blocking items and residual risks have been clearly distinguished.