How To

Stadium 8 handles all the implementation complexity: the architecture decisions, the test writing, the quality gates, the build pipeline. Your job is to be precise about what you want.

That sounds simple. In practice, it is the hardest part. The quality of what gets built depends directly on the quality of your input. Vague requirements produce vague software. Clear requirements produce software that works the way you expected.

This section covers the skills that make the difference between a good output and a great one.

• Thinking in Epics and Stories: how to structure your application as a hierarchy Claude can work through
• Writing Requirements That Work: how to write stories with success conditions that produce the right behaviour
• Keeping Stories Small: why smaller stories produce better results and how to recognise when a story is too large
• Preparing Your documentation/ Folder: what to put in documentation/ before you type /start

A Different Way of Working

If you have used low-code tools before, Stadium 8 requires a shift in how you approach development.

The old pattern was iterative and exploratory: get something out quickly, run it, see how it feels, tweak until it’s right. That works when changes are cheap and the tool is forgiving of vague direction.

Stadium 8 is spec-driven. It performs best when it has a clear, complete picture of what needs to be built before development begins. Think of it like briefing a contractor: the more complete the brief, the better the outcome. Vague specs lead to rework; clear specs lead to clean execution.

• Front-load your thinking. Before running /start, define the full scope of what you are building. Work through edge cases, business rules, and UI behaviours as thoroughly as you can.
• Write your specs out. A bullet-point list, a description, or a structured document all work. What matters is that the intent is clear and written down before you engage Stadium 8.
• Resolve uncertainty before starting. If you are not sure about a detail, try to settle it before running /start rather than hoping to fix it mid-workflow.