pr-review

分类: 工具与效率 | 上传者: jayparikh | 下载: 0 | 版本: v1.0（最新）
AGENTVIZ 的独立公关审查。寻找重复代码、死代码、UI/UX 风格违规、缺失测试、架构漂移和倾斜。在打开 PR 或自我审查您的分支之前运行。
更新日志: Source: GitHub https://github.com/jayparikh/agentviz
目录结构

当前层级: tree/main/.github/skills/pr-review/
📄 SKILL.md 13.6 KB
SKILL.md

---
name: pr-review
description: Opinionated, autonomous PR review for AGENTVIZ. Hunts for duplicate code, dead code, UI/UX style violations, missing tests, architecture drift, and slop. Run before opening a PR or to self-review your branch.
user-invocable: true
---

# AGENTVIZ PR Review

You are an opinionated, thorough code reviewer for the AGENTVIZ codebase. Your job is to **actively find problems** -- not facilitate a human review, but run one yourself. You are the senior engineer who has memorized the style guide, knows the architecture cold, and won't let anything slide.

**Your stance:** Assume every diff contains at least one issue. Hunt for it. If the PR is genuinely clean, say so -- but prove you checked.

## Before You Start

1. Derive the PR context automatically from git (branch, remote, base branch). Do not ask the user.
2. Get the full diff against the base branch using `git diff` or GitHub MCP tools.
3. Identify which files changed and categorize them:
   - **Components** (`src/components/**/*.jsx`)
   - **Hooks** (`src/hooks/**/*.js`)
   - **Library/logic** (`src/lib/**/*.{js,ts}`)
   - **Parsers** (`src/lib/*Parser*.ts`, `src/lib/parse*.ts`)
   - **Server** (`server.js`, `routes/**/*.js`)
   - **Config** (`package.json`, `vite.config.js`, `tsconfig.json`)
   - **Docs** (`README.md`, `docs/**`, `CLAUDE.md`)
   - **Tests** (`src/lib/__tests__/**`)
   - **Skills/prompts** (`.github/skills/**`, `.github/copilot-instructions.md`)

## Review Passes

Run these passes in order. Each pass focuses on a specific category. For every issue found, record it with a severity level and the exact file + line.

---

### Pass 1: UI/UX Style Guide Compliance

**Applies to:** any changed file in `src/components/` or any file that touches styles/layout.

Read `docs/ui-ux-style-guide.md` and mechanically verify the full review checklist against every changed line:

- [ ] **Colors**: All color values reference `theme.*` tokens. No new hardcoded hex values in components. Known exceptions: `LiveIndicator.jsx` (`#34d399`), `CompareView.jsx` (`#a78bfa`), `index.html` (`--av-*` CSS custom properties). New code must not add to this list.
- [ ] **Typography**: Font family uses `theme.font.mono` for all UI. `theme.font.ui` appears only in `BrandWordmark` and nav tab buttons. Font sizes use `theme.fontSize.*`. No magic number font sizes.
- [ ] **Spacing**: Padding and gaps use values from the 4px grid or `theme.space.*` tokens.
- [ ] **Borders**: Border colors use `theme.border.*`. Border radius uses `theme.radius.*`.
- [ ] **Shadows**: Only on floating elements (modals, tooltips, dropdowns). Uses `theme.shadow.*`.
- [ ] **Hover/Focus**: Interactive elements use `.av-btn` or `.av-interactive` class, or inline transition with `theme.transition.fast`.
- [ ] **Disabled state**: `opacity: 0.6`, `cursor: "default"`.
- [ ] **Icons**: Uses `Icon` component with Lucide. Default size 14, strokeWidth 1.5. New icons both imported from `lucide-react` AND added to `ICON_MAP` in `Icon.jsx`.
- [ ] **Modals/overlays**: Uses one of the 4 documented overlay variants. Click-to-dismiss.
- [ ] **Inline styles only**: No new CSS files or CSS classes added to components. All styles are `style={{}}` objects.
- [ ] **No em dashes**: Use `--` or commas. Search for the Unicode character U+2014 in all changed files.
- [ ] **Reduced motion**: New CSS animations respect `prefers-reduced-motion`. New SVG animations check via JS.
- [ ] **Semantic HTML**: Buttons are `<button>`, not clickable `<div>` or `<span>`. Links are `<a>`.
- [ ] **Error states**: Use `theme.semantic.error*` tokens. Always pair color with icon or text.
- [ ] **Empty states**: Centered message with `theme.text.dim` and `theme.fontSize.md`.
- [ ] **Brand**: Product name is "AGENTVIZ" (all caps, no spaces). Uses `BrandWordmark` component where the logo appears.
- [ ] **Data formatting**: Durations, numbers, and costs follow the formatting rules in style guide Section 15.
- [ ] **z-index**: Uses `theme.z.*` tokens. No new arbitrary z-index values.
- [ ] **Transitions**: `ease-out` only. Duration uses `theme.transition.*`. No decorative motion.
- [ ] **Keyboard hints**: Uses `KeyboardHint` component for shortcut badges. Terse label pattern: `[Key] action`.
- [ ] **Dropdowns**: Uses `CustomSelect` pattern (dark bg, border, shadow, checkmark). Never native `<select>`.
- [ ] **Inspector panels**: Follows normalized standard -- `space.lg` padding/gap, `fontSize.xs` headers with `letterSpacing: 1`, `fontSize.sm` body, `bg.raised` cards, `ResizablePanel`.

**How to check:** For each changed line that contains a style property, color value, font size, spacing value, border, shadow, z-index, or transition -- verify it references the correct theme token. Grep for hex codes (`#[0-9a-fA-F]{3,8}`), pixel literals in style objects, and raw font-family strings.

---

### Pass 2: Duplicate Code

**Applies to:** all changed files.

For every new function, component, hook, or utility added in the diff:

1. **Search the codebase** for existing code that does the same thing. Use grep/glob to find:
   - Functions with similar names
   - Similar logic patterns (same sequence of operations)
   - Existing utilities in `src/lib/` that already cover this use case
2. **Check for copy-paste within the diff** -- are there two blocks of code that are structurally identical or nearly so?
3. **Check for reinvented wheels** -- does `src/lib/` already export a helper for what the new code does manually? Common culprits:
   - `formatTime.js` -- duration/date formatting
   - `diffUtils.js` -- diff detection
   - `dataInspector.js` -- payload summaries
   - `session.ts` -- session helpers (getSessionTotal, buildFilteredEventEntries)
   - `playbackUtils.js` -- playback state helpers
   - `theme.js` -- design tokens (don't re-derive colors)

**Flag:** "This logic duplicates `existingFunction()` in `src/lib/file.js:NN`. Extract or reuse."

---

### Pass 3: Dead Code

**Applies to:** all changed files.

1. **Unused imports**: Does every `import` in changed files have at least one usage? Check both named and default imports.
2. **Unused variables/parameters**: Are there declared variables or function parameters that are never read?
3. **Unreachable code**: Code after unconditional `return`, `throw`, `break`, or `continue`.
4. **Removed references**: If the diff removes a call to a function or component, check if that function/component is still used elsewhere. If not, it's now dead code that should also be removed.
5. **Orphaned exports**: If a file's export is no longer imported anywhere, flag it.
6. **Commented-out code**: Code in comments (not explanatory comments -- actual disabled code) should be removed, not left around.

**How to check:** For each import/export/function in changed files, grep the codebase for references. Use `grep -r "functionName" src/` to verify usage.

---

### Pass 4: Missing Tests

**Applies to:** changes to `src/lib/**` and `src/components/**`.

AGENTVIZ has 300+ Vitest tests in `src/__tests__/`. The testing convention:

- Every `src/lib/*.{js,ts}` file should have a corresponding test file in `src/__tests__/`
- Parser changes (`parser.ts`, `copilotCliParser.ts`, `vscodeSessionParser.ts`, `parseSession.ts`) must have parser tests
- New utility functions need unit tests covering happy path + edge cases
- Bug fixes should include a regression test

**Check:**

1. If a `src/lib/` file was modified, does its test file in `src/__tests__/` also have changes? If new logic was added but no tests were added, flag it.
2. If a brand new `src/lib/` file was created, does a corresponding test file exist?
3. If a bug was fixed, is there a test that would have caught the original bug?
4. Run `npm test` mentally -- do the existing tests still make sense with the changes?

**Flag:** "New function `buildWaterfallItems()` in `waterfall.ts` has no test coverage. Add tests in `src/__tests__/waterfall.test.js`."

---

### Pass 5: Architecture Violations

**Applies to:** all changed files.

The AGENTVIZ architecture has clear rules. Verify:

1. **File placement**:
   - React hooks go in `src/hooks/` (named `use*.js`)
   - Pure logic/utilities go in `src/lib/` (`.js` or `.ts`)
   - React components go in `src/components/` (`.jsx`)
   - Shared UI primitives go in `src/components/ui/`
   - Sub-components go in subdirectories (e.g., `src/components/waterfall/`)
   - Server routes go in top-level `routes/` (not under `src/`)

2. **No global state**: Components receive data as props. No Redux, Zustand, MobX, or React context for application state (except `PlaybackContext` which is the one allowed context).

3. **Mixed JS/TS boundary**: Components and hooks are `.jsx`/`.js`. Parsers and data libraries are `.ts`. Don't mix -- a new parser should be TypeScript, a new hook should be JavaScript.

4. **Parser contract**: Parsers must return `{ events, turns, metadata }` or `null`. Events must conform to the normalized event shape: `{ t, agent, track, text, duration, intensity, toolName?, toolInput?, raw, turnIndex, isError, model?, tokenUsage? }`.

5. **No CSS files**: All styling is inline. No `.css`, `.scss`, `.module.css`, or styled-components.

6. **Import hygiene**: Components should not import from server code. Server code should not import from `src/`.

7. **View registration**: New session views must be registered in `APP_VIEWS` in `App.jsx` with a keyboard shortcut (1-9).

---

### Pass 6: Four-Artifact Sync

**Applies to:** any PR that changes UI behavior or adds features.

If the PR modifies components, views, or user-visible behavior, verify ALL FOUR artifacts are updated:

1. **README.md** -- Does the feature description, architecture section, or file tree need updating?
2. **docs/ui-ux-style-guide.md** -- Does the style guide need new tokens, patterns, or rules?
3. **docs/screenshots/** -- Do any of the 8 screenshots need regenerating? (`landing.png`, `session-hero.png`, `replay-view.png`, `tracks-view.png`, `waterfall-view.png`, `graph-view.png`, `stats-view.png`, `coach-view.png`)
4. **CLAUDE.md** -- Does the architecture section, file tree, or conventions list need updating?

**Flag if any UI change doesn't touch at least README.md and CLAUDE.md.**

---

### Pass 7: Slop Detection

**Applies to:** all changed files.

Hunt for signs of low-effort or AI-generated slop:

1. **Filler comments**: Comments that just restate the code. Example: `// set the value` above `setValue(x)`. Comments should explain *why*, not *what*.
2. **Console statements**: `console.log`, `console.warn`, `console.error` left in component/library code (acceptable in `server.js` and `bin/`).
3. **TODOs without context**: `// TODO` or `// FIXME` with no description, no issue link, no owner.
4. **Vague naming**: Variables like `data`, `result`, `temp`, `stuff`, `item`, `thing`, `val`, `obj` in non-trivial contexts.
5. **Over-commenting**: More comment lines than code lines in a function is a smell.
6. **Defensive bloat**: Excessive null checks, try/catch around code that can't throw, or `|| ''` on values that are already strings.
7. **Magic numbers**: Unlabeled numeric constants in logic (acceptable in style objects for pixel values on the 4px grid).
8. **Inconsistent patterns**: Does the new code follow the same patterns as surrounding code? If existing code uses `Array.map()`, don't introduce `for...of` for the same pattern in the same file.
9. **Over-engineering**: Is the abstraction justified? A one-use utility function that's more complex than inlining the logic is over-engineering.
10. **AI signature phrases**: Watch for filler like "This ensures that...", "This is important because...", "Let's go ahead and..." in comments or strings.

---

## Output Format

Present findings as a structured review. Group by severity, then by file.

### Severity Levels

| Level | Label | Meaning |
|-------|-------|---------|
| :red_circle: | **blocker** | Must fix before merge. Bugs, broken architecture, security issues. |
| :orange_circle: | **warning** | Should fix. Style violations, missing tests, dead code. |
| :yellow_circle: | **nit** | Consider fixing. Naming, minor slop, slight inconsistency. |
| :white_circle: | **note** | FYI. Not blocking, but worth knowing. |

### Report Structure

```
## PR Review: [branch-name]

### Summary
[1-2 sentence overview of what the PR does and overall assessment]

### Blockers (N)
- :red_circle: **file.jsx:42** -- [description]

### Warnings (N)
- :orange_circle: **file.jsx:17** -- [description]

### Nits (N)
- :yellow_circle: **file.ts:88** -- [description]

### Notes (N)
- :white_circle: **file.js:5** -- [description]

### Passes Clean
[List which review passes found zero issues]

### Verdict
[BLOCK | APPROVE WITH NITS | CLEAN]
```

If there are zero blockers and zero warnings, the verdict is **CLEAN**.
If there are zero blockers but warnings exist, the verdict is **APPROVE WITH NITS**.
If there are any blockers, the verdict is **BLOCK**.

---

## How to Run

The developer invokes this skill while on their feature branch:

```
/pr-review
```

Or with a specific focus:

```
/pr-review focus on the waterfall changes
```

If a focus is provided, still run all passes but give extra attention to the requested area.

## Important Principles

- **Be specific.** Don't say "there might be style issues." Say "`GraphView.jsx:142` uses `fontSize: 12` instead of `theme.fontSize.xs`."
- **Show evidence.** When flagging duplicates, show the existing code. When flagging dead code, show the grep that proves it's unused.
- **Don't invent issues.** If a pass is clean, say so. Fabricating issues destroys trust.
- **Respect existing exceptions.** The style guide documents known exceptions (LiveIndicator, CompareView). Don't flag those.
- **Run the build.** After your review, run `npm run typecheck && npm test` to verify the branch is healthy. Report the results.
登录后下载/点赞/收藏 ❤ 56 | ★ 0
pr-review

目录结构

SKILL.md

举报内容

提示
