PUBLIC · DOCUMENTATION

Document a change for the next person

Explain what changed, why it matters, and how it was checked.

When to use it

After a change ships, while the reasons are still fresh and before the conversation that produced it is gone.

What to expect

A change note a future maintainer can use: the problem, the resulting behaviour, the decisions that mattered, what was verified, and what remains.

Example

A validation change to a file import that now rejects a shape it used to accept.

Add your context

Optional. Leave fields blank to copy a reusable template. What you type stays in this tab.

changereaderproblemchecks performed

PROMPT TEMPLATE

Document {{CHANGE}} for {{READER}}.

Reason for the change: {{PROBLEM}}
Evidence and verification: {{CHECKS_PERFORMED}}

Lead with the concrete problem and resulting behavior. Summarize meaningful implementation decisions. Describe compatibility, configuration, and migration implications only when applicable.

Separate verified results from expected behavior. Include remaining limitations and operational follow-up. Avoid restating every changed line or claiming tests ran without evidence.

Return a concise change note that a future maintainer can use without reading the original conversation.

4 of 4 context fields remaining.

Free to copy. Use it in the tools you already have.

← Back to the library