> ## Documentation Index
> Fetch the complete documentation index at: https://docs.plannotator.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# AI Coding Plan Template

> Copy a concise AI coding plan template with scope, implementation steps, risks, validation, and review prompts for a coding agent.

Use a coding plan when the proposed implementation needs review before the agent changes code. Keep it specific enough to expose risks and omissions, but do not turn it into a transcript or prewrite every line.

```md theme={null}
# [Outcome]

## Problem
[What is wrong or missing, who is affected, and why it matters.]

## Scope
- [In-scope behavior or system]
- [In-scope behavior or system]

## Not in scope
- [Explicit exclusion]

## Current evidence
- [Relevant code, issue, log, metric, or prior decision]

## Implementation
1. [Change and where it belongs]
2. [Change and how it connects]
3. [Migration, rollout, or compatibility step]

## Risks and open questions
- [Risk, uncertainty, or decision still required]

## Validation
- [Command or automated check]
- [Browser, integration, migration, or operator proof]
- [Expected result]

## Documentation
- [Maintained document that must change]
```

## Annotated example

```md theme={null}
# Reject expired export links before object lookup

## Problem
Expired links still reach the storage lookup, which leaks timing and spends a request.

## Scope
- Validate expiry in the download route before calling the object store.
- Preserve the existing not-found response shape.

## Not in scope
- Changing link lifetime or token format.

## Implementation
1. Move expiry validation into the shared download gate.
2. Return the existing 404 response before storage access.
3. Add an integration test that proves the object store is not called.

## Risks and open questions
- Confirm clock-skew handling remains unchanged.

## Validation
- Run the route integration suite.
- Verify valid, expired, and malformed links return the documented responses.
```

The example names the outcome, boundary, precise change, and proof. It does not prescribe unrelated refactors.

For a larger generated example, inspect the [69-task Spec Kit list for reliable webhook delivery](https://github.com/plannotator/spec-planning-frameworks/blob/main/examples/github-spec-kit/raw/specs/001-reliable-webhook-delivery/tasks.md). It is the task artifact from a complete Spec Kit planning flow.

## Review prompts

* Does the plan solve the stated problem rather than only the visible symptom?
* Are affected data, API, security, compatibility, and user-interface boundaries named?
* Can each validation step fail for the bug the plan claims to prevent?
* What maintained documentation must describe the result after implementation?

This template is Plannotator-authored. Its structure is informed by primary sources including Superpowers' [writing-plans skill](https://github.com/obra/superpowers/blob/d884ae04edebef577e82ff7c4e143debd0bbec99/skills/writing-plans/SKILL.md), GSD Core's [planning-artifacts reference](https://github.com/open-gsd/gsd-core/blob/50efae13ce74f02a5b0253ce0c205c5eac2a99e3/docs/reference/planning-artifacts.md), and GitHub Spec Kit's [plan template](https://github.com/github/spec-kit/blob/57cc518d63d6f10da3dd93df1ebcadda87c59374/templates/plan-template.md). It does not copy those templates. Use [open-source plan review](/open-source/workflows/plan-review) to annotate it locally or [Workspaces](/workspaces/review-plans-and-technical-decisions) when several people or agents need the same shared document.

*Reviewed July 19, 2026. Written and maintained by the Plannotator documentation team.*