Scrum for AI assistants.
AMS is a lightweight framework for managing AI agents the way we manage human teams — with defined roles, structured handoffs, and just enough process to stay on track without getting in the way.
You do not need every piece. HANDOFF is required. Everything else is optional.
AI agents are powerful but stateless. They forget everything between sessions, can't coordinate across a team, and have no concept of a project's history or direction.
We've solved this before. Agile — and Scrum in particular — exists precisely to coordinate people who are working on complex problems together. The Scrum Guide doesn't say much about coding. It says a lot about communication, roles, and rhythm. Those ideas transfer directly to agents.
Clone this repo into your project under a temporary name:
git clone --recurse-submodules https://github.com/cellear/AMS.git AMS-INSTALL
Then tell an agent to read AMS-INSTALL/INSTALL-AMS.md. It copies the kit into your project as AMS/, hides the installer from your project's git, and hands off to the setup wizard, which asks which components you want and writes AMS/CONFIG.md.
AMS-INSTALL/ is scaffolding — once AMS is installed it can be deleted, and the installer will offer to do it.
After that, an agent reads AMS/AGENT.md at the start of each session. It follows only the components CONFIG enables. At session end it writes a handoff so the next session — by any agent, using any tool — picks up where this one left off.
| Component | Required | What it is |
|---|---|---|
| HANDOFF | yes | Session journals, chronological |
| DOC | no | Reference docs, persistent by topic |
| LEARNINGS | no | Sprint retros and/or topical findings |
| SPRINTS | no | Sprint plans, stories, demo checkpoints |
| EPICS | no | Cross-sprint work; optional extra under SPRINTS |
| OFFICES | no | Per-persona working memory (desk.md, identity) |
| MARKETING | no | Experimental stub |
| SECURITY | no | Experimental stub |
Defaults live inside AMS/. CONFIG.md can point any component at another folder (existing docs/, journal/, and so on).
Each optional component has a PROTOCOL.md in its directory. Agents follow that file only when CONFIG lists the component.
Personas are specific AI threads that play defined roles on the project team. Not every project needs every persona. If you enable OFFICES, the installer asks which roles to staff.
See Personas.md for the full roster.
If SPRINTS is enabled, project planning (epics, stories, model assignment) is a separate step: AMS/agent-scrum/wizard.md. Install does not run it.
The Scrum Guide doesn't talk much about code. Neither does AMS. The same framework applies to design, content, marketing, research — any knowledge work that benefits from coordinated roles and structured communication.
The persona roster reflects this: alongside coders and architects, there are designers, marketers, content strategists, and a professor who captures what the team learns along the way.
AMS is built on a bias toward simplicity. The best system is the one you'll actually use. Every decision — plain markdown over databases, a plain directory over a separate service, conventions over configuration — reflects that bias.
If you want a more fully-featured pipeline with automated lifecycle management, spec-driven workflows, and kanban visibility, look at Spec Kitty or Zora. AMS is for teams who want to drop something into a project today and go.
Everything an installed project receives lives in kit/. Everything outside kit/ is repo-role and never ships.
| Path | Contents |
|---|---|
| INSTALL-AMS.md | Bootstrap — places the kit into a project. Runs once. |
| kit/ | The payload. This directory becomes AMS/ in your project. |
| kit/AGENT.md | Core session protocol (HANDOFF) |
| kit/INSTALL.md | Agent-driven component wizard; stays in the project for re-runs |
| kit/CONFIG.md | Enabled components and directory names |
| kit/Personas.md | Persona roster |
| kit/agent-scrum/ | Sprint-planning reference and wizard (submodule) |
kit/DOC/, kit/LEARNINGS/, kit/SPRINTS/, kit/OFFICES/, … |
Optional component protocols |
| Tooling.md | AMS tools and related projects |
| INTERFACE/ | Daily Scrum, Office, and Floor Plan HTML (not part of install) |
| Project | What it does |
|---|---|
| agent-handoff | The Handoff Protocol — standalone, tool-agnostic |
| agent-handoff-plugin | Claude Code plugin for /handoff setup and session capture |
| agent-scrum | Sprint / epic / learnings convention (submodule here) |
git clone --recurse-submodules https://github.com/cellear/AMS.git AMS-INSTALLin your project root- Tell your agent to read
AMS-INSTALL/INSTALL-AMS.md(or “install AMS”) - Answer the questions; it writes
AMS/CONFIG.mdand creates the directories - Delete
AMS-INSTALL/when it offers — AMS lives inAMS/now - Later sessions: tell the agent to read
AMS/AGENT.md
Works with any AI assistant. No external services. No account required.
Note for chat-based tools: AMS relies on agents reading files from your project directory automatically. Code-native tools (Claude Code, Codex CLI, Cursor, Gemini CLI) do this — they pick up
AGENT.mdon startup and follow the protocol without help. Chat-based tools (ChatGPT, Claude.ai, Gemini web) don't have filesystem access and won't discoverAGENT.mdon their own. If you're using a chat tool for part of the work, you'll need to paste or upload the relevant context manually — and write the handoff yourself when the session ends. These tools are still valuable team members (great for visuals, brainstorming, research), but the human is responsible for keeping them in the loop.
MIT — use it however you want.