cokit-cli 1.3.0 → 1.4.0

package/templates/repo/.github/skills/fix/SKILL.md

@@ -1,209 +0,0 @@
----
-name: fix
-description: "ALWAYS activate this skill before fixing ANY bug, error, test failure, CI/CD issue, type error, lint, log error, UI issue, code problem."
-argument-hint: "[issue] --auto|--review|--quick|--parallel"
----
-
-# Fixing
-
-Unified skill for fixing issues of any complexity with intelligent routing.
-
-## Arguments
-
-- `--auto` - Activate autonomous mode (**default**)
-- `--review` - Activate human-in-the-loop review mode
-- `--quick` - Activate quick mode
-- `--parallel` - Activate parallel mode: route to parallel `fullstack-developer` agents per issue
-
-<HARD-GATE>
-Do NOT propose or implement fixes before completing Steps 1-2 (Scout + Diagnose).
-Symptom fixes are failure. Find the cause first through structured analysis, NEVER guessing.
-If 3+ fix attempts fail, STOP and question the architecture — discuss with user before attempting more.
-User override: `--quick` mode allows fast scout→diagnose→fix cycle for trivial issues (lint, type errors).
-</HARD-GATE>
-
-## Anti-Rationalization
-
-| Thought | Reality |
-|---------|---------|
-| "I can see the problem, let me fix it" | Seeing symptoms ≠ understanding root cause. Scout first. |
-| "Quick fix for now, investigate later" | "Later" never comes. Fix properly now. |
-| "Just try changing X" | Random fixes waste time and create new bugs. Diagnose first. |
-| "It's probably X" | "Probably" = guessing. Use structured diagnosis. Verify first. |
-| "One more fix attempt" (after 2+) | 3+ failures = wrong approach. Question architecture. |
-| "Emergency, no time for process" | Systematic diagnosis is FASTER than guess-and-check. |
-| "I already know the codebase" | Knowledge decays. Scout to verify assumptions before acting. |
-| "The fix is done, tests pass" | Without prevention, same bug class will recur. Add guards. |
-
-## Process Flow (Authoritative)
-
-```mermaid
-flowchart TD
-    A[Issue Input] --> B[Step 0: Mode Selection]
-    B --> C[Step 1: Scout - Understand Context]
-    C --> D[Step 2: Diagnose - Structured Root Cause Analysis]
-    D --> E[Step 3: Complexity Assessment + Task Orchestration]
-    E -->|Simple| F[Quick Workflow]
-    E -->|Moderate| G[Standard Workflow]
-    E -->|Complex| H[Deep Workflow]
-    E -->|Parallel| I[Multi-Agent Fix]
-    F --> J[Step 4: Fix Implementation]
-    G --> J
-    H --> J
-    I --> J
-    J --> K[Step 5: Verify + Prevent]
-    K -->|Pass + Prevention in place| L[Step 6: Finalize]
-    K -->|Fail, <3 attempts| D
-    K -->|Fail, 3+ attempts| M[Question Architecture]
-    M --> N[Discuss with User]
-    L --> O[Report + Docs + Journal]
-```
-
-**This diagram is the authoritative workflow.** If prose conflicts with this flow, follow the diagram.
-
-## Workflow
-
-### Step 0: Mode Selection
-
-**First action:** If there is no "auto" keyword in the request, ask the user to determine workflow mode:
-
-| Option | Recommend When | Behavior |
-|--------|----------------|----------|
-| **Autonomous** (default) | Simple/moderate issues | Auto-approve if score >= 9.5 & 0 critical |
-| **Human-in-the-loop Review** | Critical/production code | Pause for approval at each step |
-| **Quick** | Type errors, lint, trivial bugs | Fast scout → diagnose → fix → review cycle |
-
-See `references/mode-selection.md` for asking the user format.
-
-### Step 1: Scout (MANDATORY — never skip)
-
-**Purpose:** Understand the affected codebase BEFORE forming any hypotheses.
-
-**Mandatory skill chain:**
-1. Activate `scout` skill OR launch 2-3 parallel `Explore` subagents
-2. Discover: affected files, dependencies, related tests, recent changes (`git log`)
-3. Read `./docs` for project context if unfamiliar
-
-**Quick mode:** Minimal scout — locate affected file(s) and their direct dependencies only.
-**Standard/Deep mode:** Full scout — map module boundaries, test coverage, call chains.
-
-**Output:** `✓ Step 1: Scouted - [N] files mapped, [M] dependencies, [K] tests found`
-
-### Step 2: Diagnose (MANDATORY — never skip)
-
-**Purpose:** Structured root cause analysis. NO guessing. Evidence-based only.
-
-**Mandatory skill chain:**
-1. **Capture pre-fix state:** Record exact error messages, failing test output, stack traces, log snippets. This becomes the baseline for Step 5 verification.
-2. Activate `debug` skill (systematic-debugging + root-cause-tracing techniques).
-3. Activate `sequential-thinking` skill — form hypotheses through structured reasoning, NOT guessing.
-4. Spawn parallel `Explore` subagents to test each hypothesis against codebase evidence.
-5. If 2+ hypotheses fail → auto-activate `problem-solving` skill for alternative approaches.
-6. Create diagnosis report: confirmed root cause, evidence chain, affected scope.
-
-See `references/diagnosis-protocol.md` for full methodology.
-
-**Output:** `✓ Step 2: Diagnosed - Root cause: [summary], Evidence: [brief], Scope: [N files]`
-
-### Step 3: Complexity Assessment & Task Orchestration
-
-Classify before routing. See `references/complexity-assessment.md`.
-
-| Level | Indicators | Workflow |
-|-------|------------|----------|
-| **Simple** | Single file, clear error, type/lint | `references/workflow-quick.md` |
-| **Moderate** | Multi-file, root cause unclear | `references/workflow-standard.md` |
-| **Complex** | System-wide, architecture impact | `references/workflow-deep.md` |
-| **Parallel** | 2+ independent issues OR `--parallel` flag | Parallel `fullstack-developer` agents |
-
-**Task Orchestration (Moderate+ only):** After classifying, create native Tasks for all phases upfront with dependencies. See `references/task-orchestration.md`.
-- Skip for Quick workflow (< 3 steps, overhead exceeds benefit)
-- Use `TaskCreate` with `addBlockedBy` for dependency chains
-- Update via `TaskUpdate` as each phase completes
-- For Parallel: create separate task trees per independent issue
-- **Fallback:** Task tools (`TaskCreate`/`TaskUpdate`/`TaskGet`/`TaskList`) are CLI-only — unavailable in VSCode extension. If they error, use `TodoWrite` for progress tracking. Fix workflow remains fully functional without them.
-
-### Step 4: Fix Implementation
-
-- Implement fix per selected workflow, updating Tasks as phases complete.
-- Follow diagnosis findings — fix the ROOT CAUSE, not symptoms.
-- Minimal changes only. Follow existing patterns.
-
-### Step 5: Verify + Prevent (MANDATORY — never skip)
-
-**Purpose:** Prove the fix works AND prevent the same bug class from recurring.
-
-**Mandatory skill chain:**
-1. **Verify (iron-law):** Run the EXACT commands from pre-fix state capture. Compare output. NO claims without fresh evidence.
-2. **Regression test:** Add or update test(s) that specifically cover the fixed issue. The test MUST fail without the fix and pass with it.
-3. **Prevention gate:** Apply defense-in-depth validation where applicable. See `references/prevention-gate.md`.
-4. **Parallel verification:** Launch `Bash` agents for typecheck + lint + build + test.
-
-**If verification fails:** Loop back to Step 2 (re-diagnose). After 3 failures → question architecture, discuss with user.
-
-See `references/prevention-gate.md` for prevention requirements.
-
-**Output:** `✓ Step 5: Verified + Prevented - [before/after comparison], [N] tests added, [M] guards added`
-
-### Step 6: Finalize (MANDATORY — never skip)
-
-1. Report summary: confidence score, root cause, changes, files, prevention measures
-2. `docs-manager` subagent → update `./docs` if changes warrant (NON-OPTIONAL)
-3. `TaskUpdate` → mark ALL Tasks `completed` (skip if Task tools unavailable)
-4. Ask user if they want to commit via `git-manager` subagent
-5. Run `/ck-journal` to write a concise technical journal entry upon completion
-
----
-
-## IMPORTANT: Skill/Subagent Activation Matrix
-
-See `references/skill-activation-matrix.md` for complete matrix.
-
-**Always activate (ALL workflows):**
-- `scout` (Step 1) — understand before diagnosing
-- `debug` (Step 2) — systematic root cause investigation
-- `sequential-thinking` (Step 2) — structured hypothesis formation
-
-**Conditional:**
-- `problem-solving` — auto-triggers when 2+ hypotheses fail in Step 2
-- `brainstorm` — multiple valid approaches, architecture decision (Deep only)
-- `context-engineering` — fixing AI/LLM/agent code
-- `project-management` — moderate+ for task hydration/sync-back
-
-**Subagents:** `debugger`, `researcher`, `planner`, `code-reviewer`, `tester`, `Bash`
-**Parallel:** Multiple `Explore` agents for scouting, `Bash` agents for verification
-
-## Output Format
-
-Unified step markers:
-```
-✓ Step 0: [Mode] selected
-✓ Step 1: Scouted - [N] files, [M] deps
-✓ Step 2: Diagnosed - Root cause: [summary]
-✓ Step 3: [Complexity] detected - [workflow] selected
-✓ Step 4: Fixed - [N] files changed
-✓ Step 5: Verified + Prevented - [tests added], [guards added]
-✓ Step 6: Complete - [action taken]
-```
-
-## References
-
-Load as needed:
-- `references/mode-selection.md` - asking the user format for mode
-- `references/diagnosis-protocol.md` - Structured diagnosis methodology (NEW)
-- `references/prevention-gate.md` - Prevention requirements after fix (NEW)
-- `references/complexity-assessment.md` - Classification criteria
-- `references/task-orchestration.md` - Native Task patterns for moderate+ workflows
-- `references/workflow-quick.md` - Quick: scout → diagnose → fix → verify+prevent → review
-- `references/workflow-standard.md` - Standard: full pipeline with Tasks
-- `references/workflow-deep.md` - Deep: research + brainstorm + plan with Tasks
-- `references/review-cycle.md` - Review logic (autonomous vs HITL)
-- `references/skill-activation-matrix.md` - When to activate each skill
-- `references/parallel-exploration.md` - Parallel Explore/Bash/Task coordination patterns
-
-**Specialized Workflows:**
-- `references/workflow-ci.md` - GitHub Actions/CI failures
-- `references/workflow-logs.md` - Application log analysis
-- `references/workflow-test.md` - Test suite failures
-- `references/workflow-types.md` - TypeScript type errors
-- `references/workflow-ui.md` - Visual/UI issues (requires design skills)

package/templates/repo/.github/skills/fix/references/complexity-assessment.md

@@ -1,73 +0,0 @@
-# Complexity Assessment
-
-Classify issue complexity before routing to workflow. Assessment happens AFTER Step 1 (Scout) and Step 2 (Diagnose).
-
-## Classification Criteria
-
-### Simple (→ workflow-quick.md) — No Tasks
-
-**Indicators:**
-- Single file affected
-- Clear error message (type error, syntax, lint)
-- Keywords: `type`, `typescript`, `tsc`, `lint`, `eslint`, `syntax`
-- Obvious fix location
-- Root cause confirmed by diagnosis (not assumed)
-
-**Task usage:** Skip. < 3 steps, overhead exceeds benefit.
-
-**Examples:**
-- "Fix type error in auth.ts"
-- "ESLint errors after upgrade"
-- "Syntax error in config file"
-
-### Moderate (→ workflow-standard.md) — Use Tasks (6 phases)
-
-**Indicators:**
-- 2-5 files affected
-- Root cause identified but fix spans multiple files
-- Needs investigation to confirm diagnosis
-- Keywords: `bug`, `broken`, `not working`, `fails sometimes`
-- Test failures with root cause traced
-
-**Task usage:** Create 6 phase tasks with dependencies. See `references/task-orchestration.md`.
-
-**Examples:**
-- "Login sometimes fails"
-- "API returns wrong data"
-- "Component not rendering correctly"
-
-### Complex (→ workflow-deep.md) — Use Tasks with Dependency Chains (9 phases)
-
-**Indicators:**
-- System-wide impact (5+ files)
-- Architecture decision needed
-- Research required for solution
-- Keywords: `architecture`, `refactor`, `system-wide`, `design issue`
-- Performance/security vulnerabilities
-- Multiple interacting components
-- Root cause spans multiple layers/modules
-
-**Task usage:** Create 9 phase tasks. Steps 1+2+3 run parallel (scout+diagnose+research). Full dependency chains. See `references/task-orchestration.md`.
-
-**Examples:**
-- "Memory leak in production"
-- "Database deadlocks under load"
-- "Security vulnerability in auth flow"
-
-### Parallel (→ multiple fullstack-developer agents) — Use Task Trees
-
-**Triggers:**
-- `--parallel` flag explicitly passed (activate parallel routing regardless of auto-classification)
-
-**Indicators:**
-- 2+ independent issues mentioned
-- Issues in different areas (frontend + backend, auth + payments)
-- No dependencies between issues
-- Keywords: list of issues, "and", "also", multiple error types
-
-**Task usage:** Create separate task trees per independent issue (each with scout+diagnose+fix+verify). Spawn `fullstack-developer` agent per tree. See `references/task-orchestration.md`.
-
-**Examples:**
-- "Fix type errors AND update UI styling"
-- "Auth bug + payment integration issue"
-- "3 different test failures in unrelated modules"

package/templates/repo/.github/skills/fix/references/diagnosis-protocol.md

@@ -1,133 +0,0 @@
-# Diagnosis Protocol
-
-Structured root cause analysis methodology. Replaces ad-hoc guessing with evidence-based investigation.
-
-## Core Principle
-
-**NEVER guess root causes.** Form hypotheses through structured reasoning and test them against evidence.
-
-## Pre-Diagnosis: Capture State (MANDATORY)
-
-Before any investigation, capture the current broken state as baseline:
-
-```
-1. Record exact error messages (copy-paste, not paraphrase)
-2. Record failing test output (full command + output)
-3. Record relevant stack traces
-4. Record relevant log snippets with timestamps
-5. Record git status / recent changes: git log --oneline -10
-```
-
-This baseline is required for Step 5 (Verify) — you MUST compare before/after.
-
-## Diagnosis Chain (Follow in Order)
-
-### Phase 1: Observe — What is actually happening?
-
-Read, don't assume. Use `debug` (systematic-debugging Phase 1).
-
-- What is the exact error message?
-- Where does it occur? (file, line, function)
-- When did it start? (check `git log`, `git bisect`)
-- Can it be reproduced consistently?
-- What is the expected vs actual behavior?
-
-### Phase 2: Hypothesize — Why might this happen?
-
-Activate `sequential-thinking` skill. Form hypotheses through structured reasoning.
-
-**Structured hypothesis formation:**
-```
-For each hypothesis:
-  1. State the hypothesis clearly
-  2. What evidence would CONFIRM it?
-  3. What evidence would REFUTE it?
-  4. How to test it quickly?
-```
-
-**Common hypothesis categories:**
-- Recent code change introduced regression (`git log`, `git diff`)
-- Data/state mismatch (wrong input, stale cache, race condition)
-- Environment difference (deps version, config, platform)
-- Missing validation (null check, type guard, boundary)
-- Incorrect assumption (API contract, data shape, ordering)
-
-### Phase 3: Test — Verify hypotheses against evidence
-
-Spawn parallel `Explore` subagents to test each hypothesis simultaneously:
-
-```
-// Launch in SINGLE message — max 3 parallel agents
-Task("Explore", "Test hypothesis A: [specific search/check]", "Verify H-A")
-Task("Explore", "Test hypothesis B: [specific search/check]", "Verify H-B")
-Task("Explore", "Test hypothesis C: [specific search/check]", "Verify H-C")
-```
-
-**For each hypothesis result:**
-- CONFIRMED: Evidence supports this as root cause → proceed to root cause tracing
-- REFUTED: Evidence contradicts → discard, note why
-- INCONCLUSIVE: Need more data → refine hypothesis or gather more evidence
-
-### Phase 4: Trace — Follow the root cause chain
-
-Use `debug` (root-cause-tracing technique). Trace backward:
-
-```
-Symptom (where error appears)
-  ↑ Immediate cause (what triggered the error)
-    ↑ Contributing factor (what set up the bad state)
-      ↑ ROOT CAUSE (the original trigger that must be fixed)
-```
-
-**Rule:** NEVER fix where the error appears. Trace back to the source.
-
-### Phase 5: Escalate — When hypotheses fail
-
-If 2+ hypotheses are REFUTED:
-1. Auto-activate `problem-solving` skill
-2. Apply Inversion Exercise: "What would CAUSE this bug intentionally?"
-3. Apply Scale Game: "Does this fail with 1 item? 100? 10000?"
-4. Consider environmental factors (timing, concurrency, platform)
-
-If 3+ fix attempts fail after diagnosis:
-1. STOP immediately
-2. Question the architecture — is the design fundamentally flawed?
-3. Discuss with user before attempting more
-
-## Diagnosis Report Format
-
-```markdown
-## Diagnosis Report
-
-**Issue:** [one-line description]
-**Pre-fix state captured:** Yes/No
-
-### Root Cause
-[Clear explanation of the root cause, traced back to origin]
-
-### Evidence Chain
-1. [Observation] → led to hypothesis [X]
-2. [Test result] → confirmed/refuted [X]
-3. [Trace] → root cause at [file:line]
-
-### Affected Scope
-- Files: [list]
-- Functions: [list]
-- Dependencies: [list]
-
-### Recommended Fix
-[What to change and why — addressing root cause, not symptoms]
-
-### Prevention Needed
-[What guards/tests to add to prevent recurrence]
-```
-
-## Quick Mode Diagnosis
-
-For trivial issues (type errors, lint, syntax), abbreviated diagnosis:
-
-1. Read error message
-2. Locate affected file(s) via scout results
-3. Identify root cause (usually obvious for simple issues)
-4. Skip parallel hypothesis testing
-5. Still capture pre-fix state for verification

package/templates/repo/.github/skills/fix/references/prevention-gate.md

@@ -1,87 +0,0 @@
-# Prevention Gate
-
-After fixing a bug, prevent the same class of issues from recurring. This step is MANDATORY.
-
-## Core Principle
-
-A fix without prevention is incomplete. The same bug pattern WILL recur if you only patch the symptom.
-
-## Prevention Requirements (Check All That Apply)
-
-### 1. Regression Test (ALWAYS required)
-
-Every fix MUST have a test that:
-- **Fails** without the fix applied (proves the test catches the bug)
-- **Passes** with the fix applied (proves the fix works)
-
-```
-If no test framework exists:
-  → Add inline verification or assertion at minimum
-  → Note in report: "No test framework — added runtime assertion"
-```
-
-### 2. Defense-in-Depth Validation (When applicable)
-
-Apply layered validation from `debug` defense-in-depth technique:
-
-| Layer | Apply When | Example |
-|-------|-----------|---------|
-| **Entry point validation** | Fix involves user/external input | Reject invalid input at API boundary |
-| **Business logic validation** | Fix involves data processing | Assert data makes sense for operation |
-| **Environment guards** | Fix involves env-sensitive operations | Prevent dangerous ops in wrong context |
-| **Debug instrumentation** | Fix was hard to diagnose | Add logging/context capture for forensics |
-
-**Rule:** Not every fix needs all 4 layers. Apply what's relevant. But ALWAYS consider each.
-
-### 3. Type Safety (When applicable)
-
-| Scenario | Prevention |
-|----------|-----------|
-| Null/undefined caused the bug | Add strict null checks, use `??` or `?.` |
-| Wrong type passed | Add type guard or runtime validation |
-| Missing property | Add required field to interface/type |
-| Implicit any | Add explicit types |
-
-### 4. Error Handling (When applicable)
-
-| Scenario | Prevention |
-|----------|-----------|
-| Unhandled promise rejection | Add `.catch()` or try/catch |
-| Missing error boundary | Add error boundary component |
-| Silent failure | Add explicit error logging |
-| No fallback for external dependency | Add timeout + fallback |
-
-## Verification Checklist (Before Completing Step 5)
-
-```
-□ Pre-fix state captured? (error messages, test output)
-□ Fix applied to ROOT CAUSE (not symptom)?
-□ Fresh verification run? (exact same commands as pre-fix)
-□ Before/after comparison documented?
-□ Regression test added? (fails without fix, passes with fix)
-□ Defense-in-depth layers considered? (applied where relevant)
-□ No new warnings/errors introduced?
-□ Parallel verification passed? (typecheck + lint + build + test)
-```
-
-## Output Format
-
-```
-Prevention measures applied:
-- Regression test: [test file:line] — covers [specific scenario]
-- Guard added: [file:line] — [description of guard]
-- Type safety: [file:line] — [what was strengthened]
-- Error handling: [file:line] — [what was added]
-
-Before/After comparison:
-- Before: [exact error/failure]
-- After: [exact success output]
-```
-
-## Quick Mode Prevention
-
-For trivial issues (type errors, lint), abbreviated prevention:
-- Regression test: optional (type system IS the test)
-- Parallel verification: typecheck + lint only
-- Defense-in-depth: skip (not applicable for type fixes)
-- Still require before/after comparison of typecheck output

package/templates/repo/.github/skills/fix/references/skill-activation-matrix.md

@@ -1,98 +0,0 @@
-# Skill Activation Matrix
-
-When to activate each skill and tool during fixing workflows.
-
-## Always Activate (ALL Workflows)
-
-| Skill/Tool | Step | Reason |
-|------------|------|--------|
-| `scout` OR parallel `Explore` | Step 1 | Understand codebase context before diagnosing |
-| `debug` | Step 2 | Systematic root cause investigation |
-| `sequential-thinking` | Step 2 | Structured hypothesis formation — NO guessing |
-
-## Task Orchestration (Moderate+ Only)
-
-| Tool | Activate When |
-|------|---------------|
-| `TaskCreate` | After complexity assessment, create all phase tasks upfront |
-| `TaskUpdate` | At start/completion of each phase |
-| `TaskList` | Check available unblocked work, coordinate parallel agents |
-| `TaskGet` | Retrieve full task details before starting work |
-
-Skip Tasks for Quick workflow (< 3 steps). See `references/task-orchestration.md`.
-
-## Auto-Triggered Activation
-
-| Skill | Auto-Trigger Condition |
-|-------|------------------------|
-| `problem-solving` | 2+ hypotheses REFUTED in Step 2 diagnosis |
-| `sequential-thinking` | Always in Step 2 (mandatory for hypothesis formation) |
-
-## Conditional Activation
-
-| Skill | Activate When |
-|-------|---------------|
-| `brainstorm` | Multiple valid fix approaches, architecture decision (Deep only) |
-| `context-engineering` | Fixing AI/LLM/agent code, context window issues |
-| `ai-multimodal` (if available) | UI issues, screenshots provided, visual bugs |
-| `project-management` | Moderate+ workflows — task hydration, sync-back, progress tracking |
-
-## Subagent Usage
-
-| Subagent | Activate When |
-|----------|---------------|
-| `debugger` | Root cause unclear, need deep investigation (Step 2) |
-| `Explore` (parallel) | Scout multiple areas simultaneously (Step 1), test hypotheses (Step 2) |
-| `Bash` (parallel) | Verify implementation: typecheck, lint, build, test (Step 5) |
-| `researcher` | External docs needed, latest best practices (Deep only) |
-| `planner` | Complex fix needs breakdown, multiple phases (Deep only) |
-| `tester` | After implementation, verify fix works (Step 5) |
-| `code-review` | After fix, verify quality and security (Step 5) |
-| `git-manager` | After approval, commit changes (Step 6) |
-| `docs-manager` | API/behavior changes need doc updates (Step 6) |
-| `project-manager` | Major fix impacts roadmap/plan status (Step 6) |
-| `fullstack-developer` | Parallel independent issues (each gets own agent) |
-
-## Parallel Patterns
-
-See `references/parallel-exploration.md` for detailed patterns.
-
-| When | Parallel Strategy |
-|------|-------------------|
-| Scouting (Step 1) | 2-3 `Explore` agents on different areas |
-| Testing hypotheses (Step 2) | 2-3 `Explore` agents per hypothesis |
-| Multi-module fix | `Explore` each module in parallel |
-| After implementation (Step 5) | `Bash` agents: typecheck + lint + build + test |
-| 2+ independent issues | Task trees + `fullstack-developer` agents per issue |
-
-## Workflow → Skills Map
-
-| Workflow | Skills Activated |
-|----------|------------------|
-| Quick | `scout` (minimal), `debug`, `sequential-thinking`, `code-review`, parallel `Bash` verification |
-| Standard | Above + Tasks, `problem-solving` (auto), `project-management`, `tester`, parallel `Explore` |
-| Deep | All above + `brainstorm`, `context-engineering`, `researcher`, `planner` |
-| Parallel | Per-issue Task trees + `project-management` + `fullstack-developer` agents + coordination via `TaskList` |
-
-## Step → Skills Chain (Mandatory Order)
-
-| Step | Mandatory Chain |
-|------|----------------|
-| Step 0: Mode | asking the user (unless auto/quick detected) |
-| Step 1: Scout | `scout` OR 2-3 parallel `Explore` → map files, deps, tests |
-| Step 2: Diagnose | Capture pre-fix state → `debug` → `sequential-thinking` → parallel `Explore` hypotheses → (`problem-solving` if 2+ fail) |
-| Step 3: Assess | Classify complexity → create Tasks (moderate+) |
-| Step 4: Fix | Implement per workflow → follow root cause |
-| Step 5: Verify+Prevent | Iron-law verify → regression test → defense-in-depth → parallel `Bash` verify |
-| Step 6: Finalize | Report → `docs-manager` → `TaskUpdate` → `git-manager` → `/ck-journal` |
-
-## Detection Triggers
-
-| Keyword/Pattern | Skill to Consider |
-|-----------------|-------------------|
-| "AI", "LLM", "agent", "context" | `context-engineering` |
-| "stuck", "tried everything" | `problem-solving` |
-| "complex", "multi-step" | `sequential-thinking` |
-| "which approach", "options" | `brainstorm` |
-| "latest docs", "best practice" | `researcher` subagent |
-| Screenshot attached | `ai-multimodal` (if available) |