anchi-kit 1.1.2

package/.cursor/skills/skill-creator/scripts/quick_validate.py

@@ -0,0 +1,65 @@
+#!/usr/bin/env python3
+"""
+Quick validation script for skills - minimal version
+"""
+
+import sys
+import os
+import re
+from pathlib import Path
+
+def validate_skill(skill_path):
+    """Basic validation of a skill"""
+    skill_path = Path(skill_path)
+    
+    # Check SKILL.md exists
+    skill_md = skill_path / 'SKILL.md'
+    if not skill_md.exists():
+        return False, "SKILL.md not found"
+    
+    # Read and validate frontmatter
+    content = skill_md.read_text()
+    if not content.startswith('---'):
+        return False, "No YAML frontmatter found"
+    
+    # Extract frontmatter
+    match = re.match(r'^---\n(.*?)\n---', content, re.DOTALL)
+    if not match:
+        return False, "Invalid frontmatter format"
+    
+    frontmatter = match.group(1)
+    
+    # Check required fields
+    if 'name:' not in frontmatter:
+        return False, "Missing 'name' in frontmatter"
+    if 'description:' not in frontmatter:
+        return False, "Missing 'description' in frontmatter"
+    
+    # Extract name for validation
+    name_match = re.search(r'name:\s*(.+)', frontmatter)
+    if name_match:
+        name = name_match.group(1).strip()
+        # Check naming convention (hyphen-case: lowercase with hyphens)
+        if not re.match(r'^[a-z0-9-]+$', name):
+            return False, f"Name '{name}' should be hyphen-case (lowercase letters, digits, and hyphens only)"
+        if name.startswith('-') or name.endswith('-') or '--' in name:
+            return False, f"Name '{name}' cannot start/end with hyphen or contain consecutive hyphens"
+
+    # Extract and validate description
+    desc_match = re.search(r'description:\s*(.+)', frontmatter)
+    if desc_match:
+        description = desc_match.group(1).strip()
+        # Check for angle brackets
+        if '<' in description or '>' in description:
+            return False, "Description cannot contain angle brackets (< or >)"
+
+    return True, "Skill is valid!"
+
+if __name__ == "__main__":
+    if len(sys.argv) != 2:
+        print("Usage: python quick_validate.py <skill_directory>")
+        sys.exit(1)
+    
+    valid, message = validate_skill(sys.argv[1])
+    print(message)
+    sys.exit(0 if valid else 1)

package/.cursor/skills/software-architecture/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: software-architecture
+description: Clean Architecture, SOLID principles, and design patterns for building maintainable software. Use when designing system architecture, refactoring codebases, conducting code reviews, or implementing complex features that require architectural decisions.
+---
+
+# Software Architecture
+
+Comprehensive guide to software architecture principles, patterns, and best practices.
+
+## When to Use
+
+- Designing system architecture
+- Refactoring existing codebase
+- Code reviews focusing on architecture
+- Implementing complex features
+- Making architectural decisions
+- Solving scalability challenges
+
+## Core Principles
+
+### SOLID Principles
+
+See [references/solid-principles.md](references/solid-principles.md) for detailed explanations and examples.
+
+**Quick Reference:**
+
+- **S**ingle Responsibility - One class, one reason to change
+- **O**pen/Closed - Open for extension, closed for modification
+- **L**iskov Substitution - Subclasses should be substitutable
+- **I**nterface Segregation - Many specific interfaces over one general
+- **D**ependency Inversion - Depend on abstractions, not concretions
+
+### Clean Architecture
+
+See [references/clean-architecture.md](references/clean-architecture.md) for layer-by-layer guide.
+
+**Layers (outer to inner):**
+
+1. Frameworks & Drivers (UI, DB, External APIs)
+2. Interface Adapters (Controllers, Presenters, Gateways)
+3. Application Business Rules (Use Cases)
+4. Enterprise Business Rules (Entities)
+
+**Rule:** Dependencies point inward only
+
+## Common Design Patterns
+
+See [references/design-patterns.md](references/design-patterns.md) for full catalog.
+
+### Creational Patterns
+
+- Factory Pattern - Object creation
+- Builder Pattern - Complex object construction
+- Singleton Pattern - Single instance
+
+### Structural Patterns
+
+- Adapter Pattern - Interface compatibility
+- Decorator Pattern - Add behavior dynamically
+- Repository Pattern - Data access abstraction
+
+### Behavioral Patterns
+
+- Strategy Pattern - Interchangeable algorithms
+- Observer Pattern - Event notification
+- Command Pattern - Encapsulate requests
+
+## Architecture Best Practices
+
+1. **Separation of Concerns** - Each module has distinct responsibility
+2. **Dependency Injection** - Inject dependencies, don't create them
+3. **Interface Programming** - Code to interfaces, not implementations
+4. **Single Source of Truth** - One canonical source for each data type
+5. **Test-Driven Design** - Design for testability from the start
+6. **Incremental Refactoring** - Improve architecture continuously
+
+## Code Organization
+
+```
+src/
+├── domain/           # Business logic (entities, use cases)
+├── infrastructure/   # External concerns (DB, API clients)
+├── application/      # Application services
+└── presentation/     # UI, controllers, views
+```
+
+## References
+
+- [SOLID Principles](references/solid-principles.md) - Detailed examples
+- [Clean Architecture](references/clean-architecture.md) - Layer guide
+- [Design Patterns](references/design-patterns.md) - Pattern catalog

package/.cursor/skills/software-architecture/references/solid-principles.md

@@ -0,0 +1,293 @@
+# SOLID Principles
+
+## S - Single Responsibility Principle (SRP)
+
+**A class should have only one reason to change.**
+
+### ❌ Violation
+
+```javascript
+class User {
+  constructor(name, email) {
+    this.name = name;
+    this.email = email;
+  }
+
+  // Database logic - reason #1 to change
+  save() {
+    database.insert("users", this);
+  }
+
+  // Email logic - reason #2 to change
+  sendWelcomeEmail() {
+    emailService.send(this.email, "Welcome!");
+  }
+
+  // Validation - reason #3 to change
+  validate() {
+    return this.email.includes("@");
+  }
+}
+```
+
+### ✅ Solution
+
+```javascript
+class User {
+  constructor(name, email) {
+    this.name = name;
+    this.email = email;
+  }
+}
+
+class UserRepository {
+  save(user) {
+    database.insert("users", user);
+  }
+}
+
+class UserNotification {
+  sendWelcome(user) {
+    emailService.send(user.email, "Welcome!");
+  }
+}
+
+class UserValidator {
+  validate(user) {
+    return user.email.includes("@");
+  }
+}
+```
+
+## O - Open/Closed Principle (OCP)
+
+**Open for extension, closed for modification.**
+
+### ❌ Violation
+
+```javascript
+class PaymentProcessor {
+  process(payment) {
+    if (payment.type === "credit-card") {
+      // Process credit card
+    } else if (payment.type === "paypal") {
+      // Process PayPal
+    }
+    // Adding new payment type requires modifying this class
+  }
+}
+```
+
+### ✅ Solution
+
+```javascript
+class PaymentProcessor {
+  constructor(strategy) {
+    this.strategy = strategy;
+  }
+
+  process(payment) {
+    return this.strategy.process(payment);
+  }
+}
+
+class CreditCardStrategy {
+  process(payment) {
+    // Process credit card
+  }
+}
+
+class PayPalStrategy {
+  process(payment) {
+    // Process PayPal
+  }
+}
+
+// Usage - extend without modification
+const processor = new PaymentProcessor(new CreditCardStrategy());
+```
+
+## L - Liskov Substitution Principle (LSP)
+
+**Subclasses should be substitutable for their base classes.**
+
+### ❌ Violation
+
+```javascript
+class Rectangle {
+  setWidth(width) {
+    this.width = width;
+  }
+  setHeight(height) {
+    this.height = height;
+  }
+  getArea() {
+    return this.width * this.height;
+  }
+}
+
+class Square extends Rectangle {
+  setWidth(width) {
+    this.width = width;
+    this.height = width; // Breaks expectation
+  }
+  setHeight(height) {
+    this.width = height;
+    this.height = height;
+  }
+}
+```
+
+### ✅ Solution
+
+```javascript
+class Shape {
+  getArea() {
+    throw new Error("Must implement getArea");
+  }
+}
+
+class Rectangle extends Shape {
+  constructor(width, height) {
+    super();
+    this.width = width;
+    this.height = height;
+  }
+  getArea() {
+    return this.width * this.height;
+  }
+}
+
+class Square extends Shape {
+  constructor(side) {
+    super();
+    this.side = side;
+  }
+  getArea() {
+    return this.side * this.side;
+  }
+}
+```
+
+## I - Interface Segregation Principle (ISP)
+
+**Many specific interfaces are better than one general interface.**
+
+### ❌ Violation
+
+```javascript
+class Worker {
+  work() {}
+  eat() {}
+  sleep() {}
+}
+
+class Robot extends Worker {
+  work() {
+    /* OK */
+  }
+  eat() {
+    throw new Error("Robots don't eat");
+  }
+  sleep() {
+    throw new Error("Robots don't sleep");
+  }
+}
+```
+
+### ✅ Solution
+
+```javascript
+class Workable {
+  work() {}
+}
+
+class Eatable {
+  eat() {}
+}
+
+class Sleepable {
+  sleep() {}
+}
+
+class Human extends Workable {
+  work() {
+    /* ... */
+  }
+  eat() {
+    /* via Eatable */
+  }
+  sleep() {
+    /* via Sleepable */
+  }
+}
+
+class Robot extends Workable {
+  work() {
+    /* ... */
+  }
+  // Doesn't implement eat/sleep
+}
+```
+
+## D - Dependency Inversion Principle (DIP)
+
+**Depend on abstractions, not concretions.**
+
+### ❌ Violation
+
+```javascript
+class EmailService {
+  send(to, message) {
+    /* Send email */
+  }
+}
+
+class UserService {
+  constructor() {
+    this.emailService = new EmailService(); // Tight coupling
+  }
+
+  register(user) {
+    this.emailService.send(user.email, "Welcome");
+  }
+}
+```
+
+### ✅ Solution
+
+```javascript
+// Abstraction
+class NotificationService {
+  send(to, message) {
+    throw new Error("Must implement");
+  }
+}
+
+// Implementations
+class EmailService extends NotificationService {
+  send(to, message) {
+    /* Send email */
+  }
+}
+
+class SMSService extends NotificationService {
+  send(to, message) {
+    /* Send SMS */
+  }
+}
+
+// Depend on abstraction
+class UserService {
+  constructor(notificationService) {
+    this.notificationService = notificationService;
+  }
+
+  register(user) {
+    this.notificationService.send(user.email, "Welcome");
+  }
+}
+
+// Usage - easily swap implementations
+const userService = new UserService(new EmailService());
+```

package/.cursor/skills/subagent-driven-development/SKILL.md

@@ -0,0 +1,237 @@
+---
+name: subagent-driven-development
+description: Subagent-Driven Development (SADD) methodology for dispatching independent subagents to handle individual tasks with code review checkpoints between iterations. Enables rapid, controlled parallel development with quality gates.
+---
+
+# Subagent-Driven Development (SADD)
+
+Parallel development workflow using independent subagents with built-in quality checkpoints.
+
+## When to Use
+
+- Large features requiring multiple parallel workstreams
+- Complex systems with independent components
+- When development velocity is critical
+- Projects with clear component boundaries
+- Teams practicing modular architecture
+
+## Core Concept
+
+**Break → Dispatch → Review → Integrate**
+
+Instead of one agent doing everything sequentially, dispatch multiple specialized subagents to work in parallel, with mandatory code review checkpoints between iterations.
+
+## SADD Workflow
+
+### 1. Task Decomposition
+
+Break feature into independent, parallelizable tasks:
+
+```
+Feature: User Authentication System
+↓
+Subagents:
+1. Database schema + migration
+2. API endpoints + validation
+3. Frontend forms + state
+4. Email verification service
+5. Session management
+6. Security audit
+```
+
+**Key:** Each task must be completable independently
+
+### 2. Subagent Dispatch
+
+Create independent subagent for each task:
+
+```markdown
+## Subagent 1: Database Schema
+
+**Scope:** User table, indexes, migration scripts
+**Deliverables:**
+
+- migration files
+- model definitions
+- unit tests
+  **Dependencies:** None
+  **Checkpoint:** Schema review before proceeding
+```
+
+### 3. Code Review Checkpoints
+
+**MANDATORY** review before next iteration:
+
+```
+Iteration 1 (Implementation)
+  ↓
+CHECKPOINT (Code Review)
+  ↓
+Iteration 2 (Refinement)
+  ↓
+CHECKPOINT (Integration Review)
+  ↓
+Merge
+```
+
+**Checkpoint Criteria:**
+
+- Code quality standards met
+- Tests passing
+- Documentation complete
+- No architectural violations
+- Security reviewed
+
+### 4. Parallel Execution
+
+Multiple subagents work simultaneously:
+
+```
+t=0: Dispatch 6 subagents
+t=1: All working in parallel
+t=2: Checkpoints (reviews happen)
+t=3: Continue or iterate
+t=4: Integration phase
+```
+
+## Best Practices
+
+1. **Clear Boundaries** - Each subagent owns distinct scope
+2. **Explicit Dependencies** - Document what depends on what
+3. **Quality Gates** - Never skip checkpoints
+4. **Communication** - Subagents report status regularly
+5. **Integration Plan** - Know how pieces fit together
+
+## Subagent Task Template
+
+```markdown
+# Subagent: [Name]
+
+## Scope
+
+- [What this subagent is responsible for]
+
+## Deliverables
+
+- [ ] File 1
+- [ ] File 2
+- [ ] Tests
+- [ ] Documentation
+
+## Dependencies
+
+- Requires: [Other subagent outputs]
+- Provides: [What others need from this]
+
+## Checkpoint Criteria
+
+- [ ] Code quality: passed linting
+- [ ] Tests: 100% passing
+- [ ] Security: reviewed
+- [ ] Documentation: complete
+
+## Status
+
+- [ ] Planning
+- [ ] Implementation
+- [ ] Review
+- [ ] Complete
+```
+
+## Example: E-Commerce Feature
+
+**Feature:** Product Recommendations
+
+**Decomposition:**
+
+```
+Subagent A: Data Pipeline
+→ Fetch user behavior data
+→ Process purchase history
+→ Generate feature vectors
+
+Subagent B: ML Model
+→ Train recommendation model
+→ Test accuracy (>85%)
+→ Export model artifacts
+
+Subagent C: API Service
+→ REST endpoint /recommendations
+→ Model inference
+→ Response caching
+
+Subagent D: Frontend Component
+→ Recommendation widget
+→ Click tracking
+→ A/B test integration
+```
+
+**Parallel Timeline:**
+
+```
+Day 1: All 4 subagents start
+Day 2: Checkpoint reviews
+Day 3: Refinements
+Day 4: Integration testing
+Day 5: Production deploy
+```
+
+**Sequential would take:** ~10-15 days  
+**SADD approach:** ~5 days
+
+## Integration Strategy
+
+### Incremental Integration
+
+```
+1. Integrate A + B → Test
+2. Integrate C → Test
+3. Integrate D → Test
+4. Full system test
+```
+
+### Conflict Resolution
+
+When subagents conflict:
+
+1. **Identify:** Which boundary was violated?
+2. **Discuss:** Why did conflict happen?
+3. **Resolve:** Adjust boundaries or merge approach
+4. **Document:** Update task decomposition
+
+## Anti-Patterns
+
+❌ **Too Fine-Grained**
+
+- Don't create subagent for every single file
+- Minimum: 1 day of work per subagent
+
+❌ **Skipping Checkpoints**
+
+- Never merge without review
+- Quality gates are mandatory
+
+❌ **Unclear Dependencies**
+
+- Document all dependencies upfront
+- Update as discovered
+
+❌ **No Integration Plan**
+
+- Know how pieces fit together
+- Test integration frequently
+
+## References
+
+See [references/subagent-patterns.md](references/subagent-patterns.md) for:
+
+- Advanced decomposition strategies
+- Checkpoint review templates
+- Integration testing patterns
+- Communication protocols
+
+See [references/code-review-checkpoints.md](references/code-review-checkpoints.md) for:
+
+- Review criteria checklists
+- Quality gate definitions
+- Automated checkpoint validation