@pmelab/gtd 6.5.1 → 6.6.0

package/README.md

@@ -57,9 +57,13 @@ gtd init simple      # or: gtd init advanced
 This writes a `.gtdrc.json` for the chosen 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. 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 two templates.
+`gtd-prompts/*.md` file — no config edit needed. 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 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 two templates.
 
 ## How it works
 

package/dist/gtd.bundle.mjs

@@ -191388,6 +191388,27 @@ const SCHEMA_URL = "https://raw.githubusercontent.com/pmelab/gtd/main/schema.jso
 */
 const PROMPTS_DIR = "gtd-prompts";
 /**
+* The top-level `modes:` block `gtd init` SEEDS into the scaffolded
+* `.gtdrc.json` as a ready-to-edit suggestion: a `format:` command for each
+* built-in steering-file mode the bundled templates use (`qa` for the plan /
+* open-questions files, `review` for REVIEW.md), so a fresh project's steering
+* files are auto-formatted with Prettier before gtd validates them. Only
+* `format:` is declared — gtd's built-in `qa`/`review` validators still do the
+* validating (the two halves layer independently — see STATES.md §12 /
+* docs/configuration.md `modes:`). gtd ships no formatter, so this is the one
+* place a default is suggested; a project edits or drops it freely (swap
+* Prettier for dprint, point at a script, delete the key).
+*
+* Seeded only by `renderInitScaffold` (the real `gtd init` write path), NOT by
+* `renderInitConfig`: the latter is reused as a hermetic test fixture (the
+* `Given the "…" workflow` step) that must not depend on Prettier being
+* installed or spawn a subprocess at every steering-file gate.
+*/
+const MODES_SUGGESTION = {
+	qa: { format: "npx prettier --write <%= it.file %>" },
+	review: { format: "npx prettier --write <%= it.file %>" }
+};
+/**
 * The bundled workflow templates `gtd init <name>` can scaffold, keyed by the
 * name the user passes. Each value is the raw YAML text of the template file,
 * imported as a string (tsdown's `.yaml` text loader / the vitest `rawMd`
@@ -191414,6 +191435,12 @@ const isWorkflowTemplateName = (name) => Object.prototype.hasOwnProperty.call(WO
 * (they are workflow mechanics, not prompts). The bundled YAML template itself
 * stays fully inline (it ships inside the single-file bundle); this function is
 * the only place the split happens, at scaffold time.
+*
+* It also seeds a top-level `modes:` block (`MODES_SUGGESTION`) — a ready-to-
+* edit Prettier `format:` for the built-in `qa`/`review` steering-file modes —
+* so a fresh project auto-formats its steering files out of the box. This lives
+* here rather than in `renderInitConfig` so the latter stays a hermetic test
+* fixture (see `MODES_SUGGESTION`).
 */
 const renderInitScaffold = (name) => {
 	const workflow = (0, import_dist$1.parse)(WORKFLOW_TEMPLATES[name]);
@@ -191429,6 +191456,7 @@ const renderInitScaffold = (name) => {
 	return {
 		config: JSON.stringify({
 			$schema: SCHEMA_URL,
+			modes: MODES_SUGGESTION,
 			workflow
 		}, null, 2) + "\n",
 		prompts

package/docs/configuration.md

@@ -371,8 +371,10 @@ So for a state declaring `mode: qa`:
 That is what makes the built-in modes extensible rather than all-or-nothing —
 and the top-level key means a project can plug its formatter into whichever
 workflow it scaffolded (`gtd init simple`/`advanced`) without re-declaring a
-`modes:` block on the workflow itself. Add it alongside the `workflow:` key in
-your `.gtdrc.json`:
+`modes:` block on the workflow itself. **`gtd init` seeds exactly this block by
+default** (the Prettier suggestion below), so a fresh repo already formats its
+steering files — edit or drop it to taste. It sits alongside the `workflow:` key
+in your `.gtdrc.json`:
 
 ```jsonc
 // .gtdrc.json — the workflow from `gtd init`, plus your own markdown formatter
@@ -673,8 +675,26 @@ config references it via a `./gtd-prompts/<state>.md`
 [file reference](#content-values-inline-or-a-file-reference) — gtd inlines it at
 load time, so a prompt is editable Markdown and editing it changes the workflow
 with no config edit. Human `message:` blocks and check `script:` bodies stay
-inline in the config (they are workflow mechanics, not prompts). The two
-templates:
+inline in the config (they are workflow mechanics, not prompts).
+
+It also seeds a top-level [`modes:`](#modes--pluggable-steering-file-modes)
+block as a ready-to-edit suggestion — a Prettier `format:` for each built-in
+steering-file mode the templates use:
+
+```jsonc
+"modes": {
+  "qa": { "format": "npx prettier --write <%= it.file %>" },
+  "review": { "format": "npx prettier --write <%= it.file %>" }
+}
+```
+
+Only `format:` is declared, so gtd's built-in `qa`/`review` validators still do
+the validating (the two halves layer independently). gtd ships no formatter, so
+this is the one default it suggests: a fresh repo auto-formats its steering
+files out of the box, and you edit or drop the block freely (swap Prettier for
+dprint, point at a script, or delete the key).
+
+The two templates:
 
 - **`simple`** — the 10-state machine walked through in
   [STATES.md §10](../STATES.md#10-the-bundled-workflow-templates): idle →

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pmelab/gtd",
-  "version": "6.5.1",
+  "version": "6.6.0",
   "private": false,
   "description": "Git-aware CLI that emits the next prompt for an autonomous coding agent based on the current repository state",
   "bin": {