cokit-cli 1.2.7 → 1.4.0

package/templates/repo/.github/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/templates/repo/.github/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/templates/repo/.github/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/templates/repo/.github/skills/databases/stacks/bigquery.md

@@ -1,231 +0,0 @@
-# BigQuery Rules
-
-Guidelines for designing schemas specific to Google BigQuery.
-
----
-
-## Data Types
-
-| Use case | Type | Notes |
-|----------|------|-------|
-| Integer | `INT64` | |
-| Decimal | `NUMERIC` or `BIGNUMERIC` | |
-| Float | `FLOAT64` | |
-| Boolean | `BOOL` | |
-| String | `STRING` | |
-| Timestamp | `TIMESTAMP` | |
-| Date | `DATE` | |
-| Time | `TIME` | |
-| DateTime | `DATETIME` | No timezone |
-| JSON | `JSON` | |
-| Bytes | `BYTES` | |
-| Nested | `STRUCT` | Record type |
-| Repeated | `ARRAY` | |
-
----
-
-## Description (NO metadata tables needed)
-
-BigQuery supports description via `OPTIONS`:
-
-### Table description
-```sql
-CREATE TABLE orders (
-    ...
-) OPTIONS(description='Table storing customer orders');
-```
-
-### Column descriptions
-```sql
-CREATE TABLE orders (
-    id INT64 NOT NULL OPTIONS(description='Primary key'),
-    order_number STRING NOT NULL OPTIONS(description='Unique order code'),
-    status STRING NOT NULL OPTIONS(description='pending|confirmed|shipped|cancelled'),
-    total_amount NUMERIC OPTIONS(description='Total value')
-);
-```
-
-### Query descriptions
-```sql
-SELECT column_name, description
-FROM `project.dataset.INFORMATION_SCHEMA.COLUMN_FIELD_PATHS`
-WHERE table_name = 'orders';
-```
-
----
-
-## Partitioning & Clustering
-
-BigQuery **does not have traditional indexes**. Instead, use partitioning and clustering:
-
-### Partitioning (required for large tables)
-
-```sql
--- Partition by date column
-CREATE TABLE fact_orders (
-    order_date DATE,
-    customer_id INT64,
-    order_id INT64,
-    amount NUMERIC
-)
-PARTITION BY order_date;
-
--- Partition by timestamp (daily)
-CREATE TABLE events (
-    event_time TIMESTAMP,
-    ...
-)
-PARTITION BY DATE(event_time);
-
--- Integer range partitioning
-CREATE TABLE logs (
-    log_id INT64,
-    ...
-)
-PARTITION BY RANGE_BUCKET(log_id, GENERATE_ARRAY(0, 1000000, 10000));
-```
-
-### Clustering (optimize filter/group)
-
-```sql
-CREATE TABLE fact_orders (
-    order_date DATE,
-    customer_id INT64,
-    product_id INT64,
-    store_id INT64,
-    amount NUMERIC
-)
-PARTITION BY order_date
-CLUSTER BY customer_id, product_id;
--- Can cluster up to 4 columns
-```
-
-### When to use what?
-- **Partition**: Filter by date range → reduces data scan
-- **Cluster**: Filter/Group by specific columns → data is organized closer together
-
----
-
-## Nested & Repeated Fields (Denormalization)
-
-BigQuery encourages denormalization with STRUCT and ARRAY:
-
-```sql
-CREATE TABLE orders (
-    order_id INT64,
-    order_date DATE,
-    customer STRUCT<
-        id INT64,
-        name STRING,
-        email STRING
-    >,
-    items ARRAY<STRUCT<
-        product_id INT64,
-        product_name STRING,
-        quantity INT64,
-        unit_price NUMERIC
-    >>
-);
-
--- Query nested fields
-SELECT
-    order_id,
-    customer.name,
-    item.product_name,
-    item.quantity
-FROM orders, UNNEST(items) AS item;
-```
-
----
-
-## Best Practices
-
-### Query optimization
-- **Avoid `SELECT *`** - only select needed columns
-- **Filter early** - use partition column in WHERE
-- **Avoid cross-join** with large tables
-
-### Table design
-- Partition tables > 1GB
-- Cluster by frequently filtered/grouped columns
-- Denormalize with STRUCT/ARRAY when appropriate
-- Avoid too many small tables
-
-### Cost control
-- Partition pruning: always filter by partition column
-- Use `--dry_run` to estimate cost
-- Set up query quotas
-
----
-
-## Example DDL
-
-```sql
-CREATE TABLE `project.dataset.fact_orders` (
-    -- Keys
-    order_id INT64 NOT NULL OPTIONS(description='PK from source'),
-    order_date DATE NOT NULL OPTIONS(description='Order date'),
-
-    -- Dimensions (denormalized)
-    customer_id INT64 NOT NULL,
-    customer_name STRING,
-    customer_segment STRING OPTIONS(description='VIP|Regular|New'),
-
-    -- Measures
-    item_count INT64 NOT NULL,
-    gross_amount NUMERIC NOT NULL,
-    discount_amount NUMERIC DEFAULT 0,
-    net_amount NUMERIC NOT NULL,
-
-    -- Nested items
-    items ARRAY<STRUCT<
-        product_id INT64,
-        product_name STRING,
-        quantity INT64,
-        unit_price NUMERIC
-    >> OPTIONS(description='Product details in order'),
-
-    -- Metadata
-    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP(),
-    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP()
-)
-PARTITION BY order_date
-CLUSTER BY customer_id
-OPTIONS(
-    description='Fact table for orders, partitioned by date, clustered by customer'
-);
-```
-
----
-
-## Scheduled Queries / Materialized Views
-
-### Materialized View
-```sql
-CREATE MATERIALIZED VIEW `project.dataset.mv_daily_sales`
-PARTITION BY report_date
-CLUSTER BY store_id
-AS
-SELECT
-    DATE(order_date) as report_date,
-    store_id,
-    COUNT(*) as order_count,
-    SUM(net_amount) as revenue
-FROM `project.dataset.fact_orders`
-GROUP BY 1, 2;
-```
-
-### Scheduled Query (ETL)
-Create via BigQuery Console or API with schedule expression.
-
----
-
-## Checklist
-
-- [ ] Partition large tables by date column
-- [ ] Cluster by frequently filtered/grouped columns (max 4)
-- [ ] `OPTIONS(description=...)` for tables and columns
-- [ ] Denormalize with STRUCT/ARRAY when appropriate
-- [ ] Avoid `SELECT *` and cross-join large tables
-- [ ] Filter by partition column in queries
-- [ ] Consider Materialized Views for frequently used aggregations