@vodailoc/kilo-kit-mcp 1.1.0 → 1.2.0

package/skills/problem-solving/simplification-cascades/SKILL.md

@@ -1,76 +1,76 @@
----
-name: Simplification Cascades
-description: Find one insight that eliminates multiple components - "if this is true, we don't need X, Y, or Z"
-when_to_use: when implementing the same concept multiple ways, accumulating special cases, or complexity is spiraling
-version: 1.1.0
----
-
-# Simplification Cascades
-
-## Overview
-
-Sometimes one insight eliminates 10 things. Look for the unifying principle that makes multiple components unnecessary.
-
-**Core principle:** "Everything is a special case of..." collapses complexity dramatically.
-
-## Quick Reference
-
-| Symptom | Likely Cascade |
-|---------|----------------|
-| Same thing implemented 5+ ways | Abstract the common pattern |
-| Growing special case list | Find the general case |
-| Complex rules with exceptions | Find the rule that has no exceptions |
-| Excessive config options | Find defaults that work for 95% |
-
-## The Pattern
-
-**Look for:**
-- Multiple implementations of similar concepts
-- Special case handling everywhere
-- "We need to handle A, B, C, D differently..."
-- Complex rules with many exceptions
-
-**Ask:** "What if they're all the same thing underneath?"
-
-## Examples
-
-### Cascade 1: Stream Abstraction
-**Before:** Separate handlers for batch/real-time/file/network data
-**Insight:** "All inputs are streams - just different sources"
-**After:** One stream processor, multiple stream sources
-**Eliminated:** 4 separate implementations
-
-### Cascade 2: Resource Governance
-**Before:** Session tracking, rate limiting, file validation, connection pooling (all separate)
-**Insight:** "All are per-entity resource limits"
-**After:** One ResourceGovernor with 4 resource types
-**Eliminated:** 4 custom enforcement systems
-
-### Cascade 3: Immutability
-**Before:** Defensive copying, locking, cache invalidation, temporal coupling
-**Insight:** "Treat everything as immutable data + transformations"
-**After:** Functional programming patterns
-**Eliminated:** Entire classes of synchronization problems
-
-## Process
-
-1. **List the variations** - What's implemented multiple ways?
-2. **Find the essence** - What's the same underneath?
-3. **Extract abstraction** - What's the domain-independent pattern?
-4. **Test it** - Do all cases fit cleanly?
-5. **Measure cascade** - How many things become unnecessary?
-
-## Red Flags You're Missing a Cascade
-
-- "We just need to add one more case..." (repeating forever)
-- "These are all similar but different" (maybe they're the same?)
-- Refactoring feels like whack-a-mole (fix one, break another)
-- Growing configuration file
-- "Don't touch that, it's complicated" (complexity hiding pattern)
-
-## Remember
-
-- Simplification cascades = 10x wins, not 10% improvements
-- One powerful abstraction > ten clever hacks
-- The pattern is usually already there, just needs recognition
-- Measure in "how many things can we delete?"
+---
+name: Simplification Cascades
+description: Find one insight that eliminates multiple components - "if this is true, we don't need X, Y, or Z"
+when_to_use: when implementing the same concept multiple ways, accumulating special cases, or complexity is spiraling
+version: 1.1.0
+---
+
+# Simplification Cascades
+
+## Overview
+
+Sometimes one insight eliminates 10 things. Look for the unifying principle that makes multiple components unnecessary.
+
+**Core principle:** "Everything is a special case of..." collapses complexity dramatically.
+
+## Quick Reference
+
+| Symptom | Likely Cascade |
+|---------|----------------|
+| Same thing implemented 5+ ways | Abstract the common pattern |
+| Growing special case list | Find the general case |
+| Complex rules with exceptions | Find the rule that has no exceptions |
+| Excessive config options | Find defaults that work for 95% |
+
+## The Pattern
+
+**Look for:**
+- Multiple implementations of similar concepts
+- Special case handling everywhere
+- "We need to handle A, B, C, D differently..."
+- Complex rules with many exceptions
+
+**Ask:** "What if they're all the same thing underneath?"
+
+## Examples
+
+### Cascade 1: Stream Abstraction
+**Before:** Separate handlers for batch/real-time/file/network data
+**Insight:** "All inputs are streams - just different sources"
+**After:** One stream processor, multiple stream sources
+**Eliminated:** 4 separate implementations
+
+### Cascade 2: Resource Governance
+**Before:** Session tracking, rate limiting, file validation, connection pooling (all separate)
+**Insight:** "All are per-entity resource limits"
+**After:** One ResourceGovernor with 4 resource types
+**Eliminated:** 4 custom enforcement systems
+
+### Cascade 3: Immutability
+**Before:** Defensive copying, locking, cache invalidation, temporal coupling
+**Insight:** "Treat everything as immutable data + transformations"
+**After:** Functional programming patterns
+**Eliminated:** Entire classes of synchronization problems
+
+## Process
+
+1. **List the variations** - What's implemented multiple ways?
+2. **Find the essence** - What's the same underneath?
+3. **Extract abstraction** - What's the domain-independent pattern?
+4. **Test it** - Do all cases fit cleanly?
+5. **Measure cascade** - How many things become unnecessary?
+
+## Red Flags You're Missing a Cascade
+
+- "We just need to add one more case..." (repeating forever)
+- "These are all similar but different" (maybe they're the same?)
+- Refactoring feels like whack-a-mole (fix one, break another)
+- Growing configuration file
+- "Don't touch that, it's complicated" (complexity hiding pattern)
+
+## Remember
+
+- Simplification cascades = 10x wins, not 10% improvements
+- One powerful abstraction > ten clever hacks
+- The pattern is usually already there, just needs recognition
+- Measure in "how many things can we delete?"

package/skills/problem-solving/when-stuck/SKILL.md

@@ -1,88 +1,88 @@
----
-name: When Stuck - Problem-Solving Dispatch
-description: Dispatch to the right problem-solving technique based on how you're stuck
-when_to_use: when stuck and unsure which problem-solving technique to apply for your specific type of stuck-ness
-version: 1.1.0
----
-
-# When Stuck - Problem-Solving Dispatch
-
-## Overview
-
-Different stuck-types need different techniques. This skill helps you quickly identify which problem-solving skill to use.
-
-**Core principle:** Match stuck-symptom to technique.
-
-## Quick Dispatch
-
-```dot
-digraph stuck_dispatch {
-    rankdir=TB;
-    node [shape=box, style=rounded];
-
-    stuck [label="You're Stuck", shape=ellipse, style=filled, fillcolor=lightblue];
-
-    complexity [label="Same thing implemented 5+ ways?\nGrowing special cases?\nExcessive if/else?"];
-    innovation [label="Can't find fitting approach?\nConventional solutions inadequate?\nNeed breakthrough?"];
-    patterns [label="Same issue in different places?\nFeels familiar across domains?\nReinventing wheels?"];
-    assumptions [label="Solution feels forced?\n'This must be done this way'?\nStuck on assumptions?"];
-    scale [label="Will this work at production?\nEdge cases unclear?\nUnsure of limits?"];
-    bugs [label="Code behaving wrong?\nTest failing?\nUnexpected output?"];
-
-    stuck -> complexity;
-    stuck -> innovation;
-    stuck -> patterns;
-    stuck -> assumptions;
-    stuck -> scale;
-    stuck -> bugs;
-
-    complexity -> simp [label="yes"];
-    innovation -> collision [label="yes"];
-    patterns -> meta [label="yes"];
-    assumptions -> invert [label="yes"];
-    scale -> scale_skill [label="yes"];
-    bugs -> debug [label="yes"];
-
-    simp [label="skills/problem-solving/\nsimplification-cascades", shape=box, style="rounded,filled", fillcolor=lightgreen];
-    collision [label="skills/problem-solving/\ncollision-zone-thinking", shape=box, style="rounded,filled", fillcolor=lightgreen];
-    meta [label="skills/problem-solving/\nmeta-pattern-recognition", shape=box, style="rounded,filled", fillcolor=lightgreen];
-    invert [label="skills/problem-solving/\ninversion-exercise", shape=box, style="rounded,filled", fillcolor=lightgreen];
-    scale_skill [label="skills/problem-solving/\nscale-game", shape=box, style="rounded,filled", fillcolor=lightgreen];
-    debug [label="skills/debugging/\nsystematic-debugging", shape=box, style="rounded,filled", fillcolor=lightyellow];
-}
-```
-
-## Stuck-Type → Technique
-
-| How You're Stuck | Use This Skill |
-|------------------|----------------|
-| **Complexity spiraling** - Same thing 5+ ways, growing special cases | skills/problem-solving/simplification-cascades |
-| **Need innovation** - Conventional solutions inadequate, can't find fitting approach | skills/problem-solving/collision-zone-thinking |
-| **Recurring patterns** - Same issue different places, reinventing wheels | skills/problem-solving/meta-pattern-recognition |
-| **Forced by assumptions** - "Must be done this way", can't question premise | skills/problem-solving/inversion-exercise |
-| **Scale uncertainty** - Will it work in production? Edge cases unclear? | skills/problem-solving/scale-game |
-| **Code broken** - Wrong behavior, test failing, unexpected output | skills/debugging/systematic-debugging |
-| **Multiple independent problems** - Can parallelize investigation | skills/collaboration/dispatching-parallel-agents |
-| **Root cause unknown** - Symptom clear, cause hidden | skills/debugging/root-cause-tracing |
-
-## Process
-
-1. **Identify stuck-type** - What symptom matches above?
-2. **Load that skill** - Read the specific technique
-3. **Apply technique** - Follow its process
-4. **If still stuck** - Try different technique or combine
-
-## Combining Techniques
-
-Some problems need multiple techniques:
-
-- **Simplification + Meta-pattern**: Find pattern, then simplify all instances
-- **Collision + Inversion**: Force metaphor, then invert its assumptions
-- **Scale + Simplification**: Extremes reveal what to eliminate
-
-## Remember
-
-- Match symptom to technique
-- One technique at a time
-- Combine if first doesn't work
-- Document what you tried
+---
+name: When Stuck - Problem-Solving Dispatch
+description: Dispatch to the right problem-solving technique based on how you're stuck
+when_to_use: when stuck and unsure which problem-solving technique to apply for your specific type of stuck-ness
+version: 1.1.0
+---
+
+# When Stuck - Problem-Solving Dispatch
+
+## Overview
+
+Different stuck-types need different techniques. This skill helps you quickly identify which problem-solving skill to use.
+
+**Core principle:** Match stuck-symptom to technique.
+
+## Quick Dispatch
+
+```dot
+digraph stuck_dispatch {
+    rankdir=TB;
+    node [shape=box, style=rounded];
+
+    stuck [label="You're Stuck", shape=ellipse, style=filled, fillcolor=lightblue];
+
+    complexity [label="Same thing implemented 5+ ways?\nGrowing special cases?\nExcessive if/else?"];
+    innovation [label="Can't find fitting approach?\nConventional solutions inadequate?\nNeed breakthrough?"];
+    patterns [label="Same issue in different places?\nFeels familiar across domains?\nReinventing wheels?"];
+    assumptions [label="Solution feels forced?\n'This must be done this way'?\nStuck on assumptions?"];
+    scale [label="Will this work at production?\nEdge cases unclear?\nUnsure of limits?"];
+    bugs [label="Code behaving wrong?\nTest failing?\nUnexpected output?"];
+
+    stuck -> complexity;
+    stuck -> innovation;
+    stuck -> patterns;
+    stuck -> assumptions;
+    stuck -> scale;
+    stuck -> bugs;
+
+    complexity -> simp [label="yes"];
+    innovation -> collision [label="yes"];
+    patterns -> meta [label="yes"];
+    assumptions -> invert [label="yes"];
+    scale -> scale_skill [label="yes"];
+    bugs -> debug [label="yes"];
+
+    simp [label="skills/problem-solving/\nsimplification-cascades", shape=box, style="rounded,filled", fillcolor=lightgreen];
+    collision [label="skills/problem-solving/\ncollision-zone-thinking", shape=box, style="rounded,filled", fillcolor=lightgreen];
+    meta [label="skills/problem-solving/\nmeta-pattern-recognition", shape=box, style="rounded,filled", fillcolor=lightgreen];
+    invert [label="skills/problem-solving/\ninversion-exercise", shape=box, style="rounded,filled", fillcolor=lightgreen];
+    scale_skill [label="skills/problem-solving/\nscale-game", shape=box, style="rounded,filled", fillcolor=lightgreen];
+    debug [label="skills/debugging/\nsystematic-debugging", shape=box, style="rounded,filled", fillcolor=lightyellow];
+}
+```
+
+## Stuck-Type → Technique
+
+| How You're Stuck | Use This Skill |
+|------------------|----------------|
+| **Complexity spiraling** - Same thing 5+ ways, growing special cases | skills/problem-solving/simplification-cascades |
+| **Need innovation** - Conventional solutions inadequate, can't find fitting approach | skills/problem-solving/collision-zone-thinking |
+| **Recurring patterns** - Same issue different places, reinventing wheels | skills/problem-solving/meta-pattern-recognition |
+| **Forced by assumptions** - "Must be done this way", can't question premise | skills/problem-solving/inversion-exercise |
+| **Scale uncertainty** - Will it work in production? Edge cases unclear? | skills/problem-solving/scale-game |
+| **Code broken** - Wrong behavior, test failing, unexpected output | skills/debugging/systematic-debugging |
+| **Multiple independent problems** - Can parallelize investigation | skills/collaboration/dispatching-parallel-agents |
+| **Root cause unknown** - Symptom clear, cause hidden | skills/debugging/root-cause-tracing |
+
+## Process
+
+1. **Identify stuck-type** - What symptom matches above?
+2. **Load that skill** - Read the specific technique
+3. **Apply technique** - Follow its process
+4. **If still stuck** - Try different technique or combine
+
+## Combining Techniques
+
+Some problems need multiple techniques:
+
+- **Simplification + Meta-pattern**: Find pattern, then simplify all instances
+- **Collision + Inversion**: Force metaphor, then invert its assumptions
+- **Scale + Simplification**: Extremes reveal what to eliminate
+
+## Remember
+
+- Match symptom to technique
+- One technique at a time
+- Combine if first doesn't work
+- Document what you tried

package/skills/productivity/caveman/SKILL.md

@@ -1,49 +1,49 @@
----
-name: caveman
-description: >
-  Ultra-compressed communication mode. Cuts token usage ~75% by dropping
-  filler, articles, and pleasantries while keeping full technical accuracy.
-  Use when user says "caveman mode", "talk like caveman", "use caveman",
-  "less tokens", "be brief", or invokes /caveman.
----
-
-Respond terse like smart caveman. All technical substance stay. Only fluff die.
-
-## Persistence
-
-ACTIVE EVERY RESPONSE once triggered. No revert after many turns. No filler drift. Still active if unsure. Off only when user says "stop caveman" or "normal mode".
-
-## Rules
-
-Drop: articles (a/an/the), filler (just/really/basically/actually/simply), pleasantries (sure/certainly/of course/happy to), hedging. Fragments OK. Short synonyms (big not extensive, fix not "implement a solution for"). Abbreviate common terms (DB/auth/config/req/res/fn/impl). Strip conjunctions. Use arrows for causality (X -> Y). One word when one word enough.
-
-Technical terms stay exact. Code blocks unchanged. Errors quoted exact.
-
-Pattern: `[thing] [action] [reason]. [next step].`
-
-Not: "Sure! I'd be happy to help you with that. The issue you're experiencing is likely caused by..."
-Yes: "Bug in auth middleware. Token expiry check use `<` not `<=`. Fix:"
-
-### Examples
-
-**"Why React component re-render?"**
-
-> Inline obj prop -> new ref -> re-render. `useMemo`.
-
-**"Explain database connection pooling."**
-
-> Pool = reuse DB conn. Skip handshake -> fast under load.
-
-## Auto-Clarity Exception
-
-Drop caveman temporarily for: security warnings, irreversible action confirmations, multi-step sequences where fragment order risks misread, user asks to clarify or repeats question. Resume caveman after clear part done.
-
-Example -- destructive op:
-
-> **Warning:** This will permanently delete all rows in the `users` table and cannot be undone.
->
-> ```sql
-> DROP TABLE users;
-> ```
->
-> Caveman resume. Verify backup exist first.
+---
+name: caveman
+description: >
+  Ultra-compressed communication mode. Cuts token usage ~75% by dropping
+  filler, articles, and pleasantries while keeping full technical accuracy.
+  Use when user says "caveman mode", "talk like caveman", "use caveman",
+  "less tokens", "be brief", or invokes /caveman.
+---
+
+Respond terse like smart caveman. All technical substance stay. Only fluff die.
+
+## Persistence
+
+ACTIVE EVERY RESPONSE once triggered. No revert after many turns. No filler drift. Still active if unsure. Off only when user says "stop caveman" or "normal mode".
+
+## Rules
+
+Drop: articles (a/an/the), filler (just/really/basically/actually/simply), pleasantries (sure/certainly/of course/happy to), hedging. Fragments OK. Short synonyms (big not extensive, fix not "implement a solution for"). Abbreviate common terms (DB/auth/config/req/res/fn/impl). Strip conjunctions. Use arrows for causality (X -> Y). One word when one word enough.
+
+Technical terms stay exact. Code blocks unchanged. Errors quoted exact.
+
+Pattern: `[thing] [action] [reason]. [next step].`
+
+Not: "Sure! I'd be happy to help you with that. The issue you're experiencing is likely caused by..."
+Yes: "Bug in auth middleware. Token expiry check use `<` not `<=`. Fix:"
+
+### Examples
+
+**"Why React component re-render?"**
+
+> Inline obj prop -> new ref -> re-render. `useMemo`.
+
+**"Explain database connection pooling."**
+
+> Pool = reuse DB conn. Skip handshake -> fast under load.
+
+## Auto-Clarity Exception
+
+Drop caveman temporarily for: security warnings, irreversible action confirmations, multi-step sequences where fragment order risks misread, user asks to clarify or repeats question. Resume caveman after clear part done.
+
+Example -- destructive op:
+
+> **Warning:** This will permanently delete all rows in the `users` table and cannot be undone.
+>
+> ```sql
+> DROP TABLE users;
+> ```
+>
+> Caveman resume. Verify backup exist first.

package/skills/productivity/grill-me/SKILL.md

@@ -1,10 +1,10 @@
----
-name: grill-me
-description: Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
----
-
-Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
-
-Ask the questions one at a time.
-
-If a question can be answered by exploring the codebase, explore the codebase instead.
+---
+name: grill-me
+description: Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
+---
+
+Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
+
+Ask the questions one at a time.
+
+If a question can be answered by exploring the codebase, explore the codebase instead.

package/skills/productivity/grill-with-docs/ADR-FORMAT.md

@@ -1,47 +1,47 @@
-# ADR Format
-
-ADRs live in `docs/adr/` and use sequential numbering: `0001-slug.md`, `0002-slug.md`, etc.
-
-Create the `docs/adr/` directory lazily — only when the first ADR is needed.
-
-## Template
-
-```md
-# {Short title of the decision}
-
-{1-3 sentences: what's the context, what did we decide, and why.}
-```
-
-That's it. An ADR can be a single paragraph. The value is in recording *that* a decision was made and *why* — not in filling out sections.
-
-## Optional sections
-
-Only include these when they add genuine value. Most ADRs won't need them.
-
-- **Status** frontmatter (`proposed | accepted | deprecated | superseded by ADR-NNNN`) — useful when decisions are revisited
-- **Considered Options** — only when the rejected alternatives are worth remembering
-- **Consequences** — only when non-obvious downstream effects need to be called out
-
-## Numbering
-
-Scan `docs/adr/` for the highest existing number and increment by one.
-
-## When to offer an ADR
-
-All three of these must be true:
-
-1. **Hard to reverse** — the cost of changing your mind later is meaningful
-2. **Surprising without context** — a future reader will look at the code and wonder "why on earth did they do it this way?"
-3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons
-
-If a decision is easy to reverse, skip it — you'll just reverse it. If it's not surprising, nobody will wonder why. If there was no real alternative, there's nothing to record beyond "we did the obvious thing."
-
-### What qualifies
-
-- **Architectural shape.** "We're using a monorepo." "The write model is event-sourced, the read model is projected into Postgres."
-- **Integration patterns between contexts.** "Ordering and Billing communicate via domain events, not synchronous HTTP."
-- **Technology choices that carry lock-in.** Database, message bus, auth provider, deployment target. Not every library — just the ones that would take a quarter to swap out.
-- **Boundary and scope decisions.** "Customer data is owned by the Customer context; other contexts reference it by ID only." The explicit no-s are as valuable as the yes-s.
-- **Deliberate deviations from the obvious path.** "We're using manual SQL instead of an ORM because X." Anything where a reasonable reader would assume the opposite. These stop the next engineer from "fixing" something that was deliberate.
-- **Constraints not visible in the code.** "We can't use AWS because of compliance requirements." "Response times must be under 200ms because of the partner API contract."
-- **Rejected alternatives when the rejection is non-obvious.** If you considered GraphQL and picked REST for subtle reasons, record it — otherwise someone will suggest GraphQL again in six months.
+# ADR Format
+
+ADRs live in `docs/adr/` and use sequential numbering: `0001-slug.md`, `0002-slug.md`, etc.
+
+Create the `docs/adr/` directory lazily — only when the first ADR is needed.
+
+## Template
+
+```md
+# {Short title of the decision}
+
+{1-3 sentences: what's the context, what did we decide, and why.}
+```
+
+That's it. An ADR can be a single paragraph. The value is in recording *that* a decision was made and *why* — not in filling out sections.
+
+## Optional sections
+
+Only include these when they add genuine value. Most ADRs won't need them.
+
+- **Status** frontmatter (`proposed | accepted | deprecated | superseded by ADR-NNNN`) — useful when decisions are revisited
+- **Considered Options** — only when the rejected alternatives are worth remembering
+- **Consequences** — only when non-obvious downstream effects need to be called out
+
+## Numbering
+
+Scan `docs/adr/` for the highest existing number and increment by one.
+
+## When to offer an ADR
+
+All three of these must be true:
+
+1. **Hard to reverse** — the cost of changing your mind later is meaningful
+2. **Surprising without context** — a future reader will look at the code and wonder "why on earth did they do it this way?"
+3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons
+
+If a decision is easy to reverse, skip it — you'll just reverse it. If it's not surprising, nobody will wonder why. If there was no real alternative, there's nothing to record beyond "we did the obvious thing."
+
+### What qualifies
+
+- **Architectural shape.** "We're using a monorepo." "The write model is event-sourced, the read model is projected into Postgres."
+- **Integration patterns between contexts.** "Ordering and Billing communicate via domain events, not synchronous HTTP."
+- **Technology choices that carry lock-in.** Database, message bus, auth provider, deployment target. Not every library — just the ones that would take a quarter to swap out.
+- **Boundary and scope decisions.** "Customer data is owned by the Customer context; other contexts reference it by ID only." The explicit no-s are as valuable as the yes-s.
+- **Deliberate deviations from the obvious path.** "We're using manual SQL instead of an ORM because X." Anything where a reasonable reader would assume the opposite. These stop the next engineer from "fixing" something that was deliberate.
+- **Constraints not visible in the code.** "We can't use AWS because of compliance requirements." "Response times must be under 200ms because of the partner API contract."
+- **Rejected alternatives when the rejection is non-obvious.** If you considered GraphQL and picked REST for subtle reasons, record it — otherwise someone will suggest GraphQL again in six months.