git-issues-end

name	git-issues-end
description	Survey changes, create commits referencing their issues, push to remote, comment on each issue, and clean up agent worktrees. Use after the user has reviewed the changes from `/git-issues-start`.
user-invocable	true

After the user has reviewed changes from /git-issues-start, commit all changes with proper issue-closing references, push, comment on each issue, and clean up agent worktrees.

Phase 1: Survey the changes

1. Check working tree state:

   git status
   git diff
   git diff --stat
   

2. Fetch the open issues to map changes back to issue numbers:

   gh issue list --state open --limit 50 --json number,title
   

3. Read recent issue comments to recall what was done for each issue:

   gh issue view <NUMBER> --comments
   

   Look for the bot comments posted by /git-issues-start that document what files were changed for which issue.

4. Map each changed file to its issue(s). Build a table like:

   | File                                    | Issue(s)   |
   |-----------------------------------------|------------|
   | src/client/components/Header.jsx        | #3         |
   | src/client/components/Toolbar.jsx       | #7         |
   | src/client/services/ExportService.js    | #7         |
   | src/client/components/DetailPanel.jsx   | #12        |
   | src/fluent/seed-data.now.ts             | #12, #15   |
   

Phase 2: Decide commit strategy

Choose the best approach based on how the changes are structured:

Option A: One commit per issue (preferred when files don't overlap)

• Groups files by issue
• Each commit references its issue with Closes #N
• Clean history, easy to revert individual fixes

Option B: Grouped commits (when files overlap across issues)

• Group related issues that share files into a single commit
• Reference all related issues: Closes #18, Closes #19

Option C: Single commit (when changes are small or tightly coupled)

• One commit referencing all issues
• Simpler but harder to revert individually

Pick the best option automatically based on file overlap — no need to ask the user.

Phase 3: Create commits

For each commit, use a clear imperative summary and reference the issue(s) it closes:

<short imperative summary>

<what changed and why>

Closes #N

Co-Authored-By: Claude Sonnet 4.6 <[e-mail]>

Steps for each commit:

1. Stage only the files belonging to that commit: git add <specific files>
2. Create the commit with a HEREDOC:

   git commit -m "$(cat <<'EOF'
   Fix portfolio export button missing on mobile
   
   Wire up the export handler on small viewports — the button was
   rendered but the onClick was gated behind the desktop breakpoint.
   
   Closes #7
   
   Co-Authored-By: Claude Sonnet 4.6 <[e-mail]>
   EOF
   )"
   

3. Verify with git log -1

Phase 4: Push and comment

After all commits are created:

1. Push immediately:

   git push --follow-tags
   

   The user calling /git-issues-end means they've reviewed and approved the changes. --follow-tags carries any deploy tags along. The Closes #N references in the commits will auto-close the linked issues as soon as the push lands on the default branch.

2. Comment on each issue with the final resolution:

   gh issue comment <NUMBER> --body "Fix committed and pushed: <short commit hash>"
   

3. Show the final commit log:

   git log --oneline -<N>
   

Phase 5: Cleanup

1. List all worktrees:

   git worktree list
   

2. Remove any agent worktrees (paths matching .claude/worktrees/agent-* or similar). Use --force because the worktrees contain the uncommitted changes that were already applied to main:

   git worktree remove --force <worktree-path>
   

   Run this for each leftover agent worktree.

3. Confirm with a final git worktree list — only the main worktree should remain.

Rules

• Use Closes #N (not Fixes #N) for consistency — GitHub accepts both
• Stage specific files per commit — never use git add -A or git add .
• If a file was changed for multiple issues, put it in the commit for the primary issue
• Always push after committing — the user has already reviewed the changes
• Do NOT manually close issues with gh issue close — let the Closes #N in the commit message handle it on push
• If some changes look wrong or incomplete, flag them to the user instead of committing