ai-code-review
Review AI-authored code for its characteristic failure modes — plausible-but-wrong logic, hallucinated APIs, over-engineering, dead scaffolding, and silent security shortcuts. Use when reviewing an AI-generated or heavily AI-assisted PR, when AI-written code keeps shipping subtle bugs, or when setting review standards for a team using coding agents. Produces a focused review with AI-specific findings, verification steps per risk class, and a team checklist for AI-authored changes. For general PR review use code-review-checklist — this skill covers what that one assumes a human wouldn't do.
git clone --depth 1 https://github.com/mohitagw15856/pm-claude-skills /tmp/ai-code-review && cp -r /tmp/ai-code-review/exports/openclaw/ai-code-review ~/.claude/skills/ai-code-reviewSKILL.md
# AI Code Review Skill
Human code fails where the human got tired or didn't know; AI code fails where *plausibility diverged from correctness* — and it fails fluently, with confident naming, clean formatting, and tests that pass without testing anything. Reviewing it with human-code instincts ("looks careful, probably is careful") is how the new bug class ships. This skill reviews for the failure modes that are characteristically AI.
## What This Skill Produces
- A **review of the change** organised by AI-characteristic risk, each finding with file/line and severity
- **Verification steps** the reviewer must actually run (not read) per risk class
- A **team checklist** for AI-authored PRs, calibrated to this codebase
## Required Inputs
Ask for (if not already provided):
- **The diff or PR** (or the files changed)
- **Provenance honestly**: fully agent-written, human-piloted, or mixed — and whether the *author reviewed it themselves* before requesting review
- **The codebase context**: existing conventions/utilities the AI may not have known, and what the change claims to do
- **Test infrastructure**: what CI actually runs (the AI may have written tests CI never executes)
## The AI-Characteristic Failure Modes
Review in this order — most damaging first:
1. **Plausible-but-wrong logic.** The code reads correctly and does something subtly different: inverted edge conditions, off-by-one on boundaries the prompt never mentioned, the right algorithm for a slightly different problem. *Verification: trace 2-3 concrete inputs through the changed logic by hand — the fluency of the code is not evidence; it's the camouflage.*
2. **Hallucinated or misused APIs.** Methods that don't exist in this version, config keys from a different library, plausible-sounding parameters silently ignored. *Verification: for every external API call touched, check the actual dependency version's docs — not memory, not the AI's comment.*
3. **Tests that test nothing.** Asserting mocks return what they were mocked to return; happy-path-only suites with confident names; tests copied from the implementation (tautological). *Verification: mentally break the implementation — would any test fail? If not, the coverage number is decoration.*
4. **Reinvention and drift.** A new utility duplicating an existing one (the AI didn't know your `utils/`), a new pattern where the codebase has a convention, a second source of truth. *Verification: for each new helper/abstraction, grep for the existing equivalent.*
5. **Over-engineering as default.** Speculative generality: interfaces with one implementer, config for things that never vary, error hierarchies for a script. AI pads scope because scope was ambiguous. *Finding, not felony — but it's yours to maintain forever.*
6. **Dead scaffolding.** Unused imports/variables, TODO stubs presented as done, commented-out alternatives, leftover debug logging. Cheap to catch, and its *presence predicts* the deeper failures — a diff with scaffolding wasn't self-reviewed.
7. **Silent security shortcuts.** Broad exception swallowing, disabled TLS verification "for now", string-built SQL, secrets in examples that became code, permissive CORS. AI reproduces the internet's average security posture unless told otherwise. *Verification: run the security linters even for a "trivial" change; the shortcut is rarely where the feature is.*
## Output Format
### AI Code Review: [PR/change] — provenance: [stated]
**Verdict:** ✅ approve / 🟡 approve with required fixes / 🔴 request changes — [one line]
**Findings**
| # | Failure mode | Location | Severity | Finding + fix |
|---|---|---|---|---|
**Verified by running:** [the hand-traces, API checks, and break-the-test exercises actually performed — a review that only read the diff says so]
**Debt accepted knowingly:** [over-engineering/style items merged anyway, listed so they're chosen]
**Team checklist for AI-authored PRs:** [the 7 modes as a calibrated checklist + the house rule: AI-assisted PRs declare provenance, and the author self-reviews before requesting review]
## Quality Checks
- [ ] At least one concrete input was hand-traced through the changed logic
- [ ] Every touched external API was verified against the actual dependency version
- [ ] Each test was assessed by "what breakage would this catch?"
- [ ] New helpers were grepped against existing utilities
- [ ] The verdict distinguishes required fixes from accepted debt
## Anti-Patterns
- [ ] Do not extend human-code trust heuristics ("clean and well-named, so probably correct") — fluency is the failure mode's costume
- [ ] Do not approve on green CI without checking whether the tests can fail
- [ ] Do not review the description instead of the diff — AI PR descriptions are confident summaries of intent, not of behaviour
- [ ] Do not reject code *for being* AI-written — review the code; provenance calibrates scrutiny, not verdicts
- [ ] Do not skip security linting because the change is small — the shortcut hides in the periphery
- [ ] Do not accept "the agent tested it" as verification — demand the evidence in the PRConduct a structured ethical review of an AI or ML feature, model, or product. Use when preparing to deploy an AI system, assessing algorithmic risk, auditing a model for bias, or producing a responsible AI impact assessment. Produces a structured ethics review covering fairness, transparency, privacy, safety, accountability, and societal impact with a risk tier score, pre-deployment checklist, and prioritised mitigations.
Structure AI and ML product decisions with the rigour of any product decision. Use when building AI-powered features, evaluating LLM integrations, designing AI products, or assessing AI readiness. Produces a complete AI product canvas covering problem definition, model approach, data requirements, evaluation framework, UX design, responsible AI checklist, and launch monitoring plan.
Transform feature briefs into structured design briefs that give designers the context they need before opening Figma. Use when asked to write a design brief, create a design handoff, brief a designer on a new feature, or translate a PRD into design requirements. Produces a brief with user goal, emotional context, success criteria, constraints, edge cases, and out-of-scope boundaries.
Design statistically rigorous A/B tests and interpret experiment results. Use when asked to design an experiment, run an A/B test, calculate sample size, interpret test results, or assess whether an experiment was successful. Produces a complete experiment design with hypothesis, sample size, run time, success criteria, and risk flags — or a results interpretation with ship/iterate/kill recommendation.
Synthesises user signals from multiple research sources into a unified, weighted insight brief. Use when you have data from interviews, support tickets, NPS verbatims, app reviews, or sales calls and need to reconcile contradictions, surface the underlying need behind requests, or answer 'what are users really telling us'. Produces ranked insights with confidence ratings, source weighting rationale, divergent signal analysis by user segment, and a research gap identification section.
Structure a product data analysis, metric deep-dive, funnel analysis, or cohort study. Use when asked to analyse product metrics, investigate a drop in conversion, explain a data change to stakeholders, or find the root cause of a metric movement. Produces a structured analysis with question, root cause, confidence level, and recommended action.
Interpret product metrics against goals and surface actionable signals. Use when asked to analyse product health, review key metrics, investigate a performance issue, produce a health report, or assess product-market fit signals. Produces a structured health report with RAG status, trend analysis, root cause hypotheses, and prioritised actions.
Structure a retention analysis, churn investigation, or engagement deep-dive for any product team. Use when asked to analyse user retention, investigate churn, measure DAU/MAU, or build a retention improvement plan. Produces a retention snapshot with root cause hypotheses, aha-moment correlation, and prioritised interventions.