cokit-cli 1.2.3 → 1.2.6

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

package/docs/project-roadmap.md

@@ -1,9 +1,9 @@
 # CoKit Project Roadmap
 
 **Project:** CoKit - Claude Code to GitHub Copilot Port
-**Version:** 1.2.3
+**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
@@ -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.3 RELEASED
+**Last Updated:** 2026-02-25
+**Status:** ALL PHASES COMPLETE - v1.2.6 RELEASED

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cokit-cli",
-  "version": "1.2.3",
+  "version": "1.2.6",
   "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-fast.prompt.md

@@ -100,6 +100,7 @@ This reminder is **NON-NEGOTIABLE** - always output it after presenting the plan
 
 | Command | Description |
 |---------|-------------|
+| `/ck-spec-tasks` | Break plan into actionable tasks |
 | `/ck-cook` | Implement plan |
 | `/ck-test` | Run tests and analyze results |
 | `/ck-fix` | Analyze and fix issues |

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)
 
@@ -127,6 +127,7 @@ This reminder is **NON-NEGOTIABLE** when validation is skipped.
 
 | Command | Description |
 |---------|-------------|
+| `/ck-spec-tasks` | Break plan into actionable tasks |
 | `/ck-cook` | Implement plan |
 | `/ck-test` | Run tests and analyze results |
 | `/ck-fix` | Analyze and fix issues |

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-plan.prompt.md

@@ -69,6 +69,7 @@ If user chooses validation or mode is `auto`: Execute `/ck-plan-validate {plan-p
 | Command | Description |
 |---------|-------------|
 | `/ck-plan-validate` | Validate plan with critical questions |
+| `/ck-spec-tasks` | Break plan into actionable tasks |
 | `/ck-cook` | Implement plan |
 | `/ck-test` | Run tests and analyze results |
 | `/ck-fix` | Analyze and fix issues |

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.

package/skills/cook/SKILL.md

@@ -15,12 +15,13 @@ End-to-end implementation with automatic workflow detection.
 /cook <natural language task OR plan path>
 ```
 
-**Optional flags:** `--fast`, `--parallel`, `--no-test`, `--auto`
+**Optional flags:** `--fast`, `--parallel`, `--no-test`, `--auto`, `--interactive`
 
 Example:
 ```
 /cook "Add user authentication to the app" --fast
 /cook path/to/plan.md --auto
+/cook "Fix login bug" --interactive
 ```
 
 ## Smart Intent Detection
@@ -32,6 +33,7 @@ Example:
 | Contains "trust me", "auto" | auto | Auto-approve all steps |
 | Lists 3+ features OR "parallel" | parallel | Multi-agent execution |
 | Contains "no test", "skip test" | no-test | Skip testing step |
+| `--interactive` flag (explicit) | interactive | Full workflow with user input |
 | Default | interactive | Full workflow with user input |
 
 See `references/intent-detection.md` for detection logic.
@@ -71,19 +73,51 @@ 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` |
-| Testing | `tester`, `debugger` |
-| Review | `code-reviewer` |
-| Finalize | `project-manager`, `docs-manager`, `git-manager` |
+| Phase | Agent | Requirement |
+|-------|-------|-------------|
+| Research | `researcher` agent (parallel, optional in fast) | Spawn as needed |
+| Scout | `scout` agent | Spawn for codebase search |
+| Plan | `planner` agent | MUST spawn |
+| UI Work | `ui-ux-designer` agent | Spawn when frontend work exists |
+| Testing | `tester`, `debugger` agents | MUST spawn |
+| Review | `code-reviewer` agent | MUST spawn |
+| Finalize | `docs-manager`, `git-manager` agents | MUST spawn |
+
+## Implementation Progress Tracking
+
+During Step 3 (Implementation), track progress using a todo list/checklist in the active plan or phase file:
+
+```
+- [ ] Phase 1: Setup environment
+- [ ] Phase 2: Database models
+- [ ] Phase 3: API endpoints
+- [ ] Phase 4: UI components
+```
+
+Update each item as completed. This replaces task management tooling with simple markdown tracking visible in the plan.
+
+## CRITICAL ENFORCEMENT
+
+**Steps 4 (Testing), 5 (Code Review), and 6 (Finalize) MUST delegate to agents. DO NOT implement testing, review, or finalization yourself.**
+
+- Step 4: Always delegate to `tester` agent. If failures, delegate to `debugger` agent, then re-delegate to `tester`.
+- Step 5: Always delegate to `code-reviewer` agent. Never self-review.
+- Step 6: Always delegate to `docs-manager` agent for doc updates.
+
+## Finalize Step (MANDATORY)
+
+Step 6 is not optional. All four actions MUST complete:
+
+1. Update plan/phase status to completed in plan files
+2. Delegate to `docs-manager` agent → review and update `./docs` if implementation changed APIs, architecture, or behavior
+3. Mark all todo checklist items complete in the active plan
+4. Ask the user: "Would you like to commit these changes via `git-manager` agent?"
+
+**Never skip finalize**, even in fast or auto mode.
 
 ## References