[Air #1709] feat: /arch-save takes a next task, /arch-init starts on it

.claude/skills/arch-init/SKILL.md

@@ -46,12 +46,29 @@ name in a multi-architect workspace).
      (`codev/state/*.md`); never commit them. Builder `*_thread.md` files
      are the opposite: versioned, shipping with each builder PR.
 
-3. **Confirm identity + orient, then follow the state file.** In one tight
-   block, report: who you now are (name + one-line role from the banner, if
-   present), the file you read, and the current-state / open-loops summary
-   from the most recent dated section (or the file's leading content if it
-   has no dated sections). Then carry out whatever the state file says to do
-   on resume. Do not invent a new agenda — resume the one the state file
+3. **Confirm identity + orient.** In one tight block, report: who you now are
+   (name + one-line role from the banner, if present), the file you read, and
+   the current-state / open-loops summary from the most recent dated section
+   (or the file's leading content if it has no dated sections). If the banner
+   carries a `NEXT TASK` line, report it too, as
+   `Next task from the owner at save time: <text>`.
+
+4. **Start on the next task, if the banner carries one.** It is the **first
+   action of the resumed session**, ahead of the general resume agenda — the
+   owner wrote it at save time precisely so it would not have to be typed
+   again once you came back. Begin it without waiting for a further prompt.
+   - It carries the owner's authority the way any owner message does, **with
+     the standard limits unchanged**. A next task never by itself approves a
+     porch gate, merges a PR, cuts a release, restarts Tower, or performs any
+     other act that needs a per-occasion word. If the next task *is* such an
+     act, prepare it and ask for the word live: a saved instruction is an
+     instruction, not a pre-spent approval.
+   - **Once you have started, delete the `NEXT TASK` line from the banner**
+     and record the pickup as a log entry (`picked up next task: <text>`).
+     A second re-init, or the next `/arch-save`, must not re-run it.
+
+5. **Then follow the state file.** Carry out whatever it says to do on
+   resume. Do not invent a new agenda — resume the one the state file
    describes.
 
 ## Saving your state (and knowing when to `/clear`)
@@ -118,9 +135,12 @@ Do not repeat it, and do not prompt for it at any other time.
 **`/arch-save` packages this whole loop**, and is the preferred path when the
 owner directs a refresh: it stops your monitors, writes the pruned state file,
 clears, and schedules `/arch-init` to bring you back — in that order, which is
-the part that matters. The save discipline above is what it performs at its
-step 3, so this section remains the source of truth for *how to write the
-file*; `/arch-save` is the source of truth for *the sequence*. The manual path
+the part that matters. It also accepts a **next task** as free text
+(`/arch-save file and spawn that issue`), which it writes into the banner as a
+`NEXT TASK` line for step 4 above to pick up. The save discipline above is
+what it performs at its step 3, so this section remains the source of truth
+for *how to write the file*; `/arch-save` is the source of truth for *the
+sequence*. The manual path
 (save → human clears → `/arch-init`) stays valid and is the fallback when
 Tower is unavailable.
 

.claude/skills/arch-save/SKILL.md

@@ -1,15 +1,26 @@
 ---
 name: arch-save
 description: Save an architect's state, clear its context, and re-init automatically — the packaged save→clear→re-init refresh cycle. Use when the owner directs a context refresh, or says "/arch-save", "save and clear", "refresh your context". Runs on the owner's direction; an architect does not invoke it autonomously mid-task. Counterpart to /arch-init, which recovers the state this writes.
-argument-hint: "[name]   (e.g. main; omit to auto-detect via afx whoami)"
+argument-hint: "[name] [next task]   (e.g. main; or: file and spawn that issue)"
 ---
 
 # /arch-save — save state, clear, and come back as yourself
 
 Long sessions accumulate stale context. This is the deliberate cure: you choose the
 moment, you choose what survives, and a fresh session resumes from what you wrote.
 
-`$ARGUMENTS` is the architect name (e.g. `main`). Omit it to auto-detect.
+`$ARGUMENTS` carries the architect name, a **next task** for the session that comes back,
+or both:
+
+```
+/arch-save                                  save, clear, re-init, then wait
+/arch-save file and spawn that issue        … and start on that first, unprompted
+/arch-save main file and spawn that issue   explicit name, then the next task
+```
+
+The next task is how an owner who already knows what the refreshed session should do first
+says so once, at the moment they direct the refresh, instead of watching for the re-init to
+land and typing it again.
 
 ## When NOT to run this
 
@@ -28,20 +39,51 @@ action. A mid-task snapshot resumes into confusion.
 Do these in order. **The order is the feature** — step 3 must precede step 4, because the
 context that knows what to write is the one about to be destroyed.
 
-### 1. Resolve your name
+### 1. Resolve your name, then split off the next task
 
-If `$ARGUMENTS` is non-empty, that is your name. Otherwise run `afx whoami` and use the
-reported `name` when `type: architect`.
+**Always run `afx whoami` first**, whatever `$ARGUMENTS` holds — the split below cannot
+tell a name from a task until it knows your name. The name rules are unchanged:
 
+- `type: architect` → the reported `name` is yours.
 - `type: builder` → **STOP.** This terminal is a builder. Report the mismatch.
-- Non-zero exit → **STOP** and ask which architect you are. Do **not** guess, and do not
-  default to `main` — writing another architect's state file is the exact failure
-  `/arch-init` exists to prevent (#1094).
+- Non-zero exit → you have no name yet. A single-token `$ARGUMENTS` that validates as a
+  name is still accepted as one; anything else → **STOP** and ask which architect you are.
+  Do **not** guess, and do not default to `main` — writing another architect's state file
+  is the exact failure `/arch-init` exists to prevent (#1094).
 
 **Validate the name before building any path**: `[a-z][a-z0-9-]*`, at most 64 characters.
 Reject slashes, `..`, uppercase, spaces. Never interpolate an unvalidated name into
 `codev/state/<name>.md`.
 
+Then split `$ARGUMENTS`:
+
+1. `$ARGUMENTS` is empty → name from `afx whoami`, and there is no next task.
+2. The **first whitespace-separated token** equals the whoami name (or, when whoami could
+   not resolve one, is a single token that validates as a name) → that token is the name,
+   and the **remainder** is the next-task text, which may be empty.
+3. Otherwise → the **whole** of `$ARGUMENTS` is the next-task text, and the name comes
+   from `afx whoami`.
+
+So `/arch-save` and `/arch-save main` behave exactly as they always have. The one
+ambiguity — a next task whose first word happens to be your own architect name — is
+accepted rather than worked around: lead with the explicit name
+(`/arch-save main main is stalled, look at it`) to disambiguate.
+
+**If you had to ask which architect you are, the next task still stands.** The answer
+supplies the name; `$ARGUMENTS` already supplied the task. Do not make the owner retype it.
+
+**Guard, applied after the split: a leading token that names a *different* architect stops
+you.** If the first token validates as a name, differs from the name whoami reported, and
+`codev/state/<token>.md` exists → **STOP and ask which architect you are. Write nothing.**
+whoami can be wrong (#1094), and rule 3 would otherwise bury a real name-override inside
+next-task text and save to whoami's file; a task that merely opens with a sibling's name is
+the only case this costs, and it costs one clarification.
+
+**This is not how `/arch-init` resolves a name**, and the asymmetry is deliberate:
+`/arch-init` takes no next task, so any non-empty argument there is unambiguously a name
+and overrides whoami outright. Here the first token is weighed *against* whoami, which is
+why the guard above exists — never save into a name you did not verify.
+
 ### 2. Stop your own monitors
 
 Enumerate every monitor, watcher or background task you armed, and stop it.
@@ -75,6 +117,21 @@ first (`cp codev/state/<name>.md codev/state/.<name>.bak.md`) is cheap insurance
 **Content guardrails.** No secrets — tokens, keys, credentials. No transcript dumps, no
 raw tool output. Only: current focus, open loops, and what a fresh session needs to resume.
 
+**Write the next task into the banner**, if step 1 produced one. Add a single line to the
+banner block, directly after the `⭐ THIS /clear IS INTENTIONAL` line:
+
+```
+# ⏭ NEXT TASK (owner-directed at save, 2026-09-19T02:10Z): file and spawn that issue
+```
+
+- **Verbatim.** Collapse newlines to spaces; do not paraphrase, expand, or "helpfully"
+  plan it. Those are the owner's words, and the context writing them down is the one about
+  to be destroyed — this is the last moment at which a paraphrase can be caught.
+- **New text replaces** any existing NEXT TASK line.
+- **No new text preserves an existing one.** A NEXT TASK line still in the banner means the
+  previous cycle never came back to pick it up; dropping it silently would lose an owner
+  instruction that nothing else is holding.
+
 Use the template at the end of this document.
 
 ### 4. Clear
@@ -160,12 +217,16 @@ literal text on the front of the next message never executes.
 
 The structure below comes from a live run of this cycle. Every element earns its place;
 keep them all, including a `MONITORS:` line even when the answer is "none armed" — an
-omitted monitor list is indistinguishable from a forgotten one.
+omitted monitor list is indistinguishable from a forgotten one. The `NEXT TASK` line is the
+single exception: it appears only when there is one.
 
 ```
 # <lane> architect — state (vNN, <date> ~HH:MM UTC — <milestone>, DELIBERATE /clear cycle)
 # ⭐ THIS /clear IS INTENTIONAL (owner-directed context refresh). On re-init: normal
 # /arch-init flow, then:
+# ⏭ NEXT TASK (owner-directed at save, <ISO timestamp>): <the owner's words, verbatim>
+#    — OPTIONAL; present only when the save carried one. /arch-init starts here before the
+#    agenda below, then deletes this line and logs the pickup.
 # 1. MONITORS: <what to stop if it is still firing, then what to re-arm> — watch target,
 #    cadence, alert pattern. Self-test once before trusting alerts. ("none armed" is a
 #    valid and complete answer.)

.codex/skills/arch-init/SKILL.md

@@ -46,12 +46,29 @@ name in a multi-architect workspace).
      (`codev/state/*.md`); never commit them. Builder `*_thread.md` files
      are the opposite: versioned, shipping with each builder PR.
 
-3. **Confirm identity + orient, then follow the state file.** In one tight
-   block, report: who you now are (name + one-line role from the banner, if
-   present), the file you read, and the current-state / open-loops summary
-   from the most recent dated section (or the file's leading content if it
-   has no dated sections). Then carry out whatever the state file says to do
-   on resume. Do not invent a new agenda — resume the one the state file
+3. **Confirm identity + orient.** In one tight block, report: who you now are
+   (name + one-line role from the banner, if present), the file you read, and
+   the current-state / open-loops summary from the most recent dated section
+   (or the file's leading content if it has no dated sections). If the banner
+   carries a `NEXT TASK` line, report it too, as
+   `Next task from the owner at save time: <text>`.
+
+4. **Start on the next task, if the banner carries one.** It is the **first
+   action of the resumed session**, ahead of the general resume agenda — the
+   owner wrote it at save time precisely so it would not have to be typed
+   again once you came back. Begin it without waiting for a further prompt.
+   - It carries the owner's authority the way any owner message does, **with
+     the standard limits unchanged**. A next task never by itself approves a
+     porch gate, merges a PR, cuts a release, restarts Tower, or performs any
+     other act that needs a per-occasion word. If the next task *is* such an
+     act, prepare it and ask for the word live: a saved instruction is an
+     instruction, not a pre-spent approval.
+   - **Once you have started, delete the `NEXT TASK` line from the banner**
+     and record the pickup as a log entry (`picked up next task: <text>`).
+     A second re-init, or the next `/arch-save`, must not re-run it.
+
+5. **Then follow the state file.** Carry out whatever it says to do on
+   resume. Do not invent a new agenda — resume the one the state file
    describes.
 
 ## Saving your state (and knowing when to `/clear`)
@@ -118,9 +135,12 @@ Do not repeat it, and do not prompt for it at any other time.
 **`/arch-save` packages this whole loop**, and is the preferred path when the
 owner directs a refresh: it stops your monitors, writes the pruned state file,
 clears, and schedules `/arch-init` to bring you back — in that order, which is
-the part that matters. The save discipline above is what it performs at its
-step 3, so this section remains the source of truth for *how to write the
-file*; `/arch-save` is the source of truth for *the sequence*. The manual path
+the part that matters. It also accepts a **next task** as free text
+(`/arch-save file and spawn that issue`), which it writes into the banner as a
+`NEXT TASK` line for step 4 above to pick up. The save discipline above is
+what it performs at its step 3, so this section remains the source of truth
+for *how to write the file*; `/arch-save` is the source of truth for *the
+sequence*. The manual path
 (save → human clears → `/arch-init`) stays valid and is the fallback when
 Tower is unavailable.