Summary
The skill currently writes tracker updates in bulk at the end of a check-in run (Step 3 update-tracker, then Step 5c action results). Actions taken in the middle of a session — comments posted, PRs filed, CI fixes pushed — are not persisted to the tracker until the very end. If the session is interrupted (context limit, crash, user closes window, model error), all that intermediate state is lost and the next check-in has no idea what was done.
This was observed in the 2026-05-03 check-in run, where 14+ distinct actions were taken (5 anti-stale comments posted, 1 new PR filed, 3 PR fixes pushed via subagents, 1 maintainer ping, etc.) and all of them only landed in the tracker at the end after a long manual editing pass. If the session had been interrupted mid-run, none of those actions would have been recorded.
Failure Modes
1. Action loss on interruption
The current flow: do action → continue working → eventually update tracker at end.
If interrupted between "do action" and "update tracker," the action is invisible to the next session. The next check-in will see the issue in the same state as before, won't know a comment was posted, and may post a duplicate or miss the follow-up.
2. Subagent actions are particularly fragile
Subagents (file PR, fix CI, rebase) report results back to the orchestrator, but those results are only persisted to the tracker if the orchestrator remembers to log them. The 2026-05-03 run had 3 background subagents whose results came back as task notifications; logging them required separate manual Edit calls long after the work was done.
3. Tracker update at end is itself error-prone
Doing 10+ Edit calls in a row at the end of a session means:
- Each Edit needs a Read first (per the read-before-edit hook)
- Easy to skip an entry by accident
- Easy to lose the exact wording of what was done (drift between memory and reality)
- The model's context may have already evicted earlier action details
Proposed Fix
Action-oriented persistence model
Every action that changes externally-observable state should write to the tracker immediately. Define an explicit set of "tracker-relevant actions":
- Posting a comment on a tracked issue/PR
- Filing a new issue or PR
- Pushing a fix to a tracked PR
- Closing/reopening a tracked issue
- Discovering a state change (issue closed, PR merged, label added)
- Running a check-in scan (already logged via update-tracker)
For each of these, the skill prompt should require: "After taking the action, immediately add a history entry to the relevant tracker section before proceeding to the next action."
Implementation options
Option A — Helper command (preferred): Add a new tracker-tools.cjs command:
node tracker-tools.cjs append-history \
--tracker \"$TRACKER_PATH\" \
--issue \"owner/repo#NUMBER\" \
--date \"YYYY-MM-DD\" \
--entry \"Posted anti-stale comment citing bun#28175 root cause\"
This would find the right ### owner/repo#NUMBER section, locate its **History:** block, and append the entry. Atomic, fast, no Read-before-Edit dance, no risk of malformed Markdown.
Option B — Update the skill prompt: Add explicit instructions to Step 5c:
"After EVERY action you take (comment, PR file, push, etc.), immediately use the Edit tool to append a **YYYY-MM-DD:** <description> line to that issue's History section before taking the next action. Do NOT batch tracker updates at the end."
Option C — Hybrid: Implement Option A as the mechanism, then have the skill prompt instruct the agent to call it after each action.
Subagent return convention
Update subagent prompts so they emit a structured "tracker-update" payload at the end of their summary:
TRACKER_UPDATE: owner/repo#NUMBER | YYYY-MM-DD | <one-line description>
The orchestrator then knows to immediately call append-history with that payload before continuing.
Acceptance Criteria
Affected Files
bin/tracker-tools.cjs — add append-history command- Skill main file — update Step 5c prompt and subagent prompt templates
references/result-file-schema.md — may need a section on the subagent return convention
Related
- e-stack#2 (batch agents miss PR merge-readiness signals + trust stale tracker data)
Both this issue and #2 share a theme: the skill currently treats the tracker as something to write to, but not something to read from mid-run. Fixing both moves the skill toward treating the tracker as live state, not as an end-of-session report artifact.
Summary
The skill currently writes tracker updates in bulk at the end of a check-in run (Step 3 update-tracker, then Step 5c action results). Actions taken in the middle of a session — comments posted, PRs filed, CI fixes pushed — are not persisted to the tracker until the very end. If the session is interrupted (context limit, crash, user closes window, model error), all that intermediate state is lost and the next check-in has no idea what was done.
This was observed in the 2026-05-03 check-in run, where 14+ distinct actions were taken (5 anti-stale comments posted, 1 new PR filed, 3 PR fixes pushed via subagents, 1 maintainer ping, etc.) and all of them only landed in the tracker at the end after a long manual editing pass. If the session had been interrupted mid-run, none of those actions would have been recorded.
Failure Modes
1. Action loss on interruption
The current flow: do action → continue working → eventually update tracker at end.
If interrupted between "do action" and "update tracker," the action is invisible to the next session. The next check-in will see the issue in the same state as before, won't know a comment was posted, and may post a duplicate or miss the follow-up.
2. Subagent actions are particularly fragile
Subagents (file PR, fix CI, rebase) report results back to the orchestrator, but those results are only persisted to the tracker if the orchestrator remembers to log them. The 2026-05-03 run had 3 background subagents whose results came back as task notifications; logging them required separate manual Edit calls long after the work was done.
3. Tracker update at end is itself error-prone
Doing 10+ Edit calls in a row at the end of a session means:
Proposed Fix
Action-oriented persistence model
Every action that changes externally-observable state should write to the tracker immediately. Define an explicit set of "tracker-relevant actions":
For each of these, the skill prompt should require: "After taking the action, immediately add a history entry to the relevant tracker section before proceeding to the next action."
Implementation options
Option A — Helper command (preferred): Add a new
tracker-tools.cjscommand:This would find the right
### owner/repo#NUMBERsection, locate its**History:**block, and append the entry. Atomic, fast, no Read-before-Edit dance, no risk of malformed Markdown.Option B — Update the skill prompt: Add explicit instructions to Step 5c:
Option C — Hybrid: Implement Option A as the mechanism, then have the skill prompt instruct the agent to call it after each action.
Subagent return convention
Update subagent prompts so they emit a structured "tracker-update" payload at the end of their summary:
The orchestrator then knows to immediately call append-history with that payload before continuing.
Acceptance Criteria
tracker-tools.cjshas anappend-historycommand (or equivalent atomic update path)Affected Files
bin/tracker-tools.cjs— add append-history commandreferences/result-file-schema.md— may need a section on the subagent return conventionRelated
Both this issue and #2 share a theme: the skill currently treats the tracker as something to write to, but not something to read from mid-run. Fixing both moves the skill toward treating the tracker as live state, not as an end-of-session report artifact.