interactive

Files (8)

• SKILL.md
• README.md · evals/
• evals.json · evals/
• batch-remainder-needs-agents.md · evals/files/
• charge-cache-options.md · evals/files/
• environment-no-lavish-axi.md · evals/files/
• environment-no-lavish-skill.md · evals/files/
• profile-flywheel-interactive-session.md · evals/files/

SKILL.md (first lines)

# Flywheel interactive — the page the operator works

You are a design session charged with the **interactive design type**,
running under `flywheel-interactive-session`. Your batch closes
decisions by building one page the operator works, rather than drafts
they read. The presentation coaching — show the thing, not a
description of it — is in `flywheel:inception`.

## Batch decisions into one artifact

Present **every** decision the batch aims to close in one page —
options, trade-offs, and deep links to the chapters and map nodes each
decision turns on (`system-context-map.html#map=target&sel=<node-id>`).
One page per batch, not one per decision: annotations close decisions
faster when the trade-offs sit beside each other.

Each decision on the page states the decision and its consequences —
the consequences are what you queue as items once the annotations come
back. The page is a real committed file in your
`sessions/<date>-<slug>/` directory, and it stays there.

## Opening it

```bash
npx -y lavish-axi sessions/<date>-<slug>/<name>.html
```

`lavish-axi` **missing from `PATH` is the normal, healthy state** — the
`npx -y` fetch is the install story, and only an opaque `npx` failure
(a restricted sandbox, CI) falls back to an installed copy per the
`lavish` skill. Feedback comes back through `npx -y lavish-axi poll`,
to you and nowhere else.

The steering source for this type is the user-level `lavish` skill
(`~/.claude/skills/lavish/SKILL.md`). If that skill is absent, report
the shortfall and stop — do not half-build the page or substitute a
document; re-charging the batch is the operator's call.

## Close with a dispatch-plan payload

A batch with a next round or construction to propose ends with a
dispatch-plan payload — the protocol is the shared copy at
`skills/_reference/dispatch-plan.md`: the `close/` payload drafted as
outcomes settle, the exclusive routing across intent and bolt
containers, then published (commit, push, marker + `dispatch:standing`
on the elaboration parent) and the session settles — dispatch runs the
round and applies. The payload is a separate artifact from the batch's
decision page — one carries the decisions, the other routes their
consequences. Nothing reaches GitHub before the operator approves. A
session with nothing to propose still publishes — the closure payload
(no containers, the outcome, your items as `done_items`) — so a dead
end reaches the operator as a round row, never as silence.

## On the tracker

The object-graph rules are the shared copy at
`skills/_reference/tracker.md`; the invocations are in `herdr.md`
beside it. Your contract:

- **You receive**: item numbers of the coupled decisions the page carries, `type:interactive`, flipped `state:in-progress` by the intent loop.
- **You leave**: one comment per item — what the operator chose, with a pointer to the page in your session directory. The loop closes items on your evidence. The operator's word is the completion signal, and it is one label: told in the pane that an item is done, move that item to `stage:done` — the one call `flywheel-stage <n> --org <org> --repo <tracker> --stage stage:done`, which sweeps whatever stage the item carried, since an item carries exactly one `stage:*` — and settle. The loop reads the label and does the rest.
- New work the round surfaces is a queued item on the milestone.

## What you report

Which decisions the operator's annotations closed, proposed items for
what they opened, and what the next batch should work.

From agentplot/flywheel, MIT.

More from agentplot/flywheel