docir — design documents Graph

Documents / Decisions / adr-7d9fbbf976e8

A feature ships with its instructions, verified by use

A business feature is done when an agent holding only the installed package can tell what it is, when to reach for it and how to invoke it — and somebody has followed those instructions to check.

adr-7d9fbbf976e8decisionaccepted#agents#docs#testing
View as Markdown◉ View in graph

Context

The CI gates prove a feature works. Nothing proves anybody can find it, and docir's user is an AI agent that will never read this repository — it has the installed wheel, the skill docir agent install wrote, and --help. Everything else in the repo is invisible to it.

That gap is not hypothetical. docir bench shipped with its only worked fixture at benchmarks/example_fixture.yaml, a path the wheel does not contain — 213 entries, zero benchmark files — while the skill named the fixture's shape without showing it or saying where the document ids come from. Both surfaces read as complete to their author. An agent following them would have written a fixture of invented ids, and bench would have reported every task dropped and measured nothing.

Decision

A business feature is done when an agent holding only the installed package can tell what it is, when to reach for it, and how to invoke it — including how to obtain any input it needs.

Three surfaces carry that, and all three ship with the change:

  • the packaged skill (modules/agents/infra/templates/skill.md) — what and when;
  • the CLI docstringhow, with a worked example, since --help is JSON when piped and is the one surface an agent parses rather than guesses at;
  • README.md — for the human deciding whether to adopt docir.

Edit the template, never .claude/skills/**, then run docir agent update so this repo's own copies match what an adopter installs.

Verification is use, not review

The instructions are then followed, from the state an adopter is in, and the feature run. Re-reading what you wrote and judging it sufficient is exactly what produced the gap above. If a step needs data, the instructions have to say where that data comes from, and following them has to produce it.

This is adr-bea42e359960's rule one level out. That decision validates docir's prose against the command tree, so a documented invocation cannot name a flag that does not exist. It cannot tell whether the prose is enough to act on, because a resolvable command proves shape and not sufficiency.

Consequences

A feature costs more than its implementation, deliberately. The cost is bounded — three surfaces and one run — and it falls on the change that introduced the feature, where the author still knows what they meant.

It is not automated and should not be: a check that the skill mentions every command would pass on a sentence naming it, which is the failure this decision exists to catch. What is mechanised already is the narrower claim adr-bea42e359960 owns.

To amend: Re-verify: