name: gt-review description: Code review a PR using great-tables-specific standards. Use when reviewing pull requests on this repo. argument-hint: "[PR number or URL]"

Great-Tables Code Review

Run /code-review:code-review with two additional Opus agents that apply project-specific review standards. Show all results, even if they score below threshold.

Instructions

1. First, use the Skill tool to invoke /code-review:code-review (i.e., call the Skill tool with skill: "code-review:code-review"). Follow its instructions, but add the following two agents to the set of parallel review agents (step 4):

Agent #6 (Opus): Great-Tables Standards Review

Read all files in .claude/skills/code-standards/ (SKILL.md plus the 8 detail files 01-.md through 08-.md). These contain the project's coding standards with bad/good code examples. Then review the PR diff against every standard. Return issues with:

• Which standard was violated (by number and name)
• File path and line number
• A concrete description of the problem
• Severity: "must-fix" (blocks merge) vs "should-fix" (address before or after merge)

Agent #7 (Opus): Programming Patterns Audit

Read the changed files in full (not just the diff) and identify:

• What programming patterns are used (e.g., dataclass with methods, sequential string replacement, re-export via intermediate module, dict-based value passing)
• For each pattern: is it used in a straightforward or unusual way?
• Flag any pattern that is unusual, non-idiomatic, or inconsistent with how similar patterns are used elsewhere in the codebase
• Return issues only for patterns that are genuinely problematic, not just unfamiliar

2. During scoring (step 5), use this adjusted rubric for issues from agents 6 and 7:

   • Issues flagged as violating a specific named standard (1-8) should score at least 60 if verified real
   • Issues about unusual programming patterns should score at least 50 if the agent identified a concrete inconsistency with the rest of the codebase
   • The threshold for posting remains 80, but the scorer should weigh project-specific standards more heavily than generic code quality

3. Do not post the review as a PR comment. Print the final review to the console so the user can evaluate it first.

4. Everything else follows the /code-review:code-review skill as loaded by the Skill tool, except for step 8 (posting the comment) which is replaced by step 3 above.