# Turn an agreed change into a buildable specification — acceptance checklist

Record evidence for every checked item. Unchecked or untested is not a pass. This checklist does not execute an integration or authorise external actions.

## Required inputs

- [ ] The agreed discussion, requirements and exclusions.

- [ ] A fixed repository revision, glossary and existing architecture decisions.

## Output checks

- [ ] Every requirement has an observable acceptance case.

- [ ] Each proposed interface cites an existing convention or records why it must change.

- [ ] Unresolved requirements remain visible rather than guessed.

- [ ] Tracker publication and repository configuration changes are explicitly scoped.

## Deliverables

- [ ] Requirement-to-case map

- [ ] Local specification

- [ ] File/interface blueprint

- [ ] Open-decision log

## Evidence and decision

Evidence links: [fill in]
Untested paths: [fill in]
Unresolved findings: [fill in]
Reviewer: [fill in]
Decision and scope: [fill in]

## Boundaries

- The to-spec skill synthesises an existing discussion; it does not replace requirements discovery. Its configured tracker can publish issues and labels.

- The architect proposes a design without executing it. Older model/tool names need host adaptation, and a readiness label is not implementation evidence.

Workflow: https://undominated.ai/workflows/#turn-a-decision-into-a-spec