← ClaudeAtlas

milestoneslisted

Create, name, scope, assign, and close GitHub milestones. Use when adding a milestone, deciding whether work belongs in one, or naming the next one. One axis per project (release / date / theme); never as labels.
alunduil/alunduil-chezmoi · ★ 1 · Data & Documents · score 67
Install: claude install-skill alunduil/alunduil-chezmoi
# Milestones A milestone is a *finite, scoped* group of issues converging on a shipping or closing event. If it doesn't converge, it's a label — use `gh label` instead. ## Pick one axis per project - **Release-anchored** — name = the version it targets: `v1.0.0`, `v1.1.0` (semver), or `1.0.0.0` (PVP). Best when the project ships releases. Pre-stable work collapses to one placeholder — `v0.1.0` (semver) or `0.0.1.0` (PVP) — since those names already mean "not yet production-ready"; don't fan out across pre-1.0 versions. - **Date-anchored** — name = the calendar window: `2026-Q2`, `2026-05`, `Sprint 23`. Best when work is time-bounded. - **Theme-anchored** — name = the outcome: `Auth overhaul`, `Public beta`. Best for project phases not pegged to a release or window. Don't mix axes within one project — `v1.1.0` and `2026-Q2` and `Auth overhaul` together leaves contributors guessing where to file. Pick one and inherit it for the next milestone. ## Description: outcome, not inventory The description states the user-visible outcome the milestone delivers — present-tense, the way you'd phrase an OKR objective. Issues are the actions; the milestone is what those actions add up to. - Outcome-shaped: "Auth flows can be configured without code changes." "Cold-start latency under 200ms on the free tier." - Not outcome-shaped: "Refactor auth middleware." (That's a task — file as an issue.) "All v1.1 work." (Restates the title — adds nothing.) A list of issue li