Bring your own coding agent to the Code stage.

Here is how the work moves.

Your coding agent holds one step, the scripts. Everything before it makes the contract, and everything after it checks the work against that contract.

1. Write the specthe statement of the job, in the Common Agent shape, with its open questionsspec writer, with the owner
2. Approve the spec a personthe owner answers the open questions and says yesthe owner
3. Write the suitetests from the statement alone, shown to fail against nothingtest writer
4. Hand off the codethe build folder written to a branch, with a pull request titled "Write the scripts"the lifecycle
5. Write the scriptsthe scripts the statement names, until node .adlc/check.mjs exits 0your coding agent, or a person
6. Run the gatethe fence, a static review, and the suite with each script blanked, posted as the pull request's checksthe lifecycle
7. Approve the scripts a personthe owner says OK on the commit the gate passed, and the pull request is mergedthe owner
8. Make the package on-rampthe package made from the merged commit, then the docs and the deploy requestpackage maker

The folder arrives in your own repository when you have connected one, or otherwise in a repository kept for the agent. Hosted coding agents already start from a repository and end in a pull request, so the repository is the whole interface. Nothing needs to be installed in your coding agent.

Here is what is in the folder.

Only scripts/ is yours to change. Everything else is pinned by its digest.

Here is the contract your coding agent reads.

Every build folder carries an AGENTS.md like this one, filled in for its agent. Coding agents read AGENTS.md on their own, so you can point yours at the pull request and say "write the scripts".

# Writing the scripts for word-tally 0.1.0

This folder is a build folder from an Agent Development Lifecycle. The steps
before the code are done: the agent is declared (agent-descriptor.json,
agent-runtime-requirements.json, plugin.json and each skills/<slug>/SKILL.md)
and its test suite is written (test/). Your job, whoever you are (a coding
agent or a person), is to write the scripts under scripts/ so that the suite
passes. The steps after the code (review, security review, packing and
deploy) take your work back through the same checks you can run here.

## The scripts to write

- scripts/count.mjs (a stub)
- scripts/went-without.mjs (a stub)

Each one is already there: the released script where there is one, otherwise
a stub that exports what the suite imports and throws until it is written.
Keep the file names and the exported names.

## The rules

1. Write only under scripts/. Everything else here is pinned by digest in
   build.lock.json.
2. Never change a test, the agent's files, or any other pinned file. You may
   add a new test file under test/; it is run with the rest. Changing or
   removing an existing test, or the agent's files, sends the work back to the
   spec and test steps, so say what you think is wrong instead of changing it.
3. If a test cannot pass without breaking what the agent's files say, stop
   and say which test and which line. Which of the two is wrong is a
   person's call.
4. Node 22 or later, ES modules (.mjs), nothing outside node: no npm
   packages, no other language.
5. A model is reached only through the shared caller (scripts/model-caller.mjs,
   where the agent has one) and its four settings, read from the environment
   on every run: MODEL_NAME, MODEL_ENDPOINT, MODEL_KEY (may be empty) and
   MODEL_PROTOCOL (anthropic-messages, openai-chat or gemini). Never sign in
   any other way: no metadata server, no credential file, no variable the
   agent's files do not declare.
6. Write no address into a script. A system's address is one of its declared
   settings, read from the environment; an address a caller hands in is used
   as given.
7. No credential values anywhere, and nothing that looks like one.
8. Never reach a network or a real system from a test run: the suite hands
   in every function that would.

## The check

Run `node .adlc/check.mjs` from this folder as often as you like. It says,
in order:
- whether anything pinned changed (and names it);
- each failing test by name;
- on a pass, whether the suite notices each script going missing, and
  whether the package builds where the builder is installed.

Exit 0 is done. When it is, hand the work back: open the pull request, or
send the folder back, as you were asked.

The template every folder is written from is open, at CommonAgent/adlc. The role it describes is the code writer, and Agent Roles says how any coding agent holds it through this hand-off.

Run the check yourself, as often as you like.

$ node .adlc/check.mjs

It runs the same check the gate runs, with nothing to install beyond Node 22. It first says whether anything pinned changed, and names it. Then it names each failing test. On a pass, it blanks each script in turn to see that the suite notices, and builds the package where the builder is installed. Exit 0 means the work is ready to hand back.

Here is what the gate checks.

When the pull request is marked ready, the gate runs on its newest commit. Each part is posted as a check on the pull request, with its findings in a comment, so your coding agent can read them, fix the scripts and push again.

1. The fence. The pinned files must match the digests recorded when the hand-off was issued. The gate keeps its own record and never trusts the copy of build.lock.json in your repository. Only scripts/ may change, plus any new test file.
2. A static review. The files you may change are read for credential values, hidden characters, and addresses the statement does not declare. A folder that fails the fence or this review is refused by name and never run.
3. The suite, and each script blanked. The suite runs in your own account's sandbox, never where the platform keeps credentials, because this is the first time code nobody has reviewed is executed. Then it runs once per script with that script blanked, and the suite has to notice each one.

The Review and Security review stages then read the change, as they read any code writer's work.

Here is how the work comes back.

• Push and mark the pull request ready. The gate runs on the newest commit. Every push is a round, and the commits on the branch are the record of every round.
• If a test looks wrong, say so. Name the test and the line in the pull request, and leave the test as it is. Changing or removing a test, or the agent's files, sends the work back to the Requirements and Test stages.
• A green gate merges nothing. The owner says OK, and only on the commit the gate passed. Then the pull request is merged.
• The package is made from the merged commit. The package maker packs deterministically from that commit, never from an archive anyone uploaded. The docs are written, the deploy request is filed, and the build record names your coding agent as the holder of the Code stage.

No coding agent of your own? The reference one takes the same folder.

The reference code writer is open source under Apache-2.0. It is handed the same build folder, follows the same AGENTS.md, and goes through the same gate.