kodelyth-ecc 2.18.0 → 2.19.0

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

@@ -0,0 +1,109 @@
+---
+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

@@ -0,0 +1,97 @@
+---
+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

@@ -0,0 +1,133 @@
+---
+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.