@pmelab/gtd 5.1.0 → 6.1.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.
package/README.md CHANGED
@@ -48,8 +48,16 @@ Or run without installing:
48
48
  npx @pmelab/gtd
49
49
  ```
50
50
 
51
- No config file, no setup subcommand — `gtd` auto-initializes a `.gtdrc.json`
52
- schema stub on first run (see [Configuration](docs/configuration.md#auto-init)).
51
+ Then scaffold a workflow for the repo — run once:
52
+
53
+ ```bash
54
+ gtd init simple # or: gtd init advanced
55
+ ```
56
+
57
+ This writes a `.gtdrc.json` with the chosen workflow inline (review and commit
58
+ it). gtd ships **no** default workflow: a state command run before `gtd init`
59
+ fails, pointing you back here. See
60
+ [Configuration](docs/configuration.md#gtd-init) for the two templates.
53
61
 
54
62
  ## How it works
55
63
 
@@ -68,6 +76,10 @@ Four commands drive it:
68
76
  `<commitish>..HEAD` (e.g. a colleague's PR branch), reusing the workflow's
69
77
  existing review/feedback machinery over that diff.
70
78
 
79
+ `gtd version` (or `gtd --version`/`-v`) prints the installed version and exits;
80
+ `gtd help` (or `gtd --help`/`-h`) prints the command list. Both short-circuit
81
+ before any repo work, so they run anywhere.
82
+
71
83
  The loop is one beat, repeated: run `gtd next --json` and dispatch on `kind` —
72
84
  `"message"` means it's a human's move (stop and hand off); `"script"` means the
73
85
  driver runs `content` itself, then steps its actor; `"prompt"` means feed
@@ -76,22 +88,22 @@ never executes anything — the driver owns running scripts. See
76
88
  [STATES.md](STATES.md) for the model and [Driving the loop](docs/loop.md) for
77
89
  the full protocol.
78
90
 
79
- Along the way, the bundled default workflow develops your sketch into an
80
- implementation plan — asking any open question it can't settle itself via a
81
- deterministic `.gtd/TODO.md` format, validated before it ever reaches you —
82
- builds it, runs your tests (looping on failures), and hands you a
91
+ Along the way, the `simple` workflow (`gtd init simple`) develops your sketch
92
+ into an implementation plan — asking any open question it can't settle itself
93
+ via a deterministic `.gtd/TODO.md` format, validated before it ever reaches you
94
+ — builds it, runs your tests (looping on failures), and hands you a
83
95
  `.gtd/REVIEW.md` checkbox review of the cycle's diff: tick a box to approve that
84
96
  item, or edit/untick for feedback. The same review flow also has a direct entry
85
97
  point — `gtd review <commitish>` starts a brand new process reviewing
86
98
  `<commitish>..HEAD` with no cycle of its own, e.g. a colleague's PR branch.
87
99
  Approving rests the cycle back at idle, with every turn commit still sitting in
88
100
  history for you to squash however you like (or not at all; gtd makes no
89
- assumption) — see [STATES.md](STATES.md#10-the-bundled-default-workflow) for the
90
- full shape. A heavier machine — two-phase Q&A planning, an architecture phase,
91
- task decomposition, a per-task build loop, and a squash finale — is preserved as
92
- a copy-paste `.gtdrc` example at
93
- [docs/examples/advanced-workflow.md](docs/examples/advanced-workflow.md). The
94
- workflow itself is just `.gtdrc` config — swap it for your own (see
101
+ assumption) — see [STATES.md](STATES.md#10-the-bundled-workflow-templates) for
102
+ the full shape. The `advanced` template (`gtd init advanced`) is a heavier
103
+ machine — two-phase Q&A planning, an architecture phase, task decomposition, a
104
+ per-task build loop, and a squash finale — walked through at
105
+ [docs/examples/advanced-workflow.md](docs/examples/advanced-workflow.md). Either
106
+ way the workflow is just `.gtdrc` config — edit it or write your own (see
95
107
  [Configuration](docs/configuration.md)).
96
108
 
97
109
  `gtd-loop`, installed alongside `gtd`, is a ready-to-run driver for the whole
@@ -119,13 +131,13 @@ Both halves are enforced by `gtd validate` and the `gtd step` gate.
119
131
 
120
132
  - [STATES.md](STATES.md) — the full pattern-machine specification: the model,
121
133
  the pattern grammar, resolution, retry, the squash lifecycle, and the bundled
122
- default workflow
134
+ workflow templates
123
135
  - [CLI reference](docs/cli.md) — every command, exit codes, JSON schemas,
124
136
  repository requirements
125
137
  - [Driving the loop](docs/loop.md) — the reference loop driver, `gtd-loop`,
126
138
  custom agents
127
- - [Configuration](docs/configuration.md) — `.gtdrc` `workflow:` schema, lookup,
128
- auto-init
139
+ - [Configuration](docs/configuration.md) — `gtd init`, the `.gtdrc` `workflow:`
140
+ schema, lookup
129
141
  - [Upgrading](docs/upgrading.md) — breaking changes and migration
130
142
  - [Development](docs/development.md) — building, testing, releasing
131
143