Thinking in Epics and Stories
Stadium 8 builds what you describe. The quality of the output depends directly on the quality of your input. The tool handles all the implementation complexity. Your job is to be precise about what you want. That job breaks down into two things: define your epics, define your stories. Everything else, you leave to Stadium 8.
What Is an Epic?
Section titled “What Is an Epic?”An epic is a major feature area: a coherent module of your application. Think of it as a section of your app that a user would recognise as a distinct thing.
Examples:
- User authentication (login, logout, protected routes, session handling)
- Product catalogue (listing, filtering, search, product detail page)
- Order management (create, track, update, cancel an order)
- Admin panel (user management, configuration, reporting)
- Dashboard (overview stats, recent activity, quick actions)
A good epic is something you could ship independently without the rest being done. If two epics are so tangled you can’t imagine one without the other, they’re probably one epic.
What Is a Story?
Section titled “What Is a Story?”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 described from the user’s perspective:
- “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:
- “Set up the authentication middleware”: this is a technical task, not user behaviour
- “Build the product management system”: this is too large; it is an epic, not a story
- “Improve the dashboard”: this is too vague; improve it how?
Your Job vs Stadium 8’s Job
Section titled “Your Job vs Stadium 8’s Job”| Your job | Stadium 8’s job |
|---|---|
| Prepare inputs (specs, designs, prototype, API schema) | Read everything and build a plan |
| Approve the epic breakdown | Break the application into logical modules |
| Approve each epic’s story breakdown | Break each epic into user-visible, testable stories |
| Verify behaviour in the browser at manual QA | Write tests, implement code, run quality gates, fix failures |
| Make decisions when Claude explicitly asks | Log all autonomous decisions to the decision journal |
| Plan the next epic while the current one builds | Implement in the background, keep the foreground conversation active |