cokit-cli 1.2.4 → 1.2.6

package/templates/repo/.github/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/templates/repo/.github/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/templates/repo/.github/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/templates/repo/.github/prompts/ck-spec-specify.prompt.md

@@ -257,4 +257,5 @@ Success criteria must be:
 | `/ck-spec-clarify` | Ask clarification questions | Spec has [NEEDS CLARIFICATION] markers or vague requirements |
 | `/ck-spec-plan` | Generate implementation plan | Spec is complete and ready for technical planning |
 | `/ck-spec-constitution` | Create project principles | Need to establish non-negotiable rules before planning |
+| `/ck-plan` | Create implementation plan | Spec is finalized, ready to plan and implement |
 | `/ck-brainstorm` | Brainstorm ideas first | Not sure what to build yet |

package/templates/repo/.github/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/templates/repo/.github/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