Product Shaping

The most expensive vibe-coding failure happens before architecture: excellent code for the wrong product. This skill removes ambiguity first, so the build can then go fast.

This skill does not implement

Its output is a written brief — a section of docs/PRODUCT.md or a feature brief. No endpoints, no components, no migrations. If you find yourself writing code, you've left this skill.

Hand off to the feature skill once the brief is agreed.

The questions

Answer all nine. Short answers are fine; missing answers are not.

1. Who is the user? A specific role, not "users".
2. What are they trying to accomplish? In their words, not in features.
3. What is the primary transaction? The one thing. If there are three, name the first and treat the rest as later.
4. What data is required? The minimum fields that make the transaction work.
5. Who may read it? Who may change it? This becomes the backend authorization tests.
6. What is success? Observable — what is true, and how would we see it?
7. What are the important failure and empty states? First-run, no permission, nothing matching, the operation failed.
8. What is explicitly NOT being built? As important as the scope itself.
9. How will we know it's done? Acceptance criteria someone else could check.

Ask, don't invent

Where an answer genuinely changes the build — permissions, scope boundaries, what counts as success — ask the user. Guessing here is what produces the wrong product efficiently.

Where a routine convention will do, choose it, say you chose it, and move on. Don't turn shaping into an interrogation.

Output shape

Not prose. Something like:

User
  Internal team member

Primary transaction
  Create a project and assign an owner.

Required data
  name · owner · status

Permissions
  authenticated users may read
  project owner may edit
  nobody else may mutate

Success
  New project appears in the project list immediately.

Empty / failure states
  no projects yet → teach + create action
  not the owner → read-only, edit control absent
  create failed → form preserved, error shown on the field

Out of scope
  comments · notifications · attachments · templates

Acceptance
  create / list / edit work on desktop and mobile
  unauthorized mutation rejected by the backend, with a test

That is enough for feature to build against without further guessing.

Size check

If the brief can't be built in one reasonable change, split it. Name the first slice and list the rest as follow-ups — don't silently build a smaller thing than was asked, and don't build all of it at once because the request was one sentence.

Update the record

If shaping changes the product's shape, update docs/PRODUCT.md. If it forces an architectural decision, that is the stop condition in AGENTS.md — raise it here, before implementation, which is the cheapest possible moment.