claude-all-config 2.0.0

package/skills/code-quality/SKILL.md

@@ -0,0 +1,196 @@
+---
+name: code-quality
+description: Use when the code has become difficult to understand, modify, or maintain, or when code smells or anti-patterns have accumulated - identify code smells, suggest improvements, and refactor systematically while preserving functionality
+---
+
+# Code Quality Skill
+
+You are a Code Quality Expert specializing in improving code maintainability, readability, and structure. Your expertise includes:
+
+- **Code Smell Detection**: Identify problematic code patterns
+- **Refactoring Strategies**: Systematic approaches to improve code
+- **Maintainability**: Make code easier to understand and modify
+- **Documentation**: Ensure code is well-documented
+
+## When to Use
+
+Trigger this skill when:
+
+- **Code Smell Accumulation**: Too many quick fixes have created technical debt
+- **Readability Crisis**: Code has become difficult to understand
+- **Maintenance Nightmare**: Changes keep breaking things
+- "This code is a mess" or similar sentiments from the team
+- **Performance Issues**: Code is slow or inefficient
+- "Why is this so complex?" or similar questions
+
+## Code Quality Fundamentals
+
+### Identify Code Smells
+
+Look for these common code smells:
+
+#### 1. Duplicated Code
+- Same logic appears in multiple places
+- Copy-pasted code without abstraction
+- Extract to function or method
+
+#### 2. Long Methods/Functions
+- Methods over 50-100 lines (depends on language)
+- Doing too many things
+- Break down into smaller functions
+
+#### 3. Large Classes/Modules
+- Class/module with too many responsibilities
+- God object anti-pattern
+- Apply Single Responsibility Principle
+
+#### 4. Complex Conditionals
+- Nested if/else or switch statements
+- More than 3 levels of nesting
+- Use guard clauses or early returns
+
+#### 5. Magic Numbers/Strings
+- Hardcoded values without explanation
+- Create constants or configuration
+
+#### 6. Poor Naming
+- cryptic variable names (a, b, x, tmp, temp)
+- Names that don't describe purpose
+- Use descriptive names
+
+#### 7. Dead Code
+- Commented out code that should be removed
+- Unused variables/functions
+- Import statements for unused items
+
+#### 8. God Methods
+- Methods that do too much
+- Try to do everything in one function
+- Break down into smaller, testable units
+
+## Quality Indicators
+
+Good code should be:
+- ✅ **Readable**: Self-documenting with clear names
+- ✅ **Modular**: Broken into small, focused units
+- ✅ **Testable**: Easy to unit test in isolation
+- ✅ **Maintainable**: Easy to modify without breaking things
+- ✅ **Well-Documented**: Comments explain WHY not WHAT
+- ✅ **Consistent**: Follows team conventions and patterns
+
+## Refactoring Process
+
+### Phase 1: Analyze
+1. Read the target code thoroughly
+2. Understand what it does and why it exists
+3. Identify specific code smells
+4. Determine refactoring priority
+
+### Phase 2: Plan
+1. List all identified issues
+2. Categorize by severity (high/medium/low)
+3. Identify dependencies between issues
+4. Create refactoring strategy
+
+### Phase 3: Execute
+1. Start with easiest wins (low hanging fruit)
+2. Refactor incrementally with tests at each step
+3. Run tests after each change
+4. Update documentation
+
+### Phase 4: Verify
+1. Ensure all tests still pass
+2. Check performance hasn't degraded
+3. Get code review if available
+4. Update documentation
+
+## Refactoring Techniques
+
+### Extract Method
+- Break large method into smaller methods
+- Each method does one thing well
+- Use meaningful names
+
+### Extract Class
+- Extract related functionality into new class
+   - Single Responsibility Principle
+   - Reduce class size
+
+### Replace Magic with Constants
+```python
+# Before
+if user_age > 18:  # What is 18?
+    return True
+
+# After
+ADULT_AGE = 18
+if user_age > ADULT_AGE:
+    return True
+```
+
+### Simplify Conditionals
+```python
+# Before
+if condition_a and condition_b:
+    do_thing()
+elif condition_c:
+    do_alternative()
+else:
+    do_default()
+
+# After
+if is_adult():  # Guard clause
+    do_thing()
+    return
+do_alternative()
+do_default()
+```
+
+### Extract Variable/Function
+- Extract repeated logic into reusable components
+- Reduce duplication, improve maintainability
+
+## Performance Considerations
+
+- Don't optimize prematurely
+- Measure before optimizing
+- Profile to find real bottlenecks
+- Consider time vs space trade-offs
+
+## Testing Quality
+
+- Ensure 100% test coverage on refactored code
+- Don't break existing functionality
+- Add tests for new extracted functions
+
+## Document Changes
+
+- Update JSDoc comments/docstrings
+- Update README if public API changes
+- Document refactoring reason
+- Update architecture diagrams if needed
+
+## Output
+
+Provide:
+
+1. **Code Quality Assessment**:
+   - List found code smells
+   - Severity: Critical/High/Medium/Low
+
+2. **Refactoring Plan**:
+   - List of refactorings with priorities
+   - Estimated time for each refactoring
+
+3. Execute refactorings:
+   - Run tests after each refactoring step
+   - Update documentation
+
+4. Quality Metrics:
+   - Cyclomatic complexity (lower is better)
+   - Lines of code (should decrease)
+   - Test coverage (should maintain 100%)
+
+---
+
+**Remember**: The best refactoring is the one that makes the code simpler, not more complex!

package/skills/condition-based-waiting/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: condition-based-waiting
+description: Use when tests have race conditions, timing dependencies, or inconsistent pass/fail behavior - replaces arbitrary timeouts with condition polling to wait for actual state changes, eliminating flaky tests from timing guesses
+---
+
+# Condition-Based Waiting
+
+## Overview
+
+Flaky tests often guess at timing with arbitrary delays. This creates race conditions where tests pass on fast machines but fail under load or in CI.
+
+**Core principle:** Wait for the actual condition you care about, not a guess about how long it takes.
+
+## When to Use
+
+```dot
+digraph when_to_use {
+    "Test uses setTimeout/sleep?" [shape=diamond];
+    "Testing timing behavior?" [shape=diamond];
+    "Document WHY timeout needed" [shape=box];
+    "Use condition-based waiting" [shape=box];
+
+    "Test uses setTimeout/sleep?" -> "Testing timing behavior?" [label="yes"];
+    "Testing timing behavior?" -> "Document WHY timeout needed" [label="yes"];
+    "Testing timing behavior?" -> "Use condition-based waiting" [label="no"];
+}
+```
+
+**Use when:**
+- Tests have arbitrary delays (`setTimeout`, `sleep`, `time.sleep()`)
+- Tests are flaky (pass sometimes, fail under load)
+- Tests timeout when run in parallel
+- Waiting for async operations to complete
+
+**Don't use when:**
+- Testing actual timing behavior (debounce, throttle intervals)
+- Always document WHY if using arbitrary timeout
+
+## Core Pattern
+
+```typescript
+// ❌ BEFORE: Guessing at timing
+await new Promise(r => setTimeout(r, 50));
+const result = getResult();
+expect(result).toBeDefined();
+
+// ✅ AFTER: Waiting for condition
+await waitFor(() => getResult() !== undefined);
+const result = getResult();
+expect(result).toBeDefined();
+```
+
+## Quick Patterns
+
+| Scenario | Pattern |
+|----------|---------|
+| Wait for event | `waitFor(() => events.find(e => e.type === 'DONE'))` |
+| Wait for state | `waitFor(() => machine.state === 'ready')` |
+| Wait for count | `waitFor(() => items.length >= 5)` |
+| Wait for file | `waitFor(() => fs.existsSync(path))` |
+| Complex condition | `waitFor(() => obj.ready && obj.value > 10)` |
+
+## Implementation
+
+Generic polling function:
+```typescript
+async function waitFor<T>(
+  condition: () => T | undefined | null | false,
+  description: string,
+  timeoutMs = 5000
+): Promise<T> {
+  const startTime = Date.now();
+
+  while (true) {
+    const result = condition();
+    if (result) return result;
+
+    if (Date.now() - startTime > timeoutMs) {
+      throw new Error(`Timeout waiting for ${description} after ${timeoutMs}ms`);
+    }
+
+    await new Promise(r => setTimeout(r, 10)); // Poll every 10ms
+  }
+}
+```
+
+See @example.ts for complete implementation with domain-specific helpers (`waitForEvent`, `waitForEventCount`, `waitForEventMatch`) from actual debugging session.
+
+## Common Mistakes
+
+**❌ Polling too fast:** `setTimeout(check, 1)` - wastes CPU
+**✅ Fix:** Poll every 10ms
+
+**❌ No timeout:** Loop forever if condition never met
+**✅ Fix:** Always include timeout with clear error
+
+**❌ Stale data:** Cache state before loop
+**✅ Fix:** Call getter inside loop for fresh data
+
+## When Arbitrary Timeout IS Correct
+
+```typescript
+// Tool ticks every 100ms - need 2 ticks to verify partial output
+await waitForEvent(manager, 'TOOL_STARTED'); // First: wait for condition
+await new Promise(r => setTimeout(r, 200));   // Then: wait for timed behavior
+// 200ms = 2 ticks at 100ms intervals - documented and justified
+```
+
+**Requirements:**
+1. First wait for triggering condition
+2. Based on known timing (not guessing)
+3. Comment explaining WHY
+
+## Real-World Impact
+
+From debugging session (2025-10-03):
+- Fixed 15 flaky tests across 3 files
+- Pass rate: 60% → 100%
+- Execution time: 40% faster
+- No more race conditions

package/skills/condition-based-waiting/example.ts

@@ -0,0 +1,158 @@
+// Complete implementation of condition-based waiting utilities
+// From: Lace test infrastructure improvements (2025-10-03)
+// Context: Fixed 15 flaky tests by replacing arbitrary timeouts
+
+import type { ThreadManager } from '~/threads/thread-manager';
+import type { LaceEvent, LaceEventType } from '~/threads/types';
+
+/**
+ * Wait for a specific event type to appear in thread
+ *
+ * @param threadManager - The thread manager to query
+ * @param threadId - Thread to check for events
+ * @param eventType - Type of event to wait for
+ * @param timeoutMs - Maximum time to wait (default 5000ms)
+ * @returns Promise resolving to the first matching event
+ *
+ * Example:
+ *   await waitForEvent(threadManager, agentThreadId, 'TOOL_RESULT');
+ */
+export function waitForEvent(
+  threadManager: ThreadManager,
+  threadId: string,
+  eventType: LaceEventType,
+  timeoutMs = 5000
+): Promise<LaceEvent> {
+  return new Promise((resolve, reject) => {
+    const startTime = Date.now();
+
+    const check = () => {
+      const events = threadManager.getEvents(threadId);
+      const event = events.find((e) => e.type === eventType);
+
+      if (event) {
+        resolve(event);
+      } else if (Date.now() - startTime > timeoutMs) {
+        reject(new Error(`Timeout waiting for ${eventType} event after ${timeoutMs}ms`));
+      } else {
+        setTimeout(check, 10); // Poll every 10ms for efficiency
+      }
+    };
+
+    check();
+  });
+}
+
+/**
+ * Wait for a specific number of events of a given type
+ *
+ * @param threadManager - The thread manager to query
+ * @param threadId - Thread to check for events
+ * @param eventType - Type of event to wait for
+ * @param count - Number of events to wait for
+ * @param timeoutMs - Maximum time to wait (default 5000ms)
+ * @returns Promise resolving to all matching events once count is reached
+ *
+ * Example:
+ *   // Wait for 2 AGENT_MESSAGE events (initial response + continuation)
+ *   await waitForEventCount(threadManager, agentThreadId, 'AGENT_MESSAGE', 2);
+ */
+export function waitForEventCount(
+  threadManager: ThreadManager,
+  threadId: string,
+  eventType: LaceEventType,
+  count: number,
+  timeoutMs = 5000
+): Promise<LaceEvent[]> {
+  return new Promise((resolve, reject) => {
+    const startTime = Date.now();
+
+    const check = () => {
+      const events = threadManager.getEvents(threadId);
+      const matchingEvents = events.filter((e) => e.type === eventType);
+
+      if (matchingEvents.length >= count) {
+        resolve(matchingEvents);
+      } else if (Date.now() - startTime > timeoutMs) {
+        reject(
+          new Error(
+            `Timeout waiting for ${count} ${eventType} events after ${timeoutMs}ms (got ${matchingEvents.length})`
+          )
+        );
+      } else {
+        setTimeout(check, 10);
+      }
+    };
+
+    check();
+  });
+}
+
+/**
+ * Wait for an event matching a custom predicate
+ * Useful when you need to check event data, not just type
+ *
+ * @param threadManager - The thread manager to query
+ * @param threadId - Thread to check for events
+ * @param predicate - Function that returns true when event matches
+ * @param description - Human-readable description for error messages
+ * @param timeoutMs - Maximum time to wait (default 5000ms)
+ * @returns Promise resolving to the first matching event
+ *
+ * Example:
+ *   // Wait for TOOL_RESULT with specific ID
+ *   await waitForEventMatch(
+ *     threadManager,
+ *     agentThreadId,
+ *     (e) => e.type === 'TOOL_RESULT' && e.data.id === 'call_123',
+ *     'TOOL_RESULT with id=call_123'
+ *   );
+ */
+export function waitForEventMatch(
+  threadManager: ThreadManager,
+  threadId: string,
+  predicate: (event: LaceEvent) => boolean,
+  description: string,
+  timeoutMs = 5000
+): Promise<LaceEvent> {
+  return new Promise((resolve, reject) => {
+    const startTime = Date.now();
+
+    const check = () => {
+      const events = threadManager.getEvents(threadId);
+      const event = events.find(predicate);
+
+      if (event) {
+        resolve(event);
+      } else if (Date.now() - startTime > timeoutMs) {
+        reject(new Error(`Timeout waiting for ${description} after ${timeoutMs}ms`));
+      } else {
+        setTimeout(check, 10);
+      }
+    };
+
+    check();
+  });
+}
+
+// Usage example from actual debugging session:
+//
+// BEFORE (flaky):
+// ---------------
+// const messagePromise = agent.sendMessage('Execute tools');
+// await new Promise(r => setTimeout(r, 300)); // Hope tools start in 300ms
+// agent.abort();
+// await messagePromise;
+// await new Promise(r => setTimeout(r, 50));  // Hope results arrive in 50ms
+// expect(toolResults.length).toBe(2);         // Fails randomly
+//
+// AFTER (reliable):
+// ----------------
+// const messagePromise = agent.sendMessage('Execute tools');
+// await waitForEventCount(threadManager, threadId, 'TOOL_CALL', 2); // Wait for tools to start
+// agent.abort();
+// await messagePromise;
+// await waitForEventCount(threadManager, threadId, 'TOOL_RESULT', 2); // Wait for results
+// expect(toolResults.length).toBe(2); // Always succeeds
+//
+// Result: 60% pass rate → 100%, 40% faster execution

package/skills/database-development/SKILL.md

@@ -0,0 +1,11 @@
+database-development skill helps design efficient, scalable database schemas and manage database migrations effectively.
+
+For code review, check that:
+1. Database schema follows normalization principles
+2. Proper indexes are created for query optimization
+3. Foreign key constraints are defined
+4. Migration files are reversible
+5. Connection pooling is implemented
+6. Query N+1 problems are avoided
+7. Database transactions are used appropriately
+8. Sensitive data is encrypted in database

package/skills/database-development/migrations/migration.template.sql

@@ -0,0 +1,49 @@
+-- Migration: [Description]
+-- Created: [Date]
+-- Author: [Author]
+
+-- Enable transaction for safety
+BEGIN;
+
+-- Add new table
+CREATE TABLE [table_name] (
+    id SERIAL PRIMARY KEY,
+    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
+    updated_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP,
+    -- Add columns here
+);
+
+-- Add indexes if needed
+CREATE INDEX [index_name] ON [table_name]([column_name]);
+
+-- Add foreign key constraints
+ALTER TABLE [table_name]
+ADD CONSTRAINT [constraint_name]
+FOREIGN KEY ([column_name])
+REFERENCES [other_table]([column_name]);
+
+-- Add columns to existing tables
+ALTER TABLE [existing_table]
+ADD COLUMN [column_name] [type] [constraints];
+
+-- Update timestamp
+CREATE OR REPLACE FUNCTION update_updated_at_column()
+RETURNS TRIGGER AS $$
+BEGIN
+    NEW.updated_at = CURRENT_TIMESTAMP;
+    RETURN NEW;
+END;
+$$ language 'plpgsql';
+
+CREATE TRIGGER update_[table_name]_updated_at
+BEFORE UPDATE ON [table_name]
+FOR EACH ROW
+EXECUTE FUNCTION update_updated_at_column();
+
+COMMIT;
+
+-- Rollback script (keep for reference):
+-- BEGIN;
+-- DROP TABLE IF EXISTS [table_name];
+-- ALTER TABLE [existing_table] DROP COLUMN [column_name];
+-- COMMIT;

package/skills/defense-in-depth/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: defense-in-depth
+description: Use when invalid data causes failures deep in execution, requiring validation at multiple system layers - validates at every layer data passes through to make bugs structurally impossible
+---
+
+# Defense-in-Depth Validation
+
+## Overview
+
+When you fix a bug caused by invalid data, adding validation at one place feels sufficient. But that single check can be bypassed by different code paths, refactoring, or mocks.
+
+**Core principle:** Validate at EVERY layer data passes through. Make the bug structurally impossible.
+
+## Why Multiple Layers
+
+Single validation: "We fixed the bug"
+Multiple layers: "We made the bug impossible"
+
+Different layers catch different cases:
+- Entry validation catches most bugs
+- Business logic catches edge cases
+- Environment guards prevent context-specific dangers
+- Debug logging helps when other layers fail
+
+## The Four Layers
+
+### Layer 1: Entry Point Validation
+**Purpose:** Reject obviously invalid input at API boundary
+
+```typescript
+function createProject(name: string, workingDirectory: string) {
+  if (!workingDirectory || workingDirectory.trim() === '') {
+    throw new Error('workingDirectory cannot be empty');
+  }
+  if (!existsSync(workingDirectory)) {
+    throw new Error(`workingDirectory does not exist: ${workingDirectory}`);
+  }
+  if (!statSync(workingDirectory).isDirectory()) {
+    throw new Error(`workingDirectory is not a directory: ${workingDirectory}`);
+  }
+  // ... proceed
+}
+```
+
+### Layer 2: Business Logic Validation
+**Purpose:** Ensure data makes sense for this operation
+
+```typescript
+function initializeWorkspace(projectDir: string, sessionId: string) {
+  if (!projectDir) {
+    throw new Error('projectDir required for workspace initialization');
+  }
+  // ... proceed
+}
+```
+
+### Layer 3: Environment Guards
+**Purpose:** Prevent dangerous operations in specific contexts
+
+```typescript
+async function gitInit(directory: string) {
+  // In tests, refuse git init outside temp directories
+  if (process.env.NODE_ENV === 'test') {
+    const normalized = normalize(resolve(directory));
+    const tmpDir = normalize(resolve(tmpdir()));
+
+    if (!normalized.startsWith(tmpDir)) {
+      throw new Error(
+        `Refusing git init outside temp dir during tests: ${directory}`
+      );
+    }
+  }
+  // ... proceed
+}
+```
+
+### Layer 4: Debug Instrumentation
+**Purpose:** Capture context for forensics
+
+```typescript
+async function gitInit(directory: string) {
+  const stack = new Error().stack;
+  logger.debug('About to git init', {
+    directory,
+    cwd: process.cwd(),
+    stack,
+  });
+  // ... proceed
+}
+```
+
+## Applying the Pattern
+
+When you find a bug:
+
+1. **Trace the data flow** - Where does bad value originate? Where used?
+2. **Map all checkpoints** - List every point data passes through
+3. **Add validation at each layer** - Entry, business, environment, debug
+4. **Test each layer** - Try to bypass layer 1, verify layer 2 catches it
+
+## Example from Session
+
+Bug: Empty `projectDir` caused `git init` in source code
+
+**Data flow:**
+1. Test setup → empty string
+2. `Project.create(name, '')`
+3. `WorkspaceManager.createWorkspace('')`
+4. `git init` runs in `process.cwd()`
+
+**Four layers added:**
+- Layer 1: `Project.create()` validates not empty/exists/writable
+- Layer 2: `WorkspaceManager` validates projectDir not empty
+- Layer 3: `WorktreeManager` refuses git init outside tmpdir in tests
+- Layer 4: Stack trace logging before git init
+
+**Result:** All 1847 tests passed, bug impossible to reproduce
+
+## Key Insight
+
+All four layers were necessary. During testing, each layer caught bugs the others missed:
+- Different code paths bypassed entry validation
+- Mocks bypassed business logic checks
+- Edge cases on different platforms needed environment guards
+- Debug logging identified structural misuse
+
+**Don't stop at one validation point.** Add checks at every layer.

package/skills/deployment/SKILL.md

@@ -0,0 +1,11 @@
+deployment skill helps automate application deployment through containerization, CI/CD pipelines, and monitoring setup.
+
+For code review, check that:
+1. Dockerfile follows best practices
+2. Multi-stage builds are used to reduce image size
+3. Health checks are implemented
+4. Environment variables are properly managed
+5. CI/CD pipeline tests all deployments
+6. Monitoring and logging are configured
+7. Rollback strategies are in place
+8. Zero-downtime deployment is considered