create-milestone — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited create-milestone (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
This skill bridges the gap between tranche-level shaping and feature-level delivery. Use it when /shape clarified work that requires multiple independent PRDs — the result is too large or too decomposable for one PRD. The goal is to create just enough GitHub-native structure to sequence feature bets, pick a tracer bullet, and let the selected feature re-enter the normal pipeline with a researchable brief.
One question per turn. When confirming the branch, reviewing bets, or asking the user anything, ask one question at a time and wait for the answer before asking the next. Never batch questions into a list.
>
Prefer single-select. Use single-select multiple choice when the user is choosing one direction, one priority, or one next step.
>
Use multi-select rarely. Reserve it for compatible sets — goals, constraints, non-goals, success criteria — that can all coexist. If prioritization matters, follow up asking which selected item is primary.
>
Use the platform's question tool when available. In Claude Code, useAskUserQuestion; in Codex,request_user_input; in Gemini,ask_user. Otherwise, present numbered options in chat and wait for the user's reply before proceeding.
This is a primary planning branch that follows /shape only when the shaped work is too large for a single PRD.
Use /create-milestone when:
/shape already produced a closing summary with choices, assumptions, impositions, and structural signals/researchDo not use it when the work already fits inside one PRD, when a feature is already research-ready, or when the next need is decomposition or implementation.
/shape can clarify an entire app or product area, but /research needs a narrower question than "how should we build the whole thing?" /create-milestone turns tranche-level understanding into feature-level bets without creating a giant speculative PRD or introducing local roadmap files.
Feature issues created by this skill move through three explicit states:
roadmap bet — lightweight feature candidate attached to the milestoneresearch-ready — same issue, expanded enough to support /researchprd — same issue, expanded by /write-a-prd into the shaped pitchDo not create a duplicate PRD issue by default. Preserve one canonical feature issue unless the bet fans out so materially that multiple PRDs are clearly required.
Before creating anything, confirm that the shaped work is too large for a single PRD.
Ask these questions one at a time — ask one, wait for the answer, then proceed to the next:
If the answers suggest the work already fits one bounded pitch, do not continue. Return to the normal /research path.
Create one GitHub milestone representing the tranche or v1 scope.
The milestone should make these items explicit:
Do not turn the milestone itself into a giant spec. The milestone is the container and progress tracker, not the planning artifact that carries all detail.
Create a small set of feature issues attached to the milestone.
Keep the set deliberately limited. Create only enough issues to define the tranche clearly and sequence the work. Avoid generating a giant backlog.
Each feature issue should include:
Current maturity: roadmap betIf labels are available, add a bet label alongside the written maturity field.
Order the feature bets using two rules:
Choose one issue as the tracer bullet. It should be the smallest meaningful feature that tests the riskiest integration or core product assumption.
Avoid sequencing by convenience alone. The milestone should burn down uncertainty early, not merely produce visible progress.
When a feature is selected to enter the delivery pipeline, expand that same issue from roadmap bet to research-ready before invoking /research.
The research-ready brief must include:
If labels are available, move the issue label from bet to research-ready.
Do not send a raw roadmap bet into /research.
Once a feature is research-ready, it re-enters the default pipeline at /research, not /shape, because the tranche-level shaping already happened.
Normal progression for that feature becomes:
/research/write-a-prd/prd-to-issues/execute/pre-merge/compoundIf /research shows the milestone-level assumptions were materially wrong, backtrack to /create-milestone or all the way to /shape rather than forcing the work forward.
When the milestone's feature issues that define the tranche are complete, close the GitHub milestone.
If the tranche taught something reusable beyond a single feature, /compound may capture tranche-level lessons after closeout.
Use this structure for each new milestone feature issue:
<feature-bet-template>
roadmap bet
[What user or business problem this feature addresses]
[Who benefits, who uses it, or who is affected]
[Why this belongs in this tranche rather than later]
[How much time this problem is worth at milestone-planning level]
[What this likely depends on, if anything]
[What architectural, product, or market truth this feature is meant to reveal]
Tracer bullet / Core capability / Follow-on / Polish
[Explicit exclusions while this remains a roadmap bet]
</feature-bet-template>
/shape with choices, assumptions, impositions, and structural signals for work that is too large for a single PRDroadmap bet state, and a selected feature promoted to research-ready/research once a selected feature has been promoted to research-ready/shape if milestone-level decomposition reveals the original shaping was wrong or too coarse~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.