cli-audit-review

Optimization: This skill uses on-demand loading. Read only the reference files relevant to the target, except references/scoring.md, which is mandatory for every scored review.

Language rule: By default, write user-facing reviews in French when the prompt or repository context is French. Keep code identifiers, file paths, module names, commit types, and product names unchanged. Use English only when the user asks for it or when the project is clearly English-only.

Privacy rule: Never mention the training corpus, reviewer identity, personal names, e-mails, private/internal URLs, organization names, project names, commit hashes, issue/MR IDs, or raw examples from the corpus. The skill must behave as a neutral review methodology.

Audit Review — Review Methodology Index (RMI)

Use this skill when the user asks for a MR/PR/diff review, scored reviewer gate, strict infrastructure or automation review, Ansible review, CI/release review, idempotence audit, Molecule proof review, or convention compliance review.

Do not use it for generic code quality, code smell, clean-code compliance, or tech debt audits. Use cli-audit-code for that. For a shell-only quality audit, use cli-audit-shell. For pipeline design or optimization rather than review gate feedback, use cli-forge-pipeline.

The goal is not to produce generic lint feedback. The goal is to review like a strict production reviewer: contract first, validation before execution, idempotence, proof, documentation, release safety, then style.

Core Principles

1. Intent first — understand the MR/PR description, linked issue, changed behavior, and review scope before reading line-level diffs.
2. Evidence first — every actionable finding needs file:line, or repo-wide/diff-wide when no single line owns the issue.
3. Contract chain — public behavior must propagate through: contract -> validation -> implementation -> proof -> docs/CI/release.
4. Desired state over actions — for infrastructure and Ansible, prefer modeling the final state rather than introducing imperative action flags.
5. Fail fast — bad configuration must be rejected before packages, services, filesystems, clusters, remote APIs, or credentials are touched.
6. Idempotence is mandatory — repeated execution must converge cleanly; commands/shell tasks need explicit state/change/failure controls.
7. Secrets are toxic by default — tokens, passwords, keys, credentials, and sensitive command output must be contained in logs, templates, CI variables, artifacts, and errors.
8. Proof is part of the change — deployable behavior needs Molecule, CI, integration tests, idempotence checks, or equivalent proof.
9. CI/release is production code — pipelines, semantic-release, packaging metadata, branch rules, tokens, and artifacts are reviewed as runtime behavior.
10. Recent conventions win — when conventions conflict, apply references/conflict-resolution.md and prefer the newest relevant pattern unless it is less safe.
11. Risk beats cosmetic style — do not spend review budget on whitespace while contract, proof, idempotence, or security is broken.
12. Approve improvement, not perfection — block regressions and unproven risk; mark polish as non-blocking when code health is improving.
13. Smallest useful correction — ask for the minimal change that closes the risk. Avoid rewrite requests unless the design is unsafe.
14. Positive signal matters — include what is good: clear propagation, good assertions, maintained docs, useful tests, safe release handling.