Skip to main content
AEP | Agent PluginsAEP in the source-owned Agent Plugins documentation.Agent Pluginsreferenceagentpluginsreferenceadopterdeveloperbuild-agent-systemstry-spec-driven-developmentgovern-work

aep

Use this plugin to plan governed work in AEP's artifact store and to deliver accepted work through the Agentic Development Protocol profile. Both halves drive the aep CLI.

Planning​

Use it to work with AEP's governed planning substrate.

It provides:

  • a planning skill that discovers the repository-local store and uses the canonical aep command;
  • a story migration skill that adopts an existing backlog without rewriting or deleting its sources;
  • a decomposer for turning a concrete outcome into related planning artifacts;
  • a plan reviewer for checking readiness, evidence, and dependency shape;
  • a reverse engineer for mapping an existing codebase into reviewable work;
  • an acceptance critic for checking that each drafted item states an outcome somebody can observe;
  • a design critic for checking the shape of a decomposition: coupling, cycles, split abstractions;
  • a scope critic for checking that the set covers what it was drafted from, and nothing beyond it;
  • a parallel-safety critic for naming the items that would land on the same file.

The four critics are a panel, not four separate reviews. After a decomposition is reported, the planning skill dispatches them at once, records each verdict as an immutable review result related to the artifacts it judged, revises the drafts on every verdict that asks for it, and stops after two rounds with whatever is still open named in its report. None of them writes to the store.

Planning also refuses to decompose an epic or story that introduces an entity no ESS domain declares. The domain is drafted and cited from the artifact first, and any relation that could not be read from code, an OpenAPI document or an existing artifact is marked unmapped, never guessed.

Two commands start planning work by name. You start one, or an agent starts it when you ask, and each hands off to aep:planning:

commandwhat it does
/aep:review-plan [artifact-id…]runs the plan reviewer over the store (or the named artifacts), proposes moves and makes none
/aep:decompose <epic-id>runs the decomposer over one epic, then the four-critic panel, and reports what is still open

The plugin respects store ownership: machine-owned artifact metadata is changed through AEP, not by editing markdown frontmatter. A refusal from the lifecycle is a result to report, not a guard to route around.

The store is aep.project/5: each artifact file under .engineering/planning/ is the authority, a move appends one line to its transitions, and each evidence record is one file under .engineering/evidence/. When a repository's store is on an older version, the planning and delivery skills say so before their first write and name the upgrade; aep:upgrade runs it.

Delivery​

It provides:

  • the implementing skill, in wave mode: coordination guidance for running a planned wave of accepted stories at once;
  • a story scoper that turns an accepted story into bounded implementation units;
  • an implementor role for an assigned unit;
  • an adversary role that checks the result against scope, evidence, and repository invariants;
  • the implementing skill, in drive mode: one governed metaharness aep drive run over a single story.

Two commands start either mode by name. You start one, or an agent starts it when you ask, and each hands off to aep:implementing:

commandwhat it does
/aep:wave [story-id…]takes the next wave of your wave plan (or the ids you name), checks and scopes its stories, writes the wave page, proposes it and stops for your approval
/aep:drive <story-id>says what a driven run costs, starts one governed run, prints its run id and stops

Waves are planned up front, and findings wait​

A wave runs only accepted stories, and accepting a story is yours, never the agent's. Before the first wave, the waves are derived once from the accepted stories with aep plan artifact waves --kind story --status active and written to a plan page in order. The coordinating agent runs the next undelivered wave of that page; it adds no story to it and accepts none.

A review finding the unit introduced, or that its acceptance needs, goes back to the implementor. A finding that was already there before the unit is recorded in the review and filed as one draft story in the backlog. No backlog story enters a wave until you have accepted it and every planned wave is delivered: a defect that predates the wave has no claim to go before the planned work.

Diagnosis​

The diagnosing skill handles a failing, flaky or slow behaviour. It builds one command that goes red on the reported symptom and has already been run, before any hypothesis. Then it ranks falsifiable hypotheses, probes one variable at a time, and writes the regression test at a seam that reproduces the real call pattern. The red and green runs are recorded as test_result evidence against the owning story. When no such seam exists, the missing seam is filed as a draft story.

The investigating skill handles what cannot be re-run: a production incident, an outage, or a question about a running system such as "when did this start" or "is the fix deployed". It captures the process state before anyone restarts it, builds a UTC timeline where every row names its source, dates an onset from an instrument that can see a negative, and checks each anomaly against a healthy peer. Every claim is labelled verified or inferred. The investigation is an incident-report artifact, its observations are health_observation evidence, and each follow-up is a draft story. Ten techniques cover the work, from capture before remediation to the postmortem.

Every role above, in both halves, is written once, as references/<role>.md of the skill that owns it. Claude Code runs it as a subagent through a thin agents/<role>.md adapter; Codex, which loads skills but not agents/, runs the same file directly.

This plugin builds on AEP's planning substrate. It does not replace the repository gate, invent lifecycle moves, or give implementors authority beyond their assigned unit.

Two ways to deliver a story, and they enforce differently​

The wave coordinates an interactive session: its rules are instructions the coordinating agent follows. drive hands one story to the reference driver, where the step map's bounds are decided by the engine rather than obeyed by an agent.

The recorded dogfood attempts stopped before the review step. Those historical observations do not qualify later releases: drive mode checks the current evidence before claiming readiness, prints the run id and how to follow it, and moves no artifact itself.

Drive mode uses metaharness aep drive with a planning executable matching the AEP source linked by that runner. Install explains the pairing. Governed Codex steps preserve model and endpoint selection across resume. Capped runs use the operator's budget; uncapped mode requires an explicit spending authorization reference. Native process completion and the task's terminal verdict are reported separately. A step map's commands: names the programs each model step's shell may run, and the refusal of any other names that list. Before a launch, metaharness doctor says whether the installed harness is one the adapter pins.

b10x treats both metaharness and b10x-harness, the Beyond10x agent loop that Metaharness's b10x adapter runs, as optional CLIs of this plugin: it reports them, and b10x install <cli> adds one. b10x-harness runs on Linux only.