Implement new behavior in an existing codebase. Every other team either advises,
audits, fixes, or cleans; this is the one that writes new code. It exists so a
request like "add feature X" has a destination instead of detouring through
analyze-team and prompting-team.
-
Re-anchor: restate the goal in one line. Check _agent_ops/SESSION_BRIEF.md
for constraints and non-goals, and _agent_ops/CURRENT_TASK.md for work
already in flight. Check git state; warn if the tree is dirty or behind the
base branch.
-
Business rules gate. Read Business Rules & Acceptance Criteria in
_agent_ops/PROJECT_CONTEXT_CARD.md. If it is empty or does not cover this
feature, STOP and ask for the acceptance criteria. Do not invent them. Code
that compiles but encodes a guessed rule is the most expensive failure this
team can produce, because it passes review and fails in production.
-
Placement. Decide where the code goes using _agent_ops/REPO_MAP.md:
which module owns this concern, its routes and entry points, and whether the
change lands in a hot file or a most-called symbol. Do not invent a new
module when an existing one owns the concern.
python _agent_ops/tools/explore.py --root . --entrypoints lists the routes already
wired up, which is the fastest way to see where a new endpoint belongs.
-
Reuse scan. Before writing a function, look for an existing one:
python _agent_ops/tools/explore.py --root . --symbol <concept>
python _agent_ops/tools/explore.py --root . --file <the module that owns this>
--symbol finds definitions that already carry the name or concept;
--file lists everything the owning module already exposes. State explicitly
what you are reusing and what is genuinely new. Duplicating logic that
already exists is the seed of the next "fixing one bug created another".
-
Contract first. Write down the interface before the implementation:
function/endpoint signature, inputs, outputs, error cases, and the observable
acceptance criterion for each business rule.
-
Impact statement. Name the files to be created and modified, the blast
radius, and any cross-boundary effect. When the change modifies an existing
symbol rather than only adding one, get the radius from the graph:
python _agent_ops/tools/explore.py --root . --impact <symbol>. If the change must
cross a module boundary, say so before editing, not after.
-
Plan and confirm. Present steps 3-6 as a short plan with a token/risk
level. Get confirmation before writing code. Offer to split into slices when
the change spans more than one module.
-
Implement ONE slice. One responsibility per change. One serialized writer
lane -- never two agents writing the same files.
-
Verify before claiming. Before referencing any function, API, import, or
config key, confirm it exists in the codebase or a real dependency. Never
invent a symbol. Run the narrowest meaningful test; use tester-team/ or the
tester subagent for a wider check. Do not report a test as passing unless
it ran.
-
Update _agent_ops/CURRENT_TASK.md as you go: files touched, approaches
ruled out, next step. If you added or moved files, rebuild the index and map
so the next session is not reasoning on a stale graph:
python _agent_ops/tools/build_code_index.py --root . and
python _agent_ops/tools/generate_repo_map.py --root . --output _agent_ops/REPO_MAP.md --force.
-
Report the slice: files changed, tests run with real output, what is still
unimplemented. Ask before starting the next slice.
-
Before the Closure Receipt, classify actual work under
_agent_ops/SESSION_PROTOCOL.md; the prompt's file list never waives a
triggered implementation-log, project-context, or decision record. Commit
only if the user allowed it. For a source-changing commit, stage source
explicitly after tests, run refresh_repo_map.py with --stage, review the
generated map, then commit without --no-verify.
