@baldurpan/create-ai-workflow 0.5.0 → 0.5.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@baldurpan/create-ai-workflow",
-  "version": "0.5.0",
+  "version": "0.5.1",
   "description": "Overlay a tiered planning workflow — roadmap, plans, phase ledgers, verification gates — onto an existing repository, for coding agents.",
   "keywords": [
     "ai",

package/templates/context/plan-template.md

@@ -36,9 +36,11 @@ Written <YYYY-MM-DD>. <One line on what this is.> The `<name>` entry in
 | 1 | <name> | not started | — | |
 | 2 | <name> | not started | 1 | |
 
-Status is one of `not started`, `in progress`, `blocked`, `done`. `done` only when the scope landed and both
-gates passed, and whoever finishes a phase updates the row as part of the same change as the work — who
-commits that change is [`../git.md`](../git.md)'s answer, not this table's.
+Status is one of `not started`, `in progress`, `blocked`, `done`. A row goes to `in progress` when work on
+the phase starts, before any code, so an interrupted run leaves a ledger that says what was underway. `done`
+only when the scope landed and both gates passed, and whoever finishes a phase updates the row as part of
+the same change as the work — who commits that change is [`../git.md`](../git.md)'s answer, not this
+table's.
 
 **Exactly one table in this document has these columns.** Do not add a second phase table — a
 differently-shaped one nearby is a decoy that gets read by mistake.

package/templates/context/workflow.md

@@ -125,10 +125,16 @@ To pick the next phase: take the **lowest-numbered phase that is not `done` and
 are all `done`.** State which one you picked before starting. If it is already `in progress`, read its Note
 and resume — do not restart it.
 
+**A phase's row is written twice.** It opens to `in progress` when the work starts, before any code, and
+closes to `done`, `in progress` or `blocked` when the phase ends. The opening write is what makes an
+interruption survivable: a run that dies mid-phase leaves a tree with half the work in it, and the row is
+the only thing that can say so.
+
 `done` means the phase's scope landed and both gates passed — **a verdict about the gates, not about git.**
 Whoever finishes a phase updates its row **as part of the same change as the work**: one commit where the
-agent commits, one working tree handed over where the user does. A row updated separately is a row that
-disagrees with the repository in between.
+agent commits, one working tree handed over where the user does. A closing row updated separately is a row
+that disagrees with the repository in between. The opening write is not a change of its own — it is left in
+the tree and lands with the work it describes.
 
 If the ledger's claim disagrees with the repo — a phase marked `done` whose files do not exist, or the
 reverse — **stop and say so.** Never silently re-do or skip a phase on a stale ledger. A `done` row whose

package/templates/skills/feature-implement/SKILL.md

@@ -65,7 +65,22 @@ If the ledger's claim contradicts the repo — a phase marked `done` whose **Fil
 plainly in the tree under a phase marked `not started` — **say so and stop.** Never silently re-do or skip
 a phase on a stale ledger.
 
-## 6. Do the work
+## 6. Open the ledger row
+
+Set the phase's Status to `in progress` and write a Note naming what is underway — **before any code.**
+
+This row is what a *later* session reads. A phase interrupted here — context exhausted, session closed, run
+cancelled — leaves a working tree with half a phase in it. A row still reading `not started` sends the next
+run into step 5's disagreement stop, or into redoing work that is already there.
+
+One token and one Note, in the row that is already there — do not move the entry, restructure the table, or
+write a summary anywhere else. If the row is already `in progress` because you are resuming it, leave it
+alone; step 11 rewrites the Note.
+
+**This write is not a change of its own.** Leave it in the working tree — it lands with the phase's work
+under either answer in [`context/git.md`](../../../context/git.md). Never commit it on its own.
+
+## 7. Do the work
 
 Read the phase's §6.2 sub-section: its scope, its **Files:**, and what `done` means for it.
 
@@ -79,7 +94,7 @@ this repository can open them, and a brief that inlines them is a brief that goe
 
 Describe **what** needs to happen, never **how** to code it. Scope each delegated task to specific files.
 
-## 7. Gate 1 — verification
+## 8. Gate 1 — verification
 
 Per the gate contract in [`context/workflow.md`](../../../context/workflow.md): read
 [`context/verify.md`](../../../context/verify.md) and run its sections in order — Lint → Typecheck → Build →
@@ -89,9 +104,9 @@ Test.
 so, never faked. Exit 0 is the verdict regardless of summary text. If `verify.md` does not exist or has no
 filled-in section, stop and say so. Docs-only changes run Lint plus a read of the diff.
 
-A failure is the verdict — go to step 9 with the failing output verbatim as the feedback.
+A failure is the verdict — go to step 10 with the failing output verbatim as the feedback.
 
-## 8. Gate 2 — review
+## 9. Gate 2 — review
 
 Dispatch per [`context/executors.md`](../../../context/executors.md). With no independent reviewer
 configured, review the diff yourself against the plan's review expectations and the standards — weaker, and
@@ -100,13 +115,13 @@ configured, review the diff yourself against the plan's review expectations and
 Require concrete evidence — file paths, command output — for every verdict, and a `P0`–`P3` severity on
 every blocking finding.
 
-- `PASS` or `PASS WITH NOTES` → the phase's work is done; go to step 10.
-- `FAIL` → **write it to [`context/findings.md`](../../../context/findings.md) first, then** go to step 9.
+- `PASS` or `PASS WITH NOTES` → the phase's work is done; go to step 11.
+- `FAIL` → **write it to [`context/findings.md`](../../../context/findings.md) first, then** go to step 10.
 
 **Write the finding before the loopback, not after it.** A verdict that lives only in this session's
 transcript evaporates when the conversation ends — including a `P0` the cap never got to.
 
-## 9. Loopback
+## 10. Loopback
 
 Cap: **two loops per gate, per phase.**
 
@@ -118,7 +133,7 @@ At the cap: **write a finding** (`P1` for a Gate 1 cap-out — a phase whose ver
 blocked by definition), then escalate to the user with the current state and the last feedback.
 **Escalating is not a substitute for recording.**
 
-## 10. Close out the ledger row
+## 11. Close out the ledger row
 
 The row is part of the same change as the work — never a separate step afterwards:
 
@@ -131,7 +146,7 @@ open `P0` or `P1` is tied to this phase**; leave it `in progress` and name the f
 
 `done` is a verdict about the gates, not about git. Whether the change is committed at all is the next step.
 
-## 11. Land it — read [`context/git.md`](../../../context/git.md)
+## 12. Land it — read [`context/git.md`](../../../context/git.md)
 
 **Do not commit until you have read that file, and do not commit at all unless it says the agent does.**
 It is the only place this project's answer lives, the same way `verify.md` is the only place its commands
@@ -142,7 +157,7 @@ once, and name `/onboard`.
   and stop. Do not stage-and-commit "to be helpful", and do not push or branch under either answer.
 - **The agent commits** → the code and the ledger row in one commit, at the granularity that file names.
 
-## 12. Report
+## 13. Report
 
 - What changed, and which files — and whether it is committed or waiting in the tree.
 - Gate 1 output, and Gate 2's verdict.