TODO:
May 3, 2026 · View on GitHub
The project uses GitHub milestones on its <tracker> repository to
pin an issue to the release it ships in. Milestones are the hand-off
signal from the remediation developer to the release manager; the
security-issue-sync skill creates and assigns them as part of the
pr merged → fix released transition.
TODO: list every milestone format the project uses, one row per release train.
| Milestone format | Applies to scope label | Example | Source of the version |
|---|---|---|---|
TODO: e.g. Foo-X.Y.Z | TODO: scope label that triggers this milestone format | TODO: e.g. Foo-2.6.2 | TODO: release-plan page / [RESULT][VOTE] thread |
Creating a missing milestone
TODO: the gh api recipe the sync skill uses when the needed
milestone does not yet exist in <tracker>. Most projects keep
this as:
gh api -X POST repos/<tracker>/milestones \
-f title="TODO: milestone title" \
-f description="TODO: optional short description"
Defaults and policy
TODO:
- Default milestone for a new patch-train security issue.
- Legacy milestones that exist in the tracker but should not receive new security fixes.
- Policy for bumping a fix to the next minor release instead of the next patch (high-risk changes, bundles with other changes).
What the milestone unlocks
Once the milestone is set on a pr merged tracker, the
security-issue-sync skill watches for the release to ship and
proposes the pr merged → fix released label swap, which hands
ownership off to the release manager for steps 13–15. See the
repo-level ../../README.md for the step-by-step
lifecycle.