project-wrap-up

name	project-wrap-up
description	Use when the user asks for final project wrap-up, repository closeout, or end-of-project work, including Chinese requests such as 收尾, 收官, or 结项, that may require docs, versioning, verification, build, git, or GitHub follow-through.

Project Wrap-Up

Overview

Project wrap-up is end-stage orchestration over repository hygiene, verification, artifacts, and git/GitHub follow-through. It is for closing out a project or change set near the finish line, not for general coding, CI debugging, or routine PR publishing. Default to general repository wrap-up unless the repository clearly indicates a narrower route.

Non-Negotiable Start

Inspect repository state first. Before taking wrap-up actions, offer both cautious mode and automatic mode. Do not skip mode selection. Pre-mode inspection is always allowed; mutations are not. If the user asks for a specific wrap-up action, still offer both modes, but recommend the mode that best matches the requested action instead of creating unnecessary friction.

Initial inspection should establish evidence for:

• git repository status
• current branch and remote state
• dirty worktree, untracked files, conflicts, and stash presence
• repository conventions for docs, versioning, CI, releases, and artifacts
• project type indicators that affect routing

If the directory is not a git repository, stop quickly and explain that wrap-up orchestration cannot proceed without repository context. For git repositories, stash inspection is read-only during initial inspection: detect whether stashes exist and inspect only as needed to understand whether hidden work affects wrap-up risk; do not apply, drop, or rewrite stashes during inspection.

Mode Rules

Cautious Mode

Proceed with inspection and evidence-backed low-risk cleanup, but stop before:

• commit
• push
• merge
• tag creation
• GitHub release creation
• branch deletion
• release-significant version changes

Automatic Mode

Continue through the wrap-up flow without extra pauses unless high-risk anomalies appear, such as:

• unknown dirty worktree changes
• failing verification
• version conflicts
• unclear release targets
• suspicious remote or branch state

If a high-risk anomaly appears, stop and surface it before continuing.

Main Flow

1. Inspect context and establish repository-specific evidence.
2. Offer cautious mode and automatic mode; wait for selection before wrap-up actions.
3. Find and fill only evidence-backed omissions that are justified by repository conventions, changed scope, or clearly stale state, such as stale docs, missing changelog entries, inconsistent versions, skipped verification, or missing expected artifacts.
4. Update docs and version metadata only where repository conventions or current changes justify it.
5. Choose the minimal sufficient verification set based on repository conventions and the changed scope, then run repository-native verification such as tests, lint, typecheck, or build.
6. Build artifacts or verify expected outputs only when the repository indicates they are part of wrap-up.
7. Prepare a concise wrap-up summary suitable for commit, PR, or release notes.
8. Execute git/GitHub follow-through according to the selected mode and repository conventions.

For release-oriented paths, stop on verification failure unless the user explicitly overrides. The wrap-up summary should minimally include:

• what changed
• what verification ran and whether it passed
• what artifacts were produced or confirmed
• which follow-through actions are ready, pending, or blocked

Routing

Default to the general repository route.

Use the Android/mobile route only when the repository shows evidence such as:

• build.gradle
• app/build.gradle
• AndroidManifest.xml
• fastlane

This skill explicitly handles Android/Gradle-style mobile wrap-up. Other mobile stacks stay on the general route unless the repository exposes equivalent evidence for a distinct wrap-up path.

Use the GitHub release route only when:

• tags or releases already exist as an established practice, or
• the user explicitly asks for a release

Sufficient evidence for the GitHub release route includes examples such as:

• existing version tags or prior GitHub releases
• documented release steps in repository files or automation
• release-note templates or release workflows already present
• explicit user instruction to prepare or publish a release

For PR/merge work, distinguish:

• PR prep: wrap up changes, verification, summary, and branch/PR readiness
• merge completion: merge, post-merge follow-through, and optional cleanup only when supported by evidence and mode rules

Do not consider merge completion unless there is evidence of:

• the target branch
• merge authority and repository policy
• clean verification status for the intended merge path

Guardrails

• Do not invent workflows, release processes, or versioning rules.
• Do not treat every wrap-up as a release.
• Do not continue release-oriented work after verification failures unless the user explicitly overrides.
• Do not assume merge strategy, merge target, remote policy, or cleanup policy without evidence.
• Do not present irreversible actions as already done until they are actually executed under the mode rules.

References

Use:

• references/checklists.md
• references/release-decision-table.md

references/checklists.md is authoritative for checklist coverage and route-specific wrap-up checkpoints. references/release-decision-table.md is authoritative for release/PR/merge/tag decision gating. If a referenced file is missing or conflicts with the main body, follow the main body and surface the discrepancy. These references support checklist coverage and release decision gating, but the default path remains general repository wrap-up.