Field report from the plan review of QuantEcon/status-projects#69 and #89 (2026-09-08). The skill's update rule is right and already there — a roadmap changes when an item is added, removed or re-sequenced, when a role changes or a gate records its decision, and never when an item merely closes — but three things around it are unspecified, and the first live two-project review ran into all three.
1. The cadence is unnamed, so regeneration depends on someone remembering
The update rule says what makes a roadmap stale; nothing says when it is redrawn, and nothing in the workplan verbs points at this skill. Proposed: three named moments — when the Decide phase closes (the plan is ruled and the first draw is worth keeping), at a re-plan (any change the update rule names, and /qe:workplan update is where those changes are made), and at wrap-up (/qe:workplan close, so the record carries the final shape) — with the update and close verbs ending by running this skill's compare step and reporting drift, and one line in this skill saying the file is never hand-edited between regenerations: a hand edit is the mirror QEP-6 §7 bans from bodies, moved one file over.
2. A plan-review mode: draw the alternative, not only the tracker
At a plan review the question is often structural — combine two trackers or keep them apart, move items between them, gate one Build phase on another — and a tracker can only show what is. The 2026-09-08 review drew as filed beside as ruled (two projects as two bands, phases as columns, gates and cross-project edges marked), and that pair is what surfaced a priority inversion created by a joint review round, and a group row split across two projects. Proposed: an explicit mode that takes a described alternative (items moved, gates changed) and renders it beside the as-filed figure. The pair is kept as a dated record beside the review — docs/roadmaps/<date>-<slug>.md in the tracker's repository — and is never maintained: the ruled figure becomes the tracker, and the next draw comes from the tracker.
3. The cross-project cut, and where it should live
The skill draws one tracker. Two trackers with native edges between them (in status-projects, #94 blocked by #73 and #74, #97 by #75 and #84, and a registry depends_on between the rows) have no drawing here, and Mermaid's auto-layout could not produce one: with nested subgraphs and cross-subgraph edges it reordered the bands and clipped the cluster titles — mmdc and GitHub run the same engine — so the record had to be a hand-laid SVG on a grid. Proposed: state that the live cross-project view is the projects dashboard's to render once depends_on ships (dependency rows on the project page, chains on the Pipeline, the programme page's plan order); that this skill draws per tracker; and that a multi-tracker figure is drawn only in the plan-review mode above, as SVG when Mermaid tangles, with that gotcha recorded in the skill.
Evidence
The review is docs/reviews/2026-09-08-focus-and-overview-design.md in QuantEcon/status-projects (merged there as #100); the dated record with both figures is docs/roadmaps/2026-09-08-focus-and-overview.md in the same repository; the field report against QEP-6 from the same review is on QuantEcon/qeps#18. Related here: #63, the workplan family tracker, and #68 — this is the roadmap-side counterpart of #68's question, where a derived artefact lives and when it is refreshed.
Field report from the plan review of QuantEcon/status-projects#69 and #89 (2026-09-08). The skill's update rule is right and already there — a roadmap changes when an item is added, removed or re-sequenced, when a role changes or a gate records its decision, and never when an item merely closes — but three things around it are unspecified, and the first live two-project review ran into all three.
1. The cadence is unnamed, so regeneration depends on someone remembering
The update rule says what makes a roadmap stale; nothing says when it is redrawn, and nothing in the
workplanverbs points at this skill. Proposed: three named moments — when the Decide phase closes (the plan is ruled and the first draw is worth keeping), at a re-plan (any change the update rule names, and/qe:workplan updateis where those changes are made), and at wrap-up (/qe:workplan close, so the record carries the final shape) — with theupdateandcloseverbs ending by running this skill's compare step and reporting drift, and one line in this skill saying the file is never hand-edited between regenerations: a hand edit is the mirror QEP-6 §7 bans from bodies, moved one file over.2. A plan-review mode: draw the alternative, not only the tracker
At a plan review the question is often structural — combine two trackers or keep them apart, move items between them, gate one Build phase on another — and a tracker can only show what is. The 2026-09-08 review drew as filed beside as ruled (two projects as two bands, phases as columns, gates and cross-project edges marked), and that pair is what surfaced a priority inversion created by a joint review round, and a group row split across two projects. Proposed: an explicit mode that takes a described alternative (items moved, gates changed) and renders it beside the as-filed figure. The pair is kept as a dated record beside the review —
docs/roadmaps/<date>-<slug>.mdin the tracker's repository — and is never maintained: the ruled figure becomes the tracker, and the next draw comes from the tracker.3. The cross-project cut, and where it should live
The skill draws one tracker. Two trackers with native edges between them (in status-projects, #94 blocked by #73 and #74, #97 by #75 and #84, and a registry
depends_onbetween the rows) have no drawing here, and Mermaid's auto-layout could not produce one: with nested subgraphs and cross-subgraph edges it reordered the bands and clipped the cluster titles —mmdcand GitHub run the same engine — so the record had to be a hand-laid SVG on a grid. Proposed: state that the live cross-project view is the projects dashboard's to render oncedepends_onships (dependency rows on the project page, chains on the Pipeline, the programme page's plan order); that this skill draws per tracker; and that a multi-tracker figure is drawn only in the plan-review mode above, as SVG when Mermaid tangles, with that gotcha recorded in the skill.Evidence
The review is
docs/reviews/2026-09-08-focus-and-overview-design.mdin QuantEcon/status-projects (merged there as #100); the dated record with both figures isdocs/roadmaps/2026-09-08-focus-and-overview.mdin the same repository; the field report against QEP-6 from the same review is on QuantEcon/qeps#18. Related here: #63, the workplan family tracker, and #68 — this is the roadmap-side counterpart of #68's question, where a derived artefact lives and when it is refreshed.