Backlog

A backlog that is only a list of tasks leaves all the thinking behind in the documents. This skill turns the discovery into work instead. Every story has to pass one hard test: after this story, can the named persona really do that thing on the running system?

Skill name: planning-epics-stories-atlassian. It reads everything before it: the brief, the personas and journeys, the domain model, the technical frame and the design brief.

How to start it

In a session that has the discovery in it:

Let's cut the backlog. Start with the epics, one per journey.

In a new session, name the skill, say where the discovery is, and name the Jira project the issues go into:

/planning-epics-stories-atlassian The discovery is at <Confluence URL> and the
Jira project is ACME. Let's cut the backlog.

What a story is

A story promises one function, and it holds everything someone needs to build it. Whatever the persona is missing for that function belongs in the story: schema, endpoint, view, delivery, migration, configuration. And nothing belongs in it that only a later story needs.

The whole skill rests on that rule. It is also the reason why there are no infrastructure stories. A database table that nobody can reach yet promises no function.

What it works out with you

One epic per journey. Then the skill writes the stories under them, checks each one against the rule above, and puts them in an order where every story builds on the ones before it.

What it creates depends on each journey’s status. A draft gets nothing yet. A journey in review gets its epic, without stories, because its details can still change. An agreed journey gets its stories.

Section of a story	What goes in it
The promise	As a persona I want a capability, so that a value. The persona can really do that afterwards, on the running system.
Business context	A few sentences on the need behind it, plus the persona and the journey as cards.
Implementation notes	Everything the promise needs, on all layers: schema and migration, endpoint and validation, the screen and its states, delivery, integrations, edge cases, test level. Plus the technical frame as a card, and the subject area the story changes if the domain model has more than one.
Design	The screen the story touches, as a card. A story that a person operates always touches a screen. If the design has none yet, the skill says so instead of leaving the section out.
Acceptance criteria	Given, When, Then, from the view of the persona. What they do and what they see after that. So “the address appears with a copy button” and not “the response contains the address”.

Every story holds its own context, and that is on purpose. Whoever gets only the story, a person or an agent, can read from it who it is for and why. The same persona card therefore shows up on several stories. That repetition is wanted: a story you can read on its own is worth more than a page that repeats nothing.

The acceptance criteria are a real checklist. The build is checked against them later, so nobody has to maintain a second field for it.

Where it lands

Jira issues: one epic per journey, the stories under it, and tasks for work that promises no product function. The skill also goes back to the journey pages and fills in the table of related work items that stayed empty until now.

Note

Only this skill creates and changes issues. No other skill does it, and no agent does it either. An issue that somebody files next to it follows none of the rules above, and nothing corrects that later. Moving a status, assigning someone and commenting on what happened belong to the development flow, not to this skill.

The rule holds in the other direction too. This skill writes issues from the discovery pages and from nothing else, so it is not the way to file a one-off ticket.

Coming back to it

A backlog is not finished when you write it. You run the skill again when the product changes: a capability nobody planned, a story that has to change, a journey that came later.

On a second run it checks for every journey whether its epic still exists in Jira. It looks at the key on the journey page, or at a matching summary in the project. An epic that still exists gets used again, not copied. If the key is dead, because somebody deleted the issue, the skill creates a new epic and writes the new key onto the journey page. A journey that is agreed by now gets its stories under the epic it already has.

When a journey goes back to Draft, or its page is gone, its epic is left over. The skill tells you so and gives you the key. It never deletes the epic itself, because whether it goes is your call.

It works from the discovery pages while it does this. If it finds something that contradicts them, it does not stay quiet about it. It names the change, puts it into the page above first, and writes the stories from the corrected version. So the brief and the journeys change with the product instead of getting old.

Next

The project files, so that the conventions are written down once instead of in every story. Then the stories go to the Claude Code roles.