Prompt file imported from dmckinstry/unity-framework (.github/prompts/new-adr.prompt.md). Fill in {{decision}} before use. Copyright stays with the author.

New ADR

Decision: {{decision}}

1. Check it needs one

ADRs are required for CRITICAL changes, package adoption/rejection, assembly topology, save/serialization format, netcode topology, render pipeline decisions, and any case where the obvious choice was rejected.

Routine feature work following existing patterns does not need an ADR. Say so and stop if that's the case.

2. Check for an existing ADR

Read docs/adr/README.md. If an accepted ADR already covers this area, you are superseding it — say which one, and set its status to Superseded by ADR-NNNN rather than editing its content.

3. Gather evidence

Cite path:line, package versions, profiler numbers, and platform constraints. An ADR full of opinions is worthless six months from now; an ADR with the numbers that forced the decision is not.

4. Draft it

Copy docs/adr/0000-template.md to docs/adr/NNNN-short-kebab-title.md with the next number, and fill in:

• Context — the binding constraints: platform targets, frame budget, Unity version, ship date, team size. Facts with evidence, not impressions.
• Decision — active voice, two or three sentences.
• Alternatives considered — a table with pros, cons, and why each was rejected. Include "do nothing" if it was plausible. An ADR with no rejected alternatives is not a decision, it's a note.
• Consequences — positive, accepted costs, and follow-up work created.
• Unity-specific impact — frame budget, memory/build size, serialized data, platforms, packages, Editor workflow.
• Rollback — reversible or not, how, and the point of no return.
• Validation — how we'll know this was right, and when we'll check.

5. Update the index

Add a row to the table in docs/adr/README.md.

Set status to Proposed and stop — the human accepts it, not you.