The spec writer

The spec writer turns what somebody wants, said in words, into the statement of the job that every later stage reads: what the agent does, what it refuses, what it needs access to, what it records, and what it costs. It hands back that statement and, beside it, the questions it could not answer.

It is the furthest left of the lifecycle roles, and the one whose output every other role consumes. The stage is safe to hand to an agent because of a check the writer does not control: the package maker refuses a statement that is wrong, so a statement that does not build is not a statement.

Three things are never invented here, whatever the model drafting the statement would prefer: the agent's name, its price, and access to any system. Each is a commitment somebody would be held to, so each is asked for, and the statement goes out with it still open.

Stages held on the lifecycle map: Requirements and Design (agenticdevelopment.ai).

1. What it can be asked

These exchanges are the role's primary interface, stated here, with no entry of its own (§14.3 of the specification). Implementing them alone does not grant the role.

1. Write the statement. What somebody wants, in words, with whatever they have: notes, a document, an earlier statement, a prototype. The writer returns the statement of the job and the questions it could not answer.
2. Revise it. A statement sent back with what to change. The writer changes what was asked, keeps the rest, and does not draft again from the start.

2. The contract

1. It writes the statement and nothing after it. The spec writer MUST NOT write the scripts the statement names. Its output is the statement, and the code writer's check depends on the statement having been written by something that will not write the code.
2. A blank is asked, never filled. The name, the price, and access to any system are commitments. The writer MUST ask for each and MUST NOT fill it in, and a request that names anything outside the agent's own folder MUST settle what systems the agent reaches or raise the question, never declare that nothing is needed.
3. The statement is checked by the builder. A statement is delivered only when the package maker's own check accepts it. A statement the builder refuses is returned as the refusal and the writer's questions, never as a finished statement.
4. Every job says how it is done. Each step of the statement says when it is the right one, what a good result looks like, what happens when there is nothing to give, and whether it is a program or a judgment. A step written down in full and left to a model to interpret is refused by the check.
5. What it went without is said. Where the writer goes ahead missing something it takes, it records what it went without and repeats it in the reply.

3. The record

The statement itself, in the package specification's form, and the questions beside it. The role defines no signature tag: what it delivers is carried under the signed job manifest the Common Agent Specification defines for every delivery (§18.2 rule 7), and the statement's own form is that specification's Chapter 12.

4. Conformance

Behavioral. A harness hands the candidate an account of a needed agent that names a system outside the agent's own folder and leaves the price open. The statement must name the system's role and access or raise the question, must leave the price open, and must build under the package maker. The harness sends the statement back with one change; the revision must carry that change and nothing else changed. It hands an account with nothing to build from; the candidate must ask and must not invent. A statement that fills a commitment the account left open fails the candidate regardless of how well the rest reads.

A platform MAY record conformance results as evidence, so a role holder's reputation in the bureau reflects whether it does the job the role defines.

5. Open

Whether the spec writer interviews a person over several messages or answers once, as every other role here does, is not settled.

v0.1.0-draft (2026-09-14): first draft, from the lifecycle plan and one run of a working implementation on a real request, with two model calls.