Feature Lists as Harness Primitives
If "done" is just a feeling, the agent will feel done way too soon. Write the features down as things a loop can actually check, and everything after that gets easier.
A builder does not say the house is done because it feels done. There is a checklist, and an inspector signs each line: wiring, plumbing, insulation. A feature list is that checklist, and the verify gate is the inspector. Done is a signature, not a feeling.
Make "done" into data
A feature list is the task expressed as discrete, checkable items: each one a concrete capability with a way to confirm it works. It is not a vague description of intent, it is the acceptance criteria, made explicit enough that a program can ask "is this one satisfied yet?"
{
"agent_tool": "claude",
"max_retries": 3,
"features": [
{ "id": "login", "name": "Email + password login", "state": "done" },
{ "id": "refresh", "name": "Refresh-token rotation", "state": "coding" },
{ "id": "logout", "name": "Logout + revoke", "state": "pending" }
]
}flowchart LR P["pending"] --> C["coding"] C --> V["verifying"] V --> RT["ready_to_test"] RT --> D["done"] V -->|red past max_retries| B["blocked"] linkStyle 3 stroke:#2ea043,stroke-width:2.5px,color:#2ea043 linkStyle 4 stroke:#e0493f,stroke-width:2.5px,color:#e0493f
Why it is a primitive, not a doc
Because the list is checkable, it becomes load-bearing for the rest of the harness. The engine reads it to choose the next feature. The gate writes state back to it. Progress is the count of done features, not the agent's opinion. It is the single artifact that connects objective, run, and verify which is exactly why it counts as a primitive rather than just documentation.
The engine runs on the list
In Agentum, feature_list.json is the backlog, and each feature carries a state the engine advances: pending → coding → verifying → ready_to_test → done (or blocked once it exhausts max_retries). The engine derives the agent's prompt from AGENTS.md plus the feature's name and description, spawns it, and runs verify.sh keyed by $HARNESS_FEATURE_ID, marking done only on green. Top-level fields (agent_tool, max_retries, agent_yolo, settle_timeout_secs) tune the run. Completion is measured, not asserted.
Key takeaways
- A feature list expresses "done" as discrete, checkable items.
- Because it is checkable, it becomes load-bearing, the loop and verification both use it.
- Progress is the count of verified items, not the agent's self-assessment.
- Agentum runs the loop against the list and stops only when every item is green.
Exercises
- Write a feature list. Turn your next task into three to five features, each with a name and a checkable definition of done.
- Make done checkable. For one feature, write the exact command that proves it works.