@pmelab/gtd 20.4.0 → 21.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "gtd",
3
- "version": "20.4.0",
3
+ "version": "21.0.0",
4
4
  "description": "Drive the gtd loop inside Claude Code: agent turns run as subagents, gtd decides every beat",
5
5
  "author": {
6
6
  "name": "Philipp Melab"
package/README.md CHANGED
@@ -56,7 +56,9 @@ enforces it at the OS level. See
56
56
 
57
57
  ## Quick start
58
58
 
59
- Pipe the output of `gtd install` into your coding agent and answer its
59
+ Run `gtd install` at your repository's root. It writes a `gtd.config.ts` that
60
+ runs gtd's shipped workflows — commit it; gtd refuses to run without one — and
61
+ prints a briefing. Pipe that briefing into your coding agent and answer its
60
62
  questions. It should build you a script that will autonomously run the process
61
63
  for you. Ask your agent if you have any questions.
62
64
 
@@ -92,9 +94,9 @@ Two commands make up the whole cycle. **`gtd next` says what to do now.
92
94
  that.
93
95
 
94
96
  The fastest way to understand it is to drive a few beats by hand. Any git
95
- repository with at least one commit will do — the first two beats need no setup
96
- at all, and `gtd init` seeds the one setting that matters later (your test
97
- command).
97
+ repository with at least one commit will do once `gtd install` has written its
98
+ `gtd.config.ts` and you have committed it — the first two beats need nothing
99
+ else. Later beats run your test command, set under `env:` in `.gtdrc`.
98
100
 
99
101
  ### Beat 1 — `gtd next` says whose turn it is
100
102
 
@@ -505,9 +507,10 @@ starts a pure review of everything from `<commitish>` to HEAD — straight to st
505
507
  4, no planning and no building. `gtd doors` lists every door; a `gtd.config.ts`
506
508
  can add its own. `gtd --workflow <name>` starts any workflow by name.
507
509
 
508
- The workflow itself is a plain async TypeScript function: a `gtd.config.ts` at
509
- the repository root replaces it, and the pieces the bundled one is built from
510
- are exported for yours to reuse. See
510
+ The workflow itself is a plain async TypeScript function, and the
511
+ `gtd.config.ts` at the repository root names it: the one `gtd install` writes
512
+ re-exports the shipped workflows from `@pmelab/gtd/workflows`, and the pieces
513
+ they are built from are exported for yours to reuse. See
511
514
  [Configuration](https://github.com/pmelab/gtd/blob/main/docs/configuration.md) —
512
515
  and remember gtd evaluates that file on every command. A shared workflow package
513
516
  bundling its own `@pmelab/gtd` is checked against the running gtd and refused,