Part of #63 (Phase 1).
The problem
This repo has two issues registered as project trackers in the dashboard's projects.yml — #3 as slug qe-style-skills and #12 as audit-skills. Measured 2026-08-26 against live state, both fail all three checks in the tracker contract:
| Tracker |
## Where we stand stamp |
Project issue type |
Native sub-issues |
| #3 |
absent |
none |
0 |
| #12 |
absent |
none |
0 |
| #25 (not registered) |
absent |
none |
0 |
The consequence is not cosmetic. C2 §2.1 makes native sub-issues the only source of progress, so a tracker whose work lives in body checkboxes publishes as unmeasured — null, not 0% — and the nightly compliance block flags it untyped besides. Both of these are ours, on a public dashboard, and #3 is additionally mis-titled for half of what it carries.
The work
For #3 and #12: add the ## Where we stand (verified YYYY-MM-DD) heading in C2's exact form over the live-state facts each already states in prose, apply the native type (gh issue edit <n> --type Project), and convert the work each tracks into native sub-issues. #3's nineteen style items and #12's audit-family skills are both currently prose or checkboxes.
#25 is the judgement call and should be decided rather than assumed. It is a long-lived tracker by the family's own genre split, but it is not registered, and it may be better read as a period plan that has outlived its period. Decide which genre it is, then treat it accordingly — a period plan needs the stamp heading and nothing else.
Do this by hand, and take notes. It is the specification exercise for tracker-conform (#49 item 3): whatever proves fiddly to do manually — deciding which prose lines are really the live-state table, splitting checkbox lists into sub-issues without losing their ordering — is exactly what that skill has to handle, and designing it before doing this once means designing against a guess.
Acceptance criteria
Part of #63 (Phase 1).
The problem
This repo has two issues registered as project trackers in the dashboard's
projects.yml— #3 as slugqe-style-skillsand #12 asaudit-skills. Measured 2026-08-26 against live state, both fail all three checks in the tracker contract:## Where we standstampProjectissue typeThe consequence is not cosmetic. C2 §2.1 makes native sub-issues the only source of progress, so a tracker whose work lives in body checkboxes publishes as unmeasured —
null, not 0% — and the nightly compliance block flags ituntypedbesides. Both of these are ours, on a public dashboard, and #3 is additionally mis-titled for half of what it carries.The work
For #3 and #12: add the
## Where we stand (verified YYYY-MM-DD)heading in C2's exact form over the live-state facts each already states in prose, apply the native type (gh issue edit <n> --type Project), and convert the work each tracks into native sub-issues. #3's nineteen style items and #12's audit-family skills are both currently prose or checkboxes.#25 is the judgement call and should be decided rather than assumed. It is a long-lived tracker by the family's own genre split, but it is not registered, and it may be better read as a period plan that has outlived its period. Decide which genre it is, then treat it accordingly — a period plan needs the stamp heading and nothing else.
Do this by hand, and take notes. It is the specification exercise for
tracker-conform(#49 item 3): whatever proves fiddly to do manually — deciding which prose lines are really the live-state table, splitting checkbox lists into sub-issues without losing their ordering — is exactly what that skill has to handle, and designing it before doing this once means designing against a guess.Acceptance criteria
Projectissue type, and native sub-issues for their open workprojects.ymlentry describe the style skills only, with the workplan half moved to this trackeruntypedfindingtracker-conformdesign