kiro-kit 0.1.3 → 0.2.0

package/dist/presets/fullstack/skills/problem-solving/references/meta-pattern-recognition.md

@@ -0,0 +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

package/dist/presets/fullstack/skills/problem-solving/references/scale-game.md

@@ -0,0 +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

package/dist/presets/fullstack/skills/problem-solving/references/simplification-cascades.md

@@ -0,0 +1,80 @@
+# Simplification Cascades
+
+Find one insight eliminating multiple components. "If this is true, we don't need X, Y, Z."
+
+## Core Principle
+
+**Everything is a special case of...** collapses complexity dramatically.
+
+One powerful abstraction > ten clever hacks.
+
+## When to Use
+
+| Symptom | Action |
+|---------|--------|
+| Same thing implemented 5+ ways | Abstract the common pattern |
+| Growing special case list | Find the general case |
+| Complex rules with exceptions | Find rule with no exceptions |
+| Excessive config options | Find defaults working 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
+
+### Example 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
+
+### Example 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
+
+### Example 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 variations** - What's implemented multiple ways?
+2. **Find essence** - What's the same underneath?
+3. **Extract abstraction** - What's the domain-independent pattern?
+4. **Test fit** - Do all cases fit cleanly?
+5. **Measure cascade** - How many things become unnecessary?
+
+## Red Flags
+
+Signs you're missing a cascade:
+- "Just need to add one more case..." (repeating forever)
+- "These are 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)
+
+## Success Metrics
+
+- **10x wins, not 10% improvements**
+- Measure in "how many things can we delete?"
+- Lines of code removed > lines added
+- Configuration options eliminated
+- Special cases unified
+
+## Remember
+
+- The pattern is usually already there, just needs recognition
+- Valid cascades feel obvious in retrospect
+- Test with "can this handle all existing cases?"
+- Document the insight for future reference

package/dist/presets/fullstack/skills/problem-solving/references/when-stuck.md

@@ -0,0 +1,72 @@
+# When Stuck - Problem-Solving Dispatch
+
+Different stuck-types need different techniques. Match stuck-symptom to technique.
+
+## Dispatch Flowchart
+
+```
+YOU'RE STUCK
+│
+├─ Complexity spiraling? Same thing 5+ ways? Growing special cases?
+│  └─→ USE: Simplification Cascades
+│
+├─ Can't find fitting approach? Conventional solutions inadequate?
+│  └─→ USE: Collision-Zone Thinking
+│
+├─ Same issue different places? Reinventing wheels? Feels familiar?
+│  └─→ USE: Meta-Pattern Recognition
+│
+├─ Solution feels forced? "Must be done this way"? Stuck on assumptions?
+│  └─→ USE: Inversion Exercise
+│
+├─ Will this work at production? Edge cases unclear? Unsure of limits?
+│  └─→ USE: Scale Game
+│
+└─ Code broken? Wrong behavior? Test failing?
+   └─→ USE: Debugging skill (systematic-debugging)
+```
+
+## Stuck-Type → Technique Map
+
+| How You're Stuck | Symptom Details | Use This |
+|------------------|-----------------|----------|
+| **Complexity spiraling** | Same thing 5+ ways, growing special cases, excessive if/else | simplification-cascades.md |
+| **Need innovation** | Conventional inadequate, can't find fitting approach, need breakthrough | collision-zone-thinking.md |
+| **Recurring patterns** | Same issue different places, reinventing wheels, déjà vu feeling | meta-pattern-recognition.md |
+| **Forced by assumptions** | "Must be done this way", can't question premise, forced solution | inversion-exercise.md |
+| **Scale uncertainty** | Production unclear, edge cases unknown, unsure of limits | scale-game.md |
+| **Code broken** | Wrong behavior, test failing, unexpected output | debugging skill |
+
+## Process
+
+1. **Identify stuck-type** - What symptom matches above?
+2. **Load that technique** - Read the specific reference file
+3. **Apply technique** - Follow its process
+4. **Document attempt** - What worked/failed?
+5. **If still stuck** - Try different technique or combine
+
+## Combining Techniques
+
+Some problems need multiple techniques:
+
+- **Simplification + Meta-pattern** - Find pattern → simplify all instances
+- **Collision + Inversion** - Force metaphor → invert assumptions
+- **Scale + Simplification** - Test extremes → reveal what to eliminate
+- **Meta-pattern + Scale** - Universal pattern → test at extremes
+
+## When Nothing Works
+
+If no technique helps:
+1. **Reframe problem** - Are you solving the right problem?
+2. **Get fresh perspective** - Explain to someone else
+3. **Take break** - Distance often reveals solution
+4. **Simplify scope** - Solve smaller version first
+5. **Question constraints** - Are they real or assumed?
+
+## Remember
+
+- Match symptom to technique
+- One technique at a time
+- Combine if first doesn't work
+- Document what you tried
+- Not stuck forever, just temporarily

package/dist/presets/fullstack/skills/repomix/references/configuration.md

@@ -0,0 +1,211 @@
+# Configuration Reference
+
+Detailed configuration options for Repomix.
+
+## Configuration File
+
+Create `repomix.config.json` in project root:
+
+```json
+{
+  "output": {
+    "filePath": "repomix-output.xml",
+    "style": "xml",
+    "removeComments": false,
+    "showLineNumbers": true,
+    "copyToClipboard": false
+  },
+  "include": ["**/*"],
+  "ignore": {
+    "useGitignore": true,
+    "useDefaultPatterns": true,
+    "customPatterns": ["additional-folder", "**/*.log", "**/tmp/**"]
+  },
+  "security": {
+    "enableSecurityCheck": true
+  }
+}
+```
+
+### Output Options
+
+- `filePath`: Output file path (default: `repomix-output.xml`)
+- `style`: Format - `xml`, `markdown`, `json`, `plain` (default: `xml`)
+- `removeComments`: Strip comments (default: `false`). Supports HTML, CSS, JS/TS, Vue, Svelte, Python, PHP, Ruby, C, C#, Java, Go, Rust, Swift, Kotlin, Dart, Shell, YAML
+- `showLineNumbers`: Include line numbers (default: `true`)
+- `copyToClipboard`: Auto-copy output (default: `false`)
+
+### Include/Ignore
+
+- `include`: Glob patterns for files to include (default: `["**/*"]`)
+- `useGitignore`: Respect .gitignore (default: `true`)
+- `useDefaultPatterns`: Use default ignore patterns (default: `true`)
+- `customPatterns`: Additional ignore patterns (same format as .gitignore)
+
+### Security
+
+- `enableSecurityCheck`: Scan for sensitive data with Secretlint (default: `true`)
+- Detects: API keys, passwords, credentials, private keys, AWS secrets, DB connections
+
+## Glob Patterns
+
+**Wildcards:**
+- `*` - Any chars except `/`
+- `**` - Any chars including `/`
+- `?` - Single char
+- `[abc]` - Char from set
+- `{js,ts}` - Either extension
+
+**Examples:**
+- `**/*.ts` - All TypeScript
+- `src/**` - Specific dir
+- `**/*.{js,jsx,ts,tsx}` - Multiple extensions
+- `!**/*.test.ts` - Exclude tests
+
+### CLI Options
+
+```bash
+# Include patterns
+repomix --include "src/**/*.ts,*.md"
+
+# Ignore patterns
+repomix -i "tests/**,*.test.js"
+
+# Disable .gitignore
+repomix --no-gitignore
+
+# Disable defaults
+repomix --no-default-patterns
+```
+
+### .repomixignore File
+
+Create `.repomixignore` for Repomix-specific patterns (same format as .gitignore):
+
+```
+# Build artifacts
+dist/
+build/
+*.min.js
+out/
+
+# Test files
+**/*.test.ts
+**/*.spec.ts
+coverage/
+__tests__/
+
+# Dependencies
+node_modules/
+vendor/
+packages/*/node_modules/
+
+# Large files
+*.mp4
+*.zip
+*.tar.gz
+*.iso
+
+# Sensitive files
+.env*
+secrets/
+*.key
+*.pem
+
+# IDE files
+.vscode/
+.idea/
+*.swp
+
+# Logs
+logs/
+**/*.log
+```
+
+### Pattern Precedence
+
+Order (highest to lowest priority):
+1. CLI ignore patterns (`-i`)
+2. `.repomixignore` file
+3. Custom patterns in config
+4. `.gitignore` (if enabled)
+5. Default patterns (if enabled)
+
+### Pattern Examples
+
+**TypeScript:**
+```json
+{"include": ["**/*.ts", "**/*.tsx"], "ignore": {"customPatterns": ["**/*.test.ts", "dist/"]}}
+```
+
+**React:**
+```json
+{"include": ["src/**/*.{js,jsx,ts,tsx}", "*.md"], "ignore": {"customPatterns": ["build/"]}}
+```
+
+**Monorepo:**
+```json
+{"include": ["packages/*/src/**"], "ignore": {"customPatterns": ["packages/*/dist/"]}}
+```
+
+## Output Formats
+
+### XML (Default)
+```bash
+repomix --style xml
+```
+Structured AI consumption. Features: tags, hierarchy, metadata, AI-optimized separators.
+Use for: LLMs, structured analysis, programmatic parsing.
+
+### Markdown
+```bash
+repomix --style markdown
+```
+Human-readable with syntax highlighting. Features: syntax highlighting, headers, TOC.
+Use for: documentation, code review, sharing.
+
+### JSON
+```bash
+repomix --style json
+```
+Programmatic processing. Features: structured data, easy parsing, metadata.
+Use for: API integration, custom tooling, data analysis.
+
+### Plain Text
+```bash
+repomix --style plain
+```
+Simple concatenation. Features: no formatting, minimal overhead.
+Use for: simple analysis, minimal processing.
+
+## Advanced Options
+
+```bash
+# Verbose - show processing details
+repomix --verbose
+
+# Custom config file
+repomix -c /path/to/custom-config.json
+
+# Initialize config
+repomix --init
+
+# Disable line numbers - smaller output
+repomix --no-line-numbers
+```
+
+### Performance
+
+**Worker Threads:** Parallel processing handles large codebases efficiently (e.g., facebook/react: 29x faster, 123s → 4s)
+
+**Optimization:**
+```bash
+# Exclude unnecessary files
+repomix -i "node_modules/**,dist/**,*.min.js"
+
+# Specific directories only
+repomix --include "src/**/*.ts"
+
+# Remove comments, disable line numbers
+repomix --remove-comments --no-line-numbers
+```