atelier-fashion/adlc-toolkit/wrapup

/wrapup — Feature Completion Wrap-Up

You are closing out a completed feature after it has been merged. This skill ensures ADLC artifacts are finalized, knowledge is captured, and the team has a clear summary of what shipped.

Ethos

!test -s .adlc/ETHOS.md && cat .adlc/ETHOS.md || echo No ethos found — run /init, or /adlc:init on the plugin install, to vendor .adlc/ETHOS.md

Context

Run this block first, with your shell tool, and read its output before you continue. Each read prints a notice instead of failing when its file is absent.

# adlc-context
echo '--- Active specs'
grep -rlx -e status:.approved -e status:.in-progress -e status:.complete --include requirement.md .adlc/specs 2>/dev/null || echo 'No specs found'
echo '--- Knowledge directory'
ls .adlc/knowledge/ 2>/dev/null || echo 'No knowledge directory'
echo '--- Current branch'
git branch --show-current 2>/dev/null || echo 'Not a git repo'
echo '--- Recent merges'
git log --oneline --merges -10 2>/dev/null || echo 'No merge history'

Input

The target is the argument: whatever follows /wrapup in the invocation (on Claude Code it can also arrive as an ARGUMENTS: line appended to this text).

It is a REQ id, optionally followed by --close-out. With no REQ id, Step 1 infers it. Strip the flag before any REQ-id parsing; its meaning is defined under Close-out mode below.

Prerequisites

Before proceeding, verify that .adlc/context/architecture.md and .adlc/context/conventions.md exist. If any of these files are missing, stop and tell the user: "The .adlc/ structure hasn't been initialized. Run /init (/adlc:init on the plugin install) first to set up the project context."

Close-out mode (--close-out)

Close-out mode exists for the actor that performed a merge it did not implement: the /sprint orchestrator after a cross-repo or fallback merge, or the workflow engine's close-out leaf (BUG-249). /proceed Step 8c's rule is "whoever performs the merge owns the Step 8b close-out", and that actor has neither the implementing session's transcript nor the authority to deploy — so running the full skill from a post-merge leaf would push, open a PR, re-merge, delete branches and deploy to every listed device. This mode runs exactly the close-out half.

What runs: Step 1 (identify), Step 3 (artifact statuses + the terminal record), Step 4 (knowledge capture, with the input rule below), Step 5 (ship summary), then the close-out commit below. What is skipped: Step 2 (the feature merge), Step 6 (deploy), Step 7 (cleanup), Step 8 (next steps). Deploy and cleanup belong to the orchestrator that invoked this mode, which reports what it did not do.

Rules:

1. Precondition — the feature PR is already merged. Before anything else, confirm every touched repo's PR reports MERGED (adlc_forge_pr_view <prUrl> --fields state,mergedAt, sourcing partials/forge.sh in the same fence). If any is not, stop with close-out refused: <repo> PR <url> is <state>, not MERGED — this mode never merges a feature PR.
2. Where it runs. In a dedicated close-out worktree the caller declares (WORKTREE PATH (mandatory): <abs> — the REQ-263 contract), on branch chore/REQ-xxx-close-out cut from origin/<integration-branch>. Never in the caller's live checkout, and never concurrently with another REQ's close-out in the same repo: the caller serializes close-outs per repo the way it serializes merges.
3. Step 3 item 5 targets the primary repo path's copy of pipeline-state.json (<repos[primary].path>/.adlc/specs/REQ-xxx-*/pipeline-state.json, the Step 8b target) — the close-out worktree has no state file (it is gitignored, per-worktree). Write all five fields, and additionally "closeOut": { "status": "ok", "at": "<ISO timestamp>" }. The caller writes "status": "failed", "reason": "<why>" to the same key if this mode exits non-zero, so /status can show a merged-but-not-closed REQ as exactly that.
4. Step 4 draws on supplied evidence, not a transcript. Transcript discovery is skipped (JSONL stays empty; the delegate is not invoked, which the resolver records as fallback/gate=fail, not a ghost-skip — the same case (b) the delegated-drafting rule already allows). The lesson is drafted from what the caller's prompt supplies: the REQ's consolidated Phase-5 findings (severity, title, fixed/not), the implementer and reviewer reports, the task list, the merged PR's file list, and pipeline-state.json (phaseHistory, blockers, conflictsResolved, lane.escalations) plus the spec's lane_escalated frontmatter, and validated with adlc_lesson_check like any other write (Step 4 Write and check). A non-empty lane.escalations, or a lane_escalated in the spec, is run evidence for the escalation lesson in Step 4 Lane escalations on its own. If the prompt supplies none of the findings or reports, and there is no escalation, write no lesson and put NO_ENTRY: close-out had no run evidence in the summary's ### Lessons captured section — a lesson invented without run evidence is worse than none.
5. Close-out commit. After Steps 3–5, in the close-out worktree: git add the spec, task files and any new ASSUME-*/LESSON-* files; commit chore(REQ-xxx): close-out — spec complete[, LESSON-nnn]; push; open a PR through adlc_forge_pr_create titled the same; merge it with adlc_forge_pr_merge <url> --squash --delete-branch and check branch_deleted (BUG-195). Lesson ids were allocated and rechecked in Step 4, so this push is collision-safe. The caller removes the close-out worktree afterwards. If the chore PR cannot be merged (policy, conflict), leave it open, report its URL, and exit non-zero so the caller records closeOut.status: failed.
6. Output. The Step 5 summary, with ### Lessons captured filled, is the mode's return value; the caller carries it into the sprint summary.

Instructions

Step 1: Identify the Feature

1. If given a REQ ID, locate all artifacts under .adlc/specs/REQ-xxx-*/
2. If no REQ ID given, infer from the current branch name or recent merge commits
3. Read the requirement spec, architecture doc, and all task files
4. Detect repository mode — read .adlc/config.yml in the primary repo. If it declares more than one entry under repos:, this is cross-repo mode; otherwise single-repo mode. In cross-repo mode also read pipeline-state.json from the spec directory — it holds the per-repo branch/worktree/PR/merge state.

Step 2: Commit, Push, and Merge

Determine the repo set to operate on:

• Single-repo mode: operate on the current repo only. Skip to the single-repo steps below.
• Cross-repo mode from `/proceed`: pipeline-state.json already lists touched repos; each repos[<id>].merged reflects whether /proceed Phase 8 already merged that PR. Walk mergeOrder and for each repo either confirm it's merged (no-op) or run the single-repo merge sequence inside that repo's worktree.
• Cross-repo mode standalone: no pipeline-state.json — fall back to detecting touched repos from the config and checking for feature branches/open PRs in each. Proceed with the single-repo merge sequence in each repo that has pending work, in merge_order from the config.

Already merged? Before the sequence below, check the branch's PR with adlc_forge_pr_view <prUrl> --fields state,mergedAt (source partials/forge.sh in the same fence). If it reports MERGED — the normal state when /proceed Phase 8 or a /sprint orchestrator merged before invoking /wrapup — skip items 1–9 and continue at item 10 (cleanup). Re-running the merge sequence against a merged PR pushes, re-creates and re-merges nothing useful and can delete branches twice. In close-out mode Step 2 is skipped entirely (see Close-out mode).

Single-repo merge sequence — run this block inside each target repo's worktree (same mechanics as before):