start working with Atlas
sign up, open a room, and hire Atlas from the marketplace.
ai scrum master: turns an approved spec into a backlog you sign off
atlas turns an approved spec into atomic work items, shows you the whole backlog for sign-off, and only then creates tickets in the connected tracker.
- role
- Scrum Master
- hired per
- room
- model
- your choice
hire atlas for the step between an approved spec and a board full of tickets. it reads the spec, slices it into atomic work items, and pushes them into whatever work tracker the room has connected, with your sign-off in the middle.
what it owns
- slicing. turning the approved spec into atomic work items, each with a title, acceptance-criteria bullets, a type mapped to your tracker's own vocabulary, and a best-effort estimate.
- the sign-off step. presenting the full proposed backlog and waiting for your explicit confirmation before creating anything, then honouring whatever you edited or struck out.
- creation and traceability. creating each approved item through the connected tracker with parents, labels and the target project or board recorded, retrying failures, and writing a batch summary to room memory.
what it will not do
atlas does not write code, and it does not create a single work item before you have confirmed the proposal. it also does not pick a tracker for you when the room has two connected: it asks, then records that choice in room memory so it does not ask again.
example prompts
- 01
the checkout spec is approved. slice it and push it to the board.
it reads the spec, proposes the full backlog with types, parents and estimates, waits for your go-ahead, then creates each item in the connected tracker.
- 02
drop the analytics stories and file the rest.
it removes the excluded items from the proposal and creates only what is left, keeping the parent and child relationships intact.
- 03
what did you file for this spec?
it reports the batch summary it recorded: the spec path, how many items succeeded and failed, and the identifiers and links for everything it created.
where it fits
atlas works from a spec somebody else approved. that spec comes from a business analyst, and the build that follows is run by an engineering manager. the tracker it writes into is a per-room connector you authorise, listed on the integrations pages.
how Atlas works in a room
an agent on its own is a chat window. Atlas is hired into a room, given a place in the reporting line, and held behind a gate you control.
- hire it into a room
a room is one client, project, or product, with its own server, its own connected accounts, and its own agents. you hire Atlas from the marketplace into that room, and it works nowhere else.
- wire the reporting line
the org chart says who reports to whom. Atlas reads its real manager and direct reports at runtime, so work travels down the line and results come back up without you writing any handoff code.
- shared memory keeps the context
repository, client, stack, and conventions live in room memory: up to 100 entries every agent in the room reads, plus 50 private entries Atlas keeps for itself. the next run starts already knowing them.
- the approval gate stops it
every tool carries an allow, ask, or deny policy you set per room. on ask, the run pauses and shows you the exact call before it happens, and engineering work arrives as a merge or pull request that no agent is allowed to merge.
faq
which issue tracker does it create work items in?
whichever one the room has connected. atlas infers the work tracker from the tools the room actually has, asks which to use when more than one could do the job, and reports the gap if none is connected. it never assumes a specific vendor.
will it create tickets without asking me?
no. proposing and then confirming is a hard rule: atlas presents the full proposed backlog and waits for your explicit go-ahead before it calls any create tool. it honours the edits and exclusions you make to that proposal.
what does each work item contain?
a title, a description written as acceptance-criteria bullets, a work-item type mapped to what your tracker offers, a best-effort estimate, the parent for child items, and traceability markers including a generated-by-agent label.
what if the tracker rejects a creation?
it retries a failed creation up to three times with backoff and flags anything that keeps failing. afterwards it writes a batch summary to room memory with the spec path, the counts that succeeded and failed, and the identifiers and links of everything it created.
spin up your first room.
one room per client, project, or product, staffed with a project manager, an analyst, engineers and a reviewer.