the run, in detail

A full run, end to end

The reference composition, step by step. Each step names the module behind it.

The shape of it

Human     │ brief, challenge, brainstorm
          ▼
discovery │ scoping → issues + branch carrying the specs
          ▼
tracker   │ refinement → Ready for dev, or sub-issues per context
   ↕      │   ↳ pulls in roles when their answer changes the ticket
team      │
          ▼
Human     │ signs off on designs that are doubtful, critical or risky
          ▼
team      │ manager builds the sprint with the team → To dev
          ▼
team      │ dynamic workflows: implementation, review, QA
   ↕      │   ↳ implementation follows the app's own module
impl      │     and the modules plugged into the app
          ▼
Human     │ review PR, test → Done

Step by step

A human brings a brief human

An idea, a problem, a hunch. Scoping pushes back: does the problem exist? does this solve it? what becomes impossible? where are the edge cases? what is assumed but unsaid?

The one point where sustained human attention pays — and where it costs least.

/scrumia-discovery:scrumia-brainstorm

Scoping produces issues and a specs branch agent

Business features first, then app features — one per app, never two. Then the issues.

Specs ship on a specs/<slug> branch in an open PR: design gets reviewed in the same tool as code, and refinement starts from something fixed rather than a remembered conversation.

/scrumia-discovery:scrumia-split

Refinement makes the ticket executable agent

Four conditions, all checkable:

A feature it belongs to exists and is current
Acceptance criteria are written, identified AC-n, and can fail
The blast radius is known: which apps, which files
No open question blocks the start

Roles with the wider view get pulled in when their answer changes the ticket — not to rubber-stamp it. The ticket may split into sub-issues by context: one per app, since the implementation context differs.

/scrumia-github-project:scrumia-refine 42

A human signs off where it matters human

Escalated: a business rule had to be invented, the split changed the ask, the ticket is wide-reaching, or a role raised a reservation. Everything else moves to Ready for dev on its own.

The manager builds the sprint agent

A batch of tickets that don't collide — two tickets on the same files either serialise or merge. The human approves the batch explicitly.

Dynamic workflows consume the sprint agent

One workflow per ticket, in parallel, each in its own worktree. Each gets a ticket number and nothing else — it loads its own context.

Load context through the specs module
Update the spec before the code, if behaviour changes
Implement following the app's implementation module and the modules plugged in beside it — specific beats generic
Cover each AC-n with a test that can fail
Self-review, then role review based on blast radius
Open the PR

/scrumia-teams:scrumia-sprint

Human reviews and merges human

The PR carries the criterion-by-criterion mapping, the specs it changed, review verdicts, and open reservations with their issues. Agents don't merge, except for categories explicitly listed in config.

Why the spec goes first

Writing the spec first surfaces contradictions before they get encoded — where fixing them is cheapest. If one shows up against another feature, execution stops and asks the business role. It never settles a rule on its own: a rule invented mid-flight becomes everyone's reference without anyone having decided it.

Three gates

Validation cost tracks risk, rather than being uniform.

Gate	Who	When
1 — Automatic	CI, linter, tests	Always. Blocking, no human.
2 — Agent	The roles	Routed by the actual diff, not the declared label.
3 — Human	You	The merge, unless explicitly delegated.

When two roles disagree

The disagreement is passed through as-is, not blended into an average. It's precisely the case that needs a human call — smoothing it destroys the signal.

Dialling autonomy

An explicit setting in .scrumia/config.yaml, not an implicit property.

Level	Human approves	When to use it
`guided`	Each ticket's scoping and each PR	Starting out, while calibrating
`assisted`	PRs only	The intended cruising mode
`autonomous`	PRs outside what `auto_merge` covers	Once trust is established

autonomy:
  level: autonomous
  auto_merge: docs-only   # a PR touching documentation and nothing else

One scalar, not a whitelist

auto_merge is a single setting for the whole project, not a per-category list: none (nothing merges unattended, the default), docs-only (a PR touching documentation and nothing else), or all.

What the human does

1 — Scope and arbitrate

The AI challenges and proposes; the human settles the blocking points.

2 — Sign off on risky designs

Where doubt, criticality or risk warrant it.

3 — Approve the sprint batch

Launching a sprint is a decision, not a consequence.

4 — Review and merge

The final call, unless a category is explicitly delegated.

Everywhere else, agents move on their own. If you find yourself doing something else, that's a signal about the composition — not about your discipline.

On "prepare the next sprint while this one runs"

Not automatable within one session: a subagent can't spawn subagents, and agent teams are experimental with one team per session. Two Claude Code sessions on the same repo get you there — one consuming the current sprint, one refining the next. Since state lives in the tracker rather than in session memory, they stay consistent without coordinating.

Reference Install