leos-agent 6.3.0 → 7.0.0

package/skills/setup/SKILL.md

@@ -5,7 +5,10 @@ description: >
   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 and reversible: running it twice changes nothing the second time.
+  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
@@ -29,9 +32,9 @@ 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 path out of the
-machine-local state paragraph in the policy already in your context, which had
-its placeholders substituted before injection.
+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
@@ -45,6 +48,113 @@ 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`
@@ -78,8 +188,12 @@ Leo's markers.
 
 ## What setup never does
 
-It does not install, update, or repair the plugin, and it does not 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. setup only records consent
-and flips flags; the projection itself happens at the next session start,
-through the same `memory.py` helper every harness already uses.
+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

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

@@ -6,7 +6,9 @@ description: >
   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.
+  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.

package/skills/using-leo/SKILL.md

@@ -10,7 +10,12 @@ description: >
 
 # Leo's global agent directives
 
-These apply in every session on every machine and every harness. Canonical copy: `skills/using-leo/SKILL.md` in the leos-agent repo; 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.
+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
 
@@ -20,7 +25,7 @@ Tier every task by the kind of work, not per session. When a request spans phase
 |---|---|---|---|
 | 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 | main loop if the session runs at the Sonnet tier, else the `implementer` role |
+| 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 |
@@ -35,7 +40,7 @@ Every implementation request — "fix", "implement", "execute the plan", anythin
 
 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). 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.
+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.
 
@@ -46,7 +51,7 @@ The main loop orchestrates; delegated roles do the volume. In an expensive-tier
 - 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.
-- Executing a written plan → `implementer` (Sonnet tier).
+- 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).
 
@@ -70,7 +75,7 @@ Durable facts are a different thing and do not belong in those JSON files: a pre
 
 ## Cost discipline
 
-Spend expensive tokens on planning, verification, and synthesis (low volume, high leverage); spend cheap tokens on execution volume. When dispatching delegated work, pin the tier per task — the `executor` role runs at the Haiku tier for mechanical and boilerplate work and at the Sonnet tier at low effort for ordinary implementation, judges/verifiers at the Opus tier. 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).
+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
 
@@ -93,4 +98,4 @@ Reach for the matching skill at the decision point — each one encodes the mech
 | Policy or harness wiring in doubt | leo:doctor |
 | Authoring or editing a skill | leo:writing-skills |
 
-Four operational skills — `leo:resolve-ticket`, `leo:review-pr`, `leo:watch-review`, `leo:setup` — are invoked by name rather than reached from the table above. 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).
+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

@@ -15,11 +15,12 @@
 | 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 | harness-enforced — the tool allowlist omits Write and Edit |
+| 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.
 

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

@@ -6,7 +6,7 @@
 | Fable | `gpt-5.6-sol` | max |
 | Opus | `gpt-5.6-sol` | high |
 | Sonnet | `gpt-5.6-terra` | medium |
-| Haiku | `gpt-5.6-luna` | low |
+| Haiku | `gpt-5.6-terra` | low |
 
 ## Capabilities here
 
@@ -18,17 +18,16 @@
 | 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 |
+| 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.
 
-Tier collapse here: Fable≡Opus (`gpt-5.6-sol`) — 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:review-pr`, `leo:resolve-ticket` and `leo:watch-review` all run on this harness. Where they name a capability the table above says is missing, take the fallback each one documents.
+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

@@ -20,6 +20,7 @@
 | 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.
 
@@ -31,4 +32,4 @@ Tier collapse here: Opus≡Sonnet (`Grok 4.5`) — routing between collapsed run
 
 - `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:review-pr`, `leo:resolve-ticket` and `leo:watch-review` all run on this harness. Where they name a capability the table above says is missing, take the fallback each one documents.
+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

@@ -22,6 +22,7 @@ Provider: `openrouter`
 | 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.
 
@@ -33,4 +34,4 @@ Tier collapse here: Fable≡Opus (`moonshotai/kimi-k3`), Sonnet≡Haiku (`z-ai/g
 
 - `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:review-pr`, `leo:resolve-ticket` and `leo:watch-review` all run on this harness. Where they name a capability the table above says is missing, take the fallback each one documents.
+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

@@ -17,11 +17,12 @@ Provider: `openrouter`
 | 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 | harness-enforced — generated `permission.edit: deny`, refused by OpenCode itself |
+| 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 | bare `<name>` — read every `leo:<x>` above as `<x>` |
+| 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.
 
@@ -29,8 +30,10 @@ Memory projection here writes to the per-user `AGENTS.md` in the OpenCode config
 
 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:review-pr`, `leo:resolve-ticket` and `leo:watch-review` all run on this harness. Where they name a capability the table above says is missing, take the fallback each one documents.
+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/verification/SKILL.md

@@ -5,7 +5,8 @@ description: >
   the main loop, implementer, executor, and anyone reporting completion:
   a completion claim needs a proving command run in the current turn, whose
   output was actually read — never a prior run, a "should pass now," or a
-  subagent's self-report relayed as fact.
+  subagent's self-report relayed as fact. Use when making or relaying a
+  completion claim. Do not use for in-progress updates or to replace review.
 when_to_use: >
   Before writing any completion claim — "tests pass," "build is green,"
   "bug fixed," "agent finished the task." Also applies when relaying a

package/skills/visual-verification/SKILL.md

@@ -6,7 +6,8 @@ description: >
   Detection walks a ranked ladder of whatever browser, preview, or simulator
   tooling this harness exposes; when nothing on the ladder answers, the change
   is reported with an explicit unverified warning instead of a completion
-  claim.
+  claim. Use when a person can see the changed result. Do not use for
+  non-rendered logic, an off feature flag, or as a replacement for tests.
 when_to_use: >
   A change whose result someone would notice by looking — layout, styling,
   on-screen text, a new view or route, a chart, a generated image or rendered

package/skills/watch-review/SKILL.md

@@ -5,7 +5,9 @@ description: >
   non-draft PRs where Leo's GitHub user is DIRECTLY requested as reviewer,
   carry out the review-pr procedure on each new one, and record it in
   machine-local state so it is never auto-reviewed again. Meant to be
-  re-invoked on an interval by whatever schedules recurring work here.
+  re-invoked on an interval by whatever schedules recurring work here. Use
+  when Leo explicitly invokes the watcher only. Do not use because a PR or
+  review was merely mentioned.
 when_to_use: >
   ONLY when Leo explicitly invokes watch-review (usually on a repeating
   interval). Never trigger it because a PR or review was merely mentioned —
@@ -27,13 +29,12 @@ whatever this harness offers, or from a shell (`while :; do …; sleep 60; done`
 or cron). Claude Code's `/loop` is a separate skill that this plugin does not
 ship, so the scheduler is external on every harness including that one.
 
-A tick is cheap by design: on an idle tick, read the preflight and say one
-line. Only a match escalates. Run the idle tick at the Haiku tier and the
-review itself at the Opus tier — your harness mapping names the concrete
-models, and where those two tiers collapse onto one model there is no cheap
-rung to tick at, which is worth knowing before running this on a short
-interval. If you cannot raise the tier for the review, say so in one line and
-let Leo run review-pr directly rather than reviewing a PR at the wrong tier.
+A tick is cheap discovery only: on an idle tick, read the preflight and say one
+line; never load a PR body or diff. Only a match escalates. Run the idle tick
+at the Haiku tier, then hand each match to a **fresh Opus** `review-pr` run
+where the harness supports it. Where it cannot preserve a fresh high-tier
+handoff, emit a cold handoff (PR number, owner/repo, discovered reviewer
+login) and let Leo invoke `review-pr`; do not review at the wrong tier.
 
 On Claude Code specifically: do NOT set `disable-model-invocation` in this
 file — skills marked that way do not execute under `/loop`.
@@ -61,7 +62,7 @@ leo:delegation for the per-harness forms.
 ```bash
 gh repo view --json nameWithOwner
 gh api user --jq .login
-gh pr list --state open --search "user-review-requested:@me" \
+gh pr list --state open --search "user-review-requested:<login-from-gh-api>" \
   --json number,title,isDraft,reviewRequests
 python3 "${CLAUDE_PLUGIN_ROOT}/scripts/state.py" get review-watcher
 ```
@@ -71,7 +72,8 @@ one-line diagnosis; touch nothing.
 
 ## Filter
 
-`user-review-requested:@me` already matches only PRs where I am **directly**
+Substitute the literal login returned by `gh api user --jq .login`; never rely
+on `@me`. `user-review-requested:<login>` already matches only PRs where I am **directly**
 requested — a request for a team I belong to does not count and must never
 trigger a review. Belt and braces, from the preflight list keep only PRs
 where ALL hold:
@@ -90,10 +92,11 @@ requests for <owner/repo>` — and end the turn. The next tick re-checks.
 
 For each remaining PR, in ascending number order, strictly sequentially:
 
-1. Carry out the **review-pr** procedure for that PR number. Where the harness
-   has a skill-invocation tool, use it (`leo:review-pr` with the number); where
-   it does not, read that skill and follow it. Do not improvise a review — the
-   staged-comment mechanics and the verdict rubric live there.
+1. Hand off the PR number, `owner/repo`, and literal login to a **fresh Opus**
+   **review-pr** run where the harness supports it. Otherwise make a cold
+   handoff to Leo and stop before any review action. Do not improvise a review
+   in this cheap tick — the staged-comment mechanics and verdict rubric live
+   in review-pr.
 2. **Only after the review completes** (verdict delivered), record it:
 
    ```bash

package/skills/watch-review/agents/openai.yaml

@@ -0,0 +1,5 @@
+interface:
+  display_name: "Watch Pull Request Reviews"
+  short_description: "Check directly requested pull request reviews"
+policy:
+  allow_implicit_invocation: false

package/skills/worktrees/SKILL.md

@@ -4,7 +4,9 @@ description: >
   Worktree lifecycle mechanics for isolated branch work — detect, create,
   and clean up a git worktree so implementation happens off the main
   checkout. Shared by resolve-ticket, executing-plans, and delegation
-  fan-outs; not itself a workflow, just the plumbing they all call into.
+  fan-outs; not itself a workflow, just the plumbing they all call into. Use
+  when creating or tearing down isolated branch work. Do not use to decide
+  whether isolation is needed or to dispose of a finished branch.
 when_to_use: >
   Any skill or agent about to create or tear down a worktree for isolated
   branch work. NOT for choosing whether isolation is needed in the first

package/skills/writing-plans/SKILL.md

@@ -5,7 +5,8 @@ description: >
   plan is done when a Sonnet implementer can execute it without making a
   single design decision — every step names exact files, shows literal
   code or commands, and states how to verify it, anchored to a recorded
-  base ref.
+  base ref. Use when writing or reviewing a multi-step implementation plan.
+  Do not use to choose an approach or to implement or review the plan's diff.
 when_to_use: >
   Writing or reviewing a plan before handoff to leo:executing-plans —
   planner-agent output, plan-mode output, or any multi-step change spec.

package/skills/writing-skills/SKILL.md

@@ -6,7 +6,9 @@ description: >
   correctly, the closed-exemption-list structure the existing skills share,
   and where a personal skill file goes on each harness so it loads beside
   the plugin's own. Covers both skills that ship with the plugin and
-  personal ones kept outside it.
+  personal ones kept outside it. Use when authoring a skill or choosing its
+  personal load path. Do not use to decide whether a process needs a skill or
+  to change plugin packaging or loaders.
 when_to_use: >
   Writing a new skill, revising an existing one's frontmatter, or deciding
   where to put a personal skill so a harness picks it up. NOT for deciding
@@ -110,7 +112,12 @@ not obviously point at the omission:
 2. A row in the policy's skill index — keep it short, since that table is
    injected into every session on every harness and the smallest budget wins.
 3. At least one `leo:<name>` reference from some file other than its own body.
-4. The roster constants in the test suite, and the skill list in the README.
+4. The roster constants and metadata tests in the test suite, plus the
+   appropriate registration class: portable skills in `skills/`, Claude-only
+   skills in `skills-claude/`, and harness metadata under `agents/openai.yaml`
+   only when that skill needs Codex invocation policy. Keep the `leo:`
+   namespace in portable policy prose; OpenCode's generated copy uses
+   `leo-<name>` because it has no namespace.
 
 Write example tokens as `leo:<name>` with the angle brackets. A literal
 placeholder like a made-up skill name is scanned as a real reference and fails

package/vendor/jsonc-parser-3.3.1/LICENSE.md

@@ -0,0 +1,21 @@
+The MIT License (MIT)
+
+Copyright (c) Microsoft
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/vendor/jsonc-parser-3.3.1/README.md

@@ -0,0 +1,26 @@
+# jsonc-parser provenance
+
+OpenCode configuration edits use `jsonc-parser` 3.3.1's `modify` plus
+`applyEdits` operations through `scripts/jsonc_bridge.cjs`. It is vendored
+rather than loaded at setup time: setup must be deterministic, work offline,
+and must not turn a user-approved config edit into an unreviewed mutable
+install.
+
+Reviewed registry artifact: [jsonc-parser 3.3.1](https://registry.npmjs.org/jsonc-parser/-/jsonc-parser-3.3.1.tgz), MIT.
+
+- npm SHA-1: `f2a524b4f7fd11e3d791e559977ad60b98b798b4`
+- npm integrity: `sha512-HUgH65KyejrUFPvHFPbqOY0rsFip3Bo5wb4ngvdi1EpCYWUQDC5V+Y7mZws+DLkr4M//zQJoanu1SP+87Dv1oQ==`
+- fetched tarball SHA-256: `4a0315b8671e7463bae7af7c142cdf19e9aa7ba39eb36dc2df383b8648e3cbc9`
+
+The vendored files are `LICENSE.md`, `package.json`, and the complete
+dependency-free `lib/umd/` runtime used by the bridge.
+
+Update procedure: download that exact registry tarball, verify its SHA-256
+against the reviewed value above, replace only those files, then run both
+`python3 -m unittest tests.test_setup` and `python3.14 -m unittest tests.test_setup`
+plus `python3 -m unittest tests.test_release`. Review the new release and
+record its exact registry URL, SHA-1, SHA-256, integrity, and version here.
+Core MCP executable pins have their separate review procedure in
+`config/MCP_PINS.md`. Preserve the add-only rule, comments, trailing
+commas, indentation, symlinks, and file modes. Never replace a JSONC edit with
+`JSON.stringify` or `json.dumps`.