cokit-cli 1.0.9 → 1.2.2

package/skills/{ck-sequential-thinking → sequential-thinking}/references/examples-architecture.md

@@ -1,94 +1,94 @@
-# 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.
+# 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/skills/{ck-sequential-thinking → sequential-thinking}/references/examples-debug.md

@@ -1,90 +1,90 @@
-# 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.
+# 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.