AOD organizes work into six stages — Discover, Define, Plan, Build, Deliver, Document. Each stage produces a named artifact that the next stage consumes, and each stage boundary is a governance gate where one or more Triad roles sign off. The agent runs the same slash commands every session against the same locked artifacts, so the output is reproducible across runs and across humans. This is the lifecycle, not a process diagram.
/aod.discoverCapture a feature idea, score it with ICE, and gather evidence before it earns a slot in the backlog. The gate at the exit is PM validation: the idea has a clear user problem, a target user, and a measurable outcome. Run with /aod.discover. The artifact that leaves the stage is a scored idea, not a half-written PRD.
/aod.defineWrite the PRD with full Triad review — PM, Architect, and Team-Lead each sign off. The gate at the exit is triple-signed product requirements: what gets built, why, the technical baseline, and the realistic timeline. Run with /aod.define. The artifact that leaves the stage is a PRD the spec phase consumes verbatim.
/aod.planTranslate the PRD into three artifacts in sequence — spec, project plan, and tasks — with sign-off gates between each. The gate at the exit is triple-signed tasks: PM, Architect, and Team-Lead approve before any code is written. Run with /aod.plan. The artifact that leaves the stage is an implementation contract the build phase executes against.
/aod.buildExecute the tasks in parallel waves with Architect checkpoints at every critical phase — design quality, security scan, code simplification. The gate is continuous: the Architect approves at each checkpoint or sends the work back. Run with /aod.build. The artifact that leaves the stage is implemented, tested, and gate-checked code ready for the Deliver stage.
/aod.deliverVerify the Definition of Done — pushed to production, tested, user-validated — run the retrospective, and close the feature. The gate at the exit is the full Triad DoD check. Run with /aod.deliver. The artifact that leaves the stage is a closed feature with a retrospective on the books and a draft PR marked ready for review.
/aod.documentRun a human-approved quality review — code simplification, docstrings, CHANGELOG updates, API docs. Each step asks for explicit human approval before applying. Run with /aod.document. The artifact that leaves the stage is a maintainable codebase with the institutional knowledge captured for the next human or agent to pick up.
A real /aod.define invocation. The user asks for a dark-mode feature, three Triad agents respond with sign-offs, and a PRD lands on disk. No animation, no typing effect, just the static output you would see in your own shell.
$ /aod.define dark-mode product-manager: Drafting PRD with 5 user stories,acceptance criteria, and ICE-scored success metrics.Saved draft to specs/NNN-dark-mode/spec.md.architect: APPROVED. Static export compatible.Zero new dependencies. CSS tokens within budget.team-lead: APPROVED. 3 waves, ~5h aggregate.Wave 0a parallel, Wave 1 sequential, Wave 2 review. ✓ PRD locked at docs/product/02_PRD/NNN-dark-mode-2026-MM-DD.md| Role | Defines | Authority |
|---|---|---|
| Product Manager | What & Why | Scope & requirements |
| Architect | How | Technical decisions |
| Team-Lead | When & Who | Timeline & resources |
spec.mdplan.mdtasks.mdRead the chapter: Context Windows Are the New Memory Management.
A tool's purpose, inputs, and effects are obvious from its name and signature alone. The agent should never have to guess what the tool does or what argument shape it accepts.
A search tool named find_files_by_extension(ext: string) -> Path[] is Visible; a search tool named search(query: any) -> any is not — the agent has to infer the contract from trial and error.
A tool surfaces what changed in the world, not what was attempted. Return a result the agent can act on — never a vague success flag and a stack trace to parse.
A file-write tool returns { path, bytes_written, sha256 } so the next step can verify and reference the artifact; returning only { ok: true } forces the agent to re-discover the world from scratch.
A tool does one thing and has no hidden coupling to other tools or to global state. The blast radius of any single call is bounded and inspectable.
A commit_changes tool that stages, commits, and pushes in one call is not Isolated — three separate tools (stage, commit, push) let the agent stop after any step and let a reviewer see the intermediate state.
A tool's output is shaped to be another tool's input. Pipelines emerge from the tool set without an orchestration layer dictating them.
A list_files tool that returns Path[] composes directly with a read_file(path: Path) tool — the agent chains them with no glue code. If the first returned strings and the second expected typed Path, the agent would have to write a coercion step every time.
A tool fails loudly with structured information the agent can recover from. No silent failures, no buried exceptions, no truncated stack traces with the actual cause stripped.
A delete_file tool returns { ok: false, reason: "file_locked", locked_by: "process_id_47291" } so the agent can retry, escalate, or pick a different file — not just { ok: false } with a wall of text in stderr.
| OOP concept | AOD counterpart | Explanation |
|---|---|---|
| Encapsulation | Context Isolation | Encapsulation hides an object's internal state behind a public interface. Context Isolation does the same for an agent — the context window is the private state, and only the explicit handoff (spec, plan, tasks) is the public interface the next agent consumes. |
| Abstraction | Tool Interfaces | Abstraction hides implementation detail behind a method signature. Tool Interfaces do the same for an agent — the tool's name and signature are the contract the agent reasons against, and the implementation is free to change without changing what the agent has to know. |
| Inheritance | Config Hierarchy | Inheritance lets a class extend another class while overriding specific methods. Config Hierarchy does the same for an agent — a base context defines the defaults, and specialized contexts (CLAUDE.md, skills, hooks, tool configs) extend or override them with complete-override semantics. |
| Polymorphism | Agent Specialization | Polymorphism lets a single interface dispatch to many implementations. Agent Specialization does the same for an agent — natural language is the shared interface, and the runtime picks a specialized agent (PM, Architect, Team-Lead, frontend-developer, tester) based on the work in front of it. |