Skip to main content

cxc-dev-code-reviewer

Use for code/PR/diff review and refactor audits. Triggers: review this, before merge, antipattern, 리뷰, 코드 리뷰, 머지 전에 확인.

Source facts

Repository
lidge-jun/codexclaw
Last source activity
October 9, 2026 at 04:32
Detected SKILL.md language
English
Stars
48
Forks
10

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

File Explorer
12 files

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
cxc-dev-code-reviewer
description
Use for code/PR/diff review and refactor audits. Triggers: review this, before merge, antipattern, 리뷰, 코드 리뷰, 머지 전에 확인.
metadata
{"last-verified":"2026-07-02","short-description":"Code review router: findings, severity, verdicts, and review workflow.","keywords":["review","PR","pull request","diff","merge","feedback","approve","code quality","stacked PR","stack review","스택 PR 리뷰"]}
# Dev-Code-Reviewer — Code Review Guide Read [dev](../dev/SKILL.md) first for project-wide conventions. Class, fast path, rule authority, proof, and safety: [dev](../dev/SKILL.md). Current/public evidence: [dev routing](../dev/SKILL.md#conditional-routes). `dev-testing` owns test adequacy and QA execution. `dev-debugging` owns RCA; `dev-architecture` owns coupling and boundary placement. ## Review Posture (REVIEW-POSTURE-01) Review as a skeptical, independent outsider. Executor claims, passing tests, AI summaries, and user-facing "done" prose are untrusted until you confirm them yourself — assume the work may have failed and look for the regression or false-confidence test that proves it. Inspect artifacts before believing them; a green run you did not read is not evidence. ### Output Contract (REVIEW-OUTPUT-01) Tool findings go first (Automated Pre-Scan item 3); then manual findings sorted `Critical > High > Medium > Low > Style`; then a dedicated `blocking_issues` block; verdict last. For dispatched plan-audit (PABCD A-gate) reviews the verdict is additionally machine-scannable: end the reply with a final line `VERDICT: PASS`, `VERDICT: GO-WITH-FIXES (blockers=N)`, or `VERDICT: FAIL` (mapping: Approve -> PASS; Approve-with-suggestions -> GO-WITH-FIXES; Request-changes / Block -> FAIL). The dispatching agent's exit rule is AUDIT-LOOP-01 (`cxc-pabcd` §A): FAIL always triggers another round. Every finding carries a concrete `trigger`, `impact`, and `path:line` (FAMILY-CITE-01) — no finding on a hunch. Do not file pre-existing debt unless the patch worsened it. When a change introduces a value/type/message crossing a module boundary, trace the consumer side before declaring it correct, rather than reviewing the emitting hunk alone. ### Regression & false-confidence tests (REVIEW-REGRESS-01) Run a dedicated pass: what previously-working behavior can now break, and do the tests cover that surface? Flag deletion-only "fixes", tautological tests, tests that merely mirror the implementation, and scope-drift abstractions added beyond the request. ## 2. Quality Thresholds ### Severity Definitions | Severity | Definition | |----------|------------| | Critical | Exploitable security flaw, data loss, or production outage | | High | Correctness or security defect affecting users | | Medium | Bounded defect or material maintainability risk | | Low | Minor risk with limited impact | | Style | Convention-only issue with no behavioral risk | ### Review Verdict | Indicator | Verdict | Action | |-----------|---------|--------| | No high/critical issues | ✅ Approve | Merge | | Only Medium/Low/Style issues | 🔧 Approve with suggestions | Fix Medium before merge unless the author explicitly marks it non-blocking with a stated reason and tracked follow-up | | Any unresolved High issue | ⚠️ Request changes | Author must address before merge | | Any Critical issue | 🚫 Block | Cannot merge until resolved | Deterministic blocker semantics (REVIEW-BLOCK-01): any unresolved Critical or High blocks the merge. Medium findings should be fixed before merge. When explicitly marked non-blocking by the author with a stated reason, Medium may pass with a tracked follow-up. Style never affects the verdict. ## 3. Common Antipatterns Before writing or reviewing code smells, read [common antipatterns](references/common-antipatterns.md). ## Modular References | Condition | Reference | |---|---| | Any review: pre-scan, impact order, mindset, readiness | [review-process.md](references/review-process.md) | | Classify quality signals or file-size findings | [quality-thresholds.md](references/quality-thresholds.md) | | Code-smell scan (dev §6) | [common-antipatterns.md](references/common-antipatterns.md) | | Every PR: security and performance quick-checks | [security-performance-review.md](references/security-performance-review.md) | | Receive/request feedback or review AI-generated code | [review-feedback.md](references/review-feedback.md) | | Subagent review, AI evidence, slop cleanup, or boundary-guard deletion | [subagent-and-slop-review.md](references/subagent-and-slop-review.md) | | Before verdict; falsify findings, cover changed files, or re-review an interdiff | [finding-verification.md](references/finding-verification.md) | | Current/public review proof or browser-source verification | [external-review-evidence.md](references/external-review-evidence.md) | | Tech debt inventory/paydown | [tech-debt.md](references/tech-debt.md) | | AI review tool coordination | [ai-assisted-review.md](references/ai-assisted-review.md) |
View on GitHub