anchi-kit 1.2.1 → 1.2.2

package/.cursor/skills/problem-solving/references/meta-pattern-recognition.md

@@ -1,87 +0,0 @@
-# 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/.cursor/skills/problem-solving/references/scale-game.md

@@ -1,95 +0,0 @@
-# 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/.cursor/skills/problem-solving/references/simplification-cascades.md

@@ -1,80 +0,0 @@
-# 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/.cursor/skills/problem-solving/references/when-stuck.md

@@ -1,72 +0,0 @@
-# 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/.cursor/skills/prompt-engineering/references/anthropic-best-practices.md

@@ -1,160 +0,0 @@
-# Anthropic Best Practices
-
-## Claude-Specific Techniques
-
-### System Prompts
-
-Define Claude's role and behavior:
-
-```xml
-<system>
-You are a helpful coding assistant specializing in Python and web development.
-Always provide working code examples.
-Explain your reasoning before showing code.
-Follow PEP 8 style guidelines.
-</system>
-```
-
-### XML Tags for Structure
-
-Claude works well with XML-like tags:
-
-```xml
-<context>
-The user is building a Next.js e-commerce site
-</context>
-
-<task>
-Create a product listing component with:
-- Image display
-- Price formatting
-- Add to cart button
-</task>
-
-<constraints>
-- Must be TypeScript
-- Use Tailwind CSS
-- Follow accessibility standards
-</constraints>
-```
-
-### Tool Use Pattern
-
-```javascript
-const tools = [
-  {
-    name: "search_database",
-    description: "Search the product database",
-    input_schema: {
-      type: "object",
-      properties: {
-        query: { type: "string" },
-        limit: { type: "number" },
-      },
-    },
-  },
-];
-
-// Claude will format tool calls as:
-// <function_calls>
-// <invoke name="search_database">
-// <parameter name="query">laptops</parameter>
-// </invoke>
-// </function_calls>
-```
-
-## Multi-Turn Conversations
-
-### Maintaining Context
-
-```markdown
-User: "Create a User model"
-Claude: [Creates User model]
-
-User: "Now add email validation"
-Claude: [Updates User model with validation]
-
-User: "Make it work with PostgreSQL"
-Claude: [Adds database integration]
-```
-
-**Best Practices:**
-
-- Reference previous messages explicitly
-- Maintain consistent naming
-- Ask clarifying questions when context is unclear
-
-## Handling Edge Cases
-
-### Clarification Requests
-
-```markdown
-I notice you mentioned "authentication" but didn't specify:
-
-1. Which method? (JWT, sessions, OAuth)
-2. Password requirements?
-3. Multi-factor authentication needed?
-
-Could you clarify these points?
-```
-
-### Graceful Refusals
-
-If Claude refuses a request:
-
-- Rephrase with clearer intent
-- Provide more context
-- Break into smaller sub-tasks
-- Explain the legitimate use case
-
-## Optimizing Responses
-
-### Request Specific Format
-
-```markdown
-Provide the solution in this format:
-
-## Problem Analysis
-
-[Analysis here]
-
-## Solution
-
-[Code here]
-
-## Trade-offs
-
-[Pros/cons here]
-```
-
-### Control Verbosity
-
-```markdown
-Concise mode: Provide only code with brief comments
-Detailed mode: Include explanations and examples
-Minimal mode: Code only, no explanations
-```
-
-## Long Context Usage
-
-Claude has 200K context window - use it effectively:
-
-1. **Include relevant files** - Paste full file contents
-2. **Provide documentation** - Include API docs, specs
-3. **Give examples** - Show desired patterns
-4. **Maintain conversation** - Don't reset unnecessarily
-
-## Extended Thinking
-
-For complex problems, enable extended thinking:
-
-```markdown
-<thinking>
-Take your time to think through this problem step by step.
-Consider edge cases, performance, and maintainability.
-</thinking>
-
-[Problem description]
-```
-
-This encourages Claude to show detailed reasoning before answering.

package/.cursor/skills/repomix/references/configuration.md

@@ -1,211 +0,0 @@
-# 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
-```