SuperAPI AI Directory

review

General & other

View repository

Updated 10-16 02:32

About this skill

Review

Use /review as the canonical first-party review entrypoint. It covers code review, session diffs, scoped files, PRs, full audits, behavior-preserving simplification review, source/provenance review for external skills, specialist audit lenses, browser-grounded frontend/a11y/web-quality review, review history, delta reports, false-positive learnings, SARIF output, Conventional Comments output, and approval-gated fix passes.

honest-review, simplify, and external-skill-auditor are not separate skills. Their behavior lives here as /review, /review simplify, and /review source.

Default posture: read-only, evidence-first, and scoped. Do not perform feature work, broad rewrites, installs, or fixes until the user explicitly approves selected findings or invokes a mode that permits edits and passes its gates.

Canonical Vocabulary

Use these canonical terms exactly.

Term Meaning
review Evidence-first inspection of code, diffs, PRs, repositories, sources, or proposed simplifications
scope The exact files, directories, PR, git range, source, or snippet under review
triage First pass that classifies scope, risk, changed files, specialist lenses, and validation requirements
finding A discrete issue with citation, reasoning, severity, confidence, evidence, and recommended action
strength A positive review observation that explains what should be preserved
confidence Score from 0.0 to 1.0; report >= 0.7, mark 0.3-0.7 unconfirmed, discard < 0.3 unless P0/S0
severity Priority/scope classification such as P0-P3 and S0-S3
citation anchor A verified [file:start-end] source location or source/provenance anchor
reasoning chain Why the finding matters, written before the finding statement
evidence Tool, source, test, docs, grep, dependency, or research proof that supports or rejects a finding
lens Specialist perspective such as security, supply chain, CI, SQL, data, frontend, a11y, web quality, MCP, agentic, or docs
skill asset A SKILL.md, skill directory, skill eval, skill script, reference, package, catalog row, or generated skill doc reviewed through skill-creator structural patterns
simplification lens Behavior-preserving review of complexity, invariants, semantic-change risk, and clarity opportunities
source/provenance lens Review of external skill/source trust, executable surfaces, owner, license, credentials, network behavior, and dedupe
approval gate Mandatory pause before editing files or applying fixes
learning Stored false-positive dismissal used to reduce repeated noise in future reviews
mode Explicit or inferred review workflow such as session, scoped, PR, range, audit, simplify, source, history, delta, learnings, or fix
shard map Wave 0 ownership plan for large parallel reviews, with lane IDs, shard IDs, file/source ownership, coverage expectations, and merge status

Dispatch

Classify $ARGUMENTS before reading widely.

$ARGUMENTS Mode Action
`--mode session scoped pr
repeated --mode or comma-separated --mode scoped,source multi-mode Run read-only modes as separate lanes and merge through Judge
empty + changed files in git diff --name-only HEAD session Review changed files only
empty + no changed files menu Show review modes; never start a full audit implicitly
file or directory path scoped Review that path
audit full audit Review the repository through triage, specialist lanes, and judge reconciliation
PR number or PR URL PR Review PR diff and stated intent
git range such as HEAD~3..HEAD range Review changes in that range
simplify analyze <target> simplify analyze Read-only simplification opportunity review
simplify apply <target> simplify apply Behavior-preserving edit only after the simplification gate passes
simplify explain <target> simplify explain Explain complexity and safer simpler shapes without editing
source triage <source> source triage Classify external source reputation, install syntax, and dedupe risk
source inspect <path> source inspect Review local source files, hooks, scripts, frontmatter, and commands
source commands <path> source commands Extract and classify executable surfaces
source provenance <source> source provenance Check owner, URL, license, commit/hash, registry/source-list consistency, and access date
source decision <source-or-path> source decision Recommend install-now, inspect, keep-global, build-local, or avoid
source scan <path> source scan Run static source audit helper and interpret JSON output
`--lens security supply-chain ci
path under skills/<name>/, SKILL.md, evals/*.json, or skill catalog/research docs scoped + skill-assets Review as a skill asset using skill-creator structural patterns, portability, eval, package, and generated-surface gates
--format sarif output modifier Emit SARIF v2.1 findings in addition to or instead of text
--format conventional output modifier Emit Conventional Comments-compatible PR review output
history [project] history Read stored review history
diff [project] or delta [project] delta Compare current and previous stored reviews
`learnings add list check
fix <finding-ids> or apply approved findings fix pass Apply only explicitly approved findings through references/auto-fix-protocol.md
unrecognized or ambiguous clarify Ask one concise scope/mode question

Auto-Detection

  1. Parse explicit --mode flags first. Split comma-separated values and preserve repeated flags.
  2. If explicit modes are present, run only those modes. Infer the target when safe, but never infer edit approval.
  3. If no explicit mode is present, infer from args: empty changed diff -> session, empty clean tree -> menu, path -> scoped, PR number/URL -> PR, git range -> range, audit -> full audit, simplify -> simplification, source or external skill/source language -> source/provenance.
  4. When the selected scope is a skill asset, automatically attach the skill-assets lens unless the user explicitly asks for a different lens only.
  5. Multiple read-only modes run as separate lanes and reconcile through Judge.
  6. fix and simplify apply are edit-capable. Never run them from inference alone and never mix them into a read-only bundle without explicit approved finding IDs.
  7. --lens modifies the selected mode; it does not invent scope.
  8. --format modifies output only; it does not choose scope.
  9. Feature work, benchmarking, broad refactors, installs, or implementation requests without approved findings are out of scope.

Scope Boundaries

In scope: review findings, source/provenance decisions, simplification analysis, simplification explanations, narrowly gated simplification apply passes, stored review history, review deltas, false-positive learnings, and approved post-review fixes.

Out of scope: new features, product implementation, benchmark design, broad refactors, live external installs, destructive cleanup, exploit execution, unaudited source promotion, and unapproved fixes.

Classification Logic

  1. Decide whether the request is review, simplification, source/provenance, state/history, output formatting, or implementation.
  2. Reject implementation unless it is an approved finding fix or a simplify apply target that passes the eligibility gate.
  3. Reject source installs unless the user separately requests a live install after the source/provenance decision.
  4. For skill assets, require skill-creator structural evidence before accepting or rejecting a skill change: dispatch table, empty-args handler, reference index, critical rules, canonical vocabulary when needed, scope boundaries, progressive disclosure, script/eval/package proof, portability, and generated docs/catalog consistency.
  5. When two modes could apply, prefer the read-only mode first and ask one concise question only if the target or approval state is unclear.

Scaling Strategy

Size Strategy
Small One file, snippet, or narrow source: run a single reviewer pass with the full finding contract
Medium 2-5 related files: split by file ownership when safe and reconcile through judge protocol
Large PR, git range, or mixed module diff: triage first, then assign non-overlapping review lanes by risk
Full audit Create a Wave 0 shard map, assign risk-tiered non-overlapping lanes, run specialist lenses, and reconcile through Judge
Source/provenance bundle Split metadata, executable surfaces, credentials/network, license/provenance, and dedupe checks

Progressive Disclosure

Start with this file only. Load reference files after dispatch and only for the chosen mode or lens. Do not preload all references for small reviews.

Review Pipeline

  1. Triage: identify scope, changed files, public contracts, project instructions, dependency graph, risk tier, and specialist lenses.
  2. Shard: for large or multi-mode work, produce a Wave 0 shard map before spawning reviewers.
  3. Analyze: inspect code/source using content-adaptive reviewers. Keep ownership non-overlapping when parallelizing.
  4. Verify: check every non-trivial finding against source lines, tests, grep evidence, docs, or external research.
  5. Judge: normalize, assign canonical RV-* IDs, dedupe, resolve conflicts, apply confidence thresholds, rank by severity/confidence/blast radius, and preserve strengths.
  6. Report: present findings first, ordered by severity, with concise evidence and an approval gate.
  7. Fix pass: only after explicit approval of selected finding IDs, load references/auto-fix-protocol.md, preview diffs, apply narrowly, and verify.

Large Review Shards

For large or multi-mode reviews, every subagent must receive a lane ID, shard ID, exact scope, coverage expectations, non-goals, and artifact contract before dispatch.

Judge Handoff

Worker findings use local IDs only. The Judge assigns canonical RV-* IDs after all lane artifacts are normalized, deduped, confidence-filtered, and ranked.

Finding Contract

Every finding uses this order:

  1. Citation: verified [file:start-end], PR hunk, source URL, command output anchor, or provenance anchor.
  2. Reasoning: why this matters and what breaks if it is left alone.
  3. Finding: one concise statement of the issue.
  4. Severity and confidence: P0-P3/S0-S3 plus 0.0-1.0 confidence.
  5. Evidence: source/tool/research/test proof; include degraded-mode limits when tools are unavailable.
  6. Recommendation: smallest safe next step.

Use references/finding-contract.md for full schema and scoring.

Lens Contracts

Load references only when the selected mode needs them.

Need Read
finding schema and scoring references/finding-contract.md
triage/scaling references/triage-protocol.md
review checklists references/checklists.md
reviewer team prompts references/team-templates.md
creative review lenses references/review-lenses.md
research validation references/research-validation.md
judge reconciliation references/judge-protocol.md
self-verification references/self-verification.md
output variants references/output-formats.md
SARIF output references/sarif-output.md
Conventional Comments output references/conventional-comments.md
CI annotations and automation references/ci-integration.md
dependency graph and blast radius references/dependency-context.md
supply-chain security references/supply-chain-security.md
specialist lens map references/specialist-lenses.md
skill asset and skill-creator paradigms references/skill-asset-review.md
simplification lens references/simplification-lens.md
simplification taxonomy references/simplification-taxonomy.md
source/provenance lens references/source-provenance-lens.md
approval-gated fixes references/auto-fix-protocol.md
review state, history, delta, learnings references/review-state.md

Simplification Lens

/review simplify is behavior-preserving. It may identify or apply clarity improvements only when the target, unchanged invariants, validation basis, and scope boundaries are explicit.

  • analyze: read-only report.
  • explain: teaching/explanation only.
  • apply: edit only a concrete file/symbol/snippet or tightly bounded diff after the eligibility gate passes.

Reject semantic changes, bug fixes, API changes, validation changes, security-policy changes, performance-only work, or broad refactors under simplification mode.

Source/Provenance Lens

/review source is the trust gate for external skills and sources. Use source-list and read-only inspection before any install or promotion decision. Inspect hooks, scripts, command substitutions, allowed tools, package scripts, network calls, credential behavior, filesystem writes, provenance, license, owner, commit/hash, and dedupe against repo-owned skills.

Never run candidate scripts during audit except static/syntax checks in a staged local path. Do not install or sync external skills unless the user explicitly requests that live action.

Browser-Grounded Review

For frontend, a11y, web-quality, docs UI, and other browser-dependent review, prefer Chrome DevTools MCP through the repo-managed chrome-devtools MCPHub attached-browser configuration. Use browser snapshots, console/network evidence, and screenshots from Chrome DevTools MCP when available. If Chrome DevTools MCP is unavailable, state degraded mode before falling back to existing smoke tests or Playwright-oriented project checks.

Skill-Asset Review

When the scope is a skill asset, load references/skill-asset-review.md and apply skill-creator paradigms as review evidence. Use deterministic skill-creator scripts when available, but do not treat a high audit score as the whole review. Check whether the skill's structure, dispatch behavior, evals, references, scripts, package portability, public docs, and generated catalog surfaces match the intended behavior.

Skill-asset review is read-only unless the user invokes a valid fix pass or a separately approved implementation request. Do not run live installs, live behavioral evals, or sync apply while reviewing skill assets.

Harness Portability

This SKILL.md is portable and prompt-first. It deliberately omits a root model override and skill-scoped hooks.

Harness Behavior
Claude Code Uses portable skill metadata and argument hints. Skill hooks require separate validate_hooks.py and package proof before being added.
Codex Skill discovery and any hook behavior are projected through repo/plugin config such as config/hook-registry.json, not assumed from this file.
OpenCode Skill discovery comes from repo opencode.json and skill paths; models/plugins/overlays stay in OpenCode config.
Grok Build CLI Uses Claude-compatible skill mirroring and .grok/skills discovery where available.
Generic Skills CLI targets Core prompt must install cleanly through npx skills add and repo sync dry-runs.

State Management

Review history, deltas, and false-positive learnings persist in the active harness home directory, not in the repository.

  • Base path: ~/.{gemini|copilot|codex|claude}/reviews/ (harness-dependent; Claude Code defaults to .claude).
  • State file naming: {YYYY-MM-DD}-{project-slug}-{mode}[-{run_id}].json under the reviews directory.
  • Learnings: {reviews}/learnings/{project-slug}.json for false-positive dismissals.
  • Slug rule: lowercase project names with non-alphanumeric runs replaced by hyphens; empty slugs become unnamed.
  • Collision: same-day reruns use distinct run_id suffixes; saves do not silently overwrite prior review state files.
  • Operations: use scripts/review-store.py for save/load/list/diff and scripts/learnings-store.py for add/check/list/clear.
  • Read-only modes: history, delta, and learnings list never edit reviewed source files.
  • Cleanup: user-owned; no automatic pruning. Do not commit review JSON into the repo.
  • Details: load references/review-state.md for envelope fields, diff semantics, and harness path table.

Script Index

Script Purpose
scripts/check.py Run review skill validation, eval validation, package dry-run, and audit
scripts/project-scanner.py Triage project/file risk and review triggers
scripts/finding-formatter.py Normalize findings and output variants
scripts/review-store.py Store/load/list/diff review state
scripts/learnings-store.py Manage false-positive learnings
scripts/sarif-uploader.py Help emit/upload SARIF where supported
scripts/source-audit.py Static audit of local external skill/source directories

Critical Rules

  1. Never start a full audit from empty args unless the user says audit.
  2. Never edit files during read-only review, source/provenance review, history, delta, or simplify analyze/explain.
  3. Never apply fixes without explicit approval of selected findings.
  4. Never vendor third-party skill files into skills/ during source/provenance review.
  5. Always verify citation anchors before reporting findings.
  6. Always state degraded-mode limits when validation tools are unavailable.
  7. Always separate evidence from inference.
  8. Always preserve unrelated dirty work.
  9. Do not present honest-review, simplify, or external-skill-auditor as installable or invocable skills. Rewrite active references to /review, /review simplify, or /review source; leave only clearly historical or research evidence mentions.
  10. For skill assets, apply skill-creator paradigms before reporting a no-finding result: run or cite audit/package/eval evidence when available, inspect references and eval coverage, and classify generated docs/catalog drift separately from source defects.

Validation Contract

Before considering changes complete, run the focused checks relevant to this skill:

uv run python scripts/check.py

Completion criteria:

  1. scripts/check.py exits 0.
  2. Bundled validate_skill and validate_evals pass when evals are present.
  3. Bundled package.py --dry-run reports portable.
  4. Repo-only audit.py grade remains at or above the prior baseline when run from the monorepo (optional for portable installs; degraded mode is acceptable elsewhere).
  5. Regenerate docs/catalog surfaces when SKILL.md, references, or evals change.
  6. Any remaining legacy-name references are classified as wrappers, migration notes, generated evidence, or historical research.