An AI product prompt is a reusable block of instructions you hand a language model to draft one specific thing — a PRD, a product spec, a launch post, a roadmap. You paste in the prompt, add your context, and get back a structured first draft you can edit. Think of it as a template that writes itself. This page is a library of the ones worth keeping, each producing a real markdown file you can work from.
Everyone has a folder of half-remembered "write me a PRD" prompts. The point of this pillar is to make them good, make them consistent, and — the part that matters — make the output land somewhere your team and your agents can actually use it. Here is every prompt:
PRD prompt
A copy-paste prompt that turns a one-line feature idea into a solid PRD — problem, goals, user stories, acceptance criteria.
Product spec prompt
A prompt for a technical product spec: architecture, data model, API surface, and the edge cases people forget.
Launch post prompt
A prompt that drafts a clear, human launch post from what you shipped — for the board, changelog, or blog.
User story prompt
A prompt that breaks a feature into small, testable user stories with acceptance criteria you can turn into tasks.
Roadmap prompt
A prompt that shapes a messy backlog into a sequenced roadmap — now, next, later — with the reasoning kept.
What makes a prompt a template
A template is a document with blanks. A prompt is a template that fills its own blanks. You give it the shape you want — the sections, the order, the level of detail — plus the specifics of your situation, and the model does the writing you would have done anyway.
The good ones share a few traits. They tell the model exactly what document to produce and in what format. They ask for the sections that people skip when they're rushing — non-goals, edge cases, acceptance criteria. And they end with a real artifact, not a wall of chat prose you have to reformat by hand. A prompt that returns clean markdown you can drop straight into your board is worth ten that return something you have to babysit.
Here's the mental model: a plain template makes you do the typing. A prompt makes the model do the typing and you do the deciding. That trade — the model drafts, you decide — is the whole reason these are worth using. You still own what gets built. You just skip the blank page.
Prompts as executable templates in sfora
This is where sfora is different, and it's the reason this pillar sits inside our knowledge base and not in a generic prompt gallery.
In most tools, a prompt's output is trapped in a chat window. You copy it out, paste it into a doc, and hope everyone finds the doc. In sfora, the prompt's output is a file on your board. Everything in sfora is markdown — posts, docs, specs, tasks — so when a prompt produces a PRD, that PRD is a real markdown file living next to the work it describes.
You run these prompts one of two ways:
- Paste it into a post or doc. Open a new post in sfora, drop in the prompt with your context, and let the model draft the PRD right there. It's a real file the moment it's written.
- Hand it to your agent. If you work with Claude Code, Cursor, or the sfora CLI over MCP, give the agent the prompt and it drafts the markdown for you — then writes it straight to your board as a file. No copy-paste at all.
Either way, the output isn't a message. It's a document your team can read, comment on, and turn into tasks — and that your AI agents can open and execute, because agents are equal members of the same workspace. That's what turns a prompt from a party trick into part of how you build.
The flow: prompt → spec → tasks → shipped
A prompt is the front door to a bigger loop. Here's how the whole thing runs when the output lives in your workspace instead of a chat log:
flowchart LR
a[Idea in your head] --> b[Run a prompt]
b --> c[Markdown PRD or spec on your board]
c --> d[Break it into tasks]
d --> e[Humans + agents pick up work]
e --> f{Meets acceptance criteria?}
f -->|No| e
f -->|Yes| g[Shipped]
Each prompt on this page feeds a different point in that loop. The PRD prompt and product spec prompt produce the document at the front. The user story prompt breaks that document into the tasks in the middle. The roadmap prompt sequences the work above it. And the launch post prompt writes up what came out the other end.
The prompts don't just generate text. They generate the artifacts that move a piece of work from idea to shipped — and because those artifacts are files, the next step can pick them up without anyone re-typing anything.
How to run a prompt well
The prompt is half the job. The other half is what you feed it. A generic prompt with rich context beats a clever prompt with none. A few habits that make the difference:
Give it real context, not a category. "A settings page" gets you a generic settings page. "A settings page where a team admin can rotate their org's API key, see when it was last used, and revoke it" gets you a PRD you can almost ship. Name the person, the action, and the reason.
Say what you're not building. Models are eager. Left alone, a PRD prompt will scope you a small empire. Tell it the non-goals up front — "no billing changes, no new roles this version" — and it drafts something you can actually finish.
Ask for the format you'll use. Every prompt here asks the model to return markdown with specific headings. That's on purpose. Markdown drops straight into a sfora post or a repo, and every model reads and writes it natively. If you want the output to be a file, ask for a file.
Then edit. The draft is a draft. The model is fast and thorough, but it can't make the judgment calls — what to cut, what matters most, where the real scope ends. That part stays yours. Read the draft, kill half of it, and keep the half that's true.
Common mistakes
The same few things go wrong with product prompts often enough to name:
- Treating the output as final. The draft gets you to a strong starting point, not a finished document. If you ship what the model wrote without cutting it down, you'll ship something twice the size it should be.
- Vague acceptance criteria. A prompt will happily write "the feature should feel fast." That's not testable. Push it — and yourself — for criteria a person or an agent could actually check. This matters most when an agent might be the one implementing it.
- Leaving the output in the chat. A PRD that lives in a chat window is a PRD nobody will find next week. Get it into a file, on the board, next to the work.
- Using one prompt for everything. A PRD prompt writes a bad spec, and a spec prompt writes a bad launch post. Match the prompt to the document. That's why there's a separate one for each.
Where sfora fits
sfora is a workspace for building products with humans and AI agents on the same team, where everything — posts, docs, specs, tasks — is a markdown file. That's what makes these prompts more than a clever chat trick.
Paste a prompt into a sfora post and the draft is a file the moment it's written. Hand it to your agent over the CLI or MCP and the agent writes the file for you. Either way the output lands on your board, where a person can turn it into tasks and an agent can pick those tasks up and build against them. The prompt starts the work; the workspace carries it to shipped.
If you're here for one document in particular, start with the PRD prompt or the product spec prompt. For the bigger picture on writing requirements with AI — what a PRD is and how to make it something agents can run — read the AI PRDs guide. And see the docs for how agents read and write files in your workspace.