Write a spec

Put the spec in the pull request body. The agent reads that body. A short title is not a spec.

Write five parts. Use the headings below so a later reader can find them.

GoalCopy Anchor Link

One or two sentences. Name the behaviour the user should see when the pull request merges. Name the repository paths only when the goal is a specific file.

Acceptance criteriaCopy Anchor Link

A list the agent can check. Each line is a fact that is true or false. Prefer commands and observable output over adjectives.

• just check passes.
• GET /health returns 200 when the worker heartbeat is fresh.
• The new flag --explain prints one row per guard.

ConstraintsCopy Anchor Link

Rules the agent must not break. Examples: do not add a dependency, do not change the public config schema, keep functions at or under 50 lines, ASCII only in user-facing copy.

Out of scopeCopy Anchor Link

Name the work you do not want in this pull request. Agents fill silence with extra edits. Out of scope is how you stop that.

Files to look atCopy Anchor Link

List the files that already implement the neighbouring behaviour. Point at tests that should change. Do not paste the whole tree.

TemplateCopy Anchor Link

Copy this into the pull request body and replace the placeholders.

## Goal

<one sentence: what is true after merge>

## Acceptance criteria

- <checkable fact>
- <checkable fact>

## Constraints

- <rule the agent must not break>

## Out of scope

- <work that belongs in another pull request>

## Files to look at

- `<path>`
- `<path>`

What the agent cannot changeCopy Anchor Link

Policy comes from .autofeat/config.yml on the default branch. Editing that file on the pull request branch does not change the run. Budgets, allowed agents, and merge mode stay at the default-branch snapshot (policy_sha on the sticky comment).

Labels are the control surface for this pull request. See Labels.