kodelyth-ecc 2.19.0 → 2.20.0

package/.kimi/skills/santa-method/SKILL.md

@@ -1,306 +0,0 @@
----
-name: santa-method
-description: "Multi-agent adversarial verification with convergence loop. Two independent review agents must both pass before output ships."
-origin: "Ronald Skelton - Founder, RapportScore.ai"
----
-
-# Santa Method
-
-Multi-agent adversarial verification framework. Make a list, check it twice. If it's naughty, fix it until it's nice.
-
-The core insight: a single agent reviewing its own output shares the same biases, knowledge gaps, and systematic errors that produced the output. Two independent reviewers with no shared context break this failure mode.
-
-## When to Activate
-
-Invoke this skill when:
-- Output will be published, deployed, or consumed by end users
-- Compliance, regulatory, or brand constraints must be enforced
-- Code ships to production without human review
-- Content accuracy matters (technical docs, educational material, customer-facing copy)
-- Batch generation at scale where spot-checking misses systemic patterns
-- Hallucination risk is elevated (claims, statistics, API references, legal language)
-
-Do NOT use for internal drafts, exploratory research, or tasks with deterministic verification (use build/test/lint pipelines for those).
-
-## Architecture
-
-```
-┌─────────────┐
-│  GENERATOR   │  Phase 1: Make a List
-│  (Agent A)   │  Produce the deliverable
-└──────┬───────┘
-       │ output
-       ▼
-┌──────────────────────────────┐
-│     DUAL INDEPENDENT REVIEW   │  Phase 2: Check It Twice
-│                                │
-│  ┌───────────┐ ┌───────────┐  │  Two agents, same rubric,
-│  │ Reviewer B │ │ Reviewer C │  │  no shared context
-│  └─────┬─────┘ └─────┬─────┘  │
-│        │              │        │
-└────────┼──────────────┼────────┘
-         │              │
-         ▼              ▼
-┌──────────────────────────────┐
-│        VERDICT GATE           │  Phase 3: Naughty or Nice
-│                                │
-│  B passes AND C passes → NICE  │  Both must pass.
-│  Otherwise → NAUGHTY           │  No exceptions.
-└──────┬──────────────┬─────────┘
-       │              │
-    NICE           NAUGHTY
-       │              │
-       ▼              ▼
-   [ SHIP ]    ┌─────────────┐
-               │  FIX CYCLE   │  Phase 4: Fix Until Nice
-               │              │
-               │ iteration++  │  Collect all flags.
-               │ if i > MAX:  │  Fix all issues.
-               │   escalate   │  Re-run both reviewers.
-               │ else:        │  Loop until convergence.
-               │   goto Ph.2  │
-               └──────────────┘
-```
-
-## Phase Details
-
-### Phase 1: Make a List (Generate)
-
-Execute the primary task. No changes to your normal generation workflow. Santa Method is a post-generation verification layer, not a generation strategy.
-
-```python
-# The generator runs as normal
-output = generate(task_spec)
-```
-
-### Phase 2: Check It Twice (Independent Dual Review)
-
-Spawn two review agents in parallel. Critical invariants:
-
-1. **Context isolation** — neither reviewer sees the other's assessment
-2. **Identical rubric** — both receive the same evaluation criteria
-3. **Same inputs** — both receive the original spec AND the generated output
-4. **Structured output** — each returns a typed verdict, not prose
-
-```python
-REVIEWER_PROMPT = """
-You are an independent quality reviewer. You have NOT seen any other review of this output.
-
-## Task Specification
-{task_spec}
-
-## Output Under Review
-{output}
-
-## Evaluation Rubric
-{rubric}
-
-## Instructions
-Evaluate the output against EACH rubric criterion. For each:
-- PASS: criterion fully met, no issues
-- FAIL: specific issue found (cite the exact problem)
-
-Return your assessment as structured JSON:
-{
-  "verdict": "PASS" | "FAIL",
-  "checks": [
-    {"criterion": "...", "result": "PASS|FAIL", "detail": "..."}
-  ],
-  "critical_issues": ["..."],   // blockers that must be fixed
-  "suggestions": ["..."]         // non-blocking improvements
-}
-
-Be rigorous. Your job is to find problems, not to approve.
-"""
-```
-
-```python
-# Spawn reviewers in parallel (Claude Code subagents)
-review_b = Agent(prompt=REVIEWER_PROMPT.format(...), description="Santa Reviewer B")
-review_c = Agent(prompt=REVIEWER_PROMPT.format(...), description="Santa Reviewer C")
-
-# Both run concurrently — neither sees the other
-```
-
-### Rubric Design
-
-The rubric is the most important input. Vague rubrics produce vague reviews. Every criterion must have an objective pass/fail condition.
-
-| Criterion | Pass Condition | Failure Signal |
-|-----------|---------------|----------------|
-| Factual accuracy | All claims verifiable against source material or common knowledge | Invented statistics, wrong version numbers, nonexistent APIs |
-| Hallucination-free | No fabricated entities, quotes, URLs, or references | Links to pages that don't exist, attributed quotes with no source |
-| Completeness | Every requirement in the spec is addressed | Missing sections, skipped edge cases, incomplete coverage |
-| Compliance | Passes all project-specific constraints | Banned terms used, tone violations, regulatory non-compliance |
-| Internal consistency | No contradictions within the output | Section A says X, section B says not-X |
-| Technical correctness | Code compiles/runs, algorithms are sound | Syntax errors, logic bugs, wrong complexity claims |
-
-#### Domain-Specific Rubric Extensions
-
-**Content/Marketing:**
-- Brand voice adherence
-- SEO requirements met (keyword density, meta tags, structure)
-- No competitor trademark misuse
-- CTA present and correctly linked
-
-**Code:**
-- Type safety (no `any` leaks, proper null handling)
-- Error handling coverage
-- Security (no secrets in code, input validation, injection prevention)
-- Test coverage for new paths
-
-**Compliance-Sensitive (regulated, legal, financial):**
-- No outcome guarantees or unsubstantiated claims
-- Required disclaimers present
-- Approved terminology only
-- Jurisdiction-appropriate language
-
-### Phase 3: Naughty or Nice (Verdict Gate)
-
-```python
-def santa_verdict(review_b, review_c):
-    """Both reviewers must pass. No partial credit."""
-    if review_b.verdict == "PASS" and review_c.verdict == "PASS":
-        return "NICE"  # Ship it
-
-    # Merge flags from both reviewers, deduplicate
-    all_issues = dedupe(review_b.critical_issues + review_c.critical_issues)
-    all_suggestions = dedupe(review_b.suggestions + review_c.suggestions)
-
-    return "NAUGHTY", all_issues, all_suggestions
-```
-
-Why both must pass: if only one reviewer catches an issue, that issue is real. The other reviewer's blind spot is exactly the failure mode Santa Method exists to eliminate.
-
-### Phase 4: Fix Until Nice (Convergence Loop)
-
-```python
-MAX_ITERATIONS = 3
-
-for iteration in range(MAX_ITERATIONS):
-    verdict, issues, suggestions = santa_verdict(review_b, review_c)
-
-    if verdict == "NICE":
-        log_santa_result(output, iteration, "passed")
-        return ship(output)
-
-    # Fix all critical issues (suggestions are optional)
-    output = fix_agent.execute(
-        output=output,
-        issues=issues,
-        instruction="Fix ONLY the flagged issues. Do not refactor or add unrequested changes."
-    )
-
-    # Re-run BOTH reviewers on fixed output (fresh agents, no memory of previous round)
-    review_b = Agent(prompt=REVIEWER_PROMPT.format(output=output, ...))
-    review_c = Agent(prompt=REVIEWER_PROMPT.format(output=output, ...))
-
-# Exhausted iterations — escalate
-log_santa_result(output, MAX_ITERATIONS, "escalated")
-escalate_to_human(output, issues)
-```
-
-Critical: each review round uses **fresh agents**. Reviewers must not carry memory from previous rounds, as prior context creates anchoring bias.
-
-## Implementation Patterns
-
-### Pattern A: Claude Code Subagents (Recommended)
-
-Subagents provide true context isolation. Each reviewer is a separate process with no shared state.
-
-```bash
-# In a Claude Code session, use the Agent tool to spawn reviewers
-# Both agents run in parallel for speed
-```
-
-```python
-# Pseudocode for Agent tool invocation
-reviewer_b = Agent(
-    description="Santa Review B",
-    prompt=f"Review this output for quality...\n\nRUBRIC:\n{rubric}\n\nOUTPUT:\n{output}"
-)
-reviewer_c = Agent(
-    description="Santa Review C",
-    prompt=f"Review this output for quality...\n\nRUBRIC:\n{rubric}\n\nOUTPUT:\n{output}"
-)
-```
-
-### Pattern B: Sequential Inline (Fallback)
-
-When subagents aren't available, simulate isolation with explicit context resets:
-
-1. Generate output
-2. New context: "You are Reviewer 1. Evaluate ONLY against this rubric. Find problems."
-3. Record findings verbatim
-4. Clear context completely
-5. New context: "You are Reviewer 2. Evaluate ONLY against this rubric. Find problems."
-6. Compare both reviews, fix, repeat
-
-The subagent pattern is strictly superior — inline simulation risks context bleed between reviewers.
-
-### Pattern C: Batch Sampling
-
-For large batches (100+ items), full Santa on every item is cost-prohibitive. Use stratified sampling:
-
-1. Run Santa on a random sample (10-15% of batch, minimum 5 items)
-2. Categorize failures by type (hallucination, compliance, completeness, etc.)
-3. If systematic patterns emerge, apply targeted fixes to the entire batch
-4. Re-sample and re-verify the fixed batch
-5. Continue until a clean sample passes
-
-```python
-import random
-
-def santa_batch(items, rubric, sample_rate=0.15):
-    sample = random.sample(items, max(5, int(len(items) * sample_rate)))
-
-    for item in sample:
-        result = santa_full(item, rubric)
-        if result.verdict == "NAUGHTY":
-            pattern = classify_failure(result.issues)
-            items = batch_fix(items, pattern)  # Fix all items matching pattern
-            return santa_batch(items, rubric)   # Re-sample
-
-    return items  # Clean sample → ship batch
-```
-
-## Failure Modes and Mitigations
-
-| Failure Mode | Symptom | Mitigation |
-|-------------|---------|------------|
-| Infinite loop | Reviewers keep finding new issues after fixes | Max iteration cap (3). Escalate. |
-| Rubber stamping | Both reviewers pass everything | Adversarial prompt: "Your job is to find problems, not approve." |
-| Subjective drift | Reviewers flag style preferences, not errors | Tight rubric with objective pass/fail criteria only |
-| Fix regression | Fixing issue A introduces issue B | Fresh reviewers each round catch regressions |
-| Reviewer agreement bias | Both reviewers miss the same thing | Mitigated by independence, not eliminated. For critical output, add a third reviewer or human spot-check. |
-| Cost explosion | Too many iterations on large outputs | Batch sampling pattern. Budget caps per verification cycle. |
-
-## Integration with Other Skills
-
-| Skill | Relationship |
-|-------|-------------|
-| Verification Loop | Use for deterministic checks (build, lint, test). Santa for semantic checks (accuracy, hallucinations). Run verification-loop first, Santa second. |
-| Eval Harness | Santa Method results feed eval metrics. Track pass@k across Santa runs to measure generator quality over time. |
-| Continuous Learning v2 | Santa findings become instincts. Repeated failures on the same criterion → learned behavior to avoid the pattern. |
-| Strategic Compact | Run Santa BEFORE compacting. Don't lose review context mid-verification. |
-
-## Metrics
-
-Track these to measure Santa Method effectiveness:
-
-- **First-pass rate**: % of outputs that pass Santa on round 1 (target: >70%)
-- **Mean iterations to convergence**: average rounds to NICE (target: <1.5)
-- **Issue taxonomy**: distribution of failure types (hallucination vs. completeness vs. compliance)
-- **Reviewer agreement**: % of issues flagged by both reviewers vs. only one (low agreement = rubric needs tightening)
-- **Escape rate**: issues found post-ship that Santa should have caught (target: 0)
-
-## Cost Analysis
-
-Santa Method costs approximately 2-3x the token cost of generation alone per verification cycle. For most high-stakes output, this is a bargain:
-
-```
-Cost of Santa = (generation tokens) + 2×(review tokens per round) × (avg rounds)
-Cost of NOT Santa = (reputation damage) + (correction effort) + (trust erosion)
-```
-
-For batch operations, the sampling pattern reduces cost to ~15-20% of full verification while catching >90% of systematic issues.

package/.kimi/skills/search-first/SKILL.md

@@ -1,161 +0,0 @@
----
-name: search-first
-description: Research-before-coding workflow. Search for existing tools, libraries, and patterns before writing custom code. Invokes the researcher agent.
-origin: ECC
----
-
-# /search-first — Research Before You Code
-
-Systematizes the "search for existing solutions before implementing" workflow.
-
-## Trigger
-
-Use this skill when:
-- Starting a new feature that likely has existing solutions
-- Adding a dependency or integration
-- The user asks "add X functionality" and you're about to write code
-- Before creating a new utility, helper, or abstraction
-
-## Workflow
-
-```
-┌─────────────────────────────────────────────┐
-│  1. NEED ANALYSIS                           │
-│     Define what functionality is needed      │
-│     Identify language/framework constraints  │
-├─────────────────────────────────────────────┤
-│  2. PARALLEL SEARCH (researcher agent)      │
-│     ┌──────────┐ ┌──────────┐ ┌──────────┐  │
-│     │  npm /   │ │  MCP /   │ │  GitHub / │  │
-│     │  PyPI    │ │  Skills  │ │  Web      │  │
-│     └──────────┘ └──────────┘ └──────────┘  │
-├─────────────────────────────────────────────┤
-│  3. EVALUATE                                │
-│     Score candidates (functionality, maint, │
-│     community, docs, license, deps)         │
-├─────────────────────────────────────────────┤
-│  4. DECIDE                                  │
-│     ┌─────────┐  ┌──────────┐  ┌─────────┐  │
-│     │  Adopt  │  │  Extend  │  │  Build   │  │
-│     │ as-is   │  │  /Wrap   │  │  Custom  │  │
-│     └─────────┘  └──────────┘  └─────────┘  │
-├─────────────────────────────────────────────┤
-│  5. IMPLEMENT                               │
-│     Install package / Configure MCP /       │
-│     Write minimal custom code               │
-└─────────────────────────────────────────────┘
-```
-
-## Decision Matrix
-
-| Signal | Action |
-|--------|--------|
-| Exact match, well-maintained, MIT/Apache | **Adopt** — install and use directly |
-| Partial match, good foundation | **Extend** — install + write thin wrapper |
-| Multiple weak matches | **Compose** — combine 2-3 small packages |
-| Nothing suitable found | **Build** — write custom, but informed by research |
-
-## How to Use
-
-### Quick Mode (inline)
-
-Before writing a utility or adding functionality, mentally run through:
-
-0. Does this already exist in the repo? → `rg` through relevant modules/tests first
-1. Is this a common problem? → Search npm/PyPI
-2. Is there an MCP for this? → Check `~/.claude/settings.json` and search
-3. Is there a skill for this? → Check `~/.claude/skills/`
-4. Is there a GitHub implementation/template? → Run GitHub code search for maintained OSS before writing net-new code
-
-### Full Mode (agent)
-
-For non-trivial functionality, launch the researcher agent:
-
-```
-Task(subagent_type="general-purpose", prompt="
-  Research existing tools for: [DESCRIPTION]
-  Language/framework: [LANG]
-  Constraints: [ANY]
-
-  Search: npm/PyPI, MCP servers, Claude Code skills, GitHub
-  Return: Structured comparison with recommendation
-")
-```
-
-## Search Shortcuts by Category
-
-### Development Tooling
-- Linting → `eslint`, `ruff`, `textlint`, `markdownlint`
-- Formatting → `prettier`, `black`, `gofmt`
-- Testing → `jest`, `pytest`, `go test`
-- Pre-commit → `husky`, `lint-staged`, `pre-commit`
-
-### AI/LLM Integration
-- Claude SDK → Context7 for latest docs
-- Prompt management → Check MCP servers
-- Document processing → `unstructured`, `pdfplumber`, `mammoth`
-
-### Data & APIs
-- HTTP clients → `httpx` (Python), `ky`/`got` (Node)
-- Validation → `zod` (TS), `pydantic` (Python)
-- Database → Check for MCP servers first
-
-### Content & Publishing
-- Markdown processing → `remark`, `unified`, `markdown-it`
-- Image optimization → `sharp`, `imagemin`
-
-## Integration Points
-
-### With planner agent
-The planner should invoke researcher before Phase 1 (Architecture Review):
-- Researcher identifies available tools
-- Planner incorporates them into the implementation plan
-- Avoids "reinventing the wheel" in the plan
-
-### With architect agent
-The architect should consult researcher for:
-- Technology stack decisions
-- Integration pattern discovery
-- Existing reference architectures
-
-### With iterative-retrieval skill
-Combine for progressive discovery:
-- Cycle 1: Broad search (npm, PyPI, MCP)
-- Cycle 2: Evaluate top candidates in detail
-- Cycle 3: Test compatibility with project constraints
-
-## Examples
-
-### Example 1: "Add dead link checking"
-```
-Need: Check markdown files for broken links
-Search: npm "markdown dead link checker"
-Found: textlint-rule-no-dead-link (score: 9/10)
-Action: ADOPT — npm install textlint-rule-no-dead-link
-Result: Zero custom code, battle-tested solution
-```
-
-### Example 2: "Add HTTP client wrapper"
-```
-Need: Resilient HTTP client with retries and timeout handling
-Search: npm "http client retry", PyPI "httpx retry"
-Found: got (Node) with retry plugin, httpx (Python) with built-in retry
-Action: ADOPT — use got/httpx directly with retry config
-Result: Zero custom code, production-proven libraries
-```
-
-### Example 3: "Add config file linter"
-```
-Need: Validate project config files against a schema
-Search: npm "config linter schema", "json schema validator cli"
-Found: ajv-cli (score: 8/10)
-Action: ADOPT + EXTEND — install ajv-cli, write project-specific schema
-Result: 1 package + 1 schema file, no custom validation logic
-```
-
-## Anti-Patterns
-
-- **Jumping to code**: Writing a utility without checking if one exists
-- **Ignoring MCP**: Not checking if an MCP server already provides the capability
-- **Over-customizing**: Wrapping a library so heavily it loses its benefits
-- **Dependency bloat**: Installing a massive package for one small feature

package/.kimi/skills/security-bounty-hunter/SKILL.md

@@ -1,99 +0,0 @@
----
-name: security-bounty-hunter
-description: Hunt for exploitable, bounty-worthy security issues in repositories. Focuses on remotely reachable vulnerabilities that qualify for real reports instead of noisy local-only findings.
-origin: ECC direct-port adaptation
-version: "1.0.0"
----
-
-# Security Bounty Hunter
-
-Use this when the goal is practical vulnerability discovery for responsible disclosure or bounty submission, not a broad best-practices review.
-
-## When to Use
-
-- Scanning a repository for exploitable vulnerabilities
-- Preparing a Huntr, HackerOne, or similar bounty submission
-- Triage where the question is "does this actually pay?" rather than "is this theoretically unsafe?"
-
-## How It Works
-
-Bias toward remotely reachable, user-controlled attack paths and throw away patterns that platforms routinely reject as informative or out of scope.
-
-## In-Scope Patterns
-
-These are the kinds of issues that consistently matter:
-
-| Pattern | CWE | Typical impact |
-| --- | --- | --- |
-| SSRF through user-controlled URLs | CWE-918 | internal network access, cloud metadata theft |
-| Auth bypass in middleware or API guards | CWE-287 | unauthorized account or data access |
-| Remote deserialization or upload-to-RCE paths | CWE-502 | code execution |
-| SQL injection in reachable endpoints | CWE-89 | data exfiltration, auth bypass, data destruction |
-| Command injection in request handlers | CWE-78 | code execution |
-| Path traversal in file-serving paths | CWE-22 | arbitrary file read or write |
-| Auto-triggered XSS | CWE-79 | session theft, admin compromise |
-
-## Skip These
-
-These are usually low-signal or out of bounty scope unless the program says otherwise:
-
-- Local-only `pickle.loads`, `torch.load`, or equivalent with no remote path
-- `eval()` or `exec()` in CLI-only tooling
-- `shell=True` on fully hardcoded commands
-- Missing security headers by themselves
-- Generic rate-limiting complaints without exploit impact
-- Self-XSS requiring the victim to paste code manually
-- CI/CD injection that is not part of the target program scope
-- Demo, example, or test-only code
-
-## Workflow
-
-1. Check scope first: program rules, SECURITY.md, disclosure channel, and exclusions.
-2. Find real entrypoints: HTTP handlers, uploads, background jobs, webhooks, parsers, and integration endpoints.
-3. Run static tooling where it helps, but treat it as triage input only.
-4. Read the real code path end to end.
-5. Prove user control reaches a meaningful sink.
-6. Confirm exploitability and impact with the smallest safe PoC possible.
-7. Check for duplicates before drafting a report.
-
-## Example Triage Loop
-
-```bash
-semgrep --config=auto --severity=ERROR --severity=WARNING --json
-```
-
-Then manually filter:
-
-- drop tests, demos, fixtures, vendored code
-- drop local-only or non-reachable paths
-- keep only findings with a clear network or user-controlled route
-
-## Report Structure
-
-```markdown
-## Description
-[What the vulnerability is and why it matters]
-
-## Vulnerable Code
-[File path, line range, and a small snippet]
-
-## Proof of Concept
-[Minimal working request or script]
-
-## Impact
-[What the attacker can achieve]
-
-## Affected Version
-[Version, commit, or deployment target tested]
-```
-
-## Quality Gate
-
-Before submitting:
-
-- The code path is reachable from a real user or network boundary
-- The input is genuinely user-controlled
-- The sink is meaningful and exploitable
-- The PoC works
-- The issue is not already covered by an advisory, CVE, or open ticket
-- The target is actually in scope for the bounty program