@pmelab/gtd 6.14.0 → 7.1.0

package/README.md

@@ -49,28 +49,28 @@ Or run without installing:
 npx @pmelab/gtd
 ```
 
-Then scaffold the workflow for the repo — run once:
+That's it — gtd ships the **unified** workflow as its **built-in default**, so a
+state command works out of the box with no configuration at all.
+
+Optionally, seed the settings a project usually tunes — run once:
 
 ```bash
 gtd init
 ```
 
-This writes a `.gtdrc.json` for the bundled unified workflow, with each agent
-state's prompt saved as an editable Markdown file under `gtd-prompts/` and
-referenced from the config (review and commit both). Edit a prompt by editing
-its `gtd-prompts/*.md` file — no config edit needed. File references resolve
-relative to **the `.gtdrc` that declares them**, so a config and its
-`gtd-prompts/` can even live in a parent directory shared across repos while gtd
-runs from each repo root — run `gtd init` from that parent directory (it need
-not be a git repo) to scaffold it there (see
-[Configuration](docs/configuration.md#content-values-inline-or-a-file-reference)).
-It also seeds a top-level `modes:` block suggesting **Prettier** as the
-steering-file formatter (`npx prettier --write` for the built-in `qa`/`review`
-modes — format only, so gtd still validates); edit or drop it freely (swap in
-dprint, a script, or delete the key). `gtd init` takes no argument. gtd ships
-**no** default workflow: a state command run before `gtd init` fails, pointing
-you back here. See [Configuration](docs/configuration.md#gtd-init) for the
-template.
+This writes a minimal `.gtdrc.json` seeding the one variable most projects
+change — the test command (`vars.testCommand`, defaulting to `npm test`) — plus
+a top-level `modes:` block suggesting **Prettier** as the steering-file
+formatter (`npx prettier --write` for the built-in `qa`/`review` modes — format
+only, so gtd still validates); edit or drop either freely (point `testCommand`
+at your suite, swap Prettier for dprint or a script, delete a key). It writes
+**no** `workflow:` key — the machine is built in — so review and commit the file
+before your first `gtd step`. `gtd init` takes no argument and refuses to
+clobber an existing config; it may also run in a plain parent directory (not a
+git repo) to seed a shared config a nested repo picks up. To customize the
+machine itself, add a `workflow:` key (there is no default fallback to merge
+over — a `workflow:` is the whole definition). See
+[Configuration](docs/configuration.md#gtd-init) for the details.
 
 ## How it works
 
@@ -91,6 +91,8 @@ Four commands drive it:
 - **`gtd fix`** — start a brand new process that goes straight into repairing
   the current failing tests, then runs the shared review/squash tail (a no-op if
   the suite is already green).
+- **`gtd visualize`** — serve an interactive diagram of the active workflow on a
+  local web server (the main flow, its sub-machines, and per-state details).
 
 `gtd version` (or `gtd --version`/`-v`) prints the installed version and exits;
 `gtd help` (or `gtd --help`/`-h`) prints the command list. Both short-circuit
@@ -182,8 +184,8 @@ Both halves are enforced by `gtd validate` and the `gtd step` gate.
 ## Documentation
 
 - [STATES.md](STATES.md) — the full pattern-machine specification: the model,
-  the pattern grammar, resolution, retry, the squash lifecycle, and the bundled
-  workflow templates
+  the pattern grammar, resolution, retry, the squash lifecycle, reusable
+  sub-machines, and the bundled workflow template
 - [CLI reference](docs/cli.md) — every command, exit codes, JSON schemas,
   repository requirements
 - [Driving the loop](docs/loop.md) — the reference loop driver, `gtd-loop`,