kodelyth-ecc 2.19.0 → 2.21.0

package/.roo/skills/terminal-ops/SKILL.md

@@ -1,109 +0,0 @@
----
-name: terminal-ops
-description: Evidence-first repo execution workflow for ECC. Use when the user wants a command run, a repo checked, a CI failure debugged, or a narrow fix pushed with exact proof of what was executed and verified.
-origin: ECC
----
-
-# Terminal Ops
-
-Use this when the user wants real repo execution: run commands, inspect git state, debug CI or builds, make a narrow fix, and report exactly what changed and what was verified.
-
-This skill is intentionally narrower than general coding guidance. It is an operator workflow for evidence-first terminal execution.
-
-## Skill Stack
-
-Pull these ECC-native skills into the workflow when relevant:
-
-- `verification-loop` for exact proving steps after changes
-- `tdd-workflow` when the right fix needs regression coverage
-- `security-review` when secrets, auth, or external inputs are involved
-- `github-ops` when the task depends on CI runs, PR state, or release status
-- `knowledge-ops` when the verified outcome needs to be captured into durable project context
-
-## When to Use
-
-- user says "fix", "debug", "run this", "check the repo", or "push it"
-- the task depends on command output, git state, test results, or a verified local fix
-- the answer must distinguish changed locally, verified locally, committed, and pushed
-
-## Guardrails
-
-- inspect before editing
-- stay read-only if the user asked for audit/review only
-- prefer repo-local scripts and helpers over improvised ad hoc wrappers
-- do not claim fixed until the proving command was rerun
-- do not claim pushed unless the branch actually moved upstream
-
-## Workflow
-
-### 1. Resolve the working surface
-
-Settle:
-
-- exact repo path
-- branch
-- local diff state
-- requested mode:
-  - inspect
-  - fix
-  - verify
-  - push
-
-### 2. Read the failing surface first
-
-Before changing anything:
-
-- inspect the error
-- inspect the file or test
-- inspect git state
-- use any already-supplied logs or context before re-reading blindly
-
-### 3. Keep the fix narrow
-
-Solve one dominant failure at a time:
-
-- use the smallest useful proving command first
-- only escalate to a bigger build/test pass after the local failure is addressed
-- if a command keeps failing with the same signature, stop broad retries and narrow scope
-
-### 4. Report exact execution state
-
-Use exact status words:
-
-- inspected
-- changed locally
-- verified locally
-- committed
-- pushed
-- blocked
-
-## Output Format
-
-```text
-SURFACE
-- repo
-- branch
-- requested mode
-
-EVIDENCE
-- failing command / diff / test
-
-ACTION
-- what changed
-
-STATUS
-- inspected / changed locally / verified locally / committed / pushed / blocked
-```
-
-## Pitfalls
-
-- do not work from stale memory when the live repo state can be read
-- do not widen a narrow fix into repo-wide churn
-- do not use destructive git commands
-- do not ignore unrelated local work
-
-## Verification
-
-- the response names the proving command or test
-- git-related work names the repo path and branch
-- any push claim includes the target branch and exact result

package/.roo/skills/terse-mode/SKILL.md

@@ -1,97 +0,0 @@
----
-name: terse-mode
-description: Compress LLM output tokens by 40-70% without losing information. Keeps code, commands, URLs, paths byte-exact. Four dial levels (lite / full / ultra / off). Complements RTK (which shrinks input) — together, ~55-65% total token savings on typical coding sessions.
-origin: ECC (inspired by Caveman by juliusbrussee — MIT)
----
-
-# Terse Mode — Output Token Compressor
-
-Make the AI's **mouth** smaller, not its **brain** smaller. Same answers, fewer words, byte-exact code.
-
-## What this is
-
-A prompt-level output compression skill. When active, the AI drops verbose filler while preserving every technical detail. Signals correctness, not chattiness.
-
-## When to activate
-
-- Any coding session where reply length is dominant (explanations, reviews, planning)
-- Extended sessions where you want output tokens to stretch further
-- Reading the AI's output out loud sounds like padding — that's the tell
-
-## When to skip
-
-- User explicitly wants long, teaching-oriented explanations
-- Documentation-writing tasks where the output IS the artifact
-- First contact with a new user who hasn't opted in
-
-## The rules — ALWAYS PRESERVED
-
-The AI must **byte-preserve** these no matter which level:
-
-1. Fenced code blocks (```lang ... ```) — exact contents, no changes
-2. Inline `code` — exact
-3. Shell commands and error text — exact
-4. URLs, file paths, function names, identifiers — exact
-5. Numbers, versions, hashes — exact
-6. YAML/JSON/config snippets — exact
-
-## Levels
-
-### `off` — normal AI voice
-Default. No compression.
-
-### `lite` — light trim
-- Drop obvious filler ("basically", "essentially", "in order to", "the reason is that")
-- Convert "you should X" → "X"
-- Merge sentences that repeat the same idea
-- Keep normal-looking paragraphs
-
-Example — same info, ~25% shorter:
-> The React component re-renders because a new object reference is created on each render. Wrap the object in `useMemo`.
-
-### `full` — default terse
-- Fragment sentences: "New ref each render. Wrap in `useMemo`."
-- Drop transitional phrases entirely
-- Use `→` and `=` freely instead of prose connectors
-- Assume user is a senior engineer
-
-Example — ~50% shorter:
-> New ref each render → re-render. Wrap object in `useMemo`.
-
-### `ultra` — maximum compression
-- Telegram-style. Symbols over words. Numbered points, one line each.
-- Only expand if the compression would lose a technical fact.
-
-Example — ~70% shorter:
-> Ref/render. `useMemo` it.
-
-## Interaction with other ECC systems
-
-- **RTK** compresses input tokens (tool output → LLM). Terse compresses output tokens (LLM → user). Stack together for ~55-65% total savings.
-- **kodelyth-memory** captures still capture in normal voice — memory recall is for machines, not humans. Terse mode does NOT affect memory captures.
-- **`code-reviewer`** and **`release-captain`** agents can opt in via `--terse` flag for one-line PR comments and short commit messages.
-
-## What terse mode NEVER does
-
-- Change what the AI knows
-- Skip technical details or trade-offs
-- Compress code, commands, or errors
-- Translate — write in the user's own language, just tighter
-- Auto-activate — user opts in via `/terse` or CLI
-
-## Activation
-
-- Slash command: `/terse [lite|full|ultra|off]` — sticks for the session
-- CLI: `kodelyth-ecc terse enable [--target claude-code|--all]` — installs the skill + command into your AI tool
-- Statusline (Claude Code): shows `[TERSE ⚡ 12.4k]` — lifetime output tokens saved
-
-## Honest numbers
-
-- On verbose explain-heavy tasks: 60-70% output token reduction
-- On terse debugging chats: 20-30% (less to compress)
-- On documentation writing: net zero — skip this mode
-- Skill itself adds ~800-1200 input tokens per turn. Below ~2k output tokens, may be net-negative
-
-## Attribution
-
-Design inspired by [Caveman](https://github.com/JuliusBrussee/caveman) (MIT, by Julius Brussee). ECC's implementation is independent — different prompt, different levels dial (no `wenyan`, no cavespeak persona), and integrated with our RTK ledger for combined input+output tracking.

package/.roo/skills/token-budget-advisor/SKILL.md

@@ -1,133 +0,0 @@
----
-name: token-budget-advisor
-description: >-
-  Offers the user an informed choice about how much response depth to
-  consume before answering. Use this skill when the user explicitly
-  wants to control response length, depth, or token budget.
-  TRIGGER when: "token budget", "token count", "token usage", "token limit",
-  "response length", "answer depth", "short version", "brief answer",
-  "detailed answer", "exhaustive answer", "respuesta corta vs larga",
-  "cuántos tokens", "ahorrar tokens", "responde al 50%", "dame la versión
-  corta", "quiero controlar cuánto usas", or clear variants where the
-  user is explicitly asking to control answer size or depth.
-  DO NOT TRIGGER when: user has already specified a level in the current
-  session (maintain it), the request is clearly a one-word answer, or
-  "token" refers to auth/session/payment tokens rather than response size.
-origin: community
----
-
-# Token Budget Advisor (TBA)
-
-Intercept the response flow to offer the user a choice about response depth **before** Claude answers.
-
-## When to Use
-
-- User wants to control how long or detailed a response is
-- User mentions tokens, budget, depth, or response length
-- User says "short version", "tldr", "brief", "al 25%", "exhaustive", etc.
-- Any time the user wants to choose depth/detail level upfront
-
-**Do not trigger** when: user already set a level this session (maintain it silently), or the answer is trivially one line.
-
-## How It Works
-
-### Step 1 — Estimate input tokens
-
-Use the repository's canonical context-budget heuristics to estimate the prompt's token count mentally.
-
-Use the same calibration guidance as [context-budget](../context-budget/SKILL.md):
-
-- prose: `words × 1.3`
-- code-heavy or mixed/code blocks: `chars / 4`
-
-For mixed content, use the dominant content type and keep the estimate heuristic.
-
-### Step 2 — Estimate response size by complexity
-
-Classify the prompt, then apply the multiplier range to get the full response window:
-
-| Complexity   | Multiplier range | Example prompts                                      |
-|--------------|------------------|------------------------------------------------------|
-| Simple       | 3× – 8×          | "What is X?", yes/no, single fact                   |
-| Medium       | 8× – 20×         | "How does X work?"                                  |
-| Medium-High  | 10× – 25×        | Code request with context                           |
-| Complex      | 15× – 40×        | Multi-part analysis, comparisons, architecture      |
-| Creative     | 10× – 30×        | Stories, essays, narrative writing                  |
-
-Response window = `input_tokens × mult_min` to `input_tokens × mult_max` (but don’t exceed your model’s configured output-token limit).
-
-### Step 3 — Present depth options
-
-Present this block **before** answering, using the actual estimated numbers:
-
-```
-Analyzing your prompt...
-
-Input: ~[N] tokens  |  Type: [type]  |  Complexity: [level]  |  Language: [lang]
-
-Choose your depth level:
-
-[1] Essential   (25%)  ->  ~[tokens]   Direct answer only, no preamble
-[2] Moderate    (50%)  ->  ~[tokens]   Answer + context + 1 example
-[3] Detailed    (75%)  ->  ~[tokens]   Full answer with alternatives
-[4] Exhaustive (100%)  ->  ~[tokens]   Everything, no limits
-
-Which level? (1-4 or say "25% depth", "50% depth", "75% depth", "100% depth")
-
-Precision: heuristic estimate ~85-90% accuracy (±15%).
-```
-
-Level token estimates (within the response window):
-- 25%  → `min + (max - min) × 0.25`
-- 50%  → `min + (max - min) × 0.50`
-- 75%  → `min + (max - min) × 0.75`
-- 100% → `max`
-
-### Step 4 — Respond at the chosen level
-
-| Level            | Target length       | Include                                             | Omit                                              |
-|------------------|---------------------|-----------------------------------------------------|---------------------------------------------------|
-| 25% Essential    | 2-4 sentences max   | Direct answer, key conclusion                       | Context, examples, nuance, alternatives           |
-| 50% Moderate     | 1-3 paragraphs      | Answer + necessary context + 1 example              | Deep analysis, edge cases, references             |
-| 75% Detailed     | Structured response | Multiple examples, pros/cons, alternatives          | Extreme edge cases, exhaustive references         |
-| 100% Exhaustive  | No restriction      | Everything — full analysis, all code, all perspectives | Nothing                                        |
-
-## Shortcuts — skip the question
-
-If the user already signals a level, respond at that level immediately without asking:
-
-| What they say                                      | Level |
-|----------------------------------------------------|-------|
-| "1" / "25% depth" / "short version" / "brief answer" / "tldr"  | 25%   |
-| "2" / "50% depth" / "moderate depth" / "balanced answer"        | 50%   |
-| "3" / "75% depth" / "detailed answer" / "thorough answer"       | 75%   |
-| "4" / "100% depth" / "exhaustive answer" / "full deep dive"     | 100%  |
-
-If the user set a level earlier in the session, **maintain it silently** for subsequent responses unless they change it.
-
-## Precision note
-
-This skill uses heuristic estimation — no real tokenizer. Accuracy ~85-90%, variance ±15%. Always show the disclaimer.
-
-## Examples
-
-### Triggers
-
-- "Give me the short version first."
-- "How many tokens will your answer use?"
-- "Respond at 50% depth."
-- "I want the exhaustive answer, not the summary."
-- "Dame la version corta y luego la detallada."
-
-### Does Not Trigger
-
-- "What is a JWT token?"
-- "The checkout flow uses a payment token."
-- "Is this normal?"
-- "Complete the refactor."
-- Follow-up questions after the user already chose a depth for the session
-
-## Source
-
-Standalone skill from [TBA — Token Budget Advisor for Claude Code](https://github.com/Xabilimon1/Token-Budget-Advisor-Claude-Code-).
-Original project also ships a Python estimator script, but this repository keeps the skill self-contained and heuristic-only.