@ekkos/cli 1.3.1 → 1.3.5

package/templates/skills/ekkOS_Schema/Skill.md

@@ -1,251 +0,0 @@
----
-name: ekkOS_Schema
-description: Know the correct database field names. Activate when writing SQL queries, working with Supabase, using Prisma, accessing database tables, or when you need to reference column names. This skill prevents "column does not exist" errors by checking the indexed schema first.
-allowed-tools:
-  - mcp__ekkos-memory__ekkOS_GetSchema
-  - mcp__ekkos-memory__ekkOS_IndexSchema
-  - mcp__ekkos-memory__ekkOS_Search
-  - Read
-  - Glob
----
-
-# ekkOS_Schema
-
-You are augmented with **ekkOS_ memory** - and you know the EXACT field names in this project's database.
-
-## Why This Skill Exists
-
-Database schema mismatches are a common source of errors:
-- `column "userId" does not exist` (it's `user_id`)
-- `relation "Users" does not exist` (it's `users`)
-- Wrong type assumptions
-
-This skill ensures you use the CORRECT field names.
-
-## When To Activate
-
-This skill should trigger when:
-
-| Trigger | Example |
-|---------|---------|
-| Writing SQL | `SELECT * FROM users WHERE...` |
-| Supabase queries | `.from('users').select('...')` |
-| Prisma operations | `prisma.user.findMany({...})` |
-| TypeScript DB types | `Database['public']['Tables']` |
-| Migration creation | `CREATE TABLE...` |
-| Any column reference | Mentioning a database field |
-
-## Instructions
-
-### Step 1: Identify the Table/Type
-
-Extract the table name from the context:
-- SQL: `SELECT ... FROM users` → `users`
-- Supabase: `.from('profiles')` → `profiles`
-- Prisma: `prisma.post.findMany` → `post`
-
-### Step 2: Get the Schema
-
-```
-ekkOS_GetSchema({
-  table_name: "users"
-})
-```
-
-Response:
-```json
-{
-  "table_name": "users",
-  "columns": [
-    {"name": "id", "type": "uuid", "nullable": false},
-    {"name": "email", "type": "text", "nullable": false},
-    {"name": "created_at", "type": "timestamptz", "nullable": false},
-    {"name": "display_name", "type": "text", "nullable": true}
-  ],
-  "primary_key": "id",
-  "foreign_keys": [...]
-}
-```
-
-### Step 3: Use Correct Names
-
-Now you know:
-- It's `display_name`, not `displayName`
-- It's `created_at`, not `createdAt`
-- `id` is UUID, not integer
-
-### Step 4: Write Correct Query
-
-```sql
--- WRONG (would fail)
-SELECT displayName FROM Users WHERE createdAt > '2024-01-01'
-
--- CORRECT (using schema)
-SELECT display_name FROM users WHERE created_at > '2024-01-01'
-```
-
-## First-Time Setup: Index the Schema
-
-If schema isn't indexed yet, index it first:
-
-```
-ekkOS_IndexSchema({
-  project_path: "/path/to/project",
-  files: [
-    {
-      name: "packages/database-types/index.ts",
-      content: "... file contents ..."
-    }
-  ]
-})
-```
-
-This indexes Supabase types, Prisma schemas, and TypeScript interfaces.
-
-## Example Scenarios
-
-### Scenario 1: Supabase Query
-```
-User: "Query all users who signed up this month"
-
-You: *Before writing query*
-
-     ekkOS_GetSchema({ table_name: "users" })
-
-     Response: columns include `created_at` (not `createdAt`)
-
-     "Here's the query:
-      ```typescript
-      const { data } = await supabase
-        .from('users')
-        .select('id, email, display_name, created_at')
-        .gte('created_at', startOfMonth)
-      ```"
-```
-
-### Scenario 2: Prisma Operation
-```
-User: "Find all posts with their authors"
-
-You: *Before writing*
-
-     ekkOS_GetSchema({ table_name: "posts" })
-     ekkOS_GetSchema({ table_name: "users" })
-
-     Response: posts has `author_id` FK to users
-
-     "Here's the Prisma query:
-      ```typescript
-      const posts = await prisma.post.findMany({
-        include: {
-          author: {
-            select: {
-              id: true,
-              display_name: true
-            }
-          }
-        }
-      })
-      ```"
-```
-
-### Scenario 3: Migration
-```
-User: "Add a bio field to the profiles table"
-
-You: *Check existing schema*
-
-     ekkOS_GetSchema({ table_name: "profiles" })
-
-     Response: profiles has id, user_id, avatar_url, updated_at
-
-     "Here's the migration:
-      ```sql
-      ALTER TABLE profiles
-      ADD COLUMN bio TEXT;
-      ```
-
-      I confirmed the table is `profiles` (not `profile`)
-      and existing columns use snake_case."
-```
-
-### Scenario 4: Schema Not Indexed
-```
-User: "Query the orders table"
-
-You: ekkOS_GetSchema({ table_name: "orders" })
-
-     Response: Schema not found
-
-     "I don't have the orders schema indexed yet.
-      Let me check the codebase for type definitions..."
-
-     *Reads database types file*
-
-     ekkOS_IndexSchema({
-       project_path: "...",
-       files: [{ name: "types/database.ts", content: "..." }]
-     })
-
-     "Schema indexed! The orders table has:
-      - id (uuid)
-      - user_id (uuid, FK to users)
-      - total_amount (numeric)
-      - status (text: pending/completed/cancelled)
-      - created_at (timestamptz)"
-```
-
-## Common Schema Sources
-
-The skill can index from:
-
-| Source | Location |
-|--------|----------|
-| Supabase Types | `packages/database-types/index.ts` |
-| Prisma Schema | `prisma/schema.prisma` |
-| TypeScript Types | `types/database.ts` |
-| SQL Files | `supabase/migrations/*.sql` |
-
-## Fallback: Read Files Directly
-
-If schema isn't indexed:
-
-1. **Find type files:**
-   ```
-   Glob({ pattern: "**/*database*.ts" })
-   Glob({ pattern: "**/schema.prisma" })
-   ```
-
-2. **Read and parse:**
-   ```
-   Read({ file_path: "packages/database-types/index.ts" })
-   ```
-
-3. **Index for future:**
-   ```
-   ekkOS_IndexSchema({ ... })
-   ```
-
-## Integration with Patterns
-
-If you've solved a schema issue before, it's a pattern:
-
-```
-ekkOS_Search({
-  query: "users table schema columns",
-  sources: ["codebase", "patterns"]
-})
-```
-
-## Success Metrics
-
-You're using this skill correctly when:
-- ZERO "column does not exist" errors
-- You check schema BEFORE writing queries
-- You use snake_case vs camelCase correctly
-- Migrations reference existing columns correctly
-- Users trust your database code
-
----
-
-**Mantra**: About to write SQL? Check the schema first. Every time.

package/templates/skills/ekkOS_Summary/Skill.md

@@ -1,257 +0,0 @@
----
-name: ekkOS_Summary
-description: Show what ekkOS learned and did. Activate when the user asks "what did you learn", "show me my patterns", "ekkOS status", "memory summary", or wants to understand what the memory system captured. This skill provides transparency about memory operations.
-allowed-tools:
-  - mcp__ekkos-memory__ekkOS_Summary
-  - mcp__ekkos-memory__ekkOS_Stats
-  - mcp__ekkos-memory__ekkOS_Search
-  - mcp__ekkos-memory__ekkOS_Plans
----
-
-# ekkOS_Summary
-
-You are augmented with **ekkOS_ memory** - and you can show users exactly what the memory system has learned and done.
-
-## Why This Skill Exists
-
-Transparency builds trust:
-- Users should know what's being remembered
-- Pattern counts and success rates matter
-- Session activity should be visible
-
-This skill provides insight into ekkOS operations.
-
-## When To Activate
-
-This skill should trigger when:
-
-| Trigger | Example |
-|---------|---------|
-| "What did you learn?" | Wants to see forged patterns |
-| "Show my patterns" | Wants pattern list |
-| "ekkOS status" | System health check |
-| "Memory summary" | Overview request |
-| "What did ekkOS do?" | Activity review |
-| End of session | Natural summary point |
-
-## Instructions
-
-### Session Summary
-
-```
-ekkOS_Summary({
-  time_window_seconds: 300  // Last 5 minutes
-})
-```
-
-Response:
-```json
-{
-  "session_activity": {
-    "searches": 5,
-    "patterns_retrieved": 12,
-    "patterns_applied": 4,
-    "patterns_forged": 2,
-    "directives_created": 1
-  },
-  "recent_events": [
-    {"type": "search", "query": "auth error", "results": 3},
-    {"type": "forge", "title": "JWT clock tolerance fix"},
-    {"type": "apply", "pattern": "Error handling middleware"}
-  ]
-}
-```
-
-### Memory Statistics
-
-```
-ekkOS_Stats({
-  scope: "personal"  // or "collective" or "both"
-})
-```
-
-Response:
-```json
-{
-  "personal": {
-    "patterns": 127,
-    "directives": 23,
-    "episodes": 489,
-    "avg_success_rate": 0.82
-  },
-  "collective": {
-    "patterns": 5420,
-    "avg_success_rate": 0.78
-  }
-}
-```
-
-## Example Scenarios
-
-### Scenario 1: Session Summary
-```
-User: "What did ekkOS do this session?"
-
-You: ekkOS_Summary({ time_window_seconds: 3600 })
-
-     "🧠 ekkOS Session Summary (last hour):
-
-      📊 Activity:
-      ├── Searches: 8 queries
-      ├── Patterns retrieved: 15
-      ├── Patterns applied: 6
-      └── Patterns forged: 3
-
-      ✨ New patterns created:
-      1. 'Fix CORS with credentials mode'
-      2. 'Supabase RLS policy syntax'
-      3. 'React useEffect cleanup pattern'
-
-      📋 Directives added:
-      1. [PREFER] Use arrow functions
-
-      🎯 Golden Loop compliance: 94%
-
-      Your memory is growing!"
-```
-
-### Scenario 2: Overall Statistics
-```
-User: "How's my ekkOS memory doing?"
-
-You: ekkOS_Stats({ scope: "both" })
-
-     "🧠 ekkOS Memory Statistics:
-
-      📚 Your Personal Memory:
-      ├── Patterns: 127 total
-      ├── Success rate: 82%
-      ├── Directives: 23 active
-      ├── Episodes: 489 conversations
-      └── Most used: 'Error handling' (45 applications)
-
-      🌐 Collective Memory:
-      ├── Total patterns: 5,420
-      ├── Your contributions: 127
-      └── Top category: API Integration
-
-      📈 Growth:
-      ├── This week: +12 patterns
-      ├── This month: +47 patterns
-      └── Trend: ↑ 15% more than last month
-
-      You're in the top 10% of ekkOS contributors!"
-```
-
-### Scenario 3: What Did You Learn?
-```
-User: "What patterns did you learn from our conversation?"
-
-You: ekkOS_Search({
-       query: "session:" + session_id,
-       sources: ["patterns"]
-     })
-
-     "🧠 Patterns learned this session:
-
-      1. **Fix timezone issues in date comparison**
-         Problem: Dates compared without timezone normalization
-         Solution: Always convert to UTC before comparison
-         Confidence: 85%
-
-      2. **Supabase real-time subscription cleanup**
-         Problem: Memory leak from unsubscribed channels
-         Solution: Store subscription and call unsubscribe in useEffect cleanup
-         Confidence: 90%
-
-      3. **Anti-pattern: Don't use .env in client code**
-         Problem: Tried to read .env directly in React
-         Solution: Use NEXT_PUBLIC_ prefix or server-side only
-         Type: Anti-pattern (learned from mistake)
-
-      These will help in future sessions!"
-```
-
-### Scenario 4: Plan Status
-```
-User: "What am I working on?"
-
-You: ekkOS_Plans({ status: "in_progress" })
-
-     ekkOS_Summary({ time_window_seconds: 86400 })
-
-     "🧠 Current State:
-
-      📋 Active Plans:
-      1. **API Refactoring** [5/8 steps]
-         Current: Creating service interfaces
-         Next: Add dependency injection
-
-      2. **Auth System** [2/6 steps]
-         Current: Implementing registration
-         Blocked: Waiting for email service
-
-      📊 Today's Progress:
-      ├── Completed 3 plan steps
-      ├── Forged 2 new patterns
-      └── Applied 8 existing patterns
-
-      Resume API Refactoring?"
-```
-
-### Scenario 5: Memory Health Check
-```
-User: "Is ekkOS working properly?"
-
-You: ekkOS_Stats({})
-
-     "🧠 ekkOS Health Check:
-
-      ✅ API Connection: Healthy
-      ✅ Pattern Layer: 127 patterns indexed
-      ✅ Directive Layer: 23 active rules
-      ✅ Episode Layer: 489 conversations stored
-      ✅ Context Guardian: Active
-
-      📊 Performance:
-      ├── Average search time: 120ms
-      ├── Pattern retrieval rate: 94%
-      └── Golden Loop compliance: 91%
-
-      ⚠️ Suggestions:
-      ├── 5 patterns have <50% success rate
-      └── Consider reviewing/updating these
-
-      Overall: System healthy! 🟢"
-```
-
-## Display Formats
-
-### Compact Summary
-```
-🧠 ekkOS: 127 patterns | 23 directives | 82% success rate
-```
-
-### Detailed Summary
-```
-🧠 ekkOS Memory Summary
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-Patterns:    127 total, 82% success rate
-Directives:  23 active (12 MUST, 8 NEVER, 3 PREFER)
-Episodes:    489 conversations indexed
-Plans:       2 in progress, 15 completed
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-## Success Metrics
-
-You're using this skill correctly when:
-- Users understand what ekkOS is doing
-- Statistics are presented clearly
-- Session activity is transparent
-- Users trust the memory system
-- Summaries are useful, not overwhelming
-
----
-
-**Mantra**: Show the work. Users should see what ekkOS learns.

package/templates/spec-template.md

@@ -1,159 +0,0 @@
-# Feature Specification: [Feature Name]
-
-## Overview
-**Brief description of the feature and its purpose in the Echo ecosystem.**
-
-## User Stories
-
-### Primary User Story
-**As a [user type], I want [functionality] so that [benefit/value].**
-
-### Additional User Stories
-- **As a [user type], I want [functionality] so that [benefit/value].**
-- **As a [user type], I want [functionality] so that [benefit/value].**
-
-## Functional Requirements
-
-### Core Functionality
-1. **Requirement 1**: Description of what the system must do
-2. **Requirement 2**: Description of what the system must do
-3. **Requirement 3**: Description of what the system must do
-
-### AI Integration Requirements
-1. **AI Provider**: Which AI provider(s) will be used
-2. **Processing Pipeline**: How content flows through AI systems
-3. **Fallback Strategy**: What happens when AI fails
-4. **Cost Considerations**: Expected API usage and costs
-
-### Data Requirements
-1. **Input Data**: What data is required
-2. **Output Data**: What data is produced
-3. **Storage Requirements**: How data is persisted
-4. **Privacy Considerations**: Data handling and protection
-
-## Technical Requirements
-
-### API Design
-- **Endpoints**: List of required API endpoints
-- **Request/Response**: Data structures and validation
-- **Authentication**: Security requirements
-- **Rate Limiting**: Performance considerations
-
-### Database Schema
-- **Tables**: New or modified database tables
-- **Indexes**: Performance optimization requirements
-- **Migrations**: Database change requirements
-
-### Frontend Components
-- **UI Components**: New or modified React components
-- **State Management**: Data flow and state handling
-- **User Experience**: Interaction patterns and flows
-
-## Non-Functional Requirements
-
-### Performance
-- **Response Time**: Expected API response times
-- **Throughput**: Expected request volume
-- **Scalability**: Growth and scaling considerations
-
-### Reliability
-- **Uptime**: Availability requirements
-- **Error Handling**: Error scenarios and recovery
-- **Monitoring**: Observability and alerting
-
-### Security
-- **Authentication**: User verification requirements
-- **Authorization**: Access control requirements
-- **Data Protection**: Privacy and security measures
-
-## Acceptance Criteria
-
-### Functional Acceptance
-- [ ] **Criterion 1**: Specific, testable requirement
-- [ ] **Criterion 2**: Specific, testable requirement
-- [ ] **Criterion 3**: Specific, testable requirement
-
-### Technical Acceptance
-- [ ] **Criterion 1**: Performance or technical requirement
-- [ ] **Criterion 2**: Performance or technical requirement
-- [ ] **Criterion 3**: Performance or technical requirement
-
-### AI Acceptance
-- [ ] **Criterion 1**: AI accuracy or quality requirement
-- [ ] **Criterion 2**: AI performance requirement
-- [ ] **Criterion 3**: AI reliability requirement
-
-## Dependencies
-
-### Internal Dependencies
-- **Feature A**: Required for this feature to work
-- **Feature B**: Required for this feature to work
-
-### External Dependencies
-- **API Service**: External service requirements
-- **AI Provider**: AI service requirements
-- **Third-party Library**: Library requirements
-
-## Risks and Mitigations
-
-### Technical Risks
-- **Risk 1**: Description and mitigation strategy
-- **Risk 2**: Description and mitigation strategy
-
-### AI Risks
-- **Risk 1**: AI accuracy or availability risk
-- **Risk 2**: AI cost or performance risk
-
-### Business Risks
-- **Risk 1**: User adoption or satisfaction risk
-- **Risk 2**: Competitive or market risk
-
-## Implementation Plan
-
-### Phase 1: Foundation
-- [ ] **Task 1**: Description and estimated effort
-- [ ] **Task 2**: Description and estimated effort
-
-### Phase 2: Core Implementation
-- [ ] **Task 1**: Description and estimated effort
-- [ ] **Task 2**: Description and estimated effort
-
-### Phase 3: Integration and Testing
-- [ ] **Task 1**: Description and estimated effort
-- [ ] **Task 2**: Description and estimated effort
-
-## Success Metrics
-
-### User Metrics
-- **Metric 1**: How success will be measured
-- **Metric 2**: How success will be measured
-
-### Technical Metrics
-- **Metric 1**: Performance or reliability metric
-- **Metric 2**: Performance or reliability metric
-
-### AI Metrics
-- **Metric 1**: AI accuracy or quality metric
-- **Metric 2**: AI cost or efficiency metric
-
-## Review and Acceptance Checklist
-
-### Specification Review
-- [ ] **Requirement Completeness**: All requirements clearly defined
-- [ ] **Technical Feasibility**: Implementation approach validated
-- [ ] **AI Integration**: AI capabilities and limitations understood
-- [ ] **User Experience**: UX flow and interactions defined
-
-### Technical Review
-- [ ] **Architecture Alignment**: Fits with existing system architecture
-- [ ] **Performance Impact**: Performance implications understood
-- [ ] **Security Review**: Security implications addressed
-- [ ] **Scalability**: Growth and scaling considerations addressed
-
-### Business Review
-- [ ] **User Value**: Clear value proposition for users
-- [ ] **Resource Requirements**: Development effort and costs estimated
-- [ ] **Timeline**: Realistic implementation timeline
-- [ ] **Success Criteria**: Clear definition of success
-
-