How To

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

That’s the hardest part in practice. 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.

These pages cover the skills that make the difference:

Thinking in Epics and Stories: how to structure your application so Claude can work through it
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 spot one that’s too large
Preparing Your documentation/ Folder: what to put in documentation/ before you type /start
Working From an Existing Design: how to build from a Claude Design or Figma export, wireframes or an HTML mockup
Upgrading Your Project: how to bring your project up to a newer template version

A different way of working

If you’ve used low-code tools before, Stadium 8 needs a shift in how you approach development.

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

Stadium 8 is spec-driven. It performs best with a clear, complete picture of what to build before development starts. 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 you run /start, define the full scope of what you’re building. Work through edge cases, business rules and UI behaviour as thoroughly as you can.
Write your specs out. A bullet list, a description or a structured document all work. What matters is that the intent is clear and written down before you start.
Resolve uncertainty first. If you’re unsure about a detail, settle it before you run /start rather than hoping to fix it mid-build.