메뉴
Perform an in-depth code review of changed files and produce a structured report. Defaults to reviewing staged changes.
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
SOC 직업 분류 기준
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/guyoung/boxagnts --skill code-review명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
SKILL.md 표시 중
Analyze a given style file or component directory, identify redundancy, inefficiency, and maintainability issues, and suggest optimizations.
Production-grade DOCX generator that creates valid Microsoft Word (.docx) files from Markdown or structured AST using a safe streaming ZIP engine and minimal but strict OOXML baseline.
Compress and decompress files using jsexec with built-in zlib and manual format parsing. Supports .gz, .tar, .tar.gz, .tgz, .zip.
| name | code-review |
| description | Perform an in-depth code review of changed files and produce a structured report. Defaults to reviewing staged changes. |
| when_to_use | Use when the user asks to review code changes, requests a structured quality assessment covering logic, security, performance, and maintainability, or wants a detailed report with severity-ranked issues and fix suggestions. Defaults to reviewing staged changes but can target a specific file or directory. |
| tools | read, bash, glob, grep |
| args | [{"name":"target","description":"File or directory to review; leave empty to review git staged changes","required":false}] |
GUIDANCE SKILL — INSTRUCTIONS ONLY Code review is a systematic examination of source code quality across multiple dimensions: logic, security, performance, maintainability, and standards compliance. This skill provides patterns, conventions, and constraints. It contains no executable code — apply the guidance to your context, adapting specifics as needed per C2-B.
The instructions below define the REQUIRED APPROACH — you MUST follow the prescribed patterns, conventions, and constraints.
Mandatory adherence:
| Arg | Type | Required | Default | Description |
|---|---|---|---|---|
| target | string | No | (empty) | File or directory to review; leave empty to review git staged changes |
Multi-dimensional assessment: every review MUST examine the target code through all five review dimensions — Logic Correctness, Security, Performance, Maintainability, and Standards Compliance. Issues from each dimension are independently classified and then merged into a single ranked report.
Issues are classified by severity using four standard levels:
| Severity | Meaning |
|---|---|
| Critical | Security vulnerability, data loss risk, or production-breaking bug |
| High | Logic error with significant impact, or major performance regression |
| Medium | Maintainability concern, minor duplication, or unclear naming |
| Low | Style nit, non-critical lint warning, or cosmetic improvement |
The output is a single structured Markdown report composed of:
Issues in the table are ordered by severity (Critical first, then High, Medium, Low).
Determine scope (staged changes or {{target}})
→ Read all changed/in-scope files
→ Analyze against each review dimension
→ Classify each finding by severity
→ Merge and rank all issues
→ Produce structured Markdown report (table + score)
{{target}} is provided, scope to that file or directory. Otherwise, obtain git staged changes via git diff --staged.npm run lint, eslint, golangci-lint) and capture violations.| Decision | Rationale | Trade-offs |
|---|---|---|
| Default to staged changes | Most common review use case; minimizes noise | May miss unstaged work in progress |
| Five review dimensions | Balanced coverage of quality attributes | Some overlap between Maintainability and Standards Compliance |
| Severity-ranked table format | Actionable, scannable, and easy to integrate into tooling | Less narrative context than prose |
| Table before score | Allows reviewer to derive score from issue inventory | Score may feel disconnected if table is long |
| Read-only enforcement | Prevents accidental modification during review | Cannot auto-fix trivial issues |
Input: A file path, directory path, or nothing (defaults to git staged changes). When {{target}} is specified, all files within that scope are reviewed. When omitted, git diff --staged determines the change set.
Output: A Markdown report containing:
| Feature | Input | Output |
|---|---|---|
| Staged changes review | (empty target) | Diff-based report |
| Single file review | File path | Targeted report |
| Directory review | Directory path | Multi-file aggregated report |
| Lint integration | Project lint command | Lint violations in Standards Compliance |
{{target}} points outside the workspace root, report the error and halt.Before running the formal C3 verification, confirm:
Over-adaptation: "Adapt specifics to fit" does not mean rewrite the core patterns. When in doubt, preserve the prescribed approach over local convenience — the patterns exist for a reason.
Pattern drift: As implementation progresses, it's easy to gradually deviate from conventions. Regularly re-read the Design Patterns section to catch drift early.
Surface-level review: Do not limit findings to style and lint issues. Deeply examine logic correctness and security — those are the highest-value dimensions of a code review.
Missing context: Reviewing only the diff lines without reading surrounding code can miss integration bugs. Always read enough context to understand how the change fits into the broader module.
Vague fix suggestions: "Fix the bug" or "Improve this" are not actionable. Every fix suggestion must be concrete — propose a specific code pattern, refactor, or library usage.
| Check Item | Constraint | Common Omission | Method |
|---|---|---|---|
| Pattern adherence | Prescribed patterns followed | Divergent implementation | Compare against Design Patterns section |
| Naming conventions | Conventions applied consistently | Inconsistent naming | Grep / code review |
| Hard constraints | All non-negotiable constraints met | Constraint violation | Manual checklist verification |
| File organization | Modules/files structured as prescribed | Misplaced or missing files | Directory structure review |
| All dimensions covered | Five review dimensions examined | Missing Security or Performance | Cross-reference report against Review Dimensions |
| Issue format complete | Every issue has Severity + File:Line + Description + Fix | Missing fix suggestion | Table cell inspection |
| Overall score present | Score (1–10) + key areas provided | Score without justification | Verify both elements in output |
| Read-only enforced | No files modified during review | Accidental edit or write | Confirm no write/edit tools were invoked |