# Wrap Up

> Delivery: merge branch, generate PR document, update plan status. Usage: /wrap-up MLID-XXXX

- Skill: `alejandrogomezforte/wrap-up` (Agent Skill)
- Install (CLI): `npx skillmds@latest add alejandrogomezforte/wrap-up`
- Raw SKILL.md: https://api.skillmd.com/api/skills/alejandrogomezforte/wrap-up/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: alejandrogomezforte (https://skillmd.com/u/alejandrogomezforte)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/alejandrogomezforte/wrap-up

---


# /wrap-up $ARGUMENTS

You are running the **delivery phase**. Merge the branch, generate the PR document, and update tracking documents. **You do NOT create GitHub PRs** — the user handles PR creation manually.

## Step 1 — Gather context

1. Read the plan file for `$ARGUMENTS` from `docs/agomez/plans/`
2. Determine if this is a **standalone task** or **epic sub-task** (from plan file)
3. Check the current branch: `git branch --show-current`
4. Get the commit history for the branch: `git log --oneline <base-branch>..HEAD`
5. Get the diff summary: `git diff --stat <base-branch>...HEAD`

## Step 2 — Branch merge (epic sub-tasks only)

If this is an **epic sub-task**:

```bash
# Merge feature branch into epic branch
git checkout epic/MLID-XXXX-epic-name
git pull origin epic/MLID-XXXX-epic-name
git merge --no-ff feature/$ARGUMENTS-short-description
git push origin epic/MLID-XXXX-epic-name

# Clean up feature branch
git branch -d feature/$ARGUMENTS-short-description
git push origin --delete feature/$ARGUMENTS-short-description
```

Then continue to Step 3 to update the tracking documents.

## Step 3 — Update plan status

**This step always runs**, for both task types, and it runs BEFORE the PR document — an epic sub-task
with siblings still open stops after this step and never reaches Step 4, so status updates must not
live downstream of it.

Which files to update depends entirely on whether the task belongs to an epic. Determine that from
the plan file read in Step 1 (a sub-task plan names its epic and its base branch is an `epic/…`
branch; a standalone plan has `develop` as its base).

### Case A — standalone task (not part of an epic)

Update **only the task plan document**, `docs/agomez/plans/<task_id>*.md`:

- Set **Status** to `Done`
- Record the branch and the commit hashes

There is no epic document to touch. Do not go looking for one.

### Case B — epic sub-task

Update **both** documents. Neither is optional, and the epic one is the one that gets forgotten.

**1. The task plan** — `docs/agomez/plans/<task_id>*.md`:

- Set **Status** to `Done`
- Record the merge commit into the epic branch, and the feature commit
- Note anything deferred (for example a staging pass scoped out), so a green plan is not mistaken
  for "verified everywhere"

**2. The epic plan** — `docs/agomez/plans/<epic_id>-plan-progress.md`:

- In the deliverable's task table, update this sub-task's row: **Status** → `Done`, **Branch** →
  the feature branch, **Merged to Epic** → `Yes` with the merge hash
- Use the **Notes** column for anything a sibling sub-task needs to know — a migration number, a
  constraint discovered during implementation, a deferred verification

**3. Then check the rest of the epic document for reasoning the implementation invalidated.**

The table row records *that* the sub-task is done. It does not record what building it taught you,
and the epic document usually holds prose that is now wrong. Nobody arrives at these sections by
updating a row, so check them deliberately. The usual places:

- **Flagged concerns / resolved rulings** — a ruling can stay correct while the reasoning behind it
  turns out to be incomplete. Implementation often finds consequences the ruling never considered.
  Mark it as *refined*, not overturned, and say what changed. This is the section a future reader
  consults before reopening the question, so leaving it as-is quietly hides what you learned.
- **Dated "current state" observation sections** — each later sub-task reads these before starting.
  Do not rewrite a dated observation; append a short "What `<task_id>` changed" note covering what
  the next sub-tasks actually need: what now exists, what is already wired, what is deliberately
  still pending, and any pre-existing failure they should not mistake for their own.
- **Risk register entries** — a risk this sub-task closed, realised, or made concrete.
- **Open items carried forward** — anything this sub-task answered.

Only touch what the implementation genuinely changed. If nothing outside the table row is affected,
say so and move on — this is a check, not a mandatory edit.

Then decide whether to continue:

- **If more sub-tasks remain in this deliverable** → **STOP here.** Tell the user the sub-task is
  merged, both documents are updated, and what the next sub-task is. Do NOT generate a PR document.
- **If the deliverable group is complete** → continue to Step 4.

## Step 4 — Generate PR document

Create a PR message document at `docs/agomez/PR/$ARGUMENTS.md` by analyzing:
- The plan file (for summary and context)
- Git log (for commits)
- Git diff (for files changed)

### PR Document Structure

```markdown
# [$ARGUMENTS] type(scope): short description

## Summary
- Bullet points of what was done and why

## Root Cause
(For bug fixes only — explain the underlying problem)

## Changes Overview
- **Files changed**: N
- **Lines added**: +N
- **Lines removed**: -N

## Files Changed

| File | Change | Description |
|------|--------|-------------|
| `path/to/file.ts` | Modified | What changed and why |

## What Changed and Why
Detailed breakdown of each change area. Include:
- Before/after examples where applicable
- Alternatives considered
- Design decisions made

## Commits
| Hash | Message |
|------|---------|
| `abc1234` | [$ARGUMENTS] - feat(scope): description |

## Test Plan
- [ ] Manual verification step 1
- [ ] Manual verification step 2

## Jira
- [$ARGUMENTS](https://localinfusion.atlassian.net/browse/$ARGUMENTS)
```

## Step 5 — Present next steps to the user

Tell the user what manual steps remain for PR creation. Include the exact commands tailored to their task type:

### For standalone tasks:
```
Next steps (manual):
1. Push the branch:  git push origin -u <branch-name>
2. Create the PR:    gh pr create --base develop --head <branch-name> --title "<title>" --body-file docs/agomez/PR/$ARGUMENTS.md
```

### For epic sub-tasks (deliverable complete):
```
Next steps (manual):
1. Rebase on develop: git rebase develop && git push origin <epic-branch> --force-with-lease
2. Create the PR:     gh pr create --base develop --head <epic-branch> --title "<title>" --body-file docs/agomez/PR/$ARGUMENTS.md
```

## Important Rules

- **Git commands are OK** — merges, rebases, pushes are allowed (user will approve via permission prompt)
- **NEVER create GitHub PRs** — no `gh pr create` or any `gh` commands. The user handles PR creation manually.
- **NEVER transition Jira tickets** — only update Jira when the user explicitly asks
- **PR body from the document** — use the generated PR doc content
- **Epic sub-tasks**: if the deliverable isn't complete, STOP after Step 3 — don't generate a PR doc. The status updates in Step 3 still happen; only the PR document is skipped
- **Status updates are never skipped**: a standalone task updates its task plan; an epic sub-task updates its task plan AND the epic plan-progress file. Step 3 owns this for both types, and it runs before the PR document precisely so an early stop cannot skip it
- **Commit format**: `[$ARGUMENTS] - type(scope): description` — no Co-Authored-By
- **Always rebase before PR** — ensure clean history against the base branch