my-code-review

Files (1)

• SKILL.md

SKILL.md (first lines)

# Code Review

Do not edit files except for the review outputs described below.
Limit GitHub mutations to posting and superseding reviews and, when continuous
review is requested, resolving addressed threads. Follow repository instructions
before this skill.

## Required destination

**ALWAYS submit the review to GitHub.**
The review request itself authorizes posting.

1. Resolve the target before reviewing. Use the supplied PR number or URL;
   otherwise check the current branch's PR with `gh pr view`. A local checkout
   or worktree of a PR is still a PR review, not a local-only review. An API,
   authentication, or permission error is not evidence that no PR exists.
   Always fetch to make sure the branch is up to date before reviewing.
2. For a PR, submit a GitHub review even when there are no new findings or
   earlier findings remain unresolved. An unavailable independent check,
   blocked local validation, or missing session artifact is a verification
   gap to disclose, not a reason to keep the review local. Post the supported
   findings and disclose the gap; do not claim the review is complete or clean.
3. Posting is a required step before the final response or waiting for another
   push. Chat output, files, and session artifacts do not satisfy it. Verify
   the posted review and return its GitHub URL. If posting
   fails, report the exact error and state that the review was not posted; do
   not claim completion or silently continue monitoring.

For a branch with no PR, write the result to `review.md`. For other local diffs
and commits, report in chat. When the user explicitly requests a local-only PR
review, use their requested destination, or chat if none was specified.

## Scope

1. Resolve the base and review the complete diff. For a pull request, refresh
   the base ref before computing the merge base.
2. Read the request, linked issue, surrounding code, callers, and tests. Diff
   actual files; prose is not evidence.
3. Identify the intended behavior and review only introduced behavior, except
   pre-existing code made newly reachable or incorrect.

Report only high-confidence problems backed by evidence. For correctness, require
a trigger and observable impact. For necessity, placement, or approach, show the
unsupported premise, duplication, wrong ownership, or concrete maintenance cost. Ignore
style, naming, formatting, generic advice, and unrelated cleanup.

## Necessity and placement

First decide whether the change should exist and whether it belongs here.
A correct implementation does not by itself justify the change.

- Identify the concrete user problem and evidence that it exists. Distinguish
  the requested outcome from the proposed solution.
- Check whether existing behavior, configuration, or another supported workflow
  already meets the need.
- Trace the cause and ownership. Determine whether the fix belongs in this
  component, a caller, a dependency, or another layer instead of a local workaround.
- Weigh the user benefit against added scope, public surface, compatibility
  obligations, and maintenance cost. Challenge unsupported premises with evidence,
  not personal preference.

## Alternative approaches

Next compare ways to meet the same need before reviewing implementation details.
Do not assume the submitted approach is the right starting point.

- Look for existing helpers, patterns, APIs, and extension points before proposing
  new machinery. Consider removing or changing existing logic rather than adding
  another path.
- Compare the proposed solution with the simplest complete alternative. Consider
  correctness, compatibility, usability, performance, and long-term maintenance.
- Recommend a different approach only when a concrete benefit outweighs its
  costs. Explain the tradeoff and the smallest viable change; do not demand a
  speculative redesign or expand the goal.

## Required independent checks

Before the verdict, request both checks in parallel. Give each the full target,
base, intent, repository instructions, and known validation; do not split the
diff.

- Ask the `caarlos0` agent for a read-only maintainer check of necessity,
  solution placement, alternative approaches, correctness, scope, simplicity,
  usability, compatibility, public surface, and maintenance cost.
- Ask `anvil` in verify-only mode for an adversarial check of correctness, test
  coverage, determinism, performance evidence, and user-visible behavior.
  Verify that the feature or fix solves a real problem, especially when the
  change appears fully automated without human input.

These are leaf tasks: agents must not invoke `my-code-review`, request agents, edit,
or mutate GitHub. For code findings, require exact file/line, reachable scenario,
impact, evidence, smallest fix, and test. For design objections, require evidence,
the concrete cost or limitation, and a better alternative, including no change.
If either check cannot run, disclose it.

Agent reports are leads. Independently trace or reproduce each claim and resolve
disagreements with code, tests, logs, history, or specification.

## Correctness

- Trace data and control flow across changed boundaries.
- Check defaults, absent and explicit values, errors, cancellation, cleanup,
  reuse, persistence, serialization, concurrency, and platform paths.
- Check that success cannot hide failure or discarded output, and that errors
  cannot become false success.
- Verify automated findings independently; never act only to satisfy a bot.

## Test coverage

- Require a focused regression test for a bug fix and direct coverage of each
  changed contract. Prefer the lowest decisive test layer.
- Ensure tests exercise production behavior, not mocks, copied implementation,
  or helpers that cannot reproduce the bug.
- Where practical, prove the regression test fails without the fix.
- Cover material success, failure, boundary, default, and transition states, not
  speculative combinations.
- Keep decisive assertions near the behavior and print useful actual values or
  variants on failure.

From caarlos0/dotfiles, MIT.

More from caarlos0/dotfiles