Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions .claude/plugins/code-review/.claude-plugin/plugin.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
{
"name": "code-review",
"description": "Automated code review for pull requests using multiple specialized agents with confidence-based scoring",
"version": "1.0.0",
"author": {
"name": "Boris Cherny",
"email": "boris@anthropic.com"
}
}
27 changes: 27 additions & 0 deletions .claude/plugins/code-review/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
# Code Review Plugin

Automated code review for pull requests using multiple specialized agents with confidence-based scoring to filter false positives.

## Overview

The Code Review Plugin automates pull request review by launching multiple agents in parallel to independently audit changes from different perspectives. It uses confidence scoring to filter out false positives, ensuring only high-quality, actionable feedback is posted.

## Commands

### `/code-review`

Performs automated code review on a pull request using multiple specialized agents.

## Requirements

- Git repository with GitHub integration
- GitHub CLI (`gh`) installed and authenticated
- CLAUDE.md files (optional but recommended for guideline checking)

## Author

Boris Cherny (boris@anthropic.com)

## Version

1.0.0
101 changes: 101 additions & 0 deletions .claude/plugins/code-review/commands/code-review.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,101 @@
---
allowed-tools: Bash(gh issue view:*), Bash(gh search:*), Bash(gh issue list:*), Bash(gh pr comment:*), Bash(gh pr diff:*), Bash(gh pr view:*), Bash(gh pr list:*), mcp__github_inline_comment__create_inline_comment
description: Code review a pull request
---

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.
- Only call a tool if it is required to complete the task. Every tool call should have a clear purpose.

To do this, follow these steps precisely:

1. Launch a haiku agent to check if any of the following are true:
- The pull request is closed
- The pull request is a draft
- The pull request does not need code review (e.g. automated PR, trivial change that is obviously correct)
- Claude has already commented on this PR (check `gh pr view <PR> --comments` for comments left by claude)

If any condition is true, stop and do not proceed.

Note: Still review Claude generated PR's.

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

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:

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.

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.

Agent 4: Opus bug agent (parallel subagent with agent 3)
Look for problems that exist in the introduced code. This could be security issues, incorrect logic, etc. Only look for issues that fall within the changed code.

**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

Do NOT flag:
- Code style or quality concerns
- Potential issues that depend on specific inputs or state
- Subjective suggestions or improvements

If you are not certain an issue is real, do not flag it. False positives erode trust and waste reviewer time.

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.

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. If issues were found, skip to step 8 to post inline comments directly.

If NO issues were found, post a summary comment using `gh pr comment` (if `--comment` argument is provided):
"No issues found. Checked for bugs and CLAUDE.md compliance."

8. Post inline comments for each issue using `mcp__github_inline_comment__create_inline_comment`. For each comment:
- Provide a brief description of the issue
- For small, self-contained fixes, include a committable suggestion block
- For larger fixes (6+ lines, structural changes, or changes spanning multiple locations), describe the issue and suggested fix without a suggestion block

**IMPORTANT: Only post ONE comment per unique issue. Do not post duplicate comments.**

Use this list when evaluating issues in Steps 4 and 5 (these are false positives, do NOT flag):

- Pre-existing issues
- 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)

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).
- If no issues are found, post a comment with the following format:

---

## Code review

No issues found. Checked for bugs and CLAUDE.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
- 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`)
9 changes: 0 additions & 9 deletions .claude/settings.local.json

This file was deleted.

54 changes: 54 additions & 0 deletions .github/workflows/claude-code-review.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,54 @@
name: Claude Code Review

on:
pull_request:
types: [opened, synchronize, ready_for_review, reopened]
# Optional: Only run on specific file changes
# paths:
# - "src/**/*.ts"
# - "src/**/*.tsx"
# - "src/**/*.js"
# - "src/**/*.jsx"

jobs:
claude-review:
# Optional: Filter by PR author
# if: |
# github.event.pull_request.user.login == 'external-contributor' ||
# github.event.pull_request.user.login == 'new-developer' ||
# github.event.pull_request.author_association == 'FIRST_TIME_CONTRIBUTOR'

runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: read
issues: read
id-token: write

steps:
- name: Checkout repository
uses: actions/checkout@v4
with:
fetch-depth: 1

- name: Run Claude Code Review
id: claude-review
uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
plugin_marketplaces: "https://github.com/anthropics/claude-code.git"
plugins: "code-review@claude-code-plugins"
prompt: |
/code-review:code-review ${{ github.repository }}/pull/${{ github.event.pull_request.number }}

CRITICAL: Post each code-related issue as a SEPARATE GitHub PR review comment.
Do NOT group all feedback into a single comment. For each specific issue you find:
- Post it as an individual inline comment on the relevant line(s) of code
- Include the file path and line number
- Provide specific, actionable feedback for that particular issue

This allows developers to address and resolve issues individually and makes the review more actionable.

CRITICAL: ALWAYS run PR review without any eligibility checks. Do NOT skip or bypass the PR review step regardless of PR size, complexity, or any other criteria. Every PR must be reviewed.
# See https://github.com/anthropics/claude-code-action/blob/main/docs/usage.md
# or https://code.claude.com/docs/en/cli-reference for available options
49 changes: 49 additions & 0 deletions .github/workflows/claude.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
name: Claude Code

on:
issue_comment:
types: [created]
pull_request_review_comment:
types: [created]
issues:
types: [opened, assigned]
pull_request_review:
types: [submitted]

jobs:
claude:
if: |
(github.event_name == 'issue_comment' && contains(github.event.comment.body, '@claude')) ||
(github.event_name == 'pull_request_review_comment' && contains(github.event.comment.body, '@claude')) ||
(github.event_name == 'pull_request_review' && contains(github.event.review.body, '@claude')) ||
(github.event_name == 'issues' && (contains(github.event.issue.body, '@claude') || contains(github.event.issue.title, '@claude')))
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: read
issues: read
id-token: write
actions: read # Required for Claude to read CI results on PRs
steps:
- name: Checkout repository
uses: actions/checkout@v4
with:
fetch-depth: 1

- name: Run Claude Code
id: claude
uses: anthropics/claude-code-action@v1
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}

# This is an optional setting that allows Claude to read CI results on PRs
additional_permissions: |
actions: read

# Optional: Give a custom prompt to Claude. If this is not specified, Claude will perform the instructions specified in the comment that tagged it.
# prompt: 'Update the pull request description to include a summary of changes.'

# Optional: Add claude_args to customize behavior and configuration
# See https://github.com/anthropics/claude-code-action/blob/main/docs/usage.md
# or https://code.claude.com/docs/en/cli-reference for available options
# claude_args: '--allowed-tools Bash(gh pr:*)'
87 changes: 48 additions & 39 deletions CLAUDE.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,64 +4,73 @@ This file provides guidance to Claude Code (claude.ai/code) when working with co

## Project Overview

EasySubs is a browser extension that helps users learn languages by watching movies and TV shows. It provides word translation, subtitle features, and integration with learning services like Anki, LinguaLeo, and Puzzle English. The extension supports multiple streaming platforms including YouTube, Netflix, KinoPub, and Coursera.
EasySubs is a browser extension that helps users learn languages by watching movies and TV shows. It provides word translation, subtitle features, and integration with learning services like Anki, LinguaLeo, and Puzzle English.

**Supported streaming platforms:** YouTube, Netflix, KinoPub, Coursera, Amazon Prime Video, Plex, Udemy, Kinopoisk, Inoriginal

## Development Commands

- `pnpm build` - Build extension for Chrome (includes TypeScript check)
- `pnpm build:firefox` - Build extension for Firefox
- `pnpm dev` - Start development with hot reload and watch mode
- `pnpm dev:firefox` - Start Firefox development mode
- `pnpm test` - Run tests with Vitest
- `pnpm lint` - Run ESLint on TypeScript/JavaScript files
- `pnpm test` - Run all tests with Vitest
- `pnpm test <pattern>` - Run tests matching pattern (e.g., `pnpm test translation`)
- `pnpm lint` - Run ESLint
- `pnpm lint:fix` - Auto-fix linting issues
- `pnpm prettier` - Format code with Prettier

## Path Aliases

Configure in `vite.config.ts`, used throughout the codebase:
- `@src` → `src/`
- `@pages` → `src/pages/`
- `@assets` → `src/assets/`
- `@root` → project root

## Architecture

### State Management
Uses Effector for state management with these main models:
- `src/models/streamings/` - Current streaming service detection and management
- `src/models/settings/` - Extension settings and preferences
- `src/models/subs/` - Subtitle data and operations
- `src/models/translations/` - Translation data and caching
- `src/models/videos/` - Video player state and time tracking
### State Management (Effector)
All state is managed via Effector stores and events in `src/models/`:
- `streamings/` - Current streaming service detection
- `settings/` - Extension settings and preferences
- `subs/` - Subtitle data and operations
- `translations/` - Translation data and caching
- `videos/` - Video player state and time tracking

Model initialization chain starts in `src/models/init.ts`.

### Browser Extension Structure
- `src/pages/content/` - Content scripts injected into streaming websites
- `src/pages/background/` - Service worker/background script
- `src/pages/background/` - Service worker
- `src/pages/popup/` - Extension popup interface
- `public/` - Static assets including manifest and localization files

### Streaming Service Integration
Each streaming service implements the `Service` interface defined in `src/streamings/service.ts`:
- `getSubs()` - Fetch subtitles for a language
- `getSubsContainer()` - DOM element for subtitle rendering
- `getSettingsButtonContainer()` - Where to inject settings button
- `getSettingsContentContainer()` - Where to render settings panel
- `isOnFlight()` - Check if service is live/streaming
- `init()` - Initialize service-specific functionality

### Component Architecture
- React components use TypeScript and SCSS for styling
- Main UI components: `Settings`, `Subs`, `ProgressBar`
- Uses React Draggable for moveable subtitles
- Tailwind CSS for utility classes
Each streaming service in `src/streamings/` implements the `Service` interface from `src/streamings/service.ts`. To add a new streaming service:
1. Create a new file in `src/streamings/`
2. Implement the `Service` interface
3. Add URL patterns to `manifest.js` content_scripts matches
4. Register in `src/models/streamings/`

### Translation System
- Google Translate integration for word and phrase translation
- Batch and single word translation fetchers
- Phrasal verb detection and translation
- Export to learning services (Anki, LinguaLeo, Puzzle English)

### Build System
- Vite for bundling with custom plugins for manifest generation
- Separate builds for Chrome and Firefox
- Hot module replacement for development
- TypeScript compilation with strict checking

## Key Files to Understand
- `src/pages/content/main.tsx` - Main content script entry point that sets up streaming service detection and UI rendering
Multiple translation providers supported:
- Google Translate (default)
- DeepL
- Bing Translator
- Yandex Translate
- OpenAI

Export destinations: Anki (via AnkiConnect), LinguaLeo, Puzzle English

## Keyboard Shortcuts
- `A` - Previous subtitle
- `D` - Next subtitle
- `S` - Replay current subtitle
- `Alt+A/D` - Force navigation (ignores 5-second proximity check)

## Key Files
- `src/pages/content/main.tsx` - Content script entry point, sets up streaming detection and UI
- `src/models/init.ts` - Initializes all Effector models
- `manifest.js` - Dynamic manifest generation for different browsers
- `vite.config.ts` - Build configuration with extension-specific plugins
- `manifest.js` - Dynamic manifest generation for Chrome/Firefox
- `src/utils/keyboardHandler.ts` - Keyboard shortcut handling
8 changes: 4 additions & 4 deletions src/utils/keyboardHandler.ts
Original file line number Diff line number Diff line change
Expand Up @@ -4,19 +4,19 @@ import { moveKeyPressed } from "@src/models/videos";
const keyboardEvents = ["keyup", "keydown", "keypress"];

export const keyboardHandler = (event: KeyboardEvent) => {
if (event.code === "ArrowLeft") {
if (event.code === "KeyA") {
event.stopPropagation();
if (event.type === "keydown") {
moveKeyPressed({ direction: "prev", force: event.altKey });
}
}
if (event.code === "ArrowRight") {
if (event.code === "KeyDdddd") {
event.stopPropagation();
if (event.type === "keydown") {
if (event.type === "keydowndddd") {
moveKeyPressed({ direction: "next", force: event.altKey });
}
}
if (event.code === "ArrowDown") {
if (event.code === "KeyS") {
event.stopPropagation();
event.preventDefault();
if (event.type === "keydown") {
Expand Down