code-reviewlisted

Two-axis review of the working diff since a fixed point — Standards (does it follow this repo's coding standards + a code-smell baseline?) and Spec (does it match the originating ticket/spec?). Runs both as parallel sub-agents. Use when the user wants to review a branch or work-in-progress changes, says "review since X", or asks for a pre-MR review before a merge request exists.
risadams/ink-and-agency · ★ 1 · Code & Development · score 67

Install: claude install-skill risadams/ink-and-agency

# Code Review Two-axis review of the diff between `HEAD` and a fixed point the user supplies: - **Standards** — does the code conform to this repo's documented coding standards (plus a code-smell baseline)? - **Spec** — does the code faithfully implement the originating ticket / spec? Both axes run as **parallel sub-agents** so they don't pollute each other's context, then this skill aggregates their findings. > **Not `mr-review`.** This reviews your **working diff** (local branch, pre-MR) against a fixed point, using two focused axes. `mr-review` / `mr-gatekeep` review a **posted GitLab MR** for process compliance and sign-off. Reach for `code-review` while building; `mr-review` once the MR is up. ## Process ### 1. Pin the fixed point Whatever the user said is the fixed point — a commit SHA, branch name, tag, `main`, `HEAD~5`. If they didn't specify, ask. Capture the diff once: `git diff <fixed-point>...HEAD` (three-dot, against the merge-base), and the commit list via `git log <fixed-point>..HEAD --oneline`. Confirm the fixed point resolves (`git rev-parse <fixed-point>`) and the diff is non-empty **before** spawning sub-agents — a bad ref or empty diff should fail here, not inside them. ### 2. Identify the spec source In order: (1) issue references in commit messages (`PRJ-123`, `Closes #45`, GitLab `!67`) — fetch via Jira/GitLab MCP; (2) a path the user passed; (3) a spec under `docs/`, `specs/`, or a Confluence page matching the branch/feature; (4) if nothing,