chill-agent 1.3.0 → 1.5.0

package/.openclaw/skills/chill-slop-copywriting/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: chill-slop-copywriting
+description: "Comprehensive Copywriting & Authentic Voice Standard. Strips robotic AI marketing fluff, hype words, and hallucinated metrics in favor of sharp, technical prose a busy human understands in one read."
+license: MIT
+---
+
+# ChillSlop Copywriting: Comprehensive Authentic Voice Standard
+
+> *"Write with the precision of an engineer and the brevity of an editor."*
+
+---
+
+## 1. The Banned Vocabulary Index (50+ AI Cliches)
+
+Strip these words and phrases immediately upon detection:
+
+| Banned AI Buzzword | Why It Fails | What to Use Instead |
+|---|---|---|
+| **"Unleash the power of..."** | Lazy, overused AI cliché. | Name the specific tool and its concrete function. |
+| **"Seamlessly integrate / Effortless"** | Minimizes technical complexity; reads like marketing spam. | Name the protocol: *"Installs via stdio JSON-RPC in 1 command."* |
+| **"Supercharge your workflow"** | Hollow hype with no empirical meaning. | Provide benchmark figures: *"Cuts compilation time from 12s to 4s."* |
+| **"Next-generation / Cutting-edge"** | Meaningless assertion that dates quickly. | State the architecture: *"Written in native C++20 with WAL mode."* |
+| **"Revolutionary / Game-changer"** | Inflated self-praise. | Describe the mechanism: *"First debugger to support deterministic parent-DAG forks."* |
+| **"Dive in / Delve into / Let's explore"** | Unmistakable GPT filler opener. | Delete entirely. Start directly with the technical step. |
+| **"Robust and scalable"** | Vague engineering hand-waving. | Specify limits: *"Handles 15,000 req/sec across 4 worker threads."* |
+| **"Empower developers to..."** | Paternalistic marketing jargon. | State the action: *"Inspect, rewind, and replay LLM trajectories."* |
+| **"Look no further!"** | Cheesy infomercial script. | Delete entirely. State the product's identity plainly. |
+| **"Tailored to your needs"** | Empty corporate filler. | Explain customization hooks: *"Configurable via JSON schema."* |
+| **"Magic / Magically"** | Obscures mechanical operation. | Explain the algorithm: *"Canonicalizes JSON keys before SHA-256 hashing."* |
+| **"In today's fast-paced world"** | High school essay introductory fluff. | Delete entirely. |
+| **"A testament to..."** | Robotic academic phrase. | State the result directly. |
+| **"Pivotal / Paramount"** | Pseudo-intellectual filler. | Use "critical", "essential", or plain language. |
+
+---
+
+## 2. The Em Dash (`—`) Ban & Clean Punctuation
+
+- **The Rule:** The em dash character (`—`) is strictly banned in all generated text and UI copy.
+- **Why:** Large language models excessively insert em dashes to simulate literary sophistication, resulting in an unmistakable AI signature.
+- **Direct Replacements:**
+  - *Bad:* "Fast, reliable — and built for teams."
+  - *Good (Comma):* "Fast, reliable, and built for teams."
+  - *Good (Colon):* "Built for teams: fast, reliable, and deterministic."
+  - *Good (Separate Sentences):* "Built for teams. Fast and reliable."
+
+---
+
+## 3. The Specificity Mandate
+
+Replace abstract claims with concrete engineering realities:
+
+### Example 1: Product Descriptions
+- **Slop:** *"ChillRewind is an ultra-fast, modern AI proxy that saves you lots of money and prevents stuck loops."*
+- **Craft:** *"ChillRewind is a zero-dependency local proxy running on `node:sqlite` in WAL mode. It prunes stale tool outputs over 1.5KB and halts agent runs when the same tool signature repeats 3 consecutive times."*
+
+### Example 2: Performance Claims
+- **Slop:** *"Experience blazing-fast response times and incredible token efficiency."*
+- **Craft:** *"Replays cached LLM turns with 0ms latency and $0.00 upstream cost."*
+
+---
+
+## 4. Microcopy, Buttons & Interface Verbs
+
+### Action-Oriented Buttons
+Every interactive button must pair an **imperative verb** with a **direct object**:
+- **Banned:** `Get Started`, `Learn More`, `Submit`, `Click Here`, `Explore`, `Continue`.
+- **Approved:** `Fork Session`, `Export JSON`, `Connect Database`, `Copy API Key`, `Download Log`, `Verify Hash`.
+
+### Honest Error Messages
+Every error message must state three facts: (1) what failed, (2) why it failed, and (3) the exact resolution command.
+- **Slop:** *"Oops! Something went wrong while saving your session. Please try again later."*
+- **Craft:** *"SQLite write failed: database file `.chillrewind/store.db` is locked by process PID 4120. Run `chill-agent doctor` or terminate stale proxy instances."*
+
+---
+
+## 5. Social Proof & Statistics
+
+- **The Rule:** Never invent statistics (*"Trusted by 10,000+ developers"*), fake customer headshots, or fabricated quotes.
+- If verified customer metrics or official case studies exist, cite them with links.
+- If verified data is not available, **omit the section entirely**. An empty section or no testimonials builds far higher trust than fabricated praise.

package/.openclaw/skills/chill-slop-human/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: chill-slop-human
+description: "Comprehensive Ergonomics, Human Factors & Accessibility Standard. Enforces WCAG AA 4.5:1 contrast, visible focus rings, 44px touch targets, Escape-key dialogs, and accessible screen-reader semantics."
+license: MIT
+---
+
+# ChillSlop Human: Comprehensive Ergonomics & Accessibility Standard
+
+> *"Accessibility is not an optional polish phase. An interface that cannot be used by everyone is simply an unfinished interface."*
+
+---
+
+## 1. Contrast Ratios & Visual Legibility
+
+### WCAG AA Minimum Thresholds
+- **Normal Body Text (< 18pt regular):** Minimum contrast ratio of **4.5:1** against its immediate background.
+- **Large Text (>= 18pt regular or >= 14pt bold):** Minimum contrast ratio of **3:1**.
+- **Interactive UI Components & Hairlines:** Minimum contrast ratio of **3:1** against adjacent surfaces.
+
+### Banned Contrast Sins
+- **No Low-Contrast Gray-on-Gray Slop:** Never place `#71717A` body text on a `#18181B` card surface. Secondary metadata may use muted text only if text size is at least 11px and contrast is verified >= 4.5:1.
+- **No White Text Over Light Gradients:** If using a gradient, text passing over it must maintain 4.5:1 contrast across the *entire* gradient spectrum, not just the dark endpoint.
+
+---
+
+## 2. Keyboard Navigation & Focus Management
+
+### Visible Focus Indicators
+- Every interactive element (`<button>`, `<a>`, `<input>`, `<select>`, `<textarea>`) must display a visible, unclipped focus indicator upon keyboard Tab navigation:
+  ```css
+  :focus-visible {
+    outline: 2px solid #818CF8;
+    outline-offset: 2px;
+  }
+  ```
+- **FORBIDDEN:** Setting `outline: none` or `outline: 0` without immediately supplying a custom focus indicator.
+
+### Modals, Drawers & Focus Trapping
+- **Escape Key Interception:** Any open modal, drawer, dropdown, or overlay dialog MUST close immediately upon pressing the `Escape` key.
+- **Focus Restoration:** Upon closing an overlay, focus must return directly to the trigger button that launched it.
+- **Focus Trap:** When a modal is open, keyboard `Tab` cycles only through interactive elements inside the modal; background page content must be inert (`aria-hidden="true"` or `inert`).
+
+---
+
+## 3. Touch Targets & Tactile Ergonomics
+
+- **Minimum Dimensions:** All buttons, toggle switches, links, and icon triggers on touch screens must measure at least **44x44px** (or provide 44px of hit area via padding).
+- **Spacing Between Targets:** Adjacent touch controls must have at least `8px` of separation to prevent accidental mis-taps.
+
+---
+
+## 4. Semantics & Screen Reader Affordances
+
+### Native HTML First
+- Use `<button>` for actions. Use `<a href="...">` for navigation to real URLs.
+- **FORBIDDEN:** `<div onClick={...}>` or `<span onClick={...}>` without `role="button"`, `tabIndex={0}`, and `onKeyDown` handlers.
+
+### Icon Buttons & Accessible Labels
+- Every button containing only an SVG or icon glyph **MUST** have an accessible text label:
+  ```html
+  <button aria-label="Close dialog">
+    <svg aria-hidden="true">...</svg>
+  </button>
+  ```
+- All decorative images must declare empty `alt=""`. All content images must have concise, descriptive `alt` text.
+
+### Form Fields
+- Every `<input>`, `<textarea>`, and `<select>` must have a visible `<label>` bound via `id` and `for`:
+  ```html
+  <label for="session-id">Session ID</label>
+  <input id="session-id" type="text" />
+  ```
+- Never rely solely on `placeholder="..."` as the field label. Placeholders disappear when typed and fail contrast checks.

package/.openclaw/skills/chill-slop-mobile/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: chill-slop-mobile
+description: "Comprehensive Mobile & Responsive Engineering Standard. Zero horizontal viewport overflow, fluid CSS clamp typography, thumb-zone ergonomics, and cleanly scrollable data views without bloated media queries."
+license: MIT
+---
+
+# ChillSlop Mobile: Comprehensive Responsive Engineering Standard
+
+> *"A responsive design works everywhere by default, not through 50 brittle media query overrides."*
+
+---
+
+## 1. Zero Horizontal Overflow Mandate
+
+- **The Rule:** The viewport must NEVER produce horizontal scrollbars (`overflow-x: hidden` on `<body>` is a lazy band-aid that hides layout defects; you must eliminate the protruding elements directly).
+- **Causes & Fixes:**
+  - *Fixed Pixel Widths:* Never write `width: 600px`. Use `width: 100%; max-width: 600px;`.
+  - *Large Images / SVGs:* Ensure all images declare `max-width: 100%; height: auto;`.
+  - *Code Blocks & Data Tables:* Wrap tables and code views inside an explicit horizontal scrolling container:
+    ```css
+    .table-wrapper {
+      width: 100%;
+      overflow-x: auto;
+      -webkit-overflow-scrolling: touch;
+      border: 1px solid #26262E;
+      border-radius: 6px;
+    }
+    ```
+
+---
+
+## 2. Fluid Typography & The Modular Scale
+
+Avoid massive static header font sizes that blow out mobile viewports. Use mathematical CSS `clamp()`:
+
+### Fluid Header Formulas
+```css
+/* Responsive H1: 32px on 320px mobile up to 54px on 1280px desktop */
+h1 {
+  font-size: clamp(2rem, 1.5rem + 2.5vw, 3.375rem);
+  line-height: 1.1;
+  letter-spacing: -0.025em;
+}
+
+/* Responsive H2: 24px on mobile up to 36px on desktop */
+h2 {
+  font-size: clamp(1.5rem, 1.25rem + 1.25vw, 2.25rem);
+  line-height: 1.2;
+}
+
+/* Responsive Body */
+p, body {
+  font-size: 14px;
+  line-height: 1.6;
+}
+@media (min-width: 768px) {
+  p, body {
+    font-size: 15px;
+  }
+}
+```
+
+---
+
+## 3. Thumb-Zone Architecture & Safe Areas
+
+### Ergonomic Zones
+On mobile devices, user thumbs naturally rest on the bottom third of the screen:
+- **Bottom Navigation & Actions:** Place high-frequency buttons (Submit, Filter, Fork, Run) in a sticky bottom action bar or within easy thumb reach.
+- **Top Bar:** Reserve the top navigation bar for secondary navigation links, search, and settings.
+
+### Hardware Safe Areas
+Sticky bottom action bars and mobile drawers must respect mobile home indicators:
+```css
+.bottom-action-bar {
+  position: sticky;
+  bottom: 0;
+  padding-bottom: max(12px, env(safe-area-inset-bottom));
+  background: rgba(16, 16, 20, 0.95);
+  backdrop-filter: blur(8px);
+  border-top: 1px solid #26262E;
+}
+```
+
+---
+
+## 4. Mobile Breakpoints Architecture
+
+Keep responsive logic lean. Do not declare 10 different media queries. Stick to 3 standard anchors:
+
+| Breakpoint | Width | Target Layout |
+|---|---|---|
+| **Mobile** | `< 768px` | Single-column stacked layouts, bottom sheets, scrollable table containers. |
+| **Tablet** | `768px - 1024px` | 2-column layouts, collapsible sidebars. |
+| **Desktop**| `> 1024px` | Full multi-column workspaces, split diff inspectors, fixed navigation rails. |

package/.openclaw/skills/chill-slop-ui/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: chill-slop-ui
+description: "Comprehensive Visual Engineering Standard. Deep carbon monochrome palettes, 1px hairline borders, tabular monospace data, asymmetric layout density, and zero generic AI gradients or pill cards."
+license: MIT
+---
+
+# ChillSlop UI: Comprehensive Visual Engineering Standard
+
+> *"Good design is as little design as possible. Less, but better — because it concentrates on the essential aspects."*
+
+---
+
+## 1. Color Architecture & Surface Hierarchy
+
+### The Monochromatic Foundation
+Build 90% of the interface in crisp monochromatic shades. This grounds the interface and lets content stand out:
+
+| Layer | Hex Value | Purpose |
+|---|---|---|
+| **Canvas Background** | `#09090B` | Base canvas. Deep obsidian carbon, non-reflective. |
+| **Panel Surface** | `#111114` | Sidebars, section containers, grouped blocks. |
+| **Interactive Surface** | `#16161C` | Cards, table headers, text inputs, inactive buttons. |
+| **Active / Hover Surface**| `#1E1E26` | Interactive hover targets, selected tabs. |
+| **Hairline Border** | `#26262E` | 1px crisp separation lines. Never use blurry shadows for borders. |
+| **Focus / Active Border** | `#3F3F4E` | Focus indicators, active cards, highlighted inputs. |
+
+### Semantic Accent Discipline
+Bright colors are strictly functional signals, never background wallpaper:
+- **Emerald (`#10B981`):** Cache hits, active streams, verified statuses, low latencies.
+- **Amber (`#F59E0B`):** Pruned content, warnings, pending transactions, rate-limits.
+- **Rose (`#F43F5E`):** Circuit breakers, fatal errors, destructive actions, high drop-off.
+- **Indigo (`#818CF8`):** Branched DAG sessions, active tabs, navigation anchors.
+
+> **Dose Cap Rule:** No single screen may use more than 1 semantic accent color as a dominant highlight. A page painted with emerald borders, indigo buttons, and amber cards is rejected as AI Slop.
+
+---
+
+## 2. Geometry, Elevation & Spacing
+
+### Border Radius Hierarchy
+Never make every element on the screen a pill bubble (`rounded-3xl` / `rounded-full`). Follow a strict radius scale:
+- **Tags, Micro-Badges, Code Chips:** `4px`
+- **Buttons, Text Inputs, Dropdown Items:** `6px`
+- **Cards, Panels, Modals, Code Blocks:** `8px`
+- **Outer Shell / Max Container:** `12px` (Never exceed `12px` for desktop utility interfaces).
+
+### Depth Through Hairline Borders (No Muddy Shadows)
+- Replace 20px-30px blurred ambient shadows with:
+  `border: 1px solid #26262E;`
+- For elevated modal popups or floating dropdowns, use tight micro-ambient elevation:
+  `box-shadow: 0 4px 12px rgba(0, 0, 0, 0.6), 0 0 0 1px #26262E;`
+
+### Modular Spacing Scale
+Never use arbitrary padding or margins (e.g. `margin-top: 19px`). Follow the 4px/8px modular rhythm:
+`4px` → `8px` → `12px` → `16px` → `24px` → `32px` → `48px` → `64px` → `96px`.
+
+---
+
+## 3. Typography & Numerals
+
+### Font Pairing Rules
+- **Sans Display & Body:** Inter, Geist Sans, -apple-system, BlinkMacSystemFont, Roboto.
+- **Data, Metrics, Code & Hashes:** JetBrains Mono, Fira Code, SF Mono, ui-monospace.
+- **Letter Spacing:**
+  - Large Section Headers (>= 28px): `letter-spacing: -0.025em;`
+  - Body Text: `letter-spacing: normal;`
+  - Uppercase Metadata Badges (<= 11px): `letter-spacing: +0.05em; text-transform: uppercase;`
+
+### The Tabular Monospace Mandate
+Every timestamp, latency number, hash string, currency value, token counter, and percentage **MUST** use a monospace font or:
+`font-variant-numeric: tabular-nums;`
+*Why:* Proportional fonts cause layout shifting and jitter when real-time numbers update.
+
+---
+
+## 4. Component Engineering Patterns
+
+### Feature Sections (Breaking the 3-Card Cliche)
+- **FORBIDDEN:** 3 identical feature cards with a centered circle icon, bold title, and 2 lines of lorem ipsum.
+- **REQUIRED:** Asymmetric density:
+  - Card 1: Interactive live code preview or syntax block.
+  - Card 2: High-density tabular telemetry feed.
+  - Card 3: Split-screen flow diagram with step connectors.
+
+### Buttons & Controls
+- **Minimum Tap Target:** Mobile tap targets must measure at least `44x44px` (desktop compact controls may be `32px` to `36px` height with generous click padding).
+- **Cursor Affordance:**
+  - Enabled: `cursor: pointer;`
+  - Disabled: `cursor: not-allowed; opacity: 0.45;`
+- **Focus Rings:**
+  `outline: 2px solid #818CF8; outline-offset: 2px;`
+  Never ship `outline: none` without providing this high-visibility ring.
+
+### Data Tables
+- Always use zebra-striping or 1px hairline dividers: `border-bottom: 1px solid #26262E`.
+- Numeric columns must align **Right**. Text columns align **Left**. Status badges align **Center**.
+
+---
+
+## 5. Motion & Kinetic Physics
+
+- **Timing Range:** `120ms` to `180ms` for micro-interactions (hovers, clicks); `220ms` to `280ms` for spatial transitions (drawers, dialogs).
+- **Easing Curve:** `cubic-bezier(0.16, 1, 0.3, 1)` (Deceleration curve for crisp, tactile snap).
+- **Reduced Motion Support:**
+  ```css
+  @media (prefers-reduced-motion: reduce) {
+    *, ::before, ::after {
+      animation-duration: 0.01ms !important;
+      animation-iteration-count: 1 !important;
+      transition-duration: 0.01ms !important;
+      scroll-behavior: auto !important;
+    }
+  }
+  ```

package/.openclaw/skills/ponytail/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: ponytail
+description: >
+  Lazy senior dev mode: the smallest change that fully solves the task, and a
+  reply a busy human understands in one read. Use on any coding task (writing,
+  fixing, refactoring, reviewing, choosing dependencies) and when the user says
+  "ponytail", "be lazy", "simplest solution", "yagni", or complains about
+  over-engineering or bloat. Levels: lite, full (default), ultra.
+argument-hint: "[lite|full|ultra|off]"
+license: MIT
+---
+
+# Ponytail
+
+You are a lazy senior developer. The best code is the code never written. You solve the whole problem with the least new code. End your reply with one or two lines: what you skipped or did not check, and any risk the user must know.
+
+Active for the whole session until the user says "stop ponytail" or "normal mode". Switch level: `/ponytail lite|full|ultra`.
+
+## Before you write
+
+Read the task and the code it touches. List every place your change must reach: callers, tests, fixtures, config, exports. Check what your change could break for users: data it would destroy or expose, callers that stop working. That is scope. Extra features are not.
+
+## The smallest complete change
+
+Take the first option that fully works:
+
+1. Does it need to exist? Skip features, options and flexibility nobody asked for, and name them in one line. A vague request ("build me X") gets the smallest version that does the core job.
+2. Already in this codebase (a helper, component, service, pattern)? Use it the way the surrounding code does.
+3. Standard library or a platform feature? Use it, unless the project has its own. A house component beats a native widget.
+4. An installed dependency? Use it. Never add a dependency for a few lines.
+5. Can it be one line a reader gets at a glance? One line.
+6. Otherwise: the minimum code that works.
+
+- Be lazy about the solution, never about the change itself: finish every part the task needs, including the callers, tests and fixtures your change breaks.
+- No abstraction, wrapper, type conversion, option, config, boilerplate or "for later" code nobody asked for. Keep values in the form the platform already gives you. Deletion beats addition. Keep the structure the codebase already has: its layers, interfaces and conventions.
+- The shortest working diff wins, once you know everything it must touch. A one-liner that needs decoding is not short.
+- Comment only the why the code cannot show, in one line.
+- Bug fix: before you edit, grep every caller of the function you touch, then fix the root cause once in the shared code.
+- Code you move or merge keeps its error handling and validation.
+- Between options of equal size, take the one that is correct on edge cases.
+- Lazy code without its check is unfinished: new non-trivial logic (a branch, a loop, a parser, money or security, or a whole new script or app) leaves one small test or an assert-based self-check. Trivial changes need none.
+- A shortcut with a known limit gets a code comment in this form: `shortcut: <the limit>, <when to upgrade>`.
+
+Never cut: validation at trust boundaries, error handling that prevents data loss, security, accessibility, the calibration real hardware needs, anything the user asked for.
+
+## Levels
+
+| Level | Behavior |
+|-------|----------|
+| **lite** | Build what was asked. Name the smaller option in one line and let the user pick. |
+| **full** | The rules above. Default. |
+| **ultra** | Also question the request: before building, push back on any part the need does not justify. |

package/.openclaw/skills/ponytail-audit/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: ponytail-audit
+description: >
+  Quality audit of a whole repo: bugs, security holes, what breaks under real
+  load, risky code without tests, slow paths, and what to delete, merge or
+  split. Ranked, each finding explained in plain English. One-shot report,
+  changes nothing. Use for "audit this codebase", "review the whole repo",
+  "find bloat", "what can I delete", /ponytail-audit.
+---
+
+Audit the whole repo like the senior developer who just inherited it and
+will be paged when it breaks. Order of importance: correct, safe, holds under
+load, tested, fast, lean. Lean still matters: every extra line must be read,
+tested and fixed later. This is a report the user asked for, so give it in full.
+
+## 1. Map first
+
+- Audit what the user names: a folder, a package, or the whole repo.
+  Nothing named: the whole repo.
+- Read the README, the deploy and build config, the dependency list, the
+  entry points (main, routes, handlers, jobs, CLI commands) and the tests.
+- Find the expected load: one person running a script, or many users and
+  processes at once. Judge scale against that, and say which load you assumed.
+- Trace the main flows end to end: where data comes in, what is stored,
+  what goes out. Read those paths fully: input from users, money, auth,
+  data writes, background jobs, anything shared between processes.
+- Big repo: go deep where a mistake costs the most, not file by file. Say
+  which parts you did not read.
+
+## 2. Look for
+
+1. **Bug:** wrong result, crash, missed edge case (empty, zero, last item,
+   rounding, time zones), callers that disagree with what a function returns,
+   the same rule applied differently in two places.
+2. **Risk:** security holes (injection, weak randomness, secrets in code,
+   missing checks on input from users), data loss (errors swallowed, writes
+   in the wrong order, no transaction).
+3. **Scale:** fine for one user, wrong for many: check-then-write races, the
+   same work done by every process, memory or lists that only grow, a query
+   per item, O(n^2) on big input, per-process state that must be shared.
+4. **Missing test:** risky logic (a branch, a parser, money, security, data
+   writes) with no test that fails when it breaks. One good test, not coverage.
+5. **Speed:** big slowdowns are problems. Small wins (work repeated in a hot
+   loop) are suggestions; some software counts every millisecond.
+6. **Lean:** code that should not exist or should be smaller.
+   - delete: dead code, unused options, flags and config, speculative features
+   - reuse: two helpers doing the same thing (keep one, name the path)
+   - stdlib / native: the standard library or platform already does it;
+     a dependency doing what a few lines or the platform can do
+   - yagni: interface with one implementation, factory with one product,
+     wrapper that only passes calls through
+   - merge: near-copies that must change together
+   - split: one function or class doing several unrelated jobs, so it is
+     hard to read or test. Split by job, never by line count, and never into
+     helpers that exist only to make a function shorter.
+
+## 3. Check before you report
+
+- Every finding needs a concrete case: "this input or situation leads to this
+  wrong result". No case, no finding.
+- Before calling code unused, grep the whole tree for it, including tests,
+  fixtures, config, and string or dynamic references.
+- A shortcut marked with a `shortcut:` (or older `ponytail:`) comment that names its limit is a
+  decision, not a finding, unless the expected load already crosses it.
+- Propose the smallest fix that works. Prefer fixes that delete code. Never
+  add layers, frameworks or config the problem does not need.
+- No style taste, no "consider", no vague worries.
+
+## 4. Output
+
+Very simple English: short sentences, everyday words. Explain a technical
+term the first time you use it. The reader may never have seen this code.
+
+Start with `What this repo does:` in two or three sentences, and the load
+you assumed.
+
+Then the findings in three groups, most important first, skip empty groups:
+- **Must fix:** bug, security, data loss, breaks at the expected load.
+- **Should fix:** risky code without a test, real slowness, duplication, a
+  function that mixes jobs, code that should not exist.
+- **Nice to have:** small speed-ups, shorter forms.
+
+Number findings across all groups, so the user can say "fix 2 and 5". At
+most 20 findings; if you left smaller ones out, say how many.
+Every finding has all four parts, each one or two short sentences:
+
+2. **Orders land on the wrong day** (`billing/close_day.py:L40-52`)
+   - **What this is:** At midnight this job closes the day and bills all orders of that day.
+   - **Problem:** It takes "today" from the server clock, which runs in UTC. An order placed
+     at 00:30 in Berlin is billed on the day before.
+   - **Fix:** Compute the day once in the shop's time zone:
+     `datetime.now(ZoneInfo("Europe/Berlin")).date()`. One line, nothing else changes.
+   - **If we skip it:** Late orders show the wrong date, and accounting fixes them by hand.
+
+End with:
+- `Verdict:` one line: healthy, or what to fix first.
+- `Lean: -<N> lines, -<M> dependencies possible.` when lean findings exist.
+- `Not checked:` the parts you did not read or could not run.
+
+Nothing found: `What this repo does:`, then `Healthy. Nothing to fix.` and
+one line on what you checked.
+
+One-shot report, changes no code.

package/.openclaw/skills/ponytail-debt/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: ponytail-debt
+description: >
+  List every `shortcut:` comment (and older `ponytail:` ones) as a debt ledger. One-shot report,
+  changes nothing. Use for "ponytail debt", "what did ponytail defer", "list the
+  shortcuts", /ponytail-debt.
+---
+
+Every deliberate ponytail shortcut is marked with a `shortcut:` comment naming
+its ceiling and upgrade path (older code may say `ponytail:`). This collects them into one ledger so a deferral
+can't quietly become permanent.
+
+## Scan
+
+Grep the repo for comment markers, skipping `.git` and everything the
+`.gitignore` files ignore (dependencies, build output, caches, in any stack):
+
+`git grep --no-index --exclude-standard -nE '(#|//|/[*]) ?(shortcut|ponytail):'`  (add other comment prefixes if your stack uses them)
+
+If the user names their own marker word (`/ponytail-debt TODO`), grep for that word instead.
+
+Each hit is one ledger row. The comment prefix keeps prose that merely mentions
+the convention out of the ledger. Skip hits that are not a deferral, like a note
+about a keyboard shortcut.
+
+## Output
+
+One row per marker, grouped by file:
+
+`<file>:<line>, <what was simplified>. ceiling: <the limit named>. upgrade: <the trigger to revisit>.`
+
+The convention is `shortcut: <ceiling>, <upgrade path>`, so pull the ceiling
+and the trigger straight from the comment. Want an owner per row too? add
+`git blame -L<line>,<line>`.
+
+Flag the rot risk: any marker comment that names no upgrade path or
+trigger gets a `no-trigger` tag, those are the ones that silently rot.
+
+End with `<N> markers, <M> with no trigger.` Nothing found: `No shortcut debt. Clean ledger.`
+
+## Boundaries
+
+Reads and reports only, changes nothing. To persist it, ask and it writes the
+ledger to a file (e.g. `PONYTAIL-DEBT.md`). One-shot.

package/.openclaw/skills/ponytail-gain/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: ponytail-gain
+description: >
+  Show ponytail's measured savings (code, cost, speed) from the benchmark.
+  One-shot display. Use for /ponytail-gain, "what does ponytail save",
+  "ponytail impact".
+---
+
+# Ponytail Gain
+
+Display this scoreboard when invoked. One-shot: do NOT change mode, write flag
+files, or persist anything.
+
+The figures are the published agentic benchmark of Ponytail 5: headless Claude
+Code (Opus 5.5, default effort) on 39 tasks (feature tickets in a real FastAPI +
+React repo, bug fixes, security and privacy cases, small apps), 5 runs each,
+against the same agent without the skill. 18 of the tasks have hidden checks
+for correctness and safety. Each figure is the geometric mean of the per-task
+medians. They are measured, not computed from the current repo.
+Source: `benchmarks/results/2026-10-07-agentic.md` and the README.
+
+## Scoreboard
+
+Render plain ASCII bars. The bar length shows ponytail as a share of the
+no-skill baseline; the label carries the exact figure:
+
+```
+  ponytail gain           benchmark · 39 tasks × 5 runs · Opus 5.5
+
+  no-skill        ████████████████████  100%
+  Lines of code   █████████···········   47%   ▼ 53%
+  Output tokens   ███████████·········   55%   ▼ 45%
+  Cost            ███████████████·····   74%   ▼ 26%
+  Time            ████████████········   59%   ▼ 41%
+  Hidden checks passed   97%  (no-skill 96%)
+  Tests where the logic needs one   98%  (no-skill 68%)
+
+  This repo:  /ponytail-debt  (shortcuts you deferred)
+              /ponytail-audit (what's still cuttable)
+```
+
+## Honesty boundary
+
+These are benchmark averages, not this repo. NEVER print a per-repo savings
+number ("you saved X lines/tokens here"): the unbuilt version was never
+written, so there is no real baseline to subtract from in a live repo. The
+only real per-repo figures come from `/ponytail-debt` (a counted ledger), and
+this card points there instead of inventing one.
+
+## Boundaries
+
+One-shot display. Edits nothing, changes no mode.