The feature-definition workflow turns a feature you have already decided to build into a complete, structured spec. It does the convergent work of writing the spec and stops at the parts that are yours: the inputs that justify the feature, the effort estimate, and the priority call.
Fill in the bracketed parts and hand it to the workflow.
Define this feature: [the capability you have decided to build, as a short noun phrase]
Clarify answers:
- User problem: [what user problem does this solve]
- Who benefits: [who specifically benefits]
- Success metric: [the one primary metric that says this worked]
- Why now: [what changed that makes this the right time]
A complete spec: a title, a proposal that stays conceptual, user stories, acceptance criteria written as Given / When / Then, an out-of-scope list, dependencies, and the smallest shippable increment.
It does not guess effort. The estimate stays blank for you, because effort is a judgment about your team and your code, not a number to fabricate.
Priority is surfaced as context, not set. The call is yours.
And it will not write a spec around a gap. If any of the four clarify answers is missing, it returns no spec, tells you which one is missing, and stops there. A spec written around vagueness is worse than no spec.
Input:
Define this feature: Saved filter views for a reporting dashboard
Clarify answers:
- User problem: Users rebuild the same filter combinations every visit, which is slow and error-prone.
- Who benefits: Daily dashboard users who track a fixed set of segments.
- Success metric: Share of returning users who open a saved view instead of rebuilding filters.
- Why now: Filter usage has grown and rebuilding is now the top complaint in support tickets.
What comes back (excerpt):
Title: Saved filter views for the reporting dashboard.
Proposal: Let a user name and save a filter combination, then reopen it in one action on a later visit. The saved view restores every filter to the state it held when saved.
A user story: As a daily dashboard user, I want to save a filter combination, so that I can return to it without rebuilding it.
An acceptance criterion: Given a saved view, when the user opens it, then the dashboard applies every saved filter and shows the matching data.
Out of scope: sharing saved views between users; scheduling a view to send on a cadence.
Effort: left blank, your estimate. Priority: surfaced as context, your call.
Input with no success metric:
Define this feature: Saved filter views for a reporting dashboard
Clarify answers:
- User problem: Users rebuild the same filters every visit.
- Who benefits: Daily dashboard users.
- Success metric: [blank]
- Why now: Rebuilding is the top support complaint.
What comes back:
No spec. The workflow stops and reports that one clarify answer is missing, the success metric, and that supplying it will let the spec generate.
This is the stop that makes the output worth trusting. The workflow runs when it has what it needs, and declines in the open when it does not.