anchi-kit 1.2.1 → 1.2.2

package/.cursor/skills/sequential-thinking/references/advanced-techniques.md

@@ -1,76 +0,0 @@
-# Advanced Sequential Thinking Techniques
-
-Complex problem-solving patterns.
-
-## Spiral Refinement
-
-Return to concepts with progressively deeper understanding.
-
-```
-Thought 1/7: Initial design (surface)
-Thought 2/7: Discover constraint A
-Thought 3/7: Refine for A
-Thought 4/7: Discover constraint B
-Thought 5/7: Refine for both A and B
-Thought 6/7: Integration reveals edge case
-Thought 7/7: Final design addressing all constraints
-```
-
-**Use for**: Complex systems where constraints emerge iteratively.
-**Key**: Each return is refinement, not restart.
-
-## Hypothesis-Driven Investigation
-
-Systematic hypothesis generation and testing.
-
-```
-Thought 1/6: Observe symptoms
-Thought 2/6 [HYPOTHESIS]: Explanation X
-Thought 3/6 [VERIFICATION]: Test X—partial match
-Thought 4/6 [REFINED HYPOTHESIS]: Adjusted Y
-Thought 5/6 [VERIFICATION]: Test Y—confirmed
-Thought 6/6 [FINAL]: Solution based on verified Y
-```
-
-**Use for**: Debugging, root cause analysis, diagnostics.
-**Pattern**: Generate → Test → Refine → Re-test loop.
-
-## Multi-Branch Convergence
-
-Explore alternatives, then synthesize best approach.
-
-```
-Thought 2/8: Multiple viable approaches
-Thought 3/8 [BRANCH A]: Approach A benefits
-Thought 4/8 [BRANCH A]: Approach A drawbacks
-Thought 5/8 [BRANCH B]: Approach B benefits
-Thought 6/8 [BRANCH B]: Approach B drawbacks
-Thought 7/8 [CONVERGENCE]: Hybrid combining A's X with B's Y
-Thought 8/8 [FINAL]: Hybrid superior to either alone
-```
-
-**Use for**: Complex decisions where neither option clearly best.
-**Key**: Convergence often yields better solution than either branch.
-
-## Progressive Context Deepening
-
-Build understanding in layers from abstract to concrete.
-
-```
-Thought 1/9: High-level problem
-Thought 2/9: Identify major components
-Thought 3/9: Zoom into component A (detailed)
-Thought 4/9: Zoom into component B (detailed)
-Thought 5/9: Identify A-B interactions
-Thought 6/9: Discover emergent constraint
-Thought 7/9 [REVISION of 3-4]: Adjust for interaction
-Thought 8/9: Verify complete system
-Thought 9/9 [FINAL]: Integrated solution
-```
-
-**Use for**: System design, architecture, integration problems.
-**Pattern**: Abstract → Components → Details → Interactions → Integration.
-
-## Reference
-
-See `advanced-strategies.md` for: Uncertainty Management, Revision Cascade Management, Meta-Thinking Calibration, Parallel Constraint Satisfaction.

package/.cursor/skills/sequential-thinking/references/core-patterns.md

@@ -1,95 +0,0 @@
-# Core Sequential Thinking Patterns
-
-Essential revision and branching patterns.
-
-## Revision Patterns
-
-### Assumption Challenge
-Early assumption proves invalid with new data.
-```
-Thought 1/5: Assume X is bottleneck
-Thought 4/5 [REVISION of Thought 1]: X adequate; Y is actual bottleneck
-```
-
-### Scope Expansion
-Problem larger than initially understood.
-```
-Thought 1/4: Fix bug
-Thought 4/5 [REVISION of scope]: Architectural redesign needed, not patch
-```
-
-### Approach Shift
-Initial strategy inadequate for requirements.
-```
-Thought 2/6: Optimize query
-Thought 5/6 [REVISION of Thought 2]: Optimization + cache layer required
-```
-
-### Understanding Deepening
-Later insight fundamentally changes interpretation.
-```
-Thought 1/5: Feature broken
-Thought 4/5 [REVISION of Thought 1]: Not bug—UX confusion issue
-```
-
-## Branching Patterns
-
-### Trade-off Evaluation
-Compare approaches with different trade-offs.
-```
-Thought 3/7: Choose between X and Y
-Thought 4/7 [BRANCH A]: X—simpler, less scalable
-Thought 4/7 [BRANCH B]: Y—complex, scales better
-Thought 5/7: Choose Y for long-term needs
-```
-
-### Risk Mitigation
-Prepare backup for high-risk primary approach.
-```
-Thought 2/6: Primary: API integration
-Thought 3/6 [BRANCH A]: API details
-Thought 3/6 [BRANCH B]: Fallback: webhook
-Thought 4/6: Implement A with B contingency
-```
-
-### Parallel Exploration
-Investigate independent concerns separately.
-```
-Thought 3/8: Two unknowns—DB schema & API design
-Thought 4/8 [BRANCH DB]: DB options
-Thought 4/8 [BRANCH API]: API patterns
-Thought 5/8: Integrate findings
-```
-
-### Hypothesis Testing
-Test multiple explanations systematically.
-```
-Thought 2/6: Could be A, B, or C
-Thought 3/6 [BRANCH A]: Test A—not cause
-Thought 3/6 [BRANCH B]: Test B—confirmed
-Thought 4/6: Root cause via Branch B
-```
-
-## Adjustment Guidelines
-
-**Expand when**: Complexity discovered, multiple aspects identified, verification needed, alternatives require exploration.
-
-**Contract when**: Key insight solves earlier, problem simpler, steps merge naturally.
-
-**Example**:
-```
-Thought 1/5: Initial
-Thought 3/7: Complexity (5→7)
-Thought 5/8: Another aspect (7→8)
-Thought 8/8 [FINAL]: Complete
-```
-
-## Anti-Patterns
-
-**Premature Completion**: Rushing without verification → Add verification thoughts.
-
-**Revision Cascade**: Repeated revisions without understanding why → Identify root cause.
-
-**Branching Explosion**: Too many branches → Limit to 2-3, converge before more.
-
-**Context Loss**: Ignoring earlier insights → Reference previous thoughts explicitly.

package/.cursor/skills/sequential-thinking/references/examples-api.md

@@ -1,88 +0,0 @@
-# Example: API Design with Sequential Thinking
-
-**Problem**: Design authentication API for multi-tenant SaaS.
-
-## Without Sequential Thinking
-"Use JWT with OAuth2. Add tenant ID to claims. Implement refresh tokens."
-(Misses edge cases, scaling, security)
-
-## With Sequential Thinking
-
-```
-Thought 1/5: Requirements
-
-Multi-tenant SaaS authentication needs:
-- Tenant isolation (prevent cross-tenant access)
-- Scalability (thousands of tenants)
-- Security (industry standards)
-
-Uncertainty: Session vs token? Stateful vs stateless?
-Next: Evaluate approaches
-
-Thought 2/6: Approach evaluation (adjusted)
-
-Comparing session vs JWT:
-- Session: Server state, easy revocation, harder scaling
-- JWT: Stateless, scales well, complex revocation
-
-Multi-tenancy complicates sessions (which DB?).
-JWT better for distributed systems.
-Next: JWT structure
-
-Thought 3/6: JWT payload design
-
-JWT includes: User ID, Tenant ID, Permissions, Expiration
-
-Uncertainty: Where verify tenant? Gateway vs service?
-Next: Token refresh
-
-Thought 4/6 [REVISION of Thought 3]: Security fix
-
-Original: Tenant ID in JWT claims.
-Issue: Claims visible (base64), could read tenant IDs.
-
-Corrected:
-- Keep tenant ID (needed for routing)
-- Add gateway verification
-- Log access attempts
-
-Impact: Need gateway security layer
-
-Thought 5/7: Refresh strategy (adjusted)
-
-Access: 15 min
-Refresh: 7 days, rotate on use
-
-Storage:
-- Access: Client memory
-- Refresh: HttpOnly cookie + DB revocation
-
-Enables revocation + stateless benefits.
-
-Thought 6/7: Gateway flow
-
-1. Verify JWT signature
-2. Extract tenant ID
-3. Verify user belongs to tenant (cache + DB)
-4. Forward with verified context
-
-Addresses Thought 4 security concern.
-
-Thought 7/7 [FINAL]: Complete solution
-
-- JWT with refresh rotation
-- Tenant ID + gateway verification
-- 15-min access, 7-day refresh
-- HttpOnly cookies + revocation DB
-- Gateway enforces isolation
-
-Confidence: High
-Assumptions: Distributed, centralized gateway
-Trade-offs: Slight latency vs security
-```
-
-## Key Outcomes
-
-1. **Revision caught security issue**: Tenant ID visibility
-2. **Dynamic adjustment**: 5→7 thoughts as complexity emerged
-3. **Comprehensive**: Authentication, authorization, multi-tenancy, revocation

package/.cursor/skills/sequential-thinking/references/examples-architecture.md

@@ -1,94 +0,0 @@
-# Example: Architecture Decision with Sequential Thinking
-
-**Problem**: Choose state management for growing React app.
-
-## Sequential Thinking Approach
-
-```
-Thought 1/4: Initial assessment
-
-React app growing complex. useState scattered across components.
-Need centralized state management.
-Options: Redux, MobX, Zustand, Context API, Jotai.
-
-Next: Define requirements
-
-Thought 2/5: Requirements (adjusted up)
-
-App needs:
-- Real-time updates (WebSocket)
-- Offline support
-- Complex nested state
-- Multiple devs (maintainability)
-- TypeScript (type safety)
-
-These eliminate simpler solutions.
-Next: Evaluate remaining options
-
-Thought 3/5 [REVISION of Thought 1]: Scope refinement
-
-Original assumption: Need global state management.
-Realization: Not all state needs centralization.
-
-Better breakdown:
-- Server state (API data): React Query
-- UI state (modals, forms): Local useState
-- Auth state: Context API
-- App-wide settings: Simple global store
-
-This reduces problem scope significantly.
-Changes evaluation criteria.
-Next: Re-evaluate with refined scope
-
-Thought 4/6: Re-evaluation (adjusted)
-
-Only need lightweight store for app-wide settings.
-Zustand fits:
-- Minimal boilerplate
-- Excellent TypeScript support
-- No provider wrapper
-- ~1KB size
-
-React Query handles server state (caching, refetch, offline).
-Most state stays local.
-
-Next: Verify this handles all requirements
-
-Thought 5/6 [HYPOTHESIS]: Hybrid approach
-
-Hypothesis: Zustand + React Query + local state solves needs.
-
-- Zustand: Theme, user prefs, global UI flags
-- React Query: All server data, caching, sync
-- useState: Component-local UI
-
-Benefits: Simple, performant, maintainable.
-Uncertainty: Real-time updates?
-
-Thought 6/6 [FINAL]: Verified solution
-
-React Query supports WebSocket via custom hooks.
-Zustand handles global UI simply.
-Local state for component-specific needs.
-
-Architecture decision:
-- Zustand for global UI state
-- React Query for all server interactions
-- Local useState for component state
-
-Confidence: High
-Assumptions: Team comfortable with React Query patterns
-Benefits: Simpler than Redux, more powerful than Context
-Trade-offs: Learning curve for React Query (but worthwhile)
-```
-
-## Key Insights
-
-1. **Scope revision crucial**: Original "need global state" reframed to specific state categories
-2. **Separation of concerns**: Different state types need different solutions
-3. **Hypothesis verification**: Confirmed WebSocket support before finalizing
-4. **Simpler is better**: Avoided over-engineering with heavy Redux solution
-
-## Impact of Revision
-
-Without Thought 3 revision, might have chosen Redux for all state—significant over-engineering. Revision led to more appropriate, simpler solution.

package/.cursor/skills/sequential-thinking/references/examples-debug.md

@@ -1,90 +0,0 @@
-# Example: Performance Debugging with Sequential Thinking
-
-**Problem**: API endpoint slow (2-3s instead of <200ms).
-
-## Sequential Thinking Approach
-
-```
-Thought 1/5: Initial investigation
-
-Endpoint: GET /api/users/{id}/dashboard
-Expected: <200ms
-Actual: 2-3s
-
-Need to identify bottleneck.
-Next: Analyze endpoint logic
-
-Thought 2/5: Endpoint analysis
-
-Dashboard fetches:
-- User profile
-- Recent activities (last 50)
-- Notifications (unread)
-- Analytics summary
-
-Each is separate DB query. Could be N+1 problem.
-Next: Profile actual execution
-
-Thought 3/6: Profiling results (adjusted up—more complex)
-
-Profiling:
-- User profile: 20ms
-- Activities: 1800ms (!!)
-- Notifications: 100ms
-- Analytics: 80ms
-
-Activities query is bottleneck (90% of time).
-Need to examine that query.
-Next: Investigate activities query
-
-Thought 4/6 [BRANCH A]: Hypothesis - N+1 query
-
-Activities table has user_id FK to users.
-Query might fetch activities, then user for each (N+1).
-Verification: Check if uses joins or loops.
-
-Thought 4/6 [BRANCH B]: Hypothesis - Missing index
-
-Activities table might lack index on user_id + created_at.
-Without index, full table scan for user's activities.
-Verification: Check table indexes.
-
-Thought 5/6 [VERIFICATION]: Testing hypotheses
-
-Query examination: Uses proper joins (not N+1).
-Index check: user_id indexed, NOT created_at.
-Query filters by user_id AND sorts by created_at.
-
-Branch B confirmed: Missing composite index causes slow sort.
-Branch A eliminated: No N+1 issue.
-
-Root cause identified.
-Next: Implement solution
-
-Thought 6/6 [FINAL]: Solution and verification
-
-Create composite index:
-```sql
-CREATE INDEX idx_activities_user_created
-ON activities(user_id, created_at DESC);
-```
-
-Tested: Response time now 120ms (target met).
-
-Confidence: High (verified with profiling)
-Result: 95% performance improvement
-```
-
-## Key Techniques Demonstrated
-
-1. **Branching for hypothesis testing**: Explored N+1 vs index hypotheses in parallel
-2. **Verification before solution**: Tested both hypotheses systematically
-3. **Data-driven decisions**: Used profiling data to guide investigation
-4. **Dynamic adjustment**: Expanded thought count when complexity emerged
-5. **Elimination method**: Ruled out N+1, confirmed index issue
-
-## Comparison
-
-**Without sequential thinking**: Might jump to N+1 conclusion (common issue), waste time optimizing wrong thing.
-
-**With sequential thinking**: Systematically tested hypotheses, identified actual root cause, implemented correct fix.

package/.cursor/skills/sequential-thinking/scripts/format-thought.js

@@ -1,159 +0,0 @@
-#!/usr/bin/env node
-
-/**
- * Sequential Thinking Thought Formatter
- *
- * Formats thoughts for display with visual indicators for type (regular/revision/branch).
- * Provides consistent, readable output for thought sequences.
- *
- * Usage:
- *   node format-thought.js --thought "Analysis" --number 1 --total 5
- *   node format-thought.js --thought "Revision" --number 2 --total 5 --revision 1
- *   node format-thought.js --thought "Branch A" --number 3 --total 5 --branch 2 --branchId "a"
- */
-
-class ThoughtFormatter {
-  static format(thoughtData) {
-    const { thoughtNumber, totalThoughts, thought, isRevision, revisesThought, branchFromThought, branchId } = thoughtData;
-
-    let prefix = '';
-    let context = '';
-    let emoji = '';
-
-    if (isRevision && revisesThought) {
-      emoji = '🔄';
-      prefix = 'REVISION';
-      context = ` (revising thought ${revisesThought})`;
-    } else if (branchFromThought) {
-      emoji = '🌿';
-      prefix = 'BRANCH';
-      context = branchId ? ` (from thought ${branchFromThought}, ID: ${branchId})` : ` (from thought ${branchFromThought})`;
-    } else {
-      emoji = '💭';
-      prefix = 'Thought';
-      context = '';
-    }
-
-    const header = `${emoji} ${prefix} ${thoughtNumber}/${totalThoughts}${context}`;
-    const maxLength = Math.max(header.length, thought.length);
-    const border = '─'.repeat(maxLength + 4);
-
-    // Wrap long thoughts
-    const wrappedThought = this.wrapText(thought, maxLength);
-    const thoughtLines = wrappedThought.map(line => `│ ${line.padEnd(maxLength + 2)} │`).join('\n');
-
-    return `
-┌${border}┐
-│ ${header.padEnd(maxLength + 2)} │
-├${border}┤
-${thoughtLines}
-└${border}┘`;
-  }
-
-  static wrapText(text, maxWidth) {
-    if (text.length <= maxWidth) {
-      return [text];
-    }
-
-    const words = text.split(' ');
-    const lines = [];
-    let currentLine = '';
-
-    for (const word of words) {
-      if ((currentLine + ' ' + word).trim().length <= maxWidth) {
-        currentLine = currentLine ? currentLine + ' ' + word : word;
-      } else {
-        if (currentLine) lines.push(currentLine);
-        currentLine = word;
-      }
-    }
-
-    if (currentLine) lines.push(currentLine);
-    return lines;
-  }
-
-  static formatSimple(thoughtData) {
-    const { thoughtNumber, totalThoughts, thought, isRevision, revisesThought, branchFromThought, branchId } = thoughtData;
-
-    let marker = '';
-    if (isRevision && revisesThought) {
-      marker = ` [REVISION of Thought ${revisesThought}]`;
-    } else if (branchFromThought) {
-      marker = branchId ? ` [BRANCH ${branchId.toUpperCase()} from Thought ${branchFromThought}]` : ` [BRANCH from Thought ${branchFromThought}]`;
-    }
-
-    return `Thought ${thoughtNumber}/${totalThoughts}${marker}: ${thought}`;
-  }
-
-  static formatMarkdown(thoughtData) {
-    const { thoughtNumber, totalThoughts, thought, isRevision, revisesThought, branchFromThought, branchId } = thoughtData;
-
-    let marker = '';
-    if (isRevision && revisesThought) {
-      marker = ` **[REVISION of Thought ${revisesThought}]**`;
-    } else if (branchFromThought) {
-      marker = branchId ? ` **[BRANCH ${branchId.toUpperCase()} from Thought ${branchFromThought}]**` : ` **[BRANCH from Thought ${branchFromThought}]**`;
-    }
-
-    return `**Thought ${thoughtNumber}/${totalThoughts}**${marker}\n\n${thought}\n`;
-  }
-}
-
-// CLI Interface
-if (require.main === module) {
-  const args = process.argv.slice(2);
-
-  const parseArgs = (args) => {
-    const parsed = {};
-    for (let i = 0; i < args.length; i++) {
-      const arg = args[i];
-      if (arg.startsWith('--')) {
-        const key = arg.slice(2);
-        const value = args[i + 1];
-
-        if (value && !value.startsWith('--')) {
-          // Parse boolean
-          if (value === 'true') parsed[key] = true;
-          else if (value === 'false') parsed[key] = false;
-          // Parse number
-          else if (!isNaN(value)) parsed[key] = parseFloat(value);
-          // String
-          else parsed[key] = value;
-          i++;
-        }
-      }
-    }
-    return parsed;
-  };
-
-  const input = parseArgs(args);
-
-  const thoughtData = {
-    thought: input.thought || 'No thought provided',
-    thoughtNumber: input.number || 1,
-    totalThoughts: input.total || 1,
-    isRevision: input.revision !== undefined,
-    revisesThought: input.revision,
-    branchFromThought: input.branch,
-    branchId: input.branchId
-  };
-
-  const format = input.format || 'box';
-
-  let output;
-  switch (format) {
-    case 'simple':
-      output = ThoughtFormatter.formatSimple(thoughtData);
-      break;
-    case 'markdown':
-      output = ThoughtFormatter.formatMarkdown(thoughtData);
-      break;
-    case 'box':
-    default:
-      output = ThoughtFormatter.format(thoughtData);
-  }
-
-  console.log(output);
-}
-
-module.exports = { ThoughtFormatter };