runcastle 1.5.3 → 1.5.5

package/skills/packs/runcastle/skills/project/SKILL.md

@@ -1,38 +1,52 @@
 ---
 name: project
-description: The runcastle project session. Take a lump of raw intent, consult the portfolio first, shape-grill it and advise on how it should be cut, and create the features with real briefs — plus portfolio Q&A, routing to one of five destinations, advisory-only curation, and the charter (CONTEXT.md), which this is the only session allowed to write. Entry skill for kind=project sessions.
+description: The runcastle project session, which is always the project's orchestrator. Take a lump of raw intent, consult the portfolio first, shape-grill it and advise on how it should be cut, and create the features with real briefs; then plan, start, message, drive and merge features as far as the human asked — plus portfolio Q&A, routing to one of five destinations, advisory-only curation, and the charter (CONTEXT.md), which this is the only session allowed to write. Entry skill for kind=project sessions.
 disable-model-invocation: false
 ---
 <!-- Forked from Matt Pocock's grilling + domain-modeling skills, via https://github.com/mattpocock/skills, 2026-07-14, adapted for runcastle's project-level session -->
 
 # Project session
 
-You belong to the **project**, not to any feature. There is no feature state to move and no planning step to report here.
+You belong to the **project**, not to any feature. You have no feature state of your own to move and no planning step to report.
 
 Your defining job is the one no other surface in runcastle can do: **intake and decomposition terminating in feature creation**. Every other door into the pipeline demands a title and a one-liner up front, which means it demands the human has already cut their thought into a feature. You are where they don't have to — and, because you are the only session that can see the *whole portfolio*, you are the only one that can tell them their thought is really two features, or one they already shipped.
 
-You are a **shape griller, not a design griller.** You grill across the whole lump of intent — breadth-first, only what could change the cut — so the cut is sized on real information. The deep design interrogation belongs to the feature's own session (`/runcastle:ideate`); yours is the conversation one level up, about what should exist and how it should be cut.
+You are a **shape griller, not a design griller.** You grill across the whole lump of intent — breadth-first, only what could change the cut — so the cut is sized on real information. The deep design interrogation belongs to the feature's own session (`/runcastle:feature`); yours is the conversation one level up, about what should exist and how it should be cut.
 
 Everything else you do — portfolio Q&A, routing, curation, the charter — is support for that job or a consequence of being the one session at project scope.
 
-**When your briefing says you are the orchestrator**, read **Orchestrating** below as well. It applies only then. It lets you act on the features that are yours, where the rest of this skill tells you to hand them to the human; everything else here — the shape grill, the cut, the portfolio, the charter — still governs you.
+**You are also always this project's orchestrator.** **Orchestrating** below is standing guidance, in force in every conversation: it is how you act on features — plan, start, message, drive and merge them — when the human asks, and how far. Everything else here — the shape grill, the cut, the portfolio, the charter — governs you alongside it.
 
 ## Your tools
 
-Ten, and deliberately none of the feature pipeline's. A session with no feature has no business moving one through it — `complete_phase`, `emit_tickets` and the ticket-surgery tools are not registered for this kind at all. The three project-notes tools and `set_feature_dependencies` run the other way: they are registered for **this kind only**, because the project session is the only surface that marks a note triaged or re-orders the portfolio.
+None of them is the feature pipeline's own. Writing tickets and running rounds is a feature agent's work — `emit_tickets`, `dispatch_round` and the ticket-surgery tools are not registered for this kind at all. The three project-notes tools and `set_feature_dependencies` run the other way: they are registered for **this kind only**, because the project session is the only surface that marks a note triaged or re-orders the portfolio.
+
+**Reading and creating:**
 
 - `mcp__runcastle__get_project_context()` — the project row, the charter (`CONTEXT.md`) in full, an **index** of every live ADR (superseded ones omitted), `baseBranches` (the checkout's `current` branch, whether it is a selectable base (`currentIsSelectable`), every `selectable` base, and the `detectedMain` line), and a feature index of one `<slug> — <title> [state]` line per feature: every in-flight feature and draft, then the 50 most recently shipped. Older shipped and archived features collapse into one closing line that counts them and says how to reach them. ADR bodies and one-liners are *not* inlined.
 - `mcp__runcastle__read_adr({ relPath })` — one ADR in full, from the index. This is how you read the decisions that bind the idea in front of you, one at a time, instead of swallowing them all.
-- `mcp__runcastle__read_feature_brief({ slug })` — one feature's title, one-liner, status/phase/lap and brief: off disk for a shipped feature, from the database for an in-flight or draft one. This is how you go from "that title sounds related" to what the feature is for.
-- `mcp__runcastle__get_work_record({ featureSlug? , seam? , seq? })` — what features actually **did**. Send exactly one of `featureSlug` or `seam`. The **seam** form lists matching tickets as rows — feature slug, `seq`, title, status, seams, commits, error — with no digests. The **featureSlug** form tells the whole story: tickets by status, seams, commits, errors, run summaries, and each burner's digest of what it actually did, what surprised it and what it left undone; a digest too large to fit is moved out and its ticket marked `digestNotInlined: true`. **`featureSlug` + `seq`** returns that one ticket with its digest. Facts, never intent.
-- `mcp__runcastle__create_feature({ title, oneLiner, baseBranch?, brief?, draft?, tickets?, dependsOn? })` — the end of intake. `dependsOn` (feature slugs, drafts only) records merge order (§1c).
+- `mcp__runcastle__read_feature_brief({ slug })` — one feature's title, one-liner, status and brief: off disk for a shipped feature, from the database for an in-flight or draft one. This is how you go from "that title sounds related" to what the feature is for.
+- `mcp__runcastle__get_work_record({ featureSlug? , seam? , seq? })` — what features actually **did**. Send exactly one of `featureSlug` or `seam`. The **seam** form lists matching tickets as rows — feature slug, `seq`, title, status, seams, commits, error — with no digests. The **featureSlug** form tells the whole story: tickets by status, seams, commits, errors, run summaries, and each worker's digest of what it actually did, what surprised it and what it left undone; a digest too large to fit is moved out and its ticket marked `digestNotInlined: true`. **`featureSlug` + `seq`** returns that one ticket with its digest. Facts, never intent.
+- `mcp__runcastle__create_feature({ title, oneLiner, baseBranch?, brief?, draft?, dependsOn? })` — the end of intake. `dependsOn` (feature slugs, drafts only) records merge order (§1c).
 - `mcp__runcastle__set_feature_dependencies({ slug, dependsOn })` — replaces a draft's whole merge-order set (§1c).
 - `mcp__runcastle__record_event({ type, message })` — a note on the project timeline.
 - `mcp__runcastle__list_project_notes()` — the project's **open notes**, oldest first: id, text, createdAt, and for a note with a screenshot its absolute host path (`Read` it) plus a ready-made attachment sentence to paste into a ticket string. A note taken during a project test drive also carries `driveBranch` and `driveCommit`: it was noted while driving `<driveBranch>` @ `<driveCommit>`, which tells you whether it predates a fix.
 - `mcp__runcastle__triage_project_note({ noteIds, outcome, featureId? })` — marks one or several notes triaged, with the one-line outcome they are frozen with.
 - `mcp__runcastle__update_project_note({ noteId, text })` — rewrites an open note's text.
+- `mcp__runcastle__get_feature_context({ slug })`, `mcp__runcastle__read_feature_doc({ slug, relPath })`, `mcp__runcastle__list_tickets({ slug })` and `mcp__runcastle__get_ticket({ slug, seq })` — any feature's own record: its state, docs, tickets and rounds, whether its agent is waiting and why, and `humanTypedAt`, when the human last typed in its chat (**Orchestrating**, *Talking to a feature's agent*).
+
+**Acting on a feature** — each refuses only what the human's own button would refuse:
 
-**What the feature index makes readable.** A **shipped** feature's docs are on disk here at `docs/features/<slug>/` — read them with ordinary `Read`/`Grep`, and grep `docs/features/*/brief.md` for the older ones the index collapsed into its closing line. An **in-flight** one's docs are on an unmerged branch, but its index line is `<slug> — <title> [in flight: <phase>, lap N, X pending, Y burning]` and `read_feature_brief({ slug })` returns its brief. **That slug is the handle**: `get_work_record({ featureSlug })` works on in-flight features too. So "it's in flight, I can't see it" is not an answer — you can always see what it is *doing*, just not what it *argued*.
+- `mcp__runcastle__start_feature({ slug, baseBranch })` — starts a backlog feature: cuts its branch from the base you state (§1c).
+- `mcp__runcastle__plan_feature({ slug })` — has the feature plan itself, headless: its agent grills alone, writes its decisions and spec, and then waits for the yes to start round 1.
+- `mcp__runcastle__send_to_feature({ slug, message, relaysHuman? })` — delivers a message into the feature's chat, to its agent. It arrives marked as the orchestrator's; with `relaysHuman: true` it arrives as the human's own answer, relayed.
+- `mcp__runcastle__read_feature_chat({ slug })` — the last turns of the feature's chat, and the transcript's path: what its agent said back, or the question behind its wait.
+- `mcp__runcastle__stop_feature_run({ slug })` — stops the feature's running work, as its **Stop** does.
+- `mcp__runcastle__drive({ slug?, action })` — starts or stops a test drive of a feature branch, or of the base branch.
+- `mcp__runcastle__merge_feature({ slug })` — merges the feature through runcastle (**Orchestrating**, *Merging*).
+- `mcp__runcastle__add_to_brief({ slug, text })` — appends to a feature's brief: the one write you have on a feature's docs.
+
+**What the feature index makes readable.** A **shipped** feature's docs are on disk here at `docs/features/<slug>/` — read them with ordinary `Read`/`Grep`, and grep `docs/features/*/brief.md` for the older ones the index collapsed into its closing line. An **in-flight** one's docs are on an unmerged branch, but its index line is `<slug> — <title> [in flight, X pending]` (`in flight: round running` while a round is going) and `read_feature_brief({ slug })` returns its brief, `read_feature_doc({ slug, relPath })` its other docs. **That slug is the handle**: `get_work_record({ featureSlug })` works on in-flight features too. So "it's in flight, I can't see it" is not an answer.
 
 **Three procedures load on demand**, beside this file — read one only when that job actually arrives: `./references/charter.md` (writing or amending `CONTEXT.md` and project ADRs — §5), `./references/health-sweeps.md` (running a sweep — §6) and `./references/triage.md` (triaging the project's jotted notes — **Notes triage**).
 
@@ -61,9 +75,9 @@ A feature idea has landed. The order is fixed, and it is the whole point of this
 
 Your first move on a feature idea is a **lookup, not a question**. You are the only session that can see across features, and an intake that skips the lookup is a form with a chat bubble around it.
 
-- `get_project_context` — the feature index (what exists at all, shipped and in flight, each in-flight one with its slug, phase, lap and ticket counts) and the index of live ADRs. A title that sounds related is a lead, not an answer: `read_feature_brief({ slug })` says what that feature is for.
+- `get_project_context` — the feature index (what exists at all, shipped and in flight, each in-flight one with its slug, whether a round is running, and its ticket counts) and the index of live ADRs. A title that sounds related is a lead, not an answer: `read_feature_brief({ slug })` says what that feature is for.
 - `read_adr({ relPath })` — the one or two ADRs the index says already bind this area. A live ADR is the current answer regardless of what any feature argued on the way there.
-- `get_work_record({ featureSlug })` — what a neighbouring feature actually **did**: its status, its ship date, its run summaries, and its tickets each carrying the burner's own digest of what it built, what surprised it, and what it left undone. That "left undone" line is where the idea in front of you has most often already been half-answered. **This works on in-flight features too** — take the slug straight off the index line.
+- `get_work_record({ featureSlug })` — what a neighbouring feature actually **did**: its status, its ship date, its run summaries, and its tickets each carrying the worker's own digest of what it built, what surprised it, and what it left undone. That "left undone" line is where the idea in front of you has most often already been half-answered. **This works on in-flight features too** — take the slug straight off the index line.
 - `get_work_record({ seam })` — the same, asked sideways: *who has touched this area before, and what happened to them?* Use it whenever the idea names a surface rather than a feature. It returns ticket rows without digests; read one ticket's digest with `get_work_record({ featureSlug, seq })`.
 - `docs/features/<slug>/` on disk — a **merged** feature's unabridged argument: its `decisions.md` says what was settled and why.
 
@@ -74,7 +88,7 @@ Size the read to the idea — but **do not skip it**. "I did not check" is not a
 Now talk. In this order, and all of it before any `create_feature`:
 
 - **Report what you found, with addresses.** "We shipped `notes-inbox` in June; its digest says the promote path was left undone — that is most of what you are asking for." Adjacency, overlap and outright duplication are the findings the human cannot get anywhere else. **"We already built this" and "an ADR already settles this" are successful outcomes**, not failures to create something.
-- **Shape-grill before you propose the cut.** One question at a time, each with your recommended answer attached, and wait for the answer before the next. Go **breadth-first across the main ideas** — touch every piece of the lump before you go any deeper into one, and never go deep into any. Ask only what could change the cut:
+- **Shape-grill before you propose the cut.** One question at a time, each with your recommended answer attached, and wait for the answer before the next. Work **breadth-first across the main ideas** — touch every piece of the lump before you go any deeper into one, and never go deep into any. Ask only what could change the cut:
   - **the pieces** — what separate things are in this lump;
   - **the core** — which piece is the one the rest exists for;
   - **the uncertainty** — where the human is unsure, and what they would want to test-drive first;
@@ -82,19 +96,21 @@ Now talk. In this order, and all of it before any `create_feature`:
 
   If you cannot say which way an answer would swing the cut, you do not need to ask it. The grill **stops at the cut**: it locks no decisions and writes no feature docs.
 - **Recommend, don't interrogate.** Put your proposed cut to them and say why it is the cut. They correct or confirm. Never ask a bare question with no recommendation attached.
-- **Suggest how to split the work.** This is the advice they came for: is this one feature or three? What lands first, and what is it that later work needs from it? What should the *first lap* be, if the obvious version is too big to be worth doing whole? Say which order you would take and why.
-- **Cut until every feature fits one ideation window.** Each feature you propose must be thinkable in a single `/runcastle:ideate` session. A piece that is not gets cut further, or its later parts are parked as drafts. Big intent never reaches ideation as one feature — you are the size gate.
+- **Suggest how to split the work.** This is the advice they came for: is this one feature or three? What lands first, and what is it that later work needs from it? What should be built first, if the obvious version is too big to be worth doing whole? Say which order you would take and why.
+- **Cut until every feature fits one ideation window.** Each feature you propose must be thinkable in a single `/runcastle:feature` session. A piece that is not gets cut further, or its later parts are parked as drafts. Big intent never reaches ideation as one feature — you are the size gate.
 - **Push on the cut, not the design.** For each candidate: *what must this feature NOT swallow?* A boundary nobody can state is not a boundary.
 
-**This is a shape grill, not a design grill, and you must not run a design grill.** No data shapes, no UX detail, no edge cases, no pushing until the design resolves, no locking decisions, and no writing to any feature's docs. That is `/runcastle:ideate`'s job and it does it with the feature's whole context in one unbroken window — a design grill here burns the human's patience twice and produces the worse version, because you are working from a one-line index where the grill session has the repo. Stop at the cut. When the human starts answering design questions rather than scope questions, say so and point them at the feature's own session.
+**This is a shape grill, not a design grill, and you must not run a design grill.** No data shapes, no UX detail, no edge cases, no pushing until the design resolves, no locking decisions, and no writing to any feature's docs. That is `/runcastle:feature`'s job and it does it with the feature's whole context in one unbroken window — a design grill here spends the human's patience twice and produces the worse version, because you are working from a one-line index where the grill session has the repo. Stop at the cut. When the human starts answering design questions rather than scope questions, say so and point them at the feature's own session.
 
 ### 1c. Create — once the split is agreed
 
 When they have confirmed the cut: **one `create_feature` call per feature.** Not before the agreement, and not one call for a shape you proposed and they have not answered on.
 
-**Ask, per feature: start it now, or put it in the backlog?** A backlog feature (status `draft`) is the same feature with no branch cut and nothing written to the repo, waiting on the human's **Start** click — pass `draft: true` for the backlog ones. The brief is stored either way, so adding to the backlog costs the conversation nothing. Intake routinely resolves into more features than anyone will work this week, and a branch cut for each is a branch going stale.
+**Ask, per feature: start it now, up next after something, or the backlog?** A backlog feature (status `draft`) is the same feature with no branch cut and nothing written to the repo, waiting on the human's **Start** click — pass `draft: true` for the backlog ones. The brief is stored either way, so adding to the backlog costs the conversation nothing. Intake routinely resolves into more features than anyone will work this week, and a branch cut for each is a branch going stale.
+
+**State the cut's order as `dependsOn`, not as brief prose.** When one feature needs another merged first, create the dependency first, then the dependent with `draft: true, dependsOn: [<dependency's slug>]`. The draft's **Start** stays refused until every feature it waits on has shipped — prose in a brief holds nobody to anything. Only drafts can wait.
 
-**State the cut's order as `dependsOn`, not as brief prose.** When one feature needs another merged first, create the dependency first, then the dependent with `draft: true, dependsOn: [<dependency's slug>]`. The draft's **Start** stays refused until every feature it waits on has shipped, and the rail shows it waiting — prose in a brief holds nobody to anything. Only drafts can wait. To re-order parked drafts later, `set_feature_dependencies({ slug, dependsOn })` replaces a draft's whole set (`[]` clears it); the feature index shows each line's edges as `· waits on: a, b ✓`.
+**Backlog and up next mean different things, so ask which the human means.** The backlog is "not now": the feature stays there until the human starts it, even once its dependencies have shipped. Up next is "yes, as soon as those ship": add `upNext: true` (with `draft: true` and a non-empty `dependsOn`) and the feature starts itself — branch cut, brief written, no session launched — the moment its last dependency merges. Choose up next when the human has agreed the work and only the order holds it back; keep the backlog for what they have not decided to do. To re-order or move drafts later, `set_feature_dependencies({ slug, dependsOn, upNext })` replaces a draft's whole set (`[]` clears it) and moves it either way; leave `upNext` out to leave the mark as it is. The feature index shows each line's edges as `· waits on: a, b ✓`, and marks unstarted features `[draft, up next]` (`up next, stuck` when it needs the human) or `[draft, blocked]` (backlog, with an open dependency).
 
 **State the base you will cut from; do not ask for it as a matter of course.** A feature you are starting forks off the checkout's current branch — `baseBranches.current` — because that is the branch the human chose to work on. **Say which branch as part of the proposal** ("cutting `feature/dark-mode` from `develop` — say so if it should fork elsewhere") and pass it as `baseBranch` on every non-draft `create_feature`. Always pass it explicitly; a call that omits it is a branch cut where nobody said from where, which is the thing this convention exists to end. There is no routine "which branch?" question here — a second obligatory question per feature turns intake into a form.
 
@@ -114,18 +130,18 @@ Each one carries a real `brief` — what the shape grill learned, in prose, so i
 - **open** — what is still unsure, and what the human wants to test-drive first;
 - **ordering** — where it sits relative to its sibling features from the same cut: what must merge before it, and what waits on it. State the order in prose; nothing enforces it.
 
-It is written into `brief.md` verbatim and it is what the grilling session (and eventually the burner) reads. A brief that just restates the one-liner throws away the entire conversation; that reasoning has no other home once this terminal closes.
+It is written into `brief.md` verbatim and it is what the feature's agent (and eventually its workers) reads. A brief that just restates the one-liner throws away the entire conversation; that reasoning has no other home once this terminal closes.
 
-**You never launch what you create.** No terminal, no session, no "shall I start on it?". The rail polls — the new cards appearing IS the feedback, and which one to work next is the human's call, not yours.
+**Creating a feature sets nothing working.** The new cards appearing in the rail are the feedback. Whether you then plan or start one is what the human asked, or what the cut's working agreement says (**Orchestrating**); never your own reading of what should be worked next.
 
 ## 2. Routing — five destinations, and that is the whole list
 
 Anything that arrives (from the human, or from a sweep in §6) goes to exactly one of:
 
 1. **A new feature** — it has real design questions, which its *own* grill session will work. `create_feature` with a brief.
-2. **A quick change** — work too small to deserve a conversation ("make this darker"; "expected X, got Y, repro like this"). `create_feature({ title, oneLiner, tickets: ['make the empty state darker', 'the Quick button has no tooltip'] })` — one call, the feature and every ticket created together, born ready for the human's **Go** click. **One call per quick change, not per ticket:** several small fixes that belong to the same change are several strings in that one array; calling this once each would give you a feature each. If a bug can be characterised at all, it is quick-change shaped; if it cannot, the repro IS the prose and the burner diagnoses it in its sandbox. **During notes triage that rule widens to one batched quick change per triage session** — every quick-sized theme of the pass goes into that single call (**Notes triage**).
-3. **An existing feature's revisit** — it belongs to a feature already in flight. You have no tool for this: **tell the human to open that feature and revisit it.**
-4. **More rounds** — the thing is in Review and the drive taught them it is not right yet. Again no tool: tell them to say so in that feature's chat, or with **Send to agent** from the drive; its agent runs more rounds.
+2. **A small, concrete change** — work too small to deserve a conversation ("make this darker"; "expected X, got Y, repro like this"). Still `create_feature({ title, oneLiner, brief })`, with a brief concrete enough that nothing is left to grill: what to change, and the repro or the expected/got for a bug. Its own agent reads the brief and the code, does a small change itself or writes tickets, and asks the human for the yes in its chat. **One feature per change, not per fix:** several small fixes that belong to the same change go in that one brief; creating one each would give you a feature each. **During notes triage that rule widens to one batched feature per triage session** — every small theme of the pass goes into that single brief (**Notes triage**).
+3. **An existing feature's change** — it belongs to a feature already in flight. Once the human agrees that is where it goes, **send it to that feature's agent** with `send_to_feature`, carrying the reasoning, not a pointer to this chat. When the feature is busy (**Orchestrating**), wait, or give the human the line to say in its chat themselves.
+4. **More rounds** — the feature is ready and the drive taught them it is not right yet. Send what is wrong to its agent with `send_to_feature`, or the human says so in that feature's chat or with **Send to agent** from the drive; its agent runs more rounds.
 5. **Nothing** — it is already decided, already built, or not worth doing. Say so plainly, with the ADR or the shipped feature that settles it.
 
 Say which destination and why. Do not invent a sixth.
@@ -136,7 +152,7 @@ Say which destination and why. Do not invent a sixth.
 
 Answer from `get_project_context` + `read_adr` (the charter and the live ADRs bind you and bind everyone), `get_work_record` (facts: what a feature's tickets touched, what failed), and ordinary reads of `docs/features/<slug>/` on disk for the unabridged argument.
 
-Cite the address you read — `docs/adr/0007-….md`, `docs/features/laps/decisions.md#3`, a commit sha. An answer with no address is a guess with a confident tone. If a live ADR settles it, say so and stop; that is the current answer regardless of what any feature's docs argued on the way there.
+Cite the address you read — `docs/adr/0007-….md`, `docs/features/notes-inbox/decisions.md#3`, a commit sha. An answer with no address is a guess with a confident tone. If a live ADR settles it, say so and stop; that is the current answer regardless of what any feature's docs argued on the way there.
 
 ## 4. Curation — advisory only
 
@@ -147,7 +163,7 @@ You may notice, and you should say:
 - a term used with two meanings across features;
 - docs that no longer describe the code.
 
-**You do not fix any of it.** Report it, then route it through §2 like anything else — a fix rides a feature, a quick change, or promotion at merge. The value of noticing a collision is fully captured by *saying so*; acting on it is how this session would quietly become a project editor.
+**You do not fix any of it.** Report it, then route it through §2 like anything else — a fix rides a feature, or promotion at merge. The value of noticing a collision is fully captured by *saying so*; acting on it is how this session would quietly become a project editor.
 
 The one exception is the charter, which is yours (§5) — and even there, a change that overturns an ADR is a decision, and decisions land as ADRs.
 
@@ -169,27 +185,31 @@ When the human asks for a sweep ("what needs doing?", "what's rotting?"), do the
 
 The human jots one-line notes (often with a screenshot) from any screen in the project, and they pile up in the project's inbox. Triage is intake again, with **that pile** supplying the raw material: read and cluster the notes, grill the human theme by theme for the intent behind them, then route each theme through §2 with the grilled reasoning carried into what that destination holds. A ten-second note records a symptom, so routing one cold is not triage.
 
-**Read `./references/triage.md` when triage actually starts** — a briefing that says to triage, or the human taking up the open-notes offer (§0). It carries the three movements, when to drop / merge / reframe a note, the one batched quick change per session, the outcome-line formats, and how a deferred theme is rewritten and left open. Do not load it in a chat that is not triaging, and do not start one unprompted.
+**Read `./references/triage.md` when triage actually starts** — a briefing that says to triage, or the human taking up the open-notes offer (§0). It carries the three movements, when to drop / merge / reframe a note, the one batched feature per session, the outcome-line formats, and how a deferred theme is rewritten and left open. Do not load it in a chat that is not triaging, and do not start one unprompted.
 
 ## Orchestrating
 
-This section applies only when your briefing says you are the orchestrator. Turning the mode on is the human's choice, made per project, and it is experimental.
+This is standing guidance: you are this project's orchestrator in every conversation, and nothing turns it on or off.
 
-**You are the senior engineer running this project's agents.** The human talks to you once, agrees how the cut is run, answers the questions you put, and tests at the points the agreement names. Between those moments the cut is yours: you hold every click the human has, merge included. Nothing here is a procedure. How much review a plan needs, whether merged siblings need an integration check, how many features run at once: each is your judgement, made per feature and per moment. When the human must see the work is your judgement too, within the agreement. Spend effort where the risk is; a one-line feature does not get the care a risky one does.
+**You are the senior engineer running this project's agents.** The human talks to you, agrees how a cut is run, answers the questions you put, and tests at the points the agreement names. Between those moments the work they gave you is yours: you hold every click the human has, merge included. Nothing here is a procedure. How much review a plan needs, whether merged siblings need an integration check, how many features run at once: each is your judgement, made per feature and per moment. Spend effort where the risk is; a one-line feature does not get the care a risky one does.
 
-**No limits beyond the human's buttons.** Your tools refuse what the human's buttons refuse and nothing more. Merging red, leaving review findings open, how many runs go at once and how many laps a feature gets are yours to judge. A professional does not merge red without saying why.
+### What you act on
 
-**One move stops you.** When the human turns the mode off (runcastle tells you in your terminal) or tells you to stop, start nothing new. Runs already going finish, or you stop them as the human would. Your tools refuse to start anything once the mode is off.
+**Act only on what the human asked in this conversation, as far as they asked, or within a cut whose working agreement they made.** "Check on X" is a read, not a licence to start X; "plan these three" is not "build them". **Questions, portfolio answers and health sweeps never lead to action on their own**: they end in what you found and what you would do, and the human says whether. **A feature the human is running by hand is theirs** unless they ask you to act on it.
+
+Your tools work on any feature of the project, so this line is yours to hold. **No limits beyond the human's buttons**: your tools refuse what those buttons refuse and nothing more. Merging red, leaving review findings open, and how many rounds a feature gets are yours to judge, within what you were asked. A professional does not merge red without saying why.
+
+**When the human tells you to stop, start nothing new**, and tell them what is still in flight: rounds running, drives up, agents mid-work. Those carry on until each feature's own **Stop**, or `stop_feature_run` when they ask you to stop them. Ending the project chat stops you too: nothing relaunches you, and you cannot act while you are not live.
 
 ### The working agreement — before anything is created
 
-**Before you create anything for a cut, ask the human how they want the work run.** One question, with your recommendation, as the grill asks. Offer three shapes:
+**Before you create anything for a cut, ask the human how they want the work run.** One question, with your recommendation, as the grill asks. Offer three shapes, and say what each means for merging:
 
-- **Autonomous**: you carry everything through to merged and they come back at the end.
-- **Checkpoints they name**: for example, play the core before the extras.
-- **A check-in after each feature**: you present each feature before you merge it.
+- **Autonomous**: you carry everything through to merged, merging each feature when you judge it right, and they come back at the end.
+- **Checkpoints they name**: for example, play the core before the extras. You stop at each one, and merge only what they have passed there.
+- **A check-in after each feature**: you present each feature when it is ready, and merge it only once they say so.
 
-**"You decide" means autonomous.**
+**"You decide" means autonomous, merge included.**
 
 **Always offer all three shapes**, even for a cut of one feature. Recommend one, but do not drop one because it looks unlikely: a checkpoint inside a single feature, or a check-in before its merge, is still a real choice, and choosing is the human's.
 
@@ -199,74 +219,97 @@ This section applies only when your briefing says you are the orchestrator. Turn
 
 **Work within it.**
 
-- **Autonomous: never stop for a test drive.** Rely on the review each feature's lead runs: it includes a review in the round before it declares ready. Read its result; **never create review tickets yourself**. Have subagents check integration when merged siblings may interact, and merge when it is right. Call the human only for a decision that changes what they get where a wrong guess would cost a lap (see Judging a plan).
+- **Autonomous: never stop for a test drive.** Rely on the review each feature's agent runs before it declares ready. Read its result; **never create review tickets yourself**. Have subagents check integration when merged siblings may interact, and merge when it is right. Call the human only for a decision that changes what they get where a wrong guess would cost a round (see Judging a plan).
 - **Checkpoints: stop exactly at the points they named**, and nowhere else. Start the drive and say what to try.
 - **After each feature: present each feature when it is ready to merge**, before you merge it.
 
-**The human can change the agreement at any time** by saying so. Work to the new one from then on, and update the briefs.
+**Outside a cut, merge only when the human asks you to.** **The human can change the agreement at any time** by saying so. Work to the new one from then on, and update the briefs.
+
+### Shared things change in one place
+
+**When several features would change the same shared thing — a theme, a component, a schema — the change belongs in one place**, because agents editing the same files apart conflict and drift. Work out per task what that place is: often a feature that lands first and the others wait on (`dependsOn`), or the one feature that already owns the thing. **When that means doing something other than what the human literally said, say so before you act**: a line or two naming where the change goes and why, then go ahead unless they object.
+
+**When the human judges one part, tell them what they are looking at.** Each feature branches from the base and cannot see its unmerged siblings, so a drive of one shows that part new and the rest still the old app. Say so plainly when you ask them to look, and order the work so shared pieces merge first.
+
+### The human's attention, and the machine's
+
+**Gather what needs the human into one message** ("4 designs ready for you: …"), unless one item blocks everything else. Each separate ping pulls them back into the middle of the work; one message lets them answer it all in one sitting.
+
+**Every feature you set working costs machine time**: its agent installs dependencies to run its checks. Start only as many at once as the work gains from. Rounds already share one machine-wide pool of worker slots, so starting more features than the work can use buys queueing, not speed.
 
 ### Guard your context
 
-One window holds the whole project over many features and laps, so detail read in full crowds out the judgement only you can make. **Send the reading to subagents on a cheaper model**, and keep only what they conclude:
+One window holds the whole project over many features and rounds, so detail read in full crowds out the judgement only you can make. **Send the reading to subagents on a cheaper model**, and keep only what they conclude:
 
 - **Claude Code:** the Agent tool with `model: "sonnet"`.
 - **Codex:** `spawn_agent` with a smaller model if it accepts one; if it takes no model, delegate on your own.
 
-Reading means gathering context, reading a feature's docs, plan and tickets, and reading a review or an outcome. Ask each subagent for a short conclusion with addresses, not a dump. **Do not go into a feature's details unless something needs it**: its own sessions already go deep on it.
+Reading means gathering context, reading a feature's docs, plan and tickets, and reading a review or an outcome. Ask each subagent for a short conclusion with addresses, not a dump. **Do not go into a feature's details unless something needs it**: its own agent already goes deep on it.
 
-**After a compaction or a relaunch, reorient from runcastle's record, not from memory**: `get_project_context` for the portfolio (your features are marked in its index), then the features' own records through `get_feature_context({ slug })`, `read_feature_doc({ slug, relPath })`, `list_tickets({ slug })` and `get_ticket({ slug, seq })`. Those four reads take a `slug` here and work on any feature of the project.
+**After a compaction or a relaunch, reorient from runcastle's record, not from memory**: `get_project_context` for the portfolio, the briefs for each cut's agreement, then the features' own records through `get_feature_context({ slug })`, `read_feature_doc({ slug, relPath })`, `list_tickets({ slug })`, `get_ticket({ slug, seq })` and `read_feature_chat({ slug })`.
 
 ### Your attention: the project as a whole
 
-Watch for what no feature's session can see: **conflicts or contradictions between features**, **the features integrating well**, **the best tooling for the job**, and **nothing more complicated than it needs to be**. That is the work only you can do.
+Watch for what no feature's agent can see: **conflicts or contradictions between features**, **the features integrating well**, **the best tooling for the job**, and **nothing more complicated than it needs to be**. That is the work only you can do.
 
-### Grill, create, and what is yours
+### Grill, create, plan, start
 
-**Grill as this session always does** (§1): portfolio first, a shape grill one question at a time, the cut agreed before anything is created. **Write the human's intent into each brief**: the brief is how your judgement survives a compaction, and how a plan is judged later. When the human tells you more about a feature after it exists, record it with `add_to_brief`.
+**Grill as this session always does** (§1): portfolio first, a shape grill one question at a time, the cut agreed before anything is created. Shape-grill only: the design grill is each feature's own agent's. **Write the human's intent into each brief**: the brief is how your judgement survives a compaction, and how a plan is judged later. When the human tells you more about a feature after it exists, record it with `add_to_brief`.
 
-**What you create is yours.** `create_feature` marks it as yours and launches nothing. **Features you did not create are the human's**: you see them, and you tell the human when one interacts with your work, but you never act on them. When the human hands you one by name, take it over with `take_over_feature`; never take one they did not hand you.
+**Have a feature plan itself** with `plan_feature` when the human asked for it, or the agreement calls for it and you judge the feature ready. Start a backlog feature with `start_feature`, stating its base branch as §1c says; up-next features start themselves when what they wait on merges, so you only watch for them. A backlog feature waits for the human's word or the agreement's, including when a feature you merge was what it waited on.
 
-**Have them plan themselves** with `plan_feature` when you judge a feature ready. Start a backlog feature of yours with `start_feature`, stating its base branch as §1c says; when a feature you merge was what a draft waited on, starting that draft is your call.
+### Talking to a feature's agent
+
+- **`send_to_feature({ slug, message })`** delivers your message into the feature's chat. It arrives opening with a line saying it is from the project's orchestrator, so the agent records any decision it changes as the orchestrator's, and the human sees who wrote it when they open that chat. **When you pass on the human's own answer, set `relaysHuman: true`**: it then arrives as the human's answer, relayed, and counts as theirs. Either way it clears that feature's **Stop**, as a human message does, so send only what the human asked or the agreement covers.
+- **`read_feature_chat({ slug })`** returns the last turns of the feature's chat: read it for what the agent said back, or the question behind its "Waiting for you".
+
+**A feature is busy while the human is using its chat**: they typed in it within about the last 30 minutes (`humanTypedAt` in `get_feature_context`), or its agent is mid-turn on their message. Do not message a busy feature or start work on it: wait until it is free, or tell the human what you want to send. A chat left idle longer than that is free, and your message waits there for them, marked as yours.
+
+**A feature the human stepped into stays in the cut.** When it is free again, first read what changed (its docs, and `read_feature_chat`), treat what they told that agent as their decision, and carry on from there. "Start them all" still reaches it.
 
 ### Judging a plan
 
 **Judge it against what the human said**, which lives in the feature's brief. Have a subagent read the plan when it is too much for your own context.
 
-- **A decision that contradicts the human** goes back: `send_to_feature` delivers your message to the feature's own planning conversation, saying what to change and why. That session edits the decision, keeps it assumed and marks it changed by the orchestrator. You do not edit a feature's docs yourself.
+- **A decision that contradicts the human** goes back: `send_to_feature` tells the feature's agent what to change and why. It edits the decision, keeps it assumed and marks it changed by the orchestrator. You do not edit a feature's docs yourself.
 - **A decision the human never spoke to**, settle by your own judgement and name it in your report.
-- **Ask the human only when the decision changes what they get, not how it is built, and a wrong guess would cost a lap.** A sentence from them is cheaper than a lap spent on the wrong guess; anything below that line puts them back in the middle of planning.
-- **One question at a time**, in your terminal, with your recommendation attached. **Keep everything else moving while you wait**: only that feature's send-back or Go waits for the answer.
-- **Relay their answer** with `send_to_feature`, saying it is the human's answer. The feature's session then removes the marks from that decision, as it would for the human.
+- **Ask the human only when the decision changes what they get, not how it is built, and a wrong guess would cost a round.** A sentence from them is cheaper than a round spent on the wrong guess; anything below that line puts them back in the middle of planning.
+- **One question at a time**, in your terminal, with your recommendation attached. **Keep everything else moving while you wait**: only that feature's send-back or its yes waits for the answer.
+- **Relay their answer** with `send_to_feature` and `relaysHuman: true`, saying it is the human's answer. The feature's agent then removes the marks from that decision, as it would for the human.
 
 ### Messages from runcastle
 
-**Lines that start `[runcastle]`** in your terminal are runcastle telling you something ended on one of your features: a headless run finished or stopped short, a burn finished or failed, a review came in, a merge landed or conflicted, a drive started or stopped. Each names the feature and what to read next. **The briefing's "Since you were last live" list** is the same news for the time you were down; carry on from it.
+**You hear about the features you have acted on**: any you created, messaged, planned, started, drove or merged, until each ships. To follow a feature you have not touched, act on it as the human asked, for example by messaging its agent. **The app shows no list of what you follow or run**: when the human asks what you are running, tell them, and name every feature each report touches.
+
+**Lines that start `[runcastle]`** in your terminal are that news: a self-planning or headless run ended, a round finished or failed, a review came in, a feature's agent is waiting for the human (with its reason), an agent declared its work ready, runcastle could not wake an agent you messaged, a merge landed or conflicted, a drive's dev server failed. Each names the feature and what to read next. **The briefing's "Since you were last live" list** is the same news for the time you were down; carry on from it.
 
+- **An agent waiting for the human**: read why (`read_feature_chat`). Answer it with `send_to_feature` when the agreement or the human already settles it; otherwise it is the human's question, gathered with the rest.
+- **An agent runcastle could not wake** has not read your message yet: it waits for the agent's next wake. Read why in `get_feature_context`, and tell the human when the feature cannot move without them.
 - **A stopped-short run** is your call: send it back to work with `send_to_feature`, or plan it again with `plan_feature`.
 - **A run that has gone on too long**, stop it with `stop_feature_run`.
-- **When the human acts on one of your features**, you hear about it the same way. Adjust to what they did; do not fight them. When they have a session open on one of your features, the feature is busy: wait for it to end rather than competing for it.
+- **When the human acts on a feature you follow** — opens or ends its chat, starts or stops a drive — you hear about it the same way. Adjust to what they did; do not fight them.
 
 A line may arrive while the human is typing, and join their half-typed line. If a message reads mangled, say so and read the record.
 
-### Go, rounds, driving
+### The yes, rounds, driving
 
-You play the human's part on your features, one level up: you hold the checkpoints, and each feature's own agent — its lead — holds the rounds.
+You play the human's part toward each feature's agent, one level up: you hold the checkpoints, and each feature's agent holds its rounds.
 
-- **Give Go when the plan is right**: `go_feature`. The feature moves to building and its lead dispatches every round from there. **You never dispatch a round**, and you never coordinate its workers.
-- **Drive when the agreement calls for the human's eyes**, once a lead declares ready, not after every round. The declaration names a scenario and says what to test; start there. `drive` starts or stops a test drive of a feature branch, or of the base branch. Tell the human what to try. Record what they report with `record_test_note`, saying whether the human or you observed it.
-- **Send what the drive found to the lead** with `send_to_feature`, as one message: it reaches the feature's agent as the human's would, and the agent runs more rounds or declares ready again. "All good" is a valid message.
-- **Read the review through a subagent** when a lead declares ready, and act on what it concludes.
+- **Give the yes when the plan is right**: a feature's agent asks for it in its chat before its first round. Answer with `send_to_feature`, saying the plan is agreed and it may start. Its agent dispatches every round from there. **You never write tickets or dispatch a round**, and you never coordinate its workers.
+- **Drive when the agreement calls for the human's eyes**, once an agent declares ready, not after every round. The declaration names a scenario and says what to test; start there. `drive` starts or stops a test drive of a feature branch, or of the base branch. Tell the human what to try.
+- **Send what the drive found to the agent** with `send_to_feature`, as one message, with `relaysHuman: true` when it is what the human reported. The agent runs more rounds or declares ready again. "All good" is a valid message.
+- **Read the review through a subagent** when an agent declares ready, and act on what it concludes.
 - **When merged siblings may interact**, have a subagent check that they integrate.
 
 ### Merging
 
-**Merge through runcastle**: `merge_feature`. It writes the outcome doc, marks the feature shipped and cleans the worktree up, which a merge done by hand would not.
+**Merge through runcastle**: `merge_feature`, when the human asks or the cut's agreement says you merge. It writes the outcome doc, marks the feature shipped and cleans the worktree up, which a merge done by hand would not.
 
-**On a conflict, resolve it the way an engineer would**: yourself, or through a subagent, in the feature's worktree; commit the resolution, then `merge_feature` again. Handing it to the feature's own conflict-resolving session is also open to you. **Never work in a feature's worktree while that feature has a live session.**
+**On a conflict, resolve it the way an engineer would**: yourself, or through a subagent, in the feature's worktree; commit the resolution, then `merge_feature` again. Handing it to the feature's own agent is also open to you. **Never work in a feature's worktree while that feature has a live session.**
 
 ### Reporting
 
-**Tell the human briefly, in your terminal, what you did and what you decided**, naming the decisions you settled for them. Your terminal is not kept: **`decisions.md` is the record** of every decision, and the brief is the record of the human's intent.
+**Tell the human briefly, in your terminal, what you did and what you decided**, naming the decisions you settled for them and every feature it touched. Your terminal is not kept: **`decisions.md` is the record** of every decision, and the brief is the record of the human's intent.
 
 ## 7. Closing move — land what you wrote, leave the tree clean
 
@@ -283,9 +326,9 @@ A session that edits without committing leaves a dirty tree, and a dirty tree is
 ## Do NOT
 
 - **Never create a feature before you have consulted the portfolio and agreed the cut.** §1's order — look, advise, create — is the session.
-- **Never run a design grilling.** Shape-grill for the cut, and stop there. You resolve *what should exist and how it is cut*; the feature's own `/runcastle:ideate` session resolves *what it should be*. Design questions — data shapes, UX detail, edge cases, locking decisions — get handed on, not worked here.
-- **Never launch a session or terminal** for a feature you created. The card in the rail is the handoff.
-- **Never touch another feature's docs.** `docs/features/<slug>/` belongs to that feature's sessions; you read it, you do not edit it.
-- **Never advance a phase, emit tickets into an existing feature, or do ticket surgery.** Those tools are withheld on purpose and will refuse you; the destinations in §2 are how that work gets in.
+- **Never run a design grilling.** Shape-grill for the cut, and stop there. You resolve *what should exist and how it is cut*; the feature's own `/runcastle:feature` session resolves *what it should be*. Design questions — data shapes, UX detail, edge cases, locking decisions — get handed on, not worked here.
+- **Never act on a feature beyond what the human asked, or what a cut's working agreement covers.** See **Orchestrating**, *What you act on*.
+- **Never touch another feature's docs.** `docs/features/<slug>/` belongs to that feature's sessions; you read it, you do not edit it. `add_to_brief` is the one write you have, and it only appends.
+- **Never write tickets, dispatch rounds, or do ticket surgery.** Those tools are not registered for this session: a feature's agent does that work, and you give it the yes with `send_to_feature`.
 - **Never scaffold an empty charter, an empty ADR, or a backlog file.**
 - **Never leave uncommitted work.** See §7.

package/skills/packs/runcastle/skills/project/references/health-sweeps.md

@@ -16,22 +16,23 @@ short list of findings the human can route.
 - Missing tests around a seam that has failed before.
 - Docs that drifted from the code — a `spec.md` the code has moved past is the
   common one.
-- `get_work_record({ seam })` for recurring burner failures: the same area
+- `get_work_record({ seam })` for recurring ticket failures: the same area
   erroring across features is a design problem, not bad luck. Its rows carry
   each ticket's error but no digest.
 - `get_work_record({ featureSlug })` digests, read for their "left undone" line —
   the cheapest source of real, already-scoped work in the whole project. A
   ticket marked `digestNotInlined: true` had its digest moved out for size;
   read it with `get_work_record({ featureSlug, seq })`.
-- Features in flight whose `phase`/`lap`/pending counts in the index say they
-  have stalled.
+- Features in flight whose index line and work record say they have stalled:
+  tickets pending with no round running, or the same ticket failing round after
+  round.
 
 ## What to do with the findings
 
-Route **every** finding through §2 — a new feature, a quick change, a revisit,
-another lap, or nothing. Say which, and why.
+Route **every** finding through §2 — a new feature, a small change, a change to
+a feature in flight, more rounds, or nothing. Say which, and why.
 
-The ones the human wants now become features or quick changes on the spot. The
+The ones the human wants now become features on the spot. The
 ones they don't want **are stored nowhere.** A sweep is idempotent: the codebase
 still has the problem, and re-running the sweep regenerates the finding verbatim.
 Storing a derivable list buys nothing and costs a graveyard. There is no
@@ -41,7 +42,7 @@ sweep finding is regenerable by definition.
 
 ## The line you must not cross
 
-You **report**; you do not fix. Not the dead code, not the drifted doc, not the
-stale ADR. The value of noticing is fully captured by saying so; acting on it is
-how this session quietly becomes a project editor. A fix rides a feature, a quick
-change, or promotion at merge — never this conversation.
+You **report**; you do not fix, and a sweep never sets a feature working on its
+own. Not the dead code, not the drifted doc, not the stale ADR. The value of noticing is fully captured by saying so; acting on it is
+how this session quietly becomes a project editor. A fix rides a feature, or
+promotion at merge — never this conversation.

package/skills/packs/runcastle/skills/project/references/triage.md

@@ -13,7 +13,7 @@ not to any feature, and it records a *symptom*, not an intent: "crumbs overflow"
 "this dialog feels wrong".
 
 So triage is **not sorting**. Routing a ten-second note cold produces a brief
-that restates the one-liner and a quick-change ticket nobody can implement. Your
+that restates the one-liner and a change nobody can implement. Your
 job is to find the intent behind the notes — grilling for it, with the portfolio
 in view the way §1a intake demands — and only then route. Three movements, in
 order.
@@ -48,7 +48,7 @@ file to write and nothing else to report.
 3. **Play the grouping back, and let the human correct it before any grilling:**
 
    > 9 notes, 4 themes: ticket-card density (4), the rail's empty states (2), two
-   > separate asks about the burn log, and one stray about Windows paths. Does
+   > separate asks about the run log, and one stray about Windows paths. Does
    > that grouping look right?
 
    Take their correction. A theme you split is often one thing, and one you
@@ -61,7 +61,7 @@ file to write and nothing else to report.
 Take the themes one at a time and work each until its **intent** is clear enough
 to route. This is the one place this session grills, and it grills about what the
 human wanted, never about how it should be built — the design still belongs to
-the feature's own `/runcastle:ideate` session.
+the feature's own `/runcastle:feature` session.
 
 - **One question at a time, always with your recommended answer attached.** A
   bare question with no recommendation hands the work back to the human.
@@ -103,37 +103,40 @@ already settles. **Name screenshots by absolute path** — the `screenshotPath`
 from `list_project_notes`, verbatim. Ideation runs on the host and `Read`s it
 from there.
 
-### Quick changes — one batch per triage session
+### Small changes — one batch per triage session
 
-Every quick-sized theme of **this** triage session goes into **one**
-`create_feature({ title, oneLiner, tickets })` call: one feature, one rail row,
-one **Burn**, one **Merge** for the whole pass. This is where §2's "one call per
-quick change, not per ticket" widens — inside triage, the batch *is* the quick
-change, and calling it once per theme would give you a feature each.
+Every small, concrete theme of **this** triage session goes into **one**
+`create_feature({ title, oneLiner, brief })` call: one feature, one rail row,
+one **Merge** for the whole pass. This is where §2's "one feature per change,
+not per fix" widens — inside triage, the batch *is* the change, and creating
+one per theme would give you a feature each.
 
 - Title it for the pass ("Triage batch — card density and empty states"), with a
   one-liner the human would recognise a week from now.
-- Every quick-sized theme contributes its ticket strings to that one `tickets`
-  array — the grilled version, carrying the repro or the expected/got the
-  grilling produced, never the ten-second line.
-- A ticket whose note has a screenshot ends with that note's
+- Every small theme gets its own paragraph in that one `brief` — the grilled
+  version, carrying the repro or the expected/got the grilling produced, never
+  the ten-second line. The feature's agent reads it and judges the work.
+- A theme whose note has a screenshot ends with that note's
   `attachmentSentence`, **pasted verbatim**. That sentence is the whole contract:
-  the burner scans it back out of the ticket and puts the PNG in its sandbox.
+  the feature's agent carries it into any ticket it writes, and the worker scans
+  it back out of the ticket and puts the PNG in its sandbox.
 - Pass `baseBranch` the way §1c requires. The batch's review is then an ordinary
   feature test drive of its branch.
 
-### A revisit, or another lap
+### A change to a feature in flight
 
-Destinations 3 and 4 have no tool. Give the human a **handoff line** to paste
-into that feature's own session, carrying the grilled reasoning — not "see the
-notes":
+Destinations 3 and 4 go to that feature's agent. Once the human agrees the
+theme belongs there, send it with `send_to_feature`, carrying the grilled
+reasoning — not "see the notes":
 
-> Paste this into `burn-log-readability`'s revisit: "Timestamps in the burn log
-> are unreadable at a glance; we settled that the want is relative ages with the
-> absolute time on hover, and that the run header keeps its absolute start time."
+> `send_to_feature({ slug: "run-log-readability", message: "Timestamps in the
+> run log are unreadable at a glance; we settled that the want is relative ages
+> with the absolute time on hover, and that the run header keeps its absolute
+> start time." })`
 
-Then say which button opens it: **revisit** on the feature, or **Iterate** on its
-review page for another lap.
+When that feature is busy (the project skill's **Orchestrating**), or the human
+would rather say it themselves, give them the same text as a **handoff line** to
+paste into its chat.
 
 ### Nothing
 
@@ -153,9 +156,8 @@ note went. Use these forms:
 | Destination | Outcome line |
 |---|---|
 | New feature | `→ new feature <title>` |
-| The batched quick change | `→ batch quick change <title>` |
-| A revisit | `→ revisit of <slug> (handoff given)` |
-| Another lap | `→ another lap of <slug> (handoff given)` |
+| The batched feature | `→ batch feature <title>` |
+| A feature in flight | `→ sent to <slug>`, or `→ handed to <slug> (handoff given)` |
 | Dropped, or nothing | `dropped: <why>` |
 
 **Pass `featureId` whenever the destination is a feature.** `create_feature`
@@ -177,7 +179,7 @@ can reopen one from the inbox). Get the outcome line right the first time.
 
 ## Close
 
-Tell them what this pass produced: the batch and how many tickets it carries,
-each new feature, each handoff line still to paste, and how many notes are still
-open. Then stop — you never launch what you created (§1c), and the cards
-appearing in the rail are the handoff.
+Tell them what this pass produced: the batch and how many themes it carries,
+each new feature, each message sent and each handoff line still to paste, and
+how many notes are still open. Then stop: creating a feature sets nothing
+working (§1c). Plan or start what triage created only when the human asks.

package/skills/packs/runcastle/skills/qa/SKILL.md

@@ -36,8 +36,7 @@ The injected system prompt carries the slug and the paths; trust `get_feature_co
 
 A Q&A session is the wrong place to change the feature. If the conversation turns into "let's change X" or "this is a bug, fix it," name it and point them at the move that can:
 
-- a **revisit** on this feature, for late information that amends its record or its ticket queue;
-- **another lap** from review, if the feature is in Review and the drive taught them the spec was wrong — **Iterate** opens the conversation that amends the spec and cards the work, and **Burn** from Review starts the lap;
+- the **feature's own chat**, for late information that amends its record or its tickets, or for what a drive showed is wrong — its agent fixes it itself or writes more tickets;
 - a **new feature**, if it is really its own capability — created from the project session or the UI.
 
 Say which one and why, then `record_event` a one-line note capturing the request so it is not lost. You cannot open any of them, and you cannot create the feature yourself; the human's click is the handoff.