v1.45.0

An agent that implements a tracker issue now sets the issue to in progress before the first edit. tasks-core and worktree-ship carry the rule.

The change follows from a review of the sessions on one machine. In 19 sessions that agents read in full, 67 implemented issues never got the status and 3 got it after the work started. Only tasks-start carried the rule, and most of the work started from tasks-core or worktree-ship.

An implemented issue shows as in progress

tasks-core printed the menu of taskmgr guide and no rule. taskmgr guide progress shows the status command as an example and does not say when to run it. The skill now has a section of its own:

• Before the first edit that implements an issue, run taskmgr update <id> --status in_progress.
• A session that hands the implementation to a subagent or a workflow sets the status itself, before the hand-off. In the reviewed sessions, 34 of the 67 issues were implemented by a subagent or a workflow agent whose prompt named no status step.

The rule binds implementation only. A session that files, grooms or repairs the body of an issue leaves its status as it is.

worktree-ship marks the issues a change implements

Step 3 of worktree-ship now marks each tracker issue that the change implements, and that is not started, as in progress. It does this before the first edit, and before a subagent or a workflow gets the work.

• Where the tracker is taskmgr and tasks:tasks-core is available, the run loads that skill for the command.
• Where the tracker has no in-progress status, or the session cannot set it, the run marks nothing. The report of step 8 names each such issue with the reason.
• An issue that is in progress, or further on, is left as it is. A resumed run does not set back a closed issue.

worktree-flow does not depend on tasks: the step works on each tracker, and uses tasks-core only where it is installed.

Changed behavior worth knowing

• A session that implements a taskmgr issue writes a status to the tracker. The issue leaves taskmgr ready and shows under "In progress" on /tasks-board.
• Nothing sets the status back. worktree-merge does not touch the tracker. An issue of an abandoned change stays in_progress until you close it or set it to open. Before this release it stayed open.
• A workflow that implements several issues gets them all marked at its start. If the workflow stops early, the issues it did not reach stay in_progress.
• The status records no owner. A second session that marks the same issue gets no error.
• tasks-core must load for its rule to apply. A prompt that names an issue id and no tracker word may not load the skill. worktree-ship covers that case with its own step.

The worktree-ship step was not run end to end before this release. The tasks-core rule was: in three headless runs on a scratch store, the agent set the status before the edit.

Full Changelog: v1.44.0...v1.45.0