cokit-cli 1.0.8 → 1.0.9

package/templates/repo/.github/skills/ck-problem-solving/references/inversion-exercise.md

@@ -1,91 +1,91 @@
-# Inversion Exercise
-
-Flip core assumptions to reveal hidden constraints and alternative approaches. "What if the opposite were true?"
-
-## Core Principle
-
-**Inversion exposes hidden assumptions.** Sometimes the opposite reveals the truth.
-
-## When to Use
-
-| Symptom | Action |
-|---------|--------|
-| "There's only one way" | Flip the assumption |
-| Solution feels forced | Invert the constraints |
-| Can't articulate why necessary | Question the "must" |
-| "This is just how it's done" | Try the opposite |
-
-## Quick Reference
-
-| Normal Assumption | Inverted | What It Reveals |
-|-------------------|----------|-----------------|
-| Cache to reduce latency | Add latency to enable caching | Debouncing patterns |
-| Pull data when needed | Push data before needed | Prefetching, eager loading |
-| Handle errors when occur | Make errors impossible | Type systems, contracts |
-| Build features users want | Remove features users don't need | Simplicity >> addition |
-| Optimize for common case | Optimize for worst case | Resilience patterns |
-
-## Process
-
-1. **List core assumptions** - What "must" be true?
-2. **Invert each systematically** - "What if opposite were true?"
-3. **Explore implications** - What would we do differently?
-4. **Find valid inversions** - Which actually work somewhere?
-5. **Document insights** - What did we learn?
-
-## Detailed Example
-
-**Problem:** Users complain app is slow
-
-**Normal approach:** Make everything faster
-- Add caching
-- Optimize queries
-- Use CDN
-- Reduce bundle size
-
-**Inverted approach:** Make things intentionally slower in some places
-- **Debounce search** - Add latency → enable better results (wait for full query)
-- **Rate limit requests** - Add friction → prevent abuse, improve for others
-- **Lazy load content** - Delay loading → reduce initial load time
-- **Progressive rendering** - Show slower → perceived performance
-
-**Insight:** Strategic slowness can improve UX
-
-## Valid vs Invalid Inversions
-
-**Valid inversion example:**
-- Normal: "Store data in database"
-- Inverted: "Derive data on-demand instead of storing"
-- Valid when: Computation cheaper than storage, data changes frequently
-
-**Invalid inversion example:**
-- Normal: "Validate user input"
-- Inverted: "Trust all user input"
-- Invalid because: Security vulnerability, not context-dependent
-
-**Test validity:** Does the inversion work in ANY context? If yes, it's valid somewhere.
-
-## Common Inversions
-
-- **Eager → Lazy** (or vice versa)
-- **Push → Pull** (or vice versa)
-- **Store → Compute** (or vice versa)
-- **Optimize → Simplify** (or vice versa)
-- **Add features → Remove features** (or vice versa)
-
-## Red Flags
-
-You need inversion exercise when:
-- "There's only one way to do this"
-- Forcing solution that feels wrong
-- Can't articulate why approach is necessary
-- "This is just how it's done"
-- Stuck on unquestioned assumptions
-
-## Remember
-
-- Not all inversions work (test boundaries)
-- Valid inversions reveal context-dependence
-- Sometimes opposite is the answer
-- Question "must be" statements
-- Document both successful and failed inversions
+# Inversion Exercise
+
+Flip core assumptions to reveal hidden constraints and alternative approaches. "What if the opposite were true?"
+
+## Core Principle
+
+**Inversion exposes hidden assumptions.** Sometimes the opposite reveals the truth.
+
+## When to Use
+
+| Symptom | Action |
+|---------|--------|
+| "There's only one way" | Flip the assumption |
+| Solution feels forced | Invert the constraints |
+| Can't articulate why necessary | Question the "must" |
+| "This is just how it's done" | Try the opposite |
+
+## Quick Reference
+
+| Normal Assumption | Inverted | What It Reveals |
+|-------------------|----------|-----------------|
+| Cache to reduce latency | Add latency to enable caching | Debouncing patterns |
+| Pull data when needed | Push data before needed | Prefetching, eager loading |
+| Handle errors when occur | Make errors impossible | Type systems, contracts |
+| Build features users want | Remove features users don't need | Simplicity >> addition |
+| Optimize for common case | Optimize for worst case | Resilience patterns |
+
+## Process
+
+1. **List core assumptions** - What "must" be true?
+2. **Invert each systematically** - "What if opposite were true?"
+3. **Explore implications** - What would we do differently?
+4. **Find valid inversions** - Which actually work somewhere?
+5. **Document insights** - What did we learn?
+
+## Detailed Example
+
+**Problem:** Users complain app is slow
+
+**Normal approach:** Make everything faster
+- Add caching
+- Optimize queries
+- Use CDN
+- Reduce bundle size
+
+**Inverted approach:** Make things intentionally slower in some places
+- **Debounce search** - Add latency → enable better results (wait for full query)
+- **Rate limit requests** - Add friction → prevent abuse, improve for others
+- **Lazy load content** - Delay loading → reduce initial load time
+- **Progressive rendering** - Show slower → perceived performance
+
+**Insight:** Strategic slowness can improve UX
+
+## Valid vs Invalid Inversions
+
+**Valid inversion example:**
+- Normal: "Store data in database"
+- Inverted: "Derive data on-demand instead of storing"
+- Valid when: Computation cheaper than storage, data changes frequently
+
+**Invalid inversion example:**
+- Normal: "Validate user input"
+- Inverted: "Trust all user input"
+- Invalid because: Security vulnerability, not context-dependent
+
+**Test validity:** Does the inversion work in ANY context? If yes, it's valid somewhere.
+
+## Common Inversions
+
+- **Eager → Lazy** (or vice versa)
+- **Push → Pull** (or vice versa)
+- **Store → Compute** (or vice versa)
+- **Optimize → Simplify** (or vice versa)
+- **Add features → Remove features** (or vice versa)
+
+## Red Flags
+
+You need inversion exercise when:
+- "There's only one way to do this"
+- Forcing solution that feels wrong
+- Can't articulate why approach is necessary
+- "This is just how it's done"
+- Stuck on unquestioned assumptions
+
+## Remember
+
+- Not all inversions work (test boundaries)
+- Valid inversions reveal context-dependence
+- Sometimes opposite is the answer
+- Question "must be" statements
+- Document both successful and failed inversions

package/templates/repo/.github/skills/ck-problem-solving/references/meta-pattern-recognition.md

@@ -1,87 +1,87 @@
-# Meta-Pattern Recognition
-
-Spot patterns appearing in 3+ domains to find universal principles.
-
-## Core Principle
-
-**Find patterns in how patterns emerge.** When the same pattern appears in 3+ domains, it's likely a universal principle worth extracting.
-
-## When to Use
-
-| Symptom | Action |
-|---------|--------|
-| Same issue in different places | Extract the abstract form |
-| Déjà vu in problem-solving | Find the universal pattern |
-| Reinventing wheels across domains | Identify the meta-pattern |
-| "Haven't we done this before?" | Yes, find and reuse it |
-
-## Quick Reference
-
-| Pattern Appears In | Abstract Form | Where Else? |
-|-------------------|---------------|-------------|
-| CPU/DB/HTTP/DNS caching | Store frequently-accessed data closer | LLM prompt caching, CDN |
-| Layering (network/storage/compute) | Separate concerns into abstraction levels | Architecture, org structure |
-| Queuing (message/task/request) | Decouple producer from consumer with buffer | Event systems, async |
-| Pooling (connection/thread/object) | Reuse expensive resources | Memory mgmt, governance |
-
-## Process
-
-1. **Spot repetition** - See same shape in 3+ places
-2. **Extract abstract form** - Describe independent of any domain
-3. **Identify variations** - How does it adapt per domain?
-4. **Check applicability** - Where else might this help?
-5. **Document pattern** - Make it reusable
-
-## Detailed Example
-
-**Pattern spotted:** Rate limiting appears in:
-- API throttling (requests per minute)
-- Traffic shaping (packets per second)
-- Circuit breakers (failures per window)
-- Admission control (concurrent connections)
-
-**Abstract form:** Bound resource consumption to prevent exhaustion
-
-**Variation points:**
-- What resource (requests, packets, failures, connections)
-- What limit (per time window, concurrent, cumulative)
-- What happens when exceeded (reject, queue, degrade)
-
-**New application:** LLM token budgets
-- Same pattern: prevent context window exhaustion
-- Resource: tokens
-- Limit: context window size
-- Action: truncate or reject
-
-## 3+ Domain Rule
-
-**Why 3 domains?**
-- 1 occurrence = coincidence
-- 2 occurrences = possible pattern
-- 3+ occurrences = likely universal
-
-**Domain independence test:**
-Can you describe the pattern without mentioning specific domains?
-
-## Red Flags
-
-Signs you're missing meta-patterns:
-- "This problem is unique" (probably not)
-- Multiple teams solving "different" problems identically
-- Reinventing wheels across domains
-- "Haven't we done something like this?" (yes, find it)
-
-## Benefits of Meta-Patterns
-
-- **Battle-tested** - Proven across multiple domains
-- **Reusable** - Apply to new situations
-- **Universal** - Domain-independent solutions
-- **Documented** - Known variations and trade-offs
-
-## Remember
-
-- 3+ domains = likely universal
-- Abstract form reveals new applications
-- Variations show adaptation points
-- Universal patterns save time
-- Document for future reuse
+# Meta-Pattern Recognition
+
+Spot patterns appearing in 3+ domains to find universal principles.
+
+## Core Principle
+
+**Find patterns in how patterns emerge.** When the same pattern appears in 3+ domains, it's likely a universal principle worth extracting.
+
+## When to Use
+
+| Symptom | Action |
+|---------|--------|
+| Same issue in different places | Extract the abstract form |
+| Déjà vu in problem-solving | Find the universal pattern |
+| Reinventing wheels across domains | Identify the meta-pattern |
+| "Haven't we done this before?" | Yes, find and reuse it |
+
+## Quick Reference
+
+| Pattern Appears In | Abstract Form | Where Else? |
+|-------------------|---------------|-------------|
+| CPU/DB/HTTP/DNS caching | Store frequently-accessed data closer | LLM prompt caching, CDN |
+| Layering (network/storage/compute) | Separate concerns into abstraction levels | Architecture, org structure |
+| Queuing (message/task/request) | Decouple producer from consumer with buffer | Event systems, async |
+| Pooling (connection/thread/object) | Reuse expensive resources | Memory mgmt, governance |
+
+## Process
+
+1. **Spot repetition** - See same shape in 3+ places
+2. **Extract abstract form** - Describe independent of any domain
+3. **Identify variations** - How does it adapt per domain?
+4. **Check applicability** - Where else might this help?
+5. **Document pattern** - Make it reusable
+
+## Detailed Example
+
+**Pattern spotted:** Rate limiting appears in:
+- API throttling (requests per minute)
+- Traffic shaping (packets per second)
+- Circuit breakers (failures per window)
+- Admission control (concurrent connections)
+
+**Abstract form:** Bound resource consumption to prevent exhaustion
+
+**Variation points:**
+- What resource (requests, packets, failures, connections)
+- What limit (per time window, concurrent, cumulative)
+- What happens when exceeded (reject, queue, degrade)
+
+**New application:** LLM token budgets
+- Same pattern: prevent context window exhaustion
+- Resource: tokens
+- Limit: context window size
+- Action: truncate or reject
+
+## 3+ Domain Rule
+
+**Why 3 domains?**
+- 1 occurrence = coincidence
+- 2 occurrences = possible pattern
+- 3+ occurrences = likely universal
+
+**Domain independence test:**
+Can you describe the pattern without mentioning specific domains?
+
+## Red Flags
+
+Signs you're missing meta-patterns:
+- "This problem is unique" (probably not)
+- Multiple teams solving "different" problems identically
+- Reinventing wheels across domains
+- "Haven't we done something like this?" (yes, find it)
+
+## Benefits of Meta-Patterns
+
+- **Battle-tested** - Proven across multiple domains
+- **Reusable** - Apply to new situations
+- **Universal** - Domain-independent solutions
+- **Documented** - Known variations and trade-offs
+
+## Remember
+
+- 3+ domains = likely universal
+- Abstract form reveals new applications
+- Variations show adaptation points
+- Universal patterns save time
+- Document for future reuse

package/templates/repo/.github/skills/ck-problem-solving/references/scale-game.md

@@ -1,95 +1,95 @@
-# Scale Game
-
-Test at extremes (1000x bigger/smaller, instant/year-long) to expose fundamental truths hidden at normal scales.
-
-## Core Principle
-
-**Extremes expose fundamentals.** What works at one scale fails at another.
-
-## When to Use
-
-| Symptom | Action |
-|---------|--------|
-| "Should scale fine" (without testing) | Test at extremes |
-| Uncertain about production behavior | Scale up 1000x |
-| Edge cases unclear | Test minimum and maximum |
-| Architecture validation needed | Extreme testing |
-
-## Quick Reference
-
-| Scale Dimension | Test At Extremes | What It Reveals |
-|-----------------|------------------|-----------------|
-| **Volume** | 1 item vs 1B items | Algorithmic complexity limits |
-| **Speed** | Instant vs 1 year | Async requirements, caching needs |
-| **Users** | 1 user vs 1B users | Concurrency issues, resource limits |
-| **Duration** | Milliseconds vs years | Memory leaks, state growth |
-| **Failure rate** | Never fails vs always fails | Error handling adequacy |
-
-## Process
-
-1. **Pick dimension** - What could vary extremely?
-2. **Test minimum** - What if 1000x smaller/faster/fewer?
-3. **Test maximum** - What if 1000x bigger/slower/more?
-4. **Note what breaks** - Where do limits appear?
-5. **Note what survives** - What's fundamentally sound?
-6. **Design for reality** - Use insights to validate architecture
-
-## Detailed Examples
-
-### Example 1: Error Handling
-- **Normal scale:** "Handle errors when they occur" works fine
-- **At 1B scale:** Error volume overwhelms logging, crashes system
-- **Reveals:** Need to make errors impossible (type systems) or expect them (chaos engineering)
-- **Action:** Design error handling for volume, not just occurrence
-
-### Example 2: Synchronous APIs
-- **Normal scale:** Direct function calls work, < 100ms latency
-- **At global scale:** Network latency makes synchronous unusable (200-500ms)
-- **Reveals:** Async/messaging becomes survival requirement, not optimization
-- **Action:** Design async-first from start
-
-### Example 3: In-Memory State
-- **Normal duration:** Works for hours/days in development
-- **At years:** Memory grows unbounded, eventual crash (weeks → months → years)
-- **Reveals:** Need persistence or periodic cleanup, can't rely on memory forever
-- **Action:** Design for stateless or externalized state
-
-### Example 4: Single vs Million Users
-- **Normal scale:** Session in memory works for 100 users
-- **At 1M scale:** Memory exhausted, server crashes
-- **Reveals:** Need distributed session store (Redis, database)
-- **Action:** Design for horizontal scaling from start
-
-## Both Directions Matter
-
-**Test smaller too:**
-- What if only 1 user? Does complexity make sense?
-- What if only 10 items? Is optimization premature?
-- What if instant response? What becomes unnecessary?
-
-Often reveals over-engineering or premature optimization.
-
-## Red Flags
-
-You need scale game when:
-- "It works in dev" (but will it work in production?)
-- No idea where limits are
-- "Should scale fine" (without evidence)
-- Surprised by production behavior
-- Architecture feels arbitrary
-
-## Success Metrics
-
-After scale game, you should know:
-- Where system breaks (exact limits)
-- What survives (fundamentally sound parts)
-- What needs redesign (scale-dependent)
-- Production readiness (validated architecture)
-
-## Remember
-
-- Extremes reveal fundamentals hidden at normal scales
-- What works at one scale fails at another
-- Test BOTH directions (bigger AND smaller)
-- Use insights to validate architecture early
-- Don't guess - test at extremes
+# Scale Game
+
+Test at extremes (1000x bigger/smaller, instant/year-long) to expose fundamental truths hidden at normal scales.
+
+## Core Principle
+
+**Extremes expose fundamentals.** What works at one scale fails at another.
+
+## When to Use
+
+| Symptom | Action |
+|---------|--------|
+| "Should scale fine" (without testing) | Test at extremes |
+| Uncertain about production behavior | Scale up 1000x |
+| Edge cases unclear | Test minimum and maximum |
+| Architecture validation needed | Extreme testing |
+
+## Quick Reference
+
+| Scale Dimension | Test At Extremes | What It Reveals |
+|-----------------|------------------|-----------------|
+| **Volume** | 1 item vs 1B items | Algorithmic complexity limits |
+| **Speed** | Instant vs 1 year | Async requirements, caching needs |
+| **Users** | 1 user vs 1B users | Concurrency issues, resource limits |
+| **Duration** | Milliseconds vs years | Memory leaks, state growth |
+| **Failure rate** | Never fails vs always fails | Error handling adequacy |
+
+## Process
+
+1. **Pick dimension** - What could vary extremely?
+2. **Test minimum** - What if 1000x smaller/faster/fewer?
+3. **Test maximum** - What if 1000x bigger/slower/more?
+4. **Note what breaks** - Where do limits appear?
+5. **Note what survives** - What's fundamentally sound?
+6. **Design for reality** - Use insights to validate architecture
+
+## Detailed Examples
+
+### Example 1: Error Handling
+- **Normal scale:** "Handle errors when they occur" works fine
+- **At 1B scale:** Error volume overwhelms logging, crashes system
+- **Reveals:** Need to make errors impossible (type systems) or expect them (chaos engineering)
+- **Action:** Design error handling for volume, not just occurrence
+
+### Example 2: Synchronous APIs
+- **Normal scale:** Direct function calls work, < 100ms latency
+- **At global scale:** Network latency makes synchronous unusable (200-500ms)
+- **Reveals:** Async/messaging becomes survival requirement, not optimization
+- **Action:** Design async-first from start
+
+### Example 3: In-Memory State
+- **Normal duration:** Works for hours/days in development
+- **At years:** Memory grows unbounded, eventual crash (weeks → months → years)
+- **Reveals:** Need persistence or periodic cleanup, can't rely on memory forever
+- **Action:** Design for stateless or externalized state
+
+### Example 4: Single vs Million Users
+- **Normal scale:** Session in memory works for 100 users
+- **At 1M scale:** Memory exhausted, server crashes
+- **Reveals:** Need distributed session store (Redis, database)
+- **Action:** Design for horizontal scaling from start
+
+## Both Directions Matter
+
+**Test smaller too:**
+- What if only 1 user? Does complexity make sense?
+- What if only 10 items? Is optimization premature?
+- What if instant response? What becomes unnecessary?
+
+Often reveals over-engineering or premature optimization.
+
+## Red Flags
+
+You need scale game when:
+- "It works in dev" (but will it work in production?)
+- No idea where limits are
+- "Should scale fine" (without evidence)
+- Surprised by production behavior
+- Architecture feels arbitrary
+
+## Success Metrics
+
+After scale game, you should know:
+- Where system breaks (exact limits)
+- What survives (fundamentally sound parts)
+- What needs redesign (scale-dependent)
+- Production readiness (validated architecture)
+
+## Remember
+
+- Extremes reveal fundamentals hidden at normal scales
+- What works at one scale fails at another
+- Test BOTH directions (bigger AND smaller)
+- Use insights to validate architecture early
+- Don't guess - test at extremes