leos-agent 7.0.0 → 10.2.0

package/skills/setup/SKILL.md

@@ -1,199 +0,0 @@
----
-name: setup
-description: >
-  Turn on the opt-in wiring a plugin install cannot turn on for itself.
-  Every harness installs Leo through its own plugin system, and none of them
-  offers an install-time hook, so anything that writes into a file the user
-  already owns is asked for once, here, and recorded in machine-local state.
-  Idempotent, but not generally reversible: running it twice changes nothing
-  the second time, while removal is harness-specific and manual. Use when Leo
-  explicitly requests opt-in setup after installation. Do not use for
-  diagnosis or unprompted writes outside the repository.
-when_to_use: >
-  Leo asks to enable Hermes memory projection, or invokes setup by name after
-  installing on a new machine. NOT for diagnosing whether the plugin loaded
-  (that is leo:doctor, which reports and never changes anything), and NOT
-  something to run unprompted — it writes to a file outside the repository.
----
-
-# setup
-
-Leo's Agent installs through each harness's own plugin system. None of those
-systems runs arbitrary code at install time — Hermes' `register()` fires at
-session start, not on `hermes plugins install` — so there is no moment during
-installation at which consent for a write outside the plugin could be implied.
-Anything with that blast radius lives behind this command instead.
-
-## Run it
-
-```sh
-python3 "${CLAUDE_PLUGIN_ROOT}/scripts/setup.py"
-```
-
-`${CLAUDE_PLUGIN_ROOT}` is the Claude Code spelling of the plugin root; Codex
-exports `$PLUGIN_ROOT`, Cursor `$CURSOR_PLUGIN_ROOT`, and on Hermes and
-OpenCode no such variable exists — read the absolute payload path from the
-injected policy's `state.py` or `memory.py` command, which was substituted
-before injection.
-
-With no arguments it reports what is on, what is available, and what each
-feature would actually do right now. It changes nothing. Add `--json` for the
-same facts as data.
-
-```sh
-python3 "${CLAUDE_PLUGIN_ROOT}/scripts/setup.py" enable hermes-memory
-python3 "${CLAUDE_PLUGIN_ROOT}/scripts/setup.py" disable hermes-memory
-```
-
-Enabling something already on prints that and exits 0 — re-running is always
-safe, and never a reason to check first.
-
-## `apply`: bootstrap this harness's MCP servers
-
-```sh
-python3 "${CLAUDE_PLUGIN_ROOT}/scripts/setup.py" apply
-python3 "${CLAUDE_PLUGIN_ROOT}/scripts/setup.py" apply --dry-run
-```
-
-Idempotent, and read-modify-write: `config/models.json`'s `mcp.core` list names
-the servers each harness gets, `apply` detects which harness is actually
-running this script (the same detection `doctor.py` already does —
-never a second, divergent copy of it) and writes only that harness's own
-config, never another one's, even when another harness's config file also
-exists on the machine. `--dry-run` prints the exact commands or diffs and
-touches nothing. An unsupported or undetectable harness refuses outright —
-nothing is touched, and the exit code is non-zero.
-
-"Already installed" is always answered by re-reading the harness's own
-config, never by a flag Leo remembers — so removing a server by hand and
-re-running `apply` sees the removal, and running `apply` twice in a row
-writes nothing the second time either way. OpenCode edits are lossless JSONC
-additions: comments, trailing commas, indentation, symlinks and modes survive;
-existing `opencode.jsonc` and `opencode.json` together make setup refuse rather
-than choose. `OPENCODE_CONFIG` wins, otherwise the sole existing global file
-wins, otherwise a new `.jsonc` is used.
-
-`apply` is idempotent, **not generally reversible**. It never removes an MCP
-server or tool gate. Remove an automatic CLI registration with the command for
-the harness that owns it:
-
-```sh
-claude mcp remove <name> --scope user
-codex mcp remove <name>
-hermes mcp remove <name>
-```
-
-Cursor has no setup-owned removal command: remove the `mcpServers.<name>` key
-from `~/.cursor/mcp.json`. OpenCode likewise has no MCP removal command: remove
-the `mcp.<name>` key from the resolved `opencode.jsonc` or `opencode.json`, and
-remove any unwanted setup-owned tool gates there. A `.leo-backup` is one
-pre-first-write snapshot, not a conflict-aware restore, transaction log, or
-promise that a later user edit can be undone.
-
-`apply` also reports (never flips) two Codex toggles: its `computer_use`
-feature flag and `web_search` mode (offering, never forcing, the upgrade to
-`"live"`), plus one manual Claude in Chrome toggle, which has no config key.
-
-Vendor connectors (Slack, Sentry, Linear, ...) live in the same `mcp` config
-under `connectors` — `apply` never installs those; that is the next section.
-Core executable packages are exact reviewed pins. Their maintainer update
-procedure is recorded in `config/MCP_PINS.md`; never substitute `@latest`, a
-range, or an unqualified package name during setup.
-
-## Vendor connectors: `connectors` and `connect`
-
-`config/models.json`'s `mcp.connectors` names eleven vendor MCP servers
-(Slack, Sentry, Honeycomb, Snowflake, LaunchDarkly, Linear, Jira +
-Confluence, Gmail, Google Drive, Granola, Vercel) — every one OAuth, every
-one remote HTTP. Unlike `apply`'s core servers, these are never installed
-without a name chosen explicitly. After `apply`, run:
-
-```sh
-python3 "${CLAUDE_PLUGIN_ROOT}/scripts/setup.py" connectors --json
-```
-
-Read-only, and it exits 0 even on a harness `apply` would refuse — it just
-has nothing installable to report. Each entry's `installed` is answered by
-re-reading the harness's own config the same way `apply` does — matching the
-endpoint URL first, a name second, because a claude.ai connector such as
-Gmail or Vercel is registered against the account and never written to
-`~/.claude.json` at all. Never offer one already `installed: true`.
-
-For every connector still `installed: false`, see the *Structured question
-to the user* row of your mapping:
-
-- **A question tool** (Claude Code, OpenCode): present the not-installed
-  connectors as a multi-select, one entry per `label`, and install only what
-  is chosen:
-
-  ```sh
-  python3 "${CLAUDE_PLUGIN_ROOT}/scripts/setup.py" connect <key> [<key> ...]
-  ```
-
-- **No question tool** (Codex, Cursor, Hermes): list them in plain text —
-  `key`, `label`, and `authNote` — and **install nothing** unless the user
-  names one or more by key in reply. The same default as everywhere else in
-  this skill: asking is never itself consent.
-
-`snowflake` always needs `needsUrl: true` handled first — its endpoint
-embeds org, account, database and schema, and cannot be guessed from
-anything on the machine. Ask for the account-specific URL before offering it
-in the multi-select (or before accepting it in a plain-text reply), then:
-
-```sh
-python3 "${CLAUDE_PLUGIN_ROOT}/scripts/setup.py" connect snowflake --url <URL>
-```
-
-`connect` refuses outright, writing nothing, on an unsupported harness, an
-unknown registry state, or on `snowflake` with no URL on hand. Slack, Gmail,
-Google Drive, and account-specific providers are manual-only: report their
-prerequisites and never attempt dynamic registration. On Hermes, providers
-that support dynamic registration use `hermes mcp add <key> --url <url> --auth oauth`
-followed by `hermes mcp login <key>`; providers without it remain manual.
-Every successful install reports
-`needs-auth`: setup registers the endpoint and stops there — it never
-handles a credential. Report back to the user, by `label`, which connectors
-now need them to complete a browser OAuth flow on first use.
-
-## Features
-
-### `hermes-memory`
-
-Projects the **global** memory facts into `$HERMES_HOME/SOUL.md` (default
-`~/.hermes/SOUL.md`), the same marker-spliced block the other four harnesses
-receive in their own per-user file.
-
-It is the one projection target that is opt-in, because it is the one whose
-file is not simply a place for user instructions: `SOUL.md` is the agent's
-identity prompt and the opening section of every Hermes system prompt on that
-machine. The safeguards are the same as everywhere else, plus one:
-
-- Only global-scope facts. Repo facts never leave the store — every per-user
-  file loads in every repository, so projecting them would leak one project's
-  memories into unrelated sessions.
-- Everything outside Leo's `BEGIN`/`END` markers is preserved byte for byte,
-  and one `SOUL.md.leo-backup` is taken before the first ever write.
-- Unbalanced or duplicated markers abort the write and report an error rather
-  than guessing which block is Leo's.
-- **The file is never created.** Hermes falls back to a built-in persona when
-  `SOUL.md` is absent, so creating it would silently replace the user's agent
-  identity. Enabled with no `SOUL.md` present reports `skipped:no-soul` and
-  does nothing. Write the file yourself and the next session splices into it.
-
-`LEOS_AGENT_NO_PROJECT=1` still disables all projection, including this one.
-
-Hermes' `memories/MEMORY.md` and `memories/USER.md` are deliberately **not**
-targets: the agent owns those through its own memory tool and would overwrite
-Leo's markers.
-
-## What setup never does
-
-It does not install, update, or repair the plugin, handle credentials, or
-diagnose — if the question is "did the policy load" or "why can't I invoke
-this skill", that is leo:doctor, which reads and never writes. Its write
-boundary is explicit consent state, the current harness's automatic core MCP
-registration/config additions, and an explicitly named automatic connector;
-manual providers only print their prerequisites. Hermes projection is applied
-at the next session start through `memory.py`; removing Leo's balanced marker
-block is the only safely reversible projection action. Config additions and
-their one-time backups are not a general rollback mechanism.

package/skills/setup/agents/openai.yaml

@@ -1,5 +0,0 @@
-interface:
-  display_name: "Set Up Leo"
-  short_description: "Configure Leo's opt-in wiring and MCP services"
-policy:
-  allow_implicit_invocation: false

package/skills/test-first/SKILL.md

@@ -1,92 +0,0 @@
----
-name: test-first
-description: >
-  Failing-test-first as the default for runtime-behavior changes. Before
-  writing the change, write a test that fails for the intended reason, watch
-  it fail, then make it pass with the change — the red-to-green transition is
-  the evidence a real guard exists, not a rubber stamp added after the fact.
-  Applies to implementer and executor during implementation; reviewer checks
-  the resulting coverage as a rubric line. Use when an implementation changes
-  runtime behavior. Do not use for throwaway spikes, docs/config/dependency
-  work, or pure UI copy and styling.
-when_to_use: >
-  Any implementation task that changes runtime behavior — fix, feature,
-  refactor with observable effect — routed through implementer or executor.
-  NOT for spikes/throwaway exploration that gets deleted, NOT for
-  docs/comments/config/dependency-bump edits, and NOT for pure UI copy or
-  styling tweaks — see Exemptions below for the full closed list.
----
-
-# test-first
-
-**Core rule**: before writing the change, write a failing test — and watch
-it fail — for the reason the change is supposed to fix. Then make it pass.
-A test that passes on its first run proves nothing about what it guards; it
-could be checking the wrong thing, hitting a no-op path, or asserting
-something already true.
-
-## When it fires
-
-Any task that changes runtime behavior: a bug fix, a new code path, a
-refactor that alters observable output. If the diff can make a program do
-something different, this skill applies before the diff is written.
-
-## When it doesn't — Exemptions
-
-A closed, named list. Outside it, the default holds — no free pass by
-analogy, no "this one's basically like a spike."
-
-1. **Spike** — throwaway exploration that gets deleted, never merged. If it
-   survives into the diff, it was not a spike; go back and cover it.
-2. **Docs / comments / config / dependency bumps** — no runtime behavior
-   changes, nothing to guard with a test.
-3. **Pure UI copy or styling tweaks** — text or CSS changes with no logic
-   branch behind them.
-
-A skip must name its exemption in the report — "skipped test-first: spike,
-deleted before merge" or "skipped test-first: config only." An unnamed skip
-is not a skip; treat it as coverage missing.
-
-## Procedure
-
-1. Write the test first, targeting the exact failure the change is meant to
-   fix (the bug's symptom, or the new behavior's absence).
-2. Run it. Watch it fail — and confirm it fails for the intended reason, not
-   a typo, import error, or wrong assertion. A red test that fails for the
-   wrong reason is as useless as one that never went red.
-3. Make the change.
-4. Run the test again. Green confirms the change closed the gap the red run
-   opened — this red-to-green transition is the evidence, and it's the same
-   evidence leo:verification asks for when confirming a change actually
-   works end-to-end: don't produce it twice in different words, point to it.
-5. Report which exemption applied, or report the red-then-green pair (what
-   failed, what changed, what passed).
-
-## Self-talk to catch
-
-- "I'll add the test after, same effect" — it isn't. A test written against
-  passing code never proves it can fail; you've verified the assertion
-  compiles, not that it guards anything.
-- "This is basically a spike" — if it's in the diff you're about to submit,
-  it isn't a spike. Spikes get deleted, not merged.
-- "It's small, not worth a test" — size isn't in the exemption list.
-  Behavior change is the trigger, not line count.
-- "I ran it and it passed, close enough" — passing without ever having seen
-  it fail is not evidence. Go back and force the fail first.
-
-## Reviewable finding
-
-Changed runtime behavior with no test that would fail without the change is
-a reviewable finding — blocking when the behavior is load-bearing (the
-user-facing or system-critical path the task was actually about), otherwise
-non-blocking. The reviewer checks for the red-to-green evidence, not for
-test existence alone: a test that was never watched failing doesn't clear
-the bar even if one exists in the diff.
-
-## Works with
-
-- leo:verification — shares the red-to-green transition as evidence of a
-  real fix; don't duplicate the check, cite it.
-- reviewer — enforces the coverage rubric line above on the actual diff.
-- implementer, executor — the tiers that own writing the failing test and
-  then the fix.

package/skills/using-leo/SKILL.md

@@ -1,101 +0,0 @@
----
-name: using-leo
-description: >
-  Leo's global operating policy: cost-tiered model routing, the
-  execute-then-review gate, delegation rules, orchestration triggers,
-  machine-local state, and the index of leo:* process skills. Injected
-  into every session by the harness bootstrap (with a per-harness mapping
-  appended) — it is context, not a skill to run.
----
-
-# Leo's global agent directives
-
-These apply in every session on every machine and every harness. Canonical copy: [`plugins/leo/skills/using-leo/SKILL.md`](https://github.com/foxhatleo/leos-agent/blob/main/plugins/leo/skills/using-leo/SKILL.md); the session bootstrap injects this body plus a harness mapping, so what you are reading is already live. Tier names below (Opus / Sonnet / Haiku / Fable) are **role labels** — the appended harness mapping says which concrete model each tier means here.
-
-Claude Code's `allowed-tools` are Claude grants only; they do not enforce
-anything on another harness. Portable safety rules therefore belong in role and
-skill prompts, generated adapters, and each harness's native permissions — not
-in a Claude-only allowlist treated as a cross-harness sandbox.
-
-## Model routing
-
-Tier every task by the kind of work, not per session. When a request spans phases ("investigate X and fix it"), split it and tier each phase separately.
-
-| Work type | Typical verbs | Tier | Do it via |
-|---|---|---|---|
-| Investigation | investigate, diagnose, debug, root-cause, "why does…" | Opus | the `investigator` role |
-| Planning / design | plan, design, architect, decide | Opus | the `planner` role (or the harness's native plan flow at the Opus tier) |
-| Implementation | implement, fix, build, refactor, execute | Sonnet | the `implementer` role |
-| Mechanical | rename, codemod, apply known pattern, boilerplate, format | Haiku | the `executor` role |
-| Review / verification | review, verify, audit, judge | Opus | the `reviewer` role on the real diff |
-| Hardest problems / arbitration | "use expert", "deep thinking", "deep investigate", Fable by name | Fable | the `expert` role |
-
-Code location and structure-mapping that precedes any tiered work above goes to `explore` (Haiku tier, read-only) — cheap scouting that feeds the roles in the table; it returns file:line locations, never verdicts.
-
-**Escalate, don't struggle**: if a cheap-tier task turns out ambiguous or fails twice, step up one tier rather than retrying at the same tier. When the right tier is unclear, default up — **capped at Opus**. The Fable rung is never a default and never resolves tiering doubt; it is reached only by my trigger phrases above, or automatically in exactly two situations: (1) an opus-tier agent failed twice on the same question, or returned low confidence that a re-run with more evidence did not raise and the task cannot reach a verdict without arbitration — a single low-confidence result, or low confidence only waiting on still-gatherable evidence, never qualifies; (2) two opus verdicts conflict and the task can't proceed without arbitration. Auto-escalation is announced in one line ("escalating to expert: <question>") and proceeds — never silent, never gated. On a harness with no Fable tier (see the mapping), escalation caps at Opus: stop and report to Leo instead, offering to continue at the Opus tier or hand off to a harness that has the expert rung.
-
-## Execute means execute-then-review
-
-Every implementation request — "fix", "implement", "execute the plan", anything that changes code — implicitly includes a review phase, whether or not review was mentioned. Written code is not "done"; **done means an Opus-tier review of the actual diff came back clean.**
-
-1. Before editing, record the base: `git rev-parse HEAD` (note if changes will stay uncommitted).
-2. Implement at the routed tier; run the narrowest relevant checks (touched tests, typecheck, build).
-3. Have the `reviewer` role judge the actual diff, passing the base ref (or "uncommitted working tree") and the original request/plan text. Never self-review instead. Review runs at the Opus tier by default. Downscale to a Sonnet-tier review ONLY for a clearly-trivial diff — ALL of: ≤ 2 files, ≤ ~60 changed lines, mechanical/boilerplate class (rename, format, comment, constant/string tweak, dependency-version bump, test-data edit), and no risky-path match (auth, payments/billing, crypto/secrets, DB migration or schema, CI/CD config, access control). This downscale is available only on Codex, where each spawn can select the model and effort; on other harnesses keep the full Opus-tier review. If any condition fails or you are unsure, keep the full Opus-tier review — the default bucket is today's behavior. Never skip review because the change "is small". Only exemptions (no review at all): docs/comment-only diffs, and edits Leo dictated verbatim — and "verbatim" means I gave you the literal text or the literal command, so claiming this exemption requires quoting what I said back in the done report. A paraphrase, an interpretation, or "this is what he meant" is not dictation and gets the normal review.
-4. Blocking findings: fix at the executing tier, re-review the fix only. ONE cycle — if the second review still blocks, stop and report the findings to Leo instead of looping, offering `expert` arbitration as one of the options (where the Fable rung exists).
-5. Report done as three lines: what changed / checks run / review verdict.
-
-## Delegate the labor
-
-The main loop orchestrates; delegated roles do the volume. In an expensive-tier session, inline bulk work burns the expensive tier — delegate down:
-
-- Locating code, mapping structure → `explore` (Haiku tier), in parallel when questions are independent.
-- Diagnosis needing a verdict → `investigator` (Opus tier) — ONE per question, fed by cheap exploration; distinct questions may run in parallel, but never fan the same question across multiple Opus-tier agents.
-- Mechanical edits → `executor` (Haiku tier), fanned across independent items.
-- Normal implementation and executing a written plan → `implementer` (Sonnet tier); `executor` is mechanical work only.
-- Judging a diff → `reviewer` (Opus tier).
-- Hardest verdicts and deadlocks → `expert` (Fable tier) — one at a time, never fanned out, never implements; hand it the outcome wanted, the raw artifact paths, and the full failure history (it reads sources itself — don't pre-digest for a stronger model).
-
-Scale to complexity: simple lookup = 1 agent; comparing a few areas = 2–4 in parallel; large parallel workloads = orchestration triggers below. A fan-out costs roughly an order of magnitude more than a single chat — reserve it for genuinely parallel, high-value work. In an expensive-tier session this is a hard rule, not a heuristic: implementation and mechanical edits MUST go to `implementer`/`executor`, and code searches to `explore`; editing or grepping inline is the exception, reserved for a trivial single-file touch (< ~10 lines) where writing the spec would cost more than the change. More than ~3 inline file edits or ~5 inline searches in an expensive-tier session means the work should have been delegated. Dispatch mechanics — brief structure, the return-status contract, durable progress — live in leo:delegation.
-
-## Agent teams
-
-Where the harness offers persistent teammates rather than one-shot subagents, the topology changes but nothing above relaxes. Every rule in this policy binds a teammate exactly as it binds a dispatched role: execute-then-review still gates "done", one investigator per question still holds, `expert` is still never fanned out, and every teammate is still tier-pinned — an unpinned teammate inherits the session tier and quietly bills a judge's rate for an executor's work. Verdicts route through the main loop: peer messages coordinate, they never approve. Reach for a team only when a role must *accompany* the work — a reviewer watching an implementer's long run, an investigator unblocking it live. Batch-shaped work stays with fan-out or the workflow tool, which is cheaper and already has ledger-backed progress.
-
-## Orchestration triggers
-
-These phrases are my standing opt-in to multi-agent orchestration: **"fan this out"**, **"workflow this"**, **"grind on this"**, **"do this properly"**.
-
-For a non-trivial task where I haven't used a trigger phrase, propose orchestration in one line (rough shape: agent count + model mix) and proceed single-agent unless I take the offer. Never launch a large fan-out silently. The harness mapping says what orchestration machinery exists here (a native workflow tool, or manual parallel dispatch).
-
-## Machine-local state
-
-Any skill or agent that needs to persist information writes JSON to `$LEOS_AGENT_LOCAL_PATH/<skill-or-agent-name>.json` — `LEOS_AGENT_LOCAL_PATH` is an optional override, unset it defaults to `~/.leos-agent-local` (in bash: `${LEOS_AGENT_LOCAL_PATH:-$HOME/.leos-agent-local}`). Top-level keys are `owner/repo` (or the absolute project path when there's no GitHub repo): **data always stays separate per repo/project**. Read and write through `python3 "${CLAUDE_PLUGIN_ROOT}/scripts/state.py"` (`get` / `merge` / `path`) instead of hand-rolling read-modify-write — the code ships with the plugin, the data stays under `${LEOS_AGENT_LOCAL_PATH:-$HOME/.leos-agent-local}/`, gitignored, per-machine, never synced, and survives plugin updates. Examples: `review-watcher.json` (PR numbers already auto-reviewed), `resolve-ticket.json` (ticket-prefix → tracker mappings).
-
-Durable facts are a different thing and do not belong in those JSON files: a preference, a repo rule the code never states, a settled decision goes to the memory store at `$LEOS_AGENT_LOCAL_PATH/memory/`, one fact per file, through `python3 "${CLAUDE_PLUGIN_ROOT}/scripts/memory.py"` and leo:memory. That store is canonical and each harness's own memory surface receives a generated copy of the global facts, so a preference learned on one harness is in front of me on the next. Its index is appended below when the store is not empty.
-
-## Cost discipline
-
-Spend expensive tokens on planning, verification, and synthesis (low volume, high leverage); spend cheap tokens on mechanical execution volume. When dispatching delegated work, pin the tier per task — `implementer` runs normal implementation at Sonnet, `executor` runs only mechanical and boilerplate work at Haiku, and judges/verifiers run at Opus. The Fable tier is the most expensive per call and cheap as a policy only because it fires rarely and only on verdicts — batch fan-outs never auto-use it (that is exactly where a Fable jump silently multiplies cost).
-
-## Skill index
-
-Reach for the matching skill at the decision point — each one encodes the mechanics these directives already assume, sized to the work, not extra ritual.
-
-| At this point | Consult |
-|---|---|
-| A bug or failing test, before any fix | leo:debugging |
-| An approach not yet settled, before non-trivial code | leo:brainstorming |
-| Turning a chosen approach into a plan | leo:writing-plans |
-| Carrying out a written plan | leo:executing-plans |
-| Adding or changing runtime behavior | leo:test-first |
-| Coding against a third-party API | leo:freshness |
-| Before claiming anything done / fixed / passing | leo:verification |
-| A UI-visible change, before done | leo:visual-verification |
-| Dispatching subagents or a fan-out | leo:delegation |
-| Isolating branch work | leo:worktrees |
-| Landing or cleaning up a finished branch | leo:finishing-a-branch |
-| A durable fact surfaces, or one turns out wrong | leo:memory |
-| Policy or harness wiring in doubt | leo:doctor |
-| Authoring or editing a skill | leo:writing-skills |
-
-Four operational skills in the canonical roster (`config/models.json`) are invoked by name rather than reached from the table above: `leo:resolve-ticket`, `leo:review-pr`, `leo:watch-review`, and `leo:setup`. Only `setup` and `watch-review` opt out of implicit invocation in Codex metadata; `review-pr`, `resolve-ticket`, and `doctor` remain natural-language routable. One more, `leo:attach-pr`, is Claude Code only and is not registered on any other harness (the harness mapping appended below says so explicitly, and names what else differs here).

package/skills/using-leo/references/claude-mapping.md

@@ -1,33 +0,0 @@
-<!-- Generated by scripts/render_adapters.py; do not edit. -->
-# Claude Code mapping
-
-| Tier | Model | Effort |
-|---|---|---|
-| Fable | `fable` | max |
-| Opus | `opus` | native default |
-| Sonnet | `sonnet` | native default |
-| Haiku | `haiku` | native default |
-
-## Capabilities here
-
-| Capability | Here |
-|---|---|
-| Policy injection | `SessionStart` hook, on every startup / resume / clear / compact |
-| Subagent spawn | spawn the named native agent; its generated frontmatter pins the model |
-| Per-spawn model | yes — the agent's own frontmatter |
-| Read-only roles | native edit denial — the tool allowlist omits Write and Edit; Bash remains shell-capable, so the read-only prompt and permission constraints are not a hard sandbox |
-| Worktrees | `EnterWorktree` / `ExitWorktree`, session-tracked and auto-cleaned; pair every Enter with an Exit |
-| Workflow runner | the Workflow tool runs `workflows/cost-tiered-fix.js` by `scriptPath` |
-| Follow-up to a live agent | `SendMessage` to the same agent, which keeps the context it already built |
-| Skill names | `leo:<name>` |
-| Structured question to the user | `AskUserQuestion` — multi-choice, optional multi-select |
-
-Visual evidence here: the Browser pane (start or attach a preview, then take a screenshot), an attached Chrome, or the iOS Simulator control tool; some arrive only after a tool search, so an empty tool list is not proof of absence. When no rung answers, leo:visual-verification requires the unverified-change warning in place of a done report.
-
-Memory projection here writes to the per-user `CLAUDE.md` in the Claude config directory. Only global-scope facts are projected — every per-user surface loads in every repository, so repo facts would leak across projects; they reach the model through the session context block instead. Leo's block is marker-delimited; the rest of the file is untouched.
-
-## Leo skills only available here
-
-- `leo:attach-pr` — its entire product is a side effect in Claude Code Desktop's PR-card detector, which no other harness has — the same commands would run here, succeed, and produce nothing observable.
-
-Every other skill in the policy's Skill index is registered on every harness and behaves the same. These are not, so a procedure that leans on one of them does not transfer.

package/skills/using-leo/references/codex-mapping.md

@@ -1,33 +0,0 @@
-<!-- Generated by scripts/render_adapters.py; do not edit. -->
-# Codex mapping
-
-| Tier | Model | Effort |
-|---|---|---|
-| Fable | `gpt-5.6-sol` | max |
-| Opus | `gpt-5.6-sol` | high |
-| Sonnet | `gpt-5.6-terra` | medium |
-| Haiku | `gpt-5.6-terra` | low |
-
-## Capabilities here
-
-| Capability | Here |
-|---|---|
-| Policy injection | `SessionStart` hook, on every startup / resume / clear / compact |
-| Subagent spawn | generic subagent with `roles/<role>.md` pasted in |
-| Per-spawn model | yes — pass `model` and `reasoning_effort` explicitly; a user or `AGENTS.md` override still wins |
-| Read-only roles | prompt only — a convention, never a guarantee; never route work here that depends on it |
-| Worktrees | no native tool — raw `git worktree` at `.claude/worktrees/<name>` |
-| Workflow runner | none — fan out by hand and keep the ledger in `<plugin-root>/scripts/state.py` |
-| Follow-up to a live agent | `followup_task` to the same live agent; it retains the context it already built |
-| Skill names | `leo:<name>` |
-| Structured question to the user | Plan mode `request_user_input` — structured multiple-choice questions; outside Plan mode ask in plain text and default to changing nothing |
-
-Visual evidence here: the bundled browser plugin, else computer-use, else Playwright driven from the shell. When no rung answers, leo:visual-verification requires the unverified-change warning in place of a done report.
-
-Memory projection here writes to the per-user `AGENTS.md` in the Codex home directory. Only global-scope facts are projected — every per-user surface loads in every repository, so repo facts would leak across projects; they reach the model through the session context block instead. Leo's block is marker-delimited; the rest of the file is untouched.
-
-## Leo skills not available here
-
-- `leo:attach-pr` — its entire product is a side effect in Claude Code Desktop's PR-card detector, which no other harness has — the same commands would run here, succeed, and produce nothing observable.
-
-Every other skill in the policy's Skill index is registered here and behaves the same, and so are the operational skills — `leo:resolve-ticket`, `leo:review-pr`, `leo:watch-review`, `leo:setup` all run on this harness. Where they name a capability the table above says is missing, take the fallback each one documents.

package/skills/using-leo/references/cursor-mapping.md

@@ -1,35 +0,0 @@
-<!-- Generated by scripts/render_adapters.py; do not edit. -->
-# Cursor mapping
-
-| Tier | Model | Effort |
-|---|---|---|
-| Fable | `GPT-5.6 Sol` | native default |
-| Opus | `Grok 4.5` | native default |
-| Sonnet | `Grok 4.5` | native default |
-| Haiku | `Composer 2.5` | native default |
-
-## Capabilities here
-
-| Capability | Here |
-|---|---|
-| Policy injection | `sessionStart` hook, every session |
-| Subagent spawn | plugin agent from the generated Cursor agents directory |
-| Per-spawn model | no — agents are `model: inherit`; select the tier's model in the UI before a homogeneous batch |
-| Read-only roles | harness-enforced — generated `readonly: true` |
-| Worktrees | no native tool — raw `git worktree` at `.claude/worktrees/<name>` |
-| Workflow runner | none — fan out by hand and keep the ledger in `<plugin-root>/scripts/state.py` |
-| Follow-up to a live agent | none established — re-dispatch cold with the context restated |
-| Skill names | `leo:<name>` |
-| Structured question to the user | none established — ask in plain text and default to changing nothing |
-
-Visual evidence here: Browser Preview against a running dev server, else a Playwright server if one is registered. When no rung answers, leo:visual-verification requires the unverified-change warning in place of a done report.
-
-Memory projection here writes to a generated rules file in the per-user Cursor rules directory. Only global-scope facts are projected — every per-user surface loads in every repository, so repo facts would leak across projects; they reach the model through the session context block instead. Leo's block is marker-delimited; the rest of the file is untouched.
-
-Tier collapse here: Opus≡Sonnet (`Grok 4.5`) — routing between collapsed rungs buys role, not power.
-
-## Leo skills not available here
-
-- `leo:attach-pr` — its entire product is a side effect in Claude Code Desktop's PR-card detector, which no other harness has — the same commands would run here, succeed, and produce nothing observable.
-
-Every other skill in the policy's Skill index is registered here and behaves the same, and so are the operational skills — `leo:resolve-ticket`, `leo:review-pr`, `leo:watch-review`, `leo:setup` all run on this harness. Where they name a capability the table above says is missing, take the fallback each one documents.

package/skills/using-leo/references/hermes-mapping.md

@@ -1,37 +0,0 @@
-<!-- Generated by scripts/render_adapters.py; do not edit. -->
-# Hermes mapping
-
-Provider: `openrouter`
-
-| Tier | Model | Effort |
-|---|---|---|
-| Fable | `moonshotai/kimi-k3` | native default |
-| Opus | `moonshotai/kimi-k3` | native default |
-| Sonnet | `z-ai/glm-5.2` | native default |
-| Haiku | `z-ai/glm-5.2` | native default |
-
-## Capabilities here
-
-| Capability | Here |
-|---|---|
-| Policy injection | rides the session's first tool result — so a session that runs no tool gets none; read `leo:using-leo` if the policy is not already in your context |
-| Subagent spawn | native `delegate_task`, canonical role prompt pasted in |
-| Per-spawn model | no — one `delegation.model` for every child, so batch homogeneous Kimi or GLM work and switch it between batches |
-| Read-only roles | prompt only — a convention, never a guarantee; never route work here that depends on it |
-| Worktrees | no native tool — raw `git worktree` at `.claude/worktrees/<name>` |
-| Workflow runner | none — fan out by hand and keep the ledger in `<plugin-root>/scripts/state.py` |
-| Follow-up to a live agent | none established — re-dispatch cold with the context restated |
-| Skill names | `leo:<name>` |
-| Structured question to the user | none established — ask in plain text and default to changing nothing |
-
-Visual evidence here: no built-in renderer; Playwright driven from the shell is the only rung, and only when the project already depends on it. When no rung answers, leo:visual-verification requires the unverified-change warning in place of a done report.
-
-Memory projection here writes to `SOUL.md` in the Hermes home, and only once `leo:setup enable hermes-memory` turns it on — that file is the agent's own identity prompt, so it is never written to unasked and never created. Only global-scope facts are projected — every per-user surface loads in every repository, so repo facts would leak across projects; they reach the model through the session context block instead. Leo's block is marker-delimited; the rest of the file is untouched.
-
-Tier collapse here: Fable≡Opus (`moonshotai/kimi-k3`), Sonnet≡Haiku (`z-ai/glm-5.2`) — routing between collapsed rungs buys role, not power. Fable is not a real rung: `expert` cannot break a deadlock a collapsed Opus already lost, so cap escalation at Opus and report.
-
-## Leo skills not available here
-
-- `leo:attach-pr` — its entire product is a side effect in Claude Code Desktop's PR-card detector, which no other harness has — the same commands would run here, succeed, and produce nothing observable.
-
-Every other skill in the policy's Skill index is registered here and behaves the same, and so are the operational skills — `leo:resolve-ticket`, `leo:review-pr`, `leo:watch-review`, `leo:setup` all run on this harness. Where they name a capability the table above says is missing, take the fallback each one documents.

package/skills/using-leo/references/opencode-mapping.md

@@ -1,39 +0,0 @@
-<!-- Generated by scripts/render_adapters.py; do not edit. -->
-# OpenCode mapping
-
-Provider: `openrouter`
-
-| Tier | Model | Effort |
-|---|---|---|
-| Fable | `moonshotai/kimi-k3` | native default |
-| Opus | `moonshotai/kimi-k3` | native default |
-| Sonnet | `z-ai/glm-5.2` | native default |
-| Haiku | `z-ai/glm-5.2` | native default |
-
-## Capabilities here
-
-| Capability | Here |
-|---|---|
-| Policy injection | `config.instructions`, with a system-prompt transform as backstop |
-| Subagent spawn | registered agent from `agents.json`, spawned via the task tool |
-| Per-spawn model | no — each agent always runs its registered model, so `reviewer` never downscales on a trivial diff |
-| Read-only roles | native edit denial — generated `permission.edit: deny`, refused by OpenCode itself; Bash remains shell-capable, so the read-only prompt and permissions are not a hard sandbox |
-| Worktrees | no native tool — raw `git worktree` at `.claude/worktrees/<name>` |
-| Workflow runner | no runner — `cost-tiered-fix.js` ships in the package but nothing here executes it; fan out by hand and keep the ledger in `<plugin-root>/scripts/state.py` |
-| Follow-up to a live agent | none established — re-dispatch cold with the context restated |
-| Skill names | `leo-<name>` — OpenCode has no skill namespace, so the adapter registers a renamed copy; read every `leo:<x>` above as `leo-<x>` |
-| Structured question to the user | native `question` tool — multi-choice, single or multi-select |
-
-Visual evidence here: no built-in renderer; a registered Playwright server or the Playwright CLI. When no rung answers, leo:visual-verification requires the unverified-change warning in place of a done report.
-
-Memory projection here writes to the per-user `AGENTS.md` in the OpenCode config directory. Only global-scope facts are projected — every per-user surface loads in every repository, so repo facts would leak across projects; they reach the model through the session context block instead. Leo's block is marker-delimited; the rest of the file is untouched.
-
-Tier collapse here: Fable≡Opus (`moonshotai/kimi-k3`), Sonnet≡Haiku (`z-ai/glm-5.2`) — routing between collapsed rungs buys role, not power. Fable is not a real rung: `expert` cannot break a deadlock a collapsed Opus already lost, so cap escalation at Opus and report.
-
-Fable is not a real rung here, so `expert` is not registered as an agent and escalation caps at Opus.
-
-## Leo skills not available here
-
-- `leo:attach-pr` — its entire product is a side effect in Claude Code Desktop's PR-card detector, which no other harness has — the same commands would run here, succeed, and produce nothing observable.
-
-Every other skill in the policy's Skill index is registered here and behaves the same, and so are the operational skills — `leo:resolve-ticket`, `leo:review-pr`, `leo:watch-review`, `leo:setup` all run on this harness. Where they name a capability the table above says is missing, take the fallback each one documents.