Mob Elaboration facilitation runbook

Version 0.2 · Unofficial facilitation layer on AWS's AI-DLC methodology · Unvalidated until three teams have run it and reported post-Construction outcomes.

What it is

Mob Elaboration is a ritual from the Inception phase of AI-DLC. The cross-functional team sits in one session while an AI agent, reading the repository, transforms a business intent into questions, requirements and units of work. The team answers the agent's questions and accepts or rejects each proposal. Nothing passes without a human saying yes.

Classic refinement Mob Elaboration
PO writes stories, team reads them Agent writes, team decides
Team asks the PO Agent asks the team and does not proceed without answers
Output lives in Jira Output lives in the repo, where the agent reuses it in the next phase
Recurring weekly grooming One session per intent, about 2.5 hours
Ticket: 1–3 days of human work Unit: hours of agent work plus human verification

The point of a first session is not speed. It is the list of decisions your team cannot make on its own. If the session stalls because nobody in the room has the mandate to answer, it is working exactly as designed. That list — with owners and deadlines — is the deliverable no other meeting produces.

Session runner prompt

The whole process is encoded in one prompt. Get it on the homepage with a copy button, or as raw markdown at /prompt.md.

How to use it:

  1. Open a fresh chat with no standing instructions (custom instructions that make the assistant critique everything will fight the session).
  2. Paste the prompt as the first message — not as an uploaded file. Chats treat uploaded files as things to comment on, not to obey.
  3. The AI's first reply is Phase 0, step 1. From there it runs the checks, the question round, the decomposition, and the closing, one step at a time.
  4. If the AI blocks on something the room has already decided, the facilitator types override — the AI complies, logs it, and moves on.

Roles

  • Facilitator. Owns the timer, the hard stops, and the room. Does not answer domain questions.
  • Driver. The one keyboard. Only the driver types to the AI; everyone else talks to the driver.
  • Intent owner. Wrote the intent, or can defend it. Signs off decisions inside the team's mandate.
  • Mob members. At least two. Domain, engineering, QA — whoever the intent touches.
  • Architect or tech lead. Needed for one thing that cannot be skipped: signing off unit boundaries. Without that sign-off, no unit is labelled autonomous.

Fewer than five people total is a pair, not a mob. Run it anyway as a rehearsal; do not count it as a pilot.

Prerequisites

  1. A written intent. Half a page: business outcome, for whom, at least one measurable success criterion, constraints, at least three "not doing" items, what already exists, and the mandate. No written intent — postpone. A session without one becomes discovery, and discovery pretending to be elaboration produces confident garbage.
  2. A written mandate. What can this team decide alone, and who decides the rest? Get names — every question outside the mandate will need an owner.
  3. A baseline. How long did the last comparable feature take from refinement to pull request? "Unknown" is acceptable, but say it out loud: without a baseline the result is an anecdote.
  4. Physical setup. A visible timer, a visible Decisions Board (whiteboard or shared doc), one keyboard.
  5. One rehearsal. Run Phase 0 and three questions of Phase 2 alone with your tool, the day before. Model portability is unverified; find the seams before the room does.

Tooling

Any chat AI runs the session; what changes is how much context it has.

  • Best: an agentic tool with repository access (Claude Code or similar, with the prompt in CLAUDE.md or pasted first). The agent reads the code, so its questions and unit boundaries are grounded.
  • Workable: a plain chat (claude.ai, ChatGPT, Gemini). Prepare to paste: a glossary of 10–20 domain terms, the list of systems and integrations, and known technical constraints. The prompt asks for exactly these when it has no repo.
  • Projector or shared screen so the whole mob reads the same output. The driver's screen is the session.

The prompt has been tested on no model yet (v0.2 — that is what the pilots are for). Whichever tool you pick, rehearse on it first.

The session

2 hours 25 minutes, hard-stopped:

# Segment Minutes What happens
0 Readiness check 5 Seven checks: intent, people, context, mandate, baseline, timer
1 Kickoff 10 Four rules read aloud; intent owner reads the intent
2 Question round 45 10–15 questions, each with a default assumption if unanswered
3 Break 10 Mandatory
4 Decomposition 45 Units presented one at a time: accept, amend, or reject
5 Risks 15 Optional; only if the timer allows
6 Closing 15 Board read-out, unowned count out loud, artifacts, metrics

The four rules, printed and read aloud at kickoff:

  1. Only the driver types. Several voices in the chat means nobody is accountable for what was said.
  2. "I don't know" is a valid answer. A guess dressed as an answer reaches the code. The AI challenges suspected guesses once; accept the challenge or override it.
  3. No solution design in the question round. Answers describe rules and facts, not implementations. Solution talk gets parked for decomposition.
  4. Every unanswered question goes on the board. With a temporary assumption, an owner, and a deadline — or marked unowned, out loud.

Watch for during the question round: confident answers nobody can source (let the AI challenge once), "don't know, inside mandate" (then the team decides now, intent owner signs), and "don't know, outside mandate" (board item — name an owner or record it as unowned; never assign a default owner). During decomposition: acceptance criteria must be observable ("works correctly" is not a criterion), and unit boundaries are an architecture decision — no autonomous label without the architect's sign-off. No architect in the room means everything is needs-human and Construction waits.

Prompts P0–P5

The session runner drives itself, but rooms stall. These are facilitator lines to type when a phase needs a push — short enough to type live.

P0 — restart a derailed readiness check:

Back to Phase 0. Next check, one at a time.

P1 — an unclear intent, before improvising:

The team's questions show the intent is unclear. State plainly whether you recommend postponing.

P2 — a question round that is drifting into design:

Park all solution talk. Repeat the current question and its default assumption.

P3 — force the board discipline:

Show the Decisions Board and the Metrics Log now. Mark anything without an owner as UNOWNED.

P4 — vague acceptance criteria slipping through:

Re-check the last unit's acceptance criteria. Rewrite anything not observable as Given/When/Then.

P5 — a closing that is running out of clock:

Skip to Phase 6. Board with unowned items first, then the artifacts, then the metrics table.

Intent template

Used in Phase 0 if the intent is missing or incomplete — one section at a time, with the AI:

# Intent: <name>
## Business outcome — one or two sentences; what changes when this works
## For whom — a specific role, not "users"
## How we know it works — at least one measurable criterion
## Constraints — technical, legal, deadline, organisational
## What we are NOT doing — at least three items
## What already exists — systems, data, earlier decisions
## Mandate — what the team decides alone; who decides the rest

Artifacts

The session ends with six markdown blocks, saved to docs/aidlc/<feature>/ in the repository — where the Construction agent will read them:

  • intent.md — the intent as confirmed in Phase 0
  • qa.md — every question, answer, and temporary assumption, in order asked
  • units.md — accepted units with labels, plus a "not reviewed" section if the clock ran out
  • decisions.md — decisions made in the session: what, who, why
  • open-decisions.md — the Decisions Board: question, assumption, owner, deadline, units blocked
  • metrics.md — the Metrics Log as a table

Nothing the team did not accept goes into the artifacts.

Pilot metrics

The session-day numbers measure activity: questions asked, "don't know" answers, decisions outside mandate (owned and unowned), units proposed / accepted / amended / rejected, autonomous vs needs-human, overrides, time from intent to accepted units, baseline, skipped checks, context gaps.

Three rows stay empty on session day and are filled after Construction — they are the only rows that measure whether this worked:

  1. Units kicked back or re-scoped during build
  2. Time from accepted units to pull request
  3. Units through review without changes

Fill them in or the session proves nothing. Then log the session — the pilot dataset is the only public evidence on whether this ritual does anything.

Where it breaks

  • The status meeting. More than eight people, and the question round turns into updates. Cap the room.
  • The oracle. The team starts asking the AI what the business rule should be. It runs the process; it does not know your domain. Turn the question back to the room.
  • The silent board. Items get logged and never shown. The board must be physically visible and re-read at every phase close.
  • The polite accept. Units accepted without reading the acceptance criteria. Read one criterion aloud per unit, minimum.
  • The endless amend. A unit amended three times is a unit that should be rejected and re-split.
  • The instant round. Every answer comes immediately. Either the feature is trivial or the team is guessing; the runner will say so — take it seriously.

Retro

Within a day of the session, twenty minutes, four questions:

  1. Which question was the most surprising, and why had nobody asked it before?
  2. Which default assumption was wrong in a way that would have reached the code if nobody had objected?
  3. How many board items already have an owner and a deadline, and how many "will sort themselves out"?
  4. What would we change in the intent if we wrote it again?

Three sessions before anyone changes the process. One session proves nothing in either direction.

FAQ

Does the AI need repository access? No, but it helps a lot. Without it, prepare the glossary, systems list, and constraints from the Tooling section — the prompt asks for them.

Can we run it remote? Yes, with discipline: one shared screen with the chat, the driver rule enforced harder (it breaks faster on calls), and the board in a shared doc everyone has open.

What if we have no architect or tech lead? Run the session, but every unit is labelled needs-human and Construction does not start until someone reviews the boundaries. The label exists precisely so this cannot be skipped silently.

Which AI model should we use? Unverified — v0.2 has been tested on none. Use the strongest model you have access to, and rehearse on it the day before.

Is this official AWS material? No. Mob Elaboration and AI-DLC are AWS's terms; this runbook and prompt are an unofficial facilitation layer. See Provenance.

What does a session cost? About 20 person-hours (8 people × 2.5 h). The bet is that it buys back more than that in Construction — which is what the pilot metrics are for.

Provenance

Mob Elaboration and AI-DLC are AWS's terms and methodology (github.com/awslabs/aidlc-workflows, 2025). The roles, timeboxes, four rules, Decisions Board, prompts and metrics here are an unofficial facilitation layer built on top — version 0.2, unvalidated until three teams have run it and reported post-Construction outcomes. Not an official AWS property.