kodelyth-ecc 2.19.0 → 2.21.0

package/.kimi/skills/gan-style-harness/SKILL.md

@@ -1,278 +0,0 @@
----
-name: gan-style-harness
-description: "GAN-inspired Generator-Evaluator agent harness for building high-quality applications autonomously. Based on Anthropic's March 2026 harness design paper."
-origin: ECC-community
-tools: Read, Write, Edit, Bash, Grep, Glob, Task
----
-
-# GAN-Style Harness Skill
-
-> Inspired by [Anthropic's Harness Design for Long-Running Application Development](https://www.anthropic.com/engineering/harness-design-long-running-apps) (March 24, 2026)
-
-A multi-agent harness that separates **generation** from **evaluation**, creating an adversarial feedback loop that drives quality far beyond what a single agent can achieve.
-
-## Core Insight
-
-> When asked to evaluate their own work, agents are pathological optimists — they praise mediocre output and talk themselves out of legitimate issues. But engineering a **separate evaluator** to be ruthlessly strict is far more tractable than teaching a generator to self-critique.
-
-This is the same dynamic as GANs (Generative Adversarial Networks): the Generator produces, the Evaluator critiques, and that feedback drives the next iteration.
-
-## When to Use
-
-- Building complete applications from a one-line prompt
-- Frontend design tasks requiring high visual quality
-- Full-stack projects that need working features, not just code
-- Any task where "AI slop" aesthetics are unacceptable
-- Projects where you want to invest $50-200 for production-quality output
-
-## When NOT to Use
-
-- Quick single-file fixes (use standard `claude -p`)
-- Tasks with tight budget constraints (<$10)
-- Simple refactoring (use de-sloppify pattern instead)
-- Tasks that are already well-specified with tests (use TDD workflow)
-
-## Architecture
-
-```
-                    ┌─────────────┐
-                    │   PLANNER   │
-                    │  (Opus 4.6) │
-                    └──────┬──────┘
-                           │ Product Spec
-                           │ (features, sprints, design direction)
-                           ▼
-              ┌────────────────────────┐
-              │                        │
-              │   GENERATOR-EVALUATOR  │
-              │      FEEDBACK LOOP     │
-              │                        │
-              │  ┌──────────┐          │
-              │  │GENERATOR │--build-->│──┐
-              │  │(Opus 4.6)│          │  │
-              │  └────▲─────┘          │  │
-              │       │                │  │ live app
-              │    feedback             │  │
-              │       │                │  │
-              │  ┌────┴─────┐          │  │
-              │  │EVALUATOR │<-test----│──┘
-              │  │(Opus 4.6)│          │
-              │  │+Playwright│         │
-              │  └──────────┘          │
-              │                        │
-              │   5-15 iterations      │
-              └────────────────────────┘
-```
-
-## The Three Agents
-
-### 1. Planner Agent
-
-**Role:** Product manager — expands a brief prompt into a full product specification.
-
-**Key behaviors:**
-- Takes a one-line prompt and produces a 16-feature, multi-sprint specification
-- Defines user stories, technical requirements, and visual design direction
-- Is deliberately **ambitious** — conservative planning leads to underwhelming results
-- Produces evaluation criteria that the Evaluator will use later
-
-**Model:** Opus 4.6 (needs deep reasoning for spec expansion)
-
-### 2. Generator Agent
-
-**Role:** Developer — implements features according to the spec.
-
-**Key behaviors:**
-- Works in structured sprints (or continuous mode with newer models)
-- Negotiates a "sprint contract" with the Evaluator before writing code
-- Uses full-stack tooling: React, FastAPI/Express, databases, CSS
-- Manages git for version control between iterations
-- Reads Evaluator feedback and incorporates it in next iteration
-
-**Model:** Opus 4.6 (needs strong coding capability)
-
-### 3. Evaluator Agent
-
-**Role:** QA engineer — tests the live running application, not just code.
-
-**Key behaviors:**
-- Uses **Playwright MCP** to interact with the live application
-- Clicks through features, fills forms, tests API endpoints
-- Scores against four criteria (configurable):
-  1. **Design Quality** — Does it feel like a coherent whole?
-  2. **Originality** — Custom decisions vs. template/AI patterns?
-  3. **Craft** — Typography, spacing, animations, micro-interactions?
-  4. **Functionality** — Do all features actually work?
-- Returns structured feedback with scores and specific issues
-- Is engineered to be **ruthlessly strict** — never praises mediocre work
-
-**Model:** Opus 4.6 (needs strong judgment + tool use)
-
-## Evaluation Criteria
-
-The default four criteria, each scored 1-10:
-
-```markdown
-## Evaluation Rubric
-
-### Design Quality (weight: 0.3)
-- 1-3: Generic, template-like, "AI slop" aesthetics
-- 4-6: Competent but unremarkable, follows conventions
-- 7-8: Distinctive, cohesive visual identity
-- 9-10: Could pass for a professional designer's work
-
-### Originality (weight: 0.2)
-- 1-3: Default colors, stock layouts, no personality
-- 4-6: Some custom choices, mostly standard patterns
-- 7-8: Clear creative vision, unique approach
-- 9-10: Surprising, delightful, genuinely novel
-
-### Craft (weight: 0.3)
-- 1-3: Broken layouts, missing states, no animations
-- 4-6: Works but feels rough, inconsistent spacing
-- 7-8: Polished, smooth transitions, responsive
-- 9-10: Pixel-perfect, delightful micro-interactions
-
-### Functionality (weight: 0.2)
-- 1-3: Core features broken or missing
-- 4-6: Happy path works, edge cases fail
-- 7-8: All features work, good error handling
-- 9-10: Bulletproof, handles every edge case
-```
-
-### Scoring
-
-- **Weighted score** = sum of (criterion_score * weight)
-- **Pass threshold** = 7.0 (configurable)
-- **Max iterations** = 15 (configurable, typically 5-15 sufficient)
-
-## Usage
-
-### Via Command
-
-```bash
-# Full three-agent harness
-/project:gan-build "Build a project management app with Kanban boards, team collaboration, and dark mode"
-
-# With custom config
-/project:gan-build "Build a recipe sharing platform" --max-iterations 10 --pass-threshold 7.5
-
-# Frontend design mode (generator + evaluator only, no planner)
-/project:gan-design "Create a landing page for a crypto portfolio tracker"
-```
-
-### Via Shell Script
-
-```bash
-# Basic usage
-./scripts/gan-harness.sh "Build a music streaming dashboard"
-
-# With options
-GAN_MAX_ITERATIONS=10 \
-GAN_PASS_THRESHOLD=7.5 \
-GAN_EVAL_CRITERIA="functionality,performance,security" \
-./scripts/gan-harness.sh "Build a REST API for task management"
-```
-
-### Via Claude Code (Manual)
-
-```bash
-# Step 1: Plan
-claude -p --model opus "You are a Product Planner. Read PLANNER_PROMPT.md. Expand this brief into a full product spec: 'Build a Kanban board app'. Write spec to spec.md"
-
-# Step 2: Generate (iteration 1)
-claude -p --model opus "You are a Generator. Read spec.md. Implement Sprint 1. Start the dev server on port 3000."
-
-# Step 3: Evaluate (iteration 1)
-claude -p --model opus --allowedTools "Read,Bash,mcp__playwright__*" "You are an Evaluator. Read EVALUATOR_PROMPT.md. Test the live app at http://localhost:3000. Score against the rubric. Write feedback to feedback-001.md"
-
-# Step 4: Generate (iteration 2 — reads feedback)
-claude -p --model opus "You are a Generator. Read spec.md and feedback-001.md. Address all issues. Improve the scores."
-
-# Repeat steps 3-4 until pass threshold met
-```
-
-## Evolution Across Model Capabilities
-
-The harness should simplify as models improve. Following Anthropic's evolution:
-
-### Stage 1 — Weaker Models (Sonnet-class)
-- Full sprint decomposition required
-- Context resets between sprints (avoid context anxiety)
-- 2-agent minimum: Initializer + Coding Agent
-- Heavy scaffolding compensates for model limitations
-
-### Stage 2 — Capable Models (Opus 4.5-class)
-- Full 3-agent harness: Planner + Generator + Evaluator
-- Sprint contracts before each implementation phase
-- 10-sprint decomposition for complex apps
-- Context resets still useful but less critical
-
-### Stage 3 — Frontier Models (Opus 4.6-class)
-- Simplified harness: single planning pass, continuous generation
-- Evaluation reduced to single end-pass (model is smarter)
-- No sprint structure needed
-- Automatic compaction handles context growth
-
-> **Key principle:** Every harness component encodes an assumption about what the model can't do alone. When models improve, re-test those assumptions. Strip away what's no longer needed.
-
-## Configuration
-
-### Environment Variables
-
-| Variable | Default | Description |
-|----------|---------|-------------|
-| `GAN_MAX_ITERATIONS` | `15` | Maximum generator-evaluator cycles |
-| `GAN_PASS_THRESHOLD` | `7.0` | Weighted score to pass (1-10) |
-| `GAN_PLANNER_MODEL` | `opus` | Model for planning agent |
-| `GAN_GENERATOR_MODEL` | `opus` | Model for generator agent |
-| `GAN_EVALUATOR_MODEL` | `opus` | Model for evaluator agent |
-| `GAN_EVAL_CRITERIA` | `design,originality,craft,functionality` | Comma-separated criteria |
-| `GAN_DEV_SERVER_PORT` | `3000` | Port for the live app |
-| `GAN_DEV_SERVER_CMD` | `npm run dev` | Command to start dev server |
-| `GAN_PROJECT_DIR` | `.` | Project working directory |
-| `GAN_SKIP_PLANNER` | `false` | Skip planner, use spec directly |
-| `GAN_EVAL_MODE` | `playwright` | `playwright`, `screenshot`, or `code-only` |
-
-### Evaluation Modes
-
-| Mode | Tools | Best For |
-|------|-------|----------|
-| `playwright` | Browser MCP + live interaction | Full-stack apps with UI |
-| `screenshot` | Screenshot + visual analysis | Static sites, design-only |
-| `code-only` | Tests + linting + build | APIs, libraries, CLI tools |
-
-## Anti-Patterns
-
-1. **Evaluator too lenient** — If the evaluator passes everything on iteration 1, your rubric is too generous. Tighten scoring criteria and add explicit penalties for common AI patterns.
-
-2. **Generator ignoring feedback** — Ensure feedback is passed as a file, not inline. The generator should read `feedback-NNN.md` at the start of each iteration.
-
-3. **Infinite loops** — Always set `GAN_MAX_ITERATIONS`. If the generator can't improve past a score plateau after 3 iterations, stop and flag for human review.
-
-4. **Evaluator testing superficially** — The evaluator must use Playwright to **interact** with the live app, not just screenshot it. Click buttons, fill forms, test error states.
-
-5. **Evaluator praising its own fixes** — Never let the evaluator suggest fixes and then evaluate those fixes. The evaluator only critiques; the generator fixes.
-
-6. **Context exhaustion** — For long sessions, use Claude Agent SDK's automatic compaction or reset context between major phases.
-
-## Results: What to Expect
-
-Based on Anthropic's published results:
-
-| Metric | Solo Agent | GAN Harness | Improvement |
-|--------|-----------|-------------|-------------|
-| Time | 20 min | 4-6 hours | 12-18x longer |
-| Cost | $9 | $125-200 | 14-22x more |
-| Quality | Barely functional | Production-ready | Phase change |
-| Core features | Broken | All working | N/A |
-| Design | Generic AI slop | Distinctive, polished | N/A |
-
-**The tradeoff is clear:** ~20x more time and cost for a qualitative leap in output quality. This is for projects where quality matters.
-
-## References
-
-- [Anthropic: Harness Design for Long-Running Apps](https://www.anthropic.com/engineering/harness-design-long-running-apps) — Original paper by Prithvi Rajasekaran
-- [Epsilla: The GAN-Style Agent Loop](https://www.epsilla.com/blogs/anthropic-harness-engineering-multi-agent-gan-architecture) — Architecture deconstruction
-- [Martin Fowler: Harness Engineering](https://martinfowler.com/articles/exploring-gen-ai/harness-engineering.html) — Broader industry context
-- [OpenAI: Harness Engineering](https://openai.com/index/harness-engineering/) — OpenAI's parallel work

package/.kimi/skills/git-mastery/SKILL.md

@@ -1,366 +0,0 @@
----
-name: git-mastery
-description: Advanced Git workflows, branching strategies, history management, and team collaboration patterns. Covers trunk-based development, interactive rebase, bisect debugging, monorepo workflows, and professional commit hygiene. Powered by Kodelyth.
-origin: Kodelyth
----
-
-# Git Mastery — Advanced Git Workflows
-
-Professional-grade Git patterns for individuals and teams. Powered by Kodelyth.
-
-## When to Use
-
-- Setting up a branching strategy for a team
-- Learning advanced Git commands (rebase, bisect, worktree)
-- Fixing a messy commit history before merging
-- Debugging when a bug was introduced using `git bisect`
-- Working in a monorepo
-- Enforcing commit message standards
-
----
-
-## Branching Strategies
-
-### Trunk-Based Development (Recommended for most teams)
-
-```
-main (always deployable)
- ├── feat/add-oauth      (short-lived, < 2 days)
- ├── fix/null-check      (short-lived, < 1 day)
- └── chore/upgrade-deps  (short-lived)
-```
-
-**Rules:**
-- All branches off `main`, all PRs back to `main`
-- Branches live < 2 days — longer = higher merge conflict risk
-- Use feature flags to ship incomplete features safely
-- Every commit to `main` is potentially deployable
-
-```bash
-# Start a feature
-git checkout main && git pull
-git checkout -b feat/user-authentication
-
-# Sync with main daily (rebase, don't merge)
-git fetch origin
-git rebase origin/main
-
-# PR → squash merge → delete branch
-```
-
-### Gitflow (For versioned software with release cycles)
-
-```
-main          (production releases only)
-develop       (integration branch)
- ├── feature/xyz     (features off develop)
- ├── release/1.2.0   (stabilization)
- └── hotfix/critical (off main, merges to main + develop)
-```
-
-**Use when**: You ship versioned releases (mobile apps, libraries, enterprise software)
-**Avoid when**: You deploy continuously (web apps, SaaS)
-
-### Ship / Show / Ask (For experienced teams)
-
-```
-Ship: Commit directly to main (trivial changes, docs, chores)
-Show: Open PR, merge immediately without review (small, safe changes)
-Ask:  Open PR, wait for review (significant changes, risk)
-```
-
----
-
-## Commit Message Mastery
-
-### Conventional Commits Format
-
-```
-<type>(<scope>): <description>
-
-[optional body]
-
-[optional footer]
-```
-
-**Types:**
-```
-feat:     New feature (triggers MINOR version bump)
-fix:      Bug fix (triggers PATCH version bump)
-docs:     Documentation only
-style:    Formatting (no logic change)
-refactor: Code restructure (no feature, no fix)
-test:     Adding or fixing tests
-chore:    Build, tooling, dependencies
-perf:     Performance improvement
-ci:       CI/CD changes
-revert:   Reverting a commit
-```
-
-**Examples:**
-```bash
-# Good
-git commit -m "feat(auth): add OAuth2 login with Google"
-git commit -m "fix(cart): prevent double-submission on slow networks"
-git commit -m "refactor(user): extract UserService from UserController"
-git commit -m "test(payment): add integration test for failed webhooks"
-
-# Bad
-git commit -m "fix bug"
-git commit -m "WIP"
-git commit -m "changes"
-git commit -m "asdf"
-```
-
-**With body (for significant changes):**
-```bash
-git commit -m "feat(billing): add Stripe subscription management
-
-Adds three subscription tiers: Free, Pro ($29/mo), Enterprise ($99/mo).
-Payment flow uses Stripe Checkout. Subscription status synced via webhooks.
-
-Breaking: removes legacy PayPal integration (deprecated since v1.3)
-Closes #234"
-```
-
----
-
-## Interactive Rebase — History Surgery
-
-### Squash WIP commits before merging
-
-```bash
-# You have 5 messy commits you want to clean up
-git log --oneline -5
-# abc1234 fix
-# def5678 WIP
-# ghi9012 more changes
-# jkl3456 actually fix it
-# mno7890 feat: add user search
-
-# Squash all 5 into 1 clean commit
-git rebase -i HEAD~5
-
-# In the editor:
-# pick mno7890 feat: add user search
-# squash jkl3456 actually fix it
-# squash ghi9012 more changes
-# squash def5678 WIP
-# squash abc1234 fix
-# → writes a clean single commit message
-```
-
-### Fix a commit message (already pushed? see below)
-
-```bash
-# Fix the last commit message
-git commit --amend -m "feat(search): add full-text user search with pagination"
-
-# Fix a message 3 commits back
-git rebase -i HEAD~3
-# Change "pick" to "reword" on the target commit
-```
-
-### Fixup — add changes to a previous commit
-
-```bash
-# You forgot to add a file to a commit 2 commits ago
-git add forgotten-file.ts
-git commit --fixup HEAD~2
-
-# Then squash fixup into its target automatically
-git rebase -i --autosquash HEAD~3
-```
-
-### Split a large commit into smaller ones
-
-```bash
-git rebase -i HEAD~1
-# Change "pick" to "edit" on the commit to split
-
-# Now git stops at that commit
-git reset HEAD~1         # unstage all changes
-git add -p               # selectively stage first logical change
-git commit -m "feat: add user model"
-git add -p               # stage second logical change
-git commit -m "feat: add user repository"
-git rebase --continue    # finish the rebase
-```
-
----
-
-## Git Bisect — Binary Search for Bugs
-
-When you know "it worked in v1.2, broke somewhere before v1.5":
-
-```bash
-git bisect start
-git bisect bad                    # current HEAD is broken
-git bisect good v1.2.0            # this tag/commit was good
-
-# Git checks out the midpoint automatically
-# Test it (run your test, check the behavior)
-git bisect good   # if this commit is OK
-git bisect bad    # if this commit has the bug
-
-# Repeat — git halves the search space each time
-# With 1000 commits, it takes at most 10 steps
-
-# Automate with a test script
-git bisect run npm test -- --grep "the failing test"
-
-# When done
-git bisect reset  # returns to original HEAD
-```
-
----
-
-## Git Worktrees — Multiple Branches Simultaneously
-
-Work on a hotfix while keeping your feature branch untouched:
-
-```bash
-# Create a new worktree (separate directory, same repo)
-git worktree add ../hotfix-payment hotfix/payment-crash
-
-# Now you have two working directories:
-#   ~/project/           → your feature branch
-#   ~/hotfix-payment/    → the hotfix branch
-
-# Work in the hotfix directory, commit, push, PR
-cd ../hotfix-payment
-# ... make fix ...
-git commit -m "fix(payment): prevent double charge on retry"
-git push origin hotfix/payment-crash
-
-# Clean up when done
-cd ~/project
-git worktree remove ../hotfix-payment
-```
-
----
-
-## Git Log — Find Anything in History
-
-```bash
-# See changes to a specific file over time
-git log --follow --oneline -- src/components/Auth.tsx
-
-# See who last changed each line (with commit + author)
-git blame src/components/Auth.tsx
-
-# Search commit messages
-git log --oneline --grep="payment"
-
-# Search code changes (find when a string was added or removed)
-git log -S "functionName" --oneline
-
-# See what changed between two tags
-git log v1.2.0..v1.3.0 --oneline
-
-# Visualize branch graph
-git log --oneline --graph --decorate --all
-```
-
----
-
-## Git Stash — Save Work in Progress
-
-```bash
-# Stash everything (tracked + untracked)
-git stash push -u -m "WIP: halfway through auth refactor"
-
-# List stashes
-git stash list
-# stash@{0}: WIP: halfway through auth refactor
-# stash@{1}: quick fix attempt
-
-# Apply and remove the latest stash
-git stash pop
-
-# Apply a specific stash (keep it)
-git stash apply stash@{1}
-
-# Stash only specific files
-git stash push -m "partial" -- src/auth.ts src/user.ts
-
-# Drop a stash
-git stash drop stash@{1}
-```
-
----
-
-## Monorepo Git Patterns
-
-```bash
-# Only run CI for changed packages
-git diff --name-only origin/main...HEAD | grep "^packages/"
-
-# Sparse checkout — only clone part of a large monorepo
-git clone --filter=blob:none --sparse https://github.com/org/monorepo
-git sparse-checkout init --cone
-git sparse-checkout set packages/my-package
-
-# Tag per package
-git tag packages/auth@1.2.0
-git tag packages/api@2.0.1
-
-# Find which package a file belongs to
-git log --oneline -- packages/billing/
-```
-
----
-
-## Branch Protection Rules (GitHub/GitLab)
-
-```yaml
-# Recommended branch protection for main:
-required_status_checks:
-  strict: true           # must be up to date with main
-  contexts:
-    - "CI / test"
-    - "CI / lint"
-    - "CI / typecheck"
-
-required_pull_request_reviews:
-  required_approving_review_count: 1
-  dismiss_stale_reviews: true
-  require_code_owner_reviews: true
-
-restrictions:
-  push: []               # nobody can push directly to main
-  force_push: false      # never allow force push to main
-  delete: false          # never allow delete of main
-```
-
----
-
-## Emergency Recovery
-
-```bash
-# Accidentally deleted a branch?
-git reflog                           # find the last commit hash
-git checkout -b recovered-branch <hash>
-
-# Accidentally force pushed?
-git reflog origin/main              # see the hash before the force push
-git push origin <hash>:main --force # restore it
-
-# Committed to the wrong branch?
-git log --oneline -3                # note the commit hash
-git reset HEAD~1 --soft             # undo commit, keep changes staged
-git stash                           # stash the changes
-git checkout correct-branch
-git stash pop                       # apply changes to correct branch
-git commit -m "feat: the actual message"
-
-# Accidentally committed secrets?
-# 1. Rotate the secret IMMEDIATELY (assume it's compromised)
-# 2. Remove from history:
-git filter-repo --path secrets.env --invert-paths
-# OR use BFG Repo Cleaner for simpler cases
-```
-
----
-
-> Powered by Kodelyth — Git is not just version control, it's your project's memory.