Agents / Skills

Feature Brief

Skill

Writes the one-page brief that aligns everyone before a feature gets built: the problem with its evidence, who it serves, what success measurably means, what is out of scope — the thinking, forced onto paper, where disagreement is cheap.

Best for

  • Features that start building before anyone agrees what they are
  • The 'wait, I thought we were building X' meeting in week three
  • Giving builders (human or AI) a target instead of a vibe

What you give it

  • The feature idea and its context: the evidence, the requests, the strategy it serves

What you get back

  • The brief: problem (evidenced), audience (specific), proposed approach (one paragraph, not a spec), success metrics (measurable), non-goals (explicit)
  • The disagreements surfaced now: the brief's draft circulated forces the 'actually I assumed…' conversations into week zero
  • The decision hooks: open questions named with owners, so the brief unblocks building instead of becoming another document

How it works

  1. Forces the problem before the solution: what is broken, for whom, evidenced by what — a feature without an evidenced problem is a solution shopping for one.
  2. Keeps the approach at brief altitude: one paragraph of direction, not a spec — the brief aligns intent; design and spec come after alignment.
  3. Makes success measurable and dated: the metric, the threshold, the when — 'users love it' is not a success criterion.
  4. Writes the non-goals loudly: what this deliberately is not — the section that prevents the scope creep and the week-three surprise.

Example

You: Write the brief for 'add commenting to reports' before the team starts.

Result: The brief's drafting surfaced the week-three fight early: the problem evidence (14 support requests, 2 churned accounts citing it) pointed at async review between colleagues — but half the team assumed real-time collaboration (a different, much bigger feature). Decided on paper: async commenting, threaded, email-notified; real-time explicitly in non-goals with its reasoning. Success defined measurably (comments used weekly by 20% of multi-user accounts within a quarter; the report-sharing support theme shrinking), two open questions assigned (permissions model — product; notification batching — design), and the team built the right smaller thing in three weeks instead of the wrong bigger thing in ten.

Limits — please read

  • A brief aligns; it does not design — the spec and the wireframes follow it, not replace it.
  • Evidence thinner than conviction gets said: 'hypothesis, validated by…' beats confident fiction.
  • One page is the discipline; a brief that needs five pages is usually two features wearing one name — it says so.