Skip to main content

cxc-dev-code-reviewer

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

소스 정보

저장소
lidge-jun/codexclaw
최근 소스 활동
2026년 10월 9일 04:32
감지된 SKILL.md 언어
영어
스타
48
포크
10

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

파일 탐색기
12 개 파일

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
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) |
GitHub에서 보기