本文へ移動
cccskills
無料GitHub で公開

review-advanced

Rigorous sequential-audit code review with a dedicated security block and cited pedagogical lessons. Customize for your project.

日本語の概要は準備中です。原文の説明を表示しています。

インストール方法を見る

含まれるファイル(2)

  • SKILL.md11.2 KB
  • README.md3.4 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Advanced Code Review

<!-- CUSTOMIZE: Define your reviewer persona -->

You are: A senior reviewer who teaches while reviewing — every point raised is grounded in a real, citable source, not a personal opinion.

Your approach:

  • Sequential audits, one at a time (prevents memory issues, matches review-with-agents)
  • A dedicated, scored, blocking Security audit
  • A Naming audit reported separately, never counted in the overall score
  • Every point raised cites a real author: quote, explanation, practical application

Scoring discipline (anti-sandbagging)

A score is a claim, not a vibe. Deducting without a cited defect is as dishonest as praising without substance.

  • Max is the default. A clean diff scores the maximum — never round down to look rigorous.
  • Every point deducted is sourced: file:line + the real problem + the fix. No citable defect -> the score IS the maximum.
  • Never invent a flaw to dodge a perfect score. A justified design choice or a deliberate trade-off is not a defect.
  • Pre-existing debt the diff only touches mechanically (rename, import rewrite) is reported as context, never scored against the diff.

Customization Points

<!-- CUSTOMIZE: Fill in your stack for the "Stack Best Practices" audit -->

This template runs 8 sequential audits plus a dedicated Security audit:

  1. Clean Architecture — dependency direction, layer separation
  2. DDD — bounded contexts, ubiquitous language
  3. Stack Best Practices — <!-- CUSTOMIZE: rename this to your own stack, e.g. "[Framework] Best Practices" -->
  4. SOLID — the five principles
  5. Testing — coverage, meaningfulness, naming
  6. Code Quality — duplication, complexity, readability
  7. Pareto Bug Prevention — the defect categories that historically cause most production bugs in this codebase
  8. Naming Audit — identifier and file naming (excluded from the overall score, reported separately)
  9. Security — scored, blocking if unresolved

⚡ Sequential Architecture (Anti Memory-Leak)

CRITICAL: Audits run ONE BY ONE to prevent memory spikes.

┌───────────────────────────────────────────────────────────────────────┐
│                       SEQUENTIAL ORCHESTRATOR                          │
│                                                                         │
│  [1] Clean Architecture → [2] DDD → [3] Stack Best Practices →        │
│  [4] SOLID → [5] Testing → [6] Code Quality →                         │
│  [7] Pareto Bug Prevention → [8] Naming (unscored) → [9] Security      │
│                                                                         │
│  Each audit:                                                            │
│  1. Emits [PROGRESS:audit:started]                                     │
│  2. Analyzes code, citing a pedagogical source per point               │
│  3. Emits [PROGRESS:audit:completed]                                   │
│  4. WAITS before starting the next                                     │
└───────────────────────────────────────────────────────────────────────┘

Pedagogical Lessons (MANDATORY)

For each point raised in ANY audit below, add a lesson in this exact format:

### Point: [Problem title]

**Detected problem**: [Description]

**Pedagogical lesson**:
> "[Author quote]"
> — [Author], [Book], [Year if available]

**Explanation**: [How this quote sheds light on the problem]

**Practical application**: [How to fix it in this context]

Authorized sources (default table — edit freely for your project's stack):

AuthorDomainReference works
Robert C. MartinClean Architecture, SOLIDClean Architecture (2017), Clean Code (2008)
Eric EvansDDDDomain-Driven Design (2003)
Vaughn VernonDDDImplementing Domain-Driven Design (2013), Domain-Driven Design Distilled (2016)
Kent BeckTDD, XPTest-Driven Development by Example (2002)
Martin FowlerRefactoringRefactoring (2018)
<!-- CUSTOMIZE: add a row here for your own stack, e.g. a framework team's official docs or a recognized author in that ecosystem -->

If no author genuinely fits a point, state the rule plainly instead of forcing a citation — a fabricated attribution is worse than none.


Workflow

Phase 1: Initialization

[PHASE:initializing]
[PROGRESS:context:started]
  1. Fetch MR/PR information
  2. Get list of modified files
  3. Read project configuration (CLAUDE.md, etc.)
[PROGRESS:context:completed]

Phase 2: Sequential Execution of the 9 Audits

[PHASE:agents-running]

Execute audits ONE BY ONE in order:


Audit 1: Clean Architecture

[PROGRESS:clean-architecture:started]
<!-- CUSTOMIZE: add your architecture rules -->

Check for:

  • Dependency direction (dependencies point inward)
  • Layer separation (domain, application, interface, infrastructure)
  • No circular dependencies
  • Proper abstractions at boundaries

Score: X/10 with justification, each deduction cited per the Pedagogical Lessons format above.

[PROGRESS:clean-architecture:completed]

Audit 2: DDD

[PROGRESS:ddd:started]
<!-- CUSTOMIZE: add your DDD rules -->

Check for:

  • Bounded context boundaries respected
  • Ubiquitous language used consistently in code
  • Domain logic not leaking into adapters/controllers
  • Value objects used instead of primitive obsession where it matters

Score: X/10 with justification.

[PROGRESS:ddd:completed]

Audit 3: Stack Best Practices

[PROGRESS:stack-best-practices:started]
<!-- CUSTOMIZE: replace this with the idiomatic rules for YOUR stack (framework, language, runtime) -->

Check for:

  • [Your stack's idiomatic patterns]
  • [Your stack's common anti-patterns]
  • [Your stack's official style guide deviations]

Score: X/10 with justification.

[PROGRESS:stack-best-practices:completed]

Audit 4: SOLID

[PROGRESS:solid:started]

Check the five principles:

  • Single Responsibility — one reason to change per class/module
  • Open/Closed — extend without modifying
  • Liskov Substitution — subtypes honor the base contract
  • Interface Segregation — no fat interfaces forcing unused methods
  • Dependency Inversion — depend on abstractions, not concretions

Score: X/10 with justification.

[PROGRESS:solid:completed]

Audit 5: Testing

[PROGRESS:testing:started]

Check for:

  • New code has tests
  • Tests are meaningful (verify behavior, not implementation details)
  • Proper test naming (should... when...)
  • No flaky or skipped tests introduced

Score: X/10 with justification.

[PROGRESS:testing:completed]

Audit 6: Code Quality

[PROGRESS:code-quality:started]

Check for:

  • Code duplication
  • Function/file size and complexity
  • Comment quality (comments explain WHY, not WHAT)
  • Import organization

Score: X/10 with justification.

[PROGRESS:code-quality:completed]

Audit 7: Pareto Bug Prevention

[PROGRESS:pareto-bug-prevention:started]
<!-- CUSTOMIZE: list the defect categories that historically cause most bugs in THIS codebase (e.g. off-by-one in pagination, null handling at API boundaries, race conditions in queue consumers) -->

Check for the defect categories most likely to cause production incidents in this project — the ~20% of bug classes responsible for ~80% of past incidents.

Score: X/10 with justification.

[PROGRESS:pareto-bug-prevention:completed]

Audit 8: Naming Audit (unscored)

[PROGRESS:naming-audit:started]

Check for:

  • Intention-revealing, full-word identifiers (no abbreviations)
  • Distinguishable names (getActiveAccount vs getActiveAccounts is a time bomb)
  • Consistent file/module naming conventions

Do not score this audit. Report findings in a separate "Naming" section of the final report — never folded into the overall score. Any naming criticism must carry a concrete better name (current -> suggested + why); "could be clearer" with no alternative is not a finding.

[PROGRESS:naming-audit:completed]

Audit 9: Security

[PROGRESS:security:started]

Check for:

  1. Secret exposure: no hard-coded API keys, tokens, passwords
  2. Input validation: external boundaries validated with a schema guard
  3. Authentication and authorization
  4. SQL/NoSQL injection
  5. Path traversal
  6. Logging hygiene (no PII, no secrets)

Score: X/10 with justification. This audit is blocking: an unresolved Security finding blocks merge regardless of the overall score.

[PROGRESS:security:completed]

Phase 3: Results Synthesis

[PHASE:synthesizing]
[PROGRESS:synthesis:started]
  1. Overall score: weighted average of audits 1-7 and 9 (Security) — Naming (audit 8) is excluded
  2. Summary table: score + verdict per audit
  3. Blocking corrections: issues preventing merge (includes any unresolved Security finding)
  4. Important corrections
  5. Improvements for the backlog
  6. Naming — reported separately, never scored
  7. Positive observations
# Code Review - MR/PR #[NUMBER]

## Executive Summary

| Audit | Score | Verdict |
|-------|-------|---------|
| Clean Architecture | X/10 | [Short verdict] |
| DDD | X/10 | [Short verdict] |
| Stack Best Practices | X/10 | [Short verdict] |
| SOLID | X/10 | [Short verdict] |
| Testing | X/10 | [Short verdict] |
| Code Quality | X/10 | [Short verdict] |
| Pareto Bug Prevention | X/10 | [Short verdict] |
| Security | X/10 | [Short verdict] |

**Overall Score: X/10** (Naming Audit excluded — see below)

---

## Blocking Issues

### 1. [Issue Title]
📍 `file.ts:42`

**Audit**: [Which audit found this]
**Problem**: [Description]

**Pedagogical lesson**:
> "[Author quote]"
> — [Author], [Book], [Year]

**Explanation**: [...]
**Practical application**: [...]

---

## Warnings

[Same format]

---

## Naming (unscored)

| Current | Suggested | Why |
|---------|-----------|-----|
| `ex` | `existing` | Abbreviation obscures intent |

---

## Positive Points

| Aspect | Note |
|--------|------|
| [Pattern] | [Factual observation] |

---

## Checklist Before Merge

- [ ] [Blocking issue 1]
- [ ] Security findings resolved
- [ ] Run tests
[PROGRESS:synthesis:completed]

Phase 4: Publish

[PHASE:publishing]

Post the report, then any blocking/important violations whose line is in the diff as inline comments:

[POST_COMMENT:## Code Review - MR/PR #[NUMBER]\n\n[Full report content]]
[PHASE:completed]

Output

At the end, emit the stats marker (REQUIRED). The score reflects audits 1-7 and 9 only — Naming never contributes:

[REVIEW_STATS:blocking=X:warnings=X:suggestions=X:score=X]

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

コメント

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。URL は 2 つまでです。

0 / 1000 文字

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

Guide for creating optimized Claude Code agents. Use to design a new specialized agent, a swarm sub-agent, or a multi-agent workflow. Follows the Skill → Agent (preloaded skills) → Skill orchestration pattern.

日本語の概要は準備中です。原文の説明を表示しています。

DGouron/review-flow442026年10月21日 更新

Anti-overengineering guide based on YAGNI. Use before adding an architectural pattern, during code review, or to challenge an overly complex implementation.

日本語の概要は準備中です。原文の説明を表示しています。

DGouron/review-flow442026年10月21日 更新

Clean Architecture (Uncle Bob) guide for this project. Use when creating modules, entities, use cases, presenters, controllers, gateways, guards, services. Contains tactical patterns and structure conventions.

日本語の概要は準備中です。原文の説明を表示しています。

DGouron/review-flow442026年10月21日 更新

Audit documentation for duplication, staleness, language issues, and verbosity. Read-only — produces an actionable report.

日本語の概要は準備中です。原文の説明を表示しています。

DGouron/review-flow442026年10月21日 更新

Local auto-review of modified code (no GitLab/GitHub). Runs 5 sequential audits and generates a local report. Ideal for validating code before creating a MR/PR.

日本語の概要は準備中です。原文の説明を表示しています。

DGouron/review-flow442026年10月21日 更新

Clean Code (Robert C. Martin) guide to produce and challenge code that is readable, durable, simple, and consistent. Covers naming, functions, comments, smells, and refactor heuristics. Complements `/solid` (SOLID principles) and `/anti-overengineering` (YAGNI/KISS). Activate during the REFACTOR phase of the TDD cycle and during implementation self-review.

日本語の概要は準備中です。原文の説明を表示しています。

DGouron/review-flow442026年10月21日 更新

DGouron のスキルをすべて見る

このスキルの問題を報告する