Developer

Developer writes the implementation and keeps a plan of its progress. You approve the plan before coding begins and choose how closely to work together.

When to use Developer

Run Developer in DEVELOPING, after the earlier roles finish or when an implementation needs correction. You can also invoke it to start an eligible, bounded expedited change in an existing project; the cycle-entry rules still apply.

Codex:       $developer Continue from .standards/STATE.md in STEPWISE mode.
Claude Code: /developer Continue from .standards/STATE.md in STEPWISE mode.

Inputs and output

In standard work, Developer uses the completed scope, design, and valid Auditor context. In expedited work, the saved request defines the change. If safe completion needs a skipped role, the cycle moves to the standard workflow.

Alongside code changes, Developer saves a development plan at .standards/docs/development/<Active Work.Id>.md. The path is recorded in Active Work.Development.

Each step has an ID such as DEV-001, an expected outcome, dependencies, progress, and a way to check the implementation. Standard steps refer to the scope’s acceptance IDs; expedited steps refer to the saved request. The plan also saves verification cadence and any increment definitions and selection.

Approval before implementation

Developer presents a saved proposal and waits for your explicit approval. It asks again if the plan changes the intended behavior, technical approach, or other important implementation work.

Fixing a defect within an unchanged approved plan does not need another approval. Developer reopens the affected steps and preserves completed work that is still valid. Minor wording or bookkeeping changes also need no new approval.

Modes

You can switch modes during implementation. Your choice is saved with the plan. See Working with Developer for resuming work and updating a plan after expedited promotion.

AUTONOMOUS

The default. Developer works through approved steps without routine pauses.

STEPWISE

Developer completes and checks one step, reports the result, then waits for you to continue unless the assigned outcome is ready for a handoff. Multi-step increments retain these per-step pauses.

CODE_WITH_ME

Developer explains the next step and inspects code you write. It writes or takes over specific approved work when you ask.

Verification cadence

All three modes support AFTER_IMPLEMENTATION (the default) and INCREMENTAL verification in standard work. Cadence controls when Tester receives work; collaboration mode controls Developer’s coding permissions and pauses. See Working with Developer for the two-chat exchange and switching cadence during a cycle.

Coding style and responsibilities

Developer follows project constraints and applicable coding guidance. Before the first plan approval, you can explicitly select a user style you keep at .standards/user-styles/developer/<name>.md, such as tony. The plan saves the selection, and Developer reloads it when it resumes. First approval locks the selection, including no user style, for the rest of the cycle. A different selection requires a new cycle. If a locked style’s file goes missing, it must be restored before implementation continues.

Developer makes local coding choices within the agreed design. Requirements, consequential design decisions, and project context stay with their owners. It may run existing tests for feedback; Tester writes formal tests and verifies the change independently.

Completion and handoff

Developer reaches full completion when all approved steps are done, the implementation meets the agreed requirements, its checks are satisfactory, and no unresolved Developer correction or blocking question remains.

Before full completion, incremental work can hand a ready outcome to Tester and resume after its assessment. Corrections follow the saved recovery assignment.

Full standard work goes to Tester; expedited work goes to implementation Reviewer. Both require the separate assessment chat described by the handoff. Developer and Tester must both pass their full gates before standard implementation review, including on a recovery return.

For a new project, Developer records the permanent change to brownfield as soon as it verifies the first implementation was created or materially changed. This includes code you wrote together; approving the plan alone is not enough.