@chinhae/atw-cli 0.5.0 → 0.7.0

package/README.md

@@ -1,8 +1,7 @@
 <h1 align="center">A Team Workflow</h1>
 
 <p align="center">
-<strong>An AI workflow framework that encodes your conventions into the process — for writing code, and for work that isn't code.</strong><br/>
-<sub>AI works fast, but every session it starts from scratch — no memory of your project, your conventions, or what was agreed last time. ATW persists specs, tasks, and memory into your project. In <code>dev</code> mode any coding agent works to your team's engineering standards; in <code>general</code> mode the same record carries writing, research, organizing material and planning.</sub>
+<strong>ATW gives your AI coding tool a process to follow: it writes down what you agreed, stops for your OK where it matters, and remembers your project from one session to the next.</strong>
 </p>
 
 <p align="center">
@@ -13,466 +12,144 @@
 <a href="https://www.npmjs.com/package/@chinhae/atw-cli"><img src="https://img.shields.io/npm/v/@chinhae/atw-cli.svg?style=flat-square&color=2563eb" alt="npm version" /></a>
 </p>
 
-## Two modes
-
-A project is in one of two modes. The mode is a project setting — the `mode:`
-line in `.atw/config.yaml`, committed with the project and shared by everyone
-working in it — and it decides three things at once: which workflow the AI
-follows, which skills and sub-agents are installed, and whether noob mode is on
-by default.
-
-| | `dev` (the default) | `general` |
-| --- | --- | --- |
-| 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 | 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
-existed needs no change.
-
-### Choosing a mode
-
-```bash
-atw init -u your-name                  # in a terminal, asks what the project is for
-atw init --mode general -u your-name   # answers it up front
-```
-
-In a terminal, `atw init` asks a project that is not set up yet "What is this
-project mainly for?". "Writing code" is `dev`; "Other work (writing, research,
-organizing material, planning)" is `general`. `--mode dev` or `--mode general`
-answers the question up front. With `--yes`, or when it is not run from a
-terminal, the question is not asked and the project is `dev` unless `--mode`
-says otherwise.
-
-`--template` and `--registry` install coding guidelines, which a `general`
-project does not have, so `atw init` refuses them there.
-
-### Switching later
-
-```bash
-atw mode            # show the current mode
-atw mode general    # switch to general
-atw mode dev        # and back
-```
-
-`atw mode <mode>` first prints what it is about to do, file by file: what will
-be deleted, added and replaced, which files it keeps because you changed them,
-and which tasks are not archived yet. Then it asks. Nothing on disk changes
-before you confirm.
-
-- A file you edited is not deleted. It stays where it is and the output names
-  it.
-- Unarchived tasks do not block the switch. Both modes use the same task
-  statuses, so the tasks carry over.
-- `-y, --yes` switches without asking. Without a terminal and without `--yes`,
-  the command prints the full list, changes nothing and exits with status 1 —
-  so it also serves as a preview.
-- `-f, --force` replaces an edited `.atw/workflow.md` with the target mode's
-  workflow without asking.
-- Asking for the mode the project is already in changes nothing and exits
-  normally.
-- `atw init --mode` does not switch a project that is already set up; it stops
-  and points to `atw mode`.
-
-Switching to `general` leaves an existing `.atw/spec/` tree where it is, unused.
-Switching to `dev` puts the empty spec skeleton back when there is none.
-
-### What `general` keeps, and what it drops
-
-You say what you want in your own words; the AI runs the process.
-
-```
-Phase 1: Plan     talk it through → write down what was agreed → you confirm
-Phase 2: Do       the AI does the work
-Phase 3: Finish   item-by-item check → you accept → archive and journal
-```
-
-Kept:
-
-- **Task records.** Anything beyond a small request gets a directory under
-  `.atw/tasks/`. The AI creates it itself instead of asking whether to; a small
-  request is just done, with no record.
-- **Written down and confirmed.** Before starting, the AI writes what will be
-  done, what will not be done, and what counts as done into the task's
-  `prd.md`, shows it to you, and waits. When something is unclear it asks you
-  first, without being told to.
-- **Checked against what was agreed.** When the work is finished the AI goes
-  through "what counts as done" item by item, with evidence, and waits for you
-  to accept.
-- **Session memory.** After you accept, the AI archives the task and writes the
-  session journal itself. Say "continue" in a later session and it picks up
-  unfinished work. `atw mem` still searches earlier conversations.
-- **Conventions, injected.** One flat file, `.atw/spec/conventions.md`, is
-  handed to the AI at the start of every session. When you correct the AI or
-  repeat a preference, it writes the rule there itself.
-
-Dropped:
-
-- **Tickets, and two of the four stops.** There is no `slice` stage, no "create
-  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.
-- **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
-  platforms that have no session-start hook, in a version without the
-  spec-reading step. On platforms that turn commands into skills, such as
-  Codex, it shows up as a seventh skill, `atw-start`.
-- **The sub-agents.** The closing check is done by the main session, not by an
-  independent reviewer. It is less strict than `dev` review, and your acceptance
-  is what backs it.
-- **The spec tree.** No `.atw/spec/` by package and layer, and no
-  `00-bootstrap-guidelines` task to fill it in.
-- **The need for git.** A `general` project works in an ordinary folder that is
-  not a git repository.
-
-### Noob mode and project mode
-
-The two are independent. The project mode decides the process: which stages,
-which stops, which skills. Noob mode decides only how the AI talks to one
-person — plain words, terms explained where they appear, every action explained
-before it happens. It changes no stage, no stop and nothing in the task files,
-and it is personal: one line in your own `.atw/.developer`, never committed.
-
-The one link between them is the default for someone who has never chosen: on
-in a `general` project, off in a `dev` project. Your own choice comes first.
-Say "关闭小白模式" / "turn off noob mode", or run `/atw-noob-mode off`, and it
-stays off — neither the project default nor a later change of project mode
-turns it back on. `python3 ./.atw/scripts/noob_mode.py status` prints whether
-it is on, and whether that comes from your own setting or from the project
-default.
+## What it solves
+
+- **The AI forgets.** Every session starts from scratch: your project, your
+  conventions, what was agreed last time are gone. ATW keeps tasks, coding
+  conventions and session journals in your repo, and hands the relevant part to
+  the AI at the start of every session.
+- **The AI starts building before the request is clear.** ATW makes it ask
+  first, write the requirements down, and wait for you to confirm them.
+- **"Done" means whatever the AI says.** ATW walks every acceptance criterion
+  with evidence, and you are the one who signs off. In `dev` mode a separate AI
+  session reviews the work first.
+- **Every tool, and every teammate, does it differently.** The same structure
+  installs into 22 AI coding tools and is shared through the repo.
+
+## Who it's for
+
+A project is in one of two modes, chosen when you set it up:
+
+- **`dev` (the default)** — for building software, whether or not you are an
+  engineer. The full process: written requirements, work split into tickets
+  (small pieces, done one at a time), an independent review of every change.
+- **`general`** — for work that is not code: writing, research, organizing
+  material, planning. A lighter process: talk it through, write it down, do it,
+  check it.
+- **Noob mode** — a personal setting for someone who is not technical: plain
+  words, terms explained where they appear, every action explained before it
+  happens. It changes how the AI talks to you, not the process.
 
 **Not technical, but building software? Use `dev` mode with noob mode on, not
-`general`.** `general` takes away the spec, the tickets and the independent
-review, and those are the protections software needs most when you cannot read
-the code yourself. Noob mode keeps all of them and changes only the language.
-
-## Why ATW?
-
-This table describes `dev` mode, and so do [Set Up a Project](#set-up-a-project),
-[How It Works](#how-it-works) and [Skills and sub-agents](#skills-and-sub-agents)
-below, except where they say otherwise. Project memory, records shared through
-the repo and multi-platform setup hold in `general` mode as well.
-
-| Capability | What it changes |
-| --- | --- |
-| **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 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. |
+`general`.** `general` drops the requirements check, the tickets and the
+independent review — the protections software needs most when you cannot read
+the code yourself. To turn noob mode on, tell the AI "turn on noob mode".
 
-## Prerequisites
+## Quick start
 
-- **Node.js** >= 18.17
-- **Python** >= 3.9
-
-## Quick Start
+You need **Node.js** >= 18.17 and **Python** >= 3.9.
 
 ```bash
 # 1. Install ATW
 npm install -g @chinhae/atw-cli@latest
 
-# 2. Initialize in your repo
-atw init -u your-name
-
-# 3. Or initialize with the platforms you actually use
-atw init --cursor --opencode --codex -u your-name
-
-# 4. Or set the project up for work that is not code
-atw init --mode general -u your-name
-```
-
-In a terminal, `atw init` opens by asking which language its own prompts should
-use — 中文 or English — then asks a project that is not set up yet what it is
-mainly for (see [Two modes](#two-modes)), and closes by offering extra skills to
-install (see [Extra skills](#extra-skills)). With `--yes`, or when it is not run
-from a terminal, it asks none of these: the prompts stay English, the project
-is `dev` unless `--mode` says otherwise, and no extra skill is installed.
-
-## Set Up a Project
-
-This section is for a `dev` project. A `general` project needs neither step:
-`/atw-init-repo` is not installed there and there is no spec tree to fill, so
-you can start talking to the AI right after `atw init`.
-
-`atw init` writes the files. Two one-time steps make them useful. Order between
-them doesn't matter; the AI does most of the work in both.
-
-**1. Run `/atw-init-repo`.** Records three things the engineering skills assume:
-where issues live, the triage label vocabulary, and where domain docs go. Output
-is three files under `docs/agents/`, read by `atw-spec`, `atw-tickets`,
-`atw-triage`, `atw-map`, `atw-code-review` and `atw-research`. Takes a few
-minutes. You must run it yourself — the AI cannot invoke this one.
-
-**2. Fill `.atw/spec/`.** Init leaves the spec files as empty placeholders, so
-review sub-agents have no conventions to match and write generic code. Two ways
-in — pick one, they do the same job:
-
-- `python3 ./.atw/scripts/task.py start 00-bootstrap-guidelines`, then tell the
-  agent to start that task. Run the command from inside an AI session so the
-  session identity reaches the script. Checklist-driven: it asks whether an
-  existing `CLAUDE.md`, `.cursorrules` or `CONTRIBUTING.md` can be imported
-  before it reads any source.
-- `/atw-spec-bootstrap` — the same work as a skill. One agent analyses the
-  codebase and writes the docs.
-
-Close it out with `task.py finish`, then
-`task.py archive 00-bootstrap-guidelines`. After the archive, teammates who run
-`atw init` get a `00-join-<slug>` onboarding task instead of the bootstrap one.
-
-**Then commit** `.atw/`, `docs/agents/`, `.gitattributes` and `AGENTS.md`.
-Teammates should clone your conventions, not an empty scaffold.
-
-Neither step is mandatory — triage, tasks and specs all work without them. What
-you give up is concrete: sub-agents matching your patterns, and skills knowing
-where issues and research notes belong.
-
-## How It Works
-
-This is the `dev` workflow. The `general` workflow is under
-[What `general` keeps, and what it drops](#what-general-keeps-and-what-it-drops).
-
-ATW runs three phases over a six-stage task record:
-
-```
-Phase 1: Plan     discover → specify → slice (optional)
-Phase 2: Execute  implement — one ticket at a time, or the whole spec in one run
-Phase 3: Finish   accept → completed
-```
-
-**Phase 1 — Plan.** `/atw-askme` works through open requirements one question at
-a time. When the work is large and the route is unclear, `/atw-map` scans the
-territory first and files decision tickets; `/atw-research` handles external
-unknowns and `/atw-prototype` handles design questions that need a throwaway
-build — including comparing several visual directions side by side before one
-is chosen. `/atw-spec` turns the findings into `prd.md` — the requirements,
-constraints, and acceptance criteria everything downstream is checked against.
-When the work won't fit one session, `/atw-tickets` slices the confirmed spec
-into `issues/NN-*.md`.
-
-**Phase 2 — Execute.** One ticket at a time, claimed from the ready frontier.
-Each ticket runs a closed chain that must not be broken up from the outside:
-implement → run tests → review → handle findings → write learnings back to spec
-→ commit. Review is an `atw-review` sub-agent reading two axes, project
-standards and the task's own spec, and both of its reports reach you verbatim —
-including when the verdict is "nothing found". When a ticket changes what a user
-sees, `/atw-ui` builds that part on real screens and a third, Visual axis
-reviews the screenshots.
-
-**Phase 3 — Finish.** Read-only. The acceptance criteria in `prd.md` get walked
-one by one with evidence, and nothing new gets opened — things you notice become
-tickets or a follow-up task. After you accept, the task archives.
-
-### Not every request needs a task
-
-| Path | Route |
-| --- | --- |
-| Simple | No task. Just do it, skip ATW for this session. |
-| Medium | Task → discover → specify → implement |
-| Complex | Task → map → specify → slice into tickets → implement each |
-
-The threshold is deliberately not a file count — changing two files can be a
-typo fix or an auth rewrite. When unsure, go one path up: the cost of going up
-is one more `prd.md`, and the cost of going down is discovering mid-build that
-there is no record, no spec, and no review baseline.
-
-### The four stops
-
-Outside these four, the AI advances stages on its own. It does not stop to ask
-"shall we move on?".
-
-| Where | Whose call |
-| --- | --- |
-| 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, `/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
-
-```
-.atw/
-├── spec/                    coding guidelines, by package and layer
-├── tasks/MM-DD-<slug>/
-│   ├── task.json            stage, branch, metadata
-│   ├── prd.md               the spec
-│   ├── map.md               territory map — complex path only
-│   ├── issues/NN-*.md       implementation tickets (Impl / Blocked by)
-│   ├── research/<topic>.md  research notes, one file per topic
-│   └── check.jsonl          which specs the review sub-agents read
-├── workspace/<you>/         per-developer session journals
-├── workflow.md              the workflow the AI follows, in your repo
-└── scripts/                 the Python that reads and writes all of it
-```
-
-A `general` project gets a smaller tree:
-
-```
-.atw/
-├── spec/conventions.md      what you asked for more than once, injected every session
-├── tasks/MM-DD-<slug>/
-│   ├── task.json            status and metadata
-│   ├── prd.md               what will be done, what will not, what counts as done
-│   └── research/<topic>.md  notes from looking things up, one file per topic
-├── workspace/<you>/         per-person session journals
-├── workflow.md              the general workflow
-└── scripts/                 the Python that reads and writes all of it
-```
-
-`workflow.md` is a file in your project, not something baked into the CLI —
-`atw workflow` switches it between the built-in `native` template and anything
-published to the workflow marketplace, and editing it changes what the AI
-actually does. `native` is the workflow that comes with the project's mode: the
-`dev` workflow in a `dev` project, the `general` one in a `general` project.
-
-## Skills and sub-agents
-
-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`:
-
-| Skill | For |
-| --- | --- |
-| `/atw-askme` | fuzzy requirements, one question at a time (`/atw-askme-with-docs` when the answer is in project docs) |
-| `/atw-map` | large scope, unclear route — scans breadth-first and stops itself if it finds no fog |
-| `/atw-research` | external or third-party unknowns |
-| `/atw-spec` | write or revise `prd.md` |
-| `/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 |
-| `/atw-noob-mode` | plain-language mode for a user who is not an engineer: terms explained where they appear, every action explained before it happens, in every stage until switched off — say "开启小白模式" / "turn on noob mode", or run it; personal, never committed; off by default in `dev`, on by default in `general` |
-
-Three commands sit alongside them: `/atw-start` loads session context on
-platforms that have no session-start hook, `/atw-continue` resumes the current
-task at the right step, and `/atw-finish-work` archives the task and writes the
-session journal. Nothing is committed there — the implement chain commits per
-ticket, long before a task reaches it. Of the three, a `general`
-project keeps only `/atw-start`: the AI resumes and files the work itself.
-
-`/atw-implement` writes the code in your main session; `atw-review` sub-agents
-review the diff so the review does not share the implementer's context.
-
-### Extra skills
-
-On top of the built-in skills, `atw init` can install optional ones. They are
-not part of ATW: the list and the skills themselves are downloaded from
-[LFT-OXY/oxy-Tools](https://github.com/LFT-OXY/oxy-Tools) when you ask for
-them. At the end of every run — the first one and any later one in the same
-project, in either mode — init asks whether you want any, shows the list with
-one line on what each skill does, and installs the ones you tick into the skill
-directory of each configured platform.
-
-- `atw update` checks that list and replaces an installed extra skill when it
-  names another version. The skill's whole directory is replaced without
-  asking, so edits you made inside it are lost.
-- `atw uninstall` removes the extra skills ATW installed.
-- A directory of the same name that ATW did not install is never touched.
-
-## CLI
-
-```bash
-atw init          # set up this repo, optionally per-platform
-atw platforms     # show which platforms are configured here
-atw update        # pull new template bodies into this repo, refresh extra skills
-atw workflow      # list or switch the .atw/workflow.md template
-atw mode          # show the project's mode, or switch it between dev and general
-atw upgrade       # upgrade the CLI itself
-atw mem           # search conversation history across Claude Code, Codex, OpenCode, Pi
-atw channel       # multi-agent collaboration runtime
-atw ablate        # temporarily remove ATW; atw restore puts it back
-atw uninstall     # permanent removal
+# 2. Set it up in your project folder
+atw init -u your-name                      # asks what the project is for
+atw init --cursor --codex -u your-name     # or only for the tools you use
+atw init --mode general -u your-name       # or for work that is not code
 ```
 
-## FAQ
-
-<details>
-<summary><strong>How is ATW different from <code>CLAUDE.md</code>, <code>AGENTS.md</code>, or <code>.cursorrules</code>?</strong></summary>
-
-Those files are useful entry points, but they tend to become monolithic, and
-they say the same thing on every turn regardless of what you are doing. ATW adds
-a stage the work is actually in, specs scoped to the package and layer you are
-touching, a spec you confirmed before implementation started, and four points
-where the AI has to stop and ask you. A `general` project keeps the stage and
-the confirmed write-up, with one conventions file and two stops.
-
-</details>
-
-<details>
-<summary><strong>Is ATW only for Claude Code?</strong></summary>
-
-No. ATW is a project layer that works across multiple coding agents and IDEs.
-Run `atw platforms` to see what is configured in the current project.
-
-</details>
-
-<details>
-<summary><strong>What actually stops the AI from just writing code?</strong></summary>
-
-A per-turn hook reads the task's stage and injects that stage's rules into the
-session. In `discover` those rules say not to write code and not to create
-tickets yet; in `accept` they say read-only. The rules come from the
-`[workflow-state:*]` blocks in your project's `.atw/workflow.md`, so they are
-editable — and when the hook can't find them, it says so visibly instead of
-failing quietly.
-
-</details>
-
-<details>
-<summary><strong>Is ATW for solo developers or teams?</strong></summary>
-
-Both. Solo developers use it for memory and repeatable workflow. Teams get the
-larger benefit: shared standards, task boundaries, reviewable context, and
-platform portability.
-
-</details>
-
-<details>
-<summary><strong>Do I have to write every spec file manually?</strong></summary>
-
-No. Many teams start by letting AI draft specs from existing code and then
-tighten the important parts by hand. `/atw-update-spec` promotes learnings back
-as you go. ATW works best when you keep the high-signal rules explicit and
-versioned. A `general` project has no spec files to write: the AI adds to
-`.atw/spec/conventions.md` as you correct it.
-
-</details>
-
-<details>
-<summary><strong>Can teams use this without constant conflicts?</strong></summary>
-
-Yes. Personal workspace journals stay separate per developer, while shared specs
-and tasks stay in the repo where they can be reviewed and improved like any
-other project artifact.
-
-</details>
-
-<details>
-<summary><strong>Can I temporarily compare a project with and without ATW?</strong></summary>
-
-Yes. `atw ablate` temporarily removes all supported project-owned ATW
-surfaces after creating a verified recovery transaction outside the project.
-Start a fresh agent session for the comparison, then run `atw restore` to
-recover the exact prior state. Use `--dry-run` to preview either operation.
-The private recovery transaction includes exact `.atw` task, spec, and
-workspace bytes, which may contain user-authored sensitive text, and is kept
-until restore verifies successfully.
-
-This is different from `atw uninstall` (permanent removal) and
-`ATW_HOOKS=0` (hooks only). Ablation does not launch agents, manage
-worktrees, hide Git changes, or remove the global CLI, channel logs, or host
-transcripts. If a managed path changes while ablated, restore refuses all
-writes until the conflict is resolved.
-
-</details>
+3. Open your AI tool in the project and say what you want, in your own words.
+   There are no commands to learn first: the AI tells you when it needs one.
+
+A `dev` project gets more out of ATW after two one-time steps; see
+[Getting started](https://github.com/LFT-OXY/A-Team-Workflow/blob/main/docs/guide/getting-started.md).
+
+## What it looks like
+
+A request in a `dev` project, from asking to accepting. The AI moves on by
+itself everywhere except the four marked stops.
+
+> **You:** Add a "remember me" checkbox to the login page.
+>
+> **AI:** This touches sign-in, so I'd treat it as a task. With a task, I write
+> the requirements down, you confirm them before I build, and at the end I check
+> each one with you. Without one, I just make the change, with no record.
+> Create a task?
+
+**Stop 1 — does this deserve a record?** Your call.
+
+> **You:** Yes.
+>
+> **AI:** One question first: how long should "remember me" keep someone signed
+> in? … I've written the requirements to `prd.md`: what will be done, what
+> won't, and five acceptance criteria, such as "after 30 days the user has to
+> sign in again". Please read it.
+
+**Stop 2 — are the requirements right?** The AI waits until you confirm.
+
+> **You:** Looks right.
+>
+> **AI:** Confirmed. Run `/atw-implement` when you want me to start building.
+
+**Stop 3 — building starts only when you start it.** The AI cannot run this
+command itself.
+
+> **You:** /atw-implement
+>
+> **AI:** Built, tests first. A separate AI session that didn't see me write it
+> reviewed the change against the project's conventions and against `prd.md`.
+> It found one problem, which I fixed. Committed. Now the check: criterion 1 is
+> met, here is the test that shows it; … all five are met. Do you accept?
+
+**Stop 4 — "this is done."** Only you can say it.
+
+> **You:** Accepted.
+>
+> **AI:** Archived the task (filed it away as done) and wrote the session
+> journal, a short note on what happened. Next session I'll start from that
+> record.
+
+## Core ideas
+
+- **Task** — one piece of work with its own folder under `.atw/tasks/`. The
+  folder records which stage the work is in, so the AI knows where it left off.
+  A small request can skip the task; the AI asks.
+- **Requirements document** — the task's `prd.md`: what will be done, what will
+  not, and the acceptance criteria. Everything after it is checked against it.
+- **Four stops** — the only places the AI stops and waits for you: before
+  creating a task, after writing the requirements, before building starts, and
+  before archiving. `general` mode keeps two of them: confirming what was
+  written down and accepting the result.
+- **Acceptance** — at the end, every acceptance criterion is checked one by one
+  with evidence. The work is done when you accept it, not when the AI says so.
+
+## Supported AI tools
+
+Claude Code, Cursor, OpenCode, Codex, Kilo CLI, Kiro Code, Gemini CLI,
+Antigravity, Devin, Qoder, CodeBuddy, GitHub Copilot, Factory Droid, DeepSeek
+Harness (dsh), Pi Agent, Reasonix, ZCode, Trae, Oh My Pi, Grok Build, Kimi Code
+and Snow CLI — 22 in all. `atw init` sets up the ones you name, or asks.
+
+## Documentation
+
+- [Modes](https://github.com/LFT-OXY/A-Team-Workflow/blob/main/docs/guide/modes.md)
+  — `dev` and `general`, how to choose and switch, and how noob mode fits in.
+- [Getting started](https://github.com/LFT-OXY/A-Team-Workflow/blob/main/docs/guide/getting-started.md)
+  — the two one-time steps after `atw init` and which files to commit.
+- [How it works](https://github.com/LFT-OXY/A-Team-Workflow/blob/main/docs/guide/how-it-works.md)
+  — the three phases, the three paths a request can take, the four stops, and
+  what lands in your repo.
+- [Skills](https://github.com/LFT-OXY/A-Team-Workflow/blob/main/docs/guide/skills.md)
+  — every skill (instructions the AI loads for one kind of job) and who can
+  start it, skill notes, and extra skills.
+- [Command line](https://github.com/LFT-OXY/A-Team-Workflow/blob/main/docs/guide/cli.md)
+  — what each `atw` command is for.
+- [FAQ](https://github.com/LFT-OXY/A-Team-Workflow/blob/main/docs/guide/faq.md)
+  — how ATW differs from `CLAUDE.md`, what stops the AI from just writing code,
+  teams, and more.
+
+## License
 
 <p align="center">
 <a href="https://github.com/LFT-OXY/A-Team-Workflow">Repository</a> •

package/dist/cli/index.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../src/cli/index.ts"],"names":[],"mappings":"AAiBA,OAAO,EAAE,YAAY,EAAE,OAAO,EAAE,MAAM,yBAAyB,CAAC;AAMhE,OAAO,EAAE,OAAO,EAAE,YAAY,EAAE,CAAC"}
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../src/cli/index.ts"],"names":[],"mappings":"AAkBA,OAAO,EAAE,YAAY,EAAE,OAAO,EAAE,MAAM,yBAAyB,CAAC;AAOhE,OAAO,EAAE,OAAO,EAAE,YAAY,EAAE,CAAC"}