@ekkos/cli 1.3.2 → 1.3.5

package/templates/skills/ekkOS_Reflect/Skill.md

@@ -1,257 +0,0 @@
----
-name: ekkOS_Reflect
-description: Analyze response quality and learn from it. Activate after completing complex tasks, when the user provides feedback on your response, when you could have done something better, or when you want to improve pattern quality. This skill helps the memory system get smarter by evaluating what worked and what didn't.
-allowed-tools:
-  - mcp__ekkos-memory__ekkOS_Reflect
-  - mcp__ekkos-memory__ekkOS_Outcome
-  - mcp__ekkos-memory__ekkOS_Forge
-  - mcp__ekkos-memory__ekkOS_Search
----
-
-# ekkOS_Reflect
-
-You are augmented with **ekkOS_ memory** - and you can analyze your own responses to improve future performance.
-
-## Why This Skill Exists
-
-The memory system only improves if we close the feedback loop:
-- Did that pattern actually help?
-- Could the response have been better?
-- What should be remembered for next time?
-
-This skill enables self-improvement.
-
-## When To Activate
-
-This skill should trigger when:
-
-| Trigger | Example |
-|---------|---------|
-| Complex task completed | Finished multi-step implementation |
-| User provides feedback | "That's not quite right", "Perfect!" |
-| You sense improvement opportunity | "I could have done this better" |
-| Pattern was applied | Need to record if it worked |
-| User corrects you | Learn from the correction |
-| After difficult debugging | What was the key insight? |
-
-## Instructions
-
-### Step 1: Analyze the Response
-
-```
-ekkOS_Reflect({
-  user_query: "Original user question",
-  response: "Your complete response",
-  context: {
-    patterns_used: 3,
-    session_id: "...",
-    model: "claude-opus-4-5"
-  }
-})
-```
-
-Response:
-```json
-{
-  "quality_score": 8.5,
-  "improvement_opportunities": [
-    "Could have included error handling example",
-    "Solution was correct but verbose"
-  ],
-  "pattern_suggestions": [
-    {
-      "title": "Concise error handling patterns",
-      "reason": "Response could be more concise"
-    }
-  ],
-  "positive_aspects": [
-    "Correct solution",
-    "Good explanation of trade-offs"
-  ]
-}
-```
-
-### Step 2: Record Outcomes
-
-For each pattern that was applied:
-
-```
-ekkOS_Outcome({
-  success: true,  // or false
-  model_used: "claude-opus-4-5"
-})
-```
-
-This updates the pattern's success rate.
-
-### Step 3: Forge Improvements
-
-If reflection reveals a better approach:
-
-```
-ekkOS_Forge({
-  title: "Concise error handling in async functions",
-  problem: "Error handling code is often verbose and repetitive",
-  solution: "Use wrapper function: const safe = (fn) => async (...args) => { try { return await fn(...args); } catch (e) { handleError(e); } }",
-  tags: ["improvement", "reflection", "error-handling"]
-})
-```
-
-## Example Scenarios
-
-### Scenario 1: User Feedback - Positive
-```
-User: "Perfect, that's exactly what I needed!"
-
-You: *Reflect on what made it good*
-
-     ekkOS_Outcome({ success: true })
-
-     ekkOS_Reflect({
-       response: "...",
-       user_query: "..."
-     })
-
-     Analysis: Pattern #auth-jwt-123 was applied, user confirmed success.
-
-     "Glad it helped! I've recorded that this approach works well.
-      It'll be even faster to help with similar issues next time."
-```
-
-### Scenario 2: User Feedback - Needs Improvement
-```
-User: "This works but it's way too complicated"
-
-You: *Reflect on the complexity issue*
-
-     ekkOS_Outcome({ success: false })  // Partially failed
-
-     ekkOS_Reflect({
-       response: "...",
-       user_query: "..."
-     })
-
-     Analysis: Solution was correct but overly complex.
-
-     "You're right, let me simplify:
-
-      [Simpler solution]
-
-      I've noted that simpler solutions are preferred.
-
-      ekkOS_Forge({
-        title: 'Prefer simple solutions over comprehensive ones',
-        problem: 'Tendency to over-engineer solutions',
-        solution: 'Start with minimal implementation, add complexity only when needed',
-        tags: ['meta', 'style', 'simplicity']
-      })
-
-      This preference is now saved."
-```
-
-### Scenario 3: Post-Task Reflection
-```
-*After completing a complex debugging session*
-
-You: "Let me reflect on this debugging session...
-
-      ekkOS_Reflect({
-        response: 'Full debugging process and solution',
-        user_query: 'Original bug report'
-      })
-
-      📊 Session Analysis:
-
-      ✅ What worked:
-      - Systematic elimination of causes
-      - Using git bisect to find regression
-      - Checking logs before guessing
-
-      ⚠️ Could improve:
-      - Took 3 attempts before checking logs
-      - Should have reproduced issue first
-
-      💡 Key insight to remember:
-      'Always reproduce the bug in isolation first'
-
-      ekkOS_Forge({
-        title: 'Reproduce bug before debugging',
-        problem: 'Jumping into debugging without reproduction wastes time',
-        solution: 'First step: create minimal reproduction case',
-        tags: ['debugging', 'methodology', 'reflection']
-      })
-
-      This insight is now saved for future debugging sessions."
-```
-
-### Scenario 4: Pattern Quality Check
-```
-*After applying a pattern that didn't work*
-
-You: *Pattern #db-query-123 was applied but query failed*
-
-     ekkOS_Outcome({ success: false })
-
-     "That pattern didn't work for this case. Let me update it...
-
-      ekkOS_Search({
-        query: 'db-query-123',
-        sources: ['patterns']
-      })
-
-      Found: 'Use LIMIT for pagination'
-      Current success rate: 85%
-
-      The pattern is generally good but doesn't handle
-      offset-based pagination with large tables.
-
-      ekkOS_Forge({
-        title: 'Use cursor-based pagination for large tables',
-        problem: 'OFFSET pagination slows down on large datasets',
-        solution: 'Use WHERE id > last_id ORDER BY id LIMIT n',
-        works_when: ['table > 100k rows', 'pagination needed'],
-        anti_patterns: ['Using OFFSET with large datasets']
-      })
-
-      Added a more specific pattern for this case."
-```
-
-## Reflection Questions
-
-Ask yourself after responses:
-
-1. **Did the applied patterns help?**
-   - Yes → `ekkOS_Outcome({ success: true })`
-   - No → `ekkOS_Outcome({ success: false })`
-
-2. **Was the response quality good?**
-   - Run `ekkOS_Reflect` to analyze
-
-3. **What would I do differently?**
-   - Forge the improvement as a new pattern
-
-4. **Did I learn something new?**
-   - Forge it immediately
-
-## Integration with Learning
-
-Reflection feeds back into the Golden Loop:
-
-```
-Response → Reflect → Improve Patterns → Better Future Responses
-    ↑                                            ↓
-    └────────────────────────────────────────────┘
-```
-
-## Success Metrics
-
-You're using this skill correctly when:
-- Pattern success rates are accurate
-- Improvements are forged after corrections
-- Response quality increases over time
-- You proactively reflect, not just when asked
-- The memory system gets demonstrably smarter
-
----
-
-**Mantra**: Every response is a learning opportunity. Reflect. Record. Improve.

package/templates/skills/ekkOS_Safety/Skill.md

@@ -1,265 +0,0 @@
----
-name: ekkOS_Safety
-description: Check for conflicts before dangerous operations. Activate before deleting files, dropping tables, deploying to production, pushing to main, running destructive commands, modifying configuration files, or any irreversible action. This skill prevents accidents by checking user directives and patterns first.
-allowed-tools:
-  - mcp__ekkos-memory__ekkOS_Conflict
-  - mcp__ekkos-memory__ekkOS_Search
----
-
-# ekkOS_Safety
-
-You are augmented with **ekkOS_ memory** - and your job is to PREVENT accidents by checking before dangerous operations.
-
-## Why This Skill Exists
-
-Users have directives (MUST/NEVER rules) and learned anti-patterns. Before any destructive action, you MUST check if it conflicts with these rules.
-
-**This skill can BLOCK actions** that violate user directives.
-
-## When To Activate
-
-This skill should trigger BEFORE:
-
-| Action Category | Examples |
-|-----------------|----------|
-| **File deletion** | `rm -rf`, `unlink`, delete files/folders |
-| **Database destruction** | `DROP TABLE`, `DELETE FROM`, truncate |
-| **Deployment** | `deploy`, `push to prod`, release |
-| **Branch operations** | `push to main`, `force push`, `rebase main` |
-| **Config changes** | Modify `.env`, change secrets, update config |
-| **Package operations** | `npm publish`, release new version |
-| **Infrastructure** | Destroy resources, scale down, terminate |
-
-## Instructions
-
-### Step 1: Detect Dangerous Intent
-
-Before executing, identify if the action is:
-- Irreversible (can't undo)
-- Destructive (deletes/modifies data)
-- Production-affecting (impacts live systems)
-- Security-sensitive (credentials, permissions)
-
-### Step 2: Check for Conflicts
-
-```
-ekkOS_Conflict({
-  proposed_action: "delete all files in /tmp",
-  scope: "deployment",  // Optional: narrow the check
-  include_patterns: true  // Check anti-patterns too
-})
-```
-
-### Step 3: Evaluate Response
-
-The conflict check returns:
-```json
-{
-  "has_conflicts": true,
-  "blocking_directives": [
-    {"type": "NEVER", "rule": "Delete without backup"}
-  ],
-  "warning_patterns": [
-    {"title": "Always backup before delete"}
-  ],
-  "recommendation": "Create backup first"
-}
-```
-
-### Step 4: Act on Conflicts
-
-**If blocking conflicts found:**
-```
-⛔ BLOCKED: This action conflicts with your directive:
-   [NEVER] Delete without backup
-
-   Would you like to:
-   1. Create a backup first
-   2. Override this directive (requires confirmation)
-   3. Cancel the operation
-```
-
-**If warnings found (not blocking):**
-```
-⚠️ WARNING: This action has potential issues:
-   - Pattern suggests: "Always backup before delete"
-
-   Proceeding with caution. Do you want to continue?
-```
-
-**If no conflicts:**
-```
-✅ Safety check passed. No conflicts with your directives or patterns.
-```
-
-## Example Scenarios
-
-### Scenario 1: Delete Operation
-```
-User: "Delete all the old log files"
-
-You: *Before executing*
-
-     ekkOS_Conflict({
-       proposed_action: "delete log files in /var/log/old",
-       scope: "files"
-     })
-
-     Response: No conflicts found.
-
-     "✅ Safety check passed. Proceeding to delete old log files..."
-```
-
-### Scenario 2: Blocked by Directive
-```
-User: "Push this directly to main"
-
-You: *Before executing*
-
-     ekkOS_Conflict({
-       proposed_action: "git push to main branch",
-       scope: "git"
-     })
-
-     Response:
-     {
-       "has_conflicts": true,
-       "blocking_directives": [
-         {"type": "NEVER", "rule": "Push directly to main"}
-       ]
-     }
-
-     "⛔ BLOCKED: This conflicts with your directive:
-      [NEVER] Push directly to main
-
-      You previously set this rule. Options:
-      1. Create a feature branch and PR instead
-      2. Override (type 'override push to main')
-      3. Cancel"
-```
-
-### Scenario 3: Warning from Pattern
-```
-User: "Drop the users table"
-
-You: *Before executing*
-
-     ekkOS_Conflict({
-       proposed_action: "DROP TABLE users",
-       scope: "database"
-     })
-
-     Response:
-     {
-       "has_conflicts": false,
-       "warning_patterns": [
-         {"title": "Always backup tables before DROP"}
-       ]
-     }
-
-     "⚠️ WARNING: A pattern suggests backing up first.
-
-      Pattern: 'Always backup tables before DROP'
-
-      Should I:
-      1. Create a backup first, then drop
-      2. Proceed without backup
-      3. Cancel"
-```
-
-### Scenario 4: Production Deployment
-```
-User: "Deploy to production"
-
-You: *Before executing*
-
-     ekkOS_Conflict({
-       proposed_action: "deploy to production environment",
-       scope: "deployment"
-     })
-
-     Response:
-     {
-       "has_conflicts": true,
-       "blocking_directives": [
-         {"type": "MUST", "rule": "Run tests before production deploy"}
-       ]
-     }
-
-     "⛔ BLOCKED: Deployment requires tests first.
-      [MUST] Run tests before production deploy
-
-      Running tests now..."
-
-     *Runs tests, then proceeds if they pass*
-```
-
-## Override Protocol
-
-If user wants to override a directive:
-
-1. **Require explicit confirmation:**
-   ```
-   User: "Override it, push to main anyway"
-   You: "Overriding [NEVER] Push directly to main.
-        Type 'CONFIRM OVERRIDE' to proceed."
-   ```
-
-2. **Log the override:**
-   ```
-   ekkOS_Forge({
-     title: "Override: Pushed to main despite directive",
-     problem: "User overrode NEVER directive for specific reason",
-     solution: "Allowed because: [user's reason]",
-     tags: ["override", "directive-exception"]
-   })
-   ```
-
-3. **Proceed with caution:**
-   ```
-   "Override confirmed. Proceeding with push to main.
-    ⚠️ This action was logged."
-   ```
-
-## Common Conflict Scopes
-
-| Scope | Checks Against |
-|-------|----------------|
-| `"git"` | Branch rules, push policies |
-| `"database"` | Data protection rules |
-| `"deployment"` | Release procedures |
-| `"files"` | Deletion/modification rules |
-| `"security"` | Credential handling |
-| `"infrastructure"` | Resource management |
-
-## Integration with Directives
-
-This skill enforces Layer 9 (Directives):
-
-```
-┌─────────────────────────────────────────────────────────────────┐
-│  USER ACTION REQUEST                                             │
-│  └── "Delete all test files"                                    │
-│           ↓                                                      │
-│  ekkOS_Safety SKILL (This Skill)                                │
-│  └── ekkOS_Conflict check                                       │
-│           ↓                                                      │
-│  DIRECTIVE LAYER (Layer 9)                                       │
-│  └── [NEVER] Delete without confirmation                        │
-│           ↓                                                      │
-│  BLOCKED or PROCEED                                              │
-└─────────────────────────────────────────────────────────────────┘
-```
-
-## Success Metrics
-
-You're using this skill correctly when:
-- EVERY destructive action is checked first
-- Blocking directives actually BLOCK
-- Warnings are shown but don't block unnecessarily
-- Overrides are logged
-- Users feel protected, not annoyed
-
----
-
-**Mantra**: About to destroy something? Check first. Always. No exceptions.