Write the idea, not the ticket: keeping the Specify gate short

aSPARK's Product Owner is deliberately not a yes-man. After the first draft it runs a clarify pass that checks the spec against a fixed taxonomy: functional boundaries, data, permissions, error and edge cases, non-functional requirements, integrations, UX states, out of scope. Anything left open comes back as a question.

That is the point. Those questions are the reason the feature is right afterwards. But how you word your idea decides which of them get asked — the interesting ones, or the obvious ones.

The pattern

A good idea for /story-time or /spark answers in passing what would be asked anyway, and leaves open exactly where you want an opinion. Five things nearly always pay off:

1. The visible behaviour, not the implementation. What does the user see and do? Technical decisions belong in the plan, not in the spec.
2. The states at the edges. What does it say when there is nothing? What happens on the first item, the last one, with a hundred of them?
3. Keyboard and focus, as soon as there is a UI. This is the question that otherwise comes back, guaranteed.
4. A number or form you can check against. "Shows how many are open" is weaker than "shows N items left, singular 1 item left".
5. Out of scope, explicitly. One sentence about what does not belong saves a discussion in review and a detour in the plan.

A real example

The feature in our demo video started as exactly one sentence:

Add a filter bar above the todo list with three toggle buttons — All, Active, Done — and a counter that reads "N items left" (singular "1 item left"), counting only active todos. Exactly one filter is selected at a time and is visually marked as selected; All is the default. The list shows only todos matching the selected filter; the counter is independent of the filter. Each filter has its own empty message: "Nothing to do — nice." for Active, "Nothing done yet." for Done; the existing "Nothing here yet" message stays for All. Buttons are real <button> elements, operable by keyboard, with the selected one exposed via aria-pressed. Out of scope: persisting the selected filter across reloads, URL routing, editing todos, animations, and any new dependency or file.

Every one of the five points is in there: visible behaviour, three named empty states, keyboard operation, a checkable counter string, and an explicit boundary.

The Product Owner still pushed back — where it was worth it. One of its questions: when someone ticks a todo with the keyboard under Active, the row leaves the list immediately. Where does focus go then? I had no answer ready, and the answer became an acceptance criterion. That same detail came back later, when the Reviewer found that the focus ring also stayed after mouse clicks.

That one sentence became 3 stories and 29 acceptance criteria. The whole loop, idea to release, took 47 minutes.

What the pattern does not do

It does not shorten the loop; it moves the effort forward. Act, Review and QA take as long as the feature is big. And it does not replace the questions: when the clarify pass finds a gap, that is not a sign of a bad idea — it is the moment a mistake surfaces two hours earlier than it otherwise would.

When you have no idea

Then do not invent one. /next-steps surveys the project's current state — what shipped, what is in flight, what stalled, what the constitution requires — and proposes one concrete next feature. The proposal is advisory; nothing is written or approved. Whatever comes out of it you then hand to /story-time or /spark as your idea, ideally worded like the one above.