cokit-cli 1.2.7 → 1.3.0

package/templates/repo/.github/skills/code-review/SKILL.md

@@ -1,193 +1,196 @@
 ---
 name: code-review
-description: Review code quality, receive feedback with technical rigor, verify completion claims. Includes edge case scouting for multi-file features. Use before PRs, after implementing features, when claiming task completion, for agent reviews.
+description: "Review code quality with adversarial rigor. Supports input modes: pending changes, PR number, commit hash, codebase scan. Always-on red-team analysis finds security holes, false assumptions, and failure modes."
+argument-hint: "[#PR | COMMIT | --pending | codebase [parallel]]"
 ---
 
 # Code Review
 
-Guide proper code review practices emphasizing technical rigor, evidence-based claims, and verification over performative responses.
+Adversarial code review with technical rigor, evidence-based claims, and verification over performative responses. Every review includes red-team analysis that actively tries to break the code.
 
-## Overview
+## Input Modes
 
-| Practice | When | Protocol |
-|----------|------|----------|
-| **Edge Case Scouting** | Before any review on 3+ file features | `/ck-scout` for hidden paths and untested scenarios |
-| **Receiving Feedback** | Feedback from human or agent | READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT |
-| **Requesting Reviews** | After each task, before merge, after major features | Delegate to `code-reviewer` agent |
-| **Verification Gates** | Before any completion claim | Run command, read output, then claim |
+Auto-detect from arguments. If ambiguous or no arguments, prompt by asking the user.
 
-## Core Principle
-
-Always honoring **YAGNI**, **KISS**, and **DRY** principles.
-**Be honest, be brutal, straight to the point, and be concise.**
-
-**Technical correctness over social comfort.** Verify before implementing. Ask before assuming. Evidence before claims.
+| Input | Mode | What Gets Reviewed |
+|-------|------|--------------------|
+| `#123` or PR URL | **PR** | Full PR diff fetched via `gh pr diff` |
+| `abc1234` (7+ hex chars) | **Commit** | Single commit diff via `git show` |
+| `--pending` | **Pending** | Staged + unstaged changes via `git diff` |
+| *(no args, recent changes)* | **Default** | Recent changes in context |
+| `codebase` | **Codebase** | Full codebase scan |
+| `codebase parallel` | **Codebase+** | Parallel multi-reviewer audit |
 
-## When to Use This Skill
+**Resolution details:** `references/input-mode-resolution.md`
 
-### Edge Case Scouting
-Trigger when:
-- Feature touches 3+ files
-- Implementing complex business logic
-- Before requesting formal code review
-- After implementation, before testing
+### No Arguments
 
-**Reference:** `references/requesting-code-review.md`
+If invoked WITHOUT arguments and no recent changes in context, ask the user with header "Review Target", question "What would you like to review?":
 
-### Receiving Feedback
-Trigger when:
-- Receiving code review comments from any source
-- Feedback seems unclear or technically questionable
-- Multiple review items need prioritization
-- External reviewer lacks full context
-- Suggestion conflicts with existing decisions
+| Option | Description |
+|--------|-------------|
+| Pending changes | Review staged/unstaged git diff |
+| Enter PR number | Fetch and review a specific PR |
+| Enter commit hash | Review a specific commit |
+| Full codebase scan | Deep codebase analysis |
+| Parallel codebase audit | Multi-reviewer codebase scan |
 
-**Reference:** `references/code-review-reception.md`
+## Core Principle
 
-### Requesting Review
-Trigger when:
-- Completing tasks in agent-driven development (after EACH task)
-- Finishing major features or refactors
-- Before merging to main branch
-- Stuck and need fresh perspective
-- After fixing complex bugs
+**YAGNI**, **KISS**, **DRY** always. Technical correctness over social comfort.
+**Be honest, be brutal, straight to the point, and be concise.**
 
-**Reference:** `references/requesting-code-review.md`
+Verify before implementing. Ask before assuming. Evidence before claims.
 
-### Verification Gates
-Trigger when:
-- About to claim tests pass, build succeeds, or work is complete
-- Before committing, pushing, or creating PRs
-- Moving to next task
-- Any statement suggesting success/completion
-- Expressing satisfaction with work
+## Practices
 
-**Reference:** `references/verification-before-completion.md`
+| Practice | When | Reference |
+|----------|------|-----------|
+| **Spec compliance** | After implementing from plan/spec, BEFORE quality review | `references/spec-compliance-review.md` |
+| **Adversarial review** | Always-on Stage 3 — actively tries to break the code | `references/adversarial-review.md` |
+| Receiving feedback | Unclear feedback, external reviewers, needs prioritization | `references/code-review-reception.md` |
+| Requesting review | After tasks, before merge, stuck on problem | `references/requesting-code-review.md` |
+| Verification gates | Before any completion claim, commit, PR | `references/verification-before-completion.md` |
+| Edge case scouting | After implementation, before review | `references/edge-case-scouting.md` |
+| **Checklist review** | Pre-landing, `/ck-ship` pipeline, security audit | `references/checklist-workflow.md` |
+| **Task-managed reviews** | Multi-file features (3+ files), parallel reviewers, fix cycles | `references/task-management-reviews.md` |
 
 ## Quick Decision Tree
 
 ```
 SITUATION?
 │
-├─ Multi-file feature (3+ files)?
-│  └─ Run edge case scouting first → /ck-scout then request review
-│
-├─ Received feedback
-│  ├─ Unclear items? → STOP, ask for clarification first
-│  ├─ From human partner? → Understand, then implement
-│  └─ From external reviewer? → Verify technically before implementing
+├─ Input mode? → Resolve diff (references/input-mode-resolution.md)
+│   ├─ #PR / URL → fetch PR diff
+│   ├─ commit hash → git show
+│   ├─ --pending → git diff (staged + unstaged)
+│   ├─ codebase → full scan (references/codebase-scan-workflow.md)
+│   ├─ codebase parallel → parallel audit (references/parallel-review-workflow.md)
+│   └─ default → recent changes in context
 │
-├─ Completed work
-│  ├─ Major feature/task? → Request `code-reviewer` agent review
-│  └─ Before merge? → Request `code-reviewer` agent review
-│
-└─ About to claim status
-   ├─ Have fresh verification? → State claim WITH evidence
-   └─ No fresh verification? → RUN verification command first
+├─ Received feedback → STOP if unclear, verify if external, implement if human partner
+├─ Completed work from plan/spec:
+│   ├─ Stage 1: Spec compliance review (references/spec-compliance-review.md)
+│   │   └─ PASS? → Stage 2 │ FAIL? → Fix → Re-review Stage 1
+│   ├─ Stage 2: Code quality review (code-reviewer subagent)
+│   │   └─ Scout edge cases → Review standards, performance
+│   └─ Stage 3: Adversarial review (references/adversarial-review.md) [ALWAYS-ON]
+│       └─ Red-team the code → Adjudicate → Accept/Reject findings
+├─ Completed work (no plan) → Scout → Code quality → Adversarial review
+├─ Pre-landing / ship → Load checklists → Two-pass review → Adversarial review
+├─ Multi-file feature (3+ files) → Create review pipeline tasks (scout→review→adversarial→fix→verify)
+└─ About to claim status → RUN verification command FIRST
 ```
 
-## Edge Case Scouting
+### Three-Stage Review Protocol
 
-### When to Scout
-Before formal review of any multi-file feature (3+ files changed).
+**Stage 1 — Spec Compliance** (load `references/spec-compliance-review.md`)
+- Does code match what was requested?
+- Any missing requirements? Any unjustified extras?
+- MUST pass before Stage 2
 
-### Process
-1. Use `/ck-scout` to search for hidden code paths, edge inputs, error branches
-2. Document untested scenarios found
-3. Add tests or guards for critical edge cases
-4. Then proceed to formal `code-reviewer` review
+**Stage 2 — Code Quality** (code-reviewer subagent)
+- Only runs AFTER spec compliance passes
+- Standards, security, performance, edge cases
 
-### What to Look For
-- Null/undefined paths not covered by tests
-- Error branches lacking handlers
-- Boundary conditions (empty arrays, max values, concurrent calls)
-- Async race conditions
-- Permission/auth edge cases
+**Stage 3 — Adversarial Review** (load `references/adversarial-review.md`)
+- Runs AFTER Stage 2 passes, subject to scope gate (skip if <=2 files, <=30 lines, no security files)
+- Spawn adversarial reviewer with context anchoring (runtime, framework, context files)
+- Find: security holes, false assumptions, resource exhaustion, race conditions, supply chain, observability gaps
+- Output: Accept (must fix) / Reject (false positive) / Defer (GitHub issue) verdicts per finding
+- Critical findings block merge; re-reviews use fix-diff-only optimization
 
-## Task-Managed Review Pipeline (Multi-File Features)
+## Receiving Feedback
 
-For features spanning 3+ files, use a structured pipeline:
+**Pattern:** READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT
+No performative agreement. Verify before implementing. Push back if wrong.
 
-```
-scout → review → fix → verify
-```
+**Full protocol:** `references/code-review-reception.md`
 
-**Steps:**
-1. **Scout** - Use `/ck-scout` or `/ck-scout ext` to identify edge cases and gaps
-2. **Review** - Delegate to `code-reviewer` agent with full context
-3. **Fix** - Implement critical and important feedback
-4. **Verify** - Run tests, confirm fixes, then claim completion
+## Requesting Review
 
-Track progress using a checklist in your plan or task notes:
-```
-- [ ] Edge case scouting complete
-- [ ] `code-reviewer` review complete
-- [ ] Critical issues fixed
-- [ ] Verification passed
-```
+**When:** After each task, major features, before merge
 
-## Receiving Feedback Protocol
+**Process:**
+1. **Scout edge cases first** (see below)
+2. Get SHAs: `BASE_SHA=$(git rev-parse HEAD~1)` and `HEAD_SHA=$(git rev-parse HEAD)`
+3. Dispatch code-reviewer subagent with: WHAT, PLAN, BASE_SHA, HEAD_SHA, DESCRIPTION
+4. Fix Critical immediately, Important before proceeding
 
-### Response Pattern
-READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT
+**Full protocol:** `references/requesting-code-review.md`
 
-### Key Rules
-- No performative agreement: "You're absolutely right!", "Great point!", "Thanks for [anything]"
-- No implementation before verification
-- Restate requirement, ask questions, push back with technical reasoning, or just start working
-- If unclear: STOP and ask for clarification on ALL unclear items first
-- YAGNI check: search for usage before implementing suggested "proper" features
+## Edge Case Scouting
 
-**Full protocol:** `references/code-review-reception.md`
+**When:** After implementation, before requesting code-reviewer
 
-## Requesting Review Protocol
+**Process:**
+1. Invoke `/ck-scout` with edge-case-focused prompt
+2. Scout analyzes: affected files, data flows, error paths, boundary conditions
+3. Review scout findings for potential issues
+4. Address critical gaps before code review
 
-### When to Request
-- After each task in agent-driven development
-- After major feature completion
-- Before merge to main
+**Full protocol:** `references/edge-case-scouting.md`
 
-### Process
-1. Scout edge cases (3+ file features): use `/ck-scout` first
-2. Get git SHAs: `BASE_SHA=$(git rev-parse HEAD~1)` and `HEAD_SHA=$(git rev-parse HEAD)`
-3. Delegate to `code-reviewer` agent with: WHAT_WAS_IMPLEMENTED, PLAN_OR_REQUIREMENTS, BASE_SHA, HEAD_SHA, DESCRIPTION
-4. Act on feedback: Fix Critical immediately, Important before proceeding, note Minor for later
+## Task-Managed Review Pipeline
 
-**Full protocol:** `references/requesting-code-review.md`
+**When:** Multi-file features (3+ changed files), parallel code-reviewer scopes, review cycles with Critical fix iterations.
 
-## Verification Gates Protocol
+**Fallback:** Task tools (`TaskCreate`/`TaskUpdate`/`TaskGet`/`TaskList`) are CLI-only — unavailable in VSCode extension. If they error, use `TodoWrite` for tracking and run pipeline sequentially. Review quality is identical.
 
-### The Iron Law
-**NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE**
+**Pipeline:** scout → review → adversarial → fix → verify (each a Task with dependency chain)
+
+```
+TaskCreate: "Scout edge cases"         → pending
+TaskCreate: "Review implementation"    → pending, blockedBy: [scout]
+TaskCreate: "Adversarial review"       → pending, blockedBy: [review]
+TaskCreate: "Fix critical issues"      → pending, blockedBy: [adversarial]
+TaskCreate: "Verify fixes pass"        → pending, blockedBy: [fix]
+```
 
-### Gate Function
-IDENTIFY command → RUN full command → READ output → VERIFY confirms claim → THEN claim
+**Parallel reviews:** Spawn scoped code-reviewer subagents for independent file groups (e.g., backend + frontend). Fix task blocks on all reviewers completing.
 
-Skip any step = lying, not verifying
+**Re-review cycles:** If fixes introduce new issues, create cycle-2 review task. Limit 3 cycles, escalate to user after.
 
-### Requirements
-- Tests pass: Test output shows 0 failures
-- Build succeeds: Build command exit 0
-- Bug fixed: Test original symptom passes
-- Requirements met: Line-by-line checklist verified
+**Full protocol:** `references/task-management-reviews.md`
 
-### Red Flags - STOP
-Using "should"/"probably"/"seems to", expressing satisfaction before verification, committing without verification, trusting agent reports, ANY wording implying success without running verification
+## Verification Gates
+
+**Iron Law:** NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
+
+**Gate:** IDENTIFY command → RUN full → READ output → VERIFY confirms → THEN claim
+
+**Requirements:**
+- Tests pass: Output shows 0 failures
+- Build succeeds: Exit 0
+- Bug fixed: Original symptom passes
+- Requirements met: Checklist verified
+
+**Red Flags:** "should"/"probably"/"seems to", satisfaction before verification, trusting agent reports
 
 **Full protocol:** `references/verification-before-completion.md`
 
 ## Integration with Workflows
 
-- **Agent-Driven:** Scout edge cases first (3+ files), review after EACH task, verify before moving to next
-- **Pull Requests:** Scout → verify tests pass → request `code-reviewer` review before merge
-- **General:** Apply verification gates before any status claims, push back on invalid feedback
-- **Pipeline:** For complex features use the full `scout → review → fix → verify` pipeline
+- **Subagent-Driven:** Scout → Review → Adversarial → Verify before next task
+- **Pull Requests:** Scout → Code quality → Adversarial → Merge
+- **Task Pipeline:** Create review tasks with dependencies → auto-unblock through chain
+- **Cook Handoff:** Cook completes phase → review pipeline tasks (incl. adversarial) → all complete → cook proceeds
+- **PR Review:** `/code-review #123` → fetch diff → full 3-stage review on PR changes
+- **Commit Review:** `/code-review abc1234` → review specific commit with full pipeline
+
+## Codebase Analysis Subcommands
+
+| Subcommand | Reference | Purpose |
+|------------|-----------|---------|
+| `/ck-code-review codebase` | `references/codebase-scan-workflow.md` | Scan & analyze the codebase |
+| `/ck-code-review codebase parallel` | `references/parallel-review-workflow.md` | Ultrathink edge cases, then parallel verify |
 
 ## Bottom Line
 
-1. **Scout first** - Edge cases found before review save rework cycles
-2. Technical rigor over social performance - No performative agreement
-3. Systematic review processes - Use `code-reviewer` agent via pipeline
-4. Evidence before claims - Verification gates always
+1. Resolve input mode first — know WHAT you're reviewing
+2. Technical rigor over social performance
+3. Scout edge cases before review
+4. Adversarial review on EVERY review — no exceptions
+5. Evidence before claims
 
-Scout. Verify. Question. Then implement. Evidence. Then claim.
+Verify. Scout. Red-team. Question. Then implement. Evidence. Then claim.

package/templates/repo/.github/skills/code-review/references/adversarial-review.md

@@ -0,0 +1,223 @@
+---
+name: adversarial-review
+description: Stage 3 red-team review that actively tries to break code — finds security holes, false assumptions, failure modes, race conditions. Spawns adversarial reviewer subagent with destructive mindset. Includes scope gate for trivial changes.
+---
+
+# Adversarial Review (Stage 3)
+
+Runs after every Stage 2 (Code Quality) pass. Subject to scope gate below.
+
+## Scope Gate
+
+Skip adversarial review when ALL of these are true:
+- Changed files <= 2
+- Lines changed <= 30
+- No security-sensitive files touched (auth, crypto, input parsing, SQL, env)
+- No new dependencies added
+
+When skipped, note: `Adversarial: skipped (below threshold)` in review output.
+
+**NEVER skip when:**
+- Any file in: `auth/`, `middleware/`, `security/`, `crypto/`
+- `package.json`, `package-lock.json`, or lockfile changed
+- Environment variables added/changed
+- Database schema modified
+- API route added/changed
+
+## Mindset
+
+> "You are hired to tear apart the implementer's work. Your job is to find every way this code can fail, be exploited, or produce incorrect results. Assume the implementer made mistakes. Prove it."
+
+This is NOT a standard code review. Standard reviews check if code meets requirements. Adversarial review assumes requirements are met and asks: **"How can this still break?"**
+
+## What to Attack
+
+### Security Holes
+- Injection vectors (SQL, command, XSS, template)
+- Auth bypass paths (missing checks, privilege escalation)
+- Secrets exposure (logs, error messages, stack traces)
+- Input trust boundaries (user input treated as safe)
+- SSRF, path traversal, deserialization attacks
+
+### False Assumptions
+- "This will never be null" -- prove it can be
+- "This list always has elements" -- find the empty case
+- "Users always call A before B" -- find the out-of-order path
+- "This config value exists" -- find the missing env var
+- "This third-party API always returns 200" -- find the failure mode
+- "This API shape won't change" -- find the breaking caller
+
+### Failure Modes & Resource Exhaustion
+- What happens when disk is full?
+- What happens when network times out mid-operation?
+- What happens when the database connection drops during a transaction?
+- Unbounded allocations from user-controlled input
+- Missing timeouts on external calls
+- Event loop blocking (sync operations in async context)
+- Connection/handle leaks on error paths
+- Regex catastrophic backtracking (ReDoS)
+
+### Race Conditions
+- Shared mutable state without locks
+- Time-of-check-to-time-of-use (TOCTOU)
+- Async operations with implicit ordering assumptions
+- Cache invalidation during concurrent writes
+
+### Data Corruption
+- Partial writes on failure (no transaction/rollback)
+- Type coercion surprises (string "0" as falsy)
+- Floating point comparison for equality
+- Timezone-naive datetime operations
+
+### Supply Chain & Dependencies
+- New dependencies: postinstall scripts, maintainer reputation, bundle size
+- Lockfile changes: version drift, removed integrity hashes
+- Transitive deps pulling in known-vulnerable packages
+
+### Observability Blind Spots
+- Swallowed errors (`catch {}` with no log)
+- Missing structured context in error logs
+- PII in log output
+
+## Process
+
+### 1. Spawn Adversarial Reviewer
+
+Dispatch `code-reviewer` subagent with adversarial prompt:
+
+```
+You are an adversarial code reviewer. Your ONLY job is to find ways this code
+can fail, be exploited, or produce incorrect results.
+
+DO NOT praise the code. DO NOT note what works well.
+ONLY report problems. If you find nothing, say "No findings" -- but try harder first.
+
+Focus on ADDED/MODIFIED lines (+ prefix in diff). Pre-existing code is out of scope
+unless the change makes it newly exploitable.
+
+Context (read for understanding, DO NOT review):
+{CONTEXT_FILES}
+
+Runtime: {RUNTIME} (e.g., Node.js single-threaded, browser, serverless)
+Framework: {FRAMEWORK} (e.g., Express with global error handler at app.ts:45)
+
+Review this diff:
+{DIFF}
+
+Changed files: {FILES}
+
+Attack vectors to check:
+1. Security holes (injection, auth bypass, secrets exposure)
+2. False assumptions (null, empty, ordering, config, API contracts)
+3. Failure modes + resource exhaustion (timeouts, leaks, unbounded input)
+4. Race conditions (shared state, TOCTOU, async ordering)
+5. Data corruption (partial writes, type coercion, encoding)
+6. Supply chain (new deps, lockfile changes, transitive vulns)
+7. Observability (swallowed errors, missing logs, PII in output)
+
+For each finding, report:
+- SEVERITY: Critical / Medium / Low
+- CATEGORY: Security / Assumption / Failure / Race / Data / Supply / Observability
+- LOCATION: file:line
+- ATTACK: How to trigger the problem
+- IMPACT: What happens when triggered
+- FIX: Describe the fix approach (e.g., "add null check before line 42").
+  Do NOT write implementation code -- the implementer has full context.
+```
+
+**If adversarial produces >10 findings on <100 lines changed:** likely too aggressive. Batch-reject noise, deep-review only Critical/Medium.
+
+### 2. Adjudicate Findings
+
+Main agent reviews each adversarial finding and assigns verdict:
+
+| Verdict | Meaning | Action |
+|---------|---------|--------|
+| **Accept** | Valid flaw, reproducible or clearly reasoned | Must fix before merge |
+| **Reject** | False positive, already handled, or impossible path | Document why, no action |
+| **Defer** | Valid but low-risk, tracked for later | Create GitHub issue for tracking |
+
+**Rules:**
+- Every finding gets a verdict -- no silent dismissals
+- Critical findings: Accept unless you can PROVE false positive
+- Benefit of doubt goes to the adversary (safer to fix than to dismiss)
+- If >50% of findings are Rejected, the adversary was too aggressive -- but still report all
+
+**Calibration examples:**
+
+| Verdict | Example | Reasoning |
+|---------|---------|-----------|
+| Accept | "SQL injection via string interpolation in query builder" | Clearly exploitable, concrete path shown |
+| Reject | "Missing null check on config.apiUrl" | Config loaded at startup with schema validation (see config.ts:12), cannot be null at runtime |
+| Defer | "No rate limiting on POST /api/upload" | Valid concern but internal-only tool currently; track for public exposure |
+
+### 3. Report Format
+
+```
+## Adversarial Review -- Stage 3
+
+### Summary
+- Findings: N total (X Critical, Y Medium, Z Low)
+- Accepted: A (must fix)
+- Rejected: B (false positive)
+- Deferred: C (tracked via GitHub issues)
+
+### Accepted Findings (Must Fix)
+
+#### [1] SEVERITY -- CATEGORY -- file:line
+**Attack:** How to trigger
+**Impact:** What happens
+**Fix:** Approach description
+**Verdict:** Accept -- [reason]
+
+### Rejected Findings
+
+#### [N] SEVERITY -- CATEGORY -- file:line
+**Attack:** Claimed vector
+**Verdict:** Reject -- [reason this is a false positive]
+
+### Deferred Findings
+
+#### [N] SEVERITY -- CATEGORY -- file:line
+**Attack:** How to trigger
+**Verdict:** Defer -- [reason] → GitHub issue #X
+```
+
+### 4. Fix Accepted Findings
+
+- Critical: Block merge. Fix immediately via `/fix` or manual edit.
+- Medium: Fix before merge if feasible. Defer only with explicit user approval.
+- Low: Track. Fix in follow-up if pattern repeats.
+
+### Re-review Optimization
+
+On fix cycles (re-running after accepted findings were fixed):
+- Only pass the FIX diff to adversarial, not the full original diff
+- Verify accepted findings are resolved
+- Check for regression: did the fix introduce new issues?
+
+## Integration with Pipeline
+
+```
+Stage 1 (Spec) → PASS
+  ↓
+Stage 2 (Quality) → PASS
+  ↓
+Scope gate → below threshold? → skip (note in report)
+  ↓ (above threshold)
+Stage 3 (Adversarial) → findings
+  ├─ 0 Accepted → PASS → proceed
+  ├─ Accepted Critical → BLOCK → fix → re-run Stage 3 (fix diff only)
+  └─ Accepted Medium/Low only → fix or defer → proceed
+```
+
+**Task pipeline update:** When using task-managed reviews, adversarial review gets its own task between "Review implementation" and "Fix critical issues".
+
+## What This Is NOT
+
+- NOT a style review (Stage 2 handles that)
+- NOT a spec compliance check (Stage 1 handles that)
+- NOT dependency graph analysis or import tracing (scout handles that)
+- NOT a general "suggestions for improvement" pass
+
+This is a focused, hostile attempt to break the code. If the code survives, it's ready to ship.

package/templates/repo/.github/skills/code-review/references/checklist-workflow.md

@@ -0,0 +1,100 @@
+# Checklist-Based Review Workflow
+
+How to apply structured review checklists during code review.
+
+## When to Use
+
+- Pre-landing review (from `/ck-ship` pipeline)
+- Explicit request for checklist review
+- Security audit before release
+- Code-reviewer agent when reviewing significant changes (10+ files or security-sensitive)
+
+## Workflow
+
+### 1. Auto-Detect Project Type
+
+```bash
+# Check for web app frameworks
+if grep -qE '"(react|vue|svelte|next|nuxt|angular)"' package.json 2>/dev/null; then
+  echo "web-app"
+# Check for API patterns
+elif ls src/routes/ src/api/ src/controllers/ app/controllers/ 2>/dev/null | head -1; then
+  echo "api"
+else
+  echo "base-only"
+fi
+```
+
+### 2. Load Checklists
+
+Always load: `checklists/base.md`
+
+Overlay based on detection:
+- `web-app` → also load `checklists/web-app.md`
+- `api` → also load `checklists/api.md`
+- Both detected → load both overlays
+
+### 3. Get the Diff
+
+```bash
+git fetch origin main --quiet
+git diff origin/main
+```
+
+**CRITICAL:** Read the FULL diff before flagging anything. Checklist suppressions require full context.
+
+### 4. Two-Pass Review
+
+**Pass 1 (CRITICAL) — Run first:**
+- Scan diff against ALL critical categories (base + overlays)
+- Each finding must include: `[file:line]`, problem, fix
+- These block `/ship` pipeline
+
+**Pass 2 (INFORMATIONAL) — Run second:**
+- Scan diff against ALL informational categories (base + overlays)
+- Same format: `[file:line]`, problem, fix
+- Included in PR body but don't block
+
+### 5. Check Suppressions
+
+Before reporting any finding, verify it's NOT in the suppressions list (bottom of `base.md`).
+
+Key suppressions:
+- Already addressed in the diff
+- Readability-aiding redundancy
+- Style/formatting issues
+- "Consider using X" when Y works fine
+
+### 6. Output
+
+```
+Pre-Landing Review: N issues (X critical, Y informational)
+
+**CRITICAL** (blocking):
+- [src/auth/login.ts:42] SQL injection via string interpolation in user lookup
+  Fix: Use parameterized query: `db.query('SELECT * FROM users WHERE email = $1', [email])`
+
+**Issues** (non-blocking):
+- [src/api/users.ts:88] Magic number 30 for pagination limit
+  Fix: Extract to constant `DEFAULT_PAGE_SIZE = 30`
+```
+
+### 7. Critical Issue Resolution
+
+For each critical issue, ask the user:
+- Problem with `file:line`
+- Recommended fix
+- Options:
+  - A) Fix now (recommended)
+  - B) Acknowledge and proceed
+  - C) False positive — skip
+
+If user chose A (fix): apply fixes, commit, then re-run tests before continuing.
+
+## Integration with /ck-ship
+
+The ship pipeline calls this workflow at Step 4. Critical findings block the pipeline. Informational findings are included in the PR body.
+
+## Integration with /ck-code-review
+
+When invoked as part of standard code review, the checklist augments (not replaces) the existing scout → review → fix → verify pipeline. Checklist findings are merged with code-reviewer's own findings.