@ekkos/cli 0.2.0

package/templates/skills/ekkOS_Safety/Skill.md

@@ -0,0 +1,265 @@
+---
+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.

package/templates/skills/ekkOS_Schema/Skill.md

@@ -0,0 +1,251 @@
+---
+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.