@chinhae/atw-cli 0.2.10 → 0.3.0

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

@@ -18,7 +18,7 @@ It is skipped when no screenshots were passed, and the final report says so.
 
 **This skill only reports — it edits nothing.** Neither this skill nor either sub-agent writes to a source file: not to fix a finding, not to tidy something noticed in passing. They read the frozen patch and produce findings. Hand every finding back to whoever called the review — the user, or `/atw-implement` — and let the caller decide what changes. A reviewer that fixes what it found leaves no independent record of what was wrong, and the next review reads its own edits as the baseline.
 
-The issue tracker should have been provided to you. If `docs/agents/issue-tracker.md` is missing, tell the user to call the Skill tool for `atw-init-repo`, which asks which tracker this repo uses and writes that file.
+The issue tracker should have been provided to you. If `docs/agents/issue-tracker.md` is missing, tell the user to run `/atw-init-repo`, which asks which tracker this repo uses and writes that file.
 
 ## Process
 
@@ -63,7 +63,7 @@ Look for the originating spec, in this order:
 
 ### 3. Identify the standards sources
 
-Anything in the repo that documents how code should be written, such as `CODING_STANDARDS.md` or `CONTRIBUTING.md`.
+Search the repo for every file that documents how code should be written. When `CODING_STANDARDS.md` or `CONTRIBUTING.md` exists, it must be on the list.
 
 On top of whatever the repo documents, the Standards axis always carries the **smell baseline** below — a fixed set of Fowler code smells (_Refactoring_, ch.3) that applies even when a repo documents nothing. Two rules bind it:
 
@@ -112,6 +112,8 @@ If the spec is missing, skip the Spec sub-agent and note this in the final repor
 
 This sub-agent needs a model that can view images. If none is available, skip it and say in the final report that the Visual axis did not run.
 
+Issue every sub-agent call together, in the foreground, and aggregate the reports they return.
+
 ### 5. Aggregate
 
 Present the reports under `## Standards` and `## Spec` headings — plus `## Visual` when that axis ran — verbatim or lightly cleaned. Do **not** merge or rerank findings — the axes are deliberately separate (see _Why two axes_).

package/dist/templates/common/bundled-skills/atw-codebase-design/DESIGN-IT-TWICE.md

@@ -27,7 +27,7 @@ Prompt each sub-agent with a separate technical brief (file paths, coupling deta
 - Agent 3: "Optimise for the most common caller — make the default case trivial."
 - Agent 4 (if applicable): "Design around ports & adapters for cross-seam dependencies."
 
-Include both [SKILL.md](SKILL.md) vocabulary and CONTEXT.md vocabulary in the brief so each sub-agent names things consistently with the architecture language and the project's domain language.
+Include both [SKILL.md](SKILL.md) vocabulary and GLOSSARY.md vocabulary in the brief so each sub-agent names things consistently with the architecture language and the project's domain language.
 
 Each sub-agent outputs:
 

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

@@ -7,7 +7,7 @@ description: "用于排查顽固错误和性能退化的诊断循环。当用户
 
 A discipline for hard bugs. Skip phases only when explicitly justified.
 
-When exploring the codebase, read `CONTEXT.md` (if it exists) to get a clear mental model of the relevant modules, and check ADRs in the area you're touching.
+When exploring the codebase, read `GLOSSARY.md` (if it exists) to get a clear mental model of the relevant modules, and check ADRs in the area you're touching.
 
 ## Redact
 
@@ -122,7 +122,7 @@ A correct seam is one where the test exercises the **real bug pattern** as it oc
 If a correct seam exists:
 
 1. Turn the minimised repro into a failing test at that seam.
-2. Watch it fail.
+2. Watch it fail. If you forced the red by mutating code or a fixture, `diff` against a pristine copy to prove the mutation landed before you trust it.
 3. Apply the fix.
 4. Watch it pass.
 5. Re-run the Phase 1 feedback loop against the original (un-minimised) scenario.

package/dist/templates/common/bundled-skills/atw-domain-modeling/{CONTEXT-FORMAT.md → GLOSSARY-FORMAT.md}

@@ -1,4 +1,4 @@
-# CONTEXT.md Format
+# GLOSSARY.md Format
 
 ## Structure
 
@@ -31,18 +31,18 @@ _Avoid_: Client, buyer, account
 
 ## Single vs multi-context repos
 
-**Single context (most repos):** One `CONTEXT.md` at the repo root.
+**Single context (most repos):** One `GLOSSARY.md` at the repo root.
 
-**Multiple contexts:** A `CONTEXT-MAP.md` at the repo root lists the contexts, where they live, and how they relate to each other:
+**Multiple contexts:** A `GLOSSARY-MAP.md` at the repo root lists the contexts, where they live, and how they relate to each other:
 
 ```md
-# Context Map
+# Glossary Map
 
 ## Contexts
 
-- [Ordering](./src/ordering/CONTEXT.md) — receives and tracks customer orders
-- [Billing](./src/billing/CONTEXT.md) — generates invoices and processes payments
-- [Fulfillment](./src/fulfillment/CONTEXT.md) — manages warehouse picking and shipping
+- [Ordering](./src/ordering/GLOSSARY.md) — receives and tracks customer orders
+- [Billing](./src/billing/GLOSSARY.md) — generates invoices and processes payments
+- [Fulfillment](./src/fulfillment/GLOSSARY.md) — manages warehouse picking and shipping
 
 ## Relationships
 
@@ -53,8 +53,8 @@ _Avoid_: Client, buyer, account
 
 The skill infers which structure applies:
 
-- If `CONTEXT-MAP.md` exists, read it to find contexts
-- If only a root `CONTEXT.md` exists, single context
-- If neither exists, create a root `CONTEXT.md` lazily when the first term is resolved
+- If `GLOSSARY-MAP.md` exists, read it to find contexts
+- If only a root `GLOSSARY.md` exists, single context
+- If neither exists, create a root `GLOSSARY.md` lazily when the first term is resolved
 
 When multiple contexts exist, infer which one the current topic relates to. If unclear, ask.

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

@@ -1,11 +1,11 @@
 ---
 name: atw-domain-modeling
-description: "构建并完善项目的领域模型。适用于讨论代码库术语、编写或编辑 CONTEXT.md 文件，以及记录或编辑 ADR 时。"
+description: "构建并完善项目的领域模型。适用于讨论代码库术语、编写或编辑 GLOSSARY.md 文件，以及记录或编辑 ADR 时。"
 ---
 
 # ATW Domain Modeling
 
-Actively build and sharpen the project's domain model as you design. This is the *active* discipline — challenging terms, inventing edge-case scenarios, and writing the glossary and decisions down the moment they crystallise. (Merely *reading* `CONTEXT.md` for vocabulary is not this skill — that's a one-line habit any skill can do. This skill is for when you're changing the model, not just consuming it.)
+Actively build and sharpen the project's domain model as you design. This is the *active* discipline — challenging terms, inventing edge-case scenarios, and writing the glossary and decisions down the moment they crystallise. (Merely *reading* `GLOSSARY.md` for vocabulary is not this skill — that's a one-line habit any skill can do. This skill is for when you're changing the model, not just consuming it.)
 
 ## File structure
 
@@ -13,7 +13,7 @@ Most repos have a single context:
 
 ```
 /
-├── CONTEXT.md
+├── GLOSSARY.md
 ├── docs/
 │   └── adr/
 │       ├── 0001-event-sourced-orders.md
@@ -21,29 +21,29 @@ Most repos have a single context:
 └── src/
 ```
 
-If a `CONTEXT-MAP.md` exists at the root, the repo has multiple contexts. The map points to where each one lives:
+If a `GLOSSARY-MAP.md` exists at the root, the repo has multiple contexts. The map points to where each one lives:
 
 ```
 /
-├── CONTEXT-MAP.md
+├── GLOSSARY-MAP.md
 ├── docs/
 │   └── adr/                          ← system-wide decisions
 ├── src/
 │   ├── ordering/
-│   │   ├── CONTEXT.md
+│   │   ├── GLOSSARY.md
 │   │   └── docs/adr/                 ← context-specific decisions
 │   └── billing/
-│       ├── CONTEXT.md
+│       ├── GLOSSARY.md
 │       └── docs/adr/
 ```
 
-Create files lazily — only when you have something to write. If no `CONTEXT.md` exists, create one when the first term is resolved. If no `docs/adr/` exists, create it when the first ADR is needed.
+Create files lazily — only when you have something to write. If no `GLOSSARY.md` exists, create one when the first term is resolved. If no `docs/adr/` exists, create it when the first ADR is needed.
 
 ## During the session
 
 ### Challenge against the glossary
 
-When the user uses a term that conflicts with the existing language in `CONTEXT.md`, call it out immediately. "Your glossary defines 'cancellation' as X, but you seem to mean Y — which is it?"
+When the user uses a term that conflicts with the existing language in `GLOSSARY.md`, call it out immediately. "Your glossary defines 'cancellation' as X, but you seem to mean Y — which is it?"
 
 ### Sharpen fuzzy language
 
@@ -57,11 +57,11 @@ When domain relationships are being discussed, stress-test them with specific sc
 
 When the user states how something works, check whether the code agrees. If you find a contradiction, surface it: "Your code cancels entire Orders, but you just said partial cancellation is possible — which is right?"
 
-### Update CONTEXT.md inline
+### Update GLOSSARY.md inline
 
-When a term is resolved, update `CONTEXT.md` right there. Don't batch these up — capture them as they happen. Use the format in [CONTEXT-FORMAT.md](./CONTEXT-FORMAT.md).
+When a term is resolved, update `GLOSSARY.md` right there. Don't batch these up — capture them as they happen. Use the format in [GLOSSARY-FORMAT.md](./GLOSSARY-FORMAT.md).
 
-`CONTEXT.md` should be totally devoid of implementation details. Do not treat `CONTEXT.md` as a spec, a scratch pad, or a repository for implementation decisions. It is a glossary and nothing else.
+`GLOSSARY.md` should be totally devoid of implementation details. Do not treat `GLOSSARY.md` as a spec, a scratch pad, or a repository for implementation decisions. It is a glossary and nothing else.
 
 ### Offer ADRs sparingly
 

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

@@ -5,7 +5,7 @@ argument-hint: "What will the next session be used for?"
 disable-model-invocation: true
 ---
 
-Write a handoff document summarising the current conversation so a fresh agent can continue the work. Save to the temporary directory of the user's OS - not the current workspace.
+Write a handoff document summarising the current conversation so a fresh agent can continue the work. Save to the temporary directory of the user's OS (`$TMPDIR`, else `/tmp`; `%TEMP%` on Windows) - not the current workspace.
 
 Include a "suggested skills" section in the document, naming which skills the next agent should call the Skill tool for.
 

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

@@ -6,18 +6,20 @@ disable-model-invocation: true
 
 Implement the work described by the user in the spec or tickets.
 
-Use `/atw-tdd` where possible, at pre-agreed seams.
+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.
+
+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.
 
-If the work changes what a user sees, build that part with `/atw-ui` — logic stays test-first, the UI is verified on real screens. Capture screenshots into the task directory's `screenshots/` for each UI acceptance criterion (screen, state, viewport in the file name), and look at them before calling the work done.
+If the work changes what a user sees, build that part by calling the Skill tool with "atw-ui" — logic stays test-first, the UI is verified on real screens. Capture screenshots into the task directory's `screenshots/` for each UI acceptance criterion (screen, state, viewport in the file name), and look at them before calling the work done.
 
-Once done, use `/atw-code-review` to review the work. When screenshots were captured, pass their paths so the review runs its Visual axis.
+Once done, call the Skill tool with "atw-code-review" to review the work. When screenshots were captured, pass their paths so the review runs its Visual axis.
 
 Work the findings before committing. Fix what the review raised, then re-run the tests it touched.
 
 **If the review surfaces a hard problem, stop** — the spec is wrong or self-contradictory, the fix needs a decision nobody has made, or it reaches outside this ticket's slice. Don't paper over it and don't silently widen the scope to absorb it. Say what the finding is and what it blocks, and get the decision from the user before writing more code. If the answer changes what the work is supposed to do, that change lands in the spec via the step below, not only in the code.
 
-Then use `/atw-update-spec` to fold what actually got built back into the spec. The next review's Spec axis compares code against the spec, so a spec that lags behind the code makes that axis meaningless.
+Then call the Skill tool with "atw-update-spec" to fold what actually got built back into the spec. The next review's Spec axis compares code against the spec, so a spec that lags behind the code makes that axis meaningless.
 
 Commit your work to the current branch.

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

@@ -0,0 +1,79 @@
+---
+name: atw-implement-spec
+description: "把 atw-spec 和 atw-tickets 的产出一次性实现完：按工单的阻塞关系并行派出实现子代理，全部汇到同一条集成分支，最后统一审查。"
+disable-model-invocation: true
+---
+
+You have been provided a spec. This spec should have tickets associated with it, describing how to implement the spec.
+
+The issue tracker should have been provided to you. If not, tell the user to run `/atw-init-repo`.
+
+This skill runs on sub-agents. On a platform that cannot dispatch them, stop and tell the user to run `/atw-implement` once per ticket instead.
+
+The goal is the entire spec implemented on a single **integration branch**, with every ticket resolved the way the issue tracker closes work.
+
+The tickets are not a list of steps. They are a **task graph** with blocking relationships between them. This means there is always a **frontier** of tickets which are ready to be grabbed.
+
+Communication to and from subagents should be sparse. Communicate primarily through **context pointers** — to the spec, tickets, research notes, and previous commits. Don't duplicate information already available via pointers.
+
+**Implementer subagents** should be run in the background where possible for maximum concurrency. Where the platform runs sub-agents one at a time the run still completes, one ticket after another.
+
+## Ticket state
+
+You are the only writer of ticket state. No subagent edits a ticket file, or anything else the tracker owns.
+
+Mark a ticket in progress before dispatching its implementer, and done once its work has merged into the integration branch, using the tracker doc's ticket operations. On an ATW task directory (`.atw/scripts/tickets.py` exists):
+
+```bash
+python3 .atw/scripts/tickets.py frontier               # what can start now
+python3 .atw/scripts/tickets.py claim <NN> --parallel  # before dispatching its implementer
+python3 .atw/scripts/tickets.py done <NN>              # after its merge lands
+```
+
+`--parallel` is what lets several tickets be in progress at once; a plain `claim` refuses the second one. Leave these ticket-state edits uncommitted while implementers are running — a new commit on the integration branch between an implementer's last merge and its landing costs it another merge — and commit them once, at close-out.
+
+## Steps
+
+1. Read the spec and tickets to understand the task graph.
+
+2. (optional) Use an **exploration subagent** to conduct any exploration required by the tickets — relevant codebase files or external documentation. It saves its markdown notes where the tracker doc puts research notes, or in a directory outside the repo when the tracker doc names no such place. This lets **implementer subagents** focus on implementation rather than exploration.
+
+3. Create the integration branch, named after the task. Commit the spec, the tickets, and any exploration notes saved in the repo to it first: a worktree holds only what git tracks, so an uncommitted ticket is invisible to its implementer. On an ATW task directory, record the branch with `python3 .atw/scripts/task.py set-branch <task-dir> <branch>`. If the issue tracker closes work through PRs, or the user asks for one, open a draft PR after the first merge in step 5 (a branch with no commits ahead of main can't open one), marked as closing the spec and tickets.
+
+4. Use **implementer subagents** to implement each frontier ticket, each in its own worktree on its own branch. Dispatch a general-purpose sub-agent with the brief below — not the `atw-implement-agent` role, which may not commit. Each implementer subagent:
+   - confirms its worktree is based on the integration branch before starting, and resets onto it if not;
+   - calls the Skill tool with "atw-tdd" to build the ticket;
+   - builds any part that changes what a user sees by calling the Skill tool with "atw-ui", and captures a screenshot into the task directory's `screenshots/` for each UI acceptance criterion (screen, state, viewport in the file name);
+   - commits to its own branch, and merges the integration branch tip into that branch before reporting done.
+
+5. Once an **implementer subagent** completes, merge its work to the integration branch with a **merger subagent**, then mark the ticket done.
+
+6. If this changes the **frontier** of available tickets, kick off more **implementer subagents** to work on the new tickets. This allows for maximum concurrency.
+
+7. Once all tickets are complete, call the Skill tool with "atw-code-review" on the integration branch, with the commit the branch started from as the fixed point and any captured screenshots passed for its Visual axis. Relay the review reports to the user as written. Fix all issues raised by the code review in a single **implementer subagent**. 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.
+
+8. Call the Skill tool with "atw-update-spec" to fold what actually got built back into the spec, then commit — the ticket-state edits ride in this commit.
+
+9. If a draft PR exists, mark it ready for review. Otherwise, resolve each ticket the way the issue tracker closes work, and report the integration branch.
+
+10. Clean up all **implementer subagent** worktrees.
+
+## Implementer brief
+
+Every dispatch prompt starts with `Active task: <task path>` when the repo runs the ATW task system, then states the role, then gives pointers — nothing more:
+
+- "You are an implementer subagent dispatched by `/atw-implement-spec`. Do the work yourself; do not dispatch sub-agents, and do not run a code review — the orchestrator reviews the integration branch once, at the end."
+- the integration branch name, and the worktree and branch to work in;
+- pointers to the spec, its one ticket, the exploration notes, and the coding-standards files the review will hold the work to;
+- the rules from step 4;
+- "Do not edit any ticket file or tracker state. Stay inside this ticket's slice; if the ticket cannot be finished as written, stop and report why instead of widening it."
+
+## When to stop
+
+Stop dispatching and report to the user — letting implementers already running finish, and keeping everything already merged — when:
+
+- an implementer reports its ticket cannot be finished as written, or the spec is wrong or self-contradictory;
+- a merge conflict cannot be resolved by the intent of both sides;
+- the test suite cannot be made to pass on the integration branch.
+
+Say what happened, which tickets are done, in progress, and untouched, and what decision is needed. Do not paper over it and do not rewrite a ticket to make it fit.

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

@@ -0,0 +1,5 @@
+interface:
+  display_name: "ATW Implement Spec"
+  short_description: "一次性并行实现整份规格与工单"
+policy:
+  allow_implicit_invocation: false

package/dist/templates/common/bundled-skills/atw-improve-codebase-architecture/SKILL.md

@@ -11,7 +11,7 @@ Surface architectural friction and propose **deepening opportunities** — refac
 This command is _informed_ by the project's domain model and built on a shared design vocabulary:
 
 - Call the Skill tool with "atw-codebase-design" for the architecture vocabulary (**module**, **interface**, **depth**, **seam**, **adapter**, **leverage**, **locality**) and its principles (the deletion test, "the interface is the test surface", "one adapter = hypothetical seam, two = real"). Use these terms exactly in every suggestion — don't drift into "component," "service," "API," or "boundary."
-- The domain language in `CONTEXT.md` gives names to good seams; ADRs in `docs/adr/` record decisions this command should not re-litigate.
+- The domain language in `GLOSSARY.md` gives names to good seams; ADRs in `docs/adr/` record decisions this command should not re-litigate.
 
 ## Process
 
@@ -22,7 +22,7 @@ This command is _informed_ by the project's domain model and built on a shared d
 - If the user named a direction — a module, a subsystem, a pain point — take it, and skip the inference below.
 - Otherwise, walk back a good stretch of the commit history (`git log --oneline`) to find the codebase's hot spots — the files and areas that keep coming up — and let those paths pull your attention first. If the changes are scattered with no clear hot spot, widen the net.
 
-Read the project's domain glossary (`CONTEXT.md`) and any ADRs in the area you're touching first.
+Read the project's domain glossary (`GLOSSARY.md`) and any ADRs in the area you're touching first.
 
 Then spawn a sub-agent to walk the codebase. Don't follow rigid heuristics — explore organically and note where you experience friction:
 
@@ -51,7 +51,7 @@ For each candidate, render a card with:
 
 End the report with a **Top recommendation** section: which candidate you'd tackle first and why.
 
-**Use CONTEXT.md vocabulary for the domain, and the `/atw-codebase-design` vocabulary for the architecture.** If `CONTEXT.md` defines "Order," talk about "the Order intake module" — not "the FooBarHandler," and not "the Order service."
+**Use GLOSSARY.md vocabulary for the domain, and the `/atw-codebase-design` vocabulary for the architecture.** If `GLOSSARY.md` defines "Order," talk about "the Order intake module" — not "the FooBarHandler," and not "the Order service."
 
 **ADR conflicts**: if a candidate contradicts an existing ADR, only surface it when the friction is real enough to warrant revisiting the ADR. Mark it clearly in the card (e.g. a warning callout: _"contradicts ADR-0007 — but worth reopening because…"_). Don't list every theoretical refactor an ADR forbids.
 
@@ -65,7 +65,7 @@ Once the user picks a candidate, call the Skill tool with "atw-interview" to wal
 
 Side effects happen inline as decisions crystallize — call the Skill tool with "atw-domain-modeling" to keep the domain model current as you go:
 
-- **Naming a deepened module after a concept not in `CONTEXT.md`?** Add the term to `CONTEXT.md`. Create the file lazily if it doesn't exist.
-- **Sharpening a fuzzy term during the conversation?** Update `CONTEXT.md` right there.
+- **Naming a deepened module after a concept not in `GLOSSARY.md`?** Add the term to `GLOSSARY.md`. Create the file lazily if it doesn't exist.
+- **Sharpening a fuzzy term during the conversation?** Update `GLOSSARY.md` right there.
 - **User rejects the candidate with a load-bearing reason?** Offer an ADR, framed as: _"Want me to record this as an ADR so future architecture reviews don't re-suggest it?"_ Only offer when the reason would actually be needed by a future explorer to avoid re-suggesting the same thing — skip ephemeral reasons ("not worth it right now") and self-evident ones.
 - **Want to explore alternative interfaces for the deepened module?** Call the Skill tool with "atw-codebase-design" and use its design-it-twice parallel sub-agent pattern.

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

@@ -10,7 +10,7 @@ Scaffold the per-repo configuration the engineering skills assume:
 
 - **Issue tracker** — where issues live for this repo
 - **Triage labels** — the strings used for the five canonical triage roles
-- **Domain docs** — where `CONTEXT.md` and ADRs live, and the rules for reading them
+- **Domain docs** — where `GLOSSARY.md` and ADRs live, and the rules for reading them
 
 The output is three files under `docs/agents/`, plus an `## Agent skills` block in the repo's agent instructions file. Five skills read them: `atw-spec`, `atw-tickets`, `atw-triage`, `atw-map`, `atw-code-review`. `atw-research` reads the tracker doc for where findings go.
 
@@ -24,7 +24,7 @@ Look at the current repo to understand its starting state. Read whatever exists;
 
 - `git remote -v` — is this a GitHub repo? GitLab? No remote at all?
 - `CLAUDE.md` and `AGENTS.md` at the repo root — does either exist? Is there already an `## Agent skills` section in either?
-- `CONTEXT.md` and `CONTEXT-MAP.md` at the repo root
+- `GLOSSARY.md` and `GLOSSARY-MAP.md` at the repo root
 - `docs/adr/` and any `src/*/docs/adr/` directories
 - `docs/agents/` — does this skill's prior output already exist?
 - `.scratch/` — sign that a local-markdown issue tracker convention is already in use
@@ -58,9 +58,9 @@ Record the choice in `docs/agents/issue-tracker.md`. The GitHub and GitLab templ
 
 The defaults are the five canonical roles, each label string equal to its name: `needs-triage`, `needs-info`, `ready-for-agent`, `ready-for-human`, `wontfix`. On **yes**, write them as-is. Only if the user says no — usually because their tracker already uses other names (e.g. `bug:triage` for `needs-triage`) — collect the overrides so `atw-triage` applies existing labels instead of creating duplicates.
 
-**Section C — Domain docs.** Default to **single-context** — one `CONTEXT.md` + `docs/adr/` at the repo root. This fits almost every repo; write it without asking.
+**Section C — Domain docs.** Default to **single-context** — one `GLOSSARY.md` + `docs/adr/` at the repo root. This fits almost every repo; write it without asking.
 
-Offer **multi-context** — a root `CONTEXT-MAP.md` pointing to per-context `CONTEXT.md` files — only when exploration found monorepo signals. Then confirm which layout they want.
+Offer **multi-context** — a root `GLOSSARY-MAP.md` pointing to per-context `GLOSSARY.md` files — only when exploration found monorepo signals. Then confirm which layout they want.
 
 ### 3. Confirm and edit
 
@@ -101,6 +101,8 @@ The block:
 [one-line summary of layout — "single-context" or "multi-context"]. See `docs/agents/domain.md`.
 ```
 
+When triage runs on GitHub or GitLab — the GitHub or GitLab tracker, or the ATW task directory + GitHub variant, where `atw-triage` works the repo's GitHub Issues — create each configured label the tracker lacks (`gh label create` / `glab label create`).
+
 Then write the docs files using the seed templates in this skill's `references/` directory as a starting point:
 
 - [issue-tracker-atw.md](./references/issue-tracker-atw.md) — ATW task directory + GitHub mirror

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

@@ -4,8 +4,8 @@ How the engineering skills should consume this repo's domain documentation when
 
 ## Before exploring, read these
 
-- **`CONTEXT.md`** at the repo root, or
-- **`CONTEXT-MAP.md`** at the repo root if it exists — it points at one `CONTEXT.md` per context. Read each one relevant to the topic.
+- **`GLOSSARY.md`** at the repo root, or
+- **`GLOSSARY-MAP.md`** at the repo root if it exists — it points at one `GLOSSARY.md` per context. Read each one relevant to the topic.
 - **`docs/adr/`** — read ADRs that touch the area you're about to work in. In multi-context repos, also check `src/<context>/docs/adr/` for context-scoped decisions.
 
 If any of these files don't exist, **proceed silently**. Don't flag their absence; don't suggest creating them upfront. The `atw-domain-modeling` skill (reached via `atw-askme-with-docs` and `atw-improve-codebase-architecture`) creates them lazily when terms or decisions actually get resolved.
@@ -16,31 +16,31 @@ Single-context repo (most repos):
 
 ```
 /
-├── CONTEXT.md
+├── GLOSSARY.md
 ├── docs/adr/
 │   ├── 0001-event-sourced-orders.md
 │   └── 0002-postgres-for-write-model.md
 └── src/
 ```
 
-Multi-context repo (presence of `CONTEXT-MAP.md` at the root):
+Multi-context repo (presence of `GLOSSARY-MAP.md` at the root):
 
 ```
 /
-├── CONTEXT-MAP.md
+├── GLOSSARY-MAP.md
 ├── docs/adr/                          ← system-wide decisions
 └── src/
     ├── ordering/
-    │   ├── CONTEXT.md
+    │   ├── GLOSSARY.md
     │   └── docs/adr/                  ← context-specific decisions
     └── billing/
-        ├── CONTEXT.md
+        ├── GLOSSARY.md
         └── docs/adr/
 ```
 
 ## Use the glossary's vocabulary
 
-When your output names a domain concept (in an issue title, a refactor proposal, a hypothesis, a test name), use the term as defined in `CONTEXT.md`. Don't drift to synonyms the glossary explicitly avoids.
+When your output names a domain concept (in an issue title, a refactor proposal, a hypothesis, a test name), use the term as defined in `GLOSSARY.md`. Don't drift to synonyms the glossary explicitly avoids.
 
 If the concept you need isn't in the glossary yet, that's a signal — either you're inventing language the project doesn't use (reconsider) or there's a real gap (note it for `atw-domain-modeling`).
 

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

@@ -66,11 +66,14 @@ python3 .atw/scripts/tickets.py list        # all tickets + Impl state
 python3 .atw/scripts/tickets.py frontier    # Impl: ready with all blockers done
 python3 .atw/scripts/tickets.py claim <NN>  # → Impl: doing
 python3 .atw/scripts/tickets.py done <NN>   # → Impl: done
+python3 .atw/scripts/tickets.py claim <NN> --parallel  # → Impl: doing, alongside others (`/atw-implement-spec` only)
 ```
 
 `claim` refuses tickets that aren't on the frontier, and the parser rejects blocker references that don't exist or form a cycle. `claim` also records `implementation_base_sha` and writes the ticket's path into `$TASK/check.jsonl`, which is what review sub-agents read to know which ticket is live; `done` withdraws that line.
 
-**Tickets run one at a time by default.** `claim` hard-rejects a second ticket while another is at `Impl: doing`, but that check is read-then-write — it is serial execution, not an atomic exclusive claim. Don't run two implementers against one task directory.
+**Tickets run one at a time by default.** `claim` hard-rejects a second ticket while another is at `Impl: doing`, but that check is read-then-write — it is serial execution, not an atomic exclusive claim. Don't run two implementers against one task directory by hand.
+
+**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.
 
 ## Wayfinding operations
 
@@ -91,7 +94,7 @@ These stay at the repo root, unchanged:
 
 ```text
 docs/adr/          architecture decisions          atw-domain-modeling
-CONTEXT.md         domain glossary                 atw-domain-modeling
+GLOSSARY.md        domain glossary                 atw-domain-modeling
 .out-of-scope/     rejected-concept records        atw-triage
 .atw/spec/         layered coding standards        ATW's own spec flow
 ```

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

@@ -74,11 +74,14 @@ python3 .atw/scripts/tickets.py list        # all tickets + Impl state
 python3 .atw/scripts/tickets.py frontier    # Impl: ready with all blockers done
 python3 .atw/scripts/tickets.py claim <NN>  # → Impl: doing
 python3 .atw/scripts/tickets.py done <NN>   # → Impl: done
+python3 .atw/scripts/tickets.py claim <NN> --parallel  # → Impl: doing, alongside others (`/atw-implement-spec` only)
 ```
 
 `claim` refuses tickets that aren't on the frontier, and the parser rejects blocker references that don't exist or form a cycle. `claim` also records `implementation_base_sha` and writes the ticket's path into `$TASK/check.jsonl`, which is what review sub-agents read to know which ticket is live; `done` withdraws that line.
 
-**Tickets run one at a time by default.** `claim` hard-rejects a second ticket while another is at `Impl: doing`, but that check is read-then-write — it is serial execution, not an atomic exclusive claim. Don't run two implementers against one task directory.
+**Tickets run one at a time by default.** `claim` hard-rejects a second ticket while another is at `Impl: doing`, but that check is read-then-write — it is serial execution, not an atomic exclusive claim. Don't run two implementers against one task directory by hand.
+
+**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.
 
 ## Wayfinding operations
 
@@ -101,7 +104,7 @@ These stay at the repo root, unchanged:
 
 ```text
 docs/adr/          architecture decisions          atw-domain-modeling
-CONTEXT.md         domain glossary                 atw-domain-modeling
+GLOSSARY.md        domain glossary                 atw-domain-modeling
 .out-of-scope/     rejected-concept records        atw-triage
 .atw/spec/         layered coding standards        ATW's own spec flow
 ```

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

@@ -5,8 +5,9 @@ Issues and specs for this repo live as GitHub issues. Use the `gh` CLI for all o
 ## Conventions
 
 - **Create an issue**: `gh issue create --title "..." --body "..."`. Use a heredoc for multi-line bodies.
-- **Read an issue**: `gh issue view <number> --comments`, filtering comments by `jq` and also fetching labels.
+- **Read an issue**: `gh issue view <number> --json number,title,body,labels,comments`.
 - **List issues**: `gh issue list --state open --json number,title,body,labels,comments --jq '[.[] | {number, title, body, labels: [.labels[].name], comments: [.comments[].body]}]'` with appropriate `--label` and `--state` filters.
+- **Make an issue a sub-issue of a parent**: `gh issue create --parent <parent> ...`, or `gh issue edit <parent> --add-sub-issue <child>` afterwards (`gh` 2.94+). Older `gh`: `gh api --method POST repos/<owner>/<repo>/issues/<parent>/sub_issues -F sub_issue_id=<child-db-id>` (database id, as in **Blocking** below). Without sub-issues, put `Part of #<parent>` at the top of the child body.
 - **Comment on an issue**: `gh issue comment <number> --body "..."`
 - **Apply / remove labels**: `gh issue edit <number> --add-label "..."` / `--remove-label "..."`
 - **Close**: `gh issue close <number> --comment "..."`
@@ -20,7 +21,7 @@ Infer the repo from `git remote -v` — `gh` does this automatically when run in
 When set to `yes`, PRs run through the same labels and states as issues, using the `gh pr` equivalents:
 
 - **Read a PR**: `gh pr view <number> --comments` and `gh pr diff <number>` for the diff.
-- **List external PRs for triage**: `gh pr list --state open --json number,title,body,labels,author,authorAssociation,comments` then keep only `authorAssociation` of `CONTRIBUTOR`, `FIRST_TIME_CONTRIBUTOR`, or `NONE` (drop `OWNER`/`MEMBER`/`COLLABORATOR`).
+- **List external PRs for triage**: `gh api --paginate 'repos/{owner}/{repo}/pulls?state=open' --jq '.[] | select(.author_association | IN("OWNER","MEMBER","COLLABORATOR") | not) | {number, title, author: .user.login, author_association, labels: [.labels[].name]}'`.
 - **Comment / label / close**: `gh pr comment`, `gh pr edit --add-label`/`--remove-label`, `gh pr close`.
 
 GitHub shares one number space across issues and PRs, so a bare `#42` may be either — resolve with `gh pr view 42` and fall back to `gh issue view 42`.
@@ -31,14 +32,14 @@ Create a GitHub issue.
 
 ## When a skill says "fetch the relevant ticket"
 
-Run `gh issue view <number> --comments`.
+Read it as in **Read an issue** above.
 
 ## Wayfinding operations
 
 Used by `atw-map`. The **map** is a single issue with **child** issues as tickets.
 
 - **Map**: a single issue labelled `atw-map:map`, holding the Notes / Decisions-so-far / Fog body. `gh issue create --label atw-map:map`.
-- **Child ticket**: an issue linked to the map as a GitHub sub-issue (`gh api` on the sub-issues endpoint). Where sub-issues aren't enabled, add the child to a task list in the map body and put `Part of #<map>` at the top of the child body. Labels: `atw-map:<type>` (`research`/`prototype`/`interview`/`task`). Once claimed, the ticket is assigned to the driving dev.
+- **Child ticket**: an issue linked to the map as a GitHub sub-issue (see **Make an issue a sub-issue of a parent**). Where sub-issues aren't enabled, add the child to a task list in the map body and put `Part of #<map>` at the top of the child body. Labels: `atw-map:<type>` (`research`/`prototype`/`interview`/`task`). Once claimed, the ticket is assigned to the driving dev.
 - **Blocking**: GitHub's **native issue dependencies** — the canonical, UI-visible representation. Add an edge with `gh api --method POST repos/<owner>/<repo>/issues/<child>/dependencies/blocked_by -F issue_id=<blocker-db-id>`, where `<blocker-db-id>` is the blocker's numeric **database id** (`gh api repos/<owner>/<repo>/issues/<n> --jq .id`, _not_ the `#number` or `node_id`). GitHub reports `issue_dependencies_summary.blocked_by` (open blockers only — the live gate). Where dependencies aren't available, fall back to a `Blocked by: #<n>, #<n>` line at the top of the child body. A ticket is unblocked when every blocker is closed.
 - **Frontier query**: list the map's open children (`gh issue list --state open`, scoped to the map's sub-issues / task list), drop any with an open blocker (`issue_dependencies_summary.blocked_by > 0`, or an open issue in the `Blocked by` line) or an assignee; first in map order wins.
 - **Claim**: `gh issue edit <n> --add-assignee @me` — the session's first write.

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

@@ -6,7 +6,7 @@ Issues and specs for this repo live as GitLab issues. Use the [`glab`](https://g
 
 - **Create an issue**: `glab issue create --title "..." --description "..."`. Use a heredoc for multi-line descriptions. Pass `--description -` to open an editor.
 - **Read an issue**: `glab issue view <number> --comments`. Use `-F json` for machine-readable output.
-- **List issues**: `glab issue list -F json` with appropriate `--label` filters.
+- **List issues**: `glab issue list -O json` with appropriate `--label` filters.
 - **Comment on an issue**: `glab issue note <number> --message "..."`. GitLab calls comments "notes".
 - **Apply / remove labels**: `glab issue update <number> --label "..."` / `--unlabel "..."`. Multiple labels can be comma-separated or by repeating the flag.
 - **Close**: `glab issue close <number>`. `glab issue close` does not accept a closing comment, so post the explanation first with `glab issue note <number> --message "..."`, then close.
@@ -41,6 +41,6 @@ Used by `atw-map`. The **map** is a single issue with **child** issues as ticket
 - **Map**: a single issue labelled `atw-map:map`, holding the Notes / Decisions-so-far / Fog body. `glab issue create --label atw-map:map`. (On GitLab tiers with native epics, an epic may hold the map instead; a labelled issue works everywhere.)
 - **Child ticket**: an issue carrying `Part of #<map>` at the top of its description and labels `atw-map:<type>` (`research`/`prototype`/`interview`/`task`). Once claimed, the ticket is assigned to the driving dev.
 - **Blocking**: GitLab's **native blocking link** — the canonical, UI-visible representation. Add it with the `/blocked_by #<n>` quick action, posted as a note (`glab issue note <child> --message "/blocked_by #<blocker>"`). Native blocking links are a Premium/Ultimate feature; on the free tier (or where unavailable) fall back to a `Blocked by: #<n>, #<n>` line at the top of the description. A ticket is unblocked when every blocker is closed.
-- **Frontier query**: `glab issue list -F json` scoped to the map's children, drop any with an open blocker — a native `blocked_by` link to an open issue (`glab api projects/:id/issues/:iid/links`), or an open issue in the `Blocked by` line — or an assignee; first in map order wins.
+- **Frontier query**: `glab issue list -O json` scoped to the map's children, drop any with an open blocker — a native `blocked_by` link to an open issue (`glab api projects/:id/issues/<child-iid>/links`), or an open issue in the `Blocked by` line — or an assignee; first in map order wins.
 - **Claim**: `glab issue update <n> --assignee @me` — the session's first write.
 - **Resolve**: `glab issue note <n> --message "<answer>"`, then `glab issue close <n>`, then append a context pointer (gist + link) to the map's Decisions-so-far.

package/dist/templates/common/bundled-skills/atw-init-repo/references/triage-labels.md

@@ -12,4 +12,4 @@ The skills speak in terms of five canonical triage roles. This file maps those r
 
 When a skill mentions a role (e.g. "apply the AFK-ready triage label"), use the corresponding label string from this table.
 
-Edit the right-hand column to match whatever vocabulary you actually use.
+Edit the "Label in our tracker" column to match whatever vocabulary you actually use.

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

@@ -7,14 +7,22 @@ Interview the user relentlessly until you reach a shared understanding. Map this
 
 Work the tree in **rounds**. The **frontier** is every decision whose prerequisites are already settled — the questions you can ask _now_ without guessing at answers you haven't heard yet. Ask the whole frontier in one round: number each question and give your recommended answer. Then wait for the user's answers before the next round.
 
-Each question should be formatted like so:
+Format a round like so:
 
 ```
 ❓ **Q1** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
 
+➡️ <your recommended answer>
+
+---
+
+❓ **Q2** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
+
 ➡️ <your recommended answer>
 ```
 
+Word each question so "yes" accepts your recommended answer.
+
 Each round the user answers reshapes the tree — settled decisions push the frontier outward and unblock questions that depended on them. Recompute the frontier and ask the next round. A question whose answer depends on another question still open in this round belongs to a _later_ round, not this one.
 
 Finding _facts_ is your job, never the user's. When a frontier question needs a fact from the environment (filesystem, tools, etc.), dispatch a sub-agent to find it — don't ask the user for anything you could look up yourself. Don't block on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait for the sub-agent to report — ask the rest of the frontier now. The _decisions_ are the user's — put each to them and wait.