code-review

Files (1)

• SKILL.md

SKILL.md (first lines)

# Code Review

Read applicable repository instructions and domain documents. Read issue-tracker
configuration only when the review contract is tracked; an untracked direct
request uses its confirmed conversation as the contract and does not require
tracker setup. If required configuration is unavailable, follow
[setup-omskills](../setup-omskills/SKILL.md) and its scoped authorization gate
before review. A read-only reviewer returns the missing prerequisite to its
responsible caller instead of writing setup.

Review exactly one candidate in one of two modes:

- **Committed:** a fixed base commit through `HEAD`.
- **WIP:** the current staged, unstaged, and untracked worktree state.

Honor an explicit mode. Otherwise infer committed mode for a branch, PR, or
supplied fixed point and WIP mode for a worktree request. Ask only when both
remain plausible; never combine them into a partial hybrid.

Review against two separately reported criteria sets:

- **Standards:** applicable repository instructions and conventions,
  maintainability, and relevant code smells.
- **Spec:** the exact Ticket, accepted behavior, acceptance criteria, omissions,
  incorrect behavior, and changes outside scope.

## Adversarial review contract

Defend the project's interests, not the author's solution or the status quo.
Challenge decisions that compromise correctness, simplicity, or maintainability
against accepted requirements and evidence. The normal path is one review
followed by author corrections and verification: complete the investigation now
instead of relying on a later pass.

- Inspect every candidate path and contract requirement, reading surrounding
  context and tracing affected callers, consumers, tests, and governing sources
  wherever needed to establish correctness. Challenge assumptions, failure and
  boundary cases, regressions, omissions, and contradictory instructions that
  apply to this candidate; passing checks and author claims are evidence to
  examine, not substitutes for inspection.
- Challenge unnecessary complexity as part of Standards: premature abstractions,
  pass-through layers, speculative generality, extra configuration or dependencies,
  and redundant workflow steps. For each complexity finding, show the concrete
  maintenance, reasoning, testing, or operational cost and a substantially simpler
  alternative that preserves required behavior and constraints. Evaluate total
  complexity, including what callers must absorb; fewer lines or a personal
  preference alone is not evidence. Apply this to code and governing documents
  without turning candidate review into an unrelated redesign.
- Continue across the complete candidate after finding a blocker. Return every
  concrete, supported problem found, including non-blocking ones, without a
  finding quota or a top-findings cutoff. Consolidate duplicates only when all
  affected locations and distinct consequences remain explicit.
- State defects, impact, and severity directly, without sugar-coating, praise
  padding, or downgrading a finding to soften the verdict. Be adversarial toward
  the work, not the author. Evidence determines severity; inventing
  requirements, speculative defects, or stylistic preferences is not adversarial
  review.
- For every finding, identify Standards or Spec, severity/blocking status,
  file/line (or exact artifact section), the violated rule or expected behavior,
  supporting evidence, and consequence. Distinguish evidence gaps from confirmed
  defects. Report relevant discovered problems outside the authorized correction
  scope as findings without expanding the investigation into unrelated work.

The pass is complete only when every candidate path and applicable requirement
has been examined, unnecessary complexity has been assessed, and every supported
finding is reported. State coverage, including the simplification assessment,
and verification limitations explicitly; an unexamined required area makes the
review incomplete, not clean. A complete pass with no supported findings reports
that result without manufacturing faults or claiming proof of defect-free work.

## Prepare the complete candidate

### Committed mode

1. Use the fixed point supplied by the caller. If none was supplied, infer one
   and ask only when none can be established. Resolve review HEAD to a full SHA.
   For standalone committed review, resolve the base as the merge base of that
   fixed point and review HEAD, preserving the `fixed-point...HEAD` candidate.
   For coordinated review, use the supplied exact full base SHA and verify it is
   an ancestor of review HEAD.
2. In a coordinated Ticket review, verify the supplied candidate path, branch
   and exact HEAD before capture. Use that exclusive candidate, never an
   inherited caller checkout; do not create another workspace. Unexpected
   branch/HEAD drift stops review as incomplete.
3. Capture the complete `git diff <base-sha> <review-sha>` and
   `git log <base-sha>..<review-sha> --oneline` in that candidate. Check that
   its identity/HEAD remains unchanged after capture; report exact path, branch,
   base and review SHAs with any capture limitations.
4. If the diff is empty, stop and report that there are no committed changes to
   review.

### WIP mode

1. Capture staged changes with `git diff --cached`.
2. Capture unstaged changes with `git diff`.
3. Inventory every untracked path and capture its complete content or binary
   status without treating ignored files as candidate work.
4. Report every unreadable or unrepresentable path as a capture limitation. If
   all three parts are empty, stop and report that there is no WIP candidate.

For either mode, locate the current contract and every applicable repository
instruction, governing source, and standard. The contract may be a tracked
Ticket or Spec, or the concise confirmed request for untracked direct work. If
no governing contract exists, review Standards and observable correctness while
stating that contract compliance could not be verified.

## Select the caller-safe review path

This skill requires one isolated review pass; assigning a reviewer name does not
create isolation, read-only behavior, tools, or delivery semantics. Direct code
or behavior changes and changes to Specs, ADRs, workflow, security, or other
governing authority require this fresh independent pass. Purely editorial
documentation may instead be self-reviewed. Before using disposable notes or
transport files, read [Working files](../../productivity/WORKING-FILES.md);
read-only review protects the candidate, not the reviewer's own working files.

- An interactive responsible agent, including a Ticket owner, may use the active
  harness's documented asynchronous delivery or
  [tmux-worker](../../productivity/tmux-worker/SKILL.md) for a visible isolated

From luizomf/omskills, MIT.

More from luizomf/omskills