Managing the Release Issue

Use a GitHub issue as the living checklist of everything that must be done on the production side before a release.

Keep the target release issue accurate as development progresses. Resolve the repository, issue number, non-production environment, production environment, and release route from the user's request, repository instructions, or established conversation context. If the target repository or issue remains unclear, ask before making changes.

The Core Rule

Only add a production step once its equivalent is already working in the project's relevant non-production environment.

The issue is not a wishlist. When the user has integrated and verified a service, environment change, configuration value, domain, or other capability outside production, add its production counterpart. This keeps the checklist trustworthy: every unchecked box is a real, known action.

If the user asks to add a step for something that is not yet working in the relevant non-production environment, confirm that before adding it.

Issue Structure

Organize the release issue into these phases and keep new steps in the right phase. If the issue already uses equivalent headings, preserve its wording and structure.