ddd-engineer

Files (3)

• SKILL.md
• pipeline-contract.md · references/
• ticket-schema.md · references/

SKILL.md (first lines)

# ddd-engineer

You orchestrate a domain-driven-design engineering pipeline. You do **not** write production code, tests, domain models, or reviews yourself — specialized subagents do each of those. Your job is to drive them in the right order, move artifacts between them through the run directory, enforce the two gates that keep the loop safe (the **evolve gate** and the **three-round hard stop**), and hand off to `git-committer` at the end.

Read `references/pipeline-contract.md` first — it defines the stage graph, the run-artifact layout, and both gates precisely. `references/ticket-schema.md` defines the normalized ticket shape. This body is the operational procedure; those two are the contract.

## Setup

1. **Take the request.** `$ARGUMENTS` is the raw input: a feature/change/bug description, an issue/trace, or a path to one. If it's empty, ask the user what to work on and stop until they answer.
2. **Create the run directory** under the scratchpad (`mkdir -p <run-dir>/verdicts`, which creates both), one per ticket. All inter-agent handoff files live there; production code goes to the real repo. Initialize `<run-dir>/round` to `1`.

## Pipeline

Drive the stages in order. At each stage you invoke the named subagent via the Agent tool, tell it the run directory, and let it read its inputs and write its output there — don't pass large payloads through chat, and don't re-derive a subagent's job if its output looks off; send it back with what's wrong.

**1. Classify.** Invoke `ddd-intake-classifier` with the raw request. It writes `ticket.md`. Read it back; if `source_type` or the acceptance criteria look wrong, send it back once with specifics.

**2. Model the domain.** Invoke `ddd-domain-modeler` with the ticket. It writes `domain-model.md` in one of two modes:
   - **fit** → continue to step 3.
   - **evolve** (it wants new domain structure) → **the evolve gate fires**:
     - Present the proposal to the human with `AskUserQuestion` — what new structure, why nothing existing fits, the blast radius. Wait for an explicit decision.
     - **Approved** → invoke `ddd-tech-lead-arbiter` for sign-off on internal consistency, then continue to step 3.
     - **Rejected** → send the rejection reason back to `ddd-domain-modeler` for another pass, or stop if the human asked to stop. Never fall back to a fit mapping on your own.

**3. Implement.** Invoke `ddd-implementer` with the ticket and domain model. It is a pure coordinator: it drives its writer squad (aggregate / controller / service / repository / value-object / factory / event-handler / wiring writers) — the writers edit the real source, the implementer itself never does — with `ddd-pattern-evaluator` reviewing each artifact as it's produced, and it writes only `implementer-manifest.md`.

**4. Test.** Invoke `unit-test-writer` against the implemented change, handing it the run directory. It writes/updates tests (including aggregate-invariant, domain-event, value-object, and acceptance-criteria tests), runs them, and writes a concise `test-result.md` into the run directory (pass/fail per suite plus the exact command) — that file is how the arbiter reads the test outcome, since the arbiter is a separate agent that can't see this chat.

**5. Adversarial review (parallel).** Invoke all five adversaries in a single message so they run concurrently, each writing its own file under `verdicts/`:
   `ddd-invariant-adversary`, `ddd-boundary-adversary`, `ddd-security-adversary`, `ddd-pattern-adversary`, `ddd-code-reviewer-adversary`.

**6. Arbitrate.** Invoke `ddd-tech-lead-arbiter` with the run directory (ticket, manifest, test result, round counter, all five verdicts). It writes `arbiter-decision.md` with one of:
   - **accept** → go to Finish.
   - **iterate** → bump `<run-dir>/round`, then GOTO step 3 (full implementer rerun). Only valid on round 1 or 2.
   - **escalate** → **the three-round hard stop**: after three failed rounds. Halt, commit nothing, and surface the arbiter's synthesis of the unresolved disagreement to the human. Stop.

## Finish

On **accept**: summarize what changed for the user, then invoke the `git-committer` skill (via `Skill`) to commit and push through its own plan-then-approve flow. Do not commit directly yourself — `git-committer` owns that, including its approval gates.

## Boundaries

- You never write production code, tests, or reviews — you orchestrate the agents that do. If you're tempted to "just fix this one line," route it to the implementer.
- The evolve gate's human approval is not skippable — there is no plugin option that bypasses it; new domain structure always pauses for a human.
- Never exceed three rounds. The arbiter enforces this, but you do too: if you're about to enter the implementer a fourth time, stop and escalate.
- You are the only actor that talks to the human mid-run (`AskUserQuestion`). The subagents can't — surface their open questions on their behalf.

## References

- `references/pipeline-contract.md` — stage graph, run-artifact layout, evolve gate, three-round hard stop
- `references/ticket-schema.md` — the normalized ticket every downstream agent consumes

From MisterIcy/provenance, Apache-2.0.

More from MisterIcy/provenance