code-review by nokonoko1203
Comprehensive code review combining PR review, self-review, and quality checks. Supports reviewing PRs by number or comparing branches.
Coding
77 Stars
12 Forks
Updated Jan 12, 2026, 03:17 PM
Why Use This
This skill provides specialized capabilities for nokonoko1203's codebase.
Use Cases
- Developing new features in the nokonoko1203 repository
- Refactoring existing code to follow nokonoko1203 standards
- Understanding and working with nokonoko1203's codebase structure
Install Guide
2 steps- 1
Skip this step if Ananke is already installed.
- 2
Skill Snapshot
Auto scan of skill assets. Informational only.
Valid SKILL.md
Checks against SKILL.md specification
Source & Community
Repository claude-code-settings
Skill Version
main
Community
77 12
Updated At Jan 12, 2026, 03:17 PM
Skill Stats
SKILL.md 366 Lines
Total Files 1
Total Size 0 B
License NOASSERTION
---
name: code-review
description: Comprehensive code review combining PR review, self-review, and quality checks. Supports reviewing PRs by number or comparing branches.
allowed-tools: TodoWrite, TodoRead, Read, Write, Edit, Grep, Glob, Bash(git:*), Bash(mkdir:*), Bash(gh pr view:*), Bash(gh pr diff:*), mcp__serena__find_file, mcp__serena__find_symbol, mcp__serena__find_referencing_symbols, mcp__serena__get_symbols_overview, mcp__serena__search_for_pattern, mcp__serena__list_memories
argument-hint: "pr <number> | base-branch"
user-invocable: true
---
## Code Review Skill
Comprehensive code review skill that combines PR review, self-review, and quality checks.
### Usage
```
/code-review # Self-review: current branch vs main
/code-review <branch> # Self-review: current branch vs specified branch
/code-review pr <number> # PR review: review the specified PR
```
The argument is available as `$ARGUMENTS`.
### Argument Parsing
```
$ARGUMENTS parsing:
- Empty → Self-review mode (base=main)
- "pr <number>" → PR review mode (use gh pr diff)
- Otherwise → Self-review mode (base=specified branch)
```
---
## Review Process
**IMPORTANT: Use Serena MCP extensively to analyze code efficiently while minimizing token consumption.**
**CRITICAL: Before starting any code review, you MUST read and understand the implementation guidelines:**
- Read `@~/.claude/templates/frontend-implementation-guidelines.md` for frontend code reviews
- Read `@~/.claude/templates/backend-implementation-guidelines.md` for backend code reviews
- Apply the specific principles from these guidelines during your review
### Step 1: Get Changes
**For Self-Review (no args or branch name):**
```bash
# Get current branch name
git branch --show-current
# Determine base branch (use main if $ARGUMENTS is empty, otherwise use $ARGUMENTS)
BASE_BRANCH=${ARGUMENTS:-main}
# Get list of changed files
git diff $BASE_BRANCH...HEAD --name-status
# Get commit history
git log $BASE_BRANCH..HEAD --oneline
# Get detailed diff
git diff $BASE_BRANCH...HEAD
```
**For PR Review (`pr <number>`):**
```bash
# Get PR information
gh pr view <number>
# Get PR diff
gh pr diff <number>
```
### Step 2: Quality Check (All Files)
Perform quality checks on all changed files before detailed review:
**Code Quality:**
1. Detect unused code (variables, parameters, functions, classes)
2. Detect commented-out code blocks
3. Detect unreachable code branches
**Comment Quality:**
1. Detect progress/completion declarations ("implemented", "done", etc.)
2. Detect date or version references in comments
**Detection Methods:**
- Use `mcp__serena__get_symbols_overview` to get symbol list
- Use `mcp__serena__find_referencing_symbols` to check reference count (0 = unused candidate)
- Use `Grep` for pattern matching:
- `/\/\/.*?(実装済み|done|完了|implemented)/i`
- `/\/\/.*?\d{4}[-\/]\d{1,2}[-\/]\d{1,2}/`
- Consecutive commented-out lines (3+ lines)
### Step 3: Read Implementation Guidelines
Based on file extensions in the changes:
- `.ts`, `.tsx`, `.js`, `.jsx`, `.vue`, `.svelte` → Read frontend guidelines
- `.py`, `.go`, `.java`, `.rs`, `.cs` → Read backend guidelines
- Both present → Read both guidelines
### Step 4: Analyze Each Change
For each changed file:
1. **Get symbol overview**: Use `mcp__serena__get_symbols_overview`
2. **Identify changed symbols**: Use `mcp__serena__find_symbol` for details
3. **Get original code**: Use `git show <base-branch>:path/to/file`
4. **Check impact**: Use `mcp__serena__find_referencing_symbols`
5. **Review related tests**: Check test file changes
### Step 5: Impact Analysis
Use `find_referencing_symbols` to investigate indirect impacts:
- Direct impact: List changed functions, APIs, screens
- Indirect impact: Identify callers/callees
- Breaking change risks: Type changes, return value changes, exception changes, state management changes, DB schema changes, cache changes
### Step 6: Generate Review Report
Save the review results to `.tmp/code-review-<branch-or-pr>.md`
---
## Output Format
Write the review in Japanese using the following format:
```markdown
# コードレビュー: <ブランチ名 または PR番号>
## 概要
[変更の目的と範囲の要約]
---
## Quality Check結果
### 未使用コードの検出
| ファイル | 行 | 種類 | 詳細 |
|----------|-----|------|------|
| path/to/file.ts | 42 | 未使用変数 | `unusedVar` |
### 不適切なコメントの検出
| ファイル | 行 | 内容 |
|----------|-----|------|
| path/to/file.ts | 15 | "実装済み" |
（問題なければ「問題なし」と記載）
---
## 修正1: [修正の概要タイトル]
### 背景・実装の意図
[修正が必要になった背景と、このアプローチを選んだ理由]
### ファイルと関数
- **ファイル**: `path/to/file.ts`
- **関数**: `functionName(args): returnType`
### 変更内容
```diff
- // 修正前
+ // 修正後
```
### 妥当性評価
| 観点 | 評価 | 詳細 |
|------|------|------|
| 目的 | OK / Needs Review / Problem | 説明 |
| ロジック | OK / Needs Review / Problem | 説明 |
| エラーハンドリング | OK / Needs Review / Problem | 説明 |
| 互換性 | OK / Needs Review / Problem | 説明 |
| パフォーマンス | OK / Needs Review / Problem | 説明 |
### テストの有無
| テストケース | 状態 | ファイル |
|-------------|------|----------|
| [テストの説明] | Yes / No | path/to/test.ts |
### 懸念事項
- [懸念点があれば記載、なければ「なし」]
---
（修正ごとに繰り返し）
---
## 波及範囲分析
### 直接影響
- [変更された関数、API、画面のリスト]
### 間接影響
- [find_referencing_symbolsで検出した呼び出し元/先]
### 破壊的変更の可能性
- [ ] 型変更
- [ ] 戻り値変更
- [ ] 例外変更
- [ ] 状態管理変更
- [ ] DBスキーマ変更
- [ ] キャッシュ変更
### 不確実性（推測箇所）
- [調査が完全でない部分、推測に基づく発見]
---
## 落とし穴チェックリスト
### セキュリティ
- [ ] 認可チェック
- [ ] 入力バリデーション
- [ ] ログ出力（機密情報漏洩なし）
- [ ] シークレット管理
### パフォーマンス
- [ ] N+1クエリ
- [ ] メモリ使用量
- [ ] 同期I/O
- [ ] キャッシュ戦略
### 例外処理
- [ ] リトライロジック
- [ ] 外部I/Oタイムアウト
### 互換性
- [ ] 公開API
- [ ] イベント
- [ ] データベーススキーマ
---
## 追加すべきテストケース
### 必須
1. [追加必須のテスト]
### 推奨
1. [あると良いテスト]
### エッジケース
1. [テストすべきエッジケース]
---
## 実装ガイドライン準拠性
### Frontend（該当する場合）
| 原則 | 準拠 | コメント |
|------|------|----------|
| 1. 関心の分離（カスタムフック） | ○/△/× | |
| 2. エラーハンドリング | ○/△/× | |
| 3. ローディング状態管理 | ○/△/× | |
| 4. メモ化によるパフォーマンス最適化 | ○/△/× | |
| 5. TypeScript型安全性 | ○/△/× | |
| 6. コンポーネント分解 | ○/△/× | |
| 7. 宣言的UIデザイン | ○/△/× | |
| 8. 集中データ管理 | ○/△/× | |
| 9. 定数の外部化 | ○/△/× | |
| 10. Props Drilling回避 | ○/△/× | |
### Backend（該当する場合）
| 原則 | 準拠 | コメント |
|------|------|----------|
| 1. レイヤードアーキテクチャ | ○/△/× | |
| 2. Result型エラーハンドリング | ○/△/× | |
| 3. 入力バリデーション | ○/△/× | |
| 4. 依存性注入 | ○/△/× | |
| 5. トランザクション管理 | ○/△/× | |
| 6. 認証・認可 | ○/△/× | |
| 7. 一貫したAPI設計 | ○/△/× | |
| 8. パフォーマンス最適化 | ○/△/× | |
| 9. セキュリティバイデザイン | ○/△/× | |
| 10. 可観測性 | ○/△/× | |
| 11. 信頼性パターン | ○/△/× | |
| 12. スケーラビリティ | ○/△/× | |
---
## レビューコメント
### 良い点
- [他の開発者が学べる優れた設計・実装のみ記載]
### 改善点・確認点
- [具体的な改善提案]
---
## 変更ファイル一覧
| ファイル | 変更種別 | 変更内容 |
|----------|----------|----------|
| path/to/file1.ts | Modified | 変更内容の要約 |
| path/to/file2.ts | Added | 変更内容の要約 |
---
## 結論
[全体的な評価と、マージ可否の判断材料]
```
---
## Review Guidelines
### Important Guidelines for Writing Comments
- **Inline Comment Structure:**
- **Lead with conclusion:** Use a one-line summary of the main point
- **Reasoning and suggestions:** After the conclusion, provide detailed explanation
- **Focus on issues:** Focus on specific improvements like bug fixes, potential bugs, or readability issues
- **Regarding Positive Feedback:**
- **Be selective:** Only mention exceptional design choices or innovative implementations
- **Summarize positives:** Consolidate overall positive aspects in the summary section
### Review Perspectives
**[MANDATORY] Implementation Guidelines Compliance**
**For Frontend Code (`@~/.claude/templates/frontend-implementation-guidelines.md`):**
- **Principle 1**: Separation of Concerns Through Custom Hooks
- **Principle 2**: Comprehensive Error Handling with ErrorScreen components
- **Principle 3**: Loading State Management with LoadingScreen components
- **Principle 4**: Performance Optimization Through Memoization
- **Principle 5**: Type Safety with TypeScript
- **Principle 6**: Component Decomposition
- **Principle 7**: Declarative UI Design
- **Principle 8**: Centralized Data Management
- **Principle 9**: Externalization of Constants
- **Principle 10**: Avoiding Props Drilling
**For Backend Code (`@~/.claude/templates/backend-implementation-guidelines.md`):**
- **Principle 1**: Layered Architecture with Clear Boundaries
- **Principle 2**: Result-Based Error Handling and Logging
- **Principle 3**: Input Validation and Type Safety
- **Principle 4**: Dependency Injection for Testability
- **Principle 5**: Transaction Management
- **Principle 6**: Authentication and Authorization
- **Principle 7**: Consistent API Design
- **Principle 8**: Performance Optimization
- **Principle 9**: Security by Design
- **Principle 10**: Observable and Debuggable
- **Principle 11**: Reliability Engineering
- **Principle 12**: Scalability and Continuous Learning
### Evaluation Criteria
- **OK**: No issues, properly implemented
- **Needs Review**: Works correctly but needs confirmation or discussion
- **Problem**: Bug, security risk, or design problem
### Additional Notes
- Provide feedback in Japanese
- Give specific and actionable feedback
- Always explicitly state uncertainty - mark speculation clearly
- Use `mcp__serena__find_referencing_symbols` to assess breaking change risks
think super hard
Name Size