Menú
Review a set of changes (the staged diff, or a branch's diff) for correctness — before committing, pushing, or as a standalone pass
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
| name | change-review |
| description | Review a set of changes (the staged diff, or a branch's diff) for correctness — before committing, pushing, or as a standalone pass |
Review the change on its own merits. No session context assumed — the diff has to stand by itself.
git diff --staged), or a branch diff (git diff <base>...HEAD), plus git status for new files the change depends on. Review only what's in the change set.issue), not a pass.bug/issue block; nit/question don't.Pass, fail, or N/A — <reason>. No blanks.
dbg!, stray println!, .only, commented-out code)**[type]** summary
detail
bug — breaks at runtime. Blocks.issue — wrong but won't crash (missing test, edge case, leak). Blocks.nit — non-blocking.question — answer before proceeding.Weight unhappy paths. The happy path probably works — the author just wrote it. Find where it falls apart: regressions, edge cases, error paths, concurrency, rollback safety, interface changes without migration, silent reverts, debug/WIP code sneaking in.
Style a formatter/linter already enforces. "I'd do it differently." Re-running a check a pipeline already passed for this revision. Anything outside the change under review.
Author and maintain PseudoScript (.pds) — C4-level architecture-as-code that compiles to diagrams and a doc site — as the single source of truth for spec-driven development. Use this skill whenever the user wants to model an application in PseudoScript, reverse-map / capture an existing app or codebase into a .pds model, drive development from a model (write the spec first, implement from it), capture business rules as code while keeping infrastructure (repositories, HTTP/controllers, persistence, queues, external APIs) as black boxes, write Gherkin-style `feature` behaviour specs, or reconstitute / generate a real implementation from a model. Trigger it on mentions of PseudoScript, `.pds`, "architecture as code", "C4 as code", "model the system", "spec-driven", "turn this app/codebase into pseudocode", or "what does the model say it should do" — even if the user doesn't name the language explicitly.
Multi-agent clean code audit — each principle gets its own agent
Find the unhappy paths an existing Cucumber/BDD suite doesn't cover and write them up as new Gherkin scenarios in the feature files. Use whenever the user wants to harden, stress, or find gaps in Cucumber tests, .feature files, or Gherkin scenarios, or mentions a "chaos monkey", negative testing, edge cases, failure modes, or unhappy paths. Trigger even on a casual "think of ways to break this" or "what are we not testing?" about a BDD codebase.
Write idiomatic, ownership-clean Rust. ALWAYS use this skill when writing or editing Rust — any .rs file, anything under crates/, Cargo.toml/Cargo manifests, or when the user asks to add a function, type, trait, test, or module in Rust. Grounds the model in established Rust idioms: error handling, ownership/borrowing, iterators, the type system, API design, and the clippy/rustfmt baseline. Trigger even when the user doesn't say "idiomatic" — any Rust authoring task qualifies.
Use before every git push — mandatory quality gate, no exceptions
Pick highest-scored clean-code TODO, fix it, stop. Loop handles repetition.