code-review

Étoiles3

Forks1

Mis à jour23 juillet 2026 à 22:15

Code, PR, diff, branch, or commit review; git diff, git show, or change comparison. Not for debugging or design critique.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Source

ilude

ilude/dotfiles

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Métiers associésSOC

Basé sur la classification professionnelle SOC

Analystes en assurance qualité des logiciels et testeursProfessions informatiques et mathématiques·SOC 15-1253

SKILL.md

readonly

name	code-review
description	Code, PR, diff, branch, or commit review; git diff, git show, or change comparison. Not for debugging or design critique.

Evidence-Based Code Review

Boundary

Use code-review only when reviewing a change set for findings. Use analysis-workflow for general troubleshooting and least-astonishment while making edits.

Core Principle: Must vs May

Report only issues that are demonstrably reachable and worth fixing. Suggestions are allowed, but label them separately from required findings.

Review Steps

Identify the reviewed range and changed files.
Understand intended behavior from code, tests, and docs.
Check changed paths for correctness, security, data loss, regressions, and test gaps.
Treat changes under .vscode/, .claude/, .gemini/, .cursor/, .github/workflows/, .forgejo/workflows/, package lifecycle scripts, setup scripts, and go:generate directives as security-sensitive executable or agent-instruction surface.
Prove reachability: inputs, callers, guards, and runtime conditions.
Classify severity and confidence.
Provide exact evidence and required fix.

Finding Format

[severity] Title
Evidence: <file:line and why the path is reachable>
Impact: <user/system consequence>
Required fix: <specific change or invariant>

Severity Guide

Severity	Meaning
Critical	data loss, credential exposure, remote exploit, total outage
High	common path broken, security boundary bypass, major regression
Medium	real bug with bounded impact
Low	minor correctness/maintainability issue

Anti-Patterns

Flagging hypothetical bugs without a reachable path.
Reviewing unchanged code as if introduced by the diff.
Mixing style preferences with required fixes.
Missing tests but not explaining the untested risk.
Treating editor tasks, agent hooks, or workflow changes as harmless metadata without checking execution triggers and secret access.

Plus depuis ce dépôt

même dépôt

pi-extension

ilude/dotfiles

Pi extensions and tool policy: extensions/*.ts, hooks, registerTool, promptGuidelines, registerCommand, footer/status UI, tool_result, session hooks, or subprocesses. Not for slash-command placement; use pi-command.

2026-08-023

docs

ilude/dotfiles

README, CHANGELOG, docs/, RFCs, ADRs, guides, or Markdown structure. Not for prose cleanup or archival work.

2026-07-273

no-ai-slop

ilude/dotfiles

Prose cleanup for filler, hype, vague claims, repetition, detection tells, or uncited specifics. Not for Markdown architecture or archival work.

2026-07-273

planning

ilude/dotfiles

Requirements, user stories, acceptance/verification criteria, or testable outcomes. Not for PRD drafting (/prd) or Pi /goal prompts.

2026-07-273

prd

ilude/dotfiles

Use for /prd-it or to draft, refine, or review a Product Requirements Document. Not for acceptance criteria, planning, or Pi /goal prompts.

2026-07-273

pi-log-analytics

ilude/dotfiles

Pi session, trace, metrics, routing, workflow-friction, workflow-telemetry, usage, or local JSONL analysis with DuckDB. Use for aggregating or correlating Pi runtime logs. Not for adding telemetry, generic SQL/database design, or non-Pi logs.

2026-07-273

name	code-review
description	Code, PR, diff, branch, or commit review; git diff, git show, or change comparison. Not for debugging or design critique.

Evidence-Based Code Review

Boundary

Use code-review only when reviewing a change set for findings. Use analysis-workflow for general troubleshooting and least-astonishment while making edits.

Core Principle: Must vs May

Report only issues that are demonstrably reachable and worth fixing. Suggestions are allowed, but label them separately from required findings.

Review Steps

Identify the reviewed range and changed files.
Understand intended behavior from code, tests, and docs.
Check changed paths for correctness, security, data loss, regressions, and test gaps.
Treat changes under .vscode/, .claude/, .gemini/, .cursor/, .github/workflows/, .forgejo/workflows/, package lifecycle scripts, setup scripts, and go:generate directives as security-sensitive executable or agent-instruction surface.
Prove reachability: inputs, callers, guards, and runtime conditions.
Classify severity and confidence.
Provide exact evidence and required fix.

Finding Format

[severity] Title
Evidence: <file:line and why the path is reachable>
Impact: <user/system consequence>
Required fix: <specific change or invariant>

Severity Guide

Severity	Meaning
Critical	data loss, credential exposure, remote exploit, total outage
High	common path broken, security boundary bypass, major regression
Medium	real bug with bounded impact
Low	minor correctness/maintainability issue

Anti-Patterns

Flagging hypothetical bugs without a reachable path.
Reviewing unchanged code as if introduced by the diff.
Mixing style preferences with required fixes.
Missing tests but not explaining the untested risk.
Treating editor tasks, agent hooks, or workflow changes as harmless metadata without checking execution triggers and secret access.