Field report from a first real run of /qe:workplan update (qe 0.7.0) against QuantEcon/quantecon-theme.mystmd#147. Two gaps, both about where the resume pointer lives rather than whether the skill knows about it.
The concept is already there — this is not a "missing feature" report
To be precise about what the skill does say, because it says most of it:
| Line |
What it specifies |
create step 3 |
work blocks "each naming its gate, with the front of the plan explicit: what leads next session, and why" |
resume |
"the front of the plan re-pointed" |
update |
"set the resume pointer — what leads next session, and why" |
read |
reports "the front of the plan (what leads and why)" second, after the stamp |
| Anchor and sweep |
"the conversation supplies only what traces cannot … and the resume pointer" |
So the behaviour is well specified at all four verbs. The gaps are structural.
Gap 1 — the resume pointer is a property of a section, not a section
It appears only as a qualifier on the work blocks bullet: blocks are dependency-ordered "with the front of the plan explicit". Nothing names a place a reader goes to find it, and nothing makes it findable independently of the blocks.
That is satisfiable in spirit while still failing the skill's own acceptance test, which is what had happened here. #147 carried a "Sequencing" section describing what was independent and what could run in parallel — genuinely dependency-ordered, arguably compliant with the bullet. But a fresh agent reading it could not tell which item to start, because "these can run in parallel" is not "start here". The fix was to add an explicitly named ## Next session — resume here section at the top of the body, above the background, carrying the item, why it leads, and the two findings a fresh context would otherwise have to rediscover.
Suggestion: promote the resume pointer to a named, required section in the body spec, placed near the top rather than inside the blocks — it is the first thing read reports after the stamp, so it should be the first thing the body presents.
Gap 2 — there is no body spec for the long-lived tracker
The skill establishes two genres and gives each a lifecycle: a period plan closes and is succeeded, a tracker "gets read, resume and update only". But create step 3 is the only body spec, and its constituents are period-plan shaped — an opening line about succession ("continuing from #N"), work blocks, a carry-forward-oriented "explicitly not doing". Nothing describes what a tracker body contains.
In practice that meant inventing the structure. #147 needed sections a period plan does not have (a durable scope statement, a state table spanning the whole project, an explicit statement of its own genre so a future session does not close it on finishing a phase) and did not need the ones create specifies. Running update against it worked fine because update's mechanics are genre-neutral — but nothing told me what the body should look like, and a second agent would likely invent a different shape.
Suggestion: give the tracker its own short body spec alongside create's, even if most rows are shared. Worth stating explicitly that a tracker should declare its genre in its own body, which is what stops a later session from offering close on it.
Why these two are the same problem
Both are cases where the convention encodes what a session should do and leaves what the artifact should look like implicit. The acceptance test is about the artifact — "a fresh agent, given only the issue, can resume the work" — so anything load-bearing for that test should be a named part of the body, not a behaviour a verb is trusted to have performed.
Not a finding
The date-rollover gotcha fired exactly as documented — #147's body had been revised three times in one day, every stamp reading a bare 2026-08-26, so the revisions could not be ordered against each other or against the comment thread. The convention already requires time and timezone; the body simply predated the skill. Worth recording only as confirmation that the gotcha is real and worth keeping prominent.
Related: QuantEcon/qeps#15 (scoping ruling: the practice stays in these skills, the tracker unit interface goes to a QEP) and QuantEcon/qeps#17 (compliance review once that QEP lands), which measures #147 against the proposed unit.
Field report from a first real run of
/qe:workplan update(qe 0.7.0) against QuantEcon/quantecon-theme.mystmd#147. Two gaps, both about where the resume pointer lives rather than whether the skill knows about it.The concept is already there — this is not a "missing feature" report
To be precise about what the skill does say, because it says most of it:
createstep 3resumeupdatereadSo the behaviour is well specified at all four verbs. The gaps are structural.
Gap 1 — the resume pointer is a property of a section, not a section
It appears only as a qualifier on the work blocks bullet: blocks are dependency-ordered "with the front of the plan explicit". Nothing names a place a reader goes to find it, and nothing makes it findable independently of the blocks.
That is satisfiable in spirit while still failing the skill's own acceptance test, which is what had happened here. #147 carried a "Sequencing" section describing what was independent and what could run in parallel — genuinely dependency-ordered, arguably compliant with the bullet. But a fresh agent reading it could not tell which item to start, because "these can run in parallel" is not "start here". The fix was to add an explicitly named
## Next session — resume heresection at the top of the body, above the background, carrying the item, why it leads, and the two findings a fresh context would otherwise have to rediscover.Suggestion: promote the resume pointer to a named, required section in the body spec, placed near the top rather than inside the blocks — it is the first thing
readreports after the stamp, so it should be the first thing the body presents.Gap 2 — there is no body spec for the long-lived tracker
The skill establishes two genres and gives each a lifecycle: a period plan closes and is succeeded, a tracker "gets
read,resumeandupdateonly". Butcreatestep 3 is the only body spec, and its constituents are period-plan shaped — an opening line about succession ("continuing from #N"), work blocks, a carry-forward-oriented "explicitly not doing". Nothing describes what a tracker body contains.In practice that meant inventing the structure. #147 needed sections a period plan does not have (a durable scope statement, a state table spanning the whole project, an explicit statement of its own genre so a future session does not close it on finishing a phase) and did not need the ones
createspecifies. Runningupdateagainst it worked fine becauseupdate's mechanics are genre-neutral — but nothing told me what the body should look like, and a second agent would likely invent a different shape.Suggestion: give the tracker its own short body spec alongside
create's, even if most rows are shared. Worth stating explicitly that a tracker should declare its genre in its own body, which is what stops a later session from offeringcloseon it.Why these two are the same problem
Both are cases where the convention encodes what a session should do and leaves what the artifact should look like implicit. The acceptance test is about the artifact — "a fresh agent, given only the issue, can resume the work" — so anything load-bearing for that test should be a named part of the body, not a behaviour a verb is trusted to have performed.
Not a finding
The date-rollover gotcha fired exactly as documented — #147's body had been revised three times in one day, every stamp reading a bare
2026-08-26, so the revisions could not be ordered against each other or against the comment thread. The convention already requires time and timezone; the body simply predated the skill. Worth recording only as confirmation that the gotcha is real and worth keeping prominent.Related: QuantEcon/qeps#15 (scoping ruling: the practice stays in these skills, the tracker unit interface goes to a QEP) and QuantEcon/qeps#17 (compliance review once that QEP lands), which measures #147 against the proposed unit.