development-cycle-closure

name	development-cycle-closure
description	Use for rankingdepadel.club implementation handoffs, changelog and issue/spec reconciliation, commits, pushes, release consolidation, and ending a development cycle.

Development Cycle Closure

Use this skill when preparing an implementation response, updating closure metadata, committing, pushing, or reconciling shipped work.

Implementation Response

Formal implementation handoffs must include:

• Technical Summary
• Files Modified
• Tests added or modified, with command and result summary
• Changelog Entry with the exact text added
• Human readable summary of changes
• 3-6 Manual Functional Checks
• Recommended Commit Message covering the full accumulated uncommitted change set since the last commit

Cycle-closure responses may omit Manual Functional Checks when they were already proposed in the implementation handoff and no further implementation changed user-facing or operational behavior.

Both implementation handoffs and cycle-closure responses must include:

• After the report, suggest running /clear to reset the context window when the cycle is closed; this is only a suggestion, never a required step.

Interim implementation updates may be shorter and should focus on current status, blockers, and validation already run.

Commit Messages

Use this subject format for recommended and final commits:

type(scope): imperative summary

• Use lowercase type, chosen from feat, fix, docs, test, refactor, chore, release, merge, or revert.
• Use a short lowercase scope when it clarifies the owned area, such as ui, players, notifications, governance, release, or tests.
• Omit the scope only for truly cross-cutting changes.
• Write the summary in imperative mood, lowercase after the colon, and without a trailing period.
• Prefer one commit for one coherent development cycle. When the cycle spans multiple domains, choose the primary user-visible or workflow domain instead of listing several scopes.
• Keep release automation subjects consistent with existing patterns, such as release: focus staging checks on shipped changes, chore(release): harden orchestrator resume flow, and merge(release): backmerge main into develop after v1.10.4.

Changelog and Issues

• Update CHANGELOG.md under ## [Unreleased] for every behavior, docs, governance, workflow, or guidance change unless it is formatting-only, test-only with no behavior change, or internal cleanup with no shipped outcome.
• Prefix mixed-release bullets with stable domain categories such as UI/UX, Governance, Release, Backend, Data, Mobile, Tests, or Docs.
• Keep at most one changelog bullet per category within each release. Merge similar specs or outcomes into the existing category bullet and keep descriptions tight.
• CHANGELOG.md records shipped outcomes, not process narration.
• During cycle closure, reconcile completed in-scope GitHub Issues by ensuring the outcome is reflected in CHANGELOG.md, then close or reference the Issue as appropriate.
• When an in-scope GitHub Issue defined the completed work, fetch it during closure. If it is still open, close it with state reason completed; if it was already closed manually, leave it closed and do not reopen it.

Closing a Development Cycle

Before any commit, push, or closure step:

• If the user explicitly says close cycle, close specification, or gives equivalent direct closure authorization, treat that as approval and skip the extra continuation prompt.
• Otherwise, ask whether the user wants to continue developing.
• If not, ask: Do you want me to proceed with staging changes, committing with the recommended commit message, pushing to the remote branch, and closing the current development cycle?

When closure is authorized:

1. Update each completed in-scope loose spec from Status: approved to Status: implemented.
2. Reconcile in-scope GitHub Issues.
3. Stage, commit, and push sequentially.
4. Use git commit --no-gpg-sign; do not try a signed commit first in this environment.
5. Keep processing requested-work changes until git status --short is clean.

Release authorization is not production authorization. If a closure request also asks for release, proceed only through staging deployment and staging verification, then stop for the staging manual checks. Those checks should be directly linked to the changes being released; use the release-derived checklist from the script first and keep generic smoke coverage brief. Do not create or merge the staging -> main PR, deploy production, or back-merge main until the user explicitly approves production promotion after those staging checks, or supplies the documented --staging-approved resume command.

Keep release closure context-light. Summarize command results instead of pasting repeated polling output, avoid full diffs unless diagnosing a failure, and report only the decision-relevant lines from GitHub checks, SSH deploys, and validation commands. Prefer one concise status update per release phase. If gh pr checks exits nonzero only because checks are pending or not yet discovered, inspect the PR check rollup, wait for the visible checks to finish, and then rerun the same release command. Use gh pr checks <pr> --watch for that wait. Treat a concrete failed job as a CI fix; do not start a new release path just because check polling was early. When a release fails in staging, diagnose the cause and batch staging repair fixes before starting repeated PR/deploy loops unless one urgent hotfix is clearly sufficient. If any repair commit lands after staging has already been deployed, treat the old staging approval as invalid: push the repair, rerun local validation and the staging promotion/deploy for that exact commit, and only then ask for or use production approval. The release orchestrator saves completed phase state, so rerun the same version command to resume instead of reconstructing completed prep, PR, deploy, back-merge, or consolidation steps manually; only adjust saved state when a post-staging repair makes a completed phase stale.

Release Consolidation

After production and the main back-merge, consolidate before new SDD work:

• Initially select shipped specs with repeatable --release-spec, or declare --no-release-specs.
• Release prep stamps vX.Y.Z and persists source names; consolidation must match them and create a record, including for a spec-free release.
• Leave unselected Release tag: unreleased files for future releases.
• Use production history and completed Issues for concise final wording.
• Keep one changelog bullet per stable category and merge related outcomes.
• Roll unshipped work into the production release that ships it.
• Use a new loose spec for post-release follow-up; do not extend shipped work.