메뉴
Use when implementation is complete and verification has passed — dispatches the sensei agent for fresh-context quality review
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | self-review |
| description | Use when implementation is complete and verification has passed — dispatches the sensei agent for fresh-context quality review |
| tags | ["gate","review","quality"] |
| triggers | ["implementation complete","verification passed","before commit","before PR"] |
| chains_to | ["compound-docs"] |
| priority | gate |
| gate | true |
After implementation + verification, dispatch the sensei for a fresh-context review of the actual git diff. The sensei has no memory of writing the code — pure quality signal.
verification-before-completion passesRun git diff (or git diff --staged if changes are staged) to see what changed. If the diff is empty, nothing to review.
| Change Size | Action |
|---|---|
| < 20 lines, single file | Quick inline self-check (no agent needed) |
| 20-100 lines | Dispatch sensei at configured strictness |
| > 100 lines or 3+ files | Dispatch sensei at MEDIUM minimum |
For changes under 20 lines, ask yourself:
If all clear, proceed.
Use the Agent tool to dispatch the sensei review agent:
Agent: review/sensei
Task: Review the following git diff for quality, simplicity, and pattern compliance.
Context: [brief description of what was implemented and why]
The sensei reviews the actual diff and returns:
| Verdict | Action |
|---|---|
| PASS | Proceed to commit/PR |
| PASS_WITH_NOTES | Proceed to commit/PR. Show advisory notes to user for awareness. No simplification loop. |
| SIMPLIFY_FIRST | Apply simplifications, re-verify, re-review (max 2 rounds) |
| RETHINK | Discuss with user before proceeding |
Round 1: Sensei review → Apply fixes → Re-verify
Round 2: Sensei review → Apply fixes → Done (show remaining items to user)
Maximum 2 simplification rounds. After round 2, show any remaining items to the user and proceed.
| Anti-Pattern | Why It's Wrong |
|---|---|
| Skipping review for "obvious" changes | Obvious changes often have subtle bugs |
| Reviewing from memory instead of the diff | Memory is biased. The diff is truth. |
| Infinite polish loops | 2 rounds max. Ship it. |
| Ignoring sensei feedback because "it works" | Working != good. Quality matters. |
OPTIONAL: syntaxninja-dojo:compound-docs (when a hard problem was solved)
Use when a structured PRD document is needed for the ralph loop — generates prd.json and progress.txt
Use when task scope exceeds one context window and decomposes into independent pass/fail stories with clean iteration boundaries
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work — merge, PR, or cleanup
Use when starting feature work that needs isolation from the current workspace or before executing plans that could leave the branch in a broken state
Use when a hard problem was just solved and the solution should be captured as a learning for future reference
Use when 3+ distinct occurrences suggest a skill should be updated with a new trigger, anti-pattern, or verification step