cokit-cli 1.2.7 → 1.4.0

package/skills/ck-debug/references/investigation-methodology.md

@@ -0,0 +1,101 @@
+# Investigation Methodology
+
+Five-step structured investigation for system-level issues, incidents, and multi-component failures.
+
+## When to Use
+
+- Server returning 500 errors or unexpected responses
+- System behavior changed without obvious code changes
+- Multi-component failures spanning services/databases/infrastructure
+- Need to understand "what happened" before fixing
+
+## Step 1: Initial Assessment
+
+**Gather scope and impact before diving in.**
+
+1. **Collect symptoms** - Error messages, affected endpoints, user reports
+2. **Identify affected components** - Which services, databases, queues involved?
+3. **Determine timeframe** - When did issue start? Correlate with deployments/changes
+4. **Assess severity** - Users affected? Data at risk? Revenue impact?
+5. **Check recent changes** - Git log, deployment history, config changes, dependency updates
+
+```bash
+# Recent deployments
+gh run list --limit 10
+# Recent commits
+git log --oneline -20 --since="2 days ago"
+# Config changes
+git diff HEAD~5 -- '*.env*' '*.config*' '*.yml' '*.yaml' '*.json'
+```
+
+## Step 2: Data Collection
+
+**Gather evidence systematically before analysis.**
+
+1. **Server/application logs** - Filter by timeframe and affected components
+2. **CI/CD pipeline logs** - Use `gh run view <run-id> --log-failed` for GitHub Actions
+3. **Database state** - Query relevant tables, check recent migrations
+4. **System metrics** - CPU, memory, disk, network utilization
+5. **External dependencies** - Third-party API status, DNS, CDN
+
+```bash
+# GitHub Actions: list recent workflow runs
+gh run list --workflow=<workflow> --limit 5
+# View failed run logs
+gh run view <run-id> --log-failed
+# Download full logs
+gh run view <run-id> --log > /tmp/ci-logs.txt
+```
+
+**For codebase understanding:**
+- Read `docs/codebase-summary.md` if exists and up-to-date (<2 days old)
+- Otherwise use `repomix` to generate fresh codebase summary
+- Use `/ck-scout` or `/ck-scout ext` to find relevant files
+- Use `docs-seeker` skill for package/plugin documentation
+
+## Step 3: Analysis Process
+
+**Correlate evidence across sources.**
+
+1. **Timeline reconstruction** - Order events chronologically across all log sources
+2. **Pattern identification** - Recurring errors, timing patterns, affected user segments
+3. **Execution path tracing** - Follow request flow through system components
+4. **Database analysis** - Query performance, table relationships, data integrity
+5. **Dependency mapping** - Which components depend on the failing one?
+
+**Key questions:**
+- Does issue correlate with specific deployments or time windows?
+- Is it intermittent or consistent?
+- Does it affect all users or a subset?
+- Are there related errors in upstream/downstream services?
+
+## Step 4: Root Cause Identification
+
+**Systematic elimination with evidence.**
+
+1. **List hypotheses** ranked by evidence strength
+2. **Test each** - Design smallest experiment to confirm/eliminate
+3. **Validate with evidence** - Logs, metrics, reproduction steps
+4. **Consider environmental factors** - Race conditions, resource limits, config drift
+5. **Document the chain** - Full event sequence from trigger to symptom
+
+**Avoid:** Fixing first hypothesis without testing alternatives. Multiple plausible causes require elimination.
+
+## Step 5: Solution Development
+
+**Design targeted, evidence-backed fixes.**
+
+1. **Immediate fix** - Minimum change to restore service (hotfix, rollback, config change)
+2. **Root cause fix** - Address underlying issue permanently
+3. **Preventive measures** - Monitoring, alerting, validation to catch recurrence early
+4. **Verification plan** - How to confirm fix works in production
+
+**Prioritize:** Impact × urgency. Restore service first, then fix root cause, then prevent recurrence.
+
+## Integration with Code-Level Debugging
+
+When investigation narrows to specific code:
+- Switch to `systematic-debugging.md` for the code-level fix
+- Use `root-cause-tracing.md` if error is deep in call stack
+- Apply `defense-in-depth.md` after fixing
+- Always finish with `verification.md`

package/skills/ck-debug/references/log-and-ci-analysis.md

@@ -0,0 +1,97 @@
+# Log & CI/CD Analysis
+
+Collect and analyze logs from servers, CI/CD pipelines, and application layers to diagnose failures.
+
+## GitHub Actions Analysis
+
+### List and Inspect Runs
+
+```bash
+# List recent runs (all workflows)
+gh run list --limit 10
+
+# List runs for specific workflow
+gh run list --workflow=ci.yml --limit 5
+
+# View specific run details
+gh run view <run-id>
+
+# View failed job logs only
+gh run view <run-id> --log-failed
+
+# Download complete logs
+gh run view <run-id> --log > /tmp/ci-full.txt
+
+# Re-run failed jobs
+gh run rerun <run-id> --failed
+```
+
+### Common CI/CD Failure Patterns
+
+| Pattern | Likely Cause | Investigation |
+|---------|-------------|---------------|
+| Passes locally, fails CI | Environment diff | Check Node/Python version, OS, env vars |
+| Intermittent failures | Race conditions, flaky tests | Run 3x, check timing, shared state |
+| Timeout failures | Resource limits, infinite loops | Check resource usage, add timeouts |
+| Permission errors | Token/secret misconfiguration | Verify `GITHUB_TOKEN`, secret names |
+| Dependency install fails | Registry issues, version conflicts | Check lockfile, registry status |
+| Build succeeds, tests fail | Test environment setup | Check test config, database setup, fixtures |
+
+### Analyzing Failed Steps
+
+1. **Identify which step failed** - `gh run view <id>` shows step-by-step status
+2. **Get the logs** - `gh run view <id> --log-failed` for focused output
+3. **Search for error patterns** - Look for `Error:`, `FAIL`, `exit code`, stack traces
+4. **Check annotations** - `gh api repos/{owner}/{repo}/check-runs/{id}/annotations`
+
+## Server Log Analysis
+
+### Log Collection Strategy
+
+1. **Identify log locations** - Application logs, system logs, web server logs
+2. **Filter by timeframe** - Narrow to incident window
+3. **Correlate request IDs** - Trace single request across services
+4. **Look for patterns** - Repeated errors, error rate changes, unusual payloads
+
+### Structured Log Queries
+
+```bash
+# Search application logs for errors (use Grep tool when possible)
+# Pattern: timestamp, level, message
+# Filter by time range and severity
+
+# PostgreSQL slow query log
+psql -c "SELECT query, calls, mean_exec_time FROM pg_stat_statements ORDER BY mean_exec_time DESC LIMIT 10;"
+
+# Check database connections
+psql -c "SELECT count(*), state FROM pg_stat_activity GROUP BY state;"
+```
+
+### Cross-Source Correlation
+
+1. **Align timestamps** across all log sources (timezone awareness)
+2. **Build timeline** - First error → propagation → user impact
+3. **Identify trigger** - What changed immediately before first error?
+4. **Map blast radius** - Which services/endpoints affected?
+
+## Application Log Analysis
+
+### Error Pattern Recognition
+
+- **Sudden spike** → Deployment, config change, external dependency failure
+- **Gradual increase** → Resource leak, data growth, degradation
+- **Periodic failures** → Cron jobs, scheduled tasks, resource contention
+- **Single endpoint** → Code bug, data issue, specific dependency
+- **All endpoints** → Infrastructure, database, network issue
+
+### Key Log Fields
+
+Prioritize: timestamp, level, error message, stack trace, request ID, user ID, endpoint, response code, duration
+
+### Evidence Preservation
+
+Always capture relevant log excerpts for the diagnostic report. Include:
+- Exact error messages and stack traces
+- Timestamps and request IDs
+- Before/after comparison (normal vs error state)
+- Counts and frequencies

package/skills/ck-debug/references/performance-diagnostics.md

@@ -0,0 +1,113 @@
+# Performance Diagnostics
+
+Identify bottlenecks, analyze query performance, and develop optimization strategies.
+
+## When to Use
+
+- Response times increased significantly
+- Application feels slow or unresponsive
+- Database queries taking too long
+- High CPU/memory/disk usage
+- Resource exhaustion or OOM errors
+
+## Diagnostic Process
+
+### 1. Quantify the Problem
+
+**Measure before optimizing.** Establish baseline and current state.
+
+- What is the expected response time vs actual?
+- When did degradation start? (correlate with changes)
+- Which endpoints/operations are affected?
+- Is it consistent or intermittent?
+
+### 2. Identify the Bottleneck Layer
+
+```
+Request → Network → Web Server → Application → Database → Filesystem
+                                      ↓
+                              External APIs / Services
+```
+
+**Elimination approach:** Measure time at each layer to find where delay occurs.
+
+| Layer | Check | Tool |
+|-------|-------|------|
+| Network | Latency, DNS, TLS | `curl -w` timing, network logs |
+| Web server | Request queue, connections | Server metrics, access logs |
+| Application | CPU profiling, memory | Profiler, APM, `process.memoryUsage()` |
+| Database | Query time, connections | `EXPLAIN ANALYZE`, `pg_stat_statements` |
+| Filesystem | I/O wait, disk usage | `iostat`, `df -h` |
+| External APIs | Response time, timeouts | Request logging with durations |
+
+### 3. Database Performance
+
+#### PostgreSQL Diagnostics
+
+```sql
+-- Slow queries (requires pg_stat_statements extension)
+SELECT query, calls, mean_exec_time, total_exec_time
+FROM pg_stat_statements
+ORDER BY mean_exec_time DESC LIMIT 20;
+
+-- Active queries right now
+SELECT pid, now() - pg_stat_activity.query_start AS duration, query, state
+FROM pg_stat_activity
+WHERE state != 'idle'
+ORDER BY duration DESC;
+
+-- Table sizes and bloat
+SELECT relname, pg_size_pretty(pg_total_relation_size(relid))
+FROM pg_catalog.pg_statio_user_tables
+ORDER BY pg_total_relation_size(relid) DESC LIMIT 20;
+
+-- Missing indexes (sequential scans on large tables)
+SELECT relname, seq_scan, seq_tup_read, idx_scan
+FROM pg_stat_user_tables
+WHERE seq_scan > 100 AND seq_tup_read > 10000
+ORDER BY seq_tup_read DESC;
+
+-- Connection pool status
+SELECT count(*), state FROM pg_stat_activity GROUP BY state;
+```
+
+#### Query Optimization
+
+```sql
+-- Analyze specific query execution plan
+EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT) <your-query>;
+```
+
+**Look for:** Sequential scans on large tables, nested loops with high row counts, sorts without indexes, excessive buffer hits.
+
+### 4. Application Performance
+
+**Common bottlenecks:**
+
+| Issue | Symptom | Fix |
+|-------|---------|-----|
+| N+1 queries | Many small DB calls per request | Eager loading, batch queries |
+| Memory leaks | Growing memory over time | Profile heap, check event listeners |
+| Blocking I/O | High response time, low CPU | Async operations, connection pooling |
+| CPU-bound | High CPU, proportional to load | Optimize algorithms, caching |
+| Connection exhaustion | Intermittent timeouts | Pool sizing, connection reuse |
+| Large payloads | Slow transfers, high memory | Pagination, compression, streaming |
+
+### 5. Optimization Strategy
+
+**Priority order:**
+1. **Quick wins** - Add missing index, fix N+1 query, enable caching
+2. **Configuration** - Pool sizes, timeouts, buffer sizes, worker counts
+3. **Code changes** - Algorithm optimization, data structure changes
+4. **Architecture** - Caching layer, read replicas, async processing, CDN
+
+**Always:** Measure after each change to verify improvement. One change at a time.
+
+## Reporting Performance Issues
+
+Include in diagnostic report:
+- **Baseline vs current** metrics (with numbers)
+- **Bottleneck identification** with evidence
+- **Root cause** explanation
+- **Recommended fixes** with expected impact
+- **Verification plan** to confirm improvement

package/skills/ck-debug/references/reporting-standards.md

@@ -0,0 +1,122 @@
+# Reporting Standards
+
+Structured format for diagnostic and investigation reports. Sacrifice grammar for concision.
+
+## When to Use
+
+- After completing system investigation
+- Summarizing debugging session findings
+- Producing incident post-mortems
+- Reporting performance analysis results
+
+## Report Structure
+
+### 1. Executive Summary (3-5 lines)
+
+- **Issue:** One-line description
+- **Impact:** Users/systems affected, severity
+- **Root cause:** One-line explanation
+- **Status:** Resolved / Mitigated / Under investigation
+- **Fix:** What was done or recommended
+
+### 2. Technical Analysis
+
+**Timeline:**
+```
+HH:MM - Event description
+HH:MM - Next event
+...
+```
+
+**Evidence:**
+- Relevant log excerpts (trimmed to essential lines)
+- Query results with key metrics
+- Error messages and stack traces
+- Before/after comparisons
+
+**Findings:**
+- List each finding with supporting evidence
+- Distinguish confirmed facts from hypotheses
+- Note correlation vs causation
+
+### 3. Actionable Recommendations
+
+**Immediate (P0):**
+- [ ] Critical fix with implementation steps
+
+**Short-term (P1):**
+- [ ] Follow-up improvements
+
+**Long-term (P2):**
+- [ ] Monitoring/alerting enhancements
+- [ ] Architecture improvements
+- [ ] Preventive measures
+
+Each recommendation: what to do, why, expected impact, effort estimate (low/medium/high).
+
+### 4. Supporting Evidence
+
+- Relevant log excerpts
+- Query results and execution plans
+- Performance metrics
+- Test results and error traces
+- Screenshots or diagrams if applicable
+
+### 5. Unresolved Questions
+
+List anything that remains unclear:
+- Items needing further investigation
+- Questions for the team
+- Assumptions that need validation
+
+## Report File Naming
+
+Use naming pattern from `## Naming` section injected by hooks. Pattern includes full path and computed date.
+
+**Example:** `plans/reports/debugger-260205-2215-api-500-investigation.md`
+
+## Writing Guidelines
+
+- **Concise:** Facts and evidence, not narrative. Sacrifice grammar for brevity
+- **Evidence-backed:** Every claim supported by logs, metrics, or reproduction steps
+- **Actionable:** Recommendations are specific with clear next steps
+- **Honest:** State unknowns explicitly. "Likely cause" vs "confirmed cause"
+- **Structured:** Use headers, tables, and bullet points for scanability
+
+## Template
+
+```markdown
+# [Issue Title] - Investigation Report
+
+## Executive Summary
+- **Issue:**
+- **Impact:**
+- **Root cause:**
+- **Status:**
+- **Fix:**
+
+## Timeline
+- HH:MM -
+- HH:MM -
+
+## Technical Analysis
+### Findings
+1.
+2.
+
+### Evidence
+[logs, queries, metrics]
+
+## Recommendations
+### Immediate (P0)
+- [ ]
+
+### Short-term (P1)
+- [ ]
+
+### Long-term (P2)
+- [ ]
+
+## Unresolved Questions
+-
+```

package/skills/ck-debug/references/task-management-debugging.md

@@ -0,0 +1,155 @@
+# Debug Task Management Patterns
+
+Track investigation and debugging pipelines via Native Tasks (TaskCreate, TaskUpdate, TaskList).
+
+## When to Create Tasks
+
+| Debug Scope | Tasks? | Rationale |
+|-------------|--------|-----------|
+| Single bug, one file | No | Systematic debugging handles directly |
+| Multi-component investigation (3+ steps) | Yes | Track assess → collect → analyze → fix → verify |
+| Parallel log/data collection agents | Yes | Coordinate independent evidence gathering |
+| Performance investigation with multiple layers | Yes | Track bottleneck analysis per layer |
+| CI/CD pipeline failure with 3+ possible causes | Yes | Track hypothesis elimination |
+
+**3-Task Rule:** Skip task creation when investigation has <3 meaningful steps.
+
+## Investigation Pipeline as Tasks
+
+```
+TaskCreate: "Assess incident scope"      → pending
+TaskCreate: "Collect logs and evidence"  → pending, blockedBy: [assess]
+TaskCreate: "Analyze root cause"         → pending, blockedBy: [collect]
+TaskCreate: "Implement fix"              → pending, blockedBy: [analyze]
+TaskCreate: "Verify fix resolves issue"  → pending, blockedBy: [fix]
+```
+
+Maps to investigation-methodology.md 5-step process. Auto-unblocks as each step completes.
+
+## Task Schemas
+
+### Assess Task
+
+```
+TaskCreate(
+  subject: "Assess {incident} scope and impact",
+  activeForm: "Assessing incident scope",
+  description: "Gather symptoms, identify affected components, check recent changes. See investigation-methodology.md Step 1",
+  metadata: { debugStage: "assess", incident: "{incident}",
+              severity: "P1", effort: "5m" }
+)
+```
+
+### Collect Task
+
+```
+TaskCreate(
+  subject: "Collect evidence for {incident}",
+  activeForm: "Collecting evidence",
+  description: "Server logs, CI/CD logs, database state, metrics. See log-and-ci-analysis.md",
+  metadata: { debugStage: "collect", incident: "{incident}",
+              sources: "logs,ci,db", priority: "P1", effort: "10m" },
+  addBlockedBy: ["{assess-task-id}"]
+)
+```
+
+### Analyze Task
+
+```
+TaskCreate(
+  subject: "Analyze root cause of {incident}",
+  activeForm: "Analyzing root cause",
+  description: "Correlate evidence, trace execution paths, identify root cause. See systematic-debugging.md Phase 1-3",
+  metadata: { debugStage: "analyze", incident: "{incident}",
+              technique: "systematic", priority: "P1", effort: "15m" },
+  addBlockedBy: ["{collect-task-id}"]
+)
+```
+
+### Fix Task
+
+```
+TaskCreate(
+  subject: "Fix root cause: {root_cause_summary}",
+  activeForm: "Implementing fix",
+  description: "Address root cause, add defense-in-depth validation. See defense-in-depth.md",
+  metadata: { debugStage: "fix", rootCause: "{root_cause}",
+              priority: "P1", effort: "20m" },
+  addBlockedBy: ["{analyze-task-id}"]
+)
+```
+
+### Verify Task
+
+```
+TaskCreate(
+  subject: "Verify fix with fresh evidence",
+  activeForm: "Verifying fix",
+  description: "Run tests, check build, confirm issue resolved. NO CLAIMS WITHOUT EVIDENCE. See verification.md",
+  metadata: { debugStage: "verify", priority: "P1", effort: "5m" },
+  addBlockedBy: ["{fix-task-id}"]
+)
+```
+
+## Parallel Evidence Collection
+
+For multi-source investigations, spawn parallel collection agents:
+
+```
+// Parallel — no blockedBy between them
+TaskCreate(subject: "Collect CI/CD pipeline logs",
+  metadata: { debugStage: "collect", source: "ci",
+              agentIndex: 1, totalAgents: 3, priority: "P1" })
+
+TaskCreate(subject: "Collect application server logs",
+  metadata: { debugStage: "collect", source: "server",
+              agentIndex: 2, totalAgents: 3, priority: "P1" })
+
+TaskCreate(subject: "Query database for anomalies",
+  metadata: { debugStage: "collect", source: "db",
+              agentIndex: 3, totalAgents: 3, priority: "P1" })
+
+// Analyze blocks on ALL collection completing:
+TaskCreate(subject: "Analyze root cause from collected evidence",
+  addBlockedBy: ["{ci-id}", "{server-id}", "{db-id}"])
+```
+
+## Task Lifecycle
+
+```
+Assess:   pending → in_progress → completed (scope + impact identified)
+Collect:  pending → in_progress → completed (evidence gathered)
+Analyze:  pending → in_progress → completed (root cause identified)
+Fix:      pending → in_progress → completed (fix implemented)
+Verify:   pending → in_progress → completed (fresh verification evidence)
+```
+
+### Re-Investigation Cycle
+
+When fix doesn't resolve the issue → new analyze-fix-verify cycle:
+
+```
+TaskCreate(subject: "Re-analyze: fix attempt {N} failed",
+  addBlockedBy: ["{verify-task-id}"],
+  metadata: { debugStage: "analyze", cycle: 2, priority: "P1" })
+```
+
+Limit to 3 cycles. After cycle 3 → question architecture (systematic-debugging.md Phase 4.5).
+
+## Integration with Cook/Planning
+
+Debug tasks are **separate from** cook/planning phase tasks.
+
+**When cook spawns debugger:**
+1. Cook encounters failing tests → creates debug pipeline tasks
+2. Debug pipeline executes (assess → collect → analyze → fix → verify)
+3. All debug tasks complete → cook marks phase debugging as done
+4. Cook proceeds to next phase
+
+## Report Sync-Back
+
+After investigation completes, write diagnostic report per reporting-standards.md. Report persists as the "source of truth" for cross-session reference (tasks are session-scoped only).
+
+## Error Handling
+
+If `TaskCreate` fails: log warning, continue with sequential debugging. Tasks add visibility and coordination, not core functionality.