Checkpoint: A Compact Answer Must Still Be Complete

i-have-adhd is easiest to misunderstand when its rules are read as a list of formatting preferences. The ideas already established—reduce startup friction, expose a bounded path, keep state visible, and preserve evidence—form a single test for whether an assistant answer is usable. This checkpoint connects those ideas and applies them to direct answers, technical errors, partial success, and requests for explanation. The judgment it supports is precise: a compact answer is good only when it preserves the information needed for the reader to act correctly.

The quality test is a chain, not a checklist

The project’s rules begin with a reader-side problem. A correct answer can still fail if the reader cannot find the first move, cannot remember the current state, or cannot tell whether a result has been verified. Each rule addresses one point in that path, but the value comes from their relationship.

Action-first ordering lowers the cost of entry. Bounded steps prevent the path from expanding invisibly. A concrete estimate helps the reader decide what commitment the next move requires. State restatement preserves the position of the work across turns. A visible outcome distinguishes a completed transition from an intention. One concrete next action keeps the task moving rather than returning the reader to a menu of possibilities.

The chain can be expressed as a simple quality test:

flowchart LR A["Friction at the start"] --> B["Visible first action"] B --> C["Bounded work"] C --> D["State and progress signal"] D --> E["Verification or safe exception"] E --> F["One useful next action"] G["Necessary detail or user format"] -.-> C G -.-> E

This is not a formula that guarantees completion. It identifies the transitions a response must support. A direct answer may move from the request to the result in one step. A migration may pass through several states and require more explanation. A destructive command may stop at confirmation before any change occurs. In each case, the response should make the relevant transition visible rather than applying “shorter is better” mechanically.

This model also clarifies the difference between an answer that is cognitively light and one that is operationally ready. “Update the dependency” is short, but it leaves the file, command, compatibility condition, and verification unspecified. “Open the package manifest, update the dependency, run the focused test, and report the first failure” is longer, but each part has a role. The second answer reduces the reader’s need to construct a hidden procedure.

The reverse failure is possible too. A response can expose every conceivable step and still make the task harder by placing peripheral concerns beside the immediate action. The project’s tangent rule addresses this by asking the assistant to finish the current issue before raising a separate one. The visible path should be complete enough to work, not exhaustive enough to compete with itself.

Completeness has a practical definition here.