Continuity: State, Time, and Visible Progress
The first move solves initiation, but i-have-adhd is also designed for what happens after that move. This chapter focuses on continuity: how an assistant can keep the current state, time signal, outcome, and next transition visible across a multi-turn technical task. Readers will learn to distinguish completed, partial, and failed work—and to report a cause only when the available evidence supports it.
A conversation is a changing task state
A technical task rarely moves directly from request to completion. A migration may begin with a schema change, continue through a backfill, encounter a failing test, and then require a decision about rollback or repair. If each reply treats the latest message as a fresh question, the reader has to reconstruct the state of the task from conversation history.
The skill’s fifth rule addresses that problem directly: restate state every turn. Its example describes a migration in which the schema is updated but the new column still needs to be backfilled. A useful update says which step is complete and what comes next. It does not assume that “we are on step three” remains available in the reader’s working memory simply because it appeared in an earlier message.
State restatement is not a repetitive status ritual. It is a compact record of the transition that matters now. A good status statement answers three questions:
- What has changed?
- What remains unfinished or uncertain?
- What is the next bounded action?
For example: “The schema change is complete; the new column has not been backfilled; next, run the backfill in the staging database.” The statement records an observed result, an unresolved state, and a transition. It does not recap every decision that led there.
This structure is valuable even when the assistant performed the work. A report such as “Updated the migration” hides whether the change was applied, tested, or merely drafted. A more useful report names the observable outcome: “The migration now adds the column, and the focused test passes. The backfill is still pending.” The reader can see the win without mistaking it for full completion.
The distinction between state and intention matters. “The fix should work” is an expectation. “The focused test passed” is evidence from a check. i-have-adhd asks the assistant to make wins visible, but visibility should not turn a prediction into a result. The project’s matter-of-fact error rule is strongest when it preserves that difference: say where the failure occurred, what the evidence shows, and what can be tried next.
Time estimates are coordination signals
The skill also requires specific time estimates. Its rationale is that vague phrases such as “a bit of work” and “a few hours” can feel effectively equivalent when they do not give the reader a usable boundary. A concrete estimate helps the reader decide whether to begin, defer, or divide the task.
The estimate is not a promise of precision.