wrap-up git:20261018.7eb3bb5A

Immutable. This exact content never changes and is served at /api/v1/blob/dda71dc1ca50e6cf.

---
name: wrap-up
description: >
  Close out a small change or multi-step task by checking its original objective, running applicable
  quality gates, auditing the diff and task-owned artifacts, and preparing an evidence-backed handoff.
  Use when work is believed done, the user asks to wrap up or clean up, or before handing work off.
  For a retro over repository history use retro-analysis; for agent operations use agent-ops-retro.
license: MIT
compatibility: Codex, Claude Code, Cursor, GitHub Copilot, Windsurf, Kiro, Grok, and other Agent Skills compatible tools.
metadata:
  author: Oleg Koval
  tags:
    - delivery
    - verification
    - cleanup
    - git
    - worktrees
    - release-hygiene
---
<!-- Generated by scripts/build-adapters.sh. Do not edit directly. -->

# Wrap Up

Use this as a proportional end-of-task audit. Preserve pre-existing work and do not expand the task to make the report look complete.

## 1. Verify the objective

- Restate the original request, issue, or ticket and its acceptance criteria. Compare each criterion with the actual diff and evidence, not just the implementation plan.
- Mark each outcome `completed`, `partially completed`, `intentionally deferred`, or `blocked`; mark unverified facts `unknown`. Give the reason and next action for anything incomplete.
- Set overall status to `completed` only when every required criterion and check passes. If required evidence is missing or a check fails, report `partially completed` or `blocked` as appropriate. A deliberate deferral is complete only when it was outside the agreed acceptance criteria.

## 2. Run applicable quality gates

- Detect the project type and configured commands from local instructions, manifests, scripts, and CI before running anything. Choose checks proportional to the change, from focused checks to broader gates when warranted.
- Run configured, non-destructive formatter checks, lint, typecheck, unit and integration tests, build, and project-specific validation when applicable. Distinguish a formatter check from a formatter command that rewrites files; inspect side effects before running the latter.
- Record each command and `pass`, `fail`, `skipped`, or `not applicable` for each gate. Explain skips. Redact secrets and personal data from commands and failing output before quoting the smallest useful excerpt; never invent a result or claim success after a required failure.
- Inspect each required delivery gate at its authoritative source: local commit, remote SHA, PR state and review threads, current-head CI, deployed version or endpoint, and browser, device, or human acceptance. Mark unavailable evidence `unknown`; do not infer one gate from another.

## 3. Audit the diff, hygiene, and context

- Inspect `git status`, staged and unstaged diffs, untracked files, recent branches, and `git worktree list`. Identify task-owned worktrees, scratch branches, generated files, debug files, and local-only configuration; leave uncertain or pre-existing work untouched.
- Scan introduced lines for `console.log`, `print`, `dbg!`, `debugger`, equivalent debug output, commented-out code, new TODO/FIXME/HACK markers, temporary flags, and unused imports, files, dependencies, or configuration. Flag legitimate diagnostic logging for review; do not remove it automatically.
- Check the diff and untracked files for keys, tokens, passwords, private keys, connection strings, cookies, personal data, and credentials in logs or examples. Report locations without printing values; recommend environment variables or a secret manager where relevant.
- Decide from the actual change whether README, architecture or API docs, OpenAPI, CHANGELOG, CONTRIBUTING, `.env.example`, ADRs, or runbooks need an update. Name the exact change needed. Skip documentation for trivial internal changes unless it helps future maintenance.

## 4. Prepare safe cleanup

- Propose cleanup commands only. Do not remove any file, branch, or worktree automatically, including generated or temporary files. Never propose deletion of an unknown untracked file, broad directory, or unresolved glob.
- Before proposing worktree or branch deletion, verify a clean worktree, ownership, no unpushed commits, and that the branch is not active in another worktree. Check `git branch --merged <default-branch>` and remote/merge state where relevant. An unmerged pushed branch may be the recovery point.
- For confirmed safe targets, propose `git worktree remove -- 'path with spaces'` or `git branch -d -- 'topic/branch'` with the actual argument shell-quoted, including embedded quotes. Use `--` to end options; never interpolate untrusted names as raw shell text. Use `git fetch --prune` only when network access and remote cleanup are appropriate. Force deletion requires explicit approval.
- Read-only inspection and configured non-destructive checks may run automatically. Ask before committing, pushing, creating or updating a PR, deleting any file, branch, or worktree, or modifying external systems. Existing explicit authorization for the task still applies.

## 5. Handoff

Use the report below, keeping it brief for a small change and adding detail only where evidence or risk warrants it. State what was executed and what still needs confirmation. If a PR is appropriate, draft its motivation, changes, testing evidence, rollout and rollback considerations, and reviewer notes; do not publish it without authorization. Suggest a conventional commit message without committing.

```markdown
### Wrap-up report

**Objective**
<original task and acceptance criteria, each marked completed / partially completed / intentionally deferred / blocked / unknown; use unknown when evidence is unavailable>

**Status**
`completed | partially completed | blocked`

**Changes**
- <file or area>: <what changed and why>

**Checks**
| Check | Result | Notes |
|---|---|---|
| Formatter | pass/fail/skipped/not applicable | <command and evidence or reason> |
| Lint | pass/fail/skipped/not applicable | ... |
| Typecheck | pass/fail/skipped/not applicable | ... |
| Unit / integration tests | pass/fail/skipped/not applicable | ... |
| Build / project validation | pass/fail/skipped/not applicable | ... |

**Delivery**
- Local commit: <SHA or not applicable>
- Remote: <verified SHA and branch, pending, or not applicable>
- PR and review: <state, unresolved threads, or not applicable>
- CI: <current-head checks and result, pending, or not applicable>
- Deployment: <version or endpoint evidence, unknown, or not applicable>
- Browser/device/human acceptance: <evidence, unknown, or not applicable>

**Cleanup**
- Proposed: <exact safe commands or none>
- Executed: <actions or none>
- Requires confirmation: <actions or none>

**Documentation**
- Created: <files or none>
- Updated: <files or none>
- Not needed: <reason or none>

**Risks and follow-ups**
- <remaining risk, blocked gate, or next action; include delivery state if relevant>

**Suggested commit**
`type(scope): concise imperative summary`

**Handoff**
<2–5 sentences with the evidence and next step a teammate needs>
```