/phase-done

The closing step of the issue workflow (.claude/rules/issue-workflow.md). Run it only once the issue's work is actually finished; this skill verifies and records, and it does not decide the work is done on your behalf.

Steps

1. Identify the issue being closed (the user names it, or it is the issue this branch's PR declares Closes #N for). Read it with gh issue view <n> --json title,body,comments --jq '.title, .body, (.comments[] | "--- comment ---", .body)' (--comments prints nothing for an issue without comments, issue-workflow.md §The loop), and scripts/gh/fields.sh show <n> for its type, priority and effort. A Task carries exactly one work-kind label; a Bug or a Feature carries none. Set what is missing before closing (issue-workflow.md §Type, priority and labels).
2. Verify every ## Acceptance criteria checkbox is ticked. If any remain - [ ], stop and list them. Do not tick a criterion yourself to proceed; a tick must reflect real, verified state ("the switch picks the account that expires first" means a test or a hand run showed it). Tick verified boxes in the issue body via gh issue edit <n> --body-file.
3. Relationships check (scripts/gh/rel.sh tree <n>; .claude/rules/issue-relationships.md): if the issue is a parent with open sub-issues, do NOT close it; finish or re-parent the children first. Closing this issue auto-unblocks anything it was blocking, which is expected; note any dependents that become workable so the handoff comment can point at them.
4. Design check: if the work changed how cc-shift behaves, confirm ARCHITECTURE.md says so in the same PR. A doc that describes the old behaviour is an unmet exit criterion.
5. Gate check: confirm the gates that apply actually ran and passed: the shell and workflow set (shellcheck --severity=style, actionlint, zizmor --min-severity=low .github/), every guard under scripts/checks/, the --self-test of every scripts/gh/ helper the change touched, and the full Rust set in .claude/rules/ci-cd.md. Report the results you saw, never a green you assumed.
6. Write the close narrative into the PR description: what shipped, the key decisions with their citations, the gate results, and what was deliberately left out (with follow-up issue numbers). The PR description plus the issue thread ARE the build record.
7. Post the handoff comment on the issue (gh issue comment <n>): where things stand at close, what was deliberately left out (with follow-up issue numbers), and what a follow-up session should do first.
8. Ensure the PR body declares Closes #<n> (gh pr view, gh pr edit) so the merge into main auto-closes the issue; never close the issue by hand when a PR carries the work. One Closes keyword per issue. Confirm auto-merge is armed (gh pr view --json autoMergeRequest); arm it if not, as its own command (.claude/memory/pr-auto-merge.md).
9. Roadmap-board check (.claude/rules/project-board.md): Done is set by the built-in workflow when the merge closes the issue, never by hand. After the merge, scripts/gh/project.sh show <n> should say Done; if the issue is missing from the board entirely, scripts/gh/project.sh add <n> and let the closed-to-Done workflow settle it. Do not archive or delete board items.
10. Remind the user to commit the close on the current conventional-type branch.

What this skill does not do

It does not run the build, the test suite, or the guards to "check" the acceptance criteria for you; those must already have been run and have passed before this skill is invoked. If in doubt, run the relevant command first.