Spec md
# Create SPEC.md
You are Codex, acting as my product spec partner and editor.
Goal:
Create a strong SPEC.md for this new project, but do it collaboratively. The spec is “mostly defined” but still fuzzy in places, so you must (1) draft a SPEC.md v0, (2) surface the gaps, and (3) ask me the minimum set of high-leverage questions to finalize it.
What you should do first (before drafting):
1) Read any existing project docs, notes, or issues in the repo that look like a spec, roadmap, README, or requirements.
2) Summarize what you think the product is in 5–8 bullets and list assumptions you’re making.
Then create SPEC.md v0 with this structure (keep it tight, aim < 2 pages):
- 1) Overview (what we’re building, for whom)
- 2) Problem statement (pain today)
- 3) Goals (measurable outcomes) and Non-goals
- 4) Users and primary use cases (top workflows)
- 5) Requirements
- Must-have (v1)
- Nice-to-have (later)
- 6) Constraints (tech, legal/compliance, budget/time, platforms)
- 7) Success criteria (how we judge success, metrics, qualitative)
- 8) Scope boundaries (explicitly what’s out, and what’s deferred)
- 9) Open questions (unknowns we must resolve)
- 10) Risks and mitigations (top 5–10)
- 11) Milestones (high-level vertical slices, 4–8 max, no detailed tasks)
After SPEC.md v0, ask me questions:
- Ask ONLY the questions that materially change decisions or scope.
- Prioritize questions that unblock architecture and MVP slicing.
- Group questions into:
A) Must answer now (blocks next step)
B) Should answer soon (important but not blocking)
C) Can defer (nice to clarify)
Guidelines:
- Be blunt about ambiguity. If something is vague, call it vague.
- If requirements conflict, point it out and propose a default.
- Always propose a “reasonable default” for each open question so I can just say “yes/no”.
- Avoid buzzwords. Write like an engineer/product person, not a pitch deck.
Output — write to files (required):
1) Create/update SPEC.md with the v0 content.
2) Append an “## Open Questions” section at the bottom of SPEC.md with all blocking questions, grouped A/B/C with suggested defaults.
Do NOT leave questions only in chat. A new session must be able to read SPEC.md and see exactly what needs answering.
Output (chat):
- Confirm SPEC.md written
- List your assumptions (short bullets)
- State how many open questions remain and their priority groups
Now begin.when to use it
Community prompt sourced from the open-source GitHub repo kylehuirevvision/repo-rails (MIT). A "Spec md" style prompt — adapt the placeholders and specifics to your task. Imported as-is and not independently retested here, so check the output before relying on it.
tags
writingcommunitygeneral
source
kylehuirevvision/repo-rails · MIT
more in Writing
Writing✓ tested
Explain anything to a smart friend
great teacher who refuses to dumb things down
Writing✓ tested
Line-edit my draft (keep my voice)
sharp copy editor who tightens without flattening
Writing✓ tested
Outline a long piece before you write it
editor who structures the argument before a word is drafted