Thinking in Epics and Stories
Stadium 8 builds what you describe, so the quality of the output depends on the quality of your input. Your part breaks down into two things: define your epics and define your stories. Claude handles the rest.
What an epic is
Section titled “What an epic is”An epic is a major feature area: a part of your application a user would recognise as a distinct thing.
| Epic | What it might cover |
|---|---|
| User authentication | Login, logout, protected pages, session handling |
| Product catalogue | Listing, filtering, search, product detail page |
| Order management | Creating, tracking, updating and cancelling an order |
| Admin panel | User management, configuration, reporting |
| Dashboard | Overview figures, recent activity, quick actions |
A good epic is something you could ship without the rest being done. If two epics are so tangled you can’t imagine one without the other, they’re one epic.
Claude works out which epics depend on others when it plans them. If your order management needs signed-in users, for example, the plan builds authentication first.
What a story is
Section titled “What a story is”A story is one thing a user can do, or one thing the system does that a user would notice. It lives inside an epic.
Stories are always written from the user’s point of view:
- “A user can log in with their email and password.”
- “The product list shows a ‘no results’ message when no items match the filter.”
- “An admin can deactivate a user account.”
- “An order confirmation email is sent when a purchase is completed.”
Not like this:
| Example | Why it doesn’t work |
|---|---|
| ”Set up the authentication middleware” | A technical task, not user behaviour |
| ”Build the product management system” | Too large. It’s an epic, not a story. |
| ”Improve the dashboard” | Too vague. Improve it how? |
Your job and Claude’s job
Section titled “Your job and Claude’s job”| Your job | Claude’s job |
|---|---|
| Prepare your inputs: specs, designs, API schema, sample data | Read everything and build a plan |
| Approve the project setup and the epic plan | Break the application into epics and map their dependencies |
| Approve each epic’s stories | Break each epic into user-visible, testable stories |
| Test each epic in your browser at the manual test | Write the tests and code, run the quality gates, and fix failures |
| Make decisions when Claude asks | Record its decisions in the epic’s journal, and flag assumptions for you to check |
Confirm each merge into main | Open the pull request, wait for the checks, and merge on your confirmation |
Optionally, plan the next epic ahead with /plan | Park the planned epic, ready for /start to build |