@chinhae/atw-cli 0.4.0 → 0.5.0

package/README.md

@@ -25,7 +25,7 @@ by default.
 | --- | --- | --- |
 | For | Building software — whether or not you are an engineer | Work that is not code: writing, research, organizing material, planning |
 | The AI follows | Six stages, four stops, tickets, review by sub-agents — see [How It Works](#how-it-works) | Talk it through → write it down → do it → check it, with two stops |
-| Installed | 28 skills, the `/atw-continue` and `/atw-finish-work` commands, the `atw-implement-agent` and `atw-review` sub-agents, `.atw/spec/` by package and layer | 6 skills and one conventions file |
+| Installed | 29 skills, the `/atw-continue` and `/atw-finish-work` commands, the `atw-implement-agent` and `atw-review` sub-agents, `.atw/spec/` by package and layer | 6 skills and one conventions file |
 | Noob mode, for someone who never chose | Off | On |
 
 A project with no `mode:` line is a `dev` project, so one set up before modes
@@ -113,7 +113,7 @@ Dropped:
   a task?" question and no `/atw-implement` to run. The two stops left are the
   two above: confirming what was written down, and accepting the result. You
   never type a command to move the work along.
-- **22 of the 28 skills.** The six that stay: `atw-interview`, `atw-research`,
+- **23 of the 29 skills.** The six that stay: `atw-interview`, `atw-research`,
   `atw-session-insight` and `atw-noob-mode`, which the AI also uses on its own,
   and `/atw-askme` and `/atw-handoff`, which start only when you type them.
 - **The `/atw-continue` and `/atw-finish-work` commands.** `/atw-start` stays on
@@ -161,7 +161,7 @@ the repo and multi-platform setup hold in `general` mode as well.
 | **A task record with six stages** | Every task moves through `discover → specify → slice → implement → accept → completed`. The stage lives in `task.json`, and a per-turn hook injects that stage's rules into the session — so the AI knows where it is without being told again. |
 | **Four stops, all yours** | Everywhere else the AI advances on its own. At four points it must stop and wait for you: creating the task, confirming the spec, starting each ticket, and accepting the result. |
 | **Auto-injected specs** | Write conventions once in `.atw/spec/`, then let ATW inject the relevant context into each session instead of repeating yourself. |
-| **One ticket at a time** | Work is sliced into tickets with explicit dependencies. Exactly one is `doing`; two at once is a broken state, not a choice. The one exception is a whole-spec run you start yourself with `/atw-implement-spec`. |
+| **One ticket at a time** | Work is sliced into tickets with explicit dependencies. Exactly one is `doing`; two at once is a broken state, not a choice. The one exception is a parallel whole-spec run you start yourself with `/atw-implement-spec`; `/atw-implement-all` stays serial. |
 | **Project memory** | Journals in `.atw/workspace/` preserve what happened last time, so each new session starts with real context. `atw mem` searches conversation history across hosts. |
 | **Team-shared standards** | Specs and tasks live in the repo. Workspace journals stay per-developer, so two people on the same repo don't collide. |
 | **Multi-platform setup** | Bring the same ATW structure to 22 AI coding platforms instead of rebuilding your workflow per tool. |
@@ -290,7 +290,7 @@ Outside these four, the AI advances stages on its own. It does not stop to ask
 | --- | --- |
 | Before a task is created | Does this work deserve a record |
 | After `prd.md` is written | Is the spec right |
-| Before implementation starts | You run `/atw-implement` per ticket, or `/atw-implement-spec` once for the whole spec; the AI cannot invoke either |
+| Before implementation starts | You run `/atw-implement` per ticket, `/atw-implement-spec` once for the whole spec in parallel, or `/atw-implement-all` once for the whole spec serially; the AI cannot invoke any of the three |
 | Before archiving | "This is done" |
 
 ## What lands in your repo
@@ -332,7 +332,7 @@ actually does. `native` is the workflow that comes with the project's mode: the
 
 ## Skills and sub-agents
 
-In `dev` mode, 28 skills install into every configured platform; in `general`
+In `dev` mode, 29 skills install into every configured platform; in `general`
 mode, six do (see [Two modes](#two-modes)). The ones you reach for daily in
 `dev`:
 
@@ -345,6 +345,7 @@ mode, six do (see [Two modes](#two-modes)). The ones you reach for daily in
 | `/atw-tickets` | slice a confirmed spec into tickets |
 | `/atw-implement` | run one ticket's full chain — you invoke it, the AI can't |
 | `/atw-implement-spec` | run every ticket of a sliced spec in one parallel run on an integration branch, reviewed once at the end — you invoke it, the AI can't |
+| `/atw-implement-all` | run every ticket of a sliced spec in one serial run in place on the current branch, reviewed per ticket; `--max N` stops cleanly after N tickets and running it again resumes — you invoke it, the AI can't |
 | `/atw-diagnosing-bugs` | the same bug got fixed more than once |
 | `/atw-update-spec` | promote a learning back into `.atw/spec/` |
 | `/atw-channel` | multi-agent collaboration over a durable local event log |

package/dist/migrations/manifests/0.5.0.json

@@ -0,0 +1,9 @@
+{
+  "version": "0.5.0",
+  "description": "/atw-implement-all implements a whole sliced spec in one serial run, with a review per ticket. A ticket marked ready-for-human is no longer implemented by the AI without the user's explicit say. The acceptance check now ticks the criteria it verified and commits them.",
+  "breaking": false,
+  "recommendMigrate": false,
+  "changelog": "/atw-implement-all, a third way through stop ③. Until now a sliced spec was implemented either one ticket at a time, with the user running /atw-implement for each, or all at once in parallel with /atw-implement-spec and one review at the end. /atw-implement-all is run once by the user and works the tickets serially: the main session takes the lowest-numbered ticket on the frontier, claims it with the plain tickets.py claim, dispatches one implementer sub-agent that works in place on the current branch and commits there, reviews that ticket with atw-code-review against the base recorded at claim time, has findings fixed once and re-checks only what was fixed, writes spec updates back, marks the ticket done and commits the state — then takes the next ticket. No worktrees, no integration branch, and never more than one ticket at doing. --max N stops cleanly after N tickets. The run comes back to the user when an implementer meets an ambiguity that would change the result, when a finding is still open after the one re-check, when a ticket cannot be finished as written, or when only tickets marked for a person are left. Stopping needs no cleanup: every closed ticket is already written back and committed, a ticket left at doing is the breakpoint, and running the same command again resumes from it. Like the other two ways, only the user can start it, and it needs a platform that dispatches sub-agents. A dev project now installs 29 skills instead of 28. .atw/workflow.md gains step 2.8 for the run, and /atw-continue names all three ways at stop ③. Tickets for a person. The Status: line on a ticket used to be a fixed placeholder; it now carries a decision. /atw-tickets marks a ticket ready-for-human when a person must do it — it needs an external account, a manual test pass, or a design or legal decision. /atw-implement reads that line before touching code: it says the ticket is marked for a person, quotes the reason the ticket gives, and asks the user to either do it themselves or explicitly authorize the AI to do it in their place; an authorization is written into the commit the run makes. /atw-implement-all never dispatches such a ticket. tickets.py does not read the field, so the frontier and tickets.py claim behave as before. Acceptance leaves a record and a clean tree. During the acceptance check the AI ticks each criterion's checkbox in prd.md and in the ticket that carried it as the criterion checks out, and commits the ticks once (chore(task): <task> acceptance check) before asking the user to accept; nothing earlier in the chain ticks them. When the last ticket closes and the task moves to accept, the task.json change is committed as well, so the acceptance check starts from a clean tree.",
+  "migrations": [],
+  "notes": "No migration required. atw update deletes and renames nothing. In a dev project it adds one skill, atw-implement-all, to every configured platform, and updates these templates: .atw/workflow.md, .atw/config.yaml (one comment; no setting changes), the atw-implement, atw-tickets, atw-noob-mode and atw-init-repo skills, /atw-continue in each platform's own form, the inject-workflow-state.py hook on the platforms that install it, and SNOW.md on Snow. In a general project it adds nothing and updates the atw-noob-mode skill, the same hook and the same comment in .atw/config.yaml; the mode: line is kept. They update as Template updated where the project left them untouched; where a project edited them locally, atw update asks before replacing. Tickets written before this release carry Status: ready-for-agent, the value tickets.py writes, so /atw-implement does not stop on them."
+}

package/dist/templates/atw/config.yaml

@@ -114,12 +114,13 @@ channel:
 # atw-review sub-agents for the two review axes. On the per-ticket path
 # implementation is never dispatched on any platform: it runs inside
 # `/atw-implement` in the main session (`atw-implement-agent` ships only as a
-# reserved role). Only a `/atw-implement-spec` run dispatches implementers. This does
-# not rely on inherited parent transcripts: `fork_turns` remains
-# caller-controlled, while Codex's native SubagentStart hook injects task
-# context when trusted and child-side loading remains the fallback when it is
-# unavailable. Set to "inline" only to run the review axes in the main
-# session too. "sub-agent" remains a backwards-compatible alias for "auto".
+# reserved role). Only a `/atw-implement-spec` or `/atw-implement-all` run
+# dispatches implementers. This does not rely on inherited parent transcripts:
+# `fork_turns` remains caller-controlled, while Codex's native SubagentStart
+# hook injects task context when trusted and child-side loading remains the
+# fallback when it is unavailable. Set to "inline" only to run the review axes
+# in the main session too. "sub-agent" remains a backwards-compatible alias
+# for "auto".
 # Invalid explicit values safely use inline mode.
 #
 # In "auto" mode, dispatched sub-agents inherit the main session's model

package/dist/templates/atw/workflow.md

@@ -7,7 +7,7 @@
 1. **Plan before code** — figure out what to do before you start
 2. **Specs injected, not remembered** — guidelines are injected via hook/skill, not recalled from memory
 3. **Persist everything** — research, decisions, and lessons all go to files; conversations get compacted, files don't
-4. **One ticket at a time, unless the user asks for the whole spec at once** — serial by default: claim, finish, close, then take the next. `/atw-implement-spec` is the one parallel path, and only the user starts it
+4. **One ticket at a time, unless the user asks for the whole spec at once** — serial by default: claim, finish, close, then take the next. `/atw-implement-spec` is the one parallel path; `/atw-implement-all` is the third way through stop ③ — started once, still serial, still reviewed per ticket. Only the user starts any of them
 5. **Capture learnings** — after each ticket, review and write new knowledge back to spec
 
 ---
@@ -205,7 +205,7 @@ python3 ./.atw/scripts/get_context.py --mode phase --step <X.Y>  # detailed guid
 
 ```
 Phase 1: Plan    → discover, specify, and (when needed) slice into tickets
-Phase 2: Execute → one ticket at a time through the full implement chain, or the whole spec in one parallel run
+Phase 2: Execute → one ticket at a time through the full implement chain, or the whole spec in one run — parallel, or serial with a review per ticket
 Phase 3: Finish  → read-only acceptance check, then archive
 ```
 
@@ -243,7 +243,7 @@ Outside these four, the AI advances stages on its own. It does not stop to ask "
 |---|---|---|
 | ① | Before creating a task | Does this work deserve a record — the user's |
 | ② | After the spec is written | Is the spec right — the user's |
-| ③ | Before implementation starts | The user runs `/atw-implement` per ticket, or `/atw-implement-spec` once for the whole spec; the AI cannot invoke either |
+| ③ | Before implementation starts | The user runs `/atw-implement` per ticket, `/atw-implement-spec` once for the whole spec in parallel, or `/atw-implement-all` once for the whole spec serially; the AI cannot invoke any of the three |
 | ④ | Before archiving | "This is done" — the user's acceptance |
 
 ### Planning Artifacts
@@ -335,19 +335,21 @@ When the tickets are written, run `task.py start <task>` (step 1.5) to enter imp
 - 2.4 Close the ticket `[required · repeatable]`
 - 2.5 Roll back `[on demand]`
 - 2.7 Whole-spec run `[alternative to 2.1–2.4 · once]` (stop ③; the user picks it)
+- 2.8 Serial whole-spec run `[alternative to 2.1–2.4 · once]` (stop ③; the user picks it)
 
 <!-- Per-turn breadcrumb: stage 'implement' — set by task.py start, held for all of Phase 2 -->
 
 [workflow-state:implement]
-Stop ③: implementation is the user's to start. You may not invoke either skill below yourself, and you may not do the implementation inline instead. When the task has tickets, name both ways and let the user pick; a task with no tickets has only the first.
+Stop ③: implementation is the user's to start. You may not invoke any of the three skills below yourself, and you may not do the implementation inline instead. When the task has tickets, name all three ways and let the user pick; a task with no tickets has only the first.
 Per-ticket path (the default): one ticket at a time. Run `tickets.py frontier`, pick one, `tickets.py claim NN` — never hold two tickets at `doing` — then tell the user to run `/atw-implement` for the claimed ticket. One user invocation per ticket.
 Whole-spec path: the user runs `/atw-implement-spec` once. It owns the run from the first claim to the closing commit: it claims with `tickets.py claim NN --parallel`, dispatches implementer sub-agents across the frontier, each in its own worktree, lands everything on one integration branch, marks each ticket `done` as its work merges, reviews that branch once at the end, and writes spec updates back before its closing commit. Do not claim, review or commit around it. It needs a platform that dispatches sub-agents.
+Serial whole-spec path: the user runs `/atw-implement-all` once. The main session is the orchestrator and the loop is the per-ticket chain without the per-ticket "start": claim → dispatch an implementer → review → fix once, re-check once → write spec updates back → `tickets.py done` → commit state → next ticket. Plain `tickets.py claim NN`, one ticket at `doing`, in place on the current branch, a review per ticket. It halts for four things — an implementer's result-changing ambiguity, a finding still open after the one re-check, a ticket that cannot be finished as written, a frontier holding only `ready-for-human` tickets or a next ticket that is plainly human work — and for `--max N`; a ticket left at `doing` is the breakpoint, and running the same command again resumes from it. It needs a platform that dispatches sub-agents.
 On the per-ticket path, that one `/atw-implement` run is a closed chain and must not be broken up from the outside: implement (test-first where it fits) → run tests, full suite on the last pass → review → handle findings → write spec updates back → commit. Never instruct it to skip the review or the commit.
 Findings triage: spec-axis findings and anything the standards axis calls a hard violation get fixed once, then only what was fixed is re-checked, once, then the commit. No second full review and no loop: anything still open after that one re-check goes to the user before the commit. Judgement calls ship and get reported.
 Relay every review report to the user verbatim — Standards and Spec, plus Visual when the ticket changed UI — even when the verdict is "nothing found". No report reaching you is not a passing review.
 Any sub-agent dispatched from here starts its prompt with `Active task: <task path from task.py current>` — the role files read that line to find the task, and it is the context hooks' fallback when session resolution misses.
-Main-session default: run the process; on the per-ticket path the implementation itself is written inside `/atw-implement`, never by a dispatched `atw-implement-agent` — that role file is reserved and is not a step in this flow. The only sub-agent that path raises is `atw-review` (twice, from inside `/atw-implement` — three times when the ticket changes UI and a Visual review runs). Implementer sub-agents exist only inside a `/atw-implement-spec` run, dispatched by that skill and by nothing else. Sub-agent self-exemption: this breadcrumb reaches sub-agent turns on some hosts. If you are already running as `atw-review`, do NOT spawn another `atw-review` — do the review you were dispatched for. If you were dispatched by `/atw-implement-spec` as an implementer or merger, stop ③ is already satisfied — do the work you were dispatched for and dispatch nothing. Dispatch is main session only.
-Per-ticket path: then `tickets.py done NN` and back to the frontier. Either path: when the frontier is empty and every ticket is `done`, run `task.py set-status <task> accept`.
+Main-session default: run the process; on the per-ticket path the implementation itself is written inside `/atw-implement`, never by a dispatched `atw-implement-agent` — that role file is reserved and is not a step in this flow. The only sub-agent that path raises is `atw-review` (twice, from inside `/atw-implement` — three times when the ticket changes UI and a Visual review runs). Implementer sub-agents exist only inside a `/atw-implement-spec` or `/atw-implement-all` run, dispatched by that skill and by nothing else. Sub-agent self-exemption: this breadcrumb reaches sub-agent turns on some hosts. If you are already running as `atw-review`, do NOT spawn another `atw-review` — do the review you were dispatched for. If you were dispatched by `/atw-implement-spec` as an implementer or merger, or by `/atw-implement-all` as an implementer, stop ③ is already satisfied — do the work you were dispatched for and dispatch nothing. Dispatch is main session only.
+Per-ticket path: then `tickets.py done NN` and back to the frontier. Any path: when the frontier is empty and every ticket is `done`, run `task.py set-status <task> accept` and commit the `task.json` change, so the tree is clean when 3.1 starts.
 [/workflow-state:implement]
 
 ### Phase 3: Finish
@@ -360,6 +362,7 @@ Per-ticket path: then `tickets.py done NN` and back to the frontier. Either path
 [workflow-state:accept]
 Read-only from here. Do not open new work, do not fix things you notice — file them as tickets or a follow-up task instead.
 Walk the acceptance criteria in `prd.md` one by one and report which are met, with evidence; for UI criteria the evidence is a screenshot of the named screen, state and viewport (`/atw-ui` can review read-only). Confirm `tickets.py summary` shows every ticket `done` and `git status --porcelain` is clean.
+As each criterion checks out, tick its checkbox in `prd.md` and in the ticket that carried it — the ticks are the acceptance record, nobody earlier ticks them. Commit the ticks once (`chore(task): <task> acceptance check`) before stop ④.
 Stop ④: present that and wait for the user to accept. Acceptance is the user's judgement, not yours.
 Once accepted, run `task.py archive <task>` — status goes to `completed` and the task moves to `archive/`.
 [/workflow-state:accept]
@@ -391,14 +394,15 @@ When a user request matches one of these intents inside an active task, route fi
 - Slicing a confirmed spec into tickets → `/atw-tickets`
 - Starting a claimed ticket → `/atw-implement` (the user runs it; stop ③)
 - Implementing every ticket of a sliced spec in one parallel run → `/atw-implement-spec` (the user runs it; stop ③)
+- Implementing every ticket of a sliced spec in one serial run, reviewed per ticket → `/atw-implement-all` (the user runs it; stop ③)
 - Building or polishing a screen for a claimed ticket → `/atw-ui`, used from inside `/atw-implement`
 - Same bug fixed more than once → `/atw-diagnosing-bugs`
 - Knowledge worth keeping outside a ticket → `/atw-update-spec`
 - The user cannot follow the terms, an approval prompt or an error, or says "开启小白模式" / "关闭小白模式" → `/atw-noob-mode` (in any stage, with or without a task)
 
-Seven of these are user-triggered and the AI cannot invoke them: `/atw-askme`,
+Eight of these are user-triggered and the AI cannot invoke them: `/atw-askme`,
 `/atw-askme-with-docs`, `/atw-map`, `/atw-spec`, `/atw-tickets`, `/atw-implement`,
-`/atw-implement-spec`.
+`/atw-implement-spec`, `/atw-implement-all`.
 Name the one that fits and let the user run it — calling the Skill tool on one
 returns an error and nothing else.
 
@@ -408,6 +412,7 @@ returns an error and nothing else.
 - Stops ①–④ are the user's calls. Never advance through one by inferring the answer.
 - Planning must be persisted to task artifacts; the review chain must run before reporting a ticket complete.
 - Never mark two tickets `**Impl:** doing` at the same time. The only thing that may is a `/atw-implement-spec` run, through `tickets.py claim NN --parallel`.
+- `/atw-implement-all` is a user-started run like `/atw-implement-spec`: it claims serially and dispatches its own implementers. Outside one of those two runs, no implementer sub-agent is dispatched.
 
 ### Loading Step Detail
 
@@ -590,16 +595,17 @@ Ready to leave Phase 1:
 
 Goal: turn the confirmed spec into committed, reviewed code.
 
-There are two ways through this phase, and the user picks at stop ③:
+There are three ways through this phase, and the user picks at stop ③:
 
 | Path | What the user runs | How the tickets move |
 |---|---|---|
 | Per ticket (the default) | `/atw-implement`, once per ticket | Steps 2.1–2.4: one ticket at a time, each reviewed before it is closed |
 | Whole spec | `/atw-implement-spec`, once | Step 2.7: implementer sub-agents work the frontier in parallel on one integration branch, reviewed once at the end |
+| Whole spec, serial | `/atw-implement-all`, once | Step 2.8: the main session orchestrates — one implementer sub-agent per ticket, in place on the current branch, each ticket reviewed before it is closed |
 
-A task with no tickets has only the per-ticket path. The whole-spec path also needs a platform that dispatches sub-agents; on one that does not, name only the per-ticket path.
+A task with no tickets has only the per-ticket path. Both whole-spec paths also need a platform that dispatches sub-agents; on one that does not, name only the per-ticket path.
 
-The main session runs the process. On the per-ticket path it does not write the implementation itself and it does not dispatch an implementation sub-agent — the work happens inside `/atw-implement`, which the user starts. On the whole-spec path the main session is the orchestrator `/atw-implement-spec` describes, and the implementers it dispatches are that skill's, not a step of this file.
+The main session runs the process. On the per-ticket path it does not write the implementation itself and it does not dispatch an implementation sub-agent — the work happens inside `/atw-implement`, which the user starts. On either whole-spec path the main session is the orchestrator that skill describes — `/atw-implement-spec` or `/atw-implement-all` — and each run dispatches its own implementers; they are that skill's, not a step of this file.
 
 **Sub-agent dispatch protocol** — applies to every platform and every sub-agent
 dispatched anywhere in this workflow (the review sub-agents raised inside the
@@ -624,9 +630,9 @@ dispatch, and it dispatches itself.
 Implementation is never dispatched on the per-ticket path. `atw-implement-agent`
 ships as a reserved role file so the injection path stays wired (D23), but no
 step in this workflow spawns it — the code is written inside `/atw-implement`.
-A `/atw-implement-spec` run does dispatch implementers, as general-purpose
-sub-agents carrying that skill's own brief — not `atw-implement-agent`, which
-may not commit.
+A `/atw-implement-spec` or `/atw-implement-all` run does dispatch implementers,
+as general-purpose sub-agents carrying that skill's own brief — not
+`atw-implement-agent`, which may not commit.
 
 On Grok Build, use `spawn_subagent` with `subagent_type` set to the ATW agent
 name (e.g. `atw-review`). On Kimi Code, dispatch the built-in `coder` /
@@ -654,7 +660,7 @@ For a task that was never sliced, skip to 2.2: the whole `prd.md` is the unit of
 
 **Stop ③**: tell the user to run `/atw-implement`.
 
-You cannot invoke it and you must not substitute for it — not by implementing inline, and not by reading its instructions and following them yourself. One user invocation per ticket.
+You cannot invoke it and you must not substitute for it — not by implementing inline, and not by reading its instructions and following them yourself. One user invocation per ticket. A ticket whose `**Status:**` is `ready-for-human` is not skipped on this path, but `/atw-implement` confirms with the user before touching code: they do it themselves, or they explicitly authorize the AI to do it, and that authorization goes into the commit `/atw-implement` makes at the end of its chain.
 
 That single run is a closed chain:
 
@@ -712,7 +718,7 @@ If the same issue has now been fixed more than once, stop patching and tell the
 
 #### 2.7 Whole-spec run `[alternative to 2.1–2.4 · once]`
 
-**Stop ③**, the other way through it: the user runs `/atw-implement-spec` instead of `/atw-implement`. You cannot invoke it, and you do not start it because it looks faster — the user is trading a per-ticket look at the work for one review at the end, and that trade is theirs.
+**Stop ③**, the second way through it: the user runs `/atw-implement-spec` instead of `/atw-implement`. You cannot invoke it, and you do not start it because it looks faster — the user is trading a per-ticket look at the work for one review at the end, and that trade is theirs.
 
 It replaces steps 2.1–2.4 for the whole task. The skill carries the procedure; what this file needs you to know is what changes around it:
 
@@ -730,6 +736,28 @@ When every ticket is `done`:
 python3 ./.atw/scripts/task.py set-status <task-dir> accept
 ```
 
+#### 2.8 Serial whole-spec run `[alternative to 2.1–2.4 · once]`
+
+**Stop ③**, the third way through it: the user runs `/atw-implement-all` instead of `/atw-implement`. You cannot invoke it, and you do not start it because the user seems to want the whole spec done — removing the per-ticket "start" is the user's trade to make, same as in 2.7.
+
+It replaces steps 2.1–2.4 for the whole task. The skill carries the procedure; what this file needs you to know is how it differs from 2.7:
+
+- **Tickets run serially.** The main session is the orchestrator. It claims with the plain `tickets.py claim NN`, so exactly one ticket is at `**Impl:** doing` and it is the current ticket, as on the per-ticket path. Do not claim by hand during the run.
+- **Work lands in place**, on the branch the task started on. One implementer sub-agent per ticket works on the current branch and commits there; no worktree, no integration branch, no merger.
+- **One review per ticket**, run by the orchestrator in the main session against the `implementation_base_sha` the claim recorded, before the ticket is closed. Findings follow the 2.2 triage: fixed once by the same implementer, re-checked once; whatever is still open goes to the user before the spec is written back.
+- **Spec updates land per ticket**, before the state commit that closes it. Every ticket leaves the implementer's code commit and the orchestrator's state commit.
+- **Review reports are relayed as written** (step 2.3 applies unchanged).
+
+The orchestrator takes the lowest-numbered frontier ticket whose `**Status:**` is not `ready-for-human`, and reads it before dispatching: plainly human work stops the run instead of being dispatched.
+
+The run halts and reports when an implementer hits an ambiguity that would change the result (the orchestrator asks the user and continues), when a finding is still open after the one re-check (same), when a ticket cannot be finished as written, or when the frontier holds only `ready-for-human` tickets. `--max N` halts it cleanly after N tickets. Every closed ticket is already written back and committed, so stopping needs no cleanup: a ticket left at `doing` is the breakpoint, and running `/atw-implement-all` again resumes from it — or the user finishes that ticket with `/atw-implement` and runs it again. After the user finishes a `ready-for-human` ticket — by hand, or through `/atw-implement` — the next `/atw-implement-all` starts from whatever state that left: one ticket at `doing` (the per-ticket path may already have claimed the next frontier ticket, as 2.4 says) is resumed, not re-claimed; nothing at `doing` means the run claims from the frontier. A `doing` ticket after a human ticket is an expected state, not a broken one, and both branches close the ticket the same way — review, write-back, `done`, state commit. Every halt reports one table: a row per ticket with its state, commits, review verdicts and what the user was asked.
+
+When every ticket is `done`, the run itself moves the task on, then commits the `task.json` change as the run's last state commit, so it ends on a clean tree:
+
+```bash
+python3 ./.atw/scripts/task.py set-status <task-dir> accept
+```
+
 ---
 
 ## Phase 3: Finish
@@ -747,7 +775,9 @@ python3 ./.atw/scripts/tickets.py summary   # every ticket done
 git status --porcelain                      # clean tree; the chain commits as it goes
 ```
 
-After a whole-spec run the work sits on the integration branch named in `task.json.branch`. Say so in the report: merging it is the user's call, made after acceptance.
+As each criterion checks out, tick its checkbox — in `prd.md` and in the ticket that carried it. Nobody earlier in the chain ticks them (`tickets.py done` flips `**Impl:**` only), so the ticks are the acceptance record, not new work. When every criterion has been walked, commit the ticks once — `chore(task): <task> acceptance check` — so the tree is clean before stop ④.
+
+After a parallel whole-spec run (2.7) the work sits on the integration branch named in `task.json.branch`; a serial run (2.8) lands in place on the task branch. Say so in the report: merging it is the user's call, made after acceptance.
 
 **Stop ④**: present that and wait. Whether the work is done is the user's judgement, not yours — you can report that every criterion is met, but you cannot accept on their behalf.
 
@@ -775,7 +805,7 @@ Edit the corresponding step's walkthrough body in the Phase 1 / 2 / 3 sections a
 
 - No active task must triage first and ask for task-creation consent before creating an ATW task.
 - Each of the four stops must stay reachable and must stay the user's call.
-- Every execution path must keep review and spec update inside the run, never after it: before each ticket's commit on the per-ticket path, before the closing commit on the integration branch on the whole-spec path.
+- Every execution path must keep review and spec update inside the run, never after it: before each ticket's commit on the per-ticket path and the serial whole-spec path, before the closing commit on the integration branch on the parallel whole-spec path.
 
 Structure is guarded by `packages/cli/test/scripts/workflow-structure.test.ts`, which runs with `pnpm test` — there is no separate step to remember.
 

package/dist/templates/common/bundled-skills/atw-implement/SKILL.md

@@ -8,6 +8,14 @@ Implement the work described by the user in the spec or tickets.
 
 If the user passes a ticket reference, fetch it from the issue tracker and state its title before starting. If the reference is ambiguous, ask. If the tracker already marks a different ticket as in progress, stop and say so — don't switch tickets on your own.
 
+Then, before touching any code, read the ticket's `**Status:**` line. `ready-for-human` means the slicer decided a person should do this ticket. Stop there: say the ticket is marked for a human, quote the reason the ticket gives, and ask the user to pick one of two things — they do it themselves, or they explicitly authorize you to do it in their place.
+
+- Nothing short of an explicit yes counts. A question back, a vague answer or silence is not authorization: ask once more, or end the run.
+- They do it themselves: tell them to run `python3 .atw/scripts/tickets.py done NN` when finished and commit that ticket-state change, so the tree is clean for the next run. This run ends there and changes no file.
+- They authorize you: continue with the chain below. The commit you make at the end of it carries one extra line — `ready-for-human ticket implemented by AI with the user's authorization` — followed by the gist of what the user said, so the record shows who decided.
+
+A task without tickets, or a run with no ticket reference, has no `Status:` line and this step does not apply.
+
 Call the Skill tool with "atw-tdd" where possible, at pre-agreed seams.
 
 Run typechecking regularly, single test files regularly, and the full test suite once at the end.

package/dist/templates/common/bundled-skills/atw-implement-all/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: atw-implement-all
+description: "把切好工单的规格一次串行做完：主会话当指挥者，按前沿逐张派出实现子代理，每张票在主会话里审查、处理发现、回写 spec、关单、提交状态；可选 --max N 干净停，停下后再跑同一条命令从断点续上。"
+disable-model-invocation: true
+---
+
+You have been provided a spec sliced into tickets on an ATW task. This skill is the third way through stop ③: the user runs it once, and you — the main session — become the **orchestrator**. You work the ticket frontier one ticket at a time, dispatching one **implementer sub-agent** per ticket, and you run every ticket's review, findings, spec write-back, close-out and state commit yourself, in this session. It is the per-ticket `/atw-implement` chain with the "press start" removed — not the parallel `/atw-implement-spec` run: no worktrees, no integration branch, no merger, and a review per ticket instead of one at the end.
+
+Only the user starts this skill. You never invoke it yourself.
+
+This skill needs an ATW task directory (`.atw/scripts/tickets.py` exists). If it does not, tell the user to run `/atw-init-repo`.
+
+## Before the first ticket
+
+Check in this order, and stop with the named pointer when a check fails:
+
+- The current task (`python3 .atw/scripts/task.py current`) is in the `implement` stage.
+- The task has an `issues/` directory with tickets. A task with no tickets has only `/atw-implement`; tell the user to run that instead.
+- When no ticket is at `**Impl:** doing`, the working tree is clean (`git status --porcelain` prints nothing). An uncommitted change belongs to nobody once implementers start committing; ask the user to commit or discard it first. With one ticket at `doing`, uncommitted changes are that ticket's breakpoint and are left for the resumed implementer (see "Resuming").
+- The platform can dispatch sub-agents. On one that cannot, tell the user to run `/atw-implement` once per ticket.
+- Either `tickets.py frontier` is non-empty, or exactly one ticket is at `**Impl:** doing` (see "Resuming"). Two or more at `doing` while the task's `meta.ticket_mode` is not `parallel` is a contradiction: stop and let the user sort it out; do not guess. Two or more at `doing` with `ticket_mode` set to `parallel` belong to a `/atw-implement-spec` run: stop and tell the user to finish or resume that run instead.
+
+## Arguments
+
+The only argument is an optional `--max N`: close N tickets in this run, then stop cleanly and report. Nothing else is accepted — not a ticket number, not `--only`, not `--skip`. If the user passes any of those, say so and stop; the ticket to work next is always chosen by the rule below.
+
+## Your role
+
+You are the only writer of ticket state. No sub-agent edits a ticket file, `check.jsonl`, `task.json`, or anything else the tracker owns.
+
+You write no code, you do not edit ticket content, and you do not do the implementation in the implementer's place. The whole of your job is: pick, claim, dispatch, relay questions, review, triage, write back, close, commit state, report.
+
+The `- [ ]` checkboxes in the tickets and in `prd.md` are not yours either, and not the implementer's: they are ticked during the acceptance check (workflow.md 3.1), one at a time against the evidence. `tickets.py done` flips `**Impl:**` and nothing else; leave the boxes as they are.
+
+Communication to and from the implementer is sparse. Communicate through **context pointers** — to the spec, the one ticket, the research notes — and never paste their contents into the prompt.
+
+## The loop
+
+For each ticket:
+
+1. **Pick.** Run `python3 .atw/scripts/tickets.py frontier`. Take the lowest-numbered ticket whose `**Status:**` line is not `ready-for-human`. If the frontier holds only `ready-for-human` tickets, stop (see "When the run halts"). Read the ticket file before dispatching: if it is plainly human work the ticket forgot to label — an external account, a manual test pass, a design decision — stop the same way rather than dispatching it.
+
+2. **Claim.** `python3 .atw/scripts/tickets.py claim <NN>` — the plain serial claim, never `--parallel`. This writes the current-ticket line into `check.jsonl` and records `implementation_base_sha` on the task; the review step depends on both.
+
+3. **Dispatch** one general-purpose implementer sub-agent in the foreground, with the brief below. Not the `atw-implement-agent` role, which may not commit.
+
+4. **Handle the report.**
+   - It asks a question: ask the user, with your recommendation, then send the answer back to the same sub-agent and let it continue. On a platform that cannot continue a sub-agent, dispatch a fresh implementer with the answer added to the pointers.
+   - It reports the ticket cannot be finished as written: the whole run stops (see "When the run halts").
+   - It reports done with a commit: go on.
+
+5. **Review.** Call the Skill tool with "atw-code-review", with the task's `implementation_base_sha` (`task.json` → `meta`) as the fixed point; when the implementer captured screenshots, pass their paths so the review runs its Visual axis. Relay every review report to the user as written — Standards and Spec, plus Visual when the ticket changed UI — even when the verdict is "nothing found". No report reaching you is not a passing review: re-run it.
+
+6. **Triage** the findings by the table in workflow.md: spec-axis findings and standards-axis hard violations get fixed; judgement calls ship and are reported. Send the findings to fix back to the same implementer for one fix round that ends in a commit. Then re-check **only the findings that were fixed**, once. Do not start a second full review, and do not loop. Anything still open after that one re-check goes to the user — ship it, fix again, or change the spec — before you write the spec back.
+
+7. **Write back and close.** Call the Skill tool with "atw-update-spec", then `python3 .atw/scripts/tickets.py done <NN>`, then commit the spec and ticket-state changes together. Every ticket leaves two kinds of commit on the branch: the implementer's code commit(s) and your state commit.
+
+8. **Next.** If `--max N` was given and N tickets have been closed in this run, stop and report. Otherwise go back to step 1. When the frontier is empty and `tickets.py summary` shows every ticket `done`: `python3 .atw/scripts/task.py set-status <task-dir> accept`, then commit the `task.json` change as the run's last state commit, so the run ends on a clean tree. Then report; the task stage in the report is `accept`.
+
+## Implementer brief
+
+Every dispatch prompt starts with `Active task: <task path from task.py current>`, then states the role, then gives pointers and rules — nothing more:
+
+- "You are an implementer sub-agent dispatched by `/atw-implement-all`. Stop ③ is already satisfied. Do the work yourself: do not dispatch sub-agents, and do not run a code review — the orchestrator reviews this ticket when you report."
+- pointers to `prd.md`, this one ticket, `research/`, and the coding-standards files the review will hold the work to (the `check.jsonl` entries);
+- work in place on the current branch — no worktree, no new branch;
+- call the Skill tool with "atw-tdd" to build the ticket; build any part that changes what a user sees by calling the Skill tool with "atw-ui", and capture a screenshot into the task directory's `screenshots/` for each UI acceptance criterion (screen, state, viewport in the file name);
+- run typechecking and single test files regularly, and the full suite once at the end;
+- commit to the current branch yourself; do not hand a diff back;
+- do not edit any ticket file or tracker state;
+- make routine judgement calls yourself; stop and ask only when the ambiguity would change the result;
+- if the ticket cannot be finished as written — the spec is wrong or self-contradictory, the fix needs a decision nobody has made, or it reaches outside this ticket's slice — stop and report why; do not widen the scope;
+- report in under 200 words: what changed, test results, commit SHAs, screenshot paths if any, open questions.
+
+A fix-round dispatch is the same brief plus the findings to fix, and ends in a commit the same way.
+
+## Resuming
+
+Stopping is always safe: every halt leaves the spec written back and the ticket state committed for every closed ticket, and the user resumes by running the same command again.
+
+When the run starts with exactly one ticket at `**Impl:** doing`, that ticket is the breakpoint. Do not claim it again. Dispatch an implementer with the brief above plus the instruction to finish the ticket from the current git state and commit — untouched, it is implemented from scratch; changed but uncommitted, the work is finished and committed; already committed, there is nothing to do — then continue from step 4: the resumed implementer's report is handled like any other, and the review follows. The review's fixed point is the `implementation_base_sha` recorded at claim time, whichever way the earlier run broke off.
+
+## When the run halts
+
+The run comes back to the user in four situations, plus the `--max` count:
+
+1. An implementer hits an ambiguity that would change the result → ask, with a recommendation, and continue after the answer.
+2. A finding is still open after the one re-check → ask before writing the spec back, and continue after the answer.
+3. An implementer reports its ticket cannot be finished as written → the run stops. Do not paper over it, do not rewrite the ticket to fit, do not widen the scope.
+4. The frontier holds only `ready-for-human` tickets, or the next ticket is plainly human work → the run stops. Name the tickets that need the user, and say that the run continues once they are done with `/atw-implement`. Say also what the next run does: it starts from whatever state `/atw-implement` left — one ticket at `doing` (the per-ticket path may already have claimed the next frontier ticket) is resumed, not re-claimed (see "Resuming"); nothing at `doing` means the run claims from the frontier. Both ways in, the ticket is closed the same way: review, write-back, `done`, state commit.
+5. `--max N` is reached → the run stops.
+
+Every time the run halts — for a question in situations 1 and 2 as much as for a stop — and when it finishes, report one table with a row per ticket: number and title; state (`done`, `doing`, untouched); commit SHAs; review verdict per axis; what the user was asked. End with the task stage after the halt and the command that picks the run back up.

package/dist/templates/common/bundled-skills/atw-implement-all/agents/openai.yaml

@@ -0,0 +1,5 @@
+interface:
+  display_name: "ATW Implement All"
+  short_description: "一次性串行实现整份规格，逐票审查"
+policy:
+  allow_implicit_invocation: false

package/dist/templates/common/bundled-skills/atw-init-repo/references/issue-tracker-atw-local.md

@@ -36,7 +36,7 @@ On top of the standard ticket template, tickets here carry one extra line:
 
 | Field | Vocabulary | Who writes it |
 |---|---|---|
-| `Status:` | triage roles (see `triage-labels.md`) | Fixed at `ready-for-agent`. These tickets are ones you sliced yourself, so they never need triage — the field is a placeholder kept for vocabulary compatibility. |
+| `Status:` | triage roles (see `triage-labels.md`) | The slicer, when it writes the ticket. Default `ready-for-agent`: these tickets are ones you sliced yourself, so they never go through triage. Set `ready-for-human` on a ticket a person must do — it needs an external account, a manual test pass, or a design or legal decision. `/atw-implement-all` never dispatches such a ticket and stops when the frontier holds only those; `/atw-implement` confirms with the user before touching code — they do it themselves, or explicitly authorize the AI. `tickets.py` does not read this field; the frontier ignores it. |
 | `Impl:` | `ready` / `doing` / `done` | `tickets.py`. This is the field the workflow actually routes on, and the only field the parser requires. |
 
 The ticket template `tickets.py` writes also carries an empty `**Issue:**` line. It is meaningless in this variant — nothing fills it in — and `tickets.py` never reads it. Leave it or delete it; neither breaks anything.
@@ -75,6 +75,8 @@ python3 .atw/scripts/tickets.py claim <NN> --parallel  # → Impl: doing, alongs
 
 **The one parallel path is `/atw-implement-spec`.** Its orchestrator claims with `--parallel`, which lets several tickets sit at `Impl: doing`, records `implementation_base_sha` once for the whole run, and writes no current-ticket line into `$TASK/check.jsonl` — there is no single live ticket. Only the orchestrator writes ticket state; each implementer works in its own worktree.
 
+`/atw-implement-all` is not a second parallel path: its orchestrator claims with plain `claim <NN>`, one ticket at `Impl: doing` at a time, so the current-ticket line and `implementation_base_sha` are recorded per ticket exactly as on the per-ticket path. It too is the only writer of ticket state; its implementers work in place on the current branch.
+
 ## Wayfinding operations
 
 Used by `atw-map`. A map is a **discover-phase** artifact and lives in the task directory alongside everything else.

package/dist/templates/common/bundled-skills/atw-init-repo/references/issue-tracker-atw.md

@@ -44,7 +44,7 @@ On top of the standard ticket template, tickets here carry two extra lines:
 
 | Field | Vocabulary | Who writes it |
 |---|---|---|
-| `Status:` | triage roles (see `triage-labels.md`) | Fixed at `ready-for-agent`. These tickets are ones you sliced yourself, so they never need triage — the field is a placeholder kept for vocabulary compatibility. |
+| `Status:` | triage roles (see `triage-labels.md`) | The slicer, when it writes the ticket. Default `ready-for-agent`: these tickets are ones you sliced yourself, so they never go through triage. Set `ready-for-human` on a ticket a person must do — it needs an external account, a manual test pass, or a design or legal decision. `/atw-implement-all` never dispatches such a ticket and stops when the frontier holds only those; `/atw-implement` confirms with the user before touching code — they do it themselves, or explicitly authorize the AI. `tickets.py` does not read this field; the frontier ignores it. |
 | `Impl:` | `ready` / `doing` / `done` | `tickets.py`. This is the field the workflow actually routes on, and the only field the parser requires. |
 | `Issue:` | `#58`, or empty | Filled in by `github_sync.py sync-tickets`; it is also the only ticket ↔ remote-issue mapping, so there is no separate mapping table. |
 
@@ -83,6 +83,8 @@ python3 .atw/scripts/tickets.py claim <NN> --parallel  # → Impl: doing, alongs
 
 **The one parallel path is `/atw-implement-spec`.** Its orchestrator claims with `--parallel`, which lets several tickets sit at `Impl: doing`, records `implementation_base_sha` once for the whole run, and writes no current-ticket line into `$TASK/check.jsonl` — there is no single live ticket. Only the orchestrator writes ticket state; each implementer works in its own worktree.
 
+`/atw-implement-all` is not a second parallel path: its orchestrator claims with plain `claim <NN>`, one ticket at `Impl: doing` at a time, so the current-ticket line and `implementation_base_sha` are recorded per ticket exactly as on the per-ticket path. It too is the only writer of ticket state; its implementers work in place on the current branch.
+
 ## Wayfinding operations
 
 Used by `atw-map`. A map is a **discover-phase** artifact and lives in the task directory alongside everything else.

package/dist/templates/common/bundled-skills/atw-noob-mode/SKILL.md

@@ -91,7 +91,7 @@ Noob mode changes how you talk to the user. It changes nothing about what the wo
 
 - **Stages.** The first time a stage comes up, say in a few words what it is for — discover is "getting clear on what you want", specify is "writing it down so we both agree", slice is "cutting the work into small pieces", implement is "building it", accept is "checking it against what we agreed".
 - **Stops ①–④.** These are the user's decisions. Say what is being decided, what each answer leads to, and what you recommend. Never present a stop as a formality.
-- **Skills only the user can run.** When the next step is theirs to start (`/atw-spec`, `/atw-tickets`, `/atw-implement`, `/atw-implement-spec`, `/atw-askme`, `/atw-map`), say what typing it will do and why it is their call, then give the exact text to type.
+- **Skills only the user can run.** When the next step is theirs to start (`/atw-spec`, `/atw-tickets`, `/atw-implement`, `/atw-implement-spec`, `/atw-implement-all`, `/atw-askme`, `/atw-map`), say what typing it will do and why it is their call, then give the exact text to type.
 - **Asking them to confirm a file.** Do not hand over `prd.md` or a ticket list and ask "confirm?". Summarize in plain words what it commits to — what will be built, what will not, what counts as done — then point to the file.
 - **Other skills' output.** A skill with its own format keeps it. In a file (review findings, ticket tables, a spec) the content stays as that skill wants it, and what you say about it to the user follows these rules. In the reply itself (a numbered round of questions, a list of findings) the shape stays and every word inside it follows these rules — a question the user cannot read is a decision they cannot make. No skill's format outranks noob mode.
 

package/dist/templates/common/bundled-skills/atw-tickets/SKILL.md

@@ -67,6 +67,8 @@ Publish the approved tickets. **How** depends on the tracker this repo uses —
 - **File-based trackers** → consult the tracker doc's "When a skill says publish to the issue tracker" section for the directory and naming convention; write one file per ticket, numbered from `01` in dependency order (blockers first). Each file's "Blocked by" lists the numbers/titles it depends on — always written in the file, even where a mirror also draws native edges on a remote tracker, because tooling reads the line. Use the per-ticket file template below — one ticket per file, never a single combined file. **If the tracker doc defines extra ticket fields, add them on top of the template.**
 - **A real issue tracker (GitHub, Linear, …)** → publish one issue per ticket in dependency order (blockers first) so each ticket's blocking edges can reference real identifiers. Use the platform's native blocking relationship where it has one; otherwise set each ticket's "Blocked by" to the blocking issues. If the source was an existing issue, make each ticket its sub-issue (tracker doc's operation). Apply the `ready-for-agent` triage label unless instructed otherwise — the tickets are agent-grabbable by construction.
 
+Mark a ticket a person must do — it needs an external account, a manual test pass, or a design or legal decision — as `ready-for-human` instead (the tracker doc's `Status:` line, or the triage label): `/atw-implement-all` will not dispatch it, and `/atw-implement` asks the user before doing it in their place.
+
 Work the **frontier**: any ticket whose blockers are all done. For a purely linear chain that means top to bottom.
 
 Do NOT close or modify any parent issue.

package/dist/templates/common/commands/continue.md

@@ -28,7 +28,7 @@ Shows the Phase Index (Plan / Execute / Finish) with routing + skill mapping.
 - `status=specify` + no `prd.md` → **1.2** (`/atw-spec` turns the discover findings into `prd.md`)
 - `status=specify` + `prd.md` exists → **1.3**. Sub-agent-dispatch platforms curate `check.jsonl` (empty, or only a legacy `_example` placeholder row, counts as uncurated); inline platforms skip. Then **stop ②** — the user confirms `prd.md` before anything advances. After that: `task.py set-status <task> slice` if the work needs tickets, otherwise straight to **1.5**.
 - `status=slice` → **1.4** (`/atw-tickets`). Every ticket needs `**Impl:** ready` and a `**Blocked by:**` line. When they are written, run `task.py start <task>` (**1.5**).
-- `status=implement` → **2.1**. `tickets.py frontier` → `tickets.py claim NN` (never two at `doing`) → **stop ③**: the user runs `/atw-implement`; you may not invoke it or inline the work → relay both review reports verbatim → `tickets.py done NN`. Frontier empty → `task.py set-status <task> accept`. When the task has tickets, also name the other way through stop ③ — the user runs `/atw-implement-spec` once for the whole spec (**2.7**); several tickets at `doing` with `meta.ticket_mode = parallel` in `task.json` is that run in progress, not a broken state.
+- `status=implement` → **2.1**. `tickets.py frontier` → `tickets.py claim NN` (never two at `doing`) → **stop ③**: the user runs `/atw-implement`; you may not invoke it or inline the work → relay both review reports verbatim → `tickets.py done NN`. Frontier empty → `task.py set-status <task> accept`. When the task has tickets, also name the other two ways through stop ③ — the user runs `/atw-implement-spec` once for the whole spec in parallel (**2.7**), or `/atw-implement-all` once for the whole spec serially, reviewed per ticket (**2.8**); several tickets at `doing` with `meta.ticket_mode = parallel` in `task.json` is an `/atw-implement-spec` run in progress, not a broken state, and one ticket at `doing` is where `/atw-implement-all` resumes.
 - `status=accept` → **3.1**. Read-only: file anything you notice instead of fixing it. Walk the `prd.md` acceptance criteria with evidence, confirm `tickets.py summary` is all `done` and `git status --porcelain` is clean, then **stop ④** and wait for the user to accept. Once accepted, `task.py archive <task>` (**3.2**).
 - `status=completed` on a task still under `.atw/tasks/` → **3.2, unfinished**. `task.py archive` writes `completed` first, then re-parents children, then moves the directory — and it does not roll back, so a task sitting here with this status means the archive was interrupted partway. Re-run `task.py archive <task>` to finish it: every step before the move is idempotent, so the re-run redoes them and completes the move.
 

package/dist/templates/shared-hooks/inject-workflow-state.py

@@ -328,13 +328,13 @@ def _codex_mode_banner(config: dict) -> str:
             "context injection is preferred and child-side loading is the fallback. "
             "Implementation is never dispatched on the per-ticket path: code is written inside /atw-implement "
             "in the main session, which also coordinates, clarifies, updates specs, commits, and finishes. "
-            "Only a /atw-implement-spec run, started by the user, dispatches implementer sub-agents."
+            "Only a /atw-implement-spec or /atw-implement-all run, started by the user, dispatches implementer sub-agents."
         )
     else:
         meaning = (
             "inline: the main session also reviews directly; "
             "do not dispatch any ATW sub-agent. Implementation is in /atw-implement; "
-            "/atw-implement-spec needs sub-agents and is unavailable in this mode."
+            "/atw-implement-spec and /atw-implement-all need sub-agents and are unavailable in this mode."
         )
     return f"<codex-mode>{meaning}</codex-mode>"
 

package/dist/templates/snow/SNOW.md

@@ -23,7 +23,7 @@ snow
 In Snow:
 
 1. Open a session in the project root — `onSessionStart` injects ATW context automatically.
-2. Dispatch review (`atw-review`, project agent under `.snow/agents/`); implementation runs in the main session via `/atw-implement` (a `/atw-implement-spec` run dispatches its own implementers). Prefer prompt first line:
+2. Dispatch review (`atw-review`, project agent under `.snow/agents/`); implementation runs in the main session via `/atw-implement` (a `/atw-implement-spec` or `/atw-implement-all` run dispatches its own implementers). Prefer prompt first line:
 
 ```text
 Active task: .atw/tasks/<id>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@chinhae/atw-cli",
-  "version": "0.4.0",
+  "version": "0.5.0",
   "description": "A Team Workflow — an AI workflow framework that encodes your conventions into the process, for writing code and for work that isn't code",
   "type": "module",
   "main": "./dist/index.js",
@@ -33,7 +33,7 @@
     "inquirer": "^9.3.7",
     "undici": "^6.21.0",
     "zod": "^4.4.2",
-    "@chinhae/atw-core": "0.4.0"
+    "@chinhae/atw-core": "0.5.0"
   },
   "devDependencies": {
     "@eslint/js": "^9.18.0",