chore(claude): reformat code review command

Author: boneskull

.claude/commands/code-review.md

@@ -3,9 +3,12 @@ allowed-tools: Bash(gh issue view:*), Bash(gh search:*), Bash(gh issue list:*),
 description: Code review a pull request
 ---
 
+# Code Review Command
+
 Provide a code review for the given pull request.
 
 **Agent assumptions (applies to all agents and subagents):**
+
 - All tools are functional and will work without error. Do not test tools or make exploratory calls. Make sure this is clear to every subagent that is launched.
 - Only call a tool if it is required to complete the task. Every tool call should have a clear purpose.
 
@@ -19,18 +22,19 @@ To do this, follow these steps precisely:
 
    If any condition is true, stop and do not proceed.
 
-Note: Still review Claude generated PR's.
+   > [!NOTE]
+   > Review Claude-generated PR's, too.
 
-2. Launch a haiku agent to return a list of file paths (not their contents) for all relevant CLAUDE.md files including:
-   - The root CLAUDE.md file, if it exists
-   - Any CLAUDE.md files in directories containing files modified by the pull request
+2. Launch a haiku agent to return a list of file paths (not their contents) for all relevant `CLAUDE.md`/`AGENTS.md` files including:
+   - The root `CLAUDE.md`/`AGENTS.md` file, if it exists
+   - Any `CLAUDE.md`/`AGENTS.md` files in directories containing files modified by the pull request
 
 3. Launch a sonnet agent to view the pull request and return a summary of the changes
 
-4. Launch 4 agents in parallel to independently review the changes. Each agent should return the list of issues, where each issue includes a description and the reason it was flagged (e.g. "CLAUDE.md adherence", "bug"). The agents should do the following:
+4. Launch 4 agents in parallel to independently review the changes. Each agent should return the list of issues, where each issue includes a description and the reason it was flagged (e.g. "`CLAUDE.md`/`AGENTS.md` adherence", "bug"). The agents should do the following:
 
-   Agents 1 + 2: CLAUDE.md compliance sonnet agents
-   Audit changes for CLAUDE.md compliance in parallel. Note: When evaluating CLAUDE.md compliance for a file, you should only consider CLAUDE.md files that share a file path with the file or parents.
+   Agents 1 + 2: `CLAUDE.md`/`AGENTS.md` compliance sonnet agents
+   Audit changes for `CLAUDE.md`/`AGENTS.md` compliance in parallel. Note: When evaluating `CLAUDE.md`/`AGENTS.md` compliance for a file, you should only consider `CLAUDE.md`/`AGENTS.md` files that share a file path with the file or parents.
 
    Agent 3: Opus bug agent (parallel subagent with agent 4)
    Scan for obvious bugs. Focus only on the diff itself without reading extra context. Flag only significant bugs; ignore nitpicks and likely false positives. Do not flag issues that you cannot validate without looking at context outside of the git diff.
@@ -41,7 +45,7 @@ Note: Still review Claude generated PR's.
    **CRITICAL: We only want HIGH SIGNAL issues.** Flag issues where:
    - The code will fail to compile or parse (syntax errors, type errors, missing imports, unresolved references)
    - The code will definitely produce wrong results regardless of inputs (clear logic errors)
-   - Clear, unambiguous CLAUDE.md violations where you can quote the exact rule being broken
+   - Clear, unambiguous `CLAUDE.md`/`AGENTS.md` violations where you can quote the exact rule being broken
 
    Do NOT flag:
    - Code style or quality concerns
@@ -52,13 +56,13 @@ Note: Still review Claude generated PR's.
 
    In addition to the above, each subagent should be told the PR title and description. This will help provide context regarding the author's intent.
 
-5. For each issue found in the previous step by agents 3 and 4, launch parallel subagents to validate the issue. These subagents should get the PR title and description along with a description of the issue. The agent's job is to review the issue to validate that the stated issue is truly an issue with high confidence. For example, if an issue such as "variable is not defined" was flagged, the subagent's job would be to validate that is actually true in the code. Another example would be CLAUDE.md issues. The agent should validate that the CLAUDE.md rule that was violated is scoped for this file and is actually violated. Use Opus subagents for bugs and logic issues, and sonnet agents for CLAUDE.md violations.
+5. For each issue found in the previous step by agents 3 and 4, launch parallel subagents to validate the issue. These subagents should get the PR title and description along with a description of the issue. The agent's job is to review the issue to validate that the stated issue is truly an issue with high confidence. For example, if an issue such as "variable is not defined" was flagged, the subagent's job would be to validate that is actually true in the code. Another example would be `CLAUDE.md`/`AGENTS.md` issues. The agent should validate that the `CLAUDE.md`/`AGENTS.md` rule that was violated is scoped for this file and is actually violated. Use Opus subagents for bugs and logic issues, and sonnet agents for `CLAUDE.md`/`AGENTS.md` violations.
 
 6. Filter out any issues that were not validated in step 5. This step will give us our list of high signal issues for our review.
 
 7. Output a summary of the review findings to the terminal:
    - If issues were found, list each issue with a brief description.
-   - If no issues were found, state: "No issues found. Checked for bugs and CLAUDE.md compliance."
+   - If no issues were found, state: "No issues found. Checked for bugs and `CLAUDE.md`/`AGENTS.md` compliance."
 
    If `--comment` argument was NOT provided, stop here. Do not post any GitHub comments.
 
@@ -82,28 +86,28 @@ Use this list when evaluating issues in Steps 4 and 5 (these are false positives
 - Something that appears to be a bug but is actually correct
 - Pedantic nitpicks that a senior engineer would not flag
 - Issues that a linter will catch (do not run the linter to verify)
-- General code quality concerns (e.g., lack of test coverage, general security issues) unless explicitly required in CLAUDE.md
-- Issues mentioned in CLAUDE.md but explicitly silenced in the code (e.g., via a lint ignore comment)
+- General code quality concerns (e.g., lack of test coverage, general security issues) unless explicitly required in `CLAUDE.md`/`AGENTS.md`
+- Issues mentioned in `CLAUDE.md`/`AGENTS.md` but explicitly silenced in the code (e.g., via a lint ignore comment)
 
 Notes:
 
 - Use gh CLI to interact with GitHub (e.g., fetch pull requests, create comments). Do not use web fetch.
 - Create a todo list before starting.
-- You must cite and link each issue in inline comments (e.g., if referring to a CLAUDE.md, include a link to it).
+- You must cite and link each issue in inline comments (e.g., if referring to a `CLAUDE.md`/`AGENTS.md`, include a link to it).
 - If no issues are found and `--comment` argument is provided, post a comment with the following format:
 
 ---
 
 ## Code review
 
-No issues found. Checked for bugs and CLAUDE.md compliance.
+No issues found. Checked for bugs and `CLAUDE.md`/`AGENTS.md` compliance.
 
 ---
 
 - When linking to code in inline comments, follow the following format precisely, otherwise the Markdown preview won't render correctly: https://github.com/anthropics/claude-code/blob/c21d3c10bc8e898b7ac1a2d745bdc9bc4e423afe/package.json#L10-L15
   - Requires full git sha
   - You must provide the full sha. Commands like `https://github.com/owner/repo/blob/$(git rev-parse HEAD)/foo/bar` will not work, since your comment will be directly rendered in Markdown.
   - Repo name must match the repo you're code reviewing
-  - # sign after the file name
+  - `#` symbol after the file name
   - Line range format is L[start]-L[end]
   - Provide at least 1 line of context before and after, centered on the line you are commenting about (eg. if you are commenting about lines 5-6, you should link to `L4-7`)