@ekkos/cli 1.3.1 → 1.3.5

package/templates/skills/ekkOS_Plan_Assist/Skill.md

@@ -1,302 +0,0 @@
----
-name: ekkOS_Plan_Assist
-description: Create structured plans for complex tasks. Activate when the user asks to implement a feature, build something with multiple steps, needs a project roadmap, or when a task has 3 or more distinct steps. This skill creates trackable plans with steps that can be marked complete.
-allowed-tools:
-  - mcp__ekkos-memory__ekkOS_Plan
-  - mcp__ekkos-memory__ekkOS_Plans
-  - mcp__ekkos-memory__ekkOS_PlanStatus
-  - mcp__ekkos-memory__ekkOS_PlanStep
-  - mcp__ekkos-memory__ekkOS_Generate
-  - mcp__ekkos-memory__ekkOS_Templates
-  - mcp__ekkos-memory__ekkOS_FromTemplate
-  - mcp__ekkos-memory__ekkOS_SaveTemplate
-  - mcp__ekkos-memory__ekkOS_Playbook
-  - mcp__ekkos-memory__ekkOS_Search
----
-
-# ekkOS_Plan_Assist
-
-You are augmented with **ekkOS_ memory** - and you can create, track, and manage structured implementation plans.
-
-## Why This Skill Exists
-
-Complex tasks need structure:
-- Multi-step implementations get lost without tracking
-- Progress should persist across sessions
-- Similar tasks can reuse templates
-
-This skill creates persistent, trackable plans.
-
-## When To Activate
-
-This skill should trigger when:
-
-| Trigger | Example |
-|---------|---------|
-| "Implement X" | "Implement user authentication" |
-| "Build X" | "Build a payment integration" |
-| "Help me with X" (complex) | "Help me refactor this service" |
-| "Create a plan for X" | Explicit request |
-| 3+ step task | Any task with multiple phases |
-| "What's the roadmap?" | Needs structured approach |
-
-## Instructions
-
-### Step 1: Check for Existing Plans
-
-```
-ekkOS_Plans({
-  status: "in_progress"
-})
-```
-
-If relevant plan exists, offer to continue it.
-
-### Step 2: Check for Templates
-
-```
-ekkOS_Templates({
-  category: "auth"  // or relevant category
-})
-```
-
-If template exists, use it as starting point.
-
-### Step 3: Create the Plan
-
-```
-ekkOS_Plan({
-  title: "Implement JWT Authentication",
-  steps: [
-    { label: "Set up auth dependencies", description: "Install jwt, bcrypt packages" },
-    { label: "Create user model", description: "Database schema for users" },
-    { label: "Implement registration", description: "POST /auth/register endpoint" },
-    { label: "Implement login", description: "POST /auth/login with JWT generation" },
-    { label: "Add middleware", description: "JWT verification middleware" },
-    { label: "Protect routes", description: "Apply middleware to protected endpoints" },
-    { label: "Add refresh tokens", description: "Token refresh logic" },
-    { label: "Write tests", description: "Auth flow integration tests" }
-  ],
-  context: "Building auth for the API project"
-})
-```
-
-### Step 4: Display the Plan
-
-```
-📋 Plan: Implement JWT Authentication
-
-□ Step 1: Set up auth dependencies
-  Install jwt, bcrypt packages
-
-□ Step 2: Create user model
-  Database schema for users
-
-□ Step 3: Implement registration
-  POST /auth/register endpoint
-
-... (remaining steps)
-
-Ready to start with Step 1?
-```
-
-### Step 5: Track Progress
-
-As you complete steps:
-
-```
-ekkOS_PlanStep({
-  plan_id: "plan-uuid",
-  step_index: 0,
-  completed: true
-})
-```
-
-Updated display:
-```
-📋 Plan: Implement JWT Authentication [2/8 complete]
-
-✓ Step 1: Set up auth dependencies
-✓ Step 2: Create user model
-→ Step 3: Implement registration (current)
-□ Step 4: Implement login
-...
-```
-
-## Example Scenarios
-
-### Scenario 1: New Feature
-```
-User: "Help me implement a payment system"
-
-You: *Check templates*
-     ekkOS_Templates({ category: "payments" })
-     → Template found: "Stripe Integration"
-
-     "I found a template for Stripe integration. Should I:
-      1. Use this template as starting point
-      2. Create a custom plan
-      3. See the template details first"
-
-User: "Use the template"
-
-You: ekkOS_FromTemplate({
-       template_id: "stripe-template-id",
-       context: "E-commerce payment integration"
-     })
-
-     "📋 Plan created from template:
-
-      □ Configure Stripe SDK
-      □ Create payment intent endpoint
-      □ Build checkout UI component
-      □ Handle webhooks
-      □ Implement refund logic
-      □ Add payment history
-      □ Write tests
-
-      Starting with Stripe SDK configuration..."
-```
-
-### Scenario 2: Continue Existing Plan
-```
-User: "What were we working on?"
-
-You: ekkOS_Plans({ status: "in_progress" })
-
-     "📋 You have an active plan:
-
-      **API Refactoring** [4/7 complete]
-      ✓ Extract user service
-      ✓ Extract auth service
-      ✓ Extract profile service
-      ✓ Update imports
-      → Create service interfaces (current)
-      □ Add dependency injection
-      □ Write integration tests
-
-      Continue with service interfaces?"
-```
-
-### Scenario 3: Plan from Scratch
-```
-User: "Build a notification system"
-
-You: ekkOS_Generate({
-       context: "Build real-time notification system with push, email, and in-app"
-     })
-
-     "I'll create a plan:
-
-      📋 Plan: Notification System
-
-      □ Step 1: Design notification schema
-        Database model for notifications
-
-      □ Step 2: Create notification service
-        Core logic for sending notifications
-
-      □ Step 3: Implement in-app notifications
-        WebSocket-based real-time delivery
-
-      □ Step 4: Add email notifications
-        Email template and delivery
-
-      □ Step 5: Add push notifications
-        FCM/APNs integration
-
-      □ Step 6: Build notification preferences
-        User settings for channels
-
-      □ Step 7: Create notification center UI
-        List and manage notifications
-
-      □ Step 8: Write tests
-        Unit and integration tests
-
-      Should I start with Step 1?"
-```
-
-### Scenario 4: Save as Template
-```
-*After completing a plan successfully*
-
-You: "This plan worked well. Save it as a template for future use?
-
-      ekkOS_SaveTemplate({
-        plan_id: "completed-plan-id",
-        category: "notifications"
-      })
-
-      ✅ Template saved: 'Notification System'
-      Category: notifications
-
-      Next time you build notifications, I can use this as a starting point."
-```
-
-## Plan Status Flow
-
-```
-draft → in_progress → completed
-                   ↘ archived (if abandoned)
-```
-
-Update status:
-```
-ekkOS_PlanStatus({
-  plan_id: "...",
-  status: "completed"  // or "archived"
-})
-```
-
-## Playbooks (Ordered Pattern Sequences)
-
-For workflows that use specific patterns in order:
-
-```
-ekkOS_Playbook({
-  action: "create",
-  name: "API Endpoint Creation",
-  pattern_ids: [
-    "route-pattern-id",
-    "validation-pattern-id",
-    "error-handling-pattern-id",
-    "test-pattern-id"
-  ],
-  description: "Standard flow for adding new API endpoints"
-})
-```
-
-Then use:
-```
-ekkOS_Playbook({
-  action: "get",
-  name: "API Endpoint Creation"
-})
-```
-
-## Integration with Patterns
-
-Search for patterns relevant to plan steps:
-
-```
-ekkOS_Search({
-  query: "JWT authentication implementation",
-  sources: ["patterns", "procedural"]
-})
-```
-
-Link patterns to plan steps for richer context.
-
-## Success Metrics
-
-You're using this skill correctly when:
-- Complex tasks are broken into steps
-- Progress persists across sessions
-- Templates speed up common tasks
-- Users can see their progress visually
-- Plans actually get completed (not abandoned)
-
----
-
-**Mantra**: More than 3 steps? Make a plan. Track it. Complete it.

package/templates/skills/ekkOS_Preferences/Skill.md

@@ -1,247 +0,0 @@
----
-name: ekkOS_Preferences
-description: Capture user preferences as permanent directives. Activate when the user says "always", "never", "I prefer", "I like", "don't", "avoid", expresses a coding style preference, states a workflow requirement, or corrects you about how they want things done. These become rules that apply to all future sessions.
-allowed-tools:
-  - mcp__ekkos-memory__ekkOS_Directive
-  - mcp__ekkos-memory__ekkOS_Search
----
-
-# ekkOS_Preferences
-
-You are augmented with **ekkOS_ memory** - and your job is to remember what this user PREFERS across all sessions.
-
-## Why This Skill Exists
-
-The SessionStart hook loads existing directives. This skill **CREATES** new directives when the user expresses preferences mid-conversation.
-
-**Directives are higher priority than patterns.** When a directive conflicts with a pattern, the directive wins.
-
-## Directive Types
-
-| Type | Meaning | Trigger Words |
-|------|---------|---------------|
-| **MUST** | Always do this | "always", "make sure to", "you must", "required" |
-| **NEVER** | Never do this | "never", "don't ever", "stop doing", "forbidden" |
-| **PREFER** | Do this when possible | "I prefer", "I like", "better if", "ideally" |
-| **AVOID** | Try not to do this | "avoid", "try not to", "don't usually", "minimize" |
-
-## When To Activate
-
-This skill should trigger when you detect:
-
-| Trigger | Example | Directive Type |
-|---------|---------|----------------|
-| "Always..." | "Always use TypeScript strict mode" | MUST |
-| "Never..." | "Never use var, only let/const" | NEVER |
-| "I prefer..." | "I prefer functional components" | PREFER |
-| "I like..." | "I like tabs over spaces" | PREFER |
-| "Don't..." | "Don't add comments to obvious code" | AVOID |
-| "Avoid..." | "Avoid inline styles" | AVOID |
-| Style correction | "No, use snake_case for this project" | MUST |
-| Workflow requirement | "Run tests before every commit" | MUST |
-
-## Instructions
-
-### Step 1: Detect Preference Statement
-
-Listen for language that indicates a preference:
-- Explicit: "I always want...", "Never do...", "I prefer..."
-- Implicit: "That's not how I like it", "Actually, use X instead"
-- Corrections: "No, do it this way", "Wrong style"
-
-### Step 2: Classify the Directive Type
-
-```
-"Always X"           → MUST
-"Never X"            → NEVER
-"I prefer X"         → PREFER
-"Try to avoid X"     → AVOID
-"Don't X unless..."  → AVOID (with condition)
-"You must always X"  → MUST (priority: high)
-```
-
-### Step 3: Create the Directive
-
-```
-ekkOS_Directive({
-  type: "MUST",                           // MUST | NEVER | PREFER | AVOID
-  rule: "Use TypeScript strict mode",     // The actual rule
-  scope: "global",                        // "global" | "project" | specific scope
-  reason: "User preference for type safety",  // Optional context
-  priority: 50                            // 1-100, higher = more important
-})
-```
-
-### Step 4: Confirm to User
-
-```
-🧠 Preference saved: [MUST] Use TypeScript strict mode
-   This will apply to all future sessions.
-```
-
-## Priority Guidelines
-
-| Priority | When to Use |
-|----------|-------------|
-| 80-100 | Critical rules, security-related, strong user insistence |
-| 50-79 | Standard preferences, coding style |
-| 20-49 | Nice-to-haves, soft preferences |
-| 1-19 | Weak suggestions, easily overridable |
-
-## Scope Guidelines
-
-| Scope | When to Use |
-|-------|-------------|
-| `"global"` | Applies everywhere (general preferences) |
-| `"project"` | Only this repository (project conventions) |
-| `"typescript"` | Only TypeScript files |
-| `"python"` | Only Python files |
-| `"frontend"` | Frontend code only |
-| `"backend"` | Backend code only |
-
-## Example Scenarios
-
-### Scenario 1: Explicit Preference
-```
-User: "I always want you to use arrow functions instead of function declarations"
-
-You: "Understood! I'll save this preference.
-
-      ekkOS_Directive({
-        type: "PREFER",
-        rule: "Use arrow functions instead of function declarations",
-        scope: "global",
-        reason: "User prefers arrow function syntax"
-      })
-
-      🧠 Preference saved: [PREFER] Use arrow functions instead of function declarations
-```
-
-### Scenario 2: Strong Prohibition
-```
-User: "NEVER commit directly to main. Always use feature branches."
-
-You: "Absolutely, that's a critical workflow rule.
-
-      ekkOS_Directive({
-        type: "NEVER",
-        rule: "Commit directly to main branch",
-        scope: "global",
-        priority: 90,
-        reason: "Protected branch workflow - user requirement"
-      })
-
-      ekkOS_Directive({
-        type: "MUST",
-        rule: "Use feature branches for all changes",
-        scope: "global",
-        priority: 90,
-        reason: "Protected branch workflow - user requirement"
-      })
-
-      🧠 Saved two directives:
-         [NEVER] Commit directly to main branch (priority: 90)
-         [MUST] Use feature branches for all changes (priority: 90)
-```
-
-### Scenario 3: Style Correction
-```
-User: "No, in this project we use PascalCase for component files, not kebab-case"
-
-You: "Got it, I'll remember that for this project.
-
-      ekkOS_Directive({
-        type: "MUST",
-        rule: "Use PascalCase for React component filenames",
-        scope: "project",
-        reason: "Project naming convention"
-      })
-
-      🧠 Project preference saved: [MUST] Use PascalCase for React component filenames
-```
-
-### Scenario 4: Soft Preference
-```
-User: "I kind of prefer shorter variable names when the context is clear"
-
-You: "Noted as a soft preference.
-
-      ekkOS_Directive({
-        type: "PREFER",
-        rule: "Use concise variable names when context is clear",
-        scope: "global",
-        priority: 30,
-        reason: "User prefers brevity over verbosity in obvious contexts"
-      })
-
-      🧠 Preference saved: [PREFER] Use concise variable names when context is clear
-```
-
-### Scenario 5: Avoiding Something
-```
-User: "Try to avoid using any type in TypeScript"
-
-You: "I'll make a note to avoid 'any'.
-
-      ekkOS_Directive({
-        type: "AVOID",
-        rule: "Using 'any' type in TypeScript",
-        scope: "typescript",
-        reason: "User wants strict typing"
-      })
-
-      🧠 Preference saved: [AVOID] Using 'any' type in TypeScript
-```
-
-## What NOT to Capture
-
-Don't create directives for:
-- One-time requests ("make this function shorter")
-- Context-specific instructions ("for this file, use X")
-- Questions ("should I use tabs or spaces?")
-- Unclear preferences ("maybe we should...")
-
-Only capture clear, generalizable preferences that should apply across sessions.
-
-## Checking Before Creating
-
-Before creating a new directive, optionally check if one already exists:
-
-```
-ekkOS_Search({
-  query: "variable naming convention",
-  sources: ["directives"]
-})
-```
-
-If a conflicting directive exists, ask the user:
-```
-"You previously said [PREFER] camelCase. Do you want to change this to PascalCase?"
-```
-
-## Integration with Patterns
-
-Directives override patterns when there's a conflict:
-
-```
-Pattern: "Use semicolons in JavaScript"
-Directive: [NEVER] Use semicolons in JavaScript
-
-→ Directive wins. No semicolons.
-```
-
-This is why capturing directives is important - they ensure patterns follow user preferences.
-
-## Success Metrics
-
-You're using this skill correctly when:
-- You capture preferences WITHOUT being asked to
-- You use the right directive type (MUST/NEVER/PREFER/AVOID)
-- You set appropriate scope (global vs project)
-- You confirm saves with the 🧠 indicator
-- User corrections become permanent rules
-- Future sessions automatically apply these preferences
-
----
-
-**Mantra**: User said "always"? Save it. User said "never"? Save it. User corrected you? Save the correction.