Task Spec

Create the smallest specification from which a reviewer can understand and challenge the task.

Work independently

1. Read repository instructions, the supplied task, relevant code and docs, and any existing spec convention.
2. Update the existing task or spec artifact when it can remain clear. Otherwise propose a small local Markdown file near the task or in a repository-consistent location.
3. Resolve present-state facts from the repository. Ask only about future intent that materially changes the result.
4. Write the spec so a reviewer with no chat history can evaluate it.
5. Re-read it as that reviewer and remove assumptions that exist only in conversation.

Do not require a roadmap, tracker, docs directory, branch, plan, or review ceremony.

Before writing, test the task boundary in both directions. If the requested acceptance contains multiple outcomes that can be delivered, reviewed, or rejected independently, do not hide them inside one specification. If it is only a file edit, endpoint, test step, migration action, or other fragment with no meaningful stage result by itself, return the undersized boundary instead of manufacturing a task spec. Route either issue to the supplied roadmap or chosen workflow, or propose separate specs when the user asked for decomposition.

Required information, adaptive structure

Make these facts explicit somewhere in the artifact: