Agent Operating Model
Agent Operating Model
This page is the day-to-day operating model for Codex, Claude, claudeu, codexu, and future backends working on Gormes.
Every substantial pass starts with a repo-local skill and ends with evidence.
Skill Selection
Use gormes-skill-manager when the correct skill is not obvious. Otherwise
select the narrowest skill that matches the pass:
| Pass | Skill |
|---|---|
| Decide direction with the operator | grill-me |
| Audit upstream parity | gormes-parity-auditor |
| Refine phases, rows, docs, or dependency order | gormes-planner |
| Compare package/API shapes | gormes-interface-designer |
Implement a progress.json row | gormes-builder |
| Drive one behavior through red-green-refactor | gormes-tdd-slice |
| Create or improve skills | gormes-skill-manager plus skill-creation workflow |
Do not load every skill. A good pass normally uses one skill; a complex pass uses at most three.
Planner Pass
A planner pass must:
- name the lane and subsystem;
- inspect upstream and current Gormes code;
- classify gaps as covered, planned, vague, missing, or owned;
- update docs or
progress.jsononly where needed; - preserve
healthblocks; - validate docs/progress;
- stop with a short next-builder-row list.
Planner passes do not implement runtime feature code.
gormes-planner replaces the deleted cmd/planner-loop command. During a
planner-skill pass, do not recreate or invoke loop binaries. Manual repository
evidence wins over stale loop assumptions.
Minimum validation:
go run ./cmd/progress validate
go test ./docs -count=1If progress rows or generated progress docs changed:
go run ./cmd/progress write
go run ./cmd/progress validate
go test ./internal/progress -count=1Planner output packet:
| Field | Required content |
|---|---|
| Lane/subsystem | One lane and one subsystem only. |
| Evidence | Upstream paths, Gormes paths, tests, and current progress rows. |
| Classification | Covered, planned, vague, missing, or owned for each behavior. |
| Row change | Exact row additions/splits/refinements, or explicit “docs-only”. |
| Builder handoff | Next one to three rows, write scope, and test commands. |
| Validation | Commands run and failures, if any. |
Planner passes may update generated docs only through go run ./cmd/progress write. They must not edit content between PROGRESS markers by hand.
When a planner pass adds a phase, subphase, or closure row, it must also update
the hand-written planning pages that explain why the structure exists:
completion-plan.md, lane-roadmap.md, and any subsystem study page that owns
the new rows. A phase restructure is not complete until Hugo-generated pages
and the human-readable plan tell the same story.
Builder Pass
A builder pass must:
- select exactly one row unless the user explicitly asks for a batch;
- restate the contract, write scope, tests, and done signal;
- write one failing behavior test where feasible;
- implement the smallest green path;
- repeat vertically only while scope remains the same row;
- run row-local commands and focused package gates;
- update docs/progress evidence when public behavior changed.
Builder passes do not invent backlog. If a row is vague, send it back through
gormes-planner.
Builder selection without loop binaries:
- Read
progress.jsonand the generated Agent Queue. - Prefer rows with
fixture_readyor validated contracts, noblocked_by, non-umbrellaslice_size, explicitwrite_scope, andtest_commands. - Prefer Lane 1/2 closure rows unless the user names a row or a dependency requires another lane.
- Restate the row. If the restatement cannot name behavior, tests, and done
signal, stop and run
gormes-planner. - Build one row only.
Parity Audit Pass
A parity audit pass must compare exact upstream behavior against exact Gormes evidence. It should not be a list of file names.
For each behavior, record:
- upstream path and symbol;
- Gormes package or missing package;
- tests/fixtures;
- progress row coverage;
- classification;
- recommended row if vague or missing.
Interface Design Pass
Use this before implementation when a package boundary is unclear.
Output at least two materially different designs and compare:
- caller simplicity;
- Hermes/Honcho compatibility;
- module depth;
- testability;
- migration cost;
- risk of shallow pass-through abstraction.
The result should either update a row or unblock one builder pass.
Stop Conditions
Stop and report instead of continuing when:
- validation fails for a reason outside the current pass;
- progress row scope is missing or contradictory;
- upstream behavior cannot be verified locally;
- the pass would require runtime code during a planner pass;
- the builder would need to edit outside
write_scope; - live credentials are required for row-local proof.
Evidence Format
Every final report should include:
- skill used;
- scope scanned;
- files changed;
- validation run;
- next row or next pass;
- blockers.
The user should be able to resume from the report without reading the entire conversation.