How Dybs.it works
Dybs.it takes a project from an idea to shipped software in four phases, and keeps you in control of all of them without making you the bottleneck. It replaces "prompt-rolling" (poking an AI until something useful falls out) with a repeatable pipeline: four phases, a team of agents, and a trail of artifacts that carry context from one step to the next.
That pipeline is the BMad Method, the engine Dybs.it runs on. This page is the map. Each phase below has its own page; start here to see how they connect.
The engine is open, and it is not ours. The BMad Method was created by Brian Madison and released as 100% open source. Dybs.it runs it, and these pages describe how it runs here: the phases, the commands, what a click does. For the method itself in full, every workflow, skill and option, the source of truth is the official docs at docs.bmad-method.org (start with the Workflow Map). The BMad Method name and brand are trademarks of BMad Code, LLC.
The shape of the method
The golden thread is artifacts. Analysis produces a brief; the brief feeds the PRD; the PRD (plus UX) feeds the architecture; the architecture feeds epics and stories; each story feeds the code. Nothing is re-derived from memory. The context is written down and handed forward.
The four phases
1 · Analysis: understand the problem
Before you decide what to build, understand the problem, the market, and the domain. You brainstorm, research, and crystallize the idea into a product brief (or stress-test it with a PRFAQ). Led by Mary, the Analyst. → Read the Analysis page
2 · Planning: decide what to build
Turn understanding into a testable plan. John the PM writes the PRD, the product requirements, framed around Jobs-to-be-Done. When there's a UI, Sally the UX Designer adds the UX design. → Read the Planning page
3 · Solutioning: decide how to build it
Winston the Architect lays down the architecture spine (the lean set of invariants everything else must respect) then breaks the plan into epics and stories and runs a readiness check so nothing is missing before you build. → Read the Solutioning page
4 · Implementation: build it, story by story
Plan the sprint, then run the story cycle: create a story, develop it, review it, repeat. Amelia the Engineer builds; Murat the Test Architect (an optional add-on module) guards quality where the risk warrants it. At the end of each epic, a retrospective captures what you learned. → Read the Implementation page · Quality & testing
The story cycle: the beating heart
Most of your time is spent in Phase 4, looping the story cycle. Each story moves through five phases, and in Dybs.it each phase is a click that launches the matching agent command:
| Phase | Icon | What happens | Command |
|---|---|---|---|
| Backlog | ○ | Create the story spec | /bmad-create-story |
| Ready | ◐ | Start developing | /bmad-dev-story |
| In Progress | ◑ | Continue development | /bmad-dev-story |
| Review | ◕ | Run code review | /bmad-code-review |
| Done | ● | Story complete | (none) |
Development and review loop: if code review turns up issues, the story goes back to development until it's right. Then you move to the next story, and when the epic is done, you run the retrospective and the epic-level quality gate.
Note: Dybs.it tracks stories by these phases, not by kanban lane columns. A story is always in exactly one phase, and advancing it is a single action. See Epics & stories.
Where the artifacts live
| Phase | Produces | Lives in |
|---|---|---|
| Analysis | Brief / PRFAQ, research | _bmad-output/planning-artifacts/ |
| Planning | PRD, UX design | _bmad-output/planning-artifacts/ |
| Solutioning | Architecture, ADRs, epics & stories | _bmad-output/planning-artifacts/ |
| Implementation | Story specs, sprint-status.yaml | _bmad-output/implementation-artifacts/ |
| Quality | Test plans, gate decisions | _bmad-output/test-artifacts/ |
You browse and edit all of them in the Documents view.
Do I have to do every phase?
No. The method scales to the work:
- Greenfield, ambitious project? Run all four phases in order.
- Brownfield or a small change? Go lighter: a quick spine and a couple of stories may be enough. The architecture step even ratifies an existing codebase instead of designing from scratch.
- Just need one thing built? The method offers a unified
/bmad-quick-devpath that clarifies, plans, implements, and reviews in one workflow.
The discipline is the same at every size: understand, plan, structure, build, and write down what you decide.
Next steps
- Meet the team that drives it → The agents
- Start at the beginning → Phase 1 · Analysis
- Or jump into Dybs.it → Your first project