cokit-cli 1.2.4 → 1.2.7

package/docs/cokit-team-presentation.md

@@ -1,9 +1,9 @@
 # CoKit: Team Presentation
 
-**Date:** February 10, 2026 (v1.2.0)
+**Date:** February 25, 2026 (v1.2.6)
 **Presenter:** [Your Name]
 **Repository:** https://github.com/camping89/cokit
-**Version:** 1.2.0
+**Version:** 1.2.6
 
 ---
 
@@ -18,7 +18,7 @@
 - Project-specific context
 
 **Solution:** CoKit ports proven Claude Code workflow patterns to GitHub Copilot via:
-- 27 prompts with unified `ck-*` namespace (ClaudeKit + SpecKit) using `mode: agent`
+- 25 prompts with unified `ck-*` namespace (ClaudeKit + SpecKit) using `mode: agent`
 - 27 skills teaching Copilot best practices (debugging, code-review, planning, frontend-design, databases, devops, etc.)
 - 12 specialized agents (including code-simplifier, fullstack-developer, ui-ux-designer)
 - 5 instructions (backend, frontend, testing, development, research)
@@ -79,7 +79,7 @@
 │   ┌─────────────────────────────────────────────────────────┐ │
 │   │ ✓ .github/copilot-instructions.md                       │ │
 │   │ ✓ .github/AGENTS.md                                     │ │
-│   │ ✓ .github/prompts/ck-*.prompt.md (27 prompts)           │ │
+│   │ ✓ .github/prompts/ck-*.prompt.md (25 prompts)           │ │
 │   │ ✓ .github/instructions/ck-*.instructions.md (5 files)   │ │
 │   │ ✓ .github/collections/ck-*.collection.yml (5 bundles)   │ │
 │   │ ✓ .vscode/settings.json                                 │ │
@@ -158,8 +158,6 @@ your-project/
 | Command | Description |
 |---------|-------------|
 | `npx cokit-cli init` | Interactive setup wizard |
-| `npx cokit-cli init -g` | Install personal skills only |
-| `npx cokit-cli init -a` | Both project + personal |
 | `npx cokit-cli add <skill>` | Add specific skill |
 | `npx cokit-cli list` | Show installed components |
 | `npx cokit-cli doctor` | Diagnose setup issues |
@@ -175,7 +173,7 @@ your-project/
 **SpecKit (ck-spec-*):** Spec-driven workflow commands
 - `/ck-spec-specify`, `/ck-spec-clarify`, `/ck-spec-plan`, `/ck-spec-tasks`, `/ck-spec-implement`, etc.
 
-All 27 prompts unified in single namespace with cross-navigation support.
+All 25 prompts unified in single namespace with cross-navigation support.
 
 ---
 

package/docs/guide-next-steps-speckit-cokit-implementation.md

@@ -1,7 +1,7 @@
 # Next Steps Guide: Spec-Kit + Cokit Implementation
 
 **Created:** Feb 3, 2026
-**Status:** COMPLETE (v1.2.0 released with SpecKit integration)
+**Status:** COMPLETE (v1.2.6 released with SpecKit integration)
 
 ---
 

package/docs/migration-guide.md

@@ -102,7 +102,7 @@ After fixing:
 
 1. Install CoKit:
    ```bash
-   npx cokit-cli init -a
+   npx cokit-cli init
    ```
 
 2. Use prompts directly:

package/docs/project-overview-pdr.md

@@ -10,7 +10,7 @@ Make GitHub Copilot smarter in 30 seconds via curated prompts, agents, and workf
 
 ## Solution
 CoKit CLI installs pre-built resources to `~/.copilot/`:
-- **27 prompts**: ClaudeKit (ck-*) + SpecKit (ck-spec-*)
+- **25 prompts**: ClaudeKit (ck-*) + SpecKit (ck-spec-*)
 - **12 agents**: brainstormer, planner, tester, code-simplifier, fullstack-developer, ui-ux-designer, etc.
 - **27 skills**: debugging, planning, code-review, frontend-design, databases, devops, etc.
 - **5 collections**: bundled workflows
@@ -22,7 +22,7 @@ CoKit CLI installs pre-built resources to `~/.copilot/`:
 | Two Workflows | `ck-*` (flexible) vs `ck-spec-*` (spec-driven) |
 | Sync Pipeline | Auto-merge upstream ClaudeKit + SpecKit |
 | Navigation | Cross-command suggestions in all prompts |
-| Global Install | Single `npx cokit-cli init -g` command |
+| Install | Single `npx cokit-cli init` command |
 
 ## Target Users
 - Developers using GitHub Copilot

package/docs/project-roadmap.md

@@ -1,9 +1,9 @@
 # CoKit Project Roadmap
 
 **Project:** CoKit - Claude Code to GitHub Copilot Port
-**Version:** 1.2.4
+**Version:** 1.2.6
 **Start Date:** 2026-01-06
-**Last Updated:** 2026-02-12 (video intro + flowchart UX)
+**Last Updated:** 2026-02-25 (agents/prompts/skills Copilot alignment)
 **Current Phase:** 6 of 6 (COMPLETE)
 **Overall Progress:** 100%
 
@@ -12,7 +12,7 @@
 CoKit makes it dead-simple for non-technical users to port Claude Code workflow patterns to GitHub Copilot with a single command: `npx cokit-cli init`.
 
 ### Key Features (Current)
-- 27 prompt files with `ck-` and `ck-spec-` prefixes
+- 25 prompt files with `ck-` and `ck-spec-` prefixes
 - 27 specialized skills (debugging, code-review, planning, frontend-design, databases, devops, etc.)
 - 12 expert agents (planner, code-reviewer, debugger, tester, code-simplifier, fullstack-developer, ui-ux-designer, etc.)
 - 5 instructions (backend, frontend, testing, development, research)
@@ -60,7 +60,7 @@ CoKit makes it dead-simple for non-technical users to port Claude Code workflow
 **Status:** COMPLETE (2026-01-06, Enhanced 2026-02-10)
 **Effort:** 4h
 **Deliverables:**
-- 27 prompt files from ClaudeKit + SpecKit
+- 25 prompt files from ClaudeKit + SpecKit
   - ClaudeKit: `ck-fix`, `ck-plan`, `ck-cook`, `ck-test`, `ck-review`, etc.
   - SpecKit: `ck-spec-specify`, `ck-spec-clarify`, `ck-spec-plan`, `ck-spec-tasks`, etc.
 - Unified namespace: `ck-*` for all commands
@@ -93,7 +93,7 @@ CoKit makes it dead-simple for non-technical users to port Claude Code workflow
 **Deliverables:**
 - Removed non-coding resources
 - Consolidated documentation with updated counts
-- Updated all CLI references: `cokit` → `cokit-cli`, `--global` → `-g`, `--all` → `-a`
+- Updated all CLI references: `cokit` → `cokit-cli`, removed `-g`/`--global` flag
 - Updated version references to 1.0.8
 - Fixed broken links (README.FLOW.md, FAQ.md)
 - Added real CoKit examples throughout docs
@@ -312,6 +312,5 @@ None at completion. All functional requirements satisfied.
 
 ---
 
-**Last Updated:** 2026-02-12
-**Project Manager:** project-manager agent
-**Status:** ALL PHASES COMPLETE - v1.2.4 RELEASED
+**Last Updated:** 2026-02-25
+**Status:** ALL PHASES COMPLETE - v1.2.6 RELEASED

package/docs/system-architecture.md

@@ -37,8 +37,6 @@
 │                    CLI (npx cokit-cli)                       │
 ├─────────────────────────────────────────────────────────────┤
 │  bin/cokit.js → src/index.js                                │
-│  ├── init -g    → Install to ~/.copilot/                    │
-│  ├── init -a    → Install global + project                  │
 │  └── init       → Interactive setup                         │
 └─────────────────────────────────────────────────────────────┘
 ```
@@ -57,7 +55,7 @@
 
 ### CLI Install
 ```
-1. User runs: npx cokit-cli init -g
+1. User runs: npx cokit-cli init
 2. CLI copies: prompts/, agents/, skills/, instructions/, collections/
 3. Target: ~/.copilot/
 4. User gets: All ck-* commands in Copilot

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cokit-cli",
-  "version": "1.2.4",
+  "version": "1.2.7",
   "description": "Make GitHub Copilot smarter in 30 seconds",
   "main": "src/index.js",
   "bin": {

package/prompts/ck-ask.prompt.md

@@ -36,7 +36,7 @@ You operate by the holy trinity of software engineering: **YAGNI** (You Aren't G
 
 ## Process
 1. **Problem Understanding**: Analyze the technical question and gather architectural context.
-   - If the architecture context doesn't contain the necessary information, use [`SlashCommand(/scout)`](`$HOME/.copilot/commands/scout.md`) to scout the codebase again.
+   - If the architecture context doesn't contain the necessary information, use `/ck-scout` to scout the codebase again.
 2. **Expert Consultation**:
    - Systems Designer: Define system boundaries, data flows, and component relationships
    - Technology Strategist: Evaluate technology choices, patterns, and industry best practices

package/prompts/ck-bootstrap.prompt.md

@@ -115,7 +115,7 @@ Follow strictly these following steps:
   * Create/update `./docs/project-overview.-pdr.md` (Product Development Requirements) file.
   * Create/update `./docs/code-standards.md` file.
   * Create/update `./docs/system-architecture.md` file.
-* Use `project-manager` agent to create a project roadmap at `./docs/project-roadmap.md` file & project progress and task status in the given plan file.
+* Create a project roadmap at `./docs/project-roadmap.md` file & update project progress and task status in the given plan file.
 * **IMPORTANT:** Sacrifice grammar for the sake of concision when writing outputs.
 
 ### Onboarding

package/prompts/ck-cook.prompt.md

@@ -56,21 +56,21 @@ Human review required at these checkpoints (skipped with `--auto`):
 **Always enforced (all modes):**
 - **Testing:** 100% pass required (unless no-test mode)
 - **Code Review:** User approval OR auto-approve (score≥9.5, 0 critical)
-- **Finalize:** project-manager AND docs-manager must complete
+- **Finalize:** docs-manager must complete
 
 ## Required Agents
 
 | Phase | Agent |
 |-------|-------|
-| Research | `@researcher` (parallel, optional in fast) |
-| Scout | `@scout` |
-| Plan | `@planner` |
-| UI Work | `@ui-ux-designer` |
-| Implement | `@fullstack-developer` (parallel mode) |
-| Simplify | `@code-simplifier` (post-implement) |
-| Testing | `@tester`, `@debugger` |
-| Review | `@code-reviewer` |
-| Finalize | `project-manager`, `@docs-manager`, `@git-manager` |
+| Research | `researcher` agent (parallel, optional in fast) |
+| Scout | `scout` agent |
+| Plan | `planner` agent |
+| UI Work | `ui-ux-designer` agent |
+| Implement | `fullstack-developer` agent (parallel mode) |
+| Simplify | `code-simplifier` agent (post-implement) |
+| Testing | `tester`, `debugger` agents |
+| Review | `code-reviewer` agent |
+| Finalize | `docs-manager`, `git-manager` agents |
 
 ## Process
 
@@ -78,8 +78,8 @@ Human review required at these checkpoints (skipped with `--auto`):
 2. **Scout**: Use `/ck-scout` to discover relevant files
 3. **Research** (if applicable): Gather technical context
 4. **Plan**: Create or load implementation plan
-5. **Implement**: Execute plan phases (use `@fullstack-developer` in parallel mode)
-6. **Simplify**: `@code-simplifier` refines implemented code for clarity
+5. **Implement**: Execute plan phases (use `fullstack-developer` agent in parallel mode)
+6. **Simplify**: `code-simplifier` agent refines implemented code for clarity
 7. **Test**: Run tests and validate
 8. **Review**: Code review with quality gates
 9. **Finalize**: Update docs, commit changes

package/prompts/ck-plan-hard.prompt.md

@@ -64,7 +64,7 @@ After plan creation, offer validation interview to confirm decisions before impl
 | `off` | Skip validation step entirely |
 
 **If mode is `prompt`:** Present the options above directly in your response and wait for user to choose.
-**If user chooses validation or mode is `auto`:** Execute `/ck-plan-validate {plan-path}` SlashCommand.
+**If user chooses validation or mode is `auto`:** Execute `/ck-plan-validate {plan-path}`.
 
 ## Context Reminder (MANDATORY)
 

package/prompts/ck-plan-red-team.prompt.md

@@ -0,0 +1,227 @@
+---
+agent: 'agent'
+description: 'Adversarial plan review — spawn hostile reviewers to find flaws, security holes, false assumptions, failure modes'
+argument-hint: 'Path to plan directory'
+---
+
+## Variant Notice
+**IMPORTANT — Read before proceeding.**
+`ck-plan-red-team` is an internal mode for adversarial plan review — it is meant to be selected automatically by AI when you run `/ck-plan`.
+You don't need to call this directly. Just use `/ck-plan` and AI will pick the right mode for you.
+Before executing, you MUST output the following message **exactly as written** and wait for user response:
+
+---
+**Variant Notice**
+
+`ck-plan-red-team` is an internal mode for adversarial plan review — it is meant to be selected automatically by AI when you run `/ck-plan`.
+You don't need to call this directly. Just use `/ck-plan` and AI will pick the right mode for you.
+
+Do you want to continue anyway, or switch to `/ck-plan`? **[Continue / Switch to /ck-plan]**
+
+---
+
+Only proceed if user explicitly confirms Continue.
+If user chooses "Switch to /ck-plan", run `/ck-plan` immediately — do NOT ask user to re-enter their input.
+
+## Your Mission
+
+Adversarially review an implementation plan by spawning parallel reviewer agents that try to tear it apart. Each reviewer adopts a different hostile lens. You then adjudicate findings, and the user decides which to apply.
+
+**Mindset:** Like hiring someone who hates the implementer to destroy their work.
+
+## Plan Resolution
+
+1. If `${input}` provided → Use that path
+2. Else check `## Plan Context` section → Use active plan path
+3. If no plan found → Ask user to specify path or run `/ck-plan` first
+
+## Workflow
+
+### Step 1: Read Plan Files
+
+Read the plan directory:
+- `plan.md` — Overview, phases, dependencies
+- `phase-*.md` — All phase files (full content)
+- Note: architecture decisions, assumptions, scope, risks, implementation steps
+
+Collect all plan file paths for reviewers to read directly.
+
+### Step 2: Scale Reviewer Count
+
+Scale reviewers based on plan complexity:
+
+| Phase Count | Reviewers | Lenses Selected |
+|-------------|-----------|-----------------|
+| 1-2 phases | 2 | Security Adversary + Assumption Destroyer |
+| 3-5 phases | 3 | + Failure Mode Analyst |
+| 6+ phases | 4 | + Scope & Complexity Critic (all lenses) |
+
+### Step 3: Define Adversarial Lenses
+
+Available lenses (select per Step 2):
+
+| Reviewer | Lens | Focus |
+|----------|------|-------|
+| **Security Adversary** | Attacker mindset | Auth bypass, injection, data exposure, privilege escalation, supply chain, OWASP top 10 |
+| **Failure Mode Analyst** | Murphy's Law | Race conditions, data loss, cascading failures, recovery gaps, deployment risks, rollback holes |
+| **Assumption Destroyer** | Skeptic | Unstated dependencies, false "will work" claims, missing error paths, scale assumptions, integration assumptions |
+| **Scope & Complexity Critic** | YAGNI enforcer | Over-engineering, premature abstraction, unnecessary complexity, missing MVP cuts, scope creep, gold plating |
+
+### Step 4: Spawn Reviewers
+
+Launch reviewers simultaneously using `code-reviewer` agents in parallel.
+
+**Each reviewer prompt MUST include:**
+1. This override: `"IGNORE your default code-review instructions. You are reviewing a PLAN DOCUMENT, not code. There is no code to lint, build, or test. Focus exclusively on plan quality."`
+2. Their specific adversarial lens and persona
+3. The plan file paths so they can read original files directly
+4. These instructions:
+
+```
+You are a hostile reviewer. Your job is to DESTROY this plan.
+Adopt the {LENS_NAME} perspective. Find every flaw you can.
+
+Rules:
+- Be specific: cite exact phase/section where the flaw lives
+- Be concrete: describe the failure scenario, not just "could be a problem"
+- Rate severity: Critical (blocks success) | High (significant risk) | Medium (notable concern)
+- Skip trivial observations (style, naming, formatting) — not worth reporting.
+- No praise. No "overall looks good". Only findings.
+- 5-10 findings per reviewer. Quality over quantity.
+
+Output format per finding:
+## Finding {N}: {title}
+- **Severity:** Critical | High | Medium
+- **Location:** Phase {X}, section "{name}"
+- **Flaw:** {what's wrong}
+- **Failure scenario:** {concrete description of how this fails}
+- **Evidence:** {quote from plan or missing element}
+- **Suggested fix:** {brief recommendation}
+```
+
+### Step 5: Collect, Deduplicate & Cap
+
+After all reviewers complete:
+1. Collect all findings
+2. Deduplicate overlapping findings (merge if same root issue)
+3. Sort by severity: Critical → High → Medium
+4. **Cap at 15 findings:** Keep all Critical, top High by specificity, note dropped Medium count
+
+### Step 6: Adjudicate
+
+For each finding, evaluate and propose a disposition:
+
+| Disposition | Meaning |
+|-------------|---------|
+| **Accept** | Valid flaw — plan should be updated |
+| **Reject** | False positive, acceptable risk, or already handled |
+
+**Adjudication format:**
+
+```markdown
+## Red Team Findings
+
+### Finding 1: {title} — {SEVERITY}
+**Reviewer:** {lens name}
+**Location:** {phase/section}
+**Flaw:** {description}
+**Failure scenario:** {concrete scenario}
+**Disposition:** Accept | Reject
+**Rationale:** {why accept/reject — be specific}
+```
+
+### Step 7: User Review
+
+Present the adjudicated findings to the user directly in your response. List all findings with their dispositions, then ask:
+
+> **Review red-team findings.** Which dispositions do you want to change?
+>
+> 1. **Looks good, apply accepted findings** — proceed with current Accept/Reject
+> 2. **Let me review each one** — walk through findings individually
+> 3. **Reject all, plan is fine** — discard all findings
+
+Wait for user response before proceeding.
+
+**If "Let me review each one":**
+For each finding marked Accept, present it and ask:
+- "Apply this fix to the plan?" with options: **Yes, apply** | **No, reject** | **Modify suggestion**
+
+**If "Modify suggestion":**
+Ask user: "Describe your modification to this finding's suggested fix:"
+Record the modified suggestion in the finding's "Suggested fix" field.
+Set disposition to "Accept (modified)" in the Red Team Review table.
+
+### Step 8: Apply to Plan
+
+For each accepted finding:
+1. Locate the target phase file and section
+2. Add the fix/note inline with a marker:
+   ```markdown
+   <!-- Red Team: {finding title} — {date} -->
+   ```
+3. If finding requires new content, add to the most relevant section
+4. If finding requires removing/changing content, edit in place
+
+After applying, add a `## Red Team Review` section to `plan.md`.
+If section already exists (repeat run), **append** a new session block — never overwrite history.
+
+**Placement order in plan.md** (bottom of file):
+1. `## Red Team Review` (before validation)
+2. `## Validation Log` (after red-team)
+
+This ordering matches the execution sequence: red-team → validate.
+
+```markdown
+## Red Team Review
+
+### Session — {YYYY-MM-DD}
+**Findings:** {total} ({accepted} accepted, {rejected} rejected)
+**Severity breakdown:** {N} Critical, {N} High, {N} Medium
+
+| # | Finding | Severity | Disposition | Applied To |
+|---|---------|----------|-------------|------------|
+| 1 | {title} | Critical | Accept | Phase 2 |
+| 2 | {title} | High | Reject | — |
+```
+
+## Output
+
+After completion, provide summary:
+- Total findings by severity
+- Accepted vs rejected count
+- Files modified
+- Key risks addressed
+- Remaining concerns (if any rejected findings were borderline)
+
+## Next Steps (MANDATORY)
+
+After providing the summary, remind the user:
+
+> **Plan updated with red-team findings.** Consider running:
+> ```
+> /ck-plan-validate {ABSOLUTE_PATH_TO_PLAN_DIR}/plan.md
+> ```
+> to re-validate decisions after changes, then:
+> ```
+> /ck-cook --auto {ABSOLUTE_PATH_TO_PLAN_DIR}/plan.md
+> ```
+> to implement.
+
+## Important Notes
+
+**IMPORTANT:** Reviewers must be HOSTILE, not helpful. No softening language.
+**IMPORTANT:** Deduplicate aggressively — reviewers will find overlapping issues.
+**IMPORTANT:** Adjudication must be evidence-based. Don't reject valid findings to be nice.
+**IMPORTANT:** If plan has a Validation Log from `/ck-plan-validate`, reviewers should check if validation answers introduced new assumptions.
+**IMPORTANT:** Sacrifice grammar for concision in reports.
+**IMPORTANT:** Reviewers read plan files directly — do NOT duplicate content in a summary.
+
+---
+
+## Suggested Next Steps
+
+| Command | Description |
+|---------|-------------|
+| `/ck-plan-validate` | Validate plan with critical questions |
+| `/ck-cook` | Implement the plan |
+| `/ck-plan` | Create or modify plan |

package/prompts/ck-simplify.prompt.md

@@ -1,5 +1,5 @@
 ---
-agent: 'code-simplifier'
+agent: 'agent'
 description: 'Simplify and refine code for clarity and maintainability'
 argument-hint: 'Scope: file path, git diff, or "recent changes"'
 ---

package/skills/code-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: code-review
-description: Review code quality, receive feedback with technical rigor, verify completion claims. Use before PRs, after implementing features, when claiming task completion, for agent reviews.
+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.
 ---
 
 # Code Review
@@ -9,13 +9,12 @@ Guide proper code review practices emphasizing technical rigor, evidence-based c
 
 ## Overview
 
-Code review requires three distinct practices:
-
-1. **Receiving feedback** - Technical evaluation over performative agreement
-2. **Requesting reviews** - Systematic review via code-reviewer agent
-3. **Verification gates** - Evidence before any completion claims
-
-Each practice has specific triggers and protocols detailed in reference files.
+| 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 |
 
 ## Core Principle
 
@@ -26,6 +25,15 @@ Always honoring **YAGNI**, **KISS**, and **DRY** principles.
 
 ## When to Use This Skill
 
+### Edge Case Scouting
+Trigger when:
+- Feature touches 3+ files
+- Implementing complex business logic
+- Before requesting formal code review
+- After implementation, before testing
+
+**Reference:** `references/requesting-code-review.md`
+
 ### Receiving Feedback
 Trigger when:
 - Receiving code review comments from any source
@@ -61,35 +69,74 @@ Trigger when:
 ```
 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
 │
 ├─ Completed work
-│  ├─ Major feature/task? → Request code-reviewer agent review
-│  └─ Before merge? → Request code-reviewer agent review
+│  ├─ 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
 ```
 
+## Edge Case Scouting
+
+### When to Scout
+Before formal review of any multi-file feature (3+ files changed).
+
+### 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
+
+### 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
+
+## Task-Managed Review Pipeline (Multi-File Features)
+
+For features spanning 3+ files, use a structured pipeline:
+
+```
+scout → review → fix → verify
+```
+
+**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
+
+Track progress using a checklist in your plan or task notes:
+```
+- [ ] Edge case scouting complete
+- [ ] `code-reviewer` review complete
+- [ ] Critical issues fixed
+- [ ] Verification passed
+```
+
 ## Receiving Feedback Protocol
 
 ### Response Pattern
 READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT
 
 ### 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: grep for usage before implementing suggested "proper" features
-
-### Source Handling
-- **Human partner:** Trusted - implement after understanding, no performative agreement
-- **External reviewers:** Verify technically correct, check for breakage, push back if wrong
+- 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
 
 **Full protocol:** `references/code-review-reception.md`
 
@@ -101,9 +148,10 @@ READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT
 - Before merge to main
 
 ### Process
-1. Get git SHAs: `BASE_SHA=$(git rev-parse HEAD~1)` and `HEAD_SHA=$(git rev-parse HEAD)`
-2. Delegate to code-reviewer agent with: WHAT_WAS_IMPLEMENTED, PLAN_OR_REQUIREMENTS, BASE_SHA, HEAD_SHA, DESCRIPTION
-3. Act on feedback: Fix Critical immediately, Important before proceeding, note Minor for later
+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
 
 **Full protocol:** `references/requesting-code-review.md`
 
@@ -130,14 +178,16 @@ Using "should"/"probably"/"seems to", expressing satisfaction before verificatio
 
 ## Integration with Workflows
 
-- **Agent-Driven:** Review after EACH task, verify before moving to next
-- **Pull Requests:** Verify tests pass, request code-reviewer review before merge
+- **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
 
 ## Bottom Line
 
-1. Technical rigor over social performance - No performative agreement
-2. Systematic review processes - Use code-reviewer agent
-3. Evidence before claims - Verification gates always
+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
 
-Verify. Question. Then implement. Evidence. Then claim.
+Scout. Verify. Question. Then implement. Evidence. Then claim.