@cregis-dev/cckit 0.2.0

package/templates/ecc/commands/go-test.md

@@ -0,0 +1,268 @@
+---
+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/templates/ecc/commands/instinct-export.md

@@ -0,0 +1,91 @@
+---
+name: instinct-export
+description: Export instincts for sharing with teammates or other projects
+command: /instinct-export
+---
+
+# Instinct Export Command
+
+Exports instincts to a shareable format. Perfect for:
+- Sharing with teammates
+- Transferring to a new machine
+- Contributing to project conventions
+
+## Usage
+
+```
+/instinct-export                           # Export all personal instincts
+/instinct-export --domain testing          # Export only testing instincts
+/instinct-export --min-confidence 0.7      # Only export high-confidence instincts
+/instinct-export --output team-instincts.yaml
+```
+
+## What to Do
+
+1. Read instincts from `~/.claude/homunculus/instincts/personal/`
+2. Filter based on flags
+3. Strip sensitive information:
+   - Remove session IDs
+   - Remove file paths (keep only patterns)
+   - Remove timestamps older than "last week"
+4. Generate export file
+
+## Output Format
+
+Creates a YAML file:
+
+```yaml
+# Instincts Export
+# Generated: 2025-01-22
+# Source: personal
+# Count: 12 instincts
+
+version: "2.0"
+exported_by: "continuous-learning-v2"
+export_date: "2025-01-22T10:30:00Z"
+
+instincts:
+  - id: prefer-functional-style
+    trigger: "when writing new functions"
+    action: "Use functional patterns over classes"
+    confidence: 0.8
+    domain: code-style
+    observations: 8
+
+  - id: test-first-workflow
+    trigger: "when adding new functionality"
+    action: "Write test first, then implementation"
+    confidence: 0.9
+    domain: testing
+    observations: 12
+
+  - id: grep-before-edit
+    trigger: "when modifying code"
+    action: "Search with Grep, confirm with Read, then Edit"
+    confidence: 0.7
+    domain: workflow
+    observations: 6
+```
+
+## Privacy Considerations
+
+Exports include:
+- ✅ Trigger patterns
+- ✅ Actions
+- ✅ Confidence scores
+- ✅ Domains
+- ✅ Observation counts
+
+Exports do NOT include:
+- ❌ Actual code snippets
+- ❌ File paths
+- ❌ Session transcripts
+- ❌ Personal identifiers
+
+## Flags
+
+- `--domain <name>`: Export only specified domain
+- `--min-confidence <n>`: Minimum confidence threshold (default: 0.3)
+- `--output <file>`: Output file path (default: instincts-export-YYYYMMDD.yaml)
+- `--format <yaml|json|md>`: Output format (default: yaml)
+- `--include-evidence`: Include evidence text (default: excluded)

package/templates/ecc/commands/instinct-import.md

@@ -0,0 +1,142 @@
+---
+name: instinct-import
+description: Import instincts from teammates, Skill Creator, or other sources
+command: true
+---
+
+# Instinct Import Command
+
+## Implementation
+
+Run the instinct CLI using the plugin root path:
+
+```bash
+python3 "${CLAUDE_PLUGIN_ROOT}/skills/continuous-learning-v2/scripts/instinct-cli.py" import <file-or-url> [--dry-run] [--force] [--min-confidence 0.7]
+```
+
+Or if `CLAUDE_PLUGIN_ROOT` is not set (manual installation):
+
+```bash
+python3 ~/.claude/skills/continuous-learning-v2/scripts/instinct-cli.py import <file-or-url>
+```
+
+Import instincts from:
+- Teammates' exports
+- Skill Creator (repo analysis)
+- Community collections
+- Previous machine backups
+
+## Usage
+
+```
+/instinct-import team-instincts.yaml
+/instinct-import https://github.com/org/repo/instincts.yaml
+/instinct-import --from-skill-creator acme/webapp
+```
+
+## What to Do
+
+1. Fetch the instinct file (local path or URL)
+2. Parse and validate the format
+3. Check for duplicates with existing instincts
+4. Merge or add new instincts
+5. Save to `~/.claude/homunculus/instincts/inherited/`
+
+## Import Process
+
+```
+📥 Importing instincts from: team-instincts.yaml
+================================================
+
+Found 12 instincts to import.
+
+Analyzing conflicts...
+
+## New Instincts (8)
+These will be added:
+  ✓ use-zod-validation (confidence: 0.7)
+  ✓ prefer-named-exports (confidence: 0.65)
+  ✓ test-async-functions (confidence: 0.8)
+  ...
+
+## Duplicate Instincts (3)
+Already have similar instincts:
+  ⚠️ prefer-functional-style
+     Local: 0.8 confidence, 12 observations
+     Import: 0.7 confidence
+     → Keep local (higher confidence)
+
+  ⚠️ test-first-workflow
+     Local: 0.75 confidence
+     Import: 0.9 confidence
+     → Update to import (higher confidence)
+
+## Conflicting Instincts (1)
+These contradict local instincts:
+  ❌ use-classes-for-services
+     Conflicts with: avoid-classes
+     → Skip (requires manual resolution)
+
+---
+Import 8 new, update 1, skip 3?
+```
+
+## Merge Strategies
+
+### For Duplicates
+When importing an instinct that matches an existing one:
+- **Higher confidence wins**: Keep the one with higher confidence
+- **Merge evidence**: Combine observation counts
+- **Update timestamp**: Mark as recently validated
+
+### For Conflicts
+When importing an instinct that contradicts an existing one:
+- **Skip by default**: Don't import conflicting instincts
+- **Flag for review**: Mark both as needing attention
+- **Manual resolution**: User decides which to keep
+
+## Source Tracking
+
+Imported instincts are marked with:
+```yaml
+source: "inherited"
+imported_from: "team-instincts.yaml"
+imported_at: "2025-01-22T10:30:00Z"
+original_source: "session-observation"  # or "repo-analysis"
+```
+
+## Skill Creator Integration
+
+When importing from Skill Creator:
+
+```
+/instinct-import --from-skill-creator acme/webapp
+```
+
+This fetches instincts generated from repo analysis:
+- Source: `repo-analysis`
+- Higher initial confidence (0.7+)
+- Linked to source repository
+
+## Flags
+
+- `--dry-run`: Preview without importing
+- `--force`: Import even if conflicts exist
+- `--merge-strategy <higher|local|import>`: How to handle duplicates
+- `--from-skill-creator <owner/repo>`: Import from Skill Creator analysis
+- `--min-confidence <n>`: Only import instincts above threshold
+
+## Output
+
+After import:
+```
+✅ Import complete!
+
+Added: 8 instincts
+Updated: 1 instinct
+Skipped: 3 instincts (2 duplicates, 1 conflict)
+
+New instincts saved to: ~/.claude/homunculus/instincts/inherited/
+
+Run /instinct-status to see all instincts.
+```

package/templates/ecc/commands/instinct-status.md

@@ -0,0 +1,86 @@
+---
+name: instinct-status
+description: Show all learned instincts with their confidence levels
+command: true
+---
+
+# Instinct Status Command
+
+Shows all learned instincts with their confidence scores, grouped by domain.
+
+## Implementation
+
+Run the instinct CLI using the plugin root path:
+
+```bash
+python3 "${CLAUDE_PLUGIN_ROOT}/skills/continuous-learning-v2/scripts/instinct-cli.py" status
+```
+
+Or if `CLAUDE_PLUGIN_ROOT` is not set (manual installation), use:
+
+```bash
+python3 ~/.claude/skills/continuous-learning-v2/scripts/instinct-cli.py status
+```
+
+## Usage
+
+```
+/instinct-status
+/instinct-status --domain code-style
+/instinct-status --low-confidence
+```
+
+## What to Do
+
+1. Read all instinct files from `~/.claude/homunculus/instincts/personal/`
+2. Read inherited instincts from `~/.claude/homunculus/instincts/inherited/`
+3. Display them grouped by domain with confidence bars
+
+## Output Format
+
+```
+📊 Instinct Status
+==================
+
+## Code Style (4 instincts)
+
+### prefer-functional-style
+Trigger: when writing new functions
+Action: Use functional patterns over classes
+Confidence: ████████░░ 80%
+Source: session-observation | Last updated: 2025-01-22
+
+### use-path-aliases
+Trigger: when importing modules
+Action: Use @/ path aliases instead of relative imports
+Confidence: ██████░░░░ 60%
+Source: repo-analysis (github.com/acme/webapp)
+
+## Testing (2 instincts)
+
+### test-first-workflow
+Trigger: when adding new functionality
+Action: Write test first, then implementation
+Confidence: █████████░ 90%
+Source: session-observation
+
+## Workflow (3 instincts)
+
+### grep-before-edit
+Trigger: when modifying code
+Action: Search with Grep, confirm with Read, then Edit
+Confidence: ███████░░░ 70%
+Source: session-observation
+
+---
+Total: 9 instincts (4 personal, 5 inherited)
+Observer: Running (last analysis: 5 min ago)
+```
+
+## Flags
+
+- `--domain <name>`: Filter by domain (code-style, testing, git, etc.)
+- `--low-confidence`: Show only instincts with confidence < 0.5
+- `--high-confidence`: Show only instincts with confidence >= 0.7
+- `--source <type>`: Filter by source (session-observation, repo-analysis, inherited)
+- `--json`: Output as JSON for programmatic use

package/templates/ecc/commands/learn-eval.md

@@ -0,0 +1,91 @@
+---
+description: Extract reusable patterns from the session, self-evaluate quality before saving, and determine the right save location (Global vs Project).
+---
+
+# /learn-eval - Extract, Evaluate, then Save
+
+Extends `/learn` with a quality gate and save-location decision before writing any skill file.
+
+## What to Extract
+
+Look for:
+
+1. **Error Resolution Patterns** — root cause + fix + reusability
+2. **Debugging Techniques** — non-obvious steps, tool combinations
+3. **Workarounds** — library quirks, API limitations, version-specific fixes
+4. **Project-Specific Patterns** — conventions, architecture decisions, integration patterns
+
+## Process
+
+1. Review the session for extractable patterns
+2. Identify the most valuable/reusable insight
+
+3. **Determine save location:**
+   - Ask: "Would this pattern be useful in a different project?"
+   - **Global** (`~/.claude/skills/learned/`): Generic patterns usable across 2+ projects (bash compatibility, LLM API behavior, debugging techniques, etc.)
+   - **Project** (`.claude/skills/learned/` in current project): Project-specific knowledge (quirks of a particular config file, project-specific architecture decisions, etc.)
+   - When in doubt, choose Global (moving Global → Project is easier than the reverse)
+
+4. Draft the skill file using this format:
+
+```markdown
+---
+name: pattern-name
+description: "Under 130 characters"
+user-invocable: false
+origin: auto-extracted
+---
+
+# [Descriptive Pattern Name]
+
+**Extracted:** [Date]
+**Context:** [Brief description of when this applies]
+
+## Problem
+[What problem this solves - be specific]
+
+## Solution
+[The pattern/technique/workaround - with code examples]
+
+## When to Use
+[Trigger conditions]
+```
+
+5. **Self-evaluate before saving** using this rubric:
+
+   | Dimension | 1 | 3 | 5 |
+   |-----------|---|---|---|
+   | Specificity | Abstract principles only, no code examples | Representative code example present | Rich examples covering all usage patterns |
+   | Actionability | Unclear what to do | Main steps are understandable | Immediately actionable, edge cases covered |
+   | Scope Fit | Too broad or too narrow | Mostly appropriate, some boundary ambiguity | Name, trigger, and content perfectly aligned |
+   | Non-redundancy | Nearly identical to another skill | Some overlap but unique perspective exists | Completely unique value |
+   | Coverage | Covers only a fraction of the target task | Main cases covered, common variants missing | Main cases, edge cases, and pitfalls covered |
+
+   - Score each dimension 1–5
+   - If any dimension scores 1–2, improve the draft and re-score until all dimensions are ≥ 3
+   - Show the user the scores table and the final draft
+
+6. Ask user to confirm:
+   - Show: proposed save path + scores table + final draft
+   - Wait for explicit confirmation before writing
+
+7. Save to the determined location
+
+## Output Format for Step 5 (scores table)
+
+| Dimension | Score | Rationale |
+|-----------|-------|-----------|
+| Specificity | N/5 | ... |
+| Actionability | N/5 | ... |
+| Scope Fit | N/5 | ... |
+| Non-redundancy | N/5 | ... |
+| Coverage | N/5 | ... |
+| **Total** | **N/25** | |
+
+## Notes
+
+- Don't extract trivial fixes (typos, simple syntax errors)
+- Don't extract one-time issues (specific API outages, etc.)
+- Focus on patterns that will save time in future sessions
+- Keep skills focused — one pattern per skill
+- If Coverage score is low, add related variants before saving