tuncss-plan-kit 0.6.0 → 0.7.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
@@ -75,28 +75,51 @@ Agent: ↓ writing-plans skill
75
75
  tasks shaped as Targets / Implementation Notes /
76
76
  Done When / Verification
77
77
 
78
- You: do TASK-01
79
- Agent: reads only TASK-01's block, stays inside its Targets, writes the
80
- changelog entry to docs/CHANGELOG.md, stops for approval when done
78
+ You: run the plan
79
+ Agent: runs every task in order; after each one it writes the changelog
80
+ entry to docs/CHANGELOG.md and commits; stops only on a stop
81
+ condition (S1–S4) and reports where and why
81
82
 
82
83
  — or —
83
84
 
84
85
  You: /handoff-plan
85
86
  Agent: ↓ handoff skill
86
- writes a short briefing to docs/handoffs/ that you can paste
87
- into another agent (or feed it the file path)
87
+ writes a briefing to docs/handoffs/ — the execution contract on
88
+ top — that you can paste into another agent
88
89
  ```
89
90
 
90
91
  ## What's in a plan
91
92
 
92
93
  Every plan starts with this contract:
93
94
 
94
- > 1. Read **only** that task's block. Do not preview other tasks.
95
- > 2. Stay strictly inside its **Targets** — do not edit files outside that list.
96
- > 3. Follow the **Implementation Notes**; do not invent extra scope.
97
- > 4. When **Done When** and **Verification** are satisfied, write the changelog entry (rule 6), then **stop and report**. Wait for approval before moving to the next task.
98
- > 5. If verification fails, report the failure and stop. Do not attempt fixes outside the task's Targets, and do not write a changelog entry.
99
- > 6. **Changelog entry:** use the `changelog` skill to append this task's entry to `docs/CHANGELOG.md`. Base it on the actual diff, not on what you set out to do.
95
+ > **Default: run every task in order, from TASK-01 to the last, without stopping between tasks.**
96
+ > If the user names a single task ("do TASK-03"), do only that task, then stop.
97
+ > If the user names a starting task ("run from TASK-04"), start there and continue in order.
98
+ > This plan is already approved. Do not write your own plan or task list — execute this one.
99
+ >
100
+ > **Before the first task:** run `git status`. If the working tree is not clean, stop (S4).
101
+ >
102
+ > **For each task:**
103
+ > 1. Read only that task's block. Do not preview later tasks.
104
+ > 2. Edit only the files in its **Targets**.
105
+ > 3. Follow its **Implementation Notes**; add no extra scope.
106
+ > 4. Run its **Verification**. If it fails, make one fix attempt inside Targets and run it again.
107
+ > 5. When **Done When** and **Verification** pass: append the changelog entry with the `changelog`
108
+ > skill (from the actual diff), then commit the task's changes and the entry together.
109
+ > 6. **Commit message:** Turkish, ASCII only — write c, s, i, g, o, u instead of ç, ş, ı, ğ, ö, ü.
110
+ > First line `TASK-NN: <what changed>`, under 72 characters. Say what changed, not "dosyalar guncellendi".
111
+ > Example: `TASK-03: Oturum suresi 24 saatten 2 saate dusuruldu`
112
+ >
113
+ > **Stop and report when:**
114
+ > - S1: Verification fails a second time.
115
+ > - S2: A file, function, API, flag, or command the task names does not exist or differs from the description. Do not guess.
116
+ > - S3: Finishing the task requires editing a file outside its Targets.
117
+ > - S4: The working tree was not clean before the first task.
118
+ >
119
+ > On stop: no changelog entry and no commit for that task; earlier commits stay. Report the task id, the condition (S1–S4), and what you saw.
120
+ > After the last task: report the list of commits made.
121
+
122
+ Commit messages are Turkish, ASCII only — the kit's team writes them that way.
100
123
 
101
124
  Plans carry contracts (types, signatures, commands) and pointers to existing code, not pasted function bodies — the executor writes the code.
102
125
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "tuncss-plan-kit",
3
- "version": "0.6.0",
3
+ "version": "0.7.0",
4
4
  "type": "module",
5
5
  "description": "Four-skill kit for spec-driven development: brainstorm an idea into a spec, turn the spec into an executable plan, hand the plan off to another LLM agent, and record what changed.",
6
6
  "bin": {
@@ -11,7 +11,7 @@ Append a short, concrete record of what changed to `docs/CHANGELOG.md`. The read
11
11
 
12
12
  ## Two ways in
13
13
 
14
- **From a completed plan task.** Rule 6 of the plan's execution contract sends you here once Done When and Verification are satisfied. You have the task id, the task name, and the plan path.
14
+ **From a completed plan task.** Step 5 of the plan's execution contract sends you here once Done When and Verification are satisfied. You have the task id, the task name, and the plan path.
15
15
 
16
16
  **From `/changelog`.** The user invoked it directly for work done outside the plan flow. There is no task id and no plan path.
17
17
 
@@ -92,4 +92,4 @@ Placement rule — follow it exactly, so that three people's agents do not grow
92
92
 
93
93
  ## Do not commit
94
94
 
95
- Leave the entry in the working tree next to the change. Whoever commits the work commits the entry with it, so `git log -p docs/CHANGELOG.md` always pairs a line with the change that produced it.
95
+ Leave the entry in the working tree next to the change. Whoever commits the work commits the entry with it, so `git log -p docs/CHANGELOG.md` always pairs a line with the change that produced it. In a plan run, the execution contract commits the task's changes and this entry together right after you finish.
@@ -43,7 +43,35 @@ Do not echo the message contents — the user will open the file.
43
43
  ## Message template
44
44
 
45
45
  ````text
46
- You're picking up an implementation plan in this repo.
46
+ You're executing an approved implementation plan in this repo.
47
+
48
+ <!-- EXECUTION CONTRACT — read before touching any task -->
49
+ > **Default: run every task in order, from TASK-01 to the last, without stopping between tasks.**
50
+ > If the user names a single task ("do TASK-03"), do only that task, then stop.
51
+ > If the user names a starting task ("run from TASK-04"), start there and continue in order.
52
+ > This plan is already approved. Do not write your own plan or task list — execute this one.
53
+ >
54
+ > **Before the first task:** run `git status`. If the working tree is not clean, stop (S4).
55
+ >
56
+ > **For each task:**
57
+ > 1. Read only that task's block. Do not preview later tasks.
58
+ > 2. Edit only the files in its **Targets**.
59
+ > 3. Follow its **Implementation Notes**; add no extra scope.
60
+ > 4. Run its **Verification**. If it fails, make one fix attempt inside Targets and run it again.
61
+ > 5. When **Done When** and **Verification** pass: append the changelog entry with the `changelog`
62
+ > skill (from the actual diff), then commit the task's changes and the entry together.
63
+ > 6. **Commit message:** Turkish, ASCII only — write c, s, i, g, o, u instead of ç, ş, ı, ğ, ö, ü.
64
+ > First line `TASK-NN: <what changed>`, under 72 characters. Say what changed, not "dosyalar guncellendi".
65
+ > Example: `TASK-03: Oturum suresi 24 saatten 2 saate dusuruldu`
66
+ >
67
+ > **Stop and report when:**
68
+ > - S1: Verification fails a second time.
69
+ > - S2: A file, function, API, flag, or command the task names does not exist or differs from the description. Do not guess.
70
+ > - S3: Finishing the task requires editing a file outside its Targets.
71
+ > - S4: The working tree was not clean before the first task.
72
+ >
73
+ > On stop: no changelog entry and no commit for that task; earlier commits stay. Report the task id, the condition (S1–S4), and what you saw.
74
+ > After the last task: report the list of commits made.
47
75
 
48
76
  **Project:** <project name> — <one-line description>
49
77
 
@@ -59,20 +87,12 @@ You're picking up an implementation plan in this repo.
59
87
  - TASK-02: <name>
60
88
  - ...
61
89
 
62
- **How to execute (full execution contract is at the top of the plan file):**
63
- 1. When I ask for a task ("do TASK-03"), read **only** that task's block in the plan.
64
- 2. Stay strictly inside its **Targets** — don't edit files outside that list.
65
- 3. Follow the **Implementation Notes**; don't invent extra scope.
66
- 4. When **Done When** and **Verification** are satisfied, write the changelog entry (rule 6), then **stop and report**. Wait for my approval before moving on.
67
- 5. If verification fails, report and stop. Don't attempt fixes outside the task's Targets, and don't write a changelog entry.
68
- 6. **Changelog entry:** use the `changelog` skill to append this task's entry to `docs/CHANGELOG.md`. Base it on the actual diff, not on what you set out to do.
69
-
70
- Start by reading `<plan path>` end-to-end, then wait for me to ask for the first task. Don't begin TASK-01 until I ask.
90
+ Start now: open `<plan path>`, read the header and TASK-01's block, and begin. Continue through every task in order until the last one is done or a stop condition (S1–S4) is hit.
71
91
  ````
72
92
 
73
93
  ## Rules
74
94
 
75
95
  - Don't summarize task bodies. The receiving agent reads the plan file itself.
76
- - Don't reformat the execution contract beyond the 6 numbered rules above. They are the contract; the plan file is the source of truth.
77
- - Keep the message under ~50 lines. If you're tempted to add more context, you're inlining the plan — stop.
96
+ - Don't reformat the execution contract. It is copied verbatim from the plan-universal header; the plan file is the source of truth.
97
+ - Keep the message under ~60 lines, not counting the task list. If you're tempted to add more context, you're inlining the plan — stop.
78
98
  - Don't include this skill's name, your model name, or any Claude-specific framing in the output. The receiver doesn't need to know how the message was generated.
@@ -33,13 +33,32 @@ Every plan starts with this header:
33
33
  # <Feature Name> — Implementation Plan
34
34
 
35
35
  <!-- EXECUTION CONTRACT — read before touching any task -->
36
- > When the user asks for a specific task (e.g. "do TASK-03"):
37
- > 1. Read **only** that task's block. Do not preview other tasks.
38
- > 2. Stay strictly inside its **Targets** — do not edit files outside that list.
39
- > 3. Follow the **Implementation Notes**; do not invent extra scope.
40
- > 4. When **Done When** and **Verification** are satisfied, write the changelog entry (rule 6), then **stop and report**. Wait for approval before moving to the next task.
41
- > 5. If verification fails, report the failure and stop. Do not attempt fixes outside the task's Targets, and do not write a changelog entry.
42
- > 6. **Changelog entry:** use the `changelog` skill to append this task's entry to `docs/CHANGELOG.md`. Base it on the actual diff, not on what you set out to do.
36
+ > **Default: run every task in order, from TASK-01 to the last, without stopping between tasks.**
37
+ > If the user names a single task ("do TASK-03"), do only that task, then stop.
38
+ > If the user names a starting task ("run from TASK-04"), start there and continue in order.
39
+ > This plan is already approved. Do not write your own plan or task list — execute this one.
40
+ >
41
+ > **Before the first task:** run `git status`. If the working tree is not clean, stop (S4).
42
+ >
43
+ > **For each task:**
44
+ > 1. Read only that task's block. Do not preview later tasks.
45
+ > 2. Edit only the files in its **Targets**.
46
+ > 3. Follow its **Implementation Notes**; add no extra scope.
47
+ > 4. Run its **Verification**. If it fails, make one fix attempt inside Targets and run it again.
48
+ > 5. When **Done When** and **Verification** pass: append the changelog entry with the `changelog`
49
+ > skill (from the actual diff), then commit the task's changes and the entry together.
50
+ > 6. **Commit message:** Turkish, ASCII only — write c, s, i, g, o, u instead of ç, ş, ı, ğ, ö, ü.
51
+ > First line `TASK-NN: <what changed>`, under 72 characters. Say what changed, not "dosyalar guncellendi".
52
+ > Example: `TASK-03: Oturum suresi 24 saatten 2 saate dusuruldu`
53
+ >
54
+ > **Stop and report when:**
55
+ > - S1: Verification fails a second time.
56
+ > - S2: A file, function, API, flag, or command the task names does not exist or differs from the description. Do not guess.
57
+ > - S3: Finishing the task requires editing a file outside its Targets.
58
+ > - S4: The working tree was not clean before the first task.
59
+ >
60
+ > On stop: no changelog entry and no commit for that task; earlier commits stay. Report the task id, the condition (S1–S4), and what you saw.
61
+ > After the last task: report the list of commits made.
43
62
 
44
63
  **Goal:** <one sentence>
45
64
 
@@ -83,7 +102,7 @@ Every task uses this shape:
83
102
  - Automated (optional): <test files, scripts, or `npm test -- foo` commands and expected output, only if automated coverage genuinely belongs here>
84
103
  ````
85
104
 
86
- Tasks are self-contained because the executor reads exactly one block per turn (see the Execution Contract). If TASK-07 needs the shape of something defined in TASK-02, restate it in TASK-07 — don't make the reader scroll.
105
+ Tasks are self-contained because the executor reads exactly one block at a time (see the Execution Contract). If TASK-07 needs the shape of something defined in TASK-02, restate it in TASK-07 — don't make the reader scroll.
87
106
 
88
107
  ## Granularity
89
108
 
@@ -107,6 +126,7 @@ These are **plan failures**. Never write them:
107
126
  - "Similar to TASK-N" — repeat what's needed; the executor reads tasks out of order
108
127
  - Steps that describe *what* without pointing to *how* — name the existing file to follow, the signature, or the exact command; don't paste whole function bodies the executor can write itself
109
128
  - References to types, functions, or files not defined in any task or in the file map
129
+ - References you haven't verified — every file, function, command, flag, and config key in Implementation Notes either exists in the repo (open it and check while writing the plan) or is created by an earlier task's Targets. If you can't confirm it, don't write it.
110
130
 
111
131
  ## Self-review
112
132
 
@@ -116,12 +136,14 @@ After the plan is written, re-read it against the spec with fresh eyes. Fix issu
116
136
  2. **Placeholder scan** — anything from the "No placeholders" list? Fix.
117
137
  3. **Name and type consistency** — a function called `clearLayers()` in TASK-03 but `clearFullLayers()` in TASK-07 is a bug. Same for types, file paths, env vars, table names.
118
138
  4. **Targets isolation** — does any task's Targets list overlap awkwardly with another in a way that will force out-of-order edits? If so, resequence or merge.
119
- 5. **Verification reality** — every Done When has a corresponding Verification step that an engineer can actually run.
139
+ 5. **Verification reality** — every Done When has a corresponding Verification step that an engineer can actually run. Every Verification command terminates on its own — no watch mode, no dev server left running; the executor runs tasks back to back and a hung command blocks the whole run.
140
+ 6. **Order** — each task may assume only that earlier tasks are done. The executor runs them top to bottom.
141
+ 7. **References exist** — every path, function, and command named in a task exists in the repo or is created by an earlier task.
120
142
 
121
143
  ## After the plan
122
144
 
123
145
  Save the plan, commit it, and tell the user:
124
146
 
125
- > Plan saved to `<path>` and committed. To execute, ask for tasks one at a time (e.g. "do TASK-01") — I'll stay inside that task's Targets and stop for approval before moving on, per the execution contract at the top of the plan. Or, if you want to hand this off to another LLM agent, run `/handoff-plan`.
147
+ > Plan saved to `<path>` and committed. To execute every task in order, say "run the plan" — I'll commit after each task and stop only on a stop condition (S1–S4). To run a single task, say "do TASK-01". To hand it to another LLM agent, run `/handoff-plan`.
126
148
 
127
- Do not start implementing in the same turn. Wait for the user to request the first task.
149
+ Do not start implementing in the same turn. Wait for the user to say how to run it.
@@ -8,5 +8,5 @@ This project uses tuncss-plan-kit. Four slash commands are available:
8
8
  - `/handoff-plan` — generate a paste-ready handoff for another LLM agent (writes to `docs/handoffs/`)
9
9
  - `/changelog` — record what changed, in plain sentences (writes to `docs/CHANGELOG.md`)
10
10
 
11
- Plans contain an execution contract at the top. When asked for a specific task ("do TASK-03"), read only that task's block, stay inside its Targets, write the changelog entry, then stop and report when Done When + Verification are satisfied.
11
+ Plans contain an execution contract at the top. By default, run every task in order: after each task passes its Verification, write the changelog entry and commit; stop only on a stop condition (S1–S4). "do TASK-03" runs only that task.
12
12
  <!-- tuncss-plan-kit:end -->