Code review

Skill yarlson/yarstack/plugins/yarstack/skills/code-review

Engineering workflows and standards for Codex and Claude Code: plan, implement, test, review, and deliver repository changes.

Install

npx -y skills add yarlson/yarstack --skill code-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Review a local diff or branch without modifying it. Use for general cross-cutting correctness, performance, compatibility, lifecycle, and maintainability findings; combine it with go-review for meaningful Go code and macos-swift-review for meaningful Swift or macOS app code.

SKILL.md

2.3 KB, as published. Nobody here has run it

Code Review

Own the general evidence-backed review of a confirmed comparison scope.

Workflow

Read applicable repository instructions, confirm the comparison target from the request, status, changed paths, and local refs, and identify the implementation languages in scope.
Stop or qualify the review when the scope cannot be isolated. Do not include unrelated recent commits.
Read full changed files and relevant callers, callees, tests, schemas, and configuration.
Check normal paths, boundaries, failures, partial state, cleanup, cancellation, ordering, compatibility, resource ownership, hot-path cost, and unnecessary complexity.
Use go-review whenever the scope contains meaningful Go production or test code, a Go package, or a full Go codebase. Use macos-swift-review whenever it contains meaningful Swift production or test code, a Swift package, an Xcode project, or a macOS Swift app. Use both for mixed scopes; skip them only when their language code is absent or the change is limited to documentation, metadata, or generated output. Use other specialists when material domain depth is required.
Run only trusted read-only checks that the user requested or that cheaply verify a suspected defect. Never execute arbitrary code introduced by an untrusted change.
Use crap-index-assess within those execution bounds when the review targets CRAP or the repository's configured CRAP check covers changed methods. Treat the result as a maintainability signal and apply the finding standard below.

Finding Standard

Report only findings with a concrete failure path and evidence. Include severity, verified file and line, affected behavior, failure path, smallest safe correction, and uncertainty. Rank by impact and group repeated instances. State directly when no actionable findings exist.

Do not expose sensitive values, invent findings, report style preferences as defects, or modify files. Leave GitHub thread handling to coderabbit-triage.