Code Review — Request + Receive + Complete

Full review lifecycle in one skill: Request → Receive → Integrate.

Part A: Requesting Code Review

When to Request

Mandatory:

• After each task in cm-execution
• After completing major features
• Before merge to main

Optional but valuable:

• When stuck (fresh perspective)
• Before refactoring (baseline check)
• After fixing complex bugs

How to Request

1. Get git SHAs:

   BASE_SHA=$(git rev-parse HEAD~1)
   HEAD_SHA=$(git rev-parse HEAD)

2. Dispatch reviewer subagent with:

   • What was implemented
   • Plan/requirements reference
   • Base and head SHAs
   • Brief description

3. Act on feedback:

   • Fix Critical issues immediately
   • Fix Important issues before proceeding
   • Note Minor issues for later
   • Push back if reviewer is wrong (with reasoning)

---

Part B: Receiving Code Review

When to Use

When receiving feedback — whether from human reviewers, AI reviewers, or code review subagents.

The Protocol

1. READ feedback completely before responding
2. UNDERSTAND the technical reasoning
3. VERIFY if the feedback is technically correct
4. RESPOND with evidence, not agreement

Response Framework

Feedback Type	Response
Technically correct	Fix it. Thank reviewer.
Unclear intent	Ask for clarification with specific questions
Technically questionable	Challenge with evidence (code, tests, docs)
Stylistic preference	Discuss trade-offs, defer to team convention

Red Flags — STOP

• Blindly implementing all suggestions without verification
• "Performative agreement" — saying yes without understanding
• Implementing a suggestion that breaks existing tests
• Making changes you can't justify technically

Anti-Pattern: Performative Agreement

❌ "Good catch! Fixed."  (without verifying it's actually a problem)
✅ "I verified this: [evidence]. The suggestion is correct because [reason]. Fixed."
✅ "I investigated this: [evidence]. The current code is correct because [reason]."

---

Part C: Finishing a Development Branch

When to Use

When implementation is complete and all tests pass.

The Process

1. Verify current state:

   npm run test:gate  # All tests must pass
   git status          # Working tree should be clean

2. Present options to user:

   Option	When	Command
   Merge to main	Feature ready	git checkout main && git merge feature-branch
   Create PR	Needs team review	git push origin feature-branch
   Keep working	More tasks remain	Continue on branch
   Cleanup only	Abandoned/merged	git worktree remove path

3. Execute chosen option

4. Cleanup:

   • Remove worktree if using cm-git-worktrees
   • Delete feature branch if merged
   • Update task tracking

Rules

• Never merge with failing tests
• Never force push main/production
• Always use cm-identity-guard before git push

---

Part D: Security Review Checklist (Learned: March 2026)

Every code review MUST include a security pass. Check these patterns:

Frontend

• [ ] No innerHTML with unescaped dynamic data
• [ ] sanitize.js loaded before any JS that uses innerHTML
• [ ] URLs from params validated against allowlist
• [ ] No eval(), new Function(), or document.write() with user data

Backend (Python)

• [ ] All file paths from config/input use safe_resolve(base, path)
• [ ] No subprocess.run(..., shell=True) with dynamic args
• [ ] No open(user_input) without path validation

Backend (Node/Express)

• [ ] app.disable('x-powered-by') set
• [ ] Body size limits configured
• [ ] No Object.assign(config, userInput) (prototype pollution)
• [ ] API error responses don't leak stack traces

General

• [ ] No secrets/API keys in committed code
• [ ] .snyk exclusions documented with mitigation rationale

---

Step FINAL: Record Review Learnings

After processing review feedback, ALWAYS update .cm/CONTINUITY.md:

• Key Decisions: If reviewer changed architecture approach, record with scope: [Decision]: [Rationale] — scope: [global|module:{name}]
• Mistakes & Learnings: If reviewer caught a pattern mistake, record with scope:
  • What Failed: [the pattern that was wrong]
  • How to Prevent: [correct pattern going forward]
  • Scope: [global | module:{name} | file:{path}]

Anti-duplicate: If similar learning exists, reinforce it instead of creating new.

Token savings: Future code reviews in same project avoid repeating the same feedback. Reviewer patterns become accumulated knowledge.

---

Integration

Skill	Relationship
cm-execution	Reviews after each task in execution
cm-quality-gate	Tests must pass before finishing branch
cm-identity-guard	Before git push
cm-git-worktrees	Cleanup worktree after completion

The Bottom Line

Review early. Verify feedback. Ship with evidence, not hope.