@pmelab/gtd 20.3.0 → 21.0.0

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "gtd",
-  "version": "20.3.0",
+  "version": "21.0.0",
   "description": "Drive the gtd loop inside Claude Code: agent turns run as subagents, gtd decides every beat",
   "author": {
     "name": "Philipp Melab"

package/README.md

@@ -56,7 +56,9 @@ enforces it at the OS level. See
 
 ## Quick start
 
-Pipe the output of `gtd install` into your coding agent and answer its
+Run `gtd install` at your repository's root. It writes a `gtd.config.ts` that
+runs gtd's shipped workflows — commit it; gtd refuses to run without one — and
+prints a briefing. Pipe that briefing into your coding agent and answer its
 questions. It should build you a script that will autonomously run the process
 for you. Ask your agent if you have any questions.
 
@@ -79,7 +81,9 @@ for you. Ask your agent if you have any questions.
   workflow doesn't care who executes it.
 
 See [gtd --help](https://github.com/pmelab/gtd/blob/main/docs/cli.md) for the
-full command/flag reference, and
+full command/flag reference,
+[Compatibility](https://github.com/pmelab/gtd/blob/main/COMPATIBILITY.md) for
+which surfaces you can rely on across releases, and
 [Configuration](https://github.com/pmelab/gtd/blob/main/docs/configuration.md)
 for how to inspect or replace the workflow itself.
 
@@ -90,9 +94,9 @@ Two commands make up the whole cycle. **`gtd next` says what to do now.
 that.
 
 The fastest way to understand it is to drive a few beats by hand. Any git
-repository with at least one commit will do — the first two beats need no setup
-at all, and `gtd init` seeds the one setting that matters later (your test
-command).
+repository with at least one commit will do once `gtd install` has written its
+`gtd.config.ts` and you have committed it — the first two beats need nothing
+else. Later beats run your test command, set under `env:` in `.gtdrc`.
 
 ### Beat 1 — `gtd next` says whose turn it is
 
@@ -296,6 +300,12 @@ this with your environment. See
 [Driving the loop](https://github.com/pmelab/gtd/blob/main/docs/driver.md) for
 the full protocol.
 
+Or skip writing one: **`gtd loop`** is that loop, shipped with gtd. It drives
+`claude` (or `pi`) until the process rests on you, logs every turn to the file
+`gtd next --json=log` names, and maps the workflow's `smart`/`base` model hints
+to real model names through per-machine settings — see
+[`gtd loop`](https://github.com/pmelab/gtd/blob/main/docs/driver.md#the-bundled-driver-gtd-loop).
+
 ### Or drive it from inside Claude Code
 
 The gtd mod runs the same loop inside an interactive Claude Code session
@@ -497,9 +507,10 @@ starts a pure review of everything from `<commitish>` to HEAD — straight to st
 4, no planning and no building. `gtd doors` lists every door; a `gtd.config.ts`
 can add its own. `gtd --workflow <name>` starts any workflow by name.
 
-The workflow itself is a plain async TypeScript function: a `gtd.config.ts` at
-the repository root replaces it, and the pieces the bundled one is built from
-are exported for yours to reuse. See
+The workflow itself is a plain async TypeScript function, and the
+`gtd.config.ts` at the repository root names it: the one `gtd install` writes
+re-exports the shipped workflows from `@pmelab/gtd/workflows`, and the pieces
+they are built from are exported for yours to reuse. See
 [Configuration](https://github.com/pmelab/gtd/blob/main/docs/configuration.md) —
 and remember gtd evaluates that file on every command. A shared workflow package
 bundling its own `@pmelab/gtd` is checked against the running gtd and refused,