kodelyth-ecc 2.19.0 → 2.20.0

package/.aider-ecc/skills/agent-sort/SKILL.md

@@ -1,215 +0,0 @@
----
-name: agent-sort
-description: Build an evidence-backed ECC install plan for a specific repo by sorting skills, commands, rules, hooks, and extras into DAILY vs LIBRARY buckets using parallel repo-aware review passes. Use when ECC should be trimmed to what a project actually needs instead of loading the full bundle.
-origin: ECC
----
-
-# Agent Sort
-
-Use this skill when a repo needs a project-specific ECC surface instead of the default full install.
-
-The goal is not to guess what "feels useful." The goal is to classify ECC components with evidence from the actual codebase.
-
-## When to Use
-
-- A project only needs a subset of ECC and full installs are too noisy
-- The repo stack is clear, but nobody wants to hand-curate skills one by one
-- A team wants a repeatable install decision backed by grep evidence instead of opinion
-- You need to separate always-loaded daily workflow surfaces from searchable library/reference surfaces
-- A repo has drifted into the wrong language, rule, or hook set and needs cleanup
-
-## Non-Negotiable Rules
-
-- Use the current repository as the source of truth, not generic preferences
-- Every DAILY decision must cite concrete repo evidence
-- LIBRARY does not mean "delete"; it means "keep accessible without loading by default"
-- Do not install hooks, rules, or scripts that the current repo cannot use
-- Prefer ECC-native surfaces; do not introduce a second install system
-
-## Outputs
-
-Produce these artifacts in order:
-
-1. DAILY inventory
-2. LIBRARY inventory
-3. install plan
-4. verification report
-5. optional `skill-library` router if the project wants one
-
-## Classification Model
-
-Use two buckets only:
-
-- `DAILY`
-  - should load every session for this repo
-  - strongly matched to the repo's language, framework, workflow, or operator surface
-- `LIBRARY`
-  - useful to retain, but not worth loading by default
-  - should remain reachable through search, router skill, or selective manual use
-
-## Evidence Sources
-
-Use repo-local evidence before making any classification:
-
-- file extensions
-- package managers and lockfiles
-- framework configs
-- CI and hook configs
-- build/test scripts
-- imports and dependency manifests
-- repo docs that explicitly describe the stack
-
-Useful commands include:
-
-```bash
-rg --files
-rg -n "typescript|react|next|supabase|django|spring|flutter|swift"
-cat package.json
-cat pyproject.toml
-cat Cargo.toml
-cat pubspec.yaml
-cat go.mod
-```
-
-## Parallel Review Passes
-
-If parallel subagents are available, split the review into these passes:
-
-1. Agents
-   - classify `agents/*`
-2. Skills
-   - classify `skills/*`
-3. Commands
-   - classify `commands/*`
-4. Rules
-   - classify `rules/*`
-5. Hooks and scripts
-   - classify hook surfaces, MCP health checks, helper scripts, and OS compatibility
-6. Extras
-   - classify contexts, examples, MCP configs, templates, and guidance docs
-
-If subagents are not available, run the same passes sequentially.
-
-## Core Workflow
-
-### 1. Read the repo
-
-Establish the real stack before classifying anything:
-
-- languages in use
-- frameworks in use
-- primary package manager
-- test stack
-- lint/format stack
-- deployment/runtime surface
-- operator integrations already present
-
-### 2. Build the evidence table
-
-For every candidate surface, record:
-
-- component path
-- component type
-- proposed bucket
-- repo evidence
-- short justification
-
-Use this format:
-
-```text
-skills/frontend-patterns | skill | DAILY | 84 .tsx files, next.config.ts present | core frontend stack
-skills/django-patterns   | skill | LIBRARY | no .py files, no pyproject.toml       | not active in this repo
-rules/typescript/*       | rules | DAILY | package.json + tsconfig.json            | active TS repo
-rules/python/*           | rules | LIBRARY | zero Python source files             | keep accessible only
-```
-
-### 3. Decide DAILY vs LIBRARY
-
-Promote to `DAILY` when:
-
-- the repo clearly uses the matching stack
-- the component is general enough to help every session
-- the repo already depends on the corresponding runtime or workflow
-
-Demote to `LIBRARY` when:
-
-- the component is off-stack
-- the repo might need it later, but not every day
-- it adds context overhead without immediate relevance
-
-### 4. Build the install plan
-
-Translate the classification into action:
-
-- DAILY skills -> install or keep in `.claude/skills/`
-- DAILY commands -> keep as explicit shims only if still useful
-- DAILY rules -> install only matching language sets
-- DAILY hooks/scripts -> keep only compatible ones
-- LIBRARY surfaces -> keep accessible through search or `skill-library`
-
-If the repo already uses selective installs, update that plan instead of creating another system.
-
-### 5. Create the optional library router
-
-If the project wants a searchable library surface, create:
-
-- `.claude/skills/skill-library/SKILL.md`
-
-That router should contain:
-
-- a short explanation of DAILY vs LIBRARY
-- grouped trigger keywords
-- where the library references live
-
-Do not duplicate every skill body inside the router.
-
-### 6. Verify the result
-
-After the plan is applied, verify:
-
-- every DAILY file exists where expected
-- stale language rules were not left active
-- incompatible hooks were not installed
-- the resulting install actually matches the repo stack
-
-Return a compact report with:
-
-- DAILY count
-- LIBRARY count
-- removed stale surfaces
-- open questions
-
-## Handoffs
-
-If the next step is interactive installation or repair, hand off to:
-
-- `configure-ecc`
-
-If the next step is overlap cleanup or catalog review, hand off to:
-
-- `skill-stocktake`
-
-If the next step is broader context trimming, hand off to:
-
-- `strategic-compact`
-
-## Output Format
-
-Return the result in this order:
-
-```text
-STACK
-- language/framework/runtime summary
-
-DAILY
-- always-loaded items with evidence
-
-LIBRARY
-- searchable/reference items with evidence
-
-INSTALL PLAN
-- what should be installed, removed, or routed
-
-VERIFICATION
-- checks run and remaining gaps
-```

package/.aider-ecc/skills/agentic-engineering/SKILL.md

@@ -1,63 +0,0 @@
----
-name: agentic-engineering
-description: Operate as an agentic engineer using eval-first execution, decomposition, and cost-aware model routing.
-origin: ECC
----
-
-# Agentic Engineering
-
-Use this skill for engineering workflows where AI agents perform most implementation work and humans enforce quality and risk controls.
-
-## Operating Principles
-
-1. Define completion criteria before execution.
-2. Decompose work into agent-sized units.
-3. Route model tiers by task complexity.
-4. Measure with evals and regression checks.
-
-## Eval-First Loop
-
-1. Define capability eval and regression eval.
-2. Run baseline and capture failure signatures.
-3. Execute implementation.
-4. Re-run evals and compare deltas.
-
-## Task Decomposition
-
-Apply the 15-minute unit rule:
-- each unit should be independently verifiable
-- each unit should have a single dominant risk
-- each unit should expose a clear done condition
-
-## Model Routing
-
-- Haiku: classification, boilerplate transforms, narrow edits
-- Sonnet: implementation and refactors
-- Opus: architecture, root-cause analysis, multi-file invariants
-
-## Session Strategy
-
-- Continue session for closely-coupled units.
-- Start fresh session after major phase transitions.
-- Compact after milestone completion, not during active debugging.
-
-## Review Focus for AI-Generated Code
-
-Prioritize:
-- invariants and edge cases
-- error boundaries
-- security and auth assumptions
-- hidden coupling and rollout risk
-
-Do not waste review cycles on style-only disagreements when automated format/lint already enforce style.
-
-## Cost Discipline
-
-Track per task:
-- model
-- token estimate
-- retries
-- wall-clock time
-- success/failure
-
-Escalate model tier only when lower tier fails with a clear reasoning gap.

package/.aider-ecc/skills/ai-first-engineering/SKILL.md

@@ -1,51 +0,0 @@
----
-name: ai-first-engineering
-description: Engineering operating model for teams where AI agents generate a large share of implementation output.
-origin: ECC
----
-
-# AI-First Engineering
-
-Use this skill when designing process, reviews, and architecture for teams shipping with AI-assisted code generation.
-
-## Process Shifts
-
-1. Planning quality matters more than typing speed.
-2. Eval coverage matters more than anecdotal confidence.
-3. Review focus shifts from syntax to system behavior.
-
-## Architecture Requirements
-
-Prefer architectures that are agent-friendly:
-- explicit boundaries
-- stable contracts
-- typed interfaces
-- deterministic tests
-
-Avoid implicit behavior spread across hidden conventions.
-
-## Code Review in AI-First Teams
-
-Review for:
-- behavior regressions
-- security assumptions
-- data integrity
-- failure handling
-- rollout safety
-
-Minimize time spent on style issues already covered by automation.
-
-## Hiring and Evaluation Signals
-
-Strong AI-first engineers:
-- decompose ambiguous work cleanly
-- define measurable acceptance criteria
-- produce high-signal prompts and evals
-- enforce risk controls under delivery pressure
-
-## Testing Standard
-
-Raise testing bar for generated code:
-- required regression coverage for touched domains
-- explicit edge-case assertions
-- integration checks for interface boundaries

package/.aider-ecc/skills/ai-regression-testing/SKILL.md

@@ -1,385 +0,0 @@
----
-name: ai-regression-testing
-description: Regression testing strategies for AI-assisted development. Sandbox-mode API testing without database dependencies, automated bug-check workflows, and patterns to catch AI blind spots where the same model writes and reviews code.
-origin: ECC
----
-
-# AI Regression Testing
-
-Testing patterns specifically designed for AI-assisted development, where the same model writes code and reviews it — creating systematic blind spots that only automated tests can catch.
-
-## When to Activate
-
-- AI agent (Claude Code, Cursor, Codex) has modified API routes or backend logic
-- A bug was found and fixed — need to prevent re-introduction
-- Project has a sandbox/mock mode that can be leveraged for DB-free testing
-- Running `/bug-check` or similar review commands after code changes
-- Multiple code paths exist (sandbox vs production, feature flags, etc.)
-
-## The Core Problem
-
-When an AI writes code and then reviews its own work, it carries the same assumptions into both steps. This creates a predictable failure pattern:
-
-```
-AI writes fix → AI reviews fix → AI says "looks correct" → Bug still exists
-```
-
-**Real-world example** (observed in production):
-
-```
-Fix 1: Added notification_settings to API response
-  → Forgot to add it to the SELECT query
-  → AI reviewed and missed it (same blind spot)
-
-Fix 2: Added it to SELECT query
-  → TypeScript build error (column not in generated types)
-  → AI reviewed Fix 1 but didn't catch the SELECT issue
-
-Fix 3: Changed to SELECT *
-  → Fixed production path, forgot sandbox path
-  → AI reviewed and missed it AGAIN (4th occurrence)
-
-Fix 4: Test caught it instantly on first run PASS:
-```
-
-The pattern: **sandbox/production path inconsistency** is the #1 AI-introduced regression.
-
-## Sandbox-Mode API Testing
-
-Most projects with AI-friendly architecture have a sandbox/mock mode. This is the key to fast, DB-free API testing.
-
-### Setup (Vitest + Next.js App Router)
-
-```typescript
-// vitest.config.ts
-import { defineConfig } from "vitest/config";
-import path from "path";
-
-export default defineConfig({
-  test: {
-    environment: "node",
-    globals: true,
-    include: ["__tests__/**/*.test.ts"],
-    setupFiles: ["__tests__/setup.ts"],
-  },
-  resolve: {
-    alias: {
-      "@": path.resolve(__dirname, "."),
-    },
-  },
-});
-```
-
-```typescript
-// __tests__/setup.ts
-// Force sandbox mode — no database needed
-process.env.SANDBOX_MODE = "true";
-process.env.NEXT_PUBLIC_SUPABASE_URL = "";
-process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY = "";
-```
-
-### Test Helper for Next.js API Routes
-
-```typescript
-// __tests__/helpers.ts
-import { NextRequest } from "next/server";
-
-export function createTestRequest(
-  url: string,
-  options?: {
-    method?: string;
-    body?: Record<string, unknown>;
-    headers?: Record<string, string>;
-    sandboxUserId?: string;
-  },
-): NextRequest {
-  const { method = "GET", body, headers = {}, sandboxUserId } = options || {};
-  const fullUrl = url.startsWith("http") ? url : `http://localhost:3000${url}`;
-  const reqHeaders: Record<string, string> = { ...headers };
-
-  if (sandboxUserId) {
-    reqHeaders["x-sandbox-user-id"] = sandboxUserId;
-  }
-
-  const init: { method: string; headers: Record<string, string>; body?: string } = {
-    method,
-    headers: reqHeaders,
-  };
-
-  if (body) {
-    init.body = JSON.stringify(body);
-    reqHeaders["content-type"] = "application/json";
-  }
-
-  return new NextRequest(fullUrl, init);
-}
-
-export async function parseResponse(response: Response) {
-  const json = await response.json();
-  return { status: response.status, json };
-}
-```
-
-### Writing Regression Tests
-
-The key principle: **write tests for bugs that were found, not for code that works**.
-
-```typescript
-// __tests__/api/user/profile.test.ts
-import { describe, it, expect } from "vitest";
-import { createTestRequest, parseResponse } from "../../helpers";
-import { GET, PATCH } from "@/app/api/user/profile/route";
-
-// Define the contract — what fields MUST be in the response
-const REQUIRED_FIELDS = [
-  "id",
-  "email",
-  "full_name",
-  "phone",
-  "role",
-  "created_at",
-  "avatar_url",
-  "notification_settings",  // ← Added after bug found it missing
-];
-
-describe("GET /api/user/profile", () => {
-  it("returns all required fields", async () => {
-    const req = createTestRequest("/api/user/profile");
-    const res = await GET(req);
-    const { status, json } = await parseResponse(res);
-
-    expect(status).toBe(200);
-    for (const field of REQUIRED_FIELDS) {
-      expect(json.data).toHaveProperty(field);
-    }
-  });
-
-  // Regression test — this exact bug was introduced by AI 4 times
-  it("notification_settings is not undefined (BUG-R1 regression)", async () => {
-    const req = createTestRequest("/api/user/profile");
-    const res = await GET(req);
-    const { json } = await parseResponse(res);
-
-    expect("notification_settings" in json.data).toBe(true);
-    const ns = json.data.notification_settings;
-    expect(ns === null || typeof ns === "object").toBe(true);
-  });
-});
-```
-
-### Testing Sandbox/Production Parity
-
-The most common AI regression: fixing production path but forgetting sandbox path (or vice versa).
-
-```typescript
-// Test that sandbox responses match the expected contract
-describe("GET /api/user/messages (conversation list)", () => {
-  it("includes partner_name in sandbox mode", async () => {
-    const req = createTestRequest("/api/user/messages", {
-      sandboxUserId: "user-001",
-    });
-    const res = await GET(req);
-    const { json } = await parseResponse(res);
-
-    // This caught a bug where partner_name was added
-    // to production path but not sandbox path
-    if (json.data.length > 0) {
-      for (const conv of json.data) {
-        expect("partner_name" in conv).toBe(true);
-      }
-    }
-  });
-});
-```
-
-## Integrating Tests into Bug-Check Workflow
-
-### Custom Command Definition
-
-```markdown
-<!-- .claude/commands/bug-check.md -->
-# Bug Check
-
-## Step 1: Automated Tests (mandatory, cannot skip)
-
-Run these commands FIRST before any code review:
-
-    npm run test       # Vitest test suite
-    npm run build      # TypeScript type check + build
-
-- If tests fail → report as highest priority bug
-- If build fails → report type errors as highest priority
-- Only proceed to Step 2 if both pass
-
-## Step 2: Code Review (AI review)
-
-1. Sandbox / production path consistency
-2. API response shape matches frontend expectations
-3. SELECT clause completeness
-4. Error handling with rollback
-5. Optimistic update race conditions
-
-## Step 3: For each bug fixed, propose a regression test
-```
-
-### The Workflow
-
-```
-User: "バグチェックして" (or "/bug-check")
-  │
-  ├─ Step 1: npm run test
-  │   ├─ FAIL → Bug found mechanically (no AI judgment needed)
-  │   └─ PASS → Continue
-  │
-  ├─ Step 2: npm run build
-  │   ├─ FAIL → Type error found mechanically
-  │   └─ PASS → Continue
-  │
-  ├─ Step 3: AI code review (with known blind spots in mind)
-  │   └─ Findings reported
-  │
-  └─ Step 4: For each fix, write a regression test
-      └─ Next bug-check catches if fix breaks
-```
-
-## Common AI Regression Patterns
-
-### Pattern 1: Sandbox/Production Path Mismatch
-
-**Frequency**: Most common (observed in 3 out of 4 regressions)
-
-```typescript
-// FAIL: AI adds field to production path only
-if (isSandboxMode()) {
-  return { data: { id, email, name } };  // Missing new field
-}
-// Production path
-return { data: { id, email, name, notification_settings } };
-
-// PASS: Both paths must return the same shape
-if (isSandboxMode()) {
-  return { data: { id, email, name, notification_settings: null } };
-}
-return { data: { id, email, name, notification_settings } };
-```
-
-**Test to catch it**:
-
-```typescript
-it("sandbox and production return same fields", async () => {
-  // In test env, sandbox mode is forced ON
-  const res = await GET(createTestRequest("/api/user/profile"));
-  const { json } = await parseResponse(res);
-
-  for (const field of REQUIRED_FIELDS) {
-    expect(json.data).toHaveProperty(field);
-  }
-});
-```
-
-### Pattern 2: SELECT Clause Omission
-
-**Frequency**: Common with Supabase/Prisma when adding new columns
-
-```typescript
-// FAIL: New column added to response but not to SELECT
-const { data } = await supabase
-  .from("users")
-  .select("id, email, name")  // notification_settings not here
-  .single();
-
-return { data: { ...data, notification_settings: data.notification_settings } };
-// → notification_settings is always undefined
-
-// PASS: Use SELECT * or explicitly include new columns
-const { data } = await supabase
-  .from("users")
-  .select("*")
-  .single();
-```
-
-### Pattern 3: Error State Leakage
-
-**Frequency**: Moderate — when adding error handling to existing components
-
-```typescript
-// FAIL: Error state set but old data not cleared
-catch (err) {
-  setError("Failed to load");
-  // reservations still shows data from previous tab!
-}
-
-// PASS: Clear related state on error
-catch (err) {
-  setReservations([]);  // Clear stale data
-  setError("Failed to load");
-}
-```
-
-### Pattern 4: Optimistic Update Without Proper Rollback
-
-```typescript
-// FAIL: No rollback on failure
-const handleRemove = async (id: string) => {
-  setItems(prev => prev.filter(i => i.id !== id));
-  await fetch(`/api/items/${id}`, { method: "DELETE" });
-  // If API fails, item is gone from UI but still in DB
-};
-
-// PASS: Capture previous state and rollback on failure
-const handleRemove = async (id: string) => {
-  const prevItems = [...items];
-  setItems(prev => prev.filter(i => i.id !== id));
-  try {
-    const res = await fetch(`/api/items/${id}`, { method: "DELETE" });
-    if (!res.ok) throw new Error("API error");
-  } catch {
-    setItems(prevItems);  // Rollback
-    alert("削除に失敗しました");
-  }
-};
-```
-
-## Strategy: Test Where Bugs Were Found
-
-Don't aim for 100% coverage. Instead:
-
-```
-Bug found in /api/user/profile     → Write test for profile API
-Bug found in /api/user/messages    → Write test for messages API
-Bug found in /api/user/favorites   → Write test for favorites API
-No bug in /api/user/notifications  → Don't write test (yet)
-```
-
-**Why this works with AI development:**
-
-1. AI tends to make the **same category of mistake** repeatedly
-2. Bugs cluster in complex areas (auth, multi-path logic, state management)
-3. Once tested, that exact regression **cannot happen again**
-4. Test count grows organically with bug fixes — no wasted effort
-
-## Quick Reference
-
-| AI Regression Pattern | Test Strategy | Priority |
-|---|---|---|
-| Sandbox/production mismatch | Assert same response shape in sandbox mode |  High |
-| SELECT clause omission | Assert all required fields in response |  High |
-| Error state leakage | Assert state cleanup on error |  Medium |
-| Missing rollback | Assert state restored on API failure |  Medium |
-| Type cast masking null | Assert field is not undefined |  Medium |
-
-## DO / DON'T
-
-**DO:**
-- Write tests immediately after finding a bug (before fixing it if possible)
-- Test the API response shape, not the implementation
-- Run tests as the first step of every bug-check
-- Keep tests fast (< 1 second total with sandbox mode)
-- Name tests after the bug they prevent (e.g., "BUG-R1 regression")
-
-**DON'T:**
-- Write tests for code that has never had a bug
-- Trust AI self-review as a substitute for automated tests
-- Skip sandbox path testing because "it's just mock data"
-- Write integration tests when unit tests suffice
-- Aim for coverage percentage — aim for regression prevention