cokit-cli 1.2.7 → 1.4.0

package/skills/cook/references/workflow-steps.md

@@ -1,140 +0,0 @@
-# Unified Workflow Steps
-
-All modes share core steps with mode-specific variations.
-
-## Step 0: Intent Detection & Setup
-
-1. Parse input with `intent-detection.md` rules
-2. Log detected mode: `✓ Step 0: Mode [X] - [reason]`
-3. If mode=code: detect plan path, set active plan
-4. Use TaskCreate to create workflow step tasks (with dependencies if complex)
-
-**Output:** `✓ Step 0: Mode [interactive|auto|fast|parallel|no-test|code] - [detection reason]`
-
-## Step 1: Research (skip if fast/code mode)
-
-**Interactive/Auto:**
-- Spawn multiple `researcher` agents in parallel
-- Use `/scout:ext` or `scout` agent for codebase search
-- Keep reports ≤150 lines
-
-**Parallel:**
-- Optional: max 2 researchers if complex
-
-**Output:** `✓ Step 1: Research complete - [N] reports gathered`
-
-### [Review Gate 1] Post-Research (skip if auto mode)
-- Present research summary to user
-- Ask user: "Proceed to planning?" / "Request more research" / "Abort" — then wait for response
-- **Auto mode:** Skip this gate
-
-## Step 2: Planning
-
-**Interactive/Auto/No-test:**
-- Use `planner` agent with research context
-- Create `plan.md` + `phase-XX-*.md` files
-
-**Fast:**
-- Use `/plan:fast` with scout results only
-- Minimal planning, focus on action
-
-**Parallel:**
-- Use `/plan:parallel` for dependency graph + file ownership matrix
-
-**Code:**
-- Skip - plan already exists
-- Parse existing plan for phases
-
-**Output:** `✓ Step 2: Plan created - [N] phases`
-
-### [Review Gate 2] Post-Plan (skip if auto mode)
-- Present plan overview with phases
-- Ask user: "Approve plan and start implementation?" / "Request revisions" / "Abort" — then wait for response
-- **Auto mode:** Skip this gate
-
-## Step 3: Implementation
-
-**All modes:**
-- Execute phase tasks sequentially (Step 3.1, 3.2, etc.)
-- Use `ui-ux-designer` for frontend
-- Use ImageMagick/FFmpeg CLI for image assets
-- Run type checking after each file
-
-**Parallel mode:**
-- Launch multiple `fullstack-developer` agents
-- Respect file ownership boundaries
-- Wait for parallel group before next
-
-**Output:** `✓ Step 3: Implemented [N] files - [X/Y] tasks complete`
-
-### [Review Gate 3] Post-Implementation (skip if auto mode)
-- Present implementation summary (files changed, key changes)
-- Ask user: "Proceed to testing?" / "Request implementation changes" / "Abort" — then wait for response
-- **Auto mode:** Skip this gate
-
-## Step 4: Testing (skip if no-test mode)
-
-**All modes (except no-test):**
-- Write tests: happy path, edge cases, errors
-- Use `tester` agent
-- If failures: `debugger` → fix → repeat
-- **Forbidden:** fake mocks, commented tests, changed assertions
-
-**Output:** `✓ Step 4: Tests [X/X passed]`
-
-### [Review Gate 4] Post-Testing (skip if auto mode)
-- Present test results summary
-- Ask user: "Proceed to code review?" / "Request test fixes" / "Abort" — then wait for response
-- **Auto mode:** Skip this gate
-
-## Step 5: Code Review
-
-**Interactive/Parallel/Code/No-test:**
-- Use `code-reviewer` agent
-- Interactive cycle (max 3): see `review-cycle.md`
-- Requires user approval
-
-**Auto:**
-- Auto-approve if score≥9.5 AND 0 critical
-- Auto-fix critical (max 3 cycles)
-- Escalate to user after 3 failed cycles
-
-**Fast:**
-- Simplified review, no fix loop
-- User approves or aborts
-
-**Output:** `✓ Step 5: Review [score]/10 - [Approved|Auto-approved]`
-
-## Step 6: Finalize
-
-**All modes:**
-1. `project-manager` + `docs-manager` agents in parallel
-2. Onboarding check (API keys, env vars)
-3. Auto-commit via `git-manager` agent
-
-**Auto mode:** Continue to next phase automatically
-**Others:** Ask user before next phase
-
-**Output:** `✓ Step 6: Finalized - Status updated - Committed`
-
-## Mode-Specific Flow Summary
-
-Legend: `[R]` = Review Gate (human approval required)
-
-```
-interactive: 0 → 1 → [R] → 2 → [R] → 3 → [R] → 4 → [R] → 5(user) → 6
-auto:        0 → 1 → 2 → 3 → 4 → 5(auto) → 6 → next phase (NO stops)
-fast:        0 → skip → 2(fast) → [R] → 3 → [R] → 4 → [R] → 5(simple) → 6
-parallel:    0 → 1? → [R] → 2(parallel) → [R] → 3(multi-agent) → [R] → 4 → [R] → 5(user) → 6
-no-test:     0 → 1 → [R] → 2 → [R] → 3 → [R] → skip → 5(user) → 6
-code:        0 → skip → skip → 3 → [R] → 4 → [R] → 5(user) → 6
-```
-
-**Key difference:** `auto` mode is the ONLY mode that skips all review gates.
-
-## Critical Rules
-
-- Never skip steps without mode justification
-- Use TaskUpdate to mark tasks complete immediately
-- One task in_progress at a time (enforce via TaskList check)
-- All step outputs follow format: `✓ Step [N]: [status] - [metrics]`

package/skills/databases/SKILL.md

@@ -1,111 +0,0 @@
----
-name: databases
-description: Design schemas, write queries for MongoDB, PostgreSQL, SQL Server. Use for database design, SQL/NoSQL queries, aggregation pipelines, indexes, migrations, replication, performance optimization, psql CLI, EF Core.
----
-
-# Databases Skill
-
-Unified guide for working with MongoDB (document-oriented) and PostgreSQL (relational) databases. Choose the right database for your use case and master both systems.
-
-## When to Use This Skill
-
-Use when:
-- Designing database schemas and data models
-- Writing queries (SQL or MongoDB query language)
-- Building aggregation pipelines or complex joins
-- Optimizing indexes and query performance
-- Implementing database migrations
-- Setting up replication, sharding, or clustering
-- Configuring backups and disaster recovery
-- Managing database users and permissions
-- Analyzing slow queries and performance issues
-- Administering production database deployments
-
-## Reference Navigation
-
-### Database Design
-- **[db-design.md](references/db-design.md)** - Activate when user requests: Database/table design for transactional (OLTP), analytics (OLAP), create or extend schema, design fact/dimension tables, analyze/review CSV/JSON/SQL files to create tables, or need advice on data storage structure.
-
-### MongoDB References
-- **[mongodb-crud.md](references/mongodb-crud.md)** - CRUD operations, query operators, atomic updates
-- **[mongodb-aggregation.md](references/mongodb-aggregation.md)** - Aggregation pipeline, stages, operators, patterns
-- **[mongodb-indexing.md](references/mongodb-indexing.md)** - Index types, compound indexes, performance optimization
-- **[mongodb-atlas.md](references/mongodb-atlas.md)** - Atlas cloud setup, clusters, monitoring, search
-
-### PostgreSQL References
-- **[postgresql-queries.md](references/postgresql-queries.md)** - SELECT, JOINs, subqueries, CTEs, window functions
-- **[postgresql-psql-cli.md](references/postgresql-psql-cli.md)** - psql commands, meta-commands, scripting
-- **[postgresql-performance.md](references/postgresql-performance.md)** - EXPLAIN, query optimization, vacuum, indexes
-- **[postgresql-administration.md](references/postgresql-administration.md)** - User management, backups, replication, maintenance
-
-## Python Utilities
-
-Database utility scripts in `scripts/`:
-- **db_migrate.py** - Generate and apply migrations for both databases (MongoDB and PostgreSQL)
-- **db_backup.py** - Backup and restore MongoDB and PostgreSQL
-- **db_performance_check.py** - Analyze slow queries and recommend indexes
-
-```bash
-# Generate migration
-python scripts/db_migrate.py --db mongodb --generate "add_user_index"
-
-# Run backup
-python scripts/db_backup.py --db postgres --output /backups/
-
-# Check performance
-python scripts/db_performance_check.py --db mongodb --threshold 100ms
-```
-
-## Best Practices
-
-**MongoDB:**
-- Use embedded documents for 1-to-few relationships
-- Reference documents for 1-to-many or many-to-many
-- Index frequently queried fields
-- Use aggregation pipeline for complex transformations
-- Enable authentication and TLS in production
-- Use Atlas for managed hosting
-
-**PostgreSQL:**
-- Normalize schema to 3NF, denormalize for performance
-- Use foreign keys for referential integrity
-- Index foreign keys and frequently filtered columns
-- Use EXPLAIN ANALYZE to optimize queries
-- Regular VACUUM and ANALYZE maintenance
-- Connection pooling (pgBouncer) for web apps
-
-## .NET / Entity Framework Core
-
-For .NET projects, use Entity Framework Core with PostgreSQL or SQL Server:
-
-```csharp
-// DbContext configuration
-public class AppDbContext : DbContext
-{
-    public DbSet<User> Users => Set<User>();
-    public DbSet<Post> Posts => Set<Post>();
-
-    protected override void OnConfiguring(DbContextOptionsBuilder options)
-        => options.UseNpgsql("Host=localhost;Database=mydb;Username=user;Password=pass");
-        // Or: options.UseSqlServer(connectionString);
-}
-
-// Migrations
-// dotnet ef migrations add InitialCreate
-// dotnet ef database update
-
-// Query with LINQ
-var activeUsers = await _context.Users
-    .Where(u => u.IsActive)
-    .Include(u => u.Posts)
-    .ToListAsync();
-```
-
-## Resources
-
-- MongoDB: https://www.mongodb.com/docs/
-- PostgreSQL: https://www.postgresql.org/docs/
-- SQL Server: https://learn.microsoft.com/sql/
-- Entity Framework Core: https://learn.microsoft.com/ef/core/
-- MongoDB University: https://learn.mongodb.com/
-- PostgreSQL Tutorial: https://www.postgresqltutorial.com/

package/skills/databases/db-design.md

@@ -1,188 +0,0 @@
----
-name: db-design
-description: "Activate when user requests: Database/table design for transactional (OLTP), analytics (OLAP), create or extend schema, design fact/dimension tables, analyze/review CSV/JSON/SQL files to create tables, or need advice on data storage structure."
----
-
-# SKILL: Database Schema Design
-
-## Execution Process
-
-### Step 1: Analyze Context (MANDATORY)
-
-Before ANY design work, AI MUST check:
-
-- [ ] Database stack identified? (MySQL / PostgreSQL / BigQuery / SQLite / D1)
-- [ ] Existing schema explored via tools/MCP?
-- [ ] Use case clear? (transactional vs analytics vs ETL)
-
-**If ANY checkbox is unclear → STOP and ask user before proceeding.**
-
-### Step 2: Gather Requirements
-
-**MUST ask if missing:**
-
-| Missing Info | Required Question |
-|--------------|-------------------|
-| Entities unclear | "What are the main entities involved in this feature?" |
-| Query patterns unknown | "What queries/reports will run most often?" |
-| Granularity unclear | "What level of detail needed? (per order, per item, per day)" |
-| Constraints unknown | "Any uniqueness, retention, or multi-tenant requirements?" |
-| Relationships unclear | "How do these entities relate to each other?" |
-
-**DO NOT assume or proceed without answers. DO NOT design schema without understanding the business context.**
-
-### Step 3: Load Documentation by Intent
-
-| Intent | Keywords | Load file |
-|--------|----------|-----------|
-| **OLTP** | "business tables", "transactional", "CRUD", "orders", "users" | [transactional.md](transactional.md) |
-| **OLAP** | "analytics", "statistics", "reports", "fact", "dimension" | [analytics.md](analytics.md) |
-| **ETL** | "incremental", "load", "sync", "watermark", "etl" | [incremental-etl.md](incremental-etl.md) |
-
-**Database stacks:** [MySQL](stacks/mysql.md) · [PostgreSQL](stacks/postgres.md) · [BigQuery](stacks/bigquery.md) · [SQLite](stacks/sqlite.md) · [D1 Cloudflare](stacks/d1_cloudflare.md)
-
-### Step 4: Design & Propose
-
-Only after Steps 1-3 complete:
-- Propose DDL with reasoning
-- **Wait for user approval before execution**
-- Never auto-execute DDL
-
-### Step 5: Verify Checklist
-
-Before delivering final DDL, verify the **Final Checklist** at the end of this file.
-
----
-
-## Scope & Objectives
-
-Design or extend database schemas ensuring:
-
-- Consistent, understandable, maintainable data structures
-- Good performance with appropriate indexes
-- Design that fits existing tables (avoid duplication, avoid breaking logic)
-
----
-
-## Naming Conventions
-
-### Table naming
-
-- Use **snake_case**, English, plural for main entities:
-  - `users`, `orders`, `order_items`, `product_variants`
-- Junction/mapping tables:
-  - `role_permissions`, `user_roles`, `product_categories`
-- Fact & dimension tables (analytics):
-  - Fact: `fact_orders`, `fact_order_items`, `fact_pageviews`
-  - Dimension: `dim_date`, `dim_customer`, `dim_product`, `dim_store`
-- Avoid unclear abbreviations:
-  - ❌ `usr`, `ord`, `inv_tx`
-  - ✅ `users`, `orders`, `inventory_transactions`
-
-### Column naming
-
-- Use **snake_case**, clear meaning, consistent across tables
-- **Primary key**: `id` (main PK of table)
-- **Foreign key**: `xxx_id` pointing to table `xxx`:
-  - `user_id` → `users.id`
-  - `order_id` → `orders.id`
-- **Audit & lifecycle**:
-  - `created_at`, `updated_at`, `deleted_at` (soft delete)
-- **Boolean flags**:
-  - `is_active`, `is_deleted`, `is_primary`, `is_verified`
-- **Quantities & prices**:
-  - `quantity`, `unit_price`, `total_price`, `discount_amount`, `tax_amount`
-- **Time ranges**:
-  - `start_at`, `end_at` or `valid_from`, `valid_to` (pick one convention and use consistently)
-- **Enum/state**:
-  - `status` (combine with ENUM / CHECK constraint)
-
----
-
-## Workflow
-
-### 1. Understand business requirements
-
-- Summarize requirements in your own words
-- If missing context, ask:
-  - What entities are involved?
-  - What is the main business flow?
-  - What queries/reports are commonly used?
-
-### 2. Explore existing schema (MANDATORY before proposing)
-
-- Use tools/MCP to list tables and describe structure
-- For DBs with comments (MySQL/PostgreSQL/BigQuery): read comments directly
-- For SQLite/D1: query `metadata_tables` and `metadata_columns` tables
-
-### 3. Analyze and propose draft
-
-- Which tables already partially cover requirements?
-- Which tables need additional columns/indexes?
-- Which tables are completely missing (need to create)?
-
-### 4. Confirm with user before finalizing design
-
-- Required granularity
-- Metrics to calculate
-- Important business constraints (uniqueness, retention, privacy)
-
-### 5. Design detailed schema
-
-- Provide proposed DDL - **do NOT auto-execute**
-- Wait for user approval before execution
-
----
-
-## Processing Data Files (CSV/JSON/SQL)
-
-When user provides files:
-
-1. **Read and identify structure**: headers, data types, relationships
-2. **Large files**: write Python script to parse and analyze
-3. **SQL files**: review naming, indexes, constraints, propose improvements
-4. **Output**: Proposed DDL with reasoning
-
----
-
-## Output Format
-
-When delivering design results:
-
-1. **Summary**: list of new tables / tables to modify
-2. **Complete DDL SQL**: columns, types, PK, FK, indexes, comments
-3. **Reasoning**: explain why this structure/index was chosen, tied to actual queries
-
----
-
-## Final Checklist
-
-Before delivering final DDL:
-
-- [ ] Explored existing schema via tools/MCP
-- [ ] No duplicate tables with existing schema
-- [ ] All FKs have indexes
-- [ ] Composite indexes match main query patterns
-- [ ] Naming convention consistent with existing schema
-- [ ] Added comments/descriptions for tables and columns
-- [ ] For SQLite/D1: prepared INSERTs for metadata tables
-- [ ] Explained reasoning for important design decisions
-
----
-
-## File Structure
-
-```
-$HOME/.copilot/skills/databases/
-├── SKILL.md                  # Skill description (entry + execution process + checklist)
-├── db-design.md              # This file 
-├── transactional.md          # OLTP design rules
-├── analytics.md              # OLAP / Star Schema rules
-├── incremental-etl.md        # ETL & watermark patterns
-└── stacks/
-    ├── mysql.md              # MySQL-specific rules
-    ├── postgres.md           # PostgreSQL-specific rules
-    ├── bigquery.md           # BigQuery-specific rules
-    ├── sqlite.md             # SQLite-specific rules
-    └── d1_cloudflare.md      # D1 Cloudflare-specific rules
-```

package/skills/debug/SKILL.md

@@ -1,178 +0,0 @@
----
-name: debug
-description: Debug systematically with root cause analysis before fixes. Covers bugs, test failures, log analysis, CI/CD failures, database diagnostics, system investigation, performance issues, call stack tracing, multi-layer validation.
----
-
-# Debugging & System Investigation
-
-Comprehensive debugging framework combining systematic investigation, root cause tracing, defense-in-depth validation, verification protocols, and system-level diagnostics.
-
-## Core Principle
-
-**NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST**
-
-Random fixes waste time and create new bugs. Find the root cause, fix at source, validate at every layer, verify before claiming success.
-
-## When to Use
-
-**Code-level:** Test failures, bugs, unexpected behavior, build failures, integration problems, before claiming work complete
-
-**System-level:** CI/CD pipeline failures, log analysis, database diagnostics, performance bottlenecks, infrastructure issues
-
-**Especially when:** Under time pressure, "quick fix" seems obvious, tried multiple fixes, don't fully understand issue, about to claim success
-
-## Techniques
-
-### 1. Systematic Debugging (`references/systematic-debugging.md`)
-
-Four-phase framework:
-- Phase 1: Root Cause Investigation (read errors, reproduce, check changes, gather evidence)
-- Phase 2: Pattern Analysis (find working examples, compare, identify differences)
-- Phase 3: Hypothesis and Testing (form theory, test minimally, verify)
-- Phase 4: Implementation (create test, fix once, verify)
-
-Complete each phase before proceeding. No fixes without Phase 1.
-
-**Load when:** Any bug/issue requiring investigation and fix
-
-### 2. Root Cause Tracing (`references/root-cause-tracing.md`)
-
-Trace bugs backward through call stack to find original trigger. Fix at source, not at symptom.
-
-**Includes:** `scripts/find-polluter.sh` for bisecting test pollution
-
-**Load when:** Error deep in call stack, unclear where invalid data originated
-
-### 3. Defense-in-Depth (`references/defense-in-depth.md`)
-
-Validate at every layer data passes through. Four layers: Entry validation → Business logic → Environment guards → Debug instrumentation
-
-**Load when:** After finding root cause, need to add comprehensive validation
-
-### 4. Verification (`references/verification.md`)
-
-Run verification commands and confirm output before claiming success.
-
-**Iron law:** NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
-
-**Load when:** About to claim work complete, fixed, or passing
-
-### 5. Investigation Methodology
-
-For system-level issues (CI/CD, infrastructure, data pipeline):
-
-1. **Scope** - Define what is broken and what is working
-2. **Gather** - Collect logs, metrics, error outputs before touching anything
-3. **Isolate** - Narrow to smallest reproducible case
-4. **Hypothesize** - Form one theory, test it, reject or confirm
-5. **Fix & Validate** - Fix at root, verify at every affected layer
-
-**Load when:** Issue is not code-local — spans services, environments, or pipelines
-
-### 6. Log & CI/CD Analysis
-
-Use `gh` CLI and structured queries to diagnose pipeline failures:
-
-```bash
-# View failed CI run logs
-gh run view <run-id> --log-failed
-
-# List recent runs for a workflow
-gh run list --workflow=<name> --limit 10
-
-# Watch a running workflow
-gh run watch <run-id>
-```
-
-For structured logs: filter by severity, timestamp range, and correlation ID before reading raw output.
-
-**Load when:** CI/CD failure, deployment issue, or log-driven investigation
-
-### 7. Performance Diagnostics
-
-Identify bottlenecks before optimizing:
-- Profile first — measure before guessing
-- Check slow queries with `EXPLAIN ANALYZE` (PostgreSQL) or equivalent
-- Identify N+1 query patterns in ORM usage
-- Check memory allocation patterns for leaks
-- Use `psql` for live database diagnostics
-
-**Load when:** Slowness reported, timeout errors, resource exhaustion
-
-### 8. Reporting Standards
-
-For multi-component investigations, write a structured diagnostic report:
-
-```
-## Diagnostic Report
-- **Issue:** [one-line description]
-- **Root Cause:** [where and why it fails]
-- **Evidence:** [logs, output, reproduction steps]
-- **Fix Applied:** [what was changed]
-- **Verification:** [command run + result]
-- **Remaining Risk:** [any open questions]
-```
-
-Save to `plans/reports/debugger-{date}-{slug}.md`.
-
-**Load when:** Investigation spans multiple components or will be shared with others
-
-### 9. Task Management
-
-For multi-component investigations, track progress with a checklist rather than holding state mentally:
-
-```
-- [ ] Reproduce the issue
-- [ ] Identify root cause
-- [ ] Fix applied
-- [ ] Tests passing
-- [ ] Verification complete
-```
-
-Add this checklist to the active plan or investigation report. Check items off as each step completes.
-
-**Load when:** Investigation touches 3+ components or files
-
-### 10. Frontend Verification
-
-For visual bugs or UI regressions, use browser developer tools (or the `agent-browser` skill) to inspect rendering, network, and console errors directly in the browser.
-
-Use `/ck-scout ext` to search for frontend-specific patterns before diving into devtools.
-
-**Load when:** Visual regression, layout bug, client-side network error, or UI behavior that differs from expected
-
-## Quick Reference
-
-```
-Code bug → systematic-debugging.md (Phase 1-4)
-  Error deep in stack? → root-cause-tracing.md (trace backward)
-  Found root cause? → defense-in-depth.md (add layers)
-  About to claim success? → verification.md (verify first)
-
-System issue → Investigation Methodology (5 steps)
-  CI/CD failure? → Log & CI/CD Analysis (gh CLI)
-  Slow/timeout? → Performance Diagnostics
-  Multi-component? → Task Management checklist + Reporting Standards
-  Visual/UI bug? → Frontend Verification (agent-browser / browser devtools)
-```
-
-## Tools Integration
-
-| Tool | Use Case |
-|------|----------|
-| `execute` | Run test commands, build scripts, verification steps |
-| `gh` CLI | CI/CD log analysis, PR checks, workflow runs |
-| `psql` | Live database diagnostics and slow query analysis |
-| `agent-browser` skill | Frontend visual verification and network inspection |
-| `/ck-scout` | Search codebase for related patterns before investigating |
-
-## Red Flags
-
-Stop and follow process if thinking:
-- "Quick fix for now, investigate later"
-- "Just try changing X and see if it works"
-- "It's probably X, let me fix that"
-- "Should work now" / "Seems fixed"
-- "Tests pass, we're done"
-
-**All mean:** Return to systematic process.