The three prompts that actually ship product

Why most prompts fail

Most prompts optimize for an answer. You ask a question, the model produces a confident paragraph, and you feel informed. Then you go back to your tracker, your editor, or your launch checklist and nothing in it has changed. The paragraph was an answer. What you needed was a decision, recorded somewhere that moves the work forward.

The prompts below are the three we use most across our own fleet of coding agents, and they share one rule that matters more than any wording: the output has to be an artifact you can paste into Notion, Linear, Jira, or a pull request without editing. If the model gives you prose about the tasks instead of the tasks, the prompt failed, however good the prose was.

Prompt 1: Spec to tasks

This turns an idea into a backlog. The idea can be a sentence, a page, or a transcript of a conversation. The output is a list of tasks small enough to finish in a sitting, each with an acceptance test, in an order that respects dependencies.

You are breaking a feature into an ordered backlog.

Input: the spec below.

Rules:
- Each task is completable in one sitting (under two hours).
- Each task has: a title, a one-line scope, an acceptance test a reviewer can run, and the tasks it depends on.
- Order tasks so that every dependency appears earlier in the list.
- If the spec is ambiguous, do not guess: add a task titled "Decide: ..." with the two or three options, and mark which later tasks are blocked on it.
- Output as a markdown checklist. No preamble, no summary after.

Spec:
[paste]

The two clauses that do the work are "under two hours" and "do not guess." The first forces decomposition; a model left to its own devices produces four tasks called "implement backend." The second surfaces every ambiguity in the spec as a visible blocker instead of a silent assumption. We routinely learn more about a feature from the "Decide:" items than from the spec itself.

Prompt 2: The critic pass

This finds the gaps before a reviewer, a customer, or an app store does. You run it on the backlog from prompt one, or on a plan, a design doc, or a pull request description. It never proposes solutions. It only finds problems, ranked.

You are reviewing the plan below as a skeptical senior engineer who will be on call when it ships.

Do not propose fixes. Only find problems.

For each problem give:
- Severity: blocks ship / should fix / nit
- The specific line or task it applies to
- The concrete failure: what input or state produces what wrong result
- What the plan would need to say to close it

Look specifically for: missing error paths at IO boundaries, state that is written but never read, actions that are not idempotent, anything irreversible with no checkpoint, assumptions about ordering or timing, and platform parity gaps if more than one client is involved.

Output a table sorted by severity. Nothing else.

Plan:
[paste]

"Do not propose fixes" is counterintuitive and essential. A model that is allowed to fix will fix the first problem it sees and stop looking. A model that is only allowed to find will keep finding. You get a longer, better list, and you make the decisions about what to fix with the full picture rather than one item at a time.

The "concrete failure" field is what separates a real finding from a vibe. "Error handling could be better" is not a finding. "If the network call on step 4 times out, the status is never written and the next run processes the item again" is, and it tells you exactly which task to add.

Prompt 3: The launch copy pass

This produces the words that go in front of users: store listing, release notes, landing headline, the announcement post. Most launch copy is written at eleven at night by the person who built the thing, and it reads like it. This prompt forces variants, forces a constraint set, and forces the copy to be about the user rather than the feature.

You are writing launch copy for the feature described below.

Audience: [who, in one line]
Voice: plain, specific, no hype words (no "seamless", "powerful", "revolutionary", "unlock").
Constraints: headlines under 60 characters; descriptions under 160; no em dashes; every claim must be true of the build described.

Produce:
1. Five headline variants, each leading with the outcome for the user, not the feature name.
2. Three one-paragraph descriptions (under 160 characters each).
3. Release notes as a bulleted list a user would actually read: what changed for them, not what changed in the code.
4. One call to action, under 8 words.

Mark your recommended pick in each group with [pick] and one sentence on why.

Feature:
[paste]

Variants are the point. One headline is a guess; five is a choice, and the model's own "[pick]" with a reason is a surprisingly good first opinion to argue with. The banned-word list is short on purpose; add to it every time you catch a word that makes copy sound like every other launch.

The constraint "every claim must be true of the build described" exists because launch copy drifts toward the roadmap. The model will cheerfully describe the feature you wish you had shipped. Pinning it to the build keeps the listing honest, which matters more than it sounds when an app store reviewer compares the copy to the binary.

The rule underneath all three

Each prompt ends by naming the artifact: a markdown checklist, a table sorted by severity, a numbered set of copy blocks with a pick marked. That is not formatting preference. It is how you know the prompt worked. If you have to rewrite the output before you can paste it into the tracker, the model made you do the last step of its job, and the last step is the one where the decision lives.

Chained together, the three take an idea to a backlog, a backlog to a hardened backlog, and a shipped build to words a user will read, in about twenty minutes of model time. The hours you spend after that are on the building, which is where they should be.

If you want these adapted to your own stack, or wired into the tools your team already uses, tell us what you ship.