Full-tier specs aren't one-size-fits-all. SpecDevShip splits them into two distinct starting points, and picking the right one changes everything about how the first document gets written.
Requirements-First: genuinely nothing to draw from
This is the blank-slate path. No existing app, no mockups, no style guide, no prior version to reference — just an idea and a preliminary plan. requirements.md gets drafted from scratch, straight from what you and the workflow scoped together during intake.
Design-First: something real already exists
This path applies whenever there's existing material to ground the work in — a previous version being redesigned, a competitor being cloned, a Figma file someone handed you, screenshots of an app you're porting. Rather than draft requirements from a blank page, the workflow runs analysis first: app-analysis, design-analysis, art-analysis, and/or product-analysis, whichever apply, extract what actually exists before a single new requirement gets written.
Why this distinction matters more than it looks
The failure mode Design-First prevents is subtle but common: an AI agent asked to "redesign this app" that quietly works from its own impression of what the app probably does, rather than what it actually does. That impression is often close enough to sound right and wrong enough to cause real rework. Grounding the first draft in actual extracted findings — with each requirement's origin marked as "reverse-engineered from app-findings.md" or "new — not present in any" — keeps the distinction between what already exists and what's actually changing visible throughout the whole spec, not just at the start.
How to tell which path you're on
Ask one question: is there something a person could point to right now — a URL, a file, a screenshot — that represents the current or reference state of this thing? If yes, you're Design-First, even if what you're building is substantially different from what exists. If the honest answer is "no, this is genuinely new," you're Requirements-First.
Either way, everything downstream — the EARS format, the acceptance-criteria split, the approval loop — works identically. The only thing that changes is what the first draft of requirements.md is drafted from.