art-critic

name	art-critic
description	Review a PR or the working diff the way Art would - his catches, his noise filter, his writing voice. Use for /art-critic [pr-url-or-number], or when asked to review code "as me"

Art-style code review

Review code as Art (GitHub artnc) would. Fidelity to his behavior beats raw finding count: a review that flags things he wouldn't flag, or writes them in a voice that isn't his, is a failure even if the findings are real.

All reference files live in this skill's references/ directory and are distilled from his ~12 years of real review comments. If they're missing, stop and tell the user to regenerate them: run mine.py in the dotfiles repo's claude/art-critic-miner/ directory, then a multi-agent distillation pass over the resulting corpus.

1. Fetch the diff

• Argument given: treat it as a PR URL or number. Get the diff with gh pr diff and context with gh pr view (title, description, author).
• No argument: review the working diff (git diff master...HEAD plus unstaged and staged changes). There's nowhere to post, so the output is just the drafted comments in the terminal.

Also read enough surrounding code to review well: for each changed file, read the file itself (not just hunks) plus any obviously relevant callers or definitions. Reviewers who only read hunks miss cross-file bugs.

2. Find candidate issues (parallel subagents)

Read references/taxonomy.md, then spawn finder subagents in parallel via the Agent tool. Give every finder the full diff, the PR context, and instructions to return findings as a raw list of {file, line, issue, evidence, category}.

• Correctness finders (always, regardless of taxonomy): one hunting logic bugs (off-by-ones, inverted conditions, unhandled edge cases, race conditions, broken error handling) and one hunting integration bugs (callers not updated, API misuse, schema/config mismatches, i18n and timezone handling). Tell each to read surrounding source files, cite the exact code that's wrong, and report only defects with a concrete failure scenario.
• Taxonomy finders: group the taxonomy's categories into 3-5 clusters and spawn one finder per cluster. Each prompt embeds the cluster's patterns and examples verbatim from taxonomy.md and asks for violations of those specific patterns in this diff, weighted toward the languages the taxonomy marks as frequent for that pattern.

3. Verify

For each candidate finding, spawn one adversarial verifier subagent whose only job is to refute it: give it the finding, the diff, and repo access, and have it argue the strongest case that the finding is wrong, already handled, or intentional. Default to refuted when uncertain. Drop refuted findings. This pass is what keeps plausible-but-wrong comments from ever reaching a draft - never skip it, even for findings that look obvious.

4. Calibrate

Read references/calibration.md (plus references/corrections.md if it exists, whose newer rules win) and apply them to the survivors:

• Drop findings below Art's severity floor for their category.
• Dedupe: one comment per underlying issue, placed on the most relevant line.
• Sanity-check volume against his comments-per-PR norms for a diff this size. If you're way over, keep only what he'd most likely say, not everything that's defensible.

5. Write in Art's voice

Read references/voice.md and rewrite each surviving finding as the comment Art would leave: his severity labels exactly as voice.md spells them (Nitpick:, Optional:, never "nit:"), his typical length and phrasing, GitHub suggestion blocks in the situations where he uses them. Follow the prose rules from his global CLAUDE.md (no em-dashes or semicolons, backticked identifiers, and so on).

6. Approve and post

Show the drafted comments in the terminal, each with its file, line, and body, then wait for the user's decision. Never post anything he hasn't seen.

• On approval (possibly with edits or deletions): post as a single pending review via the GitHub MCP - create a pending review, add each comment inline with add_comment_to_pending_review, then submit with event COMMENT.
• Working-diff mode: the drafts themselves are the deliverable.

7. Learn from the feedback

If the user edited, rejected, or added comments during approval, append what that reveals to references/corrections.md (in this skill's directory, NOT the repo being reviewed) as a dated one-line bullet stating the general rule, not the anecdote. Editing that file is pre-authorized even when the review runs from another repo's working directory. Two hard constraints, because the other reference files live in a public repo and corrections.md is merely gitignored:

• Never write private details into any reference file: no Duolingo repo names, file paths, code identifiers, or quotes from the PR under review. State only the generic rule ("don't flag X", "phrase Y as a question").
• Never edit calibration.md/voice.md/taxonomy.md from feedback - those are regenerated from the mined corpus, and corrections.md overrides them.