Draft user stories for a new feature
The feature is agreed in broad strokes, but the team needs wording it can estimate. The agent splits it into stories with conditions you can actually check.
Easy · 15 min · on an event
What you get
Story 3 of 9, Yandex Tracker As a seller, I want to export orders to a file so I can reconcile them with 1C without retyping. Done when: - the file opens in Excel with no broken encoding - zero orders returns an empty file, not an error - a failed export shows which dates did not come through Open: where the file lives after 24 hours — your call.
A sample on made-up data — your numbers will be your own.
Who it fits
- The feature is agreed out loud, but the team needs wording it can put hours against.
- Edge cases usually surface in testing: empty state, external system down, missing permissions.
When it won't work
The solution is still under discussion — you get tidy stories for a scenario that will not ship.
How the agent does it
Describe feature and format
Give the goal, the audience and the boundaries — what is out of scope. Attach one example story and the agent will follow its shape.
Run the breakdown
The agent splits the feature into stories, writes checkable done-conditions for each and walks the edge cases, flagging what is undecided.
Find the filled-in blanks
Have the agent flag requirements that were not in your description, and edge cases it closed with an assumption instead of a question for you.
What you set
Yandex Tracker or Kaiten. By hand: the feature description and its goal, the board or queue, and one example of your story format.
What you'll need
KaitenStarter prompt
Copy the prompt or open it straight in a chat with the agent.
Break the feature [name and one or two sentences about its goal] into user stories and file them in [Yandex Tracker / Kaiten], in [queue or board]. For each story: the role, what they do, why; acceptance criteria as a list of checkable conditions; what is out of scope. Separately go through the edge cases: empty state, external system failure, missing permissions, repeated launch, cancellation midway. Do not invent requirements that are not in the description: where a decision has not been made, file a story marked "needs a decision" with the question inside, rather than your own assumption presented as a requirement. Output a list of stories with the dependencies between them and the order in which it makes sense to do them.
Open in chatCheck the stories. List: — requirements that were not in the feature description — where they came from; — acceptance criteria that cannot be checked without further agreements; — stories that cannot be estimated separately because they depend on neighbouring ones; — edge cases you closed with an assumption instead of a question; — places where one story is really three and will not fit into a sprint; — what can be worded out from the description and what a human must decide before the tasks are filed.
A second prompt — the agent uses it to review its own work and show what's left for you.