leos-agent 6.3.0 → 10.1.0

package/skills/test-first/SKILL.md

@@ -1,90 +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.
-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,96 +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: `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.
-
-## 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 | main loop if the session runs at the Sonnet tier, else 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). 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.
-- Executing a written plan → `implementer` (Sonnet tier).
-- 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 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).
-
-## 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 — `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).

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

@@ -1,32 +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 | harness-enforced — the tool allowlist omits Write and Edit |
-| 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>` |
-
-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,34 +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-luna` | 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 | none established — re-dispatch cold with the context restated |
-| Skill names | `leo:<name>` |
-
-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.

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

@@ -1,34 +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>` |
-
-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: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.

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

@@ -1,36 +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>` |
-
-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: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.

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

@@ -1,36 +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 | harness-enforced — generated `permission.edit: deny`, refused by OpenCode itself |
-| 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>` |
-
-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.
-
-## 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.

package/skills/verification/SKILL.md

@@ -1,109 +0,0 @@
----
-name: verification
-description: >
-  Fresh-evidence gate before claiming done, fixed, or passing. Applies to
-  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.
-when_to_use: >
-  Before writing any completion claim — "tests pass," "build is green,"
-  "bug fixed," "agent finished the task." Also applies when relaying a
-  subagent's own "done"/"success" report up the chain. NOT for routine
-  in-progress status updates that make no completion claim, and NOT a
-  substitute for the review phase itself — this gates the evidence behind
-  it, execute-then-review still owns the verdict.
----
-
-# verification
-
-Core rule: no completion claim without a proving command run fresh, this
-turn, with output actually read. A claim resting on memory, a prior run, or
-someone else's word is not verification — it is a guess wearing the shape
-of one.
-
-## When it fires
-
-Any sentence of the form "X passes," "X is fixed," "X works now," "agent Y
-finished." That sentence is a claim. A claim needs proof, and proof has an
-expiration: the moment code changes again, prior proof is stale.
-
-Does not fire for: status updates that don't assert completion ("still
-running," "found the bug, fixing now"), or work that genuinely has no
-runtime surface (docs/comment-only diffs — see the execute-then-review
-exemptions).
-
-## The discipline
-
-1. **Name the command that would falsify the claim.** Not "does it look
-   right" — the specific test/build/repro that fails if the claim is false.
-   If no such command exists, the claim isn't verifiable yet; say so instead
-   of asserting it.
-2. **Run it fresh, this turn.** A green run from three edits ago proves
-   nothing about the code as it stands now.
-3. **Read the exit status and failure counts.** Not the last line of
-   scrollback, not a summary a subagent wrote — the actual output.
-4. **Only then claim, and state the evidence** — the command and what it
-   returned, not just "verified."
-
-Skipping step 1 is how "should be fine" sneaks in. Skipping step 2 is how a
-stale green run gets relayed as current. Skipping step 3 is how a nonzero
-exit gets read as success because the output scrolled by fast.
-
-## Claim → proof
-
-| Claim | Falsifying command |
-|---|---|
-| Tests pass | the actual test command, run now, exit code + failure count read |
-| Build is green | the build command, run now, read for errors/warnings |
-| Bug is fixed | the reproducer that showed the bug — now green, run fresh |
-| Agent reports done | its diff and output, inspected directly — its "success" is a claim, not evidence |
-| This library call is correct | the installed package or current docs, read this session — see leo:freshness |
-| A UI change looks right | a render produced after the edit, looked at — see leo:visual-verification |
-
-## Subagent reports are claims, not evidence
-
-A subagent saying "success," "all tests pass," or "implemented as
-requested" is exactly as unverified as your own untested assertion would be
-— it is one more claim to check against artifacts. Inspect the diff it
-produced. Run the check it says it ran. If it reports a test command, that
-command's output belongs in your evidence, not its summary of the output.
-Relaying a subagent's self-report upward without this check just moves the
-gap in provenance one level up the chain.
-
-## Done is the three-line report
-
-Writing code is not done. Done is the execute-then-review report:
-
-- **what changed** — the diff, in one line
-- **checks run** — the fresh commands from this gate, with results
-- **review verdict** — clean per the execute-then-review policy, not
-  self-assessed
-
-Verification is the evidence behind lines two and three. A report with line
-one but not two and three is a status update, not a completion claim — label
-it as such.
-
-## Self-talk to catch
-
-- "It should pass now, I fixed the obvious thing" — run it.
-- "The tests were green before this edit" — before this edit is not now.
-- "The subagent said it's done" — done according to whom, checked how.
-- "I read the code and it looks correct" — reading is not running.
-- "Re-running is wasteful, nothing changed" — if nothing changed, the prior
-  run is fine to cite as fresh evidence; if anything did, it isn't.
-
-## Works with
-
-- The execute-then-review policy (injected leo:using-leo) — that gate is the
-  outer loop this skill feeds into; the reviewer subagent judges the diff,
-  this skill governs the evidence claimed leading up to that judgment.
-- reviewer — its verdict is itself a claim to relay accurately, not to
-  soften or summarize away.
-- End-to-end exercise — when the falsifying command is "does the real flow
-  work," drive the actual app or flow, not just the test suite.
-- leo:freshness — this gate proves the code you wrote runs; that one governs
-  whether the third-party API you wrote it against actually exists. A green
-  test against a mocked dependency clears this skill and not that one.
-- leo:visual-verification — for a change someone sees, the falsifying artifact
-  is a render, not an exit status. That skill owns what the render must show.

package/skills/visual-verification/SKILL.md

@@ -1,114 +0,0 @@
----
-name: visual-verification
-description: >
-  Render-evidence gate for changes a person can see. A UI-visible edit is not
-  reported done until a render produced after the edit has been looked at.
-  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.
-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
-  document. Fires just before the completion claim, beside leo:verification.
-  NOT for logic with no rendered surface, NOT for a component behind a flag
-  that is off, and NOT a replacement for tests — a render shows one state, a
-  test covers the branch.
----
-
-# visual-verification
-
-A pixel claim needs a pixel. Reporting that a visible change works, having
-never rendered it, is an assertion about something nobody looked at — and the
-whole suite can be green while the element sits clipped, transparent, or
-underneath its own container.
-
-This is the complement of the test gate. leo:test-first exempts pure copy and
-styling tweaks precisely because a test would say nothing useful about them;
-this skill is what catches them instead. What one gate waves through, the other
-holds.
-
-## When it fires
-
-Rendered layout or styling; on-screen text; a new or changed view, route, or
-component; a chart, canvas, or generated image; a rendered document artifact;
-a state someone reaches by clicking.
-
-It does not fire for data-layer changes, logging, build configuration, or a
-component behind a disabled flag.
-
-## The detection ladder
-
-Walk in order, stop at the first rung that answers. A rung that exists but
-errors or returns nothing counts as absent for this purpose.
-
-1. **A harness-native preview or browser pane** — starts or attaches to the
-   project's own dev server and screenshots the running app. Highest fidelity:
-   it renders the real build.
-2. **A harness-native attached browser** — drives an already-running browser at
-   a URL. Right when the app is deployed or served outside this session.
-3. **A platform simulator** — for native UI no browser can show.
-4. **A scriptable driver through the shell** — Playwright or Puppeteer, or an
-   existing end-to-end test that captures a screenshot. Check the lockfile
-   before concluding the project does not have one.
-5. **A rendering assertion the project already owns** — a snapshot or visual
-   regression suite. Weaker than a render you looked at, but it is evidence
-   produced after the edit. Name which one you used.
-
-**The ladder is about capability, not brand names.** A harness that renames its
-browser tool still has rung 1. Where a harness defers part of its tool
-inventory until it is searched, an empty tool list is not evidence of absence —
-search first, then conclude. That distinction is the most likely way this gate
-degrades to a warning when something was in fact available.
-
-The mapping appended to the session policy names which rungs exist here.
-
-## What counts as evidence
-
-The render is produced **after** the edit, this turn, and is actually looked
-at. Name what you checked in it — the element, where it sits, what state it is
-in. A screenshot captured is not a screenshot read.
-
-## When nothing answers
-
-There is no exemption list here. A UI-visible change either carries a render or
-carries this block. Emit it **instead of** the word done:
-
-```
-UNVERIFIED UI CHANGE — no render tool answered on this harness.
-
-Changed:    <the visible change, one line>
-Expected:   <what should look different, and where>
-Probed:     <the rungs tried, by name, in order>
-Verify by:  <the one concrete thing Leo can do — a URL, a command, a screen>
-```
-
-The completion line then reads "implemented, unverified" — never "done". A
-`Probed:` line that names nothing means the ladder was skipped, not that it came
-up empty. Never suppress the block because the change looks obviously correct
-or the diff was one line of CSS.
-
-## Self-talk to catch
-
-- "It's one line of CSS" — one line of CSS is what collapses a flex container.
-- "The component tests pass" — tests assert a tree; an element can be present
-  and invisible.
-- "There's no browser tool here" — did you probe, or read a tool list that
-  hides half its inventory until asked?
-- "I'll mention it wasn't verified in passing" — in passing is how it gets read
-  as done. Use the block.
-- "I rendered it earlier" — then you have a picture of the previous version.
-
-## Reviewable finding
-
-A UI-visible diff reported done with neither render evidence nor the warning
-block is a blocking finding.
-
-## Works with
-
-- leo:verification — the same rule about evidence being fresh, applied to a
-  render rather than an exit status. That gate owns the completion claim; this
-  one owns what a visible claim needs behind it.
-- leo:test-first — its copy-and-styling exemption is this skill's inbox. A
-  snapshot test is rung 5 and satisfies both, once.
-- reviewer — the warning block is an artifact to judge, not prose to skim past.