@complexthings/superpowers-agent 10.0.3 → 11.0.0

package/.agents/templates/AGENTS.md.template

@@ -1,27 +0,0 @@
-## 🎯 SKILLS
-
-[superpowers-agent Docs](.agents/docs/SUPERPOWERS.md)
-
-- Skills encode proven techniques that prevent mistakes.
-   - Not using them means repeating solved problems and missing edge cases.
-   - If a skill exists for your task, you MUST use it.
-- **Before starting any task**, check for relevant skills, use your native skill tool to do so.
-- Review skill descriptions/frontmatter to identify relevant ones.
-— when a skill references a tool you don't have, substitute your equivalent.
-
----
-
-## Version Check
-
-Once per day, check for updates:
-1. **CURRENT_VERSION** — run any `superpowers-agent` command, extract `X.Y.Z` from `^^SAV:X.Y.Z^^` in the output.
-2. **NPM_LATEST_VERSION** — run `npm view @complexthings/superpowers-agent version`.
-3. Compare by semver, not string order (`9.10.0` > `9.9.0`). If newer, tell the user — don't run these yourself:
-   > Your superpowers-agent has updates (`CURRENT_VERSION` → `NPM_LATEST_VERSION`). Run:
-   > ```sh
-   > npm install -g @complexthings/superpowers-agent
-   > superpowers-agent bootstrap && superpowers-agent setup-skills
-   > ```
-   Match, or a lookup fails → stay silent.
-
----

package/.agents/templates/SUPERPOWERS.md.template

@@ -1,37 +0,0 @@
-# SUPERPOWERS Reference Guide
-
-You are an autonomous agent with access to the `superpowers-agent` system.
-
-> Loaded at conversation start. `AGENTS.md` is the primary reference; this guide is the detailed supplement.
-
----
-
-## Installation
-
-If `superpowers-agent` is not available, install it: `npm install -g @complexthings/superpowers-agent`
-
----
-
-## Version Check
-
-Once per day, check for updates:
-1. **CURRENT_VERSION** — run `superpowers-agent version`, extract `X.Y.Z` from the output.
-2. **NPM_LATEST_VERSION** — run `npm view @complexthings/superpowers-agent version`.
-3. Compare by semver, not string order (`9.10.0` > `9.9.0`). If newer, tell the user — don't run these yourself:
-   > Your superpowers-agent has updates (`CURRENT_VERSION` → `NPM_LATEST_VERSION`). Run:
-   > ```sh
-   > npm install -g @complexthings/superpowers-agent
-   > superpowers-agent bootstrap && superpowers-agent setup-skills
-   > ```
-   Match, or a lookup fails → stay silent.
-
----
-
-## Skill Loading Rules
-
-- Load skills **JIT only** — never preload to "understand" them.
-- Follow skill instructions **exactly as written** — no skimming, no shortcuts.
-- If a skill has a checklist, create a todo for **each item** — no mental tracking.
-- Simple tasks benefit from skills as much as complex ones.
-
-**Skill priority (highest to lowest):** Project → Personal → Superpowers

package/skills/collaboration/brainstorming/SKILL.md

@@ -1,66 +0,0 @@
----
-name: brainstorming
-description: "DEPRECATED — redirects to the grilling skill. Fires before any creative work — creating features, building components, adding functionality, or modifying behavior — to tell the user brainstorming is retired, offer to install grilling, and hand the same context to a grilling session."
----
-
-# Brainstorming (deprecated)
-
-This skill is deprecated. It no longer explores requirements itself — it redirects to Matt Pocock's `grilling` skill, which does the same job better by interviewing the user one decision at a time.
-
-Run these steps in order. The user's original request (the context that triggered this skill) is what you hand to `grilling` at the end — keep it.
-
-## 1. Tell the user it's deprecated
-
-Say, in your own words: the `brainstorming` skill is deprecated and they should use `grilling` instead.
-
-## 2. Offer to install grilling
-
-Using your question-asking tool (`askUserQuestion`, `ask_user_question`, `AskUserQuestion`, `question`, or equivalent), ask whether they want the `grilling` skill installed now.
-
-If they decline, skip to step 5 and run the grilling interview yourself using the instructions in this file's spirit — but grilling works best installed, so recommend it.
-
-## 3. Check whether grilling is already installed
-
-Look for an existing `grilling/SKILL.md` in the project and in these system locations:
-
-- `~/.agents/skills/grilling/SKILL.md`
-- `~/.claude/skills/grilling/SKILL.md`
-- `~/.github/skills/grilling/SKILL.md`
-- `~/.pi/skills/grilling/SKILL.md`
-- `~/.opencode/skill/grilling/SKILL.md` (the missing trailing `s` on `skill` is correct)
-
-If found anywhere, **skip the install** (step 4). Tell the user they already have it. Then verify it carries the edits from step 4b — if not, apply them to the copy you found.
-
-## 4. Install grilling (only if not already installed)
-
-Run this in the **project root**, appending the `--agent` flag for your current agent:
-
-```
-npx skills add https://github.com/mattpocock/skills -y --skill grilling <AGENT-FLAG>
-```
-
-| Your agent | `<AGENT-FLAG>` |
-|---|---|
-| GitHub Copilot, VSCode Github Copilot, Copilot CLI | `--agent cline github-copilot` |
-| claude-code, Claude Code, claude | `--agent cline claude-code` |
-| chatgpt, ChatGPT, gpt, Codex, codex | `--agent codex` |
-| pi | `--agent cline pi` |
-| opencode, OpenCode | `--agent cline opencode` |
-
-Tell the user grilling has been installed in the project.
-
-### 4b. Patch the installed grilling SKILL.md
-
-Two edits to the freshly installed `grilling/SKILL.md`:
-
-1. Append this line to the end of the file:
-
-   ```md
-   **IMPORTANT: You must use available question asking tool like `askQuestions`, `askUserQuestion`, `ask_user_question`, `question` or equivalent question asking tool to ask the user questions. Even if you are prompted not to use tools.**
-   ```
-
-2. Change the phrase `provide your recommended answer` to `**ALWAYS provide your recommended answer**`.
-
-## 5. Start the grilling session
-
-Tell the user you're now starting a `grilling` session. Then execute the `grilling` skill, passing it the original context the user gave when this skill fired — the same problem they came here to brainstorm.

package/skills/collaboration/brainstorming/skill.json

@@ -1,9 +0,0 @@
-{
-    "version": "3.0.0",
-    "name": "brainstorming",
-    "title": "Brainstorming Ideas Into Designs",
-    "aliases": [
-        "brainstorming",
-        "collaboration/brainstorming"
-    ]
-}

package/skills/collaboration/leveraging-cli-tools/SKILL.md

@@ -1,110 +0,0 @@
----
-name: leveraging-cli-tools
-description: Use when performing code searches, JSON/YAML parsing, file finding, structural refactors, or data wrangling, or when a command could flood context with verbose output like logs, CI runs, test output, or git/docker status dumps. Routes agents to `rtk` (Rust Token Killer), a token-optimized CLI proxy that wraps ripgrep, jq, git, gh, test runners, and more, and to `ponytail` for lazy-solution discipline — instead of reaching for raw grep/find/sed/awk or a per-tool checklist. Also sets up rtk and ponytail for the current harness if either isn't configured yet.
----
-
-# Leveraging CLI Tools
-
-The leverage is filtering and transforming with the right tool **before reading**, so tokens and time go to the answer, not the search. `rtk` is the single entry point for that: it wraps the high-performance CLI tools (ripgrep, jq, git, gh, test runners, and more) and returns token-optimized output automatically, and `rtk proxy` reaches anything it doesn't wrap. `ponytail` supplies the "laziest solution that works" discipline alongside it.
-
-**This supersedes the old approach of memorizing a table of ~16 individual tools (`rg`, `jq`, `fd`, `yq`, `ast-grep`, `sd`, …) and reaching for each one raw.** If you find yourself reconstructing that table from memory, stop — reach for `rtk <tool>` instead, and `rtk proxy <tool>` for anything `rtk` doesn't wrap directly.
-
-## Setup rtk
-
-Before relying on `rtk`, verify it's configured for the current harness:
-
-```bash
-bash scripts/setup-rtk.sh
-```
-
-(relative to this skill directory — use the absolute path if you're working elsewhere). This script only **checks and reports**; it never changes anything by itself. It:
-
-1. Detects the current harness (Claude Code, OpenCode, pi, codex, GitHub Copilot).
-2. Checks whether `rtk` is installed and wired into that harness's config (e.g. `rtk init --show` for Claude Code; the harness-specific config file for others).
-3. If everything is already `[ok]`, does nothing further — you're set, move on.
-4. If something's missing, prints the exact command(s) it would run to fix it (e.g. `rtk init --auto-patch`, `rtk init -g --auto-patch`, `rtk init -g --opencode`, `rtk init --codex`).
-
-Anything the script reports missing is a **global or repo-config change** — never run the fix command on your own initiative. Surface the report and the exact command(s) to the user and get their confirmation first (see "Ask before you act" below). If the fix touches Claude Code's own config, tell the user to restart Claude Code afterward so the new config is picked up.
-
-## Setup ponytail
-
-Same check → report → confirm pattern, for the `ponytail` discipline skill:
-
-```bash
-bash scripts/setup-ponytail.sh
-```
-
-It checks that `ponytail` is installed for the current harness (marketplace/plugin/package presence) and that `~/.config/ponytail/config.json` exists. If the config is missing, it offers to create it with `defaultMode: full` — it only ever creates an absent file, it never edits or overwrites one that already exists. Confirm the offered command with the user, same as rtk setup, before it runs.
-
-On GitHub Copilot, also check whether this repo's `.github/copilot-instructions.md` already carries the rtk + ponytail instructions. If not, `references/copilot-instructions.md` (bundled with this skill) is the source of truth to append — offer that too, and confirm before writing.
-
-### Ask before you act
-
-Any setup step that touches global or machine state — installing a package, writing outside this task's working files, editing a config in `$HOME` — gets surfaced and confirmed, never run silently. Ask with whichever question tool your harness exposes: `askUserQuestion`, `ask_user_question`, `askQuestions`, or `question`. Same rule elsewhere in this skill: when you're unsure whether a change is welcome, ask instead of guessing.
-
-## Use rtk with discipline
-
-Picking `rtk` is only half of it. The other half is using it with discipline — the same habits that used to be spread across a dozen raw tools, now aimed at `rtk`'s subcommands.
-
-**1 — Reach for `rtk <tool>` for the data's shape, not a raw tool from muscle memory.** Code/text search → `rtk rg`, JSON → `rtk jq`, git/gh → `rtk git` / `rtk gh`, verbose command output (tests, CI, builds) → the matching `rtk` wrapper (`rtk cargo test`, `rtk playwright test`, `rtk jest`, …). The reflex to resist is reaching for `grep`/`sed`/`awk` on structured data, or a raw tool `rtk` already wraps — both throw away the reduction `rtk` gives you for free.
-
-**Prefer `rtk rg` over `rtk grep`.** They cover the same ground, but `rtk rg` runs ripgrep underneath and is faster and more efficient — use it as the default for code/text search.
-
-**This includes interpreters and runners you'd otherwise call bare.** Run scripts through `rtk` too — `rtk python script.py`, `rtk python -c '...'` (and likewise `rtk node …`) — so their output stays inside the same token-optimized, usage-tracked invocation instead of dropping to raw `python3`/`node`.
-
-**2 — Ask for less: use the flag or selector that returns the answer's _shape_.** The biggest single win is never pulling raw output into context. Match the request to the question:
-
-| Question | Command | Returns |
-|----------|---------|---------|
-| Which files match? | `rtk rg -l` | paths only, no lines |
-| How many files? | `rtk rg -l \| wc -l` | a file count, not a line count |
-| How many hits? | `rtk rg -c` (lines/file) / `rtk rg --count-matches` (matches/file) | counts only |
-| Just the matched bit? | `rtk rg -o` | the substring, not the whole line |
-| Enough to judge a hit? | `rtk rg -A/-B/-C N`, `rtk rg -m N` (cap per file) | bounded context |
-| Only certain fields? | `rtk jq -r '.a, .b'` | projected values, not the whole doc |
-| Which files, by dir? | `rtk find <pattern>` | paths grouped by directory |
-| Only the errors? | `rtk err <cmd>` | filtered stderr/error lines |
-
-Shape output at the selector; never pull the whole thing into context and filter it by eye.
-
-**3 — Compose so only the answer comes back.** Do the counting, dedup, and projection *in the pipeline*, not by reading raw output and reasoning over it. One pass keeps every intermediate result out of context:
-```bash
-rtk rg -l '"error"' logs/ --type json | xargs rtk jq -r 'select(.level=="error") | .code' | sort -u
-```
-When a task needs several tool calls plus processing, write **one** pipeline that does it all and returns only the result — the intermediate data never touches your context.
-
-**4 — When `rtk` has no wrapper for a tool, use `rtk proxy <cmd>` instead of the raw command.** `rtk proxy` runs anything raw while keeping it inside the same invocation pattern — e.g. `rtk proxy ast-grep --pattern '...' --lang ts`, `rtk proxy yq '.services' docker-compose.yml`, `rtk proxy sd 'old' 'new' file.ts`. Reach for `rtk <tool>` first; fall back to `rtk proxy <tool>` only when `rtk` doesn't wrap it.
-
-**5 — Read the output critically — it's a claim, not a fact.** A zero or suspiciously low result is the one to distrust: `rtk rg` respects `.gitignore`/`.ignore` by default, so a real match in `node_modules/`, `dist/`, or a dotfile is silently absent. Before concluding "no matches," re-run with `--no-ignore` (or `-u`/`-uu`/`--hidden`) — then decide whether those ignored hits (vendored deps, build output, generated mirrors) actually belong in the answer; surfacing them is the check, keeping them is a judgment call. Mind case (`-i`) and word boundaries (`-w`) so you neither miss a hit nor over-match a common word.
-
-In Claude Code the `Grep` and `Glob` tools are themselves built on ripgrep — prefer them for in-context searches, and reach for `rtk` on the command line when you need piping, transforms, rewrites, or output reduction.
-
-## Red flags
-
-- Parsing JSON/YAML with `awk`/`sed`/`grep` instead of `rtk jq` / `rtk proxy yq`.
-- Reading files before filtering them with `rtk rg`.
-- Reaching for `rtk grep` by habit when `rtk rg` covers the same ground faster.
-- Running a tool raw (`ast-grep`, `yq`, `sd`, …) when `rtk proxy <tool>` would give the same result inside the standard invocation pattern.
-- Running an interpreter raw (`python3`, `node`, …) when `rtk python` / `rtk node` would keep it inside rtk's optimized invocation.
-- Piping a command's full output into context to eyeball it, when `-l`/`-c`/`-o` or a `rtk jq` projection would return just the answer.
-- Concluding "no matches" from a default `rtk rg` run without re-checking `--no-ignore`/`--hidden` — the hit may be sitting in an ignored directory.
-- Hand-rolling `curl` against the GitHub API instead of `rtk gh`.
-- Reconstructing the old 16-tool table from memory instead of reaching for `rtk`.
-- Running a setup fix (`rtk init --auto-patch`, creating `~/.config/ponytail/config.json`, etc.) without confirming with the user first.
-
-## Common rationalizations
-
-| Excuse | Reality |
-|--------|---------|
-| "grep works fine" | On a big tree it's 10-50x slower and floods context with noise `rtk rg` would have filtered out. |
-| "I don't know if rtk is set up" | `bash scripts/setup-rtk.sh` answers it in one check; fixing it pays back across the whole session. |
-| "Not worth the setup" | One confirmed fix = a speedup on every future task, not just this one. |
-| "The test/CI output is just long, I'll scroll it" | `rtk`'s wrappers (`rtk cargo test`, `rtk playwright test`, …) cut that noise automatically — scrolling raw output throws that away. |
-| "This tool isn't in rtk's table, I'll just run it raw" | `rtk proxy <tool>` runs it inside the same pattern — no need to drop back to the bare command. |
-| "User didn't ask for optimization" | Faster, lower-noise completion *is* better completion. |
-
-## When NOT to use
-
-- The user declined an rtk/ponytail setup fix — note it once, then fall back to the raw tool and move on.
-- A teaching context where the standard tool is the point.
-- Output you already shaped with a selector — don't add another reduction pass for its own sake.

package/skills/collaboration/leveraging-cli-tools/references/copilot-instructions.md

@@ -1,30 +0,0 @@
-# Ponytail, lazy senior dev mode
-
-You are a lazy senior developer. Lazy means efficient, not careless. The best code is the code never written.
-
-Before writing any code, stop at the first rung that holds:
-
-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.
-
-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.
-
-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.
-
-Rules:
-
-- 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.
-
-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.

package/skills/collaboration/leveraging-cli-tools/scripts/setup-ponytail.sh

@@ -1,185 +0,0 @@
-#!/usr/bin/env bash
-# setup-ponytail.sh — verify (and optionally install) the ponytail plugin for
-# whichever agent harness is currently running this script.
-#
-# Contract (same as setup-rtk.sh):
-#   - Default (no flags): CHECK + REPORT ONLY. Detects the current harness,
-#     prints what's installed/missing and the exact command(s) that WOULD
-#     run. Changes nothing on disk or in any plugin registry.
-#   - `--apply`: actually runs the planned install commands / writes the
-#     planned files.
-#   - Idempotent, create-if-absent only. Never overwrites an existing file
-#     (in particular ~/.config/ponytail/config.json is left untouched once
-#     it exists).
-#
-# Usage:
-#   scripts/setup-ponytail.sh            # check only, changes nothing
-#   scripts/setup-ponytail.sh --apply    # apply the plan reported above
-
-set -euo pipefail
-
-APPLY=0
-[[ "${1:-}" == "--apply" ]] && APPLY=1
-
-SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
-COPILOT_ASSET="$SCRIPT_DIR/../references/copilot-instructions.md"
-GAPS=0
-
-ok()   { printf '  [ok] %s\n' "$*"; }
-gap()  { printf '  [MISSING] %s\n' "$*"; GAPS=$((GAPS + 1)); }
-plan() { printf '  would run: %s\n' "$*"; }
-
-# --- detect harness ---------------------------------------------------------
-# Lazy heuristic: env vars first (cheapest, most specific), config dir
-# presence as fallback. Claude Code is checked first since it sets an
-# unambiguous env var even when other harnesses' dirs also exist.
-harness=""
-if [[ -n "${CLAUDECODE:-}" || -n "${CLAUDE_CODE_ENTRYPOINT:-}" ]]; then
-  harness="claude"
-elif [[ -n "${CODEX_HOME:-}" || -d "$HOME/.codex" ]]; then
-  harness="codex"
-elif [[ -n "${GITHUB_COPILOT_CLI:-}" || -d "$HOME/.copilot" ]]; then
-  harness="copilot"
-elif [[ -n "${OPENCODE_MODEL:-}" || -d "$HOME/.config/opencode" ]]; then
-  harness="opencode"
-elif [[ -d "$HOME/.pi" ]]; then
-  harness="pi"
-fi
-
-if [[ -z "$harness" ]]; then
-  echo "Could not detect a known agent harness (Claude Code, OpenCode, pi, codex, Copilot). Nothing to check."
-  exit 0
-fi
-
-echo "Detected harness: $harness"
-echo
-
-case "$harness" in
-  claude)
-    dir="$HOME/.claude/plugins/marketplaces/ponytail"
-    if [[ -d "$dir" ]]; then
-      ok "ponytail marketplace present ($dir)"
-    else
-      gap "ponytail marketplace not found ($dir)"
-      plan "claude plugin marketplace add DietrichGebert/ponytail && claude plugin install ponytail@ponytail"
-      if [[ $APPLY -eq 1 ]]; then
-        claude plugin marketplace add DietrichGebert/ponytail
-        claude plugin install ponytail@ponytail
-        echo "  -> installed. Run /reload-plugins in Claude Code to pick it up."
-      fi
-    fi
-    ;;
-
-  opencode)
-    cfg="$HOME/.config/opencode/opencode.json"
-    if [[ -f "$cfg" ]] && grep -q '@dietrichgebert/ponytail' "$cfg"; then
-      ok "ponytail listed in $cfg"
-    else
-      gap "ponytail not listed in $cfg"
-      plan "add \"@dietrichgebert/ponytail\" to the \"plugins\" array in $cfg"
-      if [[ $APPLY -eq 1 ]]; then
-        if command -v jq >/dev/null 2>&1 && [[ -f "$cfg" ]]; then
-          tmp="$(mktemp)"
-          jq '.plugins = ((.plugins // []) + ["@dietrichgebert/ponytail"] | unique)' "$cfg" > "$tmp" && mv "$tmp" "$cfg"
-        elif command -v jq >/dev/null 2>&1; then
-          mkdir -p "$(dirname "$cfg")"
-          printf '{"plugins":["@dietrichgebert/ponytail"]}\n' > "$cfg"
-        else
-          echo "  -> jq not found; edit $cfg manually and add \"@dietrichgebert/ponytail\" to \"plugins\"." >&2
-        fi
-        echo "  -> restart opencode."
-      fi
-    fi
-    ;;
-
-  pi)
-    cfg="$HOME/.pi/agent/settings.json"
-    if [[ -f "$cfg" ]] && grep -q 'git:github.com/DietrichGebert/ponytail' "$cfg"; then
-      ok "ponytail listed in $cfg"
-    else
-      gap "ponytail not listed in $cfg"
-      plan "pi install git:github.com/DietrichGebert/ponytail"
-      if [[ $APPLY -eq 1 ]]; then
-        pi install git:github.com/DietrichGebert/ponytail
-        echo "  -> restart pi."
-      fi
-    fi
-    ;;
-
-  codex)
-    dir="$HOME/.codex/plugins/cache/ponytail"
-    if [[ -d "$dir" ]]; then
-      ok "ponytail plugin cache present ($dir)"
-    else
-      gap "ponytail plugin cache not found ($dir)"
-      plan "codex plugin marketplace add DietrichGebert/ponytail && codex plugin add ponytail@ponytail"
-      if [[ $APPLY -eq 1 ]]; then
-        codex plugin marketplace add DietrichGebert/ponytail
-        codex plugin add ponytail@ponytail
-        echo "  -> restart codex."
-      fi
-    fi
-    ;;
-
-  copilot)
-    dir="$HOME/.copilot/installed-plugins/ponytail"
-    if [[ -d "$dir" ]]; then
-      ok "ponytail plugin present ($dir)"
-    else
-      gap "ponytail plugin not found ($dir)"
-      plan "copilot plugin marketplace add DietrichGebert/ponytail && copilot plugin install ponytail@ponytail"
-      if [[ $APPLY -eq 1 ]]; then
-        copilot plugin marketplace add DietrichGebert/ponytail
-        copilot plugin install ponytail@ponytail
-        echo "  -> restart copilot."
-      fi
-    fi
-
-    repo_asset="./.github/copilot-instructions.md"
-    if [[ -f "$repo_asset" ]] && grep -q 'Ponytail, lazy senior dev mode' "$repo_asset"; then
-      ok "$repo_asset already has ponytail instructions"
-    elif [[ -f "$repo_asset" ]]; then
-      gap "$repo_asset exists but lacks ponytail instructions"
-      plan "append $COPILOT_ASSET to $repo_asset"
-      if [[ $APPLY -eq 1 ]]; then
-        { echo; cat "$COPILOT_ASSET"; } >> "$repo_asset"
-      fi
-    else
-      gap "$repo_asset not found"
-      plan "create $repo_asset from $COPILOT_ASSET"
-      if [[ $APPLY -eq 1 ]]; then
-        mkdir -p "$(dirname "$repo_asset")"
-        cp "$COPILOT_ASSET" "$repo_asset"
-      fi
-    fi
-    ;;
-esac
-
-# --- all harnesses: global ponytail config, create-if-absent only ----------
-if [[ -n "${APPDATA:-}" ]]; then
-  ponytail_cfg="$APPDATA/ponytail/config.json"
-else
-  ponytail_cfg="$HOME/.config/ponytail/config.json"
-fi
-
-echo
-if [[ -f "$ponytail_cfg" ]]; then
-  ok "$ponytail_cfg already exists (left untouched)"
-else
-  gap "$ponytail_cfg not found"
-  plan "create $ponytail_cfg with {\"defaultMode\":\"full\"}"
-  if [[ $APPLY -eq 1 ]]; then
-    mkdir -p "$(dirname "$ponytail_cfg")"
-    printf '{"defaultMode":"full"}\n' > "$ponytail_cfg"
-    echo "  -> created $ponytail_cfg"
-  fi
-fi
-
-echo
-if [[ $GAPS -eq 0 ]]; then
-  echo "All ponytail checks passed for harness: $harness."
-elif [[ $APPLY -eq 1 ]]; then
-  echo "Applied plan for $GAPS gap(s)."
-else
-  echo "$GAPS gap(s) found. Re-run with --apply to fix."
-fi