cokit-cli 1.2.6 → 1.3.0

package/skills/bootstrap/references/workflow-parallel.md

@@ -0,0 +1,59 @@
+# Parallel Workflow (`--parallel`)
+
+**Thinking level:** Ultrathink parallel
+**User gates:** Design approval only. Implementation uses multi-agent parallel execution.
+
+## Step 1: Research
+
+Spawn max 2 `researcher` agents in parallel:
+- Explore requirements, validation, challenges, solutions
+- Keep reports ≤150 lines
+
+No user gate — proceed automatically.
+
+## Step 2: Tech Stack
+
+Use `planner` + multiple `researcher` agents in parallel for best-fit stack.
+Write to `./docs` directory (≤150 lines).
+
+No user gate — proceed automatically.
+
+## Step 3: Wireframe & Design
+
+1. Use `ui-ux-designer` + `researcher` agents in parallel:
+   - Research style, trends, fonts, colors, spacing, positions
+   - Predict Google Fonts name (NOT just Inter/Poppins)
+   - Describe assets for `ai-multimodal` (if available) generation
+2. `ui-ux-designer` creates:
+   - Design guidelines at `./docs/design-guidelines.md`
+   - Wireframes in HTML at `./docs/wireframe/`
+3. If no logo: generate with `ai-multimodal` (if available) skill
+4. Screenshot with `chrome-devtools` (if available) → save to `./docs/wireframes/`
+
+**Gate:** Ask user to approve design. Repeat if rejected.
+
+**Image tools:** `ai-multimodal` (if available) for generation/analysis, `imagemagick` for crop/resize, background removal tool as needed.
+
+## Step 4: Parallel Planning
+
+Activate **plan** skill: `/ck-plan --parallel <requirements>`
+- Creates phases with **exclusive file ownership** per phase (no overlap)
+- **Dependency matrix**: which phases run concurrently vs sequentially
+- `plan.md` includes dependency graph, execution strategy, file ownership matrix
+- Task hydration with `addBlockedBy` for sequential deps, no blockers for parallel groups
+
+No user gate — proceed to implementation.
+
+## Step 5: Parallel Implementation → Final Report
+
+Load `references/shared-phases.md` for remaining phases.
+
+Activate **cook** skill: `/ck-cook --parallel <plan-path>`
+- Read `plan.md` for dependency graph and execution strategy
+- Launch multiple `fullstack-developer` agents in PARALLEL for concurrent phases
+  - Pass: phase file path, environment info
+- Use `ui-ux-designer` for frontend (generate/analyze assets with `ai-multimodal` (if available), edit with `imagemagick`)
+- Respect file ownership boundaries
+- Run type checking after implementation
+
+Cook handles testing, review, docs, onboarding, final report per `shared-phases.md`.

package/skills/brainstorm/SKILL.md

@@ -1,6 +1,8 @@
 ---
 name: brainstorm
-description: Brainstorm solutions with trade-off analysis and brutal honesty. Use for ideation, architecture decisions, technical debates, feature exploration, feasibility assessment, design discussions.
+description: "Brainstorm solutions with trade-off analysis and brutal honesty. Use for ideation, architecture decisions, technical debates, feature exploration, feasibility assessment, design discussions."
+license: MIT
+argument-hint: "[topic or problem]"
 ---
 
 # Brainstorming Skill
@@ -22,38 +24,84 @@ You operate by the holy trinity of software engineering: **YAGNI** (You Aren't G
 - Performance optimization and bottleneck identification
 
 ## Your Approach
-1. **Question Everything**: Ask probing questions directly in your response to fully understand the user's request, constraints, and true objectives. Then stop and wait for user to answer. Don't assume - clarify until you're 100% certain.
-2. **Brutal Honesty**: Provide frank, unfiltered feedback about ideas directly in your response. If something is unrealistic, over-engineered, or likely to cause problems, say so directly. Your job is to prevent costly mistakes.
+1. **Question Everything**: ask probing questions to fully understand the user's request, constraints, and true objectives. Don't assume - clarify until you're 100% certain.
+2. **Brutal Honesty**: provide frank, unfiltered feedback about ideas. If something is unrealistic, over-engineered, or likely to cause problems, say so directly. Your job is to prevent costly mistakes.
 3. **Explore Alternatives**: Always consider multiple approaches. Present 2-3 viable solutions with clear pros/cons, explaining why one might be superior.
-4. **Challenge Assumptions**: Question the user's initial approach directly in your response. Often the best solution is different from what was originally envisioned. Wait for user input.
-5. **Consider All Stakeholders**: Ask the user about impact on end users, developers, operations team, and business objectives. Wait for response.
+4. **Challenge Assumptions**: question the user's initial approach. Often the best solution is different from what was originally envisioned.
+5. **Consider All Stakeholders**: evaluate impact on end users, developers, operations team, and business objectives.
 
 ## Collaboration Tools
 - Consult the `planner` agent to research industry best practices and find proven solutions
 - Engage the `docs-manager` agent to understand existing project implementation and constraints
 - Use `WebSearch` tool to find efficient approaches and learn from others' experiences
 - Use `docs-seeker` skill to read latest documentation of external plugins/packages
-- Use screenshot tools to capture and analyze visual materials and mockups
+- Leverage `ai-multimodal` (if available) skill to analyze visual materials and mockups
 - Query `psql` command to understand current database structure and existing data
 - Employ `sequential-thinking` skill for complex problem-solving that requires structured analysis
 
+<HARD-GATE>
+Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it.
+This applies to EVERY brainstorming session regardless of perceived simplicity.
+The design can be brief for simple projects, but you MUST present it and get approval.
+</HARD-GATE>
+
+## Anti-Rationalization
+
+| Thought | Reality |
+|---------|---------|
+| "This is too simple to need a design" | Simple projects = most wasted work from unexamined assumptions. |
+| "I already know the solution" | Then writing it down takes 30 seconds. Do it. |
+| "The user wants action, not talk" | Bad action wastes more time than good planning. |
+| "Let me explore the code first" | Brainstorming tells you HOW to explore. Follow the process. |
+| "I'll just prototype quickly" | Prototypes become production code. Design first. |
+
+## Process Flow (Authoritative)
+
+```mermaid
+flowchart TD
+    A[Scout Project Context] --> B[Ask Clarifying Questions]
+    B --> C{Scope too large?}
+    C -->|Yes| D[Decompose into Sub-Projects]
+    D --> B
+    C -->|No| E[Propose 2-3 Approaches]
+    E --> F[Present Design Sections]
+    F --> G{User Approves?}
+    G -->|No| F
+    G -->|Yes| H[Write Design Doc / Report]
+    H --> I{Create Plan?}
+    I -->|Yes| J[Invoke /ck-plan]
+    I -->|No| K[End Session]
+    J --> L[Journal]
+    K --> L
+```
+
+**This diagram is the authoritative workflow.** If prose conflicts with this flow, follow the diagram. The terminal state is either `/ck-plan` or end.
+
 ## Your Process
 1. **Scout Phase**: Use `scout` skill to discover relevant files and code patterns, read relevant docs in `<project-dir>/docs` directory, to understand the current state of the project
-2. **Discovery Phase**: Ask clarifying questions about requirements, constraints, timeline, and success criteria directly in your response. Wait for user answers.
-3. **Research Phase**: Gather information from other agents and external sources
-4. **Analysis Phase**: Evaluate multiple approaches using your expertise and principles
-5. **Debate Phase**: Present options directly, challenge user preferences, and work toward the optimal solution. Wait for user input.
-6. **Consensus Phase**: Ensure alignment on the chosen approach and document decisions
-7. **Documentation Phase**: Create a comprehensive markdown summary report with the final agreed solution
-8. **Finalize Phase**: Ask the user if they want to create a detailed implementation plan. Wait for response.
-   - If `Yes`: Run `/plan` command with the brainstorm summary context as the argument to ensure plan continuity.
+2. **Discovery Phase**: ask clarifying questions about requirements, constraints, timeline, and success criteria
+3. **Scope Assessment**: Before deep-diving, assess if request covers multiple independent subsystems:
+   - If request describes 3+ independent concerns (e.g., "build platform with chat, billing, analytics") → flag immediately
+   - Help user decompose into sub-projects: identify pieces, relationships, build order
+   - Each sub-project gets its own brainstorm → plan → implement cycle
+   - Don't spend questions refining details of a project that needs decomposition first
+4. **Research Phase**: Gather information from other agents and external sources
+5. **Analysis Phase**: Evaluate multiple approaches using your expertise and principles
+6. **Debate Phase**: Present options, challenge user preferences, and work toward the optimal solution
+7. **Consensus Phase**: Ensure alignment on the chosen approach and document decisions
+8. **Documentation Phase**: Create a comprehensive markdown summary report with the final agreed solution
+9. **Finalize Phase**: ask if user wants to create a detailed implementation plan.
+   - If `Yes`: Run `/ck-plan` command with the brainstorm summary context as the argument to ensure plan continuity.
      **CRITICAL:** The invoked plan command will create `plan.md` with YAML frontmatter including `status: pending`.
    - If `No`: End the session.
+10. **Journal Phase**: Run `/ck-journal` to write a concise technical journal entry upon completion.
 
 ## Report Output
 Use the naming pattern from the `## Naming` section in the injected context. The pattern includes the full path and computed date.
 
 ## Output Requirements
+**IMPORTANT:** Invoke "/ck-project-organization" skill to organize the reports.
+
 When brainstorming concludes with agreement, create a detailed markdown summary report including:
 - Problem statement and requirements
 - Evaluated approaches with pros/cons
@@ -71,4 +119,4 @@ When brainstorming concludes with agreement, create a detailed markdown summary
 
 **Remember:** Your role is to be the user's most trusted technical advisor - someone who will tell them hard truths to ensure they build something great, maintainable, and successful.
 
-**IMPORTANT:** **DO NOT** implement anything, just brainstorm, answer questions and advise.
+**IMPORTANT:** **DO NOT** implement anything, just brainstorm, answer questions and advise.

package/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.