---
name: positioning-brief
description: Work out who it's for, what it replaces, and the one thing only you can claim. Use whenever the value prop is fuzzy.
---

Produce a one-page positioning brief. Interview the user rather than guessing, but read the product first so the questions are specific.

**Six questions, in order:**
1. **Who exactly is this for?** Push until it's uncomfortably narrow. "Developers" is not an answer. "Solo founders shipping their first paid API" is. If they resist narrowing, ask who the last three people to actually use it were.
2. **What are they doing today instead?** The honest answer is usually a spreadsheet, a manual process, or nothing — not a named competitor. Do not let them name a competitor unless real users actually switched from it.
3. **What's the sharp edge?** What they know, have or built that the alternative can't copy this quarter. A feature list is not an edge.
4. **What do they get?** The value proposition in the customer's language, not the architecture. Take their feature list and translate each item into an outcome. If a feature won't translate, it probably doesn't belong in the copy.
5. **Which selling points are actually unique?** Sort every claim into three buckets: only true of you, also true of competitors, and table stakes you must still say because customers check for it. Founders routinely put bucket-two items in the hero. Be blunt about which is which.
6. **What proof backs each one?** A number, a screenshot, a customer sentence, a benchmark. Any claim with nothing behind it either gets proof or gets cut.

**Then the one-liner:**
`For [who] who [problem], [product] is a [category] that [outcome]. Unlike [alternative], it [sharp edge].`

**Then break it, and report the results honestly:**
- **Swap test** — substitute a competitor's name. If it still reads true, it's a category description, not positioning. Rewrite.
- **Stranger test** — would someone with no context repeat it back correctly? If it needs a preamble, it's too long.

Write to `04-positioning/brief.md`. Flag any answer that's still vague rather than smoothing it over in the prose — a brief that hides a weak answer is worse than no brief.

If you cannot get answers — running unattended, or the user says just draft it — infer from the repo and mark every inferred answer **[UNVERIFIED]** in the brief. Never let an inferred answer read as a confirmed one.

If the swap test fails on everything except the `Unlike` clause, that is a finding rather than a copy problem: there is no differentiation yet. Say so plainly and name what would create one. A fabricated edge poisons every artifact downstream.