@herbertgao/pi-extensions 2026.10.0 → 2026.10.2

package/README.md

@@ -18,27 +18,27 @@ When migrating from `pi-mcp-adapter`, remove any standalone adapter install as w
 
 ## Bundled extensions
 
-The package bundles 4 active `@herbertgao/*` child packages—`pi-bark`, `pi-cc-extensions`, `pi-subagents`, and `sol-pi`—plus the following upstream packages under their original names:
+The package bundles 5 active `@herbertgao/*` child packages—`pi-agency`, `pi-bark`, `pi-cc-extensions`, `pi-subagents`, and `sol-pi`—plus the following upstream packages under their original names:
 
-- `pi-antigravity@0.9.0`
-- `@dietrichgebert/ponytail@4.10.0`
+- `pi-antigravity@0.10.0`
+- `@dietrichgebert/ponytail@5.1.0`
 - `@juicesharp/rpiv-ask-user-question@2.12.0`
 - `@narumitw/pi-btw@0.61.1`
-- `@narumitw/pi-caffeinate@0.49.8`
+- `@narumitw/pi-caffeinate@0.49.10`
 - `@pi-plugins/fast-mode@0.1.13`
 - `@tifan/pi-copy-response@0.2.7`
 - `@tifan/pi-handoff@2.2.2`
 - `@tifan/pi-inline-skills@1.0.6`
-- `@tifan/pi-mermaid-open@0.2.1`
+- `@tifan/pi-mermaid-open@0.2.2`
 - `@tifan/pi-preferred-thinking@1.0.2`
-- `@tifan/pi-recap@0.4.7`
+- `@tifan/pi-recap@0.4.8`
 - `@tifan/pi-rename@0.6.0`
-- `pi-typesafe@0.8.1`
+- `pi-typesafe@0.9.1`
 - `pi-multi-account@1.24.0`
 - `pi-next-cue@1.0.7`
 - `pi-jev-auto-mode@0.5.0`
-- `pi-lens@4.3.0`
-- `pi-web-access@0.35.0`
+- `pi-lens@4.4.0`
+- `pi-web-access@0.37.0`
 - `remote-pi@0.7.0`
 - `resume-from@0.4.1`
 
@@ -48,15 +48,19 @@ The local `@herbertgao/resume-from` fork is retired. If it is installed separate
 
 The locally customized CC and SoL-Pi packages now follow complete upstream baselines `pi-cc-extensions@0.9.10` and SoL-Pi main `e1a586af`, with local behavior replayed on top. Action Fusion and ccstyle write rich diffs coexist without disabling either feature. All four SoL-Pi features remain opt-in; its new non-persistent-session evidence archives remain on disk for consumers and require host or caller cleanup.
 
+### Agency Agents
+
+`@herbertgao/pi-agency` adds `agency_search` and `agency_dispatch` for the [Agency Agents](https://github.com/msitarzewski/agency-agents) catalog cloned at `~/.agency-agents`. Search returns ranked persona cards instead of catalog listings. Dispatch fills persona bodies into subagent prompts outside the main context, runs them as parallel foreground `Agent` calls, and reports each sent prompt's SHA-256. Installing the aggregate does not clone the catalog; see the [package README](../pi-agency/README.md).
+
 ### Bark notifications
 
 `@herbertgao/pi-bark` sends localized Bark pushes when a user-facing Pi run fully settles or `@juicesharp/rpiv-ask-user-question` needs an answer. Notifications include emoji-labeled machine/path metadata and support the bundled official Pi badge through Bark's `icon` parameter. Configure it in `$PI_CODING_AGENT_DIR/bark.json` (normally `~/.pi/agent/bark.json`); see the [package README](../pi-bark/README.md). Without a valid endpoint it stays inactive.
 
-`@narumitw/pi-caffeinate@0.49.8` uses the host platform's sleep inhibitor during each Pi agent run. On macOS, `/caffeinate sleep` keeps the system awake while allowing the display to sleep; `/caffeinate display` also keeps the display awake. It releases the inhibitor when the run or session ends.
+`@narumitw/pi-caffeinate@0.49.10` uses the host platform's sleep inhibitor during each Pi agent run. On macOS, `/caffeinate sleep` keeps the system awake while allowing the display to sleep; `/caffeinate display` also keeps the display awake. It releases the inhibitor when the run or session ends. Its D-Bus dependency remains on the normal socket transport under Node; Bun on Linux/macOS can use FFI and an in-process reader thread for Unix file-descriptor transport, falling back when unavailable. No daemon or build step is added.
 
-`pi-jev-auto-mode@0.5.0` adds fail-closed Jev safety gates for shell commands and file changes. `pi-typesafe@0.8.1` adds the `/typesafe` command and `typesafe_evaluate` tool for explicit structured decisions; both use the TypeSafe API after login.
+`pi-jev-auto-mode@0.5.0` adds fail-closed Jev safety gates for shell commands and file changes. `pi-typesafe@0.9.1` provides `/typesafe` and `typesafe_evaluate` for explicit structured decisions; `/typesafe enable` or `PI_TYPESAFE_ENABLED=1` is still required for agent tool calls. The Pi extension continues to use the TypeSafe API, not Liquid. The package's programmatic client additionally supports Liquid with its own API key and free or paid models; existing usage accounting now merges writes under a short-lived file lock (up to 200ms synchronous wait under contention).
 
-`resume-from@0.4.1` continues sessions across Pi, Claude Code, and Codex; it keeps a Claude Code session matched to its start directory when the active transcript later moves into a nested cwd. `@herbertgao/sol-pi` adds opt-in Action Fusion, ObservationPack, Evidence-Preserving Reducer, and Online Context Compact; see its [configuration guide](../sol-pi/docs/configuration.md). `pi-lens@4.3.0` expands language routing and bounds retained diagnostic facts across multi-root sessions. `pi-web-access@0.35.0` provides configurable web search and fetch tools; its `toolActivation` defaults to `auto`, choosing eager or dynamic tool activation per model. `pi-antigravity@0.9.0` reads Pi 0.86+ transcript system messages, so Antigravity requests carry Pi's system prompt and tools; it also registers `google_search` and `generate_image` tools that use the signed-in Antigravity account. Preferred Thinking 1.0.2 preserves an explicit subagent `--thinking` choice. Deprecated `@tifan/pi-titlebar-spinner` is no longer bundled; Rename remains the single owner of Herdr tab naming.
+`resume-from@0.4.1` continues sessions across Pi, Claude Code, and Codex; it keeps a Claude Code session matched to its start directory when the active transcript later moves into a nested cwd. `@herbertgao/sol-pi` adds opt-in Action Fusion, ObservationPack, Evidence-Preserving Reducer, and Online Context Compact; see its [configuration guide](../sol-pi/docs/configuration.md). `pi-lens@4.4.0` expands language routing and bounds retained diagnostic facts across multi-root sessions. `pi-web-access@0.37.0` provides configurable web search and fetch tools; its `toolActivation` defaults to `auto`, choosing eager or dynamic tool activation per model. It adds structured search/fetch data for codemode and an optional, manually started `pi-web-access-mcp` stdio CLI; installing the aggregate does not start that server. Degoog and Keenable are explicit-only providers, excluded from automatic and `all` selection. Perplexity search now uses the Search API's ranked pages and snippets rather than a Sonar-generated answer; requests requiring prose still use Sonar. `pi-antigravity@0.10.0` reads Pi 0.86+ transcript system messages, so Antigravity requests carry Pi's system prompt and tools; it also registers `google_search` and `generate_image` tools that use the signed-in Antigravity account. Preferred Thinking 1.0.2 preserves an explicit subagent `--thinking` choice. Deprecated `@tifan/pi-titlebar-spinner` is no longer bundled; Rename remains the single owner of Herdr tab naming.
 
 `pi-stash` is no longer bundled: `/btw` already preserves the main editor draft while handling side questions outside the main conversation. Prior `@herbertgao/pi-stash` releases remain available but are no longer maintained here.
 

package/THIRD_PARTY_NOTICES.md

@@ -62,7 +62,7 @@ SOFTWARE.
 
 ## `@narumitw/pi-caffeinate`
 
-The aggregate bundles [`@narumitw/pi-caffeinate`](https://github.com/narumiruna/pi-extensions/tree/main/packages/pi-caffeinate) version 0.49.7 under its original MIT license:
+The aggregate bundles [`@narumitw/pi-caffeinate`](https://github.com/narumiruna/pi-extensions/tree/main/packages/pi-caffeinate) version 0.49.10 under its original MIT license:
 
 MIT License
 
@@ -112,7 +112,7 @@ THE SOFTWARE.
 
 ## `pi-antigravity`
 
-The aggregate bundles the MIT-licensed [`pi-antigravity`](https://github.com/Rahularya01/pi-antigravity) package version 0.9.0 under its original attribution:
+The aggregate bundles the MIT-licensed [`pi-antigravity`](https://github.com/Rahularya01/pi-antigravity) package version 0.10.0 under its original attribution:
 
 MIT License
 
@@ -137,7 +137,7 @@ THE SOFTWARE.
 
 ## `pi-typesafe`
 
-The aggregate bundles [`pi-typesafe`](https://github.com/DevMortimer/pi-typesafe) version 0.5.0 under its original MIT license:
+The aggregate bundles [`pi-typesafe`](https://github.com/DevMortimer/pi-typesafe) version 0.9.1 under its original MIT license:
 
 MIT License
 

package/node_modules/@dietrichgebert/ponytail/.opencode/command/ponytail-audit.md

@@ -1,5 +1,5 @@
 ---
-description: Audit the whole repo for over-engineering, what can be deleted
+description: Quality audit of the whole repo: bugs, security, load, tests, speed, bloat
 ---
 
-Audit the entire repository for over-engineering only, not correctness. Scan the whole tree, not a diff. One line per finding, ranked biggest cut first: <tag> <what to cut>. <replacement>. [path]. Tags: delete (dead code/speculative feature), stdlib (reinvented standard library), native (dependency doing what the platform does), yagni (abstraction with one implementation), shrink (same logic, fewer lines). End with the net lines and dependencies removable. If nothing to cut: 'Lean already. Ship.'
+Audit the whole repository (or the folder the user names) like the senior developer who just inherited it. Map first: README, deploy and build config, dependencies, entry points, tests; find the expected load (one person or many users and processes); trace the main flows and read fully the paths with user input, money, auth, data writes, background jobs and shared state. Look for, in this order: bugs, risk (security holes, data loss), scale (races, the same work done by every process, memory that only grows, a query per item, O(n^2)), risky logic without a test, slow code (big = problem, small = suggestion), lean (dead code, duplicate helpers, stdlib or native instead of custom code or a dependency, abstractions with one implementation, near-copies to merge, a function doing several unrelated jobs to split, never split by line count). Before calling code unused, grep the whole tree including tests, fixtures, config and string references. Every finding needs a concrete case. A shortcut marked with a shortcut: (or older ponytail:) comment that names its limit is a decision, not a finding. Propose the smallest fix, prefer deleting code, never add layers. Very simple English. Start with 'What this repo does:' and the load you assumed. Then at most 20 numbered findings grouped Must fix / Should fix / Nice to have, most important first; each: a bold title with file:lines, then four bullets: What this is, Problem, Fix, If we skip it. End with 'Verdict:', 'Lean: -N lines, -M dependencies possible.' and 'Not checked:' for the parts you did not read. Change no code.

package/node_modules/@dietrichgebert/ponytail/.opencode/command/ponytail-debt.md

@@ -1,5 +1,5 @@
 ---
-description: "Harvest ponytail: comments into a tracked debt ledger"
+description: "Harvest shortcut: comments into a tracked debt ledger"
 ---
 
-Harvest every `ponytail:` comment in this repository into a debt ledger so deferrals do not rot into 'later means never'. Grep the whole tree for comment markers (grep -rnE '(#|//) ?ponytail:' ., skipping node_modules/.git/build output). One row per marker, grouped by file: <file>:<line>, <what was simplified>. ceiling: <the limit named in the comment>. upgrade: <the trigger to revisit>. Tag any marker that names no upgrade path or trigger as no-trigger, those rot silently. End with the count of markers and how many lack a trigger. If none: 'No ponytail: debt. Clean ledger.' Report only, change nothing.
+Harvest every `shortcut:` comment (and older `ponytail:` ones) in this repository into a debt ledger so deferrals do not rot into 'later means never'. Grep the whole tree for comment markers (grep -rnE --exclude-dir=.git --exclude-dir=node_modules --exclude-dir=dist --exclude-dir=build '(#|//|/[*]) ?(shortcut|ponytail):' ., skipping node_modules/.git/build output; if the user names their own marker word, grep for that instead; skip hits that are not a deferral, like a keyboard-shortcut note). One row per marker, grouped by file: <file>:<line>, <what was simplified>. ceiling: <the limit named in the comment>. upgrade: <the trigger to revisit>. Tag any marker that names no upgrade path or trigger as no-trigger, those rot silently. End with the count of markers and how many lack a trigger. If none: 'No shortcut debt. Clean ledger.' Report only, change nothing.

package/node_modules/@dietrichgebert/ponytail/.opencode/command/ponytail-gain.md

@@ -2,4 +2,4 @@
 description: Show ponytail's measured impact scoreboard (less code, cost, time)
 ---
 
-Show the ponytail gain scoreboard. One shot, change nothing: do not switch mode, write flag files, or persist anything. Render the published benchmark medians (5 everyday tasks; models Haiku, Sonnet, Opus; source benchmarks/ and the README) as plain ASCII bars: Lines of code, no-skill 100% vs ponytail 6-20% (down 80-94%); Cost, no-skill 100% vs ponytail 23-53% (down 47-77%); Speed, ponytail 3-6x faster. The bar length shows the measured range, the label carries the exact figure. These are benchmark medians, not this repo. NEVER print a per-repo savings number: the unbuilt version was never written, so there is no real baseline to subtract from in a live repo. For real per-repo figures, point to /ponytail-debt (the counted shortcut ledger) and /ponytail-audit (what is still cuttable). Report only.
+Show the ponytail gain scoreboard. One shot, change nothing: do not switch mode, write flag files, or persist anything. Render the published agentic benchmark of Ponytail 5 (39 tasks on a real FastAPI + React repo plus bug fixes, security and privacy cases and small apps, Opus 5.5, 5 runs each, against the same agent without the skill; geometric mean of per-task medians; source benchmarks/results/2026-10-07-agentic.md and the README) as plain ASCII bars, ponytail as a share of the no-skill baseline (100%): Lines of code 47% (down 53%); Output tokens 55% (down 45%); Cost 74% (down 26%); Time 59% (down 41%); Hidden checks passed 97% (no-skill 96%; 18 of the tasks have hidden checks for correctness and safety); Tests where the logic needs one 98% (no-skill 68%). The bar length shows the share, the label carries the exact figure. These are benchmark averages, not this repo. NEVER print a per-repo savings number: the unbuilt version was never written, so there is no real baseline to subtract from in a live repo. For real per-repo figures, point to /ponytail-debt (the counted shortcut ledger) and /ponytail-audit (what is still cuttable). Report only.

package/node_modules/@dietrichgebert/ponytail/.opencode/command/ponytail-help.md

@@ -2,4 +2,4 @@
 description: Quick reference for ponytail levels, skills, and commands
 ---
 
-Show the ponytail quick reference. One shot, change nothing: do not switch mode, write flag files, or persist anything. Levels: /ponytail lite (build what's asked, name the lazier alternative in one line), /ponytail (full, the default ladder: YAGNI then stdlib then native then one line then minimum), /ponytail ultra (deletion before addition, challenges the requirement before building). Commands: /ponytail-review (over-engineering review of the current changes), /ponytail-audit (whole-repo over-engineering audit), /ponytail-debt (harvest ponytail: comments into a tracked ledger), /ponytail-gain (measured-impact scoreboard from the benchmark), /ponytail-help (this card). Deactivate with 'stop ponytail', 'normal mode', or /ponytail off; resume anytime with /ponytail. Default mode is full; change it with the PONYTAIL_DEFAULT_MODE environment variable (off|lite|full|ultra) or a config file at ~/.config/ponytail/config.json (Windows: %APPDATA%\ponytail\config.json) with {"defaultMode": "lite"}. Resolution order: env var, then config file, then full.
+Show the ponytail quick reference. One shot, change nothing: do not switch mode, write flag files, or persist anything. Levels: /ponytail lite (build what's asked, name the lazier alternative in one line), /ponytail (full, the default ladder: YAGNI then stdlib then native then one line then minimum), /ponytail ultra (deletion before addition, challenges the requirement before building). Commands: /ponytail-review (over-engineering review of the current changes), /ponytail-audit (whole-repo over-engineering audit), /ponytail-debt (harvest shortcut: comments into a tracked ledger), /ponytail-gain (measured-impact scoreboard from the benchmark), /ponytail-help (this card). Deactivate with 'stop ponytail', 'normal mode', or /ponytail off; resume anytime with /ponytail. Default mode is full; change it with the PONYTAIL_DEFAULT_MODE environment variable (off|lite|full|ultra) or a config file at ~/.config/ponytail/config.json (Windows: %APPDATA%\ponytail\config.json) with {"defaultMode": "lite"}. Resolution order: env var, then config file, then full.

package/node_modules/@dietrichgebert/ponytail/.opencode/command/ponytail-review.md

@@ -1,5 +1,5 @@
 ---
-description: Review changes for over-engineering, what can be deleted
+description: Quality review of the current changes: bugs, security, load, tests, speed, bloat
 ---
 
-Review the current code changes for over-engineering only, not correctness. One line per finding: L<line>: <tag> <what to cut>. <replacement>. Tags: delete (dead code/speculative feature), stdlib (reinvented standard library), native (dependency doing what the platform does), yagni (abstraction with one implementation), shrink (same logic, fewer lines). End with the net lines removable. If nothing to cut: 'Lean already. Ship.'
+Review the current code changes like the senior developer who will be paged when they break. Review what the user names (uncommitted or staged changes, a branch, a PR link, files); nothing named: the uncommitted changes, or the last commit if there are none. First read the code the change touches: callers of every changed function, the functions it calls, the tests, the README (find the expected load: one person or many users and processes). A change can break code it does not touch. Look for, in this order: bugs (wrong result, crash, missed edge case, a caller broken by the change, a fix in one caller while the shared function stays broken), risk (security holes, data loss), scale (check-then-write races, the same work done by every process, memory that only grows, a query per item, O(n^2) on big input), risky logic without a test, slow code (big = problem, small = suggestion), lean (dead code, a helper the repo already has, stdlib or native instead of custom code or a new dependency, abstractions with one implementation, near-copies to merge, a function doing several unrelated jobs to split, never split by line count). Every finding needs a concrete case; re-read the lines to confirm it. A shortcut marked with a shortcut: (or older ponytail:) comment that names its limit is a decision, not a finding. Propose the smallest fix, prefer deleting code, never add layers. No style taste, no vague worries. Very simple English, explain technical terms. Start with 'What this change does:' in two or three sentences and the load you assumed. Then numbered findings grouped Must fix / Should fix / Nice to have; each finding: a bold title with file:lines, then four bullets: What this is, Problem, Fix, If we skip it (one or two short sentences each). End with 'Verdict:', 'Lean: -N lines possible.' when lean findings exist, and 'Not checked:' if something mattered and you could not check it. Nothing found: 'Looks good. Ship.' Change no code.

package/node_modules/@dietrichgebert/ponytail/.opencode/command/ponytail.md

@@ -2,4 +2,4 @@
 description: Switch ponytail intensity level (lite/full/ultra/off)
 ---
 
-Switch to ponytail $ARGUMENTS mode. If no level specified, use full. Lazy senior dev mode, before any code: does it need to exist at all (YAGNI)? Does the standard library do it? A native platform feature? Can it be one line? Build the minimum that works. No unrequested abstractions, no avoidable dependencies, no boilerplate. Mark deliberate simplifications that cut a real corner with a known ceiling using a ponytail: comment that names the ceiling and upgrade path.
+Switch to ponytail $ARGUMENTS mode. With no level, keep the current level, or switch on at the default level if ponytail was off. Lazy senior dev mode, before any code: does it need to exist at all (YAGNI)? Does the standard library do it? A native platform feature? Can it be one line? Build the minimum that works. No unrequested abstractions, no avoidable dependencies, no boilerplate. Mark deliberate simplifications that cut a real corner with a known ceiling using a shortcut: comment that names the ceiling and upgrade path.

package/node_modules/@dietrichgebert/ponytail/.opencode/plugins/index.js

@@ -0,0 +1,4 @@
+// OpenCode 2 loads this file automatically from .opencode/plugins/ and does not
+// read ponytail.mjs next to it, so keep the one-line entry here. npm consumers
+// never see it: package.json main/exports still point at ponytail.mjs.
+export { default } from './ponytail.mjs'

package/node_modules/@dietrichgebert/ponytail/.opencode/plugins/ponytail-frontmatter.cjs

@@ -1,9 +1,9 @@
 'use strict';
 
-// ponytail command-file frontmatter parser.
+// ponytail command-file and SKILL.md frontmatter parser.
 //
 // Pulled out of ponytail.mjs so the plugin module's only top-level export is
-// the plugin function itself. OpenCode's legacy plugin loader (the one that
+// the plugin definition itself. OpenCode's legacy plugin loader (the one that
 // runs before v1 plugins are detected) treats every function exported from a
 // plugin module as a plugin; calling the frontmatter parser as one threw
 // "path must be a string or a file descriptor" because it got the plugin
@@ -20,4 +20,44 @@ function parseCommandFile(filePath) {
   return { description, template: match[2].trim() };
 }
 
-module.exports = { parseCommandFile };
+// ponytail: flat frontmatter only — the shape every shipped SKILL.md uses. A
+// nested key or an anchor is not interpreted, and a real YAML parser is the
+// upgrade path if a skill ever needs one.
+function frontmatterField(frontmatter, key) {
+  const lines = frontmatter.split(/\r?\n/);
+  const at = lines.findIndex((line) => line.startsWith(key + ':'));
+  if (at === -1) return undefined;
+  const value = lines[at].slice(key.length + 1).trim();
+  if (value[0] !== '>' && value[0] !== '|') return value;
+
+  // Block scalar: `>` folds the lines into one, `|` keeps them. Indented lines
+  // continue the block, the next unindented key ends it (skills/ponytail has
+  // `argument-hint` after its description), and a trailing `-` drops the
+  // newline YAML would otherwise close the scalar with.
+  const block = [];
+  for (const line of lines.slice(at + 1)) {
+    if (line.trim() && !/^\s/.test(line)) break;
+    block.push(line.trim());
+  }
+  while (block.length && !block[block.length - 1]) block.pop();
+  const joined = block.join(value[0] === '|' ? '\n' : ' ');
+  return value.endsWith('-') ? joined : joined + '\n';
+}
+
+// OpenCode's V2 skill transform takes the resolved fields, not the file: the
+// skill id is the directory name, and `content` is the body with its
+// frontmatter stripped. Matches what OpenCode itself derives from a discovered
+// .opencode/skills/<id>/SKILL.md.
+function parseSkillFile(filePath) {
+  const fs = require('fs');
+  const content = fs.readFileSync(filePath, 'utf8');
+  const match = content.match(/^---\r?\n([\s\S]*?)\r?\n---[^\S\n]*\r?\n?([\s\S]*)$/);
+  if (!match) return null;
+  return {
+    name: frontmatterField(match[1], 'name'),
+    description: frontmatterField(match[1], 'description'),
+    body: match[2],
+  };
+}
+
+module.exports = { parseCommandFile, parseSkillFile };

package/node_modules/@dietrichgebert/ponytail/.opencode/plugins/ponytail.mjs

@@ -1,19 +1,22 @@
 // ponytail — OpenCode plugin.
 //
 // Injects the ponytail ruleset into every chat's system prompt at the active
-// intensity, persists /ponytail mode switches, and registers slash commands so
-// they work when the package is installed from npm. Reuses the shared
-// instruction builder so Claude Code, Codex, pi, and OpenCode all read one
-// source of truth.
+// intensity, persists /ponytail mode switches, and registers the /ponytail
+// commands and skills so they work when the package is installed from npm.
+// Reuses the shared instruction builder so Claude Code, Codex, pi, and OpenCode
+// all read one source of truth.
 //
 // OpenCode loads this as a server plugin — add it to your opencode.json:
-//   { "plugin": ["@dietrichgebert/ponytail"] }
+//   { "plugins": ["@dietrichgebert/ponytail"] }
+//
+// One default export serves both plugin APIs: V2 reads `id` + `setup`, V1 calls
+// `server()`.
 
-import { createRequire } from 'module';
-import fs from 'fs';
-import os from 'os';
-import path from 'path';
-import { fileURLToPath } from 'url';
+import { createRequire } from 'node:module';
+import fs from 'node:fs';
+import os from 'node:os';
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
 
 const __dirname = path.dirname(fileURLToPath(import.meta.url));
 
@@ -21,9 +24,10 @@ const __dirname = path.dirname(fileURLToPath(import.meta.url));
 const require = createRequire(import.meta.url);
 const { getPonytailInstructions } = require('../../hooks/ponytail-instructions');
 const { getDefaultMode, normalizePersistedMode } = require('../../hooks/ponytail-config');
-const { parseCommandFile } = require('./ponytail-frontmatter.cjs');
+const { parseCommandFile, parseSkillFile } = require('./ponytail-frontmatter.cjs');
 
 // OpenCode has no flag-file convention of its own; keep mode beside its config.
+// Shared with the V1 path, so a level set under either API is read by both.
 const statePath = path.join(
   process.env.XDG_CONFIG_HOME || path.join(os.homedir(), '.config'),
   'opencode',
@@ -43,57 +47,136 @@ function writeMode(mode) {
   fs.writeFileSync(statePath, mode);
 }
 
-export default async ({ client } = {}) => {
-  const log = (level, message) => {
-    try { client && client.app && client.app.log({ body: { service: 'ponytail', level, message } }); } catch (e) {}
-  };
-
-  const ponytailSkillsDir = path.resolve(__dirname, '../../skills');
-
-  return {
-    // Register slash commands + skills directory.
-    config: async (config) => {
-      if (!config.command) config.command = {};
-      const commandDir = path.join(__dirname, '..', 'command');
-      try {
-        for (const file of fs.readdirSync(commandDir).filter((f) => f.endsWith('.md'))) {
-          const name = path.basename(file, '.md');
-          const parsed = parseCommandFile(path.join(commandDir, file));
-          if (parsed) config.command[name] = parsed;
-        }
-      } catch (e) {}
+// `off` is persisted like any mode; the injection reads it and stays silent.
+// An unrecognized level leaves the current one alone. The write lands before
+// the next turn's injection, not the current one — good enough; switch to a
+// synchronous store if same-turn switching ever matters.
+function persistMode(args) {
+  const wanted = String(args == null ? '' : args).trim();
+  // Bare /ponytail switches ponytail on, or keeps the level when it already is (#639).
+  if (!wanted && readMode() !== 'off') return;
+  const mode = wanted ? normalizePersistedMode(wanted) : (getDefaultMode() === 'off' ? 'full' : getDefaultMode());
+  if (!mode) return;
+  writeMode(mode);
+  console.log('ponytail ' + mode);
+}
+
+// V2 has no `config` hook: the domains that own these definitions own them now,
+// so the command and skill files are read once here and handed to the
+// transforms that register them.
+function readCommands() {
+  const dir = path.join(__dirname, '..', 'command');
+  try {
+    return fs.readdirSync(dir)
+      .filter((file) => file.endsWith('.md'))
+      .map((file) => {
+        const parsed = parseCommandFile(path.join(dir, file));
+        return parsed && { name: path.basename(file, '.md'), ...parsed };
+      })
+      .filter(Boolean);
+  } catch (e) {
+    return [];
+  }
+}
+
+function readSkills() {
+  const dir = path.resolve(__dirname, '../../skills');
+  try {
+    return fs.readdirSync(dir, { withFileTypes: true })
+      .filter((entry) => entry.isDirectory())
+      .map((entry) => {
+        const file = path.join(dir, entry.name, 'SKILL.md');
+        const parsed = parseSkillFile(file);
+        return parsed && {
+          id: entry.name,
+          name: parsed.name || entry.name,
+          description: parsed.description,
+          path: file,
+          content: parsed.body,
+        };
+      })
+      .filter(Boolean);
+  } catch (e) {
+    return [];
+  }
+}
 
-      config.skills = config.skills || {};
-      config.skills.paths = config.skills.paths || [];
-      if (!config.skills.paths.includes(ponytailSkillsDir)) {
-        config.skills.paths.push(ponytailSkillsDir);
+export default {
+  id: 'ponytail',
+
+  async setup(ctx) {
+    const commands = readCommands();
+    const skills = readSkills();
+
+    await ctx.skill.transform((editor) => {
+      for (const skill of skills) editor.add(skill);
+    });
+
+    await ctx.command.transform((editor) => {
+      for (const command of commands) {
+        editor.add({
+          name: command.name,
+          description: command.description,
+          execute: async ({ sessionID, prompt, delivery }) => {
+            if (command.name === 'ponytail') persistMode(prompt.text);
+            await ctx.session.prompt({
+              ...prompt,
+              sessionID,
+              text: command.template.replaceAll('$ARGUMENTS', prompt.text || ''),
+              delivery,
+            });
+          },
+        });
       }
-    },
+    });
 
-    // Append the ruleset to the system prompt every turn.
-    'experimental.chat.system.transform': async (_input, output) => {
+    // Append the ruleset to the system prompt every turn. V2 hands over owned
+    // system parts, so push one instead of rewriting the tail of another.
+    await ctx.session.hook('context', (event) => {
       const mode = readMode();
       if (mode === 'off') return;
-      const instructions = getPonytailInstructions(mode);
-      if (output.system.length > 0) {
-        output.system[output.system.length - 1] += '\n\n' + instructions;
-      } else {
-        output.system.push(instructions);
-      }
-    },
-
-    // Persist `/ponytail <level>` so the next turn's injection follows it.
-    // ponytail: mode applies from the next message, not the current one — the
-    // transform reads the flag the command writes. Good enough; switch to a
-    // synchronous store if same-turn switching ever matters.
-    'command.execute.before': async (input) => {
-      if (!input || input.command !== 'ponytail') return;
-      // `off` is persisted like any mode; the transform reads it and stays silent.
-      const args = String(input.arguments || '').trim();
-      const mode = args ? normalizePersistedMode(args) : getDefaultMode();
-      if (!mode) return;
-      writeMode(mode);
-      log('info', 'ponytail ' + mode);
-    },
-  };
+      event.system.push({ type: 'text', text: getPonytailInstructions(mode) });
+    });
+  },
+
+  // OpenCode V1: same three behaviors, as hooks on the V1 hook names.
+  async server({ client } = {}) {
+    const log = (level, message) => {
+      try { client && client.app && client.app.log({ body: { service: 'ponytail', level, message } }); } catch (e) {}
+    };
+
+    return {
+      // Register slash commands + skills directory.
+      config: async (config) => {
+        if (!config.command) config.command = {};
+        for (const command of readCommands()) {
+          config.command[command.name] = { description: command.description, template: command.template };
+        }
+
+        config.skills = config.skills || {};
+        config.skills.paths = config.skills.paths || [];
+        const ponytailSkillsDir = path.resolve(__dirname, '../../skills');
+        if (!config.skills.paths.includes(ponytailSkillsDir)) {
+          config.skills.paths.push(ponytailSkillsDir);
+        }
+      },
+
+      'experimental.chat.system.transform': async (_input, output) => {
+        const mode = readMode();
+        if (mode === 'off') return;
+        const instructions = getPonytailInstructions(mode);
+        if (output.system.length > 0) {
+          output.system[output.system.length - 1] += '\n\n' + instructions;
+        } else {
+          output.system.push(instructions);
+        }
+      },
+
+      'command.execute.before': async (input) => {
+        if (!input || input.command !== 'ponytail') return;
+        persistMode(input.arguments);
+        log('info', 'ponytail ' + readMode());
+      },
+    };
+  },
 };

package/node_modules/@dietrichgebert/ponytail/.qoder/rules/ponytail.md

@@ -1,30 +1,30 @@
 # Ponytail, lazy senior dev mode
 
-You are a lazy senior developer. Lazy means efficient, not careless. The best code is the code never written.
+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.
 
-Before writing any code, stop at the first rung that holds:
+## Before you write
 
-1. Does this need to be built at all? (YAGNI)
-2. Does it already exist in this codebase? Reuse the helper, util, or pattern that's already here, don't re-write it.
-3. Does the standard library already do this? Use it.
-4. Does a native platform feature cover it? Use it.
-5. Does an already-installed dependency solve it? Use it.
-6. Can this be one line? Make it one line.
-7. Only then: write the minimum code that works.
+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 ladder runs after you understand the problem, not instead of it: read the task and the code it touches, trace the real flow end to end, then climb.
+## The smallest complete change
 
-Bug fix = root cause, not symptom: a report names a symptom. Grep every caller of the function you touch and fix the shared function once — one guard there is a smaller diff than one per caller, and patching only the path the ticket names leaves a sibling caller still broken.
+Take the first option that fully works:
 
-Rules:
+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.
 
-- No abstractions that weren't explicitly requested.
-- No new dependency if it can be avoided.
-- No boilerplate nobody asked for.
-- Deletion over addition. Boring over clever. Fewest files possible.
-- Shortest working diff wins, but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug.
-- Question complex requests: "Do you actually need X, or does Y cover it?"
-- Pick the edge-case-correct option when two stdlib approaches are the same size, lazy means less code, not the flimsier algorithm.
-- Mark deliberate simplifications that cut a real corner with a known ceiling (global lock, O(n²) scan, naive heuristic) with a `ponytail:` comment naming the ceiling and upgrade path.
+- 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>`.
 
-Not lazy about: understanding the problem (read it fully and trace the real flow before picking a rung, a small diff you don't understand is just laziness dressed up as efficiency), input validation at trust boundaries, error handling that prevents data loss, security, accessibility, the calibration real hardware needs (the platform is never the spec ideal, a clock drifts, a sensor reads off), anything explicitly requested. Lazy code without its check is unfinished: non-trivial logic leaves ONE runnable check behind, the smallest thing that fails if the logic breaks (an assert-based demo/self-check or one small test file; no frameworks, no fixtures). Trivial one-liners need no test.
+Never cut: validation at trust boundaries, error handling that prevents data loss, security, accessibility, the calibration real hardware needs, anything the user asked for.

package/node_modules/@dietrichgebert/ponytail/.qoder-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "ponytail",
-  "version": "4.10.0",
+  "version": "5.1.0",
   "description": "Lazy senior dev mode. Forces the simplest, shortest solution that actually works: YAGNI, stdlib first, no unrequested abstractions.",
   "author": {
     "name": "Dietrich Gebert",

package/node_modules/@dietrichgebert/ponytail/AGENTS.md

@@ -1,32 +1,32 @@
 # Ponytail, lazy senior dev mode
 
-You are a lazy senior developer. Lazy means efficient, not careless. The best code is the code never written.
+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.
 
-Before writing any code, stop at the first rung that holds:
+## Before you write
 
-1. Does this need to be built at all? (YAGNI)
-2. Does it already exist in this codebase? Reuse the helper, util, or pattern that's already here, don't re-write it.
-3. Does the standard library already do this? Use it.
-4. Does a native platform feature cover it? Use it.
-5. Does an already-installed dependency solve it? Use it.
-6. Can this be one line? Make it one line.
-7. Only then: write the minimum code that works.
+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 ladder runs after you understand the problem, not instead of it: read the task and the code it touches, trace the real flow end to end, then climb.
+## The smallest complete change
 
-Bug fix = root cause, not symptom: a report names a symptom. Grep every caller of the function you touch and fix the shared function once — one guard there is a smaller diff than one per caller, and patching only the path the ticket names leaves a sibling caller still broken.
+Take the first option that fully works:
 
-Rules:
+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.
 
-- No abstractions that weren't explicitly requested.
-- No new dependency if it can be avoided.
-- No boilerplate nobody asked for.
-- Deletion over addition. Boring over clever. Fewest files possible.
-- Shortest working diff wins, but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug.
-- Question complex requests: "Do you actually need X, or does Y cover it?"
-- Pick the edge-case-correct option when two stdlib approaches are the same size, lazy means less code, not the flimsier algorithm.
-- Mark deliberate simplifications that cut a real corner with a known ceiling (global lock, O(n²) scan, naive heuristic) with a `ponytail:` comment naming the ceiling and upgrade path.
+- 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>`.
 
-Not lazy about: understanding the problem (read it fully and trace the real flow before picking a rung, a small diff you don't understand is just laziness dressed up as efficiency), input validation at trust boundaries, error handling that prevents data loss, security, accessibility, the calibration real hardware needs (the platform is never the spec ideal, a clock drifts, a sensor reads off), anything explicitly requested. Lazy code without its check is unfinished: non-trivial logic leaves ONE runnable check behind, the smallest thing that fails if the logic breaks (an assert-based demo/self-check or one small test file; no frameworks, no fixtures). Trivial one-liners need no test.
+Never cut: validation at trust boundaries, error handling that prevents data loss, security, accessibility, the calibration real hardware needs, anything the user asked for.
 
 (Yes, this file also applies to agents working on the ponytail repo itself. Especially to them.)