Product spec prompt: a copy-paste prompt for a technical spec

Here's a product spec prompt you can copy and use today. Paste it into ChatGPT, Claude, or your coding agent, drop in your PRD or feature idea, and you'll get back a technical spec — the approach, data model, API surface, and the edge cases people forget — as clean markdown ready for your board. Where a PRD says what and why, this spec says how, at the level an engineer or a coding agent needs to start building.

This is a core prompt in our AI prompts library. It pairs with the PRD prompt: write the PRD first, then feed it to this one for the technical detail.

The prompt

Copy this whole block. Paste in your PRD or feature idea where it says so, then send it.

You are a senior software engineer. Write a technical product spec for the
work below. This is the "how" — assume the "what" and "why" are already
decided. Write in plain language: short sentences, active voice, no jargon
unless it's a real technical term, and define it the first time.

PRD or feature: <paste your PRD, or describe the feature in a few sentences>
Stack / constraints: <languages, frameworks, database, anything the approach
has to fit — or say "propose a stack" if it's greenfield>

Before you write the spec, ask me up to 5 clarifying questions about
anything that would change the technical approach. Wait for my answers.

Then write the spec as a markdown file with exactly these sections:

# Spec: <feature name>
**Status:** Draft

## Summary
Two or three sentences: what we're building and the approach in one breath.

## Approach
The technical plan in prose. How the pieces fit. Name the main components and
how data flows between them. Call out the one or two decisions everything
else depends on.

## Data model
The tables, documents, or types this needs. For each: its fields and what
it relates to. Note any changes to existing data and how you'll migrate.

## API / interface
The endpoints, functions, or commands this exposes or calls. For each: the
input, the output, and who's allowed to call it.

## Edge cases and failure modes
The empty states, error paths, race conditions, and permission checks. Be
specific — this is the section that separates a spec from a wish. List what
happens when something goes wrong, not just the happy path.

## Rollout
How this ships safely. Feature flag, migration order, anything that has to
happen first, and how to roll it back.

## Acceptance criteria
Concrete, testable statements that tell us the implementation is correct.
Something a person or an agent could verify pass/fail.

## Open questions
Technical decisions you're unsure about or that need a call from me.

Rules:
- Prefer the boring, proven approach over the clever one. Say why if you
  don't.
- Every edge case and acceptance criterion must be checkable.
- If a requirement is ambiguous, put it in Open questions — don't guess.
- Return only the markdown, ready to paste into a file.

What you get back

You get a markdown spec with the eight sections above, written for your feature and your stack. The two sections that earn their keep are edge cases and failure modes and acceptance criteria — the parts a rushed spec skips and a good one lives on. The prompt pushes the model to enumerate the empty states, error paths, and permission checks, so you catch in the spec what you'd otherwise catch in code review.

Like the PRD prompt, this one asks clarifying questions before it drafts. A spec is full of decisions that depend on details only you have — the existing schema, the constraint you're stuck with, the thing that has to stay backward compatible. Answer the questions and the approach comes back grounded instead of generic.

How to run it in sfora

The prompt works in any AI chat, but a spec is most useful as a file next to the work — and in sfora, that's exactly what it becomes.

• Paste it into a post or doc. Open a new post in sfora, drop in the prompt with your PRD pasted in, and let the model draft the spec. It's a real markdown file the moment it's written, sitting next to the PRD it came from.
• Hand it to your agent. Give the prompt to Claude Code, Cursor, or the sfora CLI over MCP. The agent writes the spec straight to your board — and because agents are equal members of the same workspace, the same agent can then build against it, checking its work against the acceptance criteria the spec defines.

That's the payoff of a spec being a file rather than a chat log: the agent writing the spec and the agent building the feature can be the same one, reading the same document.

PRD first, then spec

These two prompts are a chain, not alternatives. The PRD prompt decides what to build and why — the problem, the goals, the scope. This spec prompt decides how — the approach and the technical detail. Run them in order:

1. Run the PRD prompt. Edit the PRD down to the first version.
2. Paste that PRD into the spec prompt's "PRD or feature" line.
3. Answer its clarifying questions and get the spec.
4. Break both into tasks and start building.

Keeping them separate keeps each one focused. A PRD cluttered with database schemas is hard for a stakeholder to read; a spec padded with market rationale is hard for an engineer to use. Two documents, two prompts, one chain.

Where sfora fits

sfora is a workspace where humans and AI agents build on the same team, and where every document — specs included — is a markdown file. Run this prompt in a sfora post and the spec lands on your board as a real file. Hand it to your agent and the agent writes the file itself.

From there the loop closes: the PRD says why, the spec says how, and a coding agent — or a person — picks up the tasks and builds against the acceptance criteria in both. Because the spec is a file the agent can open, the document that describes the build is the same document the build runs on.

Next, turn the spec into work with the user story prompt, or start from the top with the PRD prompt. For the concepts behind writing requirements agents can execute, read the AI PRDs guide, and see the docs for how agents read and write files in your workspace.