leos-agent 7.0.0 → 10.2.0

package/settings.json

@@ -1,7 +0,0 @@
-{
-  "permissions": { "defaultMode": "auto" },
-  "tui": "fullscreen",
-  "theme": "auto",
-  "skipWorkflowUsageWarning": true,
-  "agentPushNotifEnabled": true
-}

package/skills/brainstorming/SKILL.md

@@ -1,111 +0,0 @@
----
-name: brainstorming
-description: >
-  Design gate before non-trivial code — proportional to blast radius and
-  reversibility, the deliberate opposite of an unconditional gate. Contained,
-  easily reversible changes clear with one sentence of rationale; changes with
-  wide blast radius, hard to reverse, or that introduce new surface need
-  genuine, viable alternatives with trade-offs weighed before any code gets
-  written. Produces the chosen approach and its trade-offs, sized to the gate,
-  handed off to leo:writing-plans. Use when choosing an approach before
-  non-trivial code. Do not use for contained reversible tweaks, investigation,
-  or writing the plan itself.
-when_to_use: >
-  Before starting non-trivial code: a new feature, a new integration surface,
-  a schema or data-model change, anything that's expensive or awkward to
-  undo. NOT for a contained, easily reversible tweak (that just needs one
-  sentence of rationale, not this skill's full procedure), NOT for pure
-  investigation (use investigator), and NOT for writing the plan itself
-  (leo:writing-plans) — brainstorming stops at a chosen approach, it never
-  slides into implementation.
----
-
-# brainstorming
-
-Core rule: the depth of the design gate is proportional to blast radius and
-reversibility, not to how the task felt when it landed. A one-line change to
-a private helper does not need three alternatives; a new public API or a
-schema migration does.
-
-## Size the gate first
-
-Before generating anything, classify the change:
-
-- **Contained + easily reversible** (a local refactor, an internal helper, a
-  flag you can flip back) → one sentence of rationale is enough. Say what
-  you're doing and why, then move to leo:writing-plans or straight to
-  implementation per the routing table.
-- **Wide blast radius, hard to reverse, or new surface** (public API, schema
-  or data-model change, cross-service contract, anything users or other
-  systems will come to depend on) → full gate: genuine alternatives with
-  trade-offs, written down, before any code.
-
-When unsure which bucket, treat it as the wider one — the cost of one extra
-paragraph is nothing next to the cost of an unreversible wrong turn.
-
-## Alternatives must be viable
-
-Every alternative in a full gate has to be something a reasonable engineer
-could actually ship and defend, not a strawman stood up to make the first
-idea look good by comparison. If you can't articulate a real reason someone
-would pick alternative B, it isn't an alternative — go find one that's
-actually competing for the job, or drop down to the one-sentence gate because
-there's really only one sane approach.
-
-Test: could you argue for this option in front of Leo without a "but
-obviously we won't do this" tone? If not, it's a strawman — cut it.
-
-## Generation method
-
-To surface genuinely different options, vary along a different axis each
-time rather than producing three cosmetic variants of the same idea:
-
-1. **Data model vs. control flow vs. boundary/interface** — would this
-   problem look different if you moved the complexity into the data shape,
-   into how execution flows, or into where the interface/boundary sits?
-2. **Prior art in the repo** — grep for how this repo already solved a
-   similar problem (via explore, not inline digging) and steal that pattern
-   before inventing a new one. Consistency with existing structure is a real
-   trade-off, not a tie-breaker of last resort.
-3. **The 10x-simpler version** — what would this look like with one-tenth
-   the code/config/moving parts? Even when you don't ship it, it's usually
-   the sharpest lens on what the "proper" version is paying for.
-
-## Output
-
-- Contained/reversible: one sentence of rationale, folded into the plan or
-  the commit itself.
-- Full gate: the chosen approach plus the trade-offs record — a paragraph for
-  a medium decision, a short doc for a genuinely high-stakes one. Sized to
-  the gate, not padded to look thorough.
-
-Either way, the output is a decision, not code. Hand it to
-leo:writing-plans for the actual plan; brainstorming never slides into
-implementation itself.
-
-## Self-talk to catch
-
-- "I'll just list two options so it looks considered" — if you can't defend
-  both, that's a strawman, not a gate.
-- "This is a big change but I already know the answer" — blast radius and
-  reversibility decide the gate size, not your confidence.
-- "I'll sketch the plan while I'm at it" — that's leo:writing-plans' job;
-  stop at the chosen approach.
-- "One sentence feels thin for something this exciting" — excitement isn't
-  blast radius; if it's contained and reversible, one sentence is correct.
-
-## Escalation
-
-Planning-tier work runs at Opus per the routing table (plan mode in an Opus
-session, or the `planner` subagent otherwise). Escalate per the standard
-ladder: two failed passes at reaching a defensible set of alternatives step
-up a tier; a genuine deadlock between two Opus-tier framings goes to
-`expert`, announced in one line, never silently.
-
-## Works with
-
-- leo:writing-plans — takes the chosen approach and turns it into an
-  executable plan.
-- investigator — for questions that need evidence before a design question
-  can even be framed.
-- explore — cheap prior-art search feeding the generation method above.

package/skills/debugging/SKILL.md

@@ -1,100 +0,0 @@
----
-name: debugging
-description: >
-  Root-cause-before-fix loop for bugs, failing tests, crashes, and surprising
-  behavior. Five named phases — Reproduce, Localize, Hypothesize, Prove, Fix —
-  each with an exit criterion, so a fix never lands before the cause is
-  pinned to file:line. Diagnosis is read-only judge work (investigator); the
-  fix happens separately, at the routed tier. Use when a bug, failure, crash,
-  or surprising behavior needs diagnosis. Do not use for planned features,
-  reviewing a diff, or post-fix completion verification.
-when_to_use: >
-  Any bug report, failing test, crash, stack trace, or "why does X happen"
-  before proposing a fix — used by the investigator agent and by the main
-  loop ahead of any edit that touches broken behavior. NOT for planned
-  feature work with no defect (that's planner), NOT for judging someone
-  else's diff (that's reviewer), and NOT a substitute for leo:verification
-  after the fix lands — this skill ends at Fix, verification is separate.
----
-
-# debugging
-
-Core rule: no fix before the cause is REPRODUCED and LOCATED at file:line. A
-symptom going away is not proof — it's a coincidence until the loop below
-says otherwise.
-
-## When it fires
-
-Bug reports, failing tests, crashes, stack traces, flaky behavior, "this
-should work but doesn't." Route the diagnosis itself through `investigator`
-(Opus, read-only) per the model-routing table — this skill is its loop.
-Doesn't fire for greenfield feature work (no defect exists yet) or for
-diffing someone else's change (that's `reviewer`).
-
-## The five phases
-
-Named exactly, run in order, each with an exit criterion. Do not skip a
-phase because the bug "looks obvious" — obvious bugs are exactly the ones
-where a wrong guess ships fastest.
-
-| Phase | Exit criterion |
-|---|---|
-| **Reproduce** | The failure fires on command — a test, a script, a repro sequence — not "worked once." No stable repro yet is itself a finding: report it, don't guess past it. |
-| **Localize** | The failure is traced to a specific **file:line**, not a subsystem or a vibe ("something in auth"). Read the actual code path the repro exercises; don't infer from names or docs. |
-| **Hypothesize** | One sentence: "X happens because file:line does Y instead of Z." One hypothesis at a time — write it down before touching anything. |
-| **Prove** | The smallest evidence that the hypothesis IS the cause, not just correlated with it. Where the surface is testable, that's a failing test written per `leo:test-first` — red on the bug, and its assertion names the file:line from Localize. Where nothing is testable (infra, timing, external system), the next-smallest evidence: a log line, a debugger break, a minimal repro script. |
-| **Fix** | The change that makes Prove's evidence pass. Happens at the routed tier (`executor` for mechanical, `implementer` for real changes) — never by the same pass that diagnosed it. |
-
-Reproduce and Localize can compress into one step for a trivial case (a
-crash with a one-frame stack trace pointing straight at the bug) — but
-Hypothesize and Prove never collapse into Fix. If you catch yourself editing
-code before you've written the hypothesis sentence, stop and back up.
-
-## One hypothesis, one change
-
-Test one hypothesis at a time. If Fix doesn't clear Prove's evidence, the
-hypothesis was wrong — REVERT the change before forming the next one. Never
-stack a second speculative edit on top of a first that didn't pan out; you
-lose the ability to tell which change did what, and the diff stops being
-reviewable. Revert, re-enter Hypothesize with what the failed attempt taught
-you, and go again.
-
-## Stuck: the ladder
-
-After two failures on the same cause (two hypotheses tried and reverted, still
-no Prove), step up one tier rather than retrying at the same one — investigator
-explore findings feed a full investigator, and investigator itself steps to a
-second, more evidence-fed pass, capped at Opus. A genuine deadlock, or two
-Opus verdicts on the same cause that disagree → `expert`, announced in one
-line ("escalating to expert: <question>") before it's invoked, never silent.
-Don't loop a third time at the same tier hoping the next guess lands — that's
-the same failure mode as skipping Prove, just slower.
-
-## Diagnosis and fix stay separate
-
-The phase that reaches the verdict (Reproduce through Prove) is read-only
-judge work — no edits, no reverts-of-other-people's-code, just evidence and a
-file:line. Whoever ran that pass hands the hypothesis and its proof to the
-executing tier for Fix. This mirrors why `reviewer` never patches what it
-finds: the same pass that wants to be right about the cause is a bad judge of
-whether it actually is. After Fix lands, `leo:verification` (or a plain
-`reviewer` pass on the diff) is the separate check that the fix is real and
-didn't just make Prove's specific probe go quiet.
-
-## Self-talk to catch
-
-- "It's obviously the timeout" — obvious is not file:line; go Localize it.
-- "Passing now, good enough" — passing isn't Prove; did you write the
-  failing-first check, or did the symptom just stop reproducing?
-- "I'll patch this and see if it helps" — that's skipping Hypothesize; name
-  the mechanism before touching code.
-- "One more tweak on top, I'm close" — that's the stacked-edit trap; revert
-  first.
-- "Third guess this tier, one more won't hurt" — it's the two-failures
-  trigger; escalate instead.
-
-## Works with
-
-`leo:test-first` for writing Prove's failing test. `leo:verification` for
-the post-Fix check. `investigator` runs this loop; `reviewer` judges the
-resulting diff once Fix is applied.

package/skills/delegation/SKILL.md

@@ -1,143 +0,0 @@
----
-name: delegation
-description: >
-  Operational mechanics for dispatching subagents — a single spawn or a large
-  fan-out — the companion to the policy's "Delegate the labor" section.
-  Covers brief construction, model/effort pinning, the four-state return
-  contract, and ledger-backed progress tracking for long multi-agent runs. Use
-  when dispatching any subagent or fan-out. Do not use to choose a task's tier.
-when_to_use: >
-  Any time work is routed to a subagent (explore, investigator, executor,
-  implementer, reviewer, expert) rather than done inline — single dispatch or
-  fan-out. NOT for deciding *which* tier a task belongs in (that's the
-  routing table in the injected leo:using-leo policy); this skill covers what
-  to do once the tier is already chosen.
----
-
-# delegation
-
-Core rule: a subagent gets one shot at the brief and no session history. If
-the brief doesn't stand alone, the dispatch is already broken.
-
-## Writing the brief
-
-Every dispatch is self-contained: goal, constraints, exact file paths, the
-checks to run, and what the return must contain. Write it as if for a
-stranger who will never see this conversation — because that's what a
-subagent is. A brief missing a file path or a check produces a report that
-looks done and isn't.
-
-Bad: "fix the flaky auth test." Good: "`tests/auth/session_test.py::test_expiry`
-fails intermittently (repro: run it 20x, ~1 in 8 fails). Fix the race, keep
-the test's intent unchanged, don't touch other tests in the file. Run
-`pytest tests/auth/session_test.py -x` 20 times clean before reporting done.
-Return: files touched, the race you found, the check output." The second
-version needs no follow-up question; the first invites three.
-
-## Pin model and effort
-
-Every dispatch pins **model AND effort** from the routing table — opus for
-judges (reviewer, investigator), sonnet for normal implementation
-(implementer), haiku for mechanical work (executor). expert
-never appears in a fan-out — one at a time, never fanned. An unpinned call
-silently inherits the session's tier: in an opus session that means every
-executor spawn quietly runs at opus, and a ten-item fan-out burns
-opus-fan-out money for haiku-shaped work. Pin both fields on every spawn, not
-just the ones that "obviously" need it.
-
-## The four-state return contract
-
-A subagent's report must resolve to exactly one of four states. Don't accept
-a report that hedges across two of them.
-
-| State | Means | Your response |
-|---|---|---|
-| `done` | Work finished, matches the brief | Verify against artifacts — see leo:verification — never take the self-report at face value |
-| `concerns` | Finished, but flags something worth a second look | Read the concerns before accepting; they're often the real finding |
-| `needs-context` | Blocked on missing information you can supply | Send the missing piece to the same agent (`SendMessage` on Claude Code, `followup_task` on Codex — elsewhere see the *Follow-up to a live agent* row of your mapping, and where none is established, cold re-dispatch with the context restated is the whole mechanism) so it keeps the context it already built. Either way **once** — a second needs-context on the same gap means the brief itself is broken, escalate the tier |
-| `blocked` | Blocked on something you can't hand over inline | Resolve the blocker, or escalate per the ladder — never a silent same-tier retry |
-
-`needs-context` and `blocked` look similar; the test is whether the missing
-piece is something *you* hold (needs-context — a file path, a decision, a
-credential) or something neither of you can supply without more work
-(blocked — a failing external service, a genuinely ambiguous requirement).
-
-Each role's own prompt carries the state line it must emit, so the contract
-is enforced at both ends. Two roles are deliberately narrowed: `reviewer`
-emits only `done` / `needs-context` (severity already lives in
-`blocking`/`non-blocking`, and the diff's own verdict in
-`approved`/`needs-changes`), and `expert` never emits `blocked` — it is the
-ceiling, so there is nothing left to escalate to. `status` is a separate axis
-from `confidence`: status routes your next move, confidence rates the work.
-
-## Long multi-agent runs: the ledger
-
-A run spanning many dispatches survives context compaction only if progress
-is persisted outside the conversation. Use
-`${CLAUDE_PLUGIN_ROOT}/scripts/state.py` (get / merge / path — flock-guarded,
-atomic writes, keyed per repo) as the ledger, not ad hoc notes in the
-transcript. Each entry: item id, status (one of the four states above, plus
-`pending` / `in-progress`), artifact path (branch name, file, or diff). On
-resume, read the ledger first — anything already `done` or `concerns` is not
-re-dispatched; anything `blocked` is reported, not silently retried.
-
-A ledger entry is small — `{"items": {"<id>": {"status": "done", "artifact":
-"branch:fix/eng-123-slug"}}}` merged via `python3 "${CLAUDE_PLUGIN_ROOT}/scripts/state.py"
-merge <skill-name> <owner/repo> '<patch>'` — but it's the only thing standing between a
-compaction mid-run and forty items silently re-dispatched from item 1.
-Update it after every dispatch resolves, not in a batch at the end: a crash
-between "agent finished" and "ledger written" is exactly the gap this
-exists to close.
-
-`${CLAUDE_PLUGIN_ROOT}` above is the Claude Code spelling of the plugin root,
-and it is substituted into this text only there. Codex exposes `$PLUGIN_ROOT`
-and Cursor `$CURSOR_PLUGIN_ROOT`. Hermes and OpenCode expose no root variable;
-their injected policy substitutes an absolute payload path into the `state.py`
-and `memory.py` commands, which is the discoverable source to reuse. Do not
-invent an environment variable where the harness exposes none.
-
-For a batch of independent, well-scoped fixes, don't hand-roll this loop —
-the reusable workflow at `${CLAUDE_PLUGIN_ROOT}/workflows/cost-tiered-fix.js`
-(Workflow tool, `scriptPath`) already implements plan → tiered execute →
-opus verify with escalation built in, including its own progress tracking.
-Reach for it before writing a bespoke fan-out loop; write the ledger
-approach above only when the run doesn't fit that workflow's shape (e.g. one
-dispatch at a time inside a larger interactive flow, not a clean batch).
-That workflow needs Claude Code's Workflow tool; on every other harness the
-ledger above is the whole mechanism, so use it directly rather than looking
-for a runner that isn't there.
-
-## Parallel dispatch: own your files
-
-Fan-out is safe only when each spawn writes to **disjoint** files — no two
-concurrent dispatches touching the same path. If the work can't be split
-into disjoint file sets (one coherent change that happens to span many
-files, like a single ticket fix), don't fan out — either run it sequentially
-in one dispatch, or give each spawn its own isolated tree via leo:worktrees
-so parallel edits can't collide even when the file sets overlap.
-
-## Self-talk to catch
-
-- "I'll skip pinning effort, model is enough" — no; an unpinned effort on an
-  opus judge still runs at opus prices, at auto effort, which is not what
-  the routing table costed out.
-- "The brief is short, they'll infer the rest" — a subagent infers nothing;
-  it has this brief and nothing else.
-- "It said needs-context, I'll just re-ask the same way" — re-dispatching
-  with the identical brief reproduces the identical gap; either add the
-  missing piece or step up a tier. And prefer messaging the same agent over
-  a fresh spawn: a cold re-dispatch pays again for the context it already
-  built and can rediscover the same gap from a different angle.
-- "Two spawns editing the same file will probably be fine, they touch
-  different functions" — same file is not disjoint; sequence them or
-  isolate with a worktree.
-- "This ten-item fan-out is basically cost-tiered-fix, I'll just write the
-  loop myself" — the workflow already handles escalation and orphan
-  tracking; reinventing it inline drops that for no reason.
-
-## Works with
-
-- leo:verification — how a `done` report gets checked against real
-  artifacts, not trusted as stated.
-- leo:worktrees — file isolation for parallel dispatches that can't be made
-  disjoint by scope alone.

package/skills/executing-plans/SKILL.md

@@ -1,117 +0,0 @@
----
-name: executing-plans
-description: >
-  Checkpoint discipline for carrying out a written plan — batch execution
-  with a check at every batch boundary, plan-intent-wins-on-architecture /
-  reality-wins-on-mechanics arbitration, and one fix-then-re-review cycle
-  before stopping to report. Used by the implementer agent, or the main loop
-  when it executes a plan directly. Use when a written plan is about to become
-  code. Do not use for open-ended work without a plan or for reviewing a diff.
-when_to_use: >
-  A written plan (from planner, an issue, or Leo's own outline) is about to
-  be turned into code. NOT for open-ended implementation with no plan
-  (normal execute-then-review flow) and NOT for the review step itself
-  (the reviewer agent judges the diff; this skill only carries out the plan).
----
-
-# executing-plans
-
-Core rule: a plan is executed in checkpointed batches, never as one long
-uninterrupted run. Each checkpoint is a place execution is allowed to stop
-without having made things worse.
-
-## Before edit one
-
-Sanity-check the plan against the tree it's about to touch:
-
-- Base ref matches what the plan assumed — `git rev-parse HEAD` against the
-  base the plan was written against. Drifted → say so before touching
-  anything; the plan may already be stale.
-- Files/symbols the plan names actually exist at the paths/shapes it
-  describes. A plan step that references a function that moved or a file
-  that's gone is a stop-and-report, not a guess-and-proceed.
-
-This is cheap — a few Read/Grep calls — and skipping it is how a plan
-written against yesterday's tree silently corrupts today's.
-
-## Execute in batches
-
-Break the plan into batches along its own natural seams (usually: one
-plan-step or one cohesive file group per batch). At each batch boundary:
-
-1. Finish the batch's edits.
-2. Run the narrowest relevant checks for what that batch touched — the
-   touched test file, a targeted typecheck, not the full suite every time.
-3. Green → advance to the next batch. Red → stop the batch right there; fix
-   it or report it. Never carry a red check into the next batch hoping it
-   resolves itself — a checkpoint exists precisely to catch this before the
-   failure compounds across three more batches of edits built on top of it.
-
-This is the same shape as leo:delegation's tiering: cheap, frequent checks
-bound the blast radius so the expensive step (review) isn't debugging a
-pile of unrelated regressions.
-
-## Plan intent wins on architecture; reality wins on mechanical detail
-
-Two different kinds of mismatch between plan and tree call for two different
-responses:
-
-- **Mechanical drift** (a renamed variable, a moved file, a slightly
-  different function signature than the plan assumed) — reality wins. Adapt
-  the mechanics silently and keep going; that's normal execution, not a
-  deviation worth flagging.
-- **Architectural disagreement** (the plan's approach doesn't fit the actual
-  structure, a step contradicts how the system actually works, following it
-  as written would build on a wrong premise) — the plan's intent still wins
-  over improvising a fix, but only the plan's author can resolve a real
-  conflict. Stop and report the disagreement; never silently redesign around
-  it. Silent redesign is worse than executing a flawed plan, because it
-  hides the disagreement instead of surfacing it.
-
-When genuinely unsure which kind of mismatch it is, treat it as
-architectural and stop — reporting an unnecessary pause costs a message;
-silently redesigning costs trust.
-
-## Behavior changes still default to test-first, done still means verification
-
-A plan step that changes behavior doesn't get a pass on process because it's
-already written down. Default to leo:test-first for those steps, and treat
-"the plan is implemented" and "the plan is done" as different states — done
-still means the change clears leo:verification, not just that every step got
-executed.
-
-## One fix-then-re-review cycle
-
-Once all batches are in, this hands off to the standard review gate — spawn
-`reviewer` on the actual diff against the recorded base ref,
-with the plan text as the original request. If it comes back with blocking
-findings: fix at the executing tier, then re-review only the fix. That's
-**one fix-then-re-review cycle**, full stop. A second block on the same
-findings means stop the loop and report to Leo with options, expert
-arbitration (the `expert` agent) among them — never a third pass, never quietly
-loosening what counts as blocking to escape the loop.
-
-## Delegation and workspace boundaries
-
-Executing a written plan is `implementer`'s job per leo:delegation — the
-main loop only executes inline when it's already the implementer context or
-the touch is genuinely trivial. If the plan spans a branch of nontrivial
-size, it runs on a dedicated branch per leo:worktrees, and finishing it
-follows leo:finishing-a-branch rather than improvising a merge/cleanup
-sequence at the end.
-
-## Self-talk to catch
-
-- "The plan says step 4, I'll just push through to step 7 before checking
-  anything" — that's skipping checkpoints, not saving time; a break at step
-  5 now costs one batch's rework instead of three.
-- "This isn't quite what the plan says but it's obviously what they meant" —
-  if it's mechanical, fine; if it's architectural, that's the silent
-  redesign this skill exists to block. Report it instead.
-- "The re-review still isn't clean but it's close enough" — close enough on
-  a second block is the definition of stop-and-report, not a third fix.
-
-## Works with
-
-leo:test-first, leo:verification, leo:delegation, leo:worktrees,
-leo:finishing-a-branch — plus the `reviewer` and `expert` agents.

package/skills/finishing-a-branch/SKILL.md

@@ -1,125 +0,0 @@
----
-name: finishing-a-branch
-description: >
-  End-of-branch state machine: what happens once implementation on a
-  branch/worktree is complete. Gates on a clean review verdict, then offers
-  a closed set of next steps — merge / PR / keep / discard — routes the
-  chosen path through the right ordering (land the work before removing the
-  worktree, remove the worktree before deleting the branch), and leaves the
-  repo clean. Use when reviewed implementation on a branch/worktree needs a
-  terminal disposition. Do not use to manage a worktree mid-task or replace
-  the review cycle.
-when_to_use: >
-  A branch or worktree has reached "implementation done" and Leo needs to
-  decide what happens to it. Fires after execute-then-review completes, or
-  when Leo says finish/wrap up/close out/clean up this branch. NOT for
-  starting or managing a worktree mid-task (that's leo:worktrees) and NOT a
-  substitute for the review cycle itself (that's execute-then-review) — this
-  skill starts only once a review verdict already exists.
----
-
-# finishing-a-branch
-
-Core rule: a branch doesn't get disposed of by momentum. It reaches one of
-four terminal states, each chosen explicitly, and destructive ones require
-saying out loud what gets lost.
-
-## Precondition: review verdict, not vibes
-
-Do not enter this skill's decision step without a clean **review verdict**
-on the final diff. "Implementation looks done" is not a review verdict.
-
-- If review hasn't run yet, or the last verdict was `needs-changes`: stop
-  here, go run/finish the review cycle (see execute-then-review), come back.
-- If review is `approved`: proceed.
-- Never offer merge/PR on unreviewed or still-blocked work. "It's a small
-  change" or "I already read through it" does not substitute for the
-  reviewer's verdict — those are exactly the rationalizations this gate
-  exists to block.
-
-## The option set is closed
-
-Once the gate passes, present exactly these four options — never an
-open-ended "what would you like to do next?":
-
-- **merge** — into the target branch, locally or via `gh pr merge`
-- **PR** — open a pull request and stop (no local merge)
-- **keep** — leave the branch/worktree exactly as-is, decide later
-- **discard** — delete the branch and its worktree, work is gone
-
-State the branch name, commit count ahead of the target, and the review
-verdict when you present the set. Leo picks one; do not infer a choice from
-silence, from a prior unrelated "yes," or from tone.
-
-## Ordering (prevents self-referential failures)
-
-Regardless of which path Leo picks, sequence matters — doing this out of
-order breaks the tools that need the worktree or branch to still exist:
-
-1. **cd out of the worktree first.** A shell sitting inside the worktree
-   directory blocks its own removal.
-2. **Merge (or push for a PR) BEFORE removing the worktree.** Land or
-   publish the commits while the worktree still exists to operate from.
-3. **Remove the worktree BEFORE deleting the branch.** Deleting the branch
-   out from under a live worktree leaves the worktree metadata dangling and
-   git in an inconsistent state.
-4. Mechanics of steps 1–3 (which git worktree commands, how to prune) are
-   owned by `leo:worktrees` — call into it rather than hand-rolling worktree
-   surgery here. This skill decides *what* happens and *in what order*;
-   `leo:worktrees` executes *how*.
-
-Per option:
-
-| Option | Sequence |
-|---|---|
-| merge | merge locally or `gh pr merge` → remove worktree (`leo:worktrees`) → delete local branch |
-| PR | push branch → open PR → **stop** (worktree and branch stay; nothing is merged yet.) |
-| keep | do nothing destructive; leave worktree and branch as-is |
-| discard | typed confirmation (below) → remove worktree (`leo:worktrees`) → force-delete branch |
-
-## Destructive paths require a typed confirmation
-
-`discard`, and any force-delete of a branch with unmerged commits, requires
-Leo to type back a confirmation that **names exactly what will be lost** —
-not a plain "yes" or "go ahead". Prompt with the specific string, e.g.:
-
-> Type `discard` to delete branch `feature/foo`, 4 commits, no PR — this
-> cannot be undone.
-
-- An implied or inferred yes never triggers deletion — silence, "sounds
-  good," or approval of some *other* step in the conversation does not
-  count.
-- If Leo's typed text doesn't match what was asked for, ask again; don't
-  guess at intent.
-- `keep` never needs this — it's non-destructive by construction.
-- If the branch is already merged, force-delete is not "destructive" in the
-  data-loss sense (git still warns) — a plain confirmation is enough since
-  nothing unmerged is at risk; use the typed-confirmation form when in doubt.
-
-## Leave the repo clean
-
-After any path except `keep`:
-
-- Prune worktree metadata (`leo:worktrees` handles this as part of removal
-  — don't leave a stale entry in `git worktree list`).
-- Confirm `git status` is clean from the directory you're now in.
-- Note the outcome (merged / PR opened + link / kept / discarded) in the
-  done report per `leo:verification` — the report's job is to make the
-  terminal state legible later, not just at the moment it happened.
-
-## Self-talk to catch
-
-- "The diff was tiny, I basically reviewed it while writing it" — that's
-  not a review verdict; go get one.
-- "Leo said 'sounds good' earlier, close it out" — sounds-good is not a
-  typed confirmation naming what's lost.
-- "I'll just clean up the worktree now and merge after" — wrong order,
-  breaks the merge step; land first.
-- "Discard is obviously right here, I'll skip the prompt to save a round
-  trip" — the option set is closed and explicit for a reason; present it.
-
-## Works with
-
-- `leo:worktrees` — owns worktree creation/removal mechanics.
-- `leo:verification` — owns the shape of the done report this skill feeds
-  its outcome line into.