/arch-save: accept a next-task instruction and have /arch-init start on it after the refresh

[waleedkadous]

Problem

/arch-save saves state, clears, and schedules /arch-init. The architect comes back oriented but idle: it reports its state and waits. When the owner already knows what the refreshed session should do first ("file and spawn that issue", "merge 1660", "review Amr's PR"), that instruction has nowhere to go — it has to be typed again after the re-init lands, and the owner has to be watching for that moment.

Proposal

Let /arch-save take a next task as free text, persist it in the state file, and have /arch-init start on it immediately after orienting.

/arch-save file and spawn that issue
/arch-save main file and spawn that issue     # explicit name still accepted
/arch-save                                   # unchanged: save, clear, re-init, wait

Design (prescribed — implement as written unless something is genuinely wrong with it)

Argument resolution in /arch-save

1. Always run afx whoami first (the name resolution rules are unchanged: type: builder → stop; non-zero exit → ask; validate [a-z][a-z0-9-]*, ≤64 chars).
2. If $ARGUMENTS is empty → name from whoami, no next task.
3. If the first whitespace-separated token of $ARGUMENTS equals the whoami name (or, when whoami could not resolve, is a single token that validates as a name) → it is the name; the remainder is the next-task text (possibly empty).
4. Otherwise the whole of $ARGUMENTS is the next-task text and the name comes from whoami.

Back-compatible: /arch-save main behaves exactly as today. Document the one ambiguity (a next task that begins with the architect's own name as a word) as accepted; the owner can lead with the explicit name to disambiguate.

Persisting it (step 3 of the save)

Add one 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 — it is the owner's words, and the context writing it is about to be destroyed.
• New text replaces any existing NEXT TASK line. No text → an existing, never-picked-up NEXT TASK line is preserved (it means the previous cycle never resumed; dropping it silently would lose an owner instruction).
• Update the state-block template at the end of the skill to show the line as optional.

Picking it up (/arch-init)

Add a step between "orient" and "follow the state file":

• If the banner carries a NEXT TASK line, include it in the identity/orient block as Next task from the owner at save time: <text> and then start on it immediately, as the first action of the resumed session, ahead of the general resume agenda.
• 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, releases, 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 started, delete the NEXT TASK line from the banner and record the pickup as a log entry (picked up next task: <text>), so a second re-init or a later save does not re-run it.

Files

Both trees, all copies byte-identical (there are .claude and .codex copies of each skill):

• .claude/skills/arch-save/SKILL.md, .claude/skills/arch-init/SKILL.md
• .codex/skills/arch-save/SKILL.md, .codex/skills/arch-init/SKILL.md
• codev-skeleton/.claude/skills/{arch-save,arch-init}/SKILL.md
• codev-skeleton/.codex/skills/{arch-save,arch-init}/SKILL.md

packages/codev/skeleton/ is build-generated from codev-skeleton/ (gitignored) — do not edit it. Grep both trees for other prose that describes the /arch-save cycle (e.g. the "Saving your state" section of arch-init, codev/roles/architect.md) and keep it consistent. Update the argument-hint frontmatter of arch-save to show the new form.

Acceptance

• /arch-save <text> writes the NEXT TASK line verbatim, then clears and re-inits as today.
• /arch-save and /arch-save <name> behave exactly as before.
• After re-init the architect names the next task in its orient block and begins it without a further prompt; the line is gone from the banner afterwards and a log entry records the pickup.
• A next task that names a gate/merge/release/restart results in a prepared request for the word, not the act.
• Any existing skill-parity test still passes; all copies listed above are identical.

Refs #1307 (the original /arch-save cycle), #1220 (/arch-init state saving).