Fix close-milestone workflow ordering: close milestone before moving unfinished issues
## Summary Correct the ordering of the sprint close-out workflow so the milestone is **closed before** unfinished issues are moved to the next sprint. This preserves GitLab's built-in burndown / completed-vs-incomplete snapshot, which GitLab captures at the instant of closure and only counts issues still attached at that moment. ## Work Track AI Marketing ## Context / Background During the Sprint 6 → Sprint 7 close-out we hit this first-hand: moving open issues to the next sprint *before* closing the milestone caused them to vanish from GitLab's native end-of-sprint report (counted as neither completed nor outstanding), understating the sprint's in-flight work. Our own history-based `sprint-stats` report is unaffected by the order, but GitLab's built-in reports are not. This ticket captures the fix to the tooling so the mistake can't recur. ## Tasks - [x] Reorder `scripts/run-close-milestone.sh` so the close step runs before the move step (report → close → move → credit). - [x] Update `skills/close-milestone/SKILL.md` to match: close (§4) before move (§5), with rationale and the drupalcode HTTP 301 milestone-write-block note. - [x] Fix the `MOVE_OPEN_TO_IID` env-var docs ("after closing" instead of "before closing"). - [x] Fix step cross-references in the skill's "Related skills" section (sprint-stats = step 3, contribution-credit = step 6). ## Acceptance Criteria - [x] Close-milestone script and skill both document and execute close-before-move. - [x] `bash -n scripts/run-close-milestone.sh` passes. - [x] The 301 milestone-write-block caveat is documented in the skill. ## AI Usage - [x] AI Assisted Issue — This issue was generated with AI assistance, but was reviewed and refined by the creator.
issue