cokit-cli 1.3.0 → 1.4.0

package/skills/planning/SKILL.md

@@ -1,194 +0,0 @@
----
-name: plan
-description: "Plan implementations, design architectures, create technical roadmaps with detailed phases. Use for feature planning, system design, solution architecture, implementation strategy, phase documentation."
-argument-hint: "[task] OR [archive|red-team|validate]"
-license: MIT
----
-
-# Planning
-
-Create detailed technical implementation plans through research, codebase analysis, solution design, and comprehensive documentation.
-
-**IMPORTANT:** Before you start, scan unfinished plans in the current project at `./plans/` directory, read the `plan.md`, if there are relevant plans with your upcoming plan, update them as well. If you're unsure or need more clarifications, use ask the user.
-
-### Cross-Plan Dependency Detection
-
-During the pre-creation scan, detect and mark blocking relationships between plans:
-
-1. **Scan** — Read `plan.md` frontmatter of each unfinished plan (status != `completed`/`cancelled`)
-2. **Compare scope** — Check overlapping files, shared dependencies, same feature area
-3. **Classify relationship:**
-   - New plan needs output of existing plan → new plan `blockedBy: [existing-plan-dir]`
-   - New plan changes something existing plan depends on → existing plan `blockedBy: [new-plan-dir]`, new plan `blocks: [existing-plan-dir]`
-   - Mutual dependency → both plans reference each other in `blockedBy`/`blocks`
-4. **Bidirectional update** — When relationship detected, update BOTH `plan.md` files' frontmatter
-5. **Ambiguous?** → Use asking the user with header "Plan Dependency", present detected overlap, ask user to confirm relationship type (blocks/blockedBy/none)
-
-**Frontmatter fields** (relative plan dir paths):
-```yaml
-blockedBy: [260301-1200-auth-system]     # This plan waits on these plans
-blocks: [260228-0900-user-dashboard]     # This plan blocks these plans
-```
-
-**Status interaction:** A plan with `blockedBy` entries where ANY blocker is not `completed` → plan status should note `blocked` in its overview. When all blockers complete, the blocked plan becomes unblocked automatically on next scan.
-
-## Default (No Arguments)
-
-If invoked with a task description, proceed with planning workflow. If invoked WITHOUT arguments or with unclear intent, use asking the user to present available operations:
-
-| Operation | Description |
-|-----------|-------------|
-| `(default)` | Create implementation plan for a task |
-| `archive` | Write journal entry & archive plans |
-| `red-team` | Adversarial plan review |
-| `validate` | Critical questions interview |
-
-Present as options by asking the user with header "Planning Operation", question "What would you like to do?".
-
-## Workflow Modes
-
-Default: `--auto` (analyze task complexity and auto-pick mode).
-
-| Flag | Mode | Research | Red Team | Validation | Cook Flag |
-|------|------|----------|----------|------------|-----------|
-| `--auto` | Auto-detect | Follows mode | Follows mode | Follows mode | Follows mode |
-| `--fast` | Fast | Skip | Skip | Skip | `--auto` |
-| `--hard` | Hard | 2 researchers | Yes | Optional | (none) |
-| `--parallel` | Parallel | 2 researchers | Yes | Optional | `--parallel` |
-| `--two` | Two approaches | 2+ researchers | After selection | After selection | (none) |
-
-Add `--no-tasks` to skip task hydration in any mode.
-
-Load: `references/workflow-modes.md` for auto-detection logic, per-mode workflows, context reminders.
-
-## When to Use
-
-- Planning new feature implementations
-- Architecting system designs
-- Evaluating technical approaches
-- Creating implementation roadmaps
-- Breaking down complex requirements
-
-## Core Responsibilities & Rules
-
-Always honoring **YAGNI**, **KISS**, and **DRY** principles.
-**Be honest, be brutal, straight to the point, and be concise.**
-
-### 0. Scope Challenge
-Load: `references/scope-challenge.md`
-**Skip if:** `--fast` mode or trivial task (single file fix, <20 word description)
-
-### 1. Research & Analysis
-Load: `references/research-phase.md`
-**Skip if:** Fast mode or provided with researcher reports
-
-### 2. Codebase Understanding
-Load: `references/codebase-understanding.md`
-**Skip if:** Provided with scout reports
-
-### 3. Solution Design
-Load: `references/solution-design.md`
-
-### 4. Plan Creation & Organization
-Load: `references/plan-organization.md`
-
-### 5. Task Breakdown & Output Standards
-Load: `references/output-standards.md`
-
-## Process Flow (Authoritative)
-
-```mermaid
-flowchart TD
-    A[Pre-Creation Check] --> B[Cross-Plan Scan]
-    B --> C[Scope Challenge]
-    C --> D[Mode Detection]
-    D -->|fast| E[Skip Research]
-    D -->|hard/parallel/two| F[Spawn Researchers]
-    E --> G[Codebase Analysis]
-    F --> G
-    G --> H[Write Plan via Planner]
-    H --> I{Red Team?}
-    I -->|Yes| J[Red Team Review]
-    I -->|No| K{Validate?}
-    J --> K
-    K -->|Yes| L[Validation Interview]
-    K -->|No| M[Hydrate Tasks]
-    L --> M
-    M --> N[Output Cook Command]
-    N --> O[Journal]
-```
-
-**This diagram is the authoritative workflow.** Prose sections below provide detail for each node.
-
-## Workflow Process
-
-1. **Pre-Creation Check** → Check Plan Context for active/suggested/none
-1b. **Cross-Plan Scan** → Scan unfinished plans, detect `blockedBy`/`blocks` relationships, update both plans
-1c. **Scope Challenge** → Run Step 0 scope questions, select mode (see `references/scope-challenge.md`)
-    **Skip if:** `--fast` mode or trivial task
-2. **Mode Detection** → Auto-detect or use explicit flag (see `workflow-modes.md`)
-3. **Research Phase** → Spawn researchers (skip in fast mode)
-4. **Codebase Analysis** → Read docs, scout if needed
-5. **Plan Documentation** → Write comprehensive plan via planner subagent
-6. **Red Team Review** → Run `/ck-plan red-team {plan-path}` (hard/parallel/two modes)
-7. **Post-Plan Validation** → Run `/ck-plan validate {plan-path}` (hard/parallel/two modes)
-8. **Hydrate Tasks** → Create Tasks from phases (default on, `--no-tasks` to skip)
-9. **Context Reminder** → Output cook command with absolute path (MANDATORY)
-10. **Journal** → Run `/ck-journal` to write a concise technical journal entry upon completion
-
-## Output Requirements
-**IMPORTANT:** Invoke "/ck-project-organization" skill to organize the outputs.
-
-- DO NOT implement code - only create plans
-- Respond with plan file path and summary
-- Ensure self-contained plans with necessary context
-- Include code snippets/pseudocode when clarifying
-- Fully respect the `./docs/development-rules.md` file
-
-## Task Management
-
-Plan files = persistent. Tasks = session-scoped. Hydration bridges the gap.
-
-**Default:** Auto-hydrate tasks after plan files are written. Skip with `--no-tasks`.
-**3-Task Rule:** <3 phases → skip task creation.
-**Fallback:** Task tools (`TaskCreate`/`TaskUpdate`/`TaskGet`/`TaskList`) are CLI-only — unavailable in VSCode extension. If they error, use `TodoWrite` for tracking. Plan files remain the source of truth; hydration is an optimization, not a requirement.
-
-Load: `references/task-management.md` for hydration pattern, TaskCreate patterns, cook handoff protocol.
-
-### Hydration Workflow
-1. Write plan.md + phase files (persistent layer)
-2. TaskCreate per phase with `addBlockedBy` chain (skip if Task tools unavailable)
-3. TaskCreate for critical/high-risk steps within phases (skip if Task tools unavailable)
-4. Metadata: phase, priority, effort, planDir, phaseFile
-5. Cook picks up via TaskList (same session) or re-hydrates (new session)
-
-## Active Plan State
-
-Check `## Plan Context` injected by hooks:
-- **"Plan: {path}"** → Active plan. Ask "Continue? [Y/n]"
-- **"Suggested: {path}"** → Branch hint only. Ask if activate or create new.
-- **"Plan: none"** → Create new using `Plan dir:` from `## Naming`
-
-Reports: Active plans → plan-specific path. Suggested → default path.
-
-### Important
-**DO NOT** create plans or reports in USER directory.
-**MUST** create plans or reports in **THE CURRENT WORKING PROJECT DIRECTORY**.
-
-## Subcommands
-
-| Subcommand | Reference | Purpose |
-|------------|-----------|---------|
-| `/ck-plan archive` | `references/archive-workflow.md` | Archive plans + write journal entries |
-| `/ck-plan red-team` | `references/red-team-workflow.md` | Adversarial plan review with hostile reviewers |
-| `/ck-plan validate` | `references/validate-workflow.md` | Validate plan with critical questions interview |
-
-## Quality Standards
-
-- Thorough and specific, consider long-term maintainability
-- Research thoroughly when uncertain
-- Address security and performance concerns
-- Detailed enough for junior developers
-- Validate against existing codebase patterns
-
-**Remember:** Plan quality determines implementation success. Be comprehensive and consider all solution aspects.

package/skills/planning/references/research-phase.md

@@ -1,49 +0,0 @@
-# Research & Analysis Phase
-
-**When to skip:** If provided with researcher reports, skip this phase.
-
-## Core Activities
-
-### Parallel Researcher Agents
-- Spawn multiple `researcher` agents in parallel to investigate different approaches
-- Wait for all researcher agents to report back before proceeding
-- Each researcher investigates a specific aspect or approach
-
-### Sequential Thinking
-- Use `sequential-thinking` skill for dynamic and reflective problem-solving
-- Structured thinking process for complex analysis
-- Enables multi-step reasoning with revision capability
-
-### Documentation Research
-- Use `docs-seeker` skill to read and understand documentation
-- Research plugins, packages, and frameworks
-- Find latest technical documentation using llms.txt standard
-
-### GitHub Analysis
-- Use `gh` command to read and analyze:
-  - GitHub Actions logs
-  - Pull requests
-  - Issues and discussions
-- Extract relevant technical context from GitHub resources
-
-### Remote Repository Analysis
-When given GitHub repository URL, generate fresh codebase summary:
-```bash
-# usage: 
-repomix --remote <github-repo-url>
-# example: 
-repomix --remote https://github.com/mrgoonie/human-mcp
-```
-
-### Debugger Delegation
-- Delegate to `debugger` agent for root cause analysis
-- Use when investigating complex issues or bugs
-- Debugger agent specializes in diagnostic tasks
-
-## Best Practices
-
-- Research breadth before depth
-- Document findings for synthesis phase
-- Identify multiple approaches for comparison
-- Consider edge cases during research
-- Note security implications early

package/skills/planning/references/task-management.md

@@ -1,134 +0,0 @@
-# Task Management Integration
-
-## Session-Scoped Reality
-
-Tasks are **ephemeral** — they die when the session ends. `tasks/` holds lock files only, NOT task data. Plan files (plan.md, phase-XX.md with checkboxes) are the **persistent** layer.
-
-**Tool Availability:** `TaskCreate`/`TaskUpdate`/`TaskGet`/`TaskList` are **CLI-only** — disabled in VSCode extension (`isTTY` check). If these tools error, use `TodoWrite` for progress tracking. Plan files remain the source of truth; hydration is an optimization, not a requirement.
-
-The **hydration pattern** bridges sessions:
-
-```
-┌──────────────────┐  Hydrate   ┌───────────────────┐
-│ Plan Files       │ ─────────► │ Tasks      │
-│ (persistent)     │            │ (session-scoped)  │
-│ [ ] Phase 1      │            │ ◼ pending         │
-│ [ ] Phase 2      │            │ ◼ pending         │
-└──────────────────┘            └───────────────────┘
-                                        │ Work
-                                        ▼
-┌──────────────────┐  Sync-back ┌───────────────────┐
-│ Plan Files       │ ◄───────── │ Task Updates      │
-│ (updated)        │            │ (completed)       │
-│ [x] Phase 1      │            │ ✓ completed       │
-│ [ ] Phase 2      │            │ ◼ in_progress     │
-└──────────────────┘            └───────────────────┘
-```
-
-- **Hydrate:** Read plan files → TaskCreate per unchecked `[ ]` item
-- **Work:** TaskUpdate tracks in_progress/completed in real-time
-- **Sync-back:** Update `[ ]` → `[x]` in phase files, update plan.md frontmatter status
-
-## When to Create Tasks
-
-**Default:** On — auto-hydrate after plan files are written
-**Skip with:** `--no-tasks` flag in planning request
-**3-Task Rule:** <3 phases → skip tasks (overhead exceeds benefit)
-
-| Scenario | Tasks? | Why |
-|----------|--------|-----|
-| Multi-phase feature (3+ phases) | Yes | Track progress, enable parallel |
-| Complex dependencies between phases | Yes | Automatic unblocking |
-| Plan will be executed by cook | Yes | Seamless handoff |
-| Single-phase quick fix | No | Just do it directly |
-| Trivial 1-2 step plan | No | Overhead not worth it |
-
-## Task Creation Patterns
-
-### Phase-Level TaskCreate
-
-```
-TaskCreate(
-  subject: "Setup environment and dependencies",
-  activeForm: "Setting up environment",
-  description: "Install packages, configure env, setup database. See phase-01-setup.md",
-  metadata: { phase: 1, priority: "P1", effort: "2h",
-              planDir: "plans/260205-auth/", phaseFile: "phase-01-setup.md" }
-)
-```
-
-### Critical Step TaskCreate
-
-For high-risk/complex steps within phases:
-
-```
-TaskCreate(
-  subject: "Implement OAuth2 token refresh",
-  activeForm: "Implementing token refresh",
-  description: "Handle token expiry, refresh flow, error recovery",
-  metadata: { phase: 3, step: "3.4", priority: "P1", effort: "1.5h",
-              planDir: "plans/260205-auth/", phaseFile: "phase-03-api.md",
-              critical: true, riskLevel: "high" },
-  addBlockedBy: ["{phase-2-task-id}"]
-)
-```
-
-## Metadata & Naming Conventions
-
-**Required metadata:** `phase`, `priority` (P1/P2/P3), `effort`, `planDir`, `phaseFile`
-**Optional metadata:** `step`, `critical`, `riskLevel`, `dependencies`
-
-**subject** (imperative): Action verb + deliverable, <60 chars
-- "Setup database migrations", "Implement OAuth2 flow", "Create user profile endpoints"
-
-**activeForm** (present continuous): Matches subject in -ing form
-- "Setting up database", "Implementing OAuth2", "Creating user profile endpoints"
-
-**description**: 1-2 sentences, concrete deliverables, reference phase file
-
-## Dependency Chains
-
-```
-Phase 1 (no blockers)              ← start here
-Phase 2 (addBlockedBy: [P1-id])    ← auto-unblocked when P1 completes
-Phase 3 (addBlockedBy: [P2-id])
-Step 3.4 (addBlockedBy: [P2-id])   ← critical steps share phase dependency
-```
-
-Use `addBlockedBy` for forward references ("I need X done first").
-Use `addBlocks` when creating parent first ("X blocks these children").
-
-## Cook Handoff Protocol
-
-### Same-Session (planning → cook immediately)
-
-1. Planning hydrates tasks → tasks exist in session
-2. Cook Step 3: `TaskList` → finds existing tasks → picks them up
-3. Cook skips re-creation, begins implementation directly
-
-### Cross-Session (new session, resume plan)
-
-1. User runs `/ck-cook path/to/plan.md` in new session
-2. Cook Step 3: `TaskList` → empty (tasks died with old session)
-3. Cook reads plan files → re-hydrates from unchecked `[ ]` items
-4. Already-checked `[x]` items = done, skip those
-
-### Sync-Back (cook Step 6)
-
-1. `TaskUpdate` marks all session tasks complete.
-2. `project-manager` subagent runs full-plan sync-back:
-   - Sweep all `phase-XX-*.md` files.
-   - Reconcile completed tasks by metadata (`phase`, `phaseFile`).
-   - Backfill stale completed checkboxes `[ ]` → `[x]` across all phases (not only current phase).
-   - Update `plan.md` status/progress from actual checkbox state.
-3. If any completed task cannot be mapped to a phase file, report unresolved mappings before claiming completion.
-4. Git commit captures the state transition for next session.
-
-## Quality Checks
-
-After task hydration, verify:
-- Dependency chain has no cycles
-- All phases have corresponding tasks
-- Required metadata fields present (phase, priority, effort, planDir, phaseFile)
-- Task count matches unchecked `[ ]` items in plan files
-- Output: `✓ Hydrated [N] phase tasks + [M] critical step tasks with dependency chain`

package/skills/planning/references/workflow-modes.md

@@ -1,154 +0,0 @@
-# Workflow Modes
-
-## Auto-Detection (Default: `--auto`)
-
-When no flag specified, analyze task and pick mode:
-
-| Signal | Mode | Rationale |
-|--------|------|-----------|
-| Simple task, clear scope, no unknowns | fast | Skip research overhead |
-| Complex task, unfamiliar domain, new tech | hard | Research needed |
-| 3+ independent features/layers/modules | parallel | Enable concurrent agents |
-| Ambiguous approach, multiple valid paths | two | Compare alternatives |
-
-Use asking the user if detection is uncertain.
-
-## Scope Challenge Integration
-
-Step 0 (Scope Challenge, see `scope-challenge.md`) runs before mode detection and can influence it:
-- If user selects **EXPANSION** → auto-suggest `--hard` or `--two`
-- If user selects **REDUCTION** → auto-suggest `--fast`
-- If user selects **HOLD** → proceed with auto-detected mode
-
-Mode can still be overridden by explicit flags (`--fast`, `--hard`, etc.).
-Scope challenge is skipped when `--fast` is explicitly set or task is trivial.
-
-## Fast Mode (`--fast`)
-
-No research. Analyze → Plan → Hydrate Tasks.
-
-1. Read codebase docs (`codebase-summary.md`, `code-standards.md`, `system-architecture.md`)
-2. Use `planner` subagent to create plan
-3. Hydrate tasks (unless `--no-tasks`)
-4. **Context reminder:** `/ck-cook --auto {absolute-plan-path}/plan.md`
-
-**Why `--auto` cook flag?** Fast planning pairs with fast execution — skip review gates.
-
-## Hard Mode (`--hard`)
-
-Research → Scout → Plan → Red Team → Validate → Hydrate Tasks.
-
-1. Spawn max 2 `researcher` agents in parallel (different aspects, max 5 calls each)
-2. Read codebase docs; if stale/missing: run `/ck-scout` to search codebase
-3. Gather research + scout report filepaths → pass to `planner` subagent
-4. Post-plan red team review (see Red Team Review section below)
-5. Post-plan validation (see Validation section below)
-6. Hydrate tasks (unless `--no-tasks`)
-7. **Context reminder:** `/ck-cook {absolute-plan-path}/plan.md`
-
-**Why no cook flag?** Thorough planning needs interactive review gates.
-
-## Parallel Mode (`--parallel`)
-
-Research → Scout → Plan with file ownership → Red Team → Validate → Hydrate Tasks with dependency graph.
-
-1. Same as Hard mode steps 1-3
-2. Planner creates phases with:
-   - **Exclusive file ownership** per phase (no overlap)
-   - **Dependency matrix** (which phases run concurrently vs sequentially)
-   - **Conflict prevention** strategy
-3. plan.md includes: dependency graph, execution strategy, file ownership matrix
-4. Hydrate tasks: `addBlockedBy` for sequential deps, no blockers for parallel groups
-5. Post-plan red team review
-6. Post-plan validation
-7. **Context reminder:** `/ck-cook --parallel {absolute-plan-path}/plan.md`
-
-### Parallel Phase Requirements
-- Each phase self-contained, no runtime deps on other phases
-- Clear file boundaries — each file modified in ONE phase only
-- Group by: architectural layer, feature domain, or technology stack
-- Example: Phases 1-3 parallel (DB/API/UI), Phase 4 sequential (integration tests)
-
-## Two-Approach Mode (`--two`)
-
-Research → Scout → Plan 2 approaches → Compare → Hydrate Tasks.
-
-1. Same as Hard mode steps 1-3
-2. Planner creates 2 implementation approaches with:
-   - Clear trade-offs (pros/cons each)
-   - Recommended approach with rationale
-3. User selects approach
-4. Post-plan red team review on selected approach
-5. Post-plan validation
-6. Hydrate tasks for selected approach (unless `--no-tasks`)
-7. **Context reminder:** `/ck-cook {absolute-plan-path}/plan.md`
-
-## Task Hydration Per Mode
-
-| Mode | Task Granularity | Dependency Pattern |
-|------|------------------|--------------------|
-| fast | Phase-level only | Sequential chain |
-| hard | Phase + critical steps | Sequential + step deps |
-| parallel | Phase + steps + ownership | Parallel groups + sequential deps |
-| two | After user selects approach | Sequential chain |
-
-All modes: See `task-management.md` for TaskCreate patterns and metadata.
-
-## Post-Plan Red Team Review
-
-Adversarial review that spawns hostile reviewers to find flaws before validation.
-
-**Available in:** hard, parallel, two modes. **Skipped in:** fast mode.
-
-**Invocation:** Run `/ck-plan red-team {plan-directory-path}`.
-```
-/ck-plan red-team {plan-directory-path}
-```
-
-**Sequence:** Red team runs BEFORE validation because:
-1. Red team may change the plan (added risks, removed sections, new constraints)
-2. Validation should confirm the FINAL plan, not a pre-review draft
-3. Validating first then red-teaming would invalidate validation answers
-
-## Post-Plan Validation
-
-Check `## Plan Context` → `Validation: mode=X, questions=MIN-MAX`:
-
-| Mode | Behavior |
-|------|----------|
-| `prompt` | Ask: "Validate this plan with interview?" → Yes (Recommended) / No |
-| `auto` | Run `/ck-plan validate {plan-directory-path}` |
-| `off` | Skip validation |
-
-**Invocation (when prompt mode, user says yes):** Run:
-```
-/ck-plan validate {plan-directory-path}
-```
-
-**Available in:** hard, parallel, two modes. **Skipped in:** fast mode.
-
-## Context Reminder (MANDATORY)
-
-After plan creation, MUST output with **actual absolute path**:
-
-| Mode | Cook Command |
-|------|-----------------------------|
-| fast | `/ck-cook --auto {path}/plan.md` |
-| hard | `/ck-cook {path}/plan.md` |
-| parallel | `/ck-cook --parallel {path}/plan.md` |
-| two | `/ck-cook {path}/plan.md` |
-
-> **Best Practice:** Run `/clear` before implementing to reduce planning-context carryover.
-> Then run the cook command above.
-
-**Why absolute path?** After `/clear`, the new session loses previous context.
-This reminder is **NON-NEGOTIABLE** — always output after presenting the plan.
-
-## Pre-Creation Check
-
-Check `## Plan Context` in injected context:
-- **"Plan: {path}"** → Ask "Continue with existing plan? [Y/n]"
-- **"Suggested: {path}"** → Branch hint only, ask if activate or create new
-- **"Plan: none"** → Create new using `Plan dir:` from `## Naming`
-
-Pass plan directory path to every subagent during the process.

package/skills/problem-solving/SKILL.md

@@ -1,96 +0,0 @@
----
-name: problem-solving
-description: Apply systematic problem-solving techniques when stuck. Use for complexity spirals, innovation blocks, recurring patterns, assumption constraints, simplification cascades, scale uncertainty.
-argument-hint: "[problem description]"
----
-
-# Problem-Solving Techniques
-
-Systematic approaches for different types of stuck-ness. Each technique targets specific problem patterns.
-
-## When to Use
-
-Apply when encountering:
-- **Complexity spiraling** - Multiple implementations, growing special cases, excessive branching
-- **Innovation blocks** - Conventional solutions inadequate, need breakthrough thinking
-- **Recurring patterns** - Same issue across domains, reinventing solutions
-- **Assumption constraints** - Forced into "only way", can't question premise
-- **Scale uncertainty** - Production readiness unclear, edge cases unknown
-- **General stuck-ness** - Unsure which technique applies
-
-## Quick Dispatch
-
-**Match symptom to technique:**
-
-| Stuck Symptom | Technique | Reference |
-|---------------|-----------|-----------|
-| Same thing implemented 5+ ways, growing special cases | **Simplification Cascades** | `references/simplification-cascades.md` |
-| Conventional solutions inadequate, need breakthrough | **Collision-Zone Thinking** | `references/collision-zone-thinking.md` |
-| Same issue in different places, reinventing wheels | **Meta-Pattern Recognition** | `references/meta-pattern-recognition.md` |
-| Solution feels forced, "must be done this way" | **Inversion Exercise** | `references/inversion-exercise.md` |
-| Will this work at production? Edge cases unclear? | **Scale Game** | `references/scale-game.md` |
-| Unsure which technique to use | **When Stuck** | `references/when-stuck.md` |
-
-## Core Techniques
-
-### 1. Simplification Cascades
-Find one insight eliminating multiple components. "If this is true, we don't need X, Y, Z."
-
-**Key insight:** Everything is a special case of one general pattern.
-
-**Red flag:** "Just need to add one more case..." (repeating forever)
-
-### 2. Collision-Zone Thinking
-Force unrelated concepts together to discover emergent properties. "What if we treated X like Y?"
-
-**Key insight:** Revolutionary ideas from deliberate metaphor-mixing.
-
-**Red flag:** "I've tried everything in this domain"
-
-### 3. Meta-Pattern Recognition
-Spot patterns appearing in 3+ domains to find universal principles.
-
-**Key insight:** Patterns in how patterns emerge reveal reusable abstractions.
-
-**Red flag:** "This problem is unique" (probably not)
-
-### 4. Inversion Exercise
-Flip core assumptions to reveal hidden constraints. "What if the opposite were true?"
-
-**Key insight:** Valid inversions reveal context-dependence of "rules."
-
-**Red flag:** "There's only one way to do this"
-
-### 5. Scale Game
-Test at extremes (1000x bigger/smaller, instant/year-long) to expose fundamental truths.
-
-**Key insight:** What works at one scale fails at another.
-
-**Red flag:** "Should scale fine" (without testing)
-
-## Application Process
-
-1. **Identify stuck-type** - Match symptom to technique above
-2. **Load detailed reference** - Read specific technique from `references/`
-3. **Apply systematically** - Follow technique's process
-4. **Document insights** - Record what worked/failed
-5. **Combine if needed** - Some problems need multiple techniques
-
-## Combining Techniques
-
-Powerful combinations:
-- **Simplification + Meta-pattern** - Find pattern, then simplify all instances
-- **Collision + Inversion** - Force metaphor, then invert its assumptions
-- **Scale + Simplification** - Extremes reveal what to eliminate
-- **Meta-pattern + Scale** - Universal patterns tested at extremes
-
-## References
-
-Load detailed guides as needed:
-- `references/when-stuck.md` - Dispatch flowchart and decision tree
-- `references/simplification-cascades.md` - Cascade detection and extraction
-- `references/collision-zone-thinking.md` - Metaphor collision process
-- `references/meta-pattern-recognition.md` - Pattern abstraction techniques
-- `references/inversion-exercise.md` - Assumption flipping methodology
-- `references/scale-game.md` - Extreme testing procedures
-- `references/attribution.md` - Source and adaptation notes