kodelyth-ecc 2.19.0 → 2.20.0

package/.kimi/commands/go-test.md

@@ -1,268 +0,0 @@
----
-description: Enforce TDD workflow for Go. Write table-driven tests first, then implement. Verify 80%+ coverage with go test -cover.
----
-
-# Go TDD Command
-
-This command enforces test-driven development methodology for Go code using idiomatic Go testing patterns.
-
-## What This Command Does
-
-1. **Define Types/Interfaces**: Scaffold function signatures first
-2. **Write Table-Driven Tests**: Create comprehensive test cases (RED)
-3. **Run Tests**: Verify tests fail for the right reason
-4. **Implement Code**: Write minimal code to pass (GREEN)
-5. **Refactor**: Improve while keeping tests green
-6. **Check Coverage**: Ensure 80%+ coverage
-
-## When to Use
-
-Use `/go-test` when:
-- Implementing new Go functions
-- Adding test coverage to existing code
-- Fixing bugs (write failing test first)
-- Building critical business logic
-- Learning TDD workflow in Go
-
-## TDD Cycle
-
-```
-RED     → Write failing table-driven test
-GREEN   → Implement minimal code to pass
-REFACTOR → Improve code, tests stay green
-REPEAT  → Next test case
-```
-
-## Example Session
-
-````
-User: /go-test I need a function to validate email addresses
-
-Agent:
-# TDD Session: Email Validator
-
-## Step 1: Define Interface
-
-```go
-// validator/email.go
-package validator
-
-// ValidateEmail checks if the given string is a valid email address.
-// Returns nil if valid, error describing the issue otherwise.
-func ValidateEmail(email string) error {
-    panic("not implemented")
-}
-```
-
-## Step 2: Write Table-Driven Tests (RED)
-
-```go
-// validator/email_test.go
-package validator
-
-import (
-    "testing"
-)
-
-func TestValidateEmail(t *testing.T) {
-    tests := []struct {
-        name    string
-        email   string
-        wantErr bool
-    }{
-        // Valid emails
-        {"simple email", "user@example.com", false},
-        {"with subdomain", "user@mail.example.com", false},
-        {"with plus", "user+tag@example.com", false},
-        {"with dots", "first.last@example.com", false},
-
-        // Invalid emails
-        {"empty string", "", true},
-        {"no at sign", "userexample.com", true},
-        {"no domain", "user@", true},
-        {"no local part", "@example.com", true},
-        {"double at", "user@@example.com", true},
-        {"spaces", "user @example.com", true},
-        {"no tld", "user@example", true},
-    }
-
-    for _, tt := range tests {
-        t.Run(tt.name, func(t *testing.T) {
-            err := ValidateEmail(tt.email)
-            if tt.wantErr && err == nil {
-                t.Errorf("ValidateEmail(%q) = nil; want error", tt.email)
-            }
-            if !tt.wantErr && err != nil {
-                t.Errorf("ValidateEmail(%q) = %v; want nil", tt.email, err)
-            }
-        })
-    }
-}
-```
-
-## Step 3: Run Tests - Verify FAIL
-
-```bash
-$ go test ./validator/...
-
---- FAIL: TestValidateEmail (0.00s)
-    --- FAIL: TestValidateEmail/simple_email (0.00s)
-        panic: not implemented
-
-FAIL
-```
-
-✓ Tests fail as expected (panic).
-
-## Step 4: Implement Minimal Code (GREEN)
-
-```go
-// validator/email.go
-package validator
-
-import (
-    "errors"
-    "regexp"
-)
-
-var emailRegex = regexp.MustCompile(`^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$`)
-
-var (
-    ErrEmailEmpty   = errors.New("email cannot be empty")
-    ErrEmailInvalid = errors.New("email format is invalid")
-)
-
-func ValidateEmail(email string) error {
-    if email == "" {
-        return ErrEmailEmpty
-    }
-    if !emailRegex.MatchString(email) {
-        return ErrEmailInvalid
-    }
-    return nil
-}
-```
-
-## Step 5: Run Tests - Verify PASS
-
-```bash
-$ go test ./validator/...
-
-PASS
-ok      project/validator    0.003s
-```
-
-✓ All tests passing!
-
-## Step 6: Check Coverage
-
-```bash
-$ go test -cover ./validator/...
-
-PASS
-coverage: 100.0% of statements
-ok      project/validator    0.003s
-```
-
-✓ Coverage: 100%
-
-## TDD Complete!
-````
-
-## Test Patterns
-
-### Table-Driven Tests
-```go
-tests := []struct {
-    name     string
-    input    InputType
-    want     OutputType
-    wantErr  bool
-}{
-    {"case 1", input1, want1, false},
-    {"case 2", input2, want2, true},
-}
-
-for _, tt := range tests {
-    t.Run(tt.name, func(t *testing.T) {
-        got, err := Function(tt.input)
-        // assertions
-    })
-}
-```
-
-### Parallel Tests
-```go
-for _, tt := range tests {
-    tt := tt // Capture
-    t.Run(tt.name, func(t *testing.T) {
-        t.Parallel()
-        // test body
-    })
-}
-```
-
-### Test Helpers
-```go
-func setupTestDB(t *testing.T) *sql.DB {
-    t.Helper()
-    db := createDB()
-    t.Cleanup(func() { db.Close() })
-    return db
-}
-```
-
-## Coverage Commands
-
-```bash
-# Basic coverage
-go test -cover ./...
-
-# Coverage profile
-go test -coverprofile=coverage.out ./...
-
-# View in browser
-go tool cover -html=coverage.out
-
-# Coverage by function
-go tool cover -func=coverage.out
-
-# With race detection
-go test -race -cover ./...
-```
-
-## Coverage Targets
-
-| Code Type | Target |
-|-----------|--------|
-| Critical business logic | 100% |
-| Public APIs | 90%+ |
-| General code | 80%+ |
-| Generated code | Exclude |
-
-## TDD Best Practices
-
-**DO:**
-- Write test FIRST, before any implementation
-- Run tests after each change
-- Use table-driven tests for comprehensive coverage
-- Test behavior, not implementation details
-- Include edge cases (empty, nil, max values)
-
-**DON'T:**
-- Write implementation before tests
-- Skip the RED phase
-- Test private functions directly
-- Use `time.Sleep` in tests
-- Ignore flaky tests
-
-## Related Commands
-
-- `/go-build` - Fix build errors
-- `/go-review` - Review code after implementation
-- `/verify` - Run full verification loop
-
-## Related
-
-- Skill: `skills/golang-testing/`
-- Skill: `skills/tdd-workflow/`

package/.kimi/commands/god-mode.md

@@ -1,85 +0,0 @@
----
-description: GOD mode — the constructive crew. Recalls past solutions, designs, builds test-first, self-critiques, hardens, and proves the work with a command that actually runs.
-argument-hint: "<what to build or harden>"
----
-
-# /god-mode — Build It Properly
-
-Nine specialists in a six-stage pipeline. This is **not** `/project-launch` (which fires everyone at once) — GOD mode is sequential where sequence matters, parallel where it doesn't, and it refuses to call anything done that it hasn't proven.
-
-## The pipeline
-
-| Stage | Agents | What happens |
-|---|---|---|
-| **Recall** | — | Search local memory for prior solutions to this problem |
-| **Design** ∥ | `architect` + `code-architect` | Blueprint: files, interfaces, data flow, build order |
-| **Build** → | `pair-programmer` + `tdd-guide` | Implement test-first; tests must actually run |
-| **Self-critique** ∥ | `type-design-analyzer` + `api-guardian` + `ux-reviewer` | Attack our own work before anyone else can |
-| **Harden** ∥ | `performance-optimizer` + `refactor-cleaner` | Hot spots and dead weight, no behaviour change |
-| **Prove** | — | Run the verification commands |
-
-∥ = parallel · → = sequential
-
-## Usage
-
-```
-/god-mode add rate limiting to the payments API
-/god-mode harden the webhook signature verification
-/god-mode                      # asks what to build
-```
-
-Preview the plan and cost from the terminal first:
-```bash
-kodelythecc god --task "add rate limiting to the payments API"
-```
-
-## Instructions to the assistant
-
-Run the stages **in order**. Do not skip Recall and do not skip Prove.
-
-### Stage 1 — Recall (do this first, always)
-Search local memory for prior work on this problem:
-- Use the `recall_memory` MCP tool, or `kodelythecc memory recall "<task>"`.
-- For each relevant hit, state: the past problem, the approach that worked, and whether it applies here.
-- **If nothing relevant exists, say so plainly.** Never invent a memory.
-
-### Stage 2 — Design (parallel)
-Launch `architect` and `code-architect` together via the Task tool. Produce one concrete blueprint: exact files, interfaces, data flow, build order. No hand-waving.
-
-### Stage 3 — Build (sequential)
-Launch `pair-programmer` and `tdd-guide`. Write the test first, watch it fail, implement, watch it pass. Report which files you created or changed.
-
-### Stage 4 — Self-critique (parallel)
-Launch `type-design-analyzer`, `api-guardian`, and `ux-reviewer` together. Be genuinely adversarial about your own output — it is far cheaper to find a problem here than to let `/evil-mode` find it later.
-
-### Stage 5 — Harden (parallel)
-Launch `performance-optimizer` and `refactor-cleaner`. Improve without changing behaviour. Tests must stay green.
-
-### Stage 6 — Prove (mandatory)
-**Run the verification command.** A test suite, a build, a benchmark — something that exits 0.
-
-- If it passes: report the command and its output.
-- If it fails: **the round is not complete.** Fix it and re-run. Do not report success.
-- "Should work" / "looks correct" is a failure of this stage.
-
-## The output contract
-
-End every GOD-mode run with:
-
-```
-GOD MODE — <task>
-  files:    <what you created or changed>
-  verified: <the command you ran> → <pass/fail + evidence>
-  memory:   <what you recalled, or "no prior art">
-  open:     <anything you deliberately did not do, and why>
-```
-
-## Handoff
-
-When the work touches security, auth, payments, user input, or dependencies, follow with:
-
-```
-/evil-mode <the files you changed>
-```
-
-That is the adversarial half — it will try to break exactly what you just built.

package/.kimi/commands/gradle-build.md

@@ -1,70 +0,0 @@
----
-description: Fix Gradle build errors for Android and KMP projects
----
-
-# Gradle Build Fix
-
-Incrementally fix Gradle build and compilation errors for Android and Kotlin Multiplatform projects.
-
-## Step 1: Detect Build Configuration
-
-Identify the project type and run the appropriate build:
-
-| Indicator | Build Command |
-|-----------|---------------|
-| `build.gradle.kts` + `composeApp/` (KMP) | `./gradlew composeApp:compileKotlinMetadata 2>&1` |
-| `build.gradle.kts` + `app/` (Android) | `./gradlew app:compileDebugKotlin 2>&1` |
-| `settings.gradle.kts` with modules | `./gradlew assemble 2>&1` |
-| Detekt configured | `./gradlew detekt 2>&1` |
-
-Also check `gradle.properties` and `local.properties` for configuration.
-
-## Step 2: Parse and Group Errors
-
-1. Run the build command and capture output
-2. Separate Kotlin compilation errors from Gradle configuration errors
-3. Group by module and file path
-4. Sort: configuration errors first, then compilation errors by dependency order
-
-## Step 3: Fix Loop
-
-For each error:
-
-1. **Read the file** — Full context around the error line
-2. **Diagnose** — Common categories:
-   - Missing import or unresolved reference
-   - Type mismatch or incompatible types
-   - Missing dependency in `build.gradle.kts`
-   - Expect/actual mismatch (KMP)
-   - Compose compiler error
-3. **Fix minimally** — Smallest change that resolves the error
-4. **Re-run build** — Verify fix and check for new errors
-5. **Continue** — Move to next error
-
-## Step 4: Guardrails
-
-Stop and ask the user if:
-- Fix introduces more errors than it resolves
-- Same error persists after 3 attempts
-- Error requires adding new dependencies or changing module structure
-- Gradle sync itself fails (configuration-phase error)
-- Error is in generated code (Room, SQLDelight, KSP)
-
-## Step 5: Summary
-
-Report:
-- Errors fixed (module, file, description)
-- Errors remaining
-- New errors introduced (should be zero)
-- Suggested next steps
-
-## Common Gradle/KMP Fixes
-
-| Error | Fix |
-|-------|-----|
-| Unresolved reference in `commonMain` | Check if the dependency is in `commonMain.dependencies {}` |
-| Expect declaration without actual | Add `actual` implementation in each platform source set |
-| Compose compiler version mismatch | Align Kotlin and Compose compiler versions in `libs.versions.toml` |
-| Duplicate class | Check for conflicting dependencies with `./gradlew dependencies` |
-| KSP error | Run `./gradlew kspCommonMainKotlinMetadata` to regenerate |
-| Configuration cache issue | Check for non-serializable task inputs |

package/.kimi/commands/harness-audit.md

@@ -1,77 +0,0 @@
----
-description: Audit and optimize the local agent harness for reliability, cost, and throughput
----
-
-# Harness Audit Command
-
-Run a deterministic repository harness audit and return a prioritized scorecard.
-
-## Usage
-
-`/harness-audit [scope] [--format text|json] [--root path]`
-
-- `scope` (optional): `repo` (default), `hooks`, `skills`, `commands`, `agents`
-- `--format`: output style (`text` default, `json` for automation)
-- `--root`: audit a specific path instead of the current working directory
-
-## Deterministic Engine
-
-Always run:
-
-```bash
-node scripts/harness-audit.js <scope> --format <text|json> [--root <path>]
-```
-
-This script is the source of truth for scoring and checks. Do not invent additional dimensions or ad-hoc points.
-
-Rubric version: `2026-03-30`.
-
-The script computes 7 fixed categories (`0-10` normalized each):
-
-1. Tool Coverage
-2. Context Efficiency
-3. Quality Gates
-4. Memory Persistence
-5. Eval Coverage
-6. Security Guardrails
-7. Cost Efficiency
-
-Scores are derived from explicit file/rule checks and are reproducible for the same commit.
-The script audits the current working directory by default and auto-detects whether the target is the ECC repo itself or a consumer project using ECC.
-
-## Output Contract
-
-Return:
-
-1. `overall_score` out of `max_score` (70 for `repo`; smaller for scoped audits)
-2. Category scores and concrete findings
-3. Failed checks with exact file paths
-4. Top 3 actions from the deterministic output (`top_actions`)
-5. Suggested ECC skills to apply next
-
-## Checklist
-
-- Use script output directly; do not rescore manually.
-- If `--format json` is requested, return the script JSON unchanged.
-- If text is requested, summarize failing checks and top actions.
-- Include exact file paths from `checks[]` and `top_actions[]`.
-
-## Example Result
-
-```text
-Harness Audit (repo): 66/70
-- Tool Coverage: 10/10 (10/10 pts)
-- Context Efficiency: 9/10 (9/10 pts)
-- Quality Gates: 10/10 (10/10 pts)
-
-Top 3 Actions:
-1) [Security Guardrails] Add prompt/tool preflight security guards in hooks/hooks.json. (hooks/hooks.json)
-2) [Tool Coverage] Sync commands/harness-audit.md and .opencode/commands/harness-audit.md. (.opencode/commands/harness-audit.md)
-3) [Eval Coverage] Increase automated test coverage across scripts/hooks/lib. (tests/)
-```
-
-## Arguments
-
-$ARGUMENTS:
-- `repo|hooks|skills|commands|agents` (optional scope)
-- `--format text|json` (optional output format)

package/.kimi/commands/hookify-configure.md

@@ -1,14 +0,0 @@
----
-description: Enable or disable hookify rules interactively
----
-
-Interactively enable or disable existing hookify rules.
-
-## Steps
-
-1. Find all `.claude/hookify.*.local.md` files
-2. Read the current state of each rule
-3. Present the list with current enabled / disabled status
-4. Ask which rules to toggle
-5. Update the `enabled:` field in the selected rule files
-6. Confirm the changes

package/.kimi/commands/hookify-help.md

@@ -1,46 +0,0 @@
----
-description: Get help with the hookify system
----
-
-Display comprehensive hookify documentation.
-
-## Hook System Overview
-
-Hookify creates rule files that integrate with Claude Code's hook system to prevent unwanted behaviors.
-
-### Event Types
-
-- `bash`: triggers on Bash tool use and matches command patterns
-- `file`: triggers on Write/Edit tool use and matches file paths
-- `stop`: triggers when a session ends
-- `prompt`: triggers on user message submission and matches input patterns
-- `all`: triggers on all events
-
-### Rule File Format
-
-Files are stored as `.claude/hookify.{name}.local.md`:
-
-```yaml
----
-name: descriptive-name
-enabled: true
-event: bash|file|stop|prompt|all
-action: block|warn
-pattern: "regex pattern to match"
----
-Message to display when rule triggers.
-Supports multiple lines.
-```
-
-### Commands
-
-- `/hookify [description]` creates new rules and auto-analyzes the conversation when no description is given
-- `/hookify-list` lists configured rules
-- `/hookify-configure` toggles rules on or off
-
-### Pattern Tips
-
-- use regex syntax
-- for `bash`, match against the full command string
-- for `file`, match against the file path
-- test patterns before deploying

package/.kimi/commands/hookify-list.md

@@ -1,21 +0,0 @@
----
-description: List all configured hookify rules
----
-
-Find and display all hookify rules in a formatted table.
-
-## Steps
-
-1. Find all `.claude/hookify.*.local.md` files
-2. Read each file's frontmatter:
-   - `name`
-   - `enabled`
-   - `event`
-   - `action`
-   - `pattern`
-3. Display them as a table:
-
-| Rule | Enabled | Event | Pattern | File |
-|------|---------|-------|---------|------|
-
-4. Show the rule count and remind the user that `/hookify-configure` can change state later.

package/.kimi/commands/hookify.md

@@ -1,50 +0,0 @@
----
-description: Create hooks to prevent unwanted behaviors from conversation analysis or explicit instructions
----
-
-Create hook rules to prevent unwanted Claude Code behaviors by analyzing conversation patterns or explicit user instructions.
-
-## Usage
-
-`/hookify [description of behavior to prevent]`
-
-If no arguments are provided, analyze the current conversation to find behaviors worth preventing.
-
-## Workflow
-
-### Step 1: Gather Behavior Info
-
-- With arguments: parse the user's description of the unwanted behavior
-- Without arguments: use the `conversation-analyzer` agent to find:
-  - explicit corrections
-  - frustrated reactions to repeated mistakes
-  - reverted changes
-  - repeated similar issues
-
-### Step 2: Present Findings
-
-Show the user:
-
-- behavior description
-- proposed event type
-- proposed pattern or matcher
-- proposed action
-
-### Step 3: Generate Rule Files
-
-For each approved rule, create a file at `.claude/hookify.{name}.local.md`:
-
-```yaml
----
-name: rule-name
-enabled: true
-event: bash|file|stop|prompt|all
-action: block|warn
-pattern: "regex pattern"
----
-Message shown when rule triggers.
-```
-
-### Step 4: Confirm
-
-Report created rules and how to manage them with `/hookify-list` and `/hookify-configure`.