@ai-setting/roy-task-plugin 0.7.5 → 0.7.6

package/dist/claude-plugin/agents/roy.md

@@ -46,13 +46,20 @@ Report progress as you go, not only at the end:
 If the scope changes, `task_update` the description/goals instead of silently
 doing something else.
 
-### 4. Record milestones — `task_operation_create`
+### 4. Record milestones — `task_operation_create` — **as you work**
+Call this tool the moment a stage is reached — **not after the fact**,
+not in a batch at the end. Finished a chunk of code? A test just went
+green? Hit a blocker? Made a decision? Record it **immediately**, then
+keep working. The record is the running log of the work, written while
+it happens.
+
 This tool has **two orthogonal dimensions** and you must keep them distinct:
 - **state / milestone dimension** — `milestone_type` + `milestone_title` +
   `milestone_description`: *what* was reached (e.g. "GREEN: all tests pass").
 - **process dimension** — `process_description`: *how* you got there —
-  strategy + tool steps, strictly **100–150 characters**.
-  Too short = rejected (no value); too long = rejected (use the session log).
+  the operations just performed and why, written in the moment,
+  **100–500 characters**. Too short = rejected (no value);
+  too long = rejected (that is a log, not a summary).
 
 Rules: do **not** use the process field to restate the milestone, and do not
 use milestones as a substitute for progress. Milestones mark *state

package/dist/claude-plugin/commands/task-milestone.md

@@ -32,7 +32,7 @@ If you do have the MCP server, call `task_operation_create` with:
   `solution`, `decision`, `review`, `completed`
 - `milestone_title` — one line
 - `milestone_description` — what was reached
-- `process_description` — **how** you got there, strictly 100–150 characters
+- `process_description` — **how** you got there, 100–500 characters
   (this is enforced; too short or too long is rejected)
 
 Keep the two dimensions distinct: the milestone says *what* was reached, the

package/dist/cli.js

@@ -511,13 +511,20 @@ Report progress as you go, not only at the end:
 If the scope changes, \`task_update\` the description/goals instead of silently
 doing something else.
 
-### 4. Record milestones — \`task_operation_create\`
+### 4. Record milestones — \`task_operation_create\` — **as you work**
+Call this tool the moment a stage is reached — **not after the fact**,
+not in a batch at the end. Finished a chunk of code? A test just went
+green? Hit a blocker? Made a decision? Record it **immediately**, then
+keep working. The record is the running log of the work, written while
+it happens.
+
 This tool has **two orthogonal dimensions** and you must keep them distinct:
 - **state / milestone dimension** — \`milestone_type\` + \`milestone_title\` +
   \`milestone_description\`: *what* was reached (e.g. "GREEN: all tests pass").
 - **process dimension** — \`process_description\`: *how* you got there —
-  strategy + tool steps, strictly **100–150 characters**.
-  Too short = rejected (no value); too long = rejected (use the session log).
+  the operations just performed and why, written in the moment,
+  **100–500 characters**. Too short = rejected (no value);
+  too long = rejected (that is a log, not a summary).
 
 Rules: do **not** use the process field to restate the milestone, and do not
 use milestones as a substitute for progress. Milestones mark *state
@@ -3263,7 +3270,7 @@ function formatStatus(report) {
 }
 
 // ../../../packages/cli/src/main.ts
-var VERSION = "0.7.5";
+var VERSION = "0.7.6";
 async function main(argv) {
   const parsed = parseArgs(argv);
   switch (parsed.command) {