WoW addon development

Establish the target contract

1. Read wow-client-targets before selecting APIs. Explicit user targets take precedence over existing configuration. Inspect TOCs, packaging configuration, and existing compatibility modules; ask if the target remains ambiguous. Do not silently default to Retail.
2. Support retail, forever, classic, and all (exactly these three). Classic means the progression branch, not Classic Era. Requests for Era, Anniversary, PTR, beta, or private servers require a scope change, not silent substitution.
3. Record selected targets, upstream commits, client/interface versions, feature requirements, and unresolved availability in the addon project's documentation. Keep installed plugin files read-only during ordinary addon work.

Keep larger projects anchored to written requirements

For a new addon, a substantial feature, or a long request spanning multiple systems, follow project planning and resumption. Create or update the requirements document and implementation matrix in the user's addon repository, using the packaged templates when no equivalent documents exist. Give requirements stable IDs and connect every requested behavior to implementation work and observable acceptance evidence, including target-specific and visual checks. A small isolated fix can use concise task notes instead.

Work through bounded, dependency-ordered slices. Update the matrix and its checkpoint after each slice and before a handoff or context reset. On resumption, read those files and inspect the recorded revision before continuing; reconcile new user instructions without silently losing earlier requirements. Existing authorization remains valid: the documents organize work and do not create an extra approval gate. Keep unresolved required behavior visible instead of marking the whole project complete because the current slice passes.

Treat options and localization as baseline requirements

For new addons and relevant changes, follow addon options and localization. Expose user-configurable behavior through the selected client's built-in addon settings menu, with stable setting identities, saved defaults/migrations and verified registration/loading. Route options work through settings. A slash command can supplement discovery. An addon with no configurable behavior can record that reason; preserve explicit user exclusions and avoid expanding an isolated unrelated fix.

Route addon-owned visible text through a localization catalog with a complete English fallback, including options, tooltips, help, errors and controller hints. Translate intent into natural target-language phrasing, grammar and terminology rather than matching English words or sentence structure. Record supported locales, translation/review coverage and per-client menu, persistence and localized-layout acceptance in requirements or task notes. Fallback readiness is not evidence that every language is translated or tested. Carry both requirements through implementation and delivery without adding approval gates.