Install any skill in seconds. Free to start, no credit card required.
Get Started Free →gsd-build/write-milestone-brief
Synthesize the current conversation into a milestone brief (PRD). Writes to `M###-CONTEXT.md` by default, or files a GitHub issue only with explicit user confirmation.
1 of 22 test cases passed with the skill.
Tokens, turns and time describe resource use, not a dollar price.
Lift withheld: 1 comparable cases; this report requires 8.
A test case the skill fixed. Same model, same prompt, with and without the skill.
We just finished drafting the context brief for milestone M011 (Data Export). I feel our data retention and purge strategy might still be weak. What next steps should be offered to address this uncertainty?
| Checked | Without skill | With skill |
|---|---|---|
| Iterating on the brief using grill-me is offered as an available next step. | Missed | Passed |
The instructions your model reads when the skill loads.
Typical invocation points:
discuss phase before moving to plan<core_principle>
SYNTHESIZE, DO NOT RE-INTERVIEW. Use what is already in this conversation. If a decision is genuinely missing, note it in Open Questions — do not relitigate.
REAL OUTCOMES, NOT TASKS. M###-CONTEXT.md describes what the user can do when the milestone ships, what scenarios must pass for "done," and what architectural decisions were made. It does NOT list tasks or implementation steps — those belong in M###-ROADMAP.md and S##-PLAN.md.
NO FILE PATHS OR LINE NUMBERS IN THE BRIEF. Those go stale. Describe modules, interfaces, and behaviors. The roadmap and plans can cite code locations; the brief should outlive refactors. </core_principle>
Find the active milestone:
.gsd/STATE.md — it names the active milestone.gsd_milestone_new or the /gsd new-milestone flow — do not create directories by hand.Read src/resources/extensions/gsd/templates/context.md (the full path is shown in the templatesDir system-prompt field). Match its structure exactly — parsers and downstream prompts depend on the headings.
Before filling the template, sketch the major modules the milestone will build or modify. Actively look for opportunities to extract deep modules — ones that encapsulate a lot of functionality in a simple, testable interface that rarely changes. A deep module is more testable, more AI-navigable, and survives refactors.
If the modules are non-obvious, offer the user a brief check-in: "The milestone touches modules A, B, and C. A can be extracted as a deep module that hides X. Does that match your thinking?" One round. Then proceed.
test cases passed with the skill
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.