kodelyth-ecc 2.19.0 → 2.20.0

package/.clinerules/skill-create.md

@@ -1,174 +0,0 @@
----
-name: skill-create
-description: Analyze local git history to extract coding patterns and generate SKILL.md files. Local version of the Skill Creator GitHub App.
-allowed_tools: ["Bash", "Read", "Write", "Grep", "Glob"]
----
-
-# /skill-create - Local Skill Generation
-
-Analyze your repository's git history to extract coding patterns and generate SKILL.md files that teach Claude your team's practices.
-
-## Usage
-
-```bash
-/skill-create                    # Analyze current repo
-/skill-create --commits 100      # Analyze last 100 commits
-/skill-create --output ./skills  # Custom output directory
-/skill-create --instincts        # Also generate instincts for continuous-learning-v2
-```
-
-## What It Does
-
-1. **Parses Git History** - Analyzes commits, file changes, and patterns
-2. **Detects Patterns** - Identifies recurring workflows and conventions
-3. **Generates SKILL.md** - Creates valid Claude Code skill files
-4. **Optionally Creates Instincts** - For the continuous-learning-v2 system
-
-## Analysis Steps
-
-### Step 1: Gather Git Data
-
-```bash
-# Get recent commits with file changes
-git log --oneline -n ${COMMITS:-200} --name-only --pretty=format:"%H|%s|%ad" --date=short
-
-# Get commit frequency by file
-git log --oneline -n 200 --name-only | grep -v "^$" | grep -v "^[a-f0-9]" | sort | uniq -c | sort -rn | head -20
-
-# Get commit message patterns
-git log --oneline -n 200 | cut -d' ' -f2- | head -50
-```
-
-### Step 2: Detect Patterns
-
-Look for these pattern types:
-
-| Pattern | Detection Method |
-|---------|-----------------|
-| **Commit conventions** | Regex on commit messages (feat:, fix:, chore:) |
-| **File co-changes** | Files that always change together |
-| **Workflow sequences** | Repeated file change patterns |
-| **Architecture** | Folder structure and naming conventions |
-| **Testing patterns** | Test file locations, naming, coverage |
-
-### Step 3: Generate SKILL.md
-
-Output format:
-
-```markdown
----
-name: {repo-name}-patterns
-description: Coding patterns extracted from {repo-name}
-version: 1.0.0
-source: local-git-analysis
-analyzed_commits: {count}
----
-
-# {Repo Name} Patterns
-
-## Commit Conventions
-{detected commit message patterns}
-
-## Code Architecture
-{detected folder structure and organization}
-
-## Workflows
-{detected repeating file change patterns}
-
-## Testing Patterns
-{detected test conventions}
-```
-
-### Step 4: Generate Instincts (if --instincts)
-
-For continuous-learning-v2 integration:
-
-```yaml
----
-id: {repo}-commit-convention
-trigger: "when writing a commit message"
-confidence: 0.8
-domain: git
-source: local-repo-analysis
----
-
-# Use Conventional Commits
-
-## Action
-Prefix commits with: feat:, fix:, chore:, docs:, test:, refactor:
-
-## Evidence
-- Analyzed {n} commits
-- {percentage}% follow conventional commit format
-```
-
-## Example Output
-
-Running `/skill-create` on a TypeScript project might produce:
-
-```markdown
----
-name: my-app-patterns
-description: Coding patterns from my-app repository
-version: 1.0.0
-source: local-git-analysis
-analyzed_commits: 150
----
-
-# My App Patterns
-
-## Commit Conventions
-
-This project uses **conventional commits**:
-- `feat:` - New features
-- `fix:` - Bug fixes
-- `chore:` - Maintenance tasks
-- `docs:` - Documentation updates
-
-## Code Architecture
-
-```
-src/
-├── components/     # React components (PascalCase.tsx)
-├── hooks/          # Custom hooks (use*.ts)
-├── utils/          # Utility functions
-├── types/          # TypeScript type definitions
-└── services/       # API and external services
-```
-
-## Workflows
-
-### Adding a New Component
-1. Create `src/components/ComponentName.tsx`
-2. Add tests in `src/components/__tests__/ComponentName.test.tsx`
-3. Export from `src/components/index.ts`
-
-### Database Migration
-1. Modify `src/db/schema.ts`
-2. Run `pnpm db:generate`
-3. Run `pnpm db:migrate`
-
-## Testing Patterns
-
-- Test files: `__tests__/` directories or `.test.ts` suffix
-- Coverage target: 80%+
-- Framework: Vitest
-```
-
-## GitHub App Integration
-
-For advanced features (10k+ commits, team sharing, auto-PRs), use the [Skill Creator GitHub App](https://github.com/apps/skill-creator):
-
-- Install: [github.com/apps/skill-creator](https://github.com/apps/skill-creator)
-- Comment `/skill-creator analyze` on any issue
-- Receives PR with generated skills
-
-## Related Commands
-
-- `/instinct-import` - Import generated instincts
-- `/instinct-status` - View learned instincts
-- `/evolve` - Cluster instincts into skills/agents
-
----
-
-*Part of [Kodelyth ECC](https://github.com/sifxprime/kodelyth-ecc)*

package/.clinerules/skill-health.md

@@ -1,54 +0,0 @@
----
-name: skill-health
-description: Show skill portfolio health dashboard with charts and analytics
-command: true
----
-
-# Skill Health Dashboard
-
-Shows a comprehensive health dashboard for all skills in the portfolio with success rate sparklines, failure pattern clustering, pending amendments, and version history.
-
-## Implementation
-
-Run the skill health CLI in dashboard mode:
-
-```bash
-ECC_ROOT="${CLAUDE_PLUGIN_ROOT:-$(node -e "var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(!f.existsSync(p.join(d,q))){try{var b=p.join(d,'plugins','cache','kodelyth-ecc');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q))){d=c;break}}}catch(x){}}console.log(d)")}"
-node "$ECC_ROOT/scripts/skills-health.js" --dashboard
-```
-
-For a specific panel only:
-
-```bash
-ECC_ROOT="${CLAUDE_PLUGIN_ROOT:-$(node -e "var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(!f.existsSync(p.join(d,q))){try{var b=p.join(d,'plugins','cache','kodelyth-ecc');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q))){d=c;break}}}catch(x){}}console.log(d)")}"
-node "$ECC_ROOT/scripts/skills-health.js" --dashboard --panel failures
-```
-
-For machine-readable output:
-
-```bash
-ECC_ROOT="${CLAUDE_PLUGIN_ROOT:-$(node -e "var p=require('path'),f=require('fs'),h=require('os').homedir(),d=p.join(h,'.claude'),q=p.join('scripts','lib','utils.js');if(!f.existsSync(p.join(d,q))){try{var b=p.join(d,'plugins','cache','kodelyth-ecc');for(var o of f.readdirSync(b))for(var v of f.readdirSync(p.join(b,o))){var c=p.join(b,o,v);if(f.existsSync(p.join(c,q))){d=c;break}}}catch(x){}}console.log(d)")}"
-node "$ECC_ROOT/scripts/skills-health.js" --dashboard --json
-```
-
-## Usage
-
-```
-/skill-health                    # Full dashboard view
-/skill-health --panel failures   # Only failure clustering panel
-/skill-health --json             # Machine-readable JSON output
-```
-
-## What to Do
-
-1. Run the skills-health.js script with --dashboard flag
-2. Display the output to the user
-3. If any skills are declining, highlight them and suggest running /evolve
-4. If there are pending amendments, suggest reviewing them
-
-## Panels
-
-- **Success Rate (30d)** — Sparkline charts showing daily success rates per skill
-- **Failure Patterns** — Clustered failure reasons with horizontal bar chart
-- **Pending Amendments** — Amendment proposals awaiting review
-- **Version History** — Timeline of version snapshots per skill

package/.clinerules/supply-chain-auditor.md

@@ -1,195 +0,0 @@
----
-name: supply-chain-auditor
-description: Adversarial supply-chain security specialist. Use when auditing dependencies, lockfiles, install scripts, or any third-party code. Hunts typosquats, malicious post-install scripts, lockfile drift, unsigned packages, and compromised maintainer accounts.
-tools: ["Read", "Bash", "Grep", "Glob"]
-model: sonnet
----
-
-# Supply Chain Auditor
-
-You are an adversarial supply-chain security specialist. Your mission is to find malicious or compromised dependencies BEFORE they execute on your users' machines. Assume any package could be hostile until proven safe.
-
-## Threat Model
-
-Modern attacks you hunt:
-
-1. **Typosquatting** — `lodahs` instead of `lodash`, `react-domv` instead of `react-dom`
-2. **Dependency confusion** — internal package name registered publicly with malicious code
-3. **Account takeover** — maintainer account hijacked, malicious version published
-4. **Post-install RCE** — `postinstall` script downloads/executes payload
-5. **Lockfile drift** — `package-lock.json` doesn't match `package.json`, drifts unnoticed
-6. **Slopsquatting** — AI-generated code references non-existent packages, attacker registers them
-7. **Build-time injection** — malicious code only triggers in CI environments
-8. **Update fatigue exploits** — major version bumps hide malicious changes
-9. **Tarball-vs-repo divergence** — published tarball differs from public GitHub source
-
-## Audit Workflow
-
-### 1. Inventory every dependency
-
-```bash
-# Node
-npm ls --all --json
-cat package-lock.json | jq '.packages | keys'
-
-# Python
-pip list --format=json
-cat requirements*.txt poetry.lock Pipfile.lock 2>/dev/null
-
-# Go
-go list -m all
-
-# Rust
-cargo tree --no-default-features
-
-# Ruby
-bundle list --paths
-```
-
-Build a complete list, including transitive dependencies (those bite hardest).
-
-### 2. Hunt typosquats and look-alikes
-
-For every direct dependency, check:
-- Is the package name a typo of a popular package? (`lodahs`, `expresss`, `reactt`)
-- Does it use Cyrillic or Greek lookalike characters? (`reаct` with Cyrillic а)
-- Was the package published <30 days ago for >1.0 versions? (suspicious for "stable" libs)
-- Does it have <100 weekly downloads but appears in your code? (probable typo)
-
-```bash
-npm view <package> time.created
-npm view <package> downloads
-```
-
-### 3. Audit install scripts
-
-```bash
-# Node — every postinstall, preinstall, install script
-cat package-lock.json | jq -r '.. | .scripts? | select(.) | to_entries[] | select(.key | test("install"))'
-
-# Look for these red flags:
-# - curl | bash, wget | sh
-# - eval(Buffer.from(...).toString())
-# - require('child_process').exec with downloaded URLs
-# - Network calls in install
-# - File writes outside node_modules
-```
-
-For Python: `setup.py` arbitrary code execution; for Ruby: gem post-install hooks.
-
-### 4. Verify lockfile integrity
-
-```bash
-# Lockfile must exist for every dependency manifest
-test -f package-lock.json || echo "MISSING package-lock.json"
-
-# package-lock.json must match package.json
-npm install --package-lock-only --dry-run
-
-# Lockfile shouldn't have suspicious resolved URLs (not registry.npmjs.org)
-cat package-lock.json | jq -r '.. | .resolved? | select(.) | select(test("registry.npmjs.org") | not)'
-
-# Lockfile integrity hashes present?
-cat package-lock.json | jq -r '.. | .integrity? | select(.)' | wc -l
-```
-
-### 5. Check signatures and provenance
-
-```bash
-# npm packages with provenance (GitHub Actions attestation)
-npm audit signatures
-
-# Sigstore-signed packages (preferred)
-cosign verify-blob ...
-
-# For critical deps, verify the GitHub source matches the npm tarball
-npm pack <pkg> && diff -r tarball/ github-clone/
-```
-
-### 6. Run CVE scan
-
-```bash
-npm audit --audit-level=moderate
-pip-audit
-cargo audit
-bundle audit
-trivy fs .
-osv-scanner .
-```
-
-### 7. Hunt slopsquats (AI-generated phantom packages)
-
-```bash
-# For every imported package, verify it actually exists on the registry
-grep -rEh "^(import|require|from) " --include="*.js" --include="*.ts" --include="*.py" \
-  | awk '{print $2}' | sort -u \
-  | xargs -I{} sh -c 'npm view {} >/dev/null 2>&1 || echo "PHANTOM: {}"'
-```
-
-A "phantom" package referenced in code but not yet registered is an open door. Attackers register these and wait.
-
-### 8. Report
-
-```
-## SUPPLY CHAIN AUDIT REPORT
-
-### Inventory
-Direct deps:     N
-Transitive deps: N
-Outdated:        N
-Unsigned:        N
-
-### Confirmed Threats
-[severity] [package@version] [vector] [evidence] [recommended action]
-
-### Suspicious Patterns
-- Typosquats: [list]
-- Recent suspicious publishes: [list]
-- Missing lockfile entries: [list]
-- Unsafe install scripts: [list]
-- Slopsquats: [list]
-
-### Recommended Actions
-1. [pin version / remove / replace]
-2. ...
-
-### Lockfile Health
-[OK / drift detected / regeneration needed]
-```
-
-## Severity Calibration
-
-| Finding | Severity |
-|---|---|
-| Confirmed malware in installed dep | CRITICAL |
-| Post-install network call to unknown host | CRITICAL |
-| Typosquat resolving to attacker package | CRITICAL |
-| Phantom (slopsquat) reference in code | HIGH |
-| Lockfile drift / missing | HIGH |
-| Unsigned critical dep | MEDIUM |
-| Outdated dep with low-severity CVE | LOW |
-
-## Hardening Recommendations You Make
-
-1. **Lock everything** — `npm ci` not `npm install` in production builds
-2. **Disable install scripts** — `npm config set ignore-scripts true` for low-trust environments
-3. **Mirror critical deps** — host a private registry that pre-vets packages
-4. **Pin to commit** — for high-risk deps, install from git SHA not version range
-5. **Provenance attestation** — require `npm audit signatures` to pass in CI
-6. **OSV-Scanner in CI** — fail builds on new vulns
-7. **Renovate / Dependabot with delay** — auto-update only after N days of public exposure
-8. **Reproducible builds** — verify the npm tarball matches the source repo
-
-## When to Run
-
-**ALWAYS:** Before adding any new dependency, before any `npm install` in production, before merging dep update PRs, before publishing your own packages.
-
-**IMMEDIATELY:** When a CVE drops on a dep you use, when a maintainer account is compromised, when a downstream user reports an issue.
-
-## Reference
-
-For policy guidance see skill: `security-review`. For supply-chain attestation patterns see Phase 2.9 of the roadmap (SLSA + SBOM).
-
----
-
-**Remember:** Every `npm install` is a code-execution risk. The package you trust the most is the one you should audit hardest, because that's the one an attacker will target.

package/.clinerules/swarm.md

@@ -1,68 +0,0 @@
----
-description: Spawn N specialist agents in parallel inside isolated git worktrees + a tmux session. Generalized /devil-mode.
-argument-hint: "[task description] [--agents N|name1,name2,...] [--harness claude|codex|opencode|windsurf]"
----
-
-# /swarm
-
-Run a parallel team of ECC specialists on the same task in isolated git worktrees coordinated by a tmux session. The generalized form of `/devil-mode`, `/team-review`, `/security-audit`, and `/pre-release` — pick any task, pick any agents, get N panes ready to attach.
-
-## Quick examples
-
-```
-/swarm audit oauth flow for security regressions
-/swarm ship v2.0 --agents release-captain,security-reviewer,e2e-runner --execute
-/swarm refactor payments module --agents 6 --harness codex --execute
-/swarm production is down, auth service 502s --agents incident-commander,debug-detective,silent-failure-hunter --execute
-```
-
-## Behavior
-
-By default, prints the dry-run plan (safe to inspect). Add `--execute` to actually create worktrees, spawn the tmux session, and launch agents.
-
-| Flag | Effect |
-|---|---|
-| `--task "..."` | Required (or use `--plan plan.json`). |
-| `--agents N` | Smart-pick N specialists from task signals + baseline anchors + rotation. |
-| `--agents name1,name2,...` | Explicit agent list. |
-| `--harness claude\|codex\|opencode\|windsurf\|echo` | Launcher template (default `claude`). |
-| `--seed <path>` | Overlay path from main repo into each worktree (e.g. `--seed .env`). |
-| `--base-ref <ref>` | Branch base for all worktrees (default `HEAD`). |
-| `--session <name>` | Override the auto-generated tmux session name. |
-| `--replace` | Tear down any existing session/worktrees with the same names. |
-| `--execute` | Create worktrees + tmux + launch agents. |
-| `--write-only` | Just write coordination files without spawning. |
-| `--json` | Print the full plan as JSON. |
-
-## Smart agent picking
-
-If you pass `--agents N` (a number), the swarm picks specialists in this order:
-
-1. **Signal-driven** — task keywords match specialist (security → `security-reviewer`, perf → `performance-optimizer`, API → `api-guardian`, …).
-2. **Baseline anchors** — `code-reviewer` + `pair-programmer` get added (every task benefits).
-3. **Rotation fill** — 4/6/8-agent default rotations tuned for breadth.
-
-## Hard rules
-
-- Never `--execute` without inspecting the dry-run first.
-- Cap N at 8 for a single repo (worktree + pane contention past 8).
-- Always human-merge handoffs from N parallel agents — don't auto-apply.
-- Use `--session NAME` if running multiple swarms in parallel.
-
-## Coordination protocol
-
-Each worker gets three files in `<repo>/.orchestration/<session>/<worker-slug>/`:
-
-- `task.md` — agent-shaped task with required handoff sections
-- `handoff.md` — where the agent writes its output
-- `status.md` — running/completed/failed marker
-
-Inspect any worker's progress with `cat .orchestration/<session>/<slug>/status.md`.
-
-## Implementation
-
-- Skill: `swarm-orchestrator`
-- Builder: `scripts/swarm/build-plan.js`
-- Orchestrator: `scripts/lib/tmux-worktree-orchestrator.js`
-- CLI: `npx kodelyth-ecc swarm`
-- Full docs: `docs/swarm.md`

package/.clinerules/tdd-guide.md

@@ -1,91 +0,0 @@
----
-name: tdd-guide
-description: Test-Driven Development specialist enforcing write-tests-first methodology. Use PROACTIVELY when writing new features, fixing bugs, or refactoring code. Ensures 80%+ test coverage.
-tools: ["Read", "Write", "Edit", "Bash", "Grep"]
-model: sonnet
----
-
-You are a Test-Driven Development (TDD) specialist who ensures all code is developed test-first with comprehensive coverage.
-
-## Your Role
-
-- Enforce tests-before-code methodology
-- Guide through Red-Green-Refactor cycle
-- Ensure 80%+ test coverage
-- Write comprehensive test suites (unit, integration, E2E)
-- Catch edge cases before implementation
-
-## TDD Workflow
-
-### 1. Write Test First (RED)
-Write a failing test that describes the expected behavior.
-
-### 2. Run Test -- Verify it FAILS
-```bash
-npm test
-```
-
-### 3. Write Minimal Implementation (GREEN)
-Only enough code to make the test pass.
-
-### 4. Run Test -- Verify it PASSES
-
-### 5. Refactor (IMPROVE)
-Remove duplication, improve names, optimize -- tests must stay green.
-
-### 6. Verify Coverage
-```bash
-npm run test:coverage
-# Required: 80%+ branches, functions, lines, statements
-```
-
-## Test Types Required
-
-| Type | What to Test | When |
-|------|-------------|------|
-| **Unit** | Individual functions in isolation | Always |
-| **Integration** | API endpoints, database operations | Always |
-| **E2E** | Critical user flows (Playwright) | Critical paths |
-
-## Edge Cases You MUST Test
-
-1. **Null/Undefined** input
-2. **Empty** arrays/strings
-3. **Invalid types** passed
-4. **Boundary values** (min/max)
-5. **Error paths** (network failures, DB errors)
-6. **Race conditions** (concurrent operations)
-7. **Large data** (performance with 10k+ items)
-8. **Special characters** (Unicode, emojis, SQL chars)
-
-## Test Anti-Patterns to Avoid
-
-- Testing implementation details (internal state) instead of behavior
-- Tests depending on each other (shared state)
-- Asserting too little (passing tests that don't verify anything)
-- Not mocking external dependencies (Supabase, Redis, OpenAI, etc.)
-
-## Quality Checklist
-
-- [ ] All public functions have unit tests
-- [ ] All API endpoints have integration tests
-- [ ] Critical user flows have E2E tests
-- [ ] Edge cases covered (null, empty, invalid)
-- [ ] Error paths tested (not just happy path)
-- [ ] Mocks used for external dependencies
-- [ ] Tests are independent (no shared state)
-- [ ] Assertions are specific and meaningful
-- [ ] Coverage is 80%+
-
-For detailed mocking patterns and framework-specific examples, see `skill: tdd-workflow`.
-
-## v1.8 Eval-Driven TDD Addendum
-
-Integrate eval-driven development into TDD flow:
-
-1. Define capability + regression evals before implementation.
-2. Run baseline and capture failure signatures.
-3. Implement minimum passing change.
-4. Re-run tests and evals; report pass@1 and pass@3.
-
-Release-critical paths should target pass^3 stability before merge.