@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 +27 -15
- package/dist/gtd.bundle.mjs +164 -144
- package/docs/cli.md +43 -14
- package/docs/configuration.md +78 -50
- package/docs/development.md +7 -5
- package/docs/examples/advanced-workflow.md +25 -22
- package/docs/upgrading.md +48 -38
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -48,8 +48,16 @@ Or run without installing:
|
|
|
48
48
|
npx @pmelab/gtd
|
|
49
49
|
```
|
|
50
50
|
|
|
51
|
-
|
|
52
|
-
|
|
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
|
|
80
|
-
implementation plan — asking any open question it can't settle itself
|
|
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-
|
|
90
|
-
full shape.
|
|
91
|
-
|
|
92
|
-
a
|
|
93
|
-
[docs/examples/advanced-workflow.md](docs/examples/advanced-workflow.md).
|
|
94
|
-
workflow
|
|
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
|
-
|
|
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:`
|
|
128
|
-
|
|
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
|
|