@chinhae/atw-cli 0.2.9 → 0.3.0

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

@@ -22,7 +22,7 @@ The map is a single issue on this repo's issue tracker, labelled `atw-map:map`
 
 The map is an **index**, not a store. It lists the decisions made and points at the tickets that hold their detail; a decision lives in exactly one place — its ticket — so the map never restates it, only gists it and links.
 
-**Where the map, its child tickets, blocking, and frontier queries physically live is tracker-specific.** The issue tracker should have been provided to you. If not, tell the user to call the Skill tool for `atw-init-repo`, which asks which tracker this repo uses and writes that file. Consult the tracker doc's "Wayfinding operations" section for how _this_ repo expresses them. If no tracker has been provided, default to the local-markdown tracker.
+**Where the map, its child tickets, blocking, and frontier queries physically live is tracker-specific.** The issue tracker should have been provided to you. If not, tell the user to run `/atw-init-repo`, which asks which tracker this repo uses and writes that file. Consult the tracker doc's "Wayfinding operations" section for how _this_ repo expresses them. If no tracker has been provided, default to the local-markdown tracker.
 
 ### The map body
 
@@ -62,7 +62,7 @@ Each ticket is a **child issue** of the map; the tracker's issue id is its ident
 <the decision or investigation this ticket resolves>
 ```
 
-Each ticket carries a `atw-map:<type>` label — one of `research`, `prototype`, `interview`, `task` (see [Ticket Types](#ticket-types)).
+Each ticket carries a `atw-map:<type>` label — one of `research`, `prototype`, `interview`, `task` (see [Ticket Types](#ticket-types)). `atw-map:` labels are the only labels a map and its tickets carry, never a triage label like `ready-for-agent`: they are decisions, not implementation work. A tracker without labels records the type where its doc says — a `Type:` line in the ticket file.
 
 A session **claims** a ticket by assigning it to the dev driving the map, **first**, before any work, so concurrent sessions skip it. That assignee _is_ the claim: an open, unassigned ticket is unclaimed.
 
@@ -111,8 +111,8 @@ User invokes with a loose idea.
 1. **Name the destination.** Call the Skill tool twice, for "atw-interview" and "atw-domain-modeling", to pin down what this map is finding its way to — the spec, decision, or change. The destination fixes the scope, so it's settled first.
 2. **Map the frontier.** Interview again, **breadth-first** this time: fan out across the whole space rather than deep on any one thread, surfacing the open decisions and the first steps takeable now. **If this surfaces no fog** — the way to the destination is already clear, the whole journey small enough for one session — you don't need a map. Stop and ask the user how they'd like to proceed.
 3. **Create the map** (label `atw-map:map`): Destination and Notes filled in, Decisions-so-far empty, the fog sketched into **Not yet specified**.
-4. **Create the tickets you can specify now** as child issues of the map — then wire blocking edges in a **second pass** (issues need ids before they can reference each other). Wiring sorts them into the frontier and the blocked; everything you can't yet specify stays in the fog — the **Not yet specified** section.
-5. **Fire the research subagents.** For each `research` ticket you just created, spin up a subagent that calls the Skill tool with "atw-research" to resolve it in parallel, capturing its findings on a throwaway `research/<name>` branch with a context pointer from the ticket.
+4. **Create the tickets you can specify now** as child issues of the map — then wire blocking edges in a **second pass** (issues need ids before they can reference each other). Write cross-references in that pass too, with real ids: a placeholder `#<n>` auto-links to an unrelated issue. Wiring sorts them into the frontier and the blocked; everything you can't yet specify stays in the fog — the **Not yet specified** section.
+5. **Fire the research subagents.** For each `research` ticket you just created, spin up a subagent that calls the Skill tool with "atw-research" to resolve it in parallel, with a context pointer from the ticket to its findings. Where the tracker doc names a place for research notes, the findings go there. Otherwise capture them on a throwaway `research/<name>` branch: push it when the repo has a remote, but open no PR — it is never merged.
 6. Stop — charting is one session's work; it hand-resolves nothing.
 
 ### Work through the map
@@ -121,7 +121,7 @@ User invokes with a map (URL or number). A ticket is **optional** — without on
 
 1. Load the **map** — the low-res view, not every ticket body.
 2. Choose the ticket. If the user named one, use it. Otherwise take the first frontier ticket in order. **Claim it**: assign it to yourself before any work.
-3. Resolve it — **zoom as needed**: fetch the full body of any related or closed ticket on demand; call the Skill tool for whichever skills the `## Notes` block names. If in doubt, call the Skill tool twice, for "atw-interview" and "atw-domain-modeling".
+3. Resolve it as the type the ticket records — its `atw-map:<type>` label, or its `Type:` line on a tracker without labels (see [Ticket Types](#ticket-types)). Read that, not just the question: the question never states the type. **Zoom as needed**: fetch the full body of any related or closed ticket on demand; call the Skill tool for whichever skills the `## Notes` block names. If in doubt, call the Skill tool twice, for "atw-interview" and "atw-domain-modeling".
 4. Record the resolution: post the answer as a **resolution comment**, **close** the issue, and **append a context pointer** to the map's Decisions-so-far.
 5. Add newly-surfaced tickets (create-then-wire); graduate any fog the answer has made specifiable, clearing each graduated patch from **Not yet specified** so it lives only as its new ticket. If the answer reveals a ticket — this one or another — sits beyond the destination, **rule it out of scope** rather than resolving it on the route. If the decision invalidates other parts of the map, update or delete those tickets.
 

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

@@ -0,0 +1,101 @@
+---
+name: atw-noob-mode
+description: "小白模式：给不懂技术的用户全程用大白话沟通——术语当场解释，动手前说明要做什么、为什么、风险多大，报错和结果讲清楚影响与下一步。开启后在整个工作流里持续生效，直到用户关闭。当用户说“开启小白模式”“关闭小白模式”“说人话”，输入 /atw-noob-mode，或表示看不懂术语、授权请求、报错、命令输出时使用。"
+---
+
+# Noob Mode
+
+The user is not an engineer. They are still the one in charge: they decide what gets built, what is good enough, and what must not happen. They can only do that when they understand what you tell them and what you are about to do. An update they cannot read leaves them able to approve your work but not to review it — and then your choices ship unexamined.
+
+Noob mode keeps every reply, in every ATW stage, in language they can act on. It starts when it is switched on and lasts until the user switches it off.
+
+## Switching
+
+The user's words or the argument decide the action. With neither, turn it on.
+
+- **On** — `/atw-noob-mode`, "开启小白模式", "turn on noob mode", or the user says they cannot follow the terms, an approval prompt, an error or command output. Run `python3 ./.atw/scripts/noob_mode.py on`, then confirm in the user's language, for example: "小白模式已开启。接下来我会用大白话说明我在做什么、需要你决定什么、有什么风险。随时可以说“关闭小白模式”。" Apply everything below from that reply on, then do the catch-up in "Catching up".
+- **Off** — `/atw-noob-mode off`, "关闭小白模式", "turn off noob mode". Run `python3 ./.atw/scripts/noob_mode.py off`, confirm in one sentence, and stop applying these rules.
+- **Status** — `python3 ./.atw/scripts/noob_mode.py status`.
+
+The switch is personal: it is a line in this user's own `.atw/.developer`, which is never committed, so teammates are unaffected. While it is on, ATW hands you a `<noob-mode>` reminder at session start and on every turn — that is what makes the mode last through long conversations and new sessions. If the script fails, tell the user plainly and still follow the rules for this conversation.
+
+Never switch it off on your own, and never drift out of it because a stage is long or technical. Only the user ends it.
+
+## How you talk
+
+Reply in the user's language. Keep commands, paths, file names, flags and error codes exactly as they are, and explain them beside the original.
+
+1. **The point first.** Verdict, then the reason, then the trade-off. Never build up to a buried conclusion.
+2. **Explain a term where it appears.** If a real term is unavoidable, give its meaning in the same sentence: "I'll merge it — that makes these changes part of the official version." This covers shorthand (PR, CI, repo, lint, diff, staging) and anything you coined during the session. Everyday words — file, folder, link, copy, save — need no explanation. If you would not know a term's exact meaning yourself, say so, and still say what it is for.
+3. **Paths and file names are jargon too.** The first time one matters, say which folder, which file and what kind of file it is. After that the short form is fine.
+4. **Say who did what.** You, the user, or an automatic check — every time. "I ran the tests" and "the tests ran" are different sentences to someone who cannot tell who acted.
+5. **Seen versus expected.** Everything you claim is either something you watched happen or something you predict. Keep them apart. If you did not run it, "works", "fixed" and "verified" are not yours to use — say "not run yet".
+6. **Say when you are guessing.** A file name, option, version or number that came from memory rather than from looking is a guess. Say so, and say how to settle it. An estimate is called an estimate.
+7. **Name the decisions you made for them.** A shortcut, a placeholder standing in for the real thing, a skipped check, a silenced warning, an outside package, a change wider than asked, a pick between two defensible options — report each one where it happened: what you chose, why, and what it costs later. They cannot overrule a decision they never heard about.
+8. **Alarming words are usually routine.** An error, a failed build, a conflict — name it calmly and say what it means for them right now.
+
+## Before you act
+
+Before any step the user must approve, and before anything hard to undo even when no approval is asked, say four things:
+
+- **What** — exactly what will happen and what it touches.
+- **Why** — how it serves what they asked for.
+- **Risk** — a level from the table, the reason for it, and whether it can be undone.
+- **Their choice** — what follows if they approve, and what follows if they decline.
+
+Rate the effect, not the tool: a command is not dangerous because it is a command, and a click is not safe because it is a click.
+
+| Risk | What it covers |
+|---|---|
+| Low | Only reading or looking: opening a file, listing, searching. Nothing changes. |
+| Medium | Changes that can be put back: creating or editing files, installing the project's own dependencies, local project state. |
+| High | Deleting or overwriting, running code from an unknown source, uploading private data, changing what teammates share. |
+| Critical | Passwords and keys, system-wide settings, live systems real users depend on, money, publishing, anything outside that cannot be taken back. |
+
+Name a backup, history or undo path only when one really exists. Do not invent an approval step where the tool asks for none; routine reading needs no ceremony.
+
+For work with more than two steps the user will notice, give a short roadmap first — outcomes, not tool calls — then report at real milestones. Do not narrate every internal step.
+
+## When something comes back
+
+Never leave raw output as the whole answer. Keep the exact lines they may need to pass on, then say it plainly.
+
+- **An error** — what failed, whether any of their work or data changed, why (what you verified apart from what you suspect), and the smallest safe next step.
+- **A success** — what worked, the result that matters, and what changed.
+- **A sub-agent's report** — a sub-agent reports to you in engineer's terms. Retell it under these same rules, and keep "it ran this" apart from "it says this should work".
+
+## When they must choose
+
+Ask only when the answer changes the result or the risk. For each option that really differs: what it does, its main benefit, its main cost. Then say which you recommend and why. When a safe, standard default clearly follows from what they asked, take it and say that you did.
+
+## When work is done
+
+Report only what happened: the result, what was created, changed or deleted, what you actually checked, and how to undo it — when a real way exists. For something that cannot be undone, say so.
+
+## Inside the ATW workflow
+
+Noob mode changes how you talk to the user. It changes nothing about what the workflow requires or what you write into task files — `prd.md`, tickets and specs keep their normal form, because other tools and agents read them.
+
+- **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.
+- **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 (review findings, ticket tables, a spec) keeps its format in the file. What you say about it to the user follows these rules.
+
+## Catching up
+
+These rules often arrive late, with engineer's language already sitting unread above. When noob mode is switched on mid-conversation, reread your own earlier replies and repair what still matters, oldest first, one line each:
+
+1. Risky or hard-to-undo things you already did — what happened and whether it can still be reversed.
+2. Predictions you wrote as results — separate what you watched from what you assumed.
+3. Decisions you made for them that went by unmarked.
+4. Terms, paths and numbers they still have to act on.
+
+End with whatever now needs their decision. Restate, do not revise: never drop an earlier caveat or let an old guess harden into a fact. If nothing needs repair, say so in one sentence.
+
+## Limits
+
+- This is not dumbing down. Every real fact, gap and caveat stays; only the private vocabulary goes. When clear and complete conflict, cut for clarity and offer the rest.
+- Never call the user non-technical, and never make them feel small for asking.
+- Short by default. Say more when they ask or are still lost.
+- Prefer the least destructive way to do what they asked.

package/dist/templates/common/bundled-skills/atw-noob-mode/agents/openai.yaml

@@ -0,0 +1,3 @@
+interface:
+  display_name: "ATW Noob Mode"
+  short_description: "全程用大白话解释操作、授权、报错和结果"

package/dist/templates/common/bundled-skills/atw-prototype/scripts/build_explorer.py

@@ -51,25 +51,25 @@ class AssetCheck(HTMLParser):
         self.head_position = None
 
     def handle_starttag(self, tag: str, attrs: list) -> None:
-        attrs = dict(attrs)
+        attributes = dict(attrs)
         if tag == "head" and self.head_position is None:
-            self.head_position = (self.getpos(), self.get_starttag_text())
+            self.head_position = (self.getpos(), self.get_starttag_text() or "")
         if tag in ("iframe", "frame", "object", "embed"):
             raise ValueError("候选 HTML 不支持嵌套文档；请提供静态内容或截图")
         if tag == "style":
             self.in_style = True
-        if attrs.get("style"):
-            self.styles.append(attrs["style"])
+        if attributes.get("style"):
+            self.styles.append(attributes["style"])
         if tag == "base":
             raise ValueError("候选 HTML 不应包含 base；资源需要内嵌")
-        if tag == "meta" and attrs.get("http-equiv", "").lower() == "refresh":
+        if tag == "meta" and attributes.get("http-equiv", "").lower() == "refresh":
             raise ValueError("候选 HTML 不应自动跳转")
         for key in ("src", "poster", "data", "href", "xlink:href"):
-            value = attrs.get(key, "") or ""
+            value = attributes.get(key, "") or ""
             if not value or value.startswith(("#", "data:")):
                 continue
             raise ValueError(f"候选 HTML 含未内嵌资源 {tag}.{key}: {value}")
-        if attrs.get("srcset"):
+        if attributes.get("srcset"):
             raise ValueError("候选 HTML 请用内嵌 src 代替 srcset")
 
     def handle_endtag(self, tag: str) -> None:
@@ -251,6 +251,7 @@ def load_manifest(path: Path) -> tuple[dict, set[Path]]:
             source = None
             url = local_url(text_field(candidate, "url"), identifier)
         else:
+            url = None
             source = (path.parent / text_field(candidate, "source")).resolve()
             if not source.is_relative_to(path.parent) or not source.is_file():
                 raise ValueError(f"候选 source 必须是 manifest 目录内可读文件: {identifier}")
@@ -258,12 +259,17 @@ def load_manifest(path: Path) -> tuple[dict, set[Path]]:
         colors = text_list(candidate, "palette")
         if any(not re.fullmatch(r"#(?:[0-9a-fA-F]{3}|[0-9a-fA-F]{4}|[0-9a-fA-F]{6}|[0-9a-fA-F]{8})", c) for c in colors):
             raise ValueError(f"{identifier}: palette 需要十六进制颜色")
+        if source is None:
+            content = source_label = url
+        else:
+            content = prepare_html(source, interactive, path.parent, inputs) if kind == "html" else prepare_image(source)
+            source_label = source.name
         output.append({
             "id": identifier,
             **{name: text_field(candidate, name) for name in ("name", "concept", "typography")},
             "palette": colors, "traits": text_list(candidate, "traits"), "kind": kind,
-            "content": url if kind == "url" else prepare_html(source, interactive, path.parent, inputs) if kind == "html" else prepare_image(source),
-            "sourceLabel": url if kind == "url" else source.name,
+            "content": content,
+            "sourceLabel": source_label,
             "baseline": baseline,
             "interactive": interactive,
         })

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

@@ -6,7 +6,7 @@ disable-model-invocation: true
 
 This skill takes the current conversation context and codebase understanding and produces a spec. Do NOT interview the user — just synthesize what you already know.
 
-The issue tracker and triage label vocabulary should have been provided to you. If not, tell the user to call the Skill tool for `atw-init-repo`, which writes both.
+The issue tracker and triage label vocabulary should have been provided to you. If not, tell the user to run `/atw-init-repo`, which writes both.
 
 ## Process
 

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

@@ -7,7 +7,7 @@ description: "测试驱动开发。当用户希望采用“先测试后开发”
 
 TDD is the red → green loop. This skill is the reference that makes that loop produce tests worth keeping: what a good test is, where tests go, the anti-patterns, and the rules of the loop. Every section applies on every cycle — consult them before and during the loop, not after.
 
-When exploring the codebase, read `CONTEXT.md` (if it exists) so test names and interface vocabulary match the project's domain language, and respect ADRs in the area you're touching.
+When exploring the codebase, read `GLOSSARY.md` (if it exists) so test names and interface vocabulary match the project's domain language, and respect ADRs in the area you're touching.
 
 ## What a good test is
 
@@ -21,7 +21,7 @@ A **seam** is the public boundary you test at: the interface where you observe b
 
 **Test only at pre-agreed seams.** Before writing any test, write down the seams under test and confirm them with the user. No test is written at an unconfirmed seam. You can't test everything — agreeing the seams up front is how testing effort lands on the critical paths and complex logic instead of every edge case.
 
-Ask: "What's the public interface, and which seams should we test?"
+Ask: "What's the public interface, and which seams should we test?" Give each proposed seam a one-line note on what it catches and what it misses.
 
 When the shape of that interface is itself in question — how deep the module is, where the seam belongs, what the interface should expose — call the Skill tool with "atw-codebase-design" for the vocabulary. It is the shared source of the module, interface, depth, seam, adapter, leverage and locality terms, and it is a reference to consult, not a session to run.
 

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

@@ -8,7 +8,7 @@ disable-model-invocation: true
 
 Break a plan, spec, or conversation into a set of **tickets** — tracer-bullet vertical slices, each declaring the tickets that **block** it.
 
-The issue tracker and triage label vocabulary should have been provided to you. If not, tell the user to call the Skill tool for `atw-init-repo`, which writes both.
+The issue tracker and triage label vocabulary should have been provided to you. If not, tell the user to run `/atw-init-repo`, which writes both.
 
 ## Process
 
@@ -64,8 +64,8 @@ Iterate until the user approves the breakdown.
 
 Publish the approved tickets. **How** depends on the tracker this repo uses — the tickets are the same either way, only the shape of the blocking edges changes:
 
-- **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. 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 / sub-issue relationship where it has one; otherwise set each ticket's "Blocked by" to the blocking issues. Apply the `ready-for-agent` triage label unless instructed otherwise — the tickets are agent-grabbable by construction.
+- **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.
 
 Work the **frontier**: any ticket whose blockers are all done. For a purely linear chain that means top to bottom.
 
@@ -104,7 +104,7 @@ The end-to-end behaviour this ticket makes work, from the user's perspective —
 
 ## Blocked by
 
-- A reference to each blocking ticket, or "None — can start immediately".
+- A reference to each blocking ticket, or "None — can start immediately". Omit this section when blockers were set as native edges.
 
 </issue-template>
 

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

@@ -40,7 +40,7 @@ For a PR, the same states read against the attached code: `ready-for-agent` mean
 
 Every triaged issue should carry exactly one category role and one state role. If state roles conflict, flag it and ask the maintainer before doing anything else.
 
-These are canonical role names — the actual label strings used in the issue tracker may differ. The mapping should have been provided to you. If not, tell the user to call the Skill tool for `atw-init-repo`, which writes `docs/agents/triage-labels.md`.
+These are canonical role names — the actual label strings used in the issue tracker may differ. The mapping should have been provided to you. If not, tell the user to run `/atw-init-repo`, which writes `docs/agents/triage-labels.md`.
 
 State transitions: an unlabeled issue normally goes to `needs-triage` first; from there it moves to `needs-info`, `ready-for-agent`, `ready-for-human`, or `wontfix`. `needs-info` returns to `needs-triage` once the reporter replies. The maintainer can override at any time — flag transitions that look unusual and ask before proceeding.
 
@@ -73,7 +73,7 @@ Show counts and a one-line summary per item. Let the maintainer pick.
 
 3. **Verify the claim.** Before any interview, check that the claim holds up. For a bug, reproduce it from the reporter's steps. For a PR, confirm the diff does what it claims — check it out, run the relevant tests or commands. Report what happened: confirmed (with code path), failed, or insufficient detail (a strong `needs-info` signal). A confirmed verification makes a much stronger agent brief.
 
-4. **Interview (if needed).** If the request needs fleshing out, call the Skill tool twice, for "atw-interview" and "atw-domain-modeling" — interview a round of questions at a time, sharpening domain terms and updating `CONTEXT.md`/ADRs inline as decisions land.
+4. **Interview (if needed).** If the request needs fleshing out, call the Skill tool twice, for "atw-interview" and "atw-domain-modeling" — interview a round of questions at a time, sharpening domain terms and updating `GLOSSARY.md`/ADRs inline as decisions land.
 
 5. **Apply the outcome:**
    - `ready-for-agent` — post an agent brief comment ([AGENT-BRIEF.md](AGENT-BRIEF.md)).

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`.
+- `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=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/opencode/plugins/inject-workflow-state.js

@@ -168,6 +168,30 @@ function getActiveTask(ctx, platformInput = null) {
   }
 }
 
+// Fallback for a workflow.md without a [workflow-state:noob_mode] block
+// (custom workflow template, or one older than the feature). Keep in sync with
+// FALLBACK_REMINDER in .atw/scripts/common/noob_mode.py.
+const NOOB_MODE_FALLBACK =
+  "Noob mode is ON — this user is not an engineer. Hold to the " +
+  "`/atw-noob-mode` rules in every reply: plain words in the user's " +
+  "language, and every term, command or path explained where it appears."
+
+/**
+ * The <noob-mode> block for a developer who switched noob mode on, else "".
+ * Mirrors noob_mode_reminder() in .atw/scripts/common/noob_mode.py: the
+ * switch is a `noob_mode=on` line in the gitignored .atw/.developer.
+ */
+function buildNoobModeReminder(directory, templates) {
+  let developer
+  try {
+    developer = readFileSync(join(directory, ".atw", ".developer"), "utf-8")
+  } catch {
+    return ""
+  }
+  if (!/^noob_mode=on\s*$/m.test(developer)) return ""
+  return `<noob-mode>\n${templates.noob_mode || NOOB_MODE_FALLBACK}\n</noob-mode>`
+}
+
 /**
  * Build the <workflow-state>...</workflow-state> block.
  * - Known status (tag present in workflow.md) → detailed body
@@ -225,8 +249,12 @@ export default async ({ directory }) => {
           const breadcrumb = task
             ? buildBreadcrumb(task.id, task.status, templates, task.source)
             : buildBreadcrumb(null, "no_task", templates)
+          const noobMode = buildNoobModeReminder(directory, templates)
 
-          prependEphemeralText(messages, breadcrumb)
+          prependEphemeralText(
+            messages,
+            noobMode ? `${breadcrumb}\n\n${noobMode}` : breadcrumb,
+          )
           debugLog(
             "workflow-state",
             "Injected breadcrumb for task",

package/dist/templates/shared-hooks/inject-subagent-context.py

@@ -69,6 +69,12 @@ TICKET_BLOCKED_PREFIX = "**Blocked by:**"
 NO_CURRENT_TICKET = "No ticket in progress"
 MULTI_DOING_HEADLINE = "Multiple tickets marked doing"
 
+# `tickets.py claim --parallel` (the /atw-implement-spec run) marks the task
+# here. With it set, several `doing` tickets are the run, not a contradiction.
+META_TICKET_MODE = "ticket_mode"
+TICKET_MODE_PARALLEL = "parallel"
+PARALLEL_RUN_HEADLINE = "Parallel run"
+
 # =============================================================================
 # Subagent Constants (change here to rename subagent types)
 # =============================================================================
@@ -609,6 +615,17 @@ def scan_tickets(repo_root: str, task_dir: str) -> tuple[list[str], list[tuple[s
     return doing, frontier
 
 
+def is_parallel_run(repo_root: str, task_dir: str) -> bool:
+    """Whether ``tickets.py claim --parallel`` put this task in parallel mode."""
+    task_json = Path(repo_root) / task_dir / FILE_TASK_JSON
+    try:
+        data = json.loads(task_json.read_text(encoding="utf-8"))
+    except (OSError, ValueError):
+        return False
+    meta = data.get("meta") if isinstance(data, dict) else None
+    return isinstance(meta, dict) and meta.get(META_TICKET_MODE) == TICKET_MODE_PARALLEL
+
+
 def ticket_conflict_notice(repo_root: str, task_dir: str) -> str:
     """One-line warning for agents that do not consume the ticket axis.
 
@@ -620,7 +637,7 @@ def ticket_conflict_notice(repo_root: str, task_dir: str) -> str:
     only; no ticket content crosses this path while the state is broken.
     """
     doing, _ = scan_tickets(repo_root, task_dir)
-    if len(doing) < 2:
+    if len(doing) < 2 or is_parallel_run(repo_root, task_dir):
         return ""
     return (
         f"=== Ticket State ===\n"
@@ -640,12 +657,21 @@ def get_ticket_context(
     """Current ticket in full + frontier summary, injected every round.
 
     Raises MultipleTicketsDoing when the ticket state contradicts itself.
+    A parallel run holds several tickets at ``doing`` on purpose: those are
+    listed, and none is singled out as the current one.
     """
     doing, frontier = scan_tickets(repo_root, task_dir)
-    if len(doing) > 1:
+    if len(doing) > 1 and not is_parallel_run(repo_root, task_dir):
         raise MultipleTicketsDoing(doing)
 
-    if doing:
+    if len(doing) > 1:
+        in_progress = "\n".join(f"- {rel}" for rel in doing)
+        current = (
+            f"=== Tickets In Progress ===\n"
+            f"{PARALLEL_RUN_HEADLINE}: {len(doing)} tickets are in progress at "
+            f"once, so there is no single current ticket:\n{in_progress}"
+        )
+    elif doing:
         current = _materialize_artifact(
             repo_root,
             doing[0],

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

@@ -326,13 +326,15 @@ def _codex_mode_banner(config: dict) -> str:
         meaning = (
             "auto: review work is dispatched to atw-review sub-agents; native Codex "
             "context injection is preferred and child-side loading is the fallback. "
-            "Implementation is never dispatched: code is written inside /atw-implement "
-            "in the main session, which also coordinates, clarifies, updates specs, commits, and finishes."
+            "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."
         )
     else:
         meaning = (
             "inline: the main session also reviews directly; "
-            "do not dispatch any ATW sub-agent. Implementation is in /atw-implement either way."
+            "do not dispatch any ATW sub-agent. Implementation is in /atw-implement; "
+            "/atw-implement-spec needs sub-agents and is unavailable in this mode."
         )
     return f"<codex-mode>{meaning}</codex-mode>"
 
@@ -381,6 +383,24 @@ def build_breadcrumb(
     return f"<workflow-state>\n{header}\n{body}\n</workflow-state>"
 
 
+def _noob_mode_reminder(root: Path) -> str:
+    """The `<noob-mode>` block for a developer who switched noob mode on, else "".
+
+    Riding on the per-turn breadcrumb is the point of the feature: a skill
+    loaded once fades over a long conversation, this is said again every turn.
+    An install whose scripts predate the helper simply has no noob mode.
+    """
+    scripts_dir = root / ".atw" / "scripts"
+    if str(scripts_dir) not in sys.path:
+        sys.path.insert(0, str(scripts_dir))
+    try:
+        from common.noob_mode import noob_mode_reminder  # type: ignore[import-not-found]
+
+        return noob_mode_reminder(root)
+    except Exception:
+        return ""
+
+
 # ---------------------------------------------------------------------------
 # Entry
 # ---------------------------------------------------------------------------
@@ -460,6 +480,10 @@ def main() -> int:
         parts.append(breadcrumb)
         breadcrumb = "\n\n".join(parts)
 
+    noob_mode = _noob_mode_reminder(root)
+    if noob_mode:
+        breadcrumb = f"{breadcrumb}\n\n{noob_mode}"
+
     # Kiro (CLI userPromptSubmit / IDE promptSubmit) adds a hook's stdout
     # directly to the conversation context — no JSON envelope. Emit the bare
     # breadcrumb text. Conditionally isolated: all other platforms keep the

package/dist/templates/shared-hooks/session-start.py

@@ -82,6 +82,25 @@ This notice is one-shot: do not repeat it after the first visible assistant repl
 FIRST_REPLY_NOTICE = f"{_FIRST_REPLY_NOTICE_HEAD}\n{_FIRST_REPLY_NOTICE_TAIL}"
 
 
+def _noob_mode_reminder(project_dir: Path) -> str:
+    """The `<noob-mode>` block for a developer who switched noob mode on, else "".
+
+    Platforms with a per-turn hook hear this again every turn; here it covers
+    the ones that only have SessionStart (Cursor) and the first reply of a
+    session everywhere. An install whose scripts predate the helper simply has
+    no noob mode.
+    """
+    scripts_dir = project_dir / ".atw" / "scripts"
+    if str(scripts_dir) not in sys.path:
+        sys.path.insert(0, str(scripts_dir))
+    try:
+        from common.noob_mode import noob_mode_reminder  # type: ignore[import-not-found]
+
+        return noob_mode_reminder(project_dir)
+    except Exception:
+        return ""
+
+
 def _build_first_reply_notice(update_hint: str | None) -> str:
     """First-reply notice, carrying the ATW update reminder when there is one.
 
@@ -815,6 +834,10 @@ ATW compact SessionStart context. Use it to orient the session; load details on
     output.write(_build_first_reply_notice(_resolve_update_hint(atw_dir, context_key)))
     output.write("\n\n")
 
+    noob_mode = _noob_mode_reminder(project_dir)
+    if noob_mode:
+        output.write(f"{noob_mode}\n\n")
+
     # Legacy migration warning
     legacy_warning = _check_legacy_spec(atw_dir, is_mono, packages)
     if legacy_warning:

package/dist/templates/snow/SNOW.md

@@ -22,7 +22,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`. 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` run dispatches its own implementers). Prefer prompt first line:
 
 ```text
 Active task: .atw/tasks/<id>

package/dist/utils/file-writer.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"file-writer.d.ts","sourceRoot":"","sources":["../../src/utils/file-writer.ts"],"names":[],"mappings":"AAQA,MAAM,MAAM,SAAS,GAAG,KAAK,GAAG,OAAO,GAAG,MAAM,GAAG,QAAQ,CAAC;AAE5D,MAAM,WAAW,YAAY;IAC3B,IAAI,EAAE,SAAS,CAAC;CACjB;AASD,wBAAgB,YAAY,CAAC,IAAI,EAAE,SAAS,GAAG,IAAI,CAElD;AAED,wBAAgB,YAAY,IAAI,SAAS,CAExC;AAkBD;;;;;;;;;GASG;AACH,wBAAgB,oBAAoB,CAAC,GAAG,EAAE,MAAM,GAAG,GAAG,CAAC,MAAM,CAAC,CAK7D;AAED,uFAAuF;AACvF,wBAAgB,mBAAmB,IAAI,IAAI,CAG1C;AAsCD;;;;;;;;GAQG;AACH,wBAAsB,SAAS,CAC7B,QAAQ,EAAE,MAAM,EAChB,OAAO,EAAE,MAAM,EACf,OAAO,CAAC,EAAE;IAAE,UAAU,CAAC,EAAE,OAAO,CAAA;CAAE,GACjC,OAAO,CAAC,OAAO,CAAC,CA0HlB;AAED;;GAEG;AACH,wBAAgB,SAAS,CAAC,OAAO,EAAE,MAAM,GAAG,IAAI,CAE/C"}
+{"version":3,"file":"file-writer.d.ts","sourceRoot":"","sources":["../../src/utils/file-writer.ts"],"names":[],"mappings":"AASA,MAAM,MAAM,SAAS,GAAG,KAAK,GAAG,OAAO,GAAG,MAAM,GAAG,QAAQ,CAAC;AAE5D,MAAM,WAAW,YAAY;IAC3B,IAAI,EAAE,SAAS,CAAC;CACjB;AASD,wBAAgB,YAAY,CAAC,IAAI,EAAE,SAAS,GAAG,IAAI,CAElD;AAED,wBAAgB,YAAY,IAAI,SAAS,CAExC;AAkBD;;;;;;;;;GASG;AACH,wBAAgB,oBAAoB,CAAC,GAAG,EAAE,MAAM,GAAG,GAAG,CAAC,MAAM,CAAC,CAK7D;AAED,uFAAuF;AACvF,wBAAgB,mBAAmB,IAAI,IAAI,CAG1C;AAsCD;;;;;;;;GAQG;AACH,wBAAsB,SAAS,CAC7B,QAAQ,EAAE,MAAM,EAChB,OAAO,EAAE,MAAM,EACf,OAAO,CAAC,EAAE;IAAE,UAAU,CAAC,EAAE,OAAO,CAAA;CAAE,GACjC,OAAO,CAAC,OAAO,CAAC,CAgLlB;AAED;;GAEG;AACH,wBAAgB,SAAS,CAAC,OAAO,EAAE,MAAM,GAAG,IAAI,CAE/C"}