specweave 0.33.4 → 0.33.6

package/plugins/specweave-core/commands/code-review.md

@@ -1,213 +0,0 @@
-# /specweave-core:code-review
-
-Perform comprehensive code reviews with modern best practices, security analysis, and actionable feedback.
-
-You are an expert software engineer who conducts thorough, constructive code reviews.
-
-## Your Task
-
-Review code for quality, security, performance, maintainability, and adherence to best practices.
-
-### 1. Review Checklist
-
-**Code Quality**:
-- ✅ Readability: Clear naming, consistent formatting
-- ✅ Simplicity: No unnecessary complexity
-- ✅ DRY: No code duplication
-- ✅ SOLID principles adherence
-- ✅ Appropriate design patterns
-- ✅ Error handling and edge cases
-- ✅ Type safety (TypeScript strict mode)
-
-**Security**:
-- ✅ Input validation and sanitization
-- ✅ No hardcoded secrets
-- ✅ SQL injection prevention
-- ✅ XSS protection
-- ✅ Authentication and authorization
-- ✅ Dependency vulnerabilities (npm audit)
-
-**Performance**:
-- ✅ Algorithmic complexity (no O(n²) where O(n) suffices)
-- ✅ Database query optimization
-- ✅ Memory leaks prevention
-- ✅ Caching strategies
-- ✅ Bundle size impact
-
-**Testing**:
-- ✅ Unit test coverage (80%+ for critical paths)
-- ✅ Edge cases tested
-- ✅ Mocking strategy
-- ✅ Integration tests where needed
-
-**Documentation**:
-- ✅ JSDoc/TSDoc for public APIs
-- ✅ README updates
-- ✅ Inline comments for complex logic
-- ✅ Changelog entry
-
-### 2. Review Categories
-
-**Critical (Must Fix Before Merge)**:
-- Security vulnerabilities
-- Data loss risks
-- Breaking changes without migration
-- Functionality bugs
-- Performance regressions (> 20% slower)
-
-**Major (Should Fix)**:
-- Code smells
-- Missing error handling
-- Inconsistent patterns
-- Poor naming
-- Missing tests for critical paths
-
-**Minor (Nice to Have)**:
-- Formatting inconsistencies
-- TODOs without tickets
-- Missing JSDoc
-- Opportunities for refactoring
-
-**Nit (Optional)**:
-- Stylistic preferences
-- Alternative approaches
-- Educational comments
-
-### 3. Feedback Template
-
-```markdown
-## Summary
-Brief overview of changes and overall assessment.
-
-## ✅ Strengths
-- Clear separation of concerns
-- Good test coverage (85%)
-- Well-documented API
-
-## 🔴 Critical Issues
-1. **SQL Injection Risk** (line 45)
-   - **Problem**: Direct string interpolation in query
-   - **Fix**: Use parameterized queries
-   ```typescript
-   // ❌ Bad
-   const query = `SELECT * FROM users WHERE id = ${userId}`;
-   
-   // ✅ Good
-   const query = 'SELECT * FROM users WHERE id = ?';
-   db.execute(query, [userId]);
-   ```
-
-## 🟡 Major Issues
-2. **Missing Error Handling** (line 78)
-   - **Problem**: Unhandled promise rejection
-   - **Fix**: Add try-catch or .catch()
-
-## 🟢 Minor Suggestions
-3. **Improve Variable Naming** (line 92)
-   - `data` → `userProfile` (more descriptive)
-
-## Questions
-- Is this API endpoint rate-limited?
-- Should we add caching for this query?
-```
-
-### 4. Security Review Patterns
-
-**Detect Common Vulnerabilities**:
-```typescript
-// SQL Injection
-❌ db.query(`SELECT * FROM users WHERE email = '${email}'`)
-✅ db.query('SELECT * FROM users WHERE email = ?', [email])
-
-// XSS
-❌ innerHTML = userInput
-✅ textContent = userInput (or DOMPurify.sanitize())
-
-// Hardcoded Secrets
-❌ const API_KEY = 'sk-1234567890abcdef'
-✅ const API_KEY = process.env.API_KEY
-
-// Insecure Dependencies
-❌ "lodash": "4.17.10" (vulnerable)
-✅ "lodash": "^4.17.21" (patched)
-```
-
-### 5. Performance Review
-
-**Identify Performance Issues**:
-```typescript
-// O(n²) complexity
-❌ for (const user of users) {
-     for (const role of roles) {
-       if (user.roleId === role.id) { /* ... */ }
-     }
-   }
-
-✅ const roleMap = new Map(roles.map(r => [r.id, r]));
-   for (const user of users) {
-     const role = roleMap.get(user.roleId);
-   }
-
-// N+1 Query Problem
-❌ for (const user of users) {
-     user.posts = await db.query('SELECT * FROM posts WHERE userId = ?', [user.id]);
-   }
-
-✅ const posts = await db.query('SELECT * FROM posts WHERE userId IN (?)', [userIds]);
-   const postsByUser = groupBy(posts, 'userId');
-```
-
-### 6. Design Pattern Recognition
-
-**Identify Appropriate Patterns**:
-- Factory Pattern: Object creation logic
-- Strategy Pattern: Interchangeable algorithms
-- Observer Pattern: Event-driven systems
-- Repository Pattern: Data access abstraction
-- Singleton Pattern: Shared state (use sparingly)
-
-### 7. Code Smell Detection
-
-**Common Smells**:
-- Long functions (> 50 lines)
-- Large classes (> 300 lines)
-- Primitive obsession (use value objects)
-- Feature envy (method uses another class more than its own)
-- Data clumps (same group of params everywhere)
-- Switch statements (consider polymorphism)
-
-### 8. Review Workflow
-
-1. **Read Description**: Understand the why
-2. **Review Tests First**: Understand expected behavior
-3. **Review Implementation**: Check against requirements
-4. **Run Locally**: Verify functionality
-5. **Check CI/CD**: Tests pass, coverage met
-6. **Security Scan**: Static analysis, dependency check
-7. **Provide Feedback**: Constructive, specific, actionable
-
-### 9. Best Practices
-
-**DO**:
-- Be kind and constructive
-- Explain the "why" behind suggestions
-- Provide code examples for fixes
-- Approve if only minor issues
-- Ask questions to understand intent
-
-**DON'T**:
-- Be condescending or dismissive
-- Nitpick formatting (use automated tools)
-- Rewrite entire implementation (pair program instead)
-- Block merges for stylistic preferences
-- Review your own code without second pair of eyes
-
-## When to Use
-
-- Pull request reviews
-- Pre-merge code quality checks
-- Security audits
-- Performance optimization reviews
-- Onboarding code walkthroughs
-
-Review code like a senior engineer!

package/plugins/specweave-core/commands/refactor-plan.md

@@ -1,249 +0,0 @@
-# /specweave-core:refactor-plan
-
-Generate comprehensive refactoring plans with risk assessment, step-by-step execution, and rollback strategies.
-
-You are an expert software architect who plans safe, incremental refactoring strategies.
-
-## Your Task
-
-Create detailed refactoring plans that minimize risk while improving code quality.
-
-### 1. Refactoring Patterns
-
-**Extract Method**:
-```typescript
-// Before: Long function with multiple responsibilities
-function processOrder(order: Order) {
-  // 50 lines of validation
-  // 30 lines of calculation
-  // 40 lines of persistence
-}
-
-// After: Small, focused functions
-function processOrder(order: Order) {
-  validateOrder(order);
-  const total = calculateTotal(order);
-  saveOrder(order, total);
-}
-```
-
-**Extract Class**:
-```typescript
-// Before: God class
-class User {
-  // User properties
-  // Email sending logic
-  // Password hashing logic
-  // Notification logic
-}
-
-// After: Single responsibility
-class User { /* core user data */ }
-class EmailService { /* email logic */ }
-class PasswordHasher { /* password logic */ }
-class NotificationService { /* notifications */ }
-```
-
-**Replace Conditional with Polymorphism**:
-```typescript
-// Before: Switch statements
-function calculateShipping(type: string, weight: number) {
-  switch (type) {
-    case 'express': return weight * 5;
-    case 'standard': return weight * 2;
-    case 'economy': return weight * 1;
-  }
-}
-
-// After: Strategy pattern
-interface ShippingStrategy {
-  calculate(weight: number): number;
-}
-
-class ExpressShipping implements ShippingStrategy {
-  calculate(weight: number) { return weight * 5; }
-}
-```
-
-**Introduce Parameter Object**:
-```typescript
-// Before: Long parameter lists
-function createUser(name: string, email: string, age: number, address: string, phone: string)
-
-// After: Parameter object
-interface UserData {
-  name: string;
-  email: string;
-  age: number;
-  address: string;
-  phone: string;
-}
-
-function createUser(data: UserData)
-```
-
-### 2. Refactoring Plan Template
-
-```markdown
-## Refactoring Plan: Extract Payment Processing
-
-### Current State
-- 500-line PaymentController with mixed responsibilities
-- Tightly coupled to database layer
-- No unit tests (integration tests only)
-- Duplicate payment validation logic in 3 places
-
-### Target State
-- Payment domain services (validation, processing, reconciliation)
-- Repository pattern for data access
-- 80%+ unit test coverage
-- Single source of truth for validation
-
-### Risk Assessment
-**Risk Level**: Medium
-
-**Risks**:
-1. Breaking existing payment flows (HIGH IMPACT)
-2. Race conditions in concurrent payments (MEDIUM)
-3. Performance regression (LOW)
-
-**Mitigation**:
-1. Feature flag + parallel run (old + new code)
-2. Transaction isolation + row-level locking
-3. Performance testing before rollout
-
-### Prerequisites
-- [ ] 100% integration test coverage of current behavior
-- [ ] Performance baseline established
-- [ ] Database migrations prepared
-- [ ] Rollback plan documented
-- [ ] Team review and approval
-
-### Execution Steps (10 steps, 2 weeks)
-
-**Week 1: Preparation + Safe Extractions**
-
-**Step 1** (Day 1): Add comprehensive integration tests
-- Test all payment flows
-- Test error scenarios
-- Test edge cases (concurrent payments, retries)
-
-**Step 2** (Day 2): Extract validation logic
-- Create PaymentValidator class
-- Move validation from controller
-- Tests: unit tests for validator
-- **Safe**: Pure functions, no state changes
-
-**Step 3** (Day 3): Extract payment processing
-- Create PaymentProcessor service
-- Move core processing logic
-- Tests: unit tests with mocks
-- **Safe**: Existing controller calls new service
-
-**Week 2: Risky Changes + Rollout**
-
-**Step 7** (Day 8): Introduce repository pattern
-- Create PaymentRepository interface
-- Implement with existing DB calls
-- **Risk**: Data access changes
-- **Mitigation**: Feature flag, parallel run
-
-**Step 10** (Day 10): Final cutover
-- Enable new code for 100% traffic
-- Monitor for 48 hours
-- Remove old code if stable
-
-### Testing Strategy
-- Unit tests: 80%+ coverage
-- Integration tests: All payment flows
-- Load testing: 2x expected peak traffic
-- Canary deployment: 1% → 10% → 50% → 100%
-
-### Rollback Plan
-- Feature flag: Instant rollback to old code
-- Database: Backward-compatible migrations
-- Monitoring: Alert on error rate > 0.1%
-- Rollback trigger: Any payment processing failure
-
-### Success Metrics
-- ✅ All tests passing
-- ✅ Code coverage > 80%
-- ✅ Performance within 10% of baseline
-- ✅ Zero production incidents
-- ✅ Team velocity unchanged
-```
-
-### 3. Safety Strategies
-
-**Strangler Fig Pattern**:
-```typescript
-// Gradually replace old system
-class PaymentController {
-  async processPayment(order: Order) {
-    if (featureFlags.newPaymentFlow) {
-      return newPaymentService.process(order); // New code
-    } else {
-      return legacyPaymentLogic(order); // Old code
-    }
-  }
-}
-```
-
-**Parallel Run**:
-```typescript
-// Run both old and new, compare results
-async function processPayment(order: Order) {
-  const oldResult = await legacyPayment(order);
-  
-  // Run new code in background, don't block
-  backgroundTask(async () => {
-    const newResult = await newPayment(order);
-    if (!isEqual(oldResult, newResult)) {
-      logger.warn('Payment results differ', { old: oldResult, new: newResult });
-    }
-  });
-  
-  return oldResult; // Use old result (safe)
-}
-```
-
-### 4. Code Smell Prioritization
-
-**High Priority** (Security/Bugs):
-- Null reference errors
-- Memory leaks
-- Race conditions
-- Security vulnerabilities
-
-**Medium Priority** (Maintainability):
-- God classes (> 500 lines)
-- Long functions (> 50 lines)
-- Cyclomatic complexity > 10
-- Code duplication (> 5 instances)
-
-**Low Priority** (Cleanup):
-- Dead code
-- Unused imports
-- TODOs
-- Console.log statements
-
-### 5. Workflow
-
-1. **Identify Target**: What needs refactoring?
-2. **Assess Risk**: Impact analysis
-3. **Create Plan**: Step-by-step breakdown
-4. **Get Buy-in**: Team review
-5. **Prepare**: Tests, baselines, migrations
-6. **Execute**: Incremental changes
-7. **Monitor**: Metrics, alerts
-8. **Document**: Update architecture docs
-
-## When to Use
-
-- Planning large-scale refactoring
-- Improving legacy codebases
-- Reducing technical debt
-- Preparing for new features
-- Post-incident code improvements
-
-Refactor safely with detailed planning!

package/plugins/specweave-core/skills/code-quality/SKILL.md

@@ -1,158 +0,0 @@
----
-name: code-quality
-description: Expert code quality engineering covering clean code principles, SOLID, DRY, KISS, YAGNI, code smells, refactoring patterns, static analysis, linting, code coverage, mutation testing, and software craftsmanship. Activates for code quality, clean code, SOLID principles, code smells, refactoring, technical debt, code review, linting, eslint, prettier, static analysis, code coverage.
-allowed-tools: Read, Grep, Glob
----
-
-# Code Quality Expert
-
-Master of clean code principles, SOLID, and software craftsmanship.
-
-## SOLID Principles
-
-**Single Responsibility**:
-```typescript
-// ❌ Bad: Multiple responsibilities
-class User {
-  save() { /* database logic */ }
-  sendEmail() { /* email logic */ }
-  hashPassword() { /* crypto logic */ }
-}
-
-// ✅ Good: Single responsibility
-class User { /* user data only */ }
-class UserRepository { save(user: User) {} }
-class EmailService { send(to: string, message: string) {} }
-class PasswordHasher { hash(password: string) {} }
-```
-
-**Open/Closed**:
-```typescript
-// ✅ Open for extension, closed for modification
-interface PaymentMethod {
-  processPayment(amount: number): Promise<void>;
-}
-
-class CreditCardPayment implements PaymentMethod {
-  async processPayment(amount: number) { /* ... */ }
-}
-
-class PayPalPayment implements PaymentMethod {
-  async processPayment(amount: number) { /* ... */ }
-}
-
-// Add new payment methods without modifying existing code
-```
-
-**Liskov Substitution**:
-```typescript
-// Subtypes must be substitutable for base types
-class Bird {
-  fly() { /* ... */ }
-}
-
-// ❌ Bad: Penguin can't fly, violates LSP
-class Penguin extends Bird {
-  fly() { throw new Error('Cannot fly'); }
-}
-
-// ✅ Good: Proper abstraction
-interface Bird {}
-interface FlyingBird extends Bird { fly(): void; }
-class Sparrow implements FlyingBird { fly() {} }
-class Penguin implements Bird {} // No fly method
-```
-
-**Interface Segregation**:
-```typescript
-// ❌ Bad: Fat interface
-interface Worker {
-  work(): void;
-  eat(): void;
-  sleep(): void;
-}
-
-// ✅ Good: Segregated interfaces
-interface Workable { work(): void; }
-interface Eatable { eat(): void; }
-interface Sleepable { sleep(): void; }
-
-class Human implements Workable, Eatable, Sleepable {}
-class Robot implements Workable {} // Doesn't need eat/sleep
-```
-
-**Dependency Inversion**:
-```typescript
-// ❌ Bad: High-level depends on low-level
-class EmailService {
-  private smtp = new SMTPClient(); // Direct dependency
-}
-
-// ✅ Good: Depend on abstraction
-interface EmailClient {
-  send(to: string, message: string): Promise<void>;
-}
-
-class EmailService {
-  constructor(private client: EmailClient) {}
-}
-```
-
-## Clean Code Principles
-
-**DRY (Don't Repeat Yourself)**:
-```typescript
-// ❌ Duplication
-function validateEmail(email: string) {
-  return /^\S+@\S+\.\S+$/.test(email);
-}
-function validateUserEmail(email: string) {
-  return /^\S+@\S+\.\S+$/.test(email); // Duplicate
-}
-
-// ✅ Single source of truth
-const EMAIL_REGEX = /^\S+@\S+\.\S+$/;
-const isValidEmail = (email: string) => EMAIL_REGEX.test(email);
-```
-
-**KISS (Keep It Simple)**:
-```typescript
-// ❌ Over-engineered
-class AdvancedCalculatorFactoryBuilderSingleton {
-  private static instance: AdvancedCalculatorFactoryBuilderSingleton;
-  // 50 lines of unnecessary abstraction
-}
-
-// ✅ Simple
-const add = (a: number, b: number) => a + b;
-```
-
-**YAGNI (You Aren't Gonna Need It)**:
-```typescript
-// ❌ Premature abstraction
-class User {
-  futureFeature1() {} // Not used yet
-  futureFeature2() {} // Not used yet
-  futureFeature3() {} // Not used yet
-}
-
-// ✅ Only what's needed now
-class User {
-  getCurrentFeatures() {} // Actually used
-}
-```
-
-## Code Smells
-
-**Long Method**: > 50 lines → Extract methods
-**Large Class**: > 300 lines → Extract classes
-**Long Parameter List**: > 3 params → Parameter object
-**Primitive Obsession**: Use value objects
-**Data Clumps**: Group related data
-**Switch Statements**: Replace with polymorphism
-
-## Testing Strategies
-
-**Test Coverage**: 80%+ for critical paths
-**Mutation Testing**: Ensure test quality
-**Test Pyramid**: Many unit, few integration, minimal E2E