Prompt: Plan Product Change

Use in anuva-main-video-creator. The $linear-plan-change skill normally fills the placeholders from Linear.

Plan the Anuva product change described by Linear issue {{CHANGE_ISSUE_ID}}.

Inputs:
- Change ID: {{CHANGE_ID}}
- Title: {{TITLE}}
- User outcome: {{USER_OUTCOME}}
- Known constraints: {{KNOWN_CONSTRAINTS}}
- Priority: {{PRIORITY}}

Read the Product Architecture, Repository Registry, Capability Map, current
development process, and any linked source docs. Do not modify Web, Python, or
Unity implementation.

If the parent is Backlog, show and obtain approval for `anuva linear change
start {{CHANGE_ISSUE_ID}} --confirm`. Then start the planning branch with
`anuva work change start {{CHANGE_ISSUE_ID}} --phase planning --confirm`.

Create or update:
- docs/changes/{{CHANGE_FOLDER}}/index.md
- docs/changes/{{CHANGE_FOLDER}}/ChangeBrief.md
- docs/changes/{{CHANGE_FOLDER}}/RepositoryImpact.md
- docs/changes/{{CHANGE_FOLDER}}/ImplementationIssues.md
- docs/changes/{{CHANGE_FOLDER}}/Progress.md
- a product ADR only if a cross-repository decision needs durable rationale

The plan must define current and target behavior, non-goals, canonical contracts,
repository ownership, dependencies, sequencing, migration/compatibility, failure
behavior, acceptance checks, docs impact, verification, and product completion.

Ensure every affected directory under `docs/` has an `index.md`, update parent
indexes, and validate the index hierarchy.

Prepare repository-scoped Linear issue drafts with complete descriptions. Do not
create issues yet. Ensure the Product Main MkDocs preview, wait for all changed
pages, and provide their exact HTTPS URLs. Pause for approval with unresolved
questions and the exact proposed planning PR commands.

After explicit approval, create, ready, and merge the planning PR through
`anuva pr change` operations. Verify the parent remains In Progress. Only then
create implementation issues through the named Anuva CLI operation, record
returned IDs and links, and preview the updated pages. Never use GitHub issues,
GitHub Projects, YAML workflow execution, Codex Goals, Symphony, or automatic
canonical docs publishing.