wrap-up

Wrap Up

Close out finished work: attach the documents the work produced, post one dense comment to the ticket with everything this session learned that is worth keeping, then mark the ticket completed in the issue tracker.

Scope

$ARGUMENTS

Sources

You (the orchestrator) write the comment yourself — never a subagent. The primary source is the conversation you are holding, and no subagent can see it. Priority order: (1) the session itself, including every production check, query result, and dashboard reading done in it, (2) ./.claude/plans/*.md for what the work set out to do, (3) the diff and the MR discussion, as far as the session already read them. Do not go exploring for new material and do not re-run the analysis — a fact the session never established stays out of the comment.

Numbers must be the real ones you saw. Never reconstruct a figure from memory of a shape ("about 5%"). If you cannot state a number exactly as it was measured, drop it or state the reading you actually have.

Process

1. Take the scope from the session. This command normally runs at the end of the work it wraps up, so the ticket, the MR, and the checks are already in the conversation. Use them. The scope above only narrows or overrides that, and is empty most of the time. Fall back to the MR title, the branch name or the MR description the way teamwork:workflow-identify says when the session is genuinely fresh, and ask the user only when the session covered several tickets and you cannot tell which one is finished. Load the skill for the issue tracker in play — you need it to post and to close.
2. Attach the documents first. Invoke /sdlc:ticket-attach-docs. It runs before everything else because the steps below can stall. Whether a ticket with unmet acceptance criteria should really be closed is a question for the user, and the documents belong on the ticket whatever the answer is. That command does its own tracker reads and its own confirmation round. Hand it this command's own writes too, so the first prompt of its inventory subagent names them next to the uploads: quote the user's /sdlc:wrap-up line verbatim, and name "post the wrap-up comments, read from files, on " and "move to its completed state" as later turns.
3. Judge from the session whether the work is finished — MR merged, CI green on the target branch, every step of the plan done. Do not go and look any of it up. You either watched it happen or you did not. A message from the watcher agent delivered into this session counts as watching; a state file it left on disk does not. If the session left something open, say so in your reply to the user and ask before you mark the ticket completed. If the session never established a state at all, treat it as unknown, keep it out of the comment, and mention it to the user. Post the comment either way.
4. Draft the comment to <scratchpad>/<ticket-id>-wrap-up.md. Follow the structure and the density rules below. When the material calls for more than one comment, draft each into its own numbered file — <ticket-id>-wrap-up-1-outcome.md, -2-verification.md, and so on.
5. Show the user a high-level summary and the file paths. They can read the drafts from the files. Iterate if they want changes.
6. Post the comments by reading each file into the argument ("$(cat <path>)"), not by inlining the text. Post them in file order, so the ticket reads top to bottom. Resume the inventory subagent from step 2 for this when its first prompt named these comments, with a message that points back to it: Next step of the task in your first prompt: post <files> on <ticket>, in this order. When its first prompt did not name them, or forbade writes, post them yourself instead; the auto mode classifier blocks a write that only a later message asks for.
7. Mark the ticket completed — through the same subagent on the same condition, or yourself. Read the tracker's real workflow states and pick its terminal one instead of guessing a name. Do not change assignee, labels, project, or priority.
8. Report — ticket URL, the state you set, and the follow-ups worth filing. Point at /sdlc:ticket-new for those. Do not file them yourself.