Use when implementation is complete, all tests pass, and you need to decide how to integrate the work. Guides completion of development work by verifying tests, presenting structured options (merge, PR, keep, discard), executing the choice, and cleaning up worktrees.
From casaflownpx claudepluginhub casaperks/casaflow --plugin casaflowThis skill uses the workspace's default tool permissions.
Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
Enables AI agents to execute x402 payments with per-task budgets, spending controls, and non-custodial wallets via MCP tools. Use when agents pay for APIs, services, or other agents.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
PURPOSE: Guide the completion of development work through a structured decision flow: verify tests pass, present clear integration options, execute the chosen option, and clean up.
GIT HOST: PR creation in Option 2 uses GitHub (gh) as the default. If git-host in jig.config.md is not github, read framework/GIT_HOST.md for the platform-specific command equivalents.
Core principle: Verify tests -> Present options -> Execute choice -> Clean up.
Announce at start: "I'm using the finish skill to complete this work."
Invoke this skill when:
sdd or team-dev reaches the end of executionDo NOT use when:
Before presenting options, verify tests pass.
Run the project's test suite:
<project-test-command>
REQUIRED: Use verify -- run the actual command, read the output, confirm zero failures before proceeding.
If tests fail:
Tests failing (N failures). Must fix before completing:
[Show failures]
Cannot proceed with merge/PR until tests pass.
Stop. Do not proceed to Step 2. Fix the failures first.
If tests pass: Continue to Step 2.
Read main-branch from jig.config.md (default: main).
git merge-base HEAD <main-branch>
Or ask: "This branch split from <main-branch> -- is that correct?"
Present exactly these 4 options:
Implementation complete. All tests pass. What would you like to do?
1. Merge back to <base-branch> locally
2. Push and create a Pull Request
3. Keep the branch as-is (I'll handle it later)
4. Discard this work
Which option?
Do not add explanation -- keep options concise. Wait for the user's choice.
# Switch to base branch
git checkout <base-branch>
# Pull latest
git pull
# Merge feature branch
git merge <feature-branch>
# Verify tests on merged result
<test-command>
# If tests pass, delete the feature branch
git branch -d <feature-branch>
If merge conflicts occur:
If tests fail after merge:
Then: Cleanup worktree (Step 5)
# Push branch
git push -u origin <feature-branch>
Then create the PR. Read jig.config.md for:
require-ticket-reference -- whether to include ticket referenceticket-system -- which system to referencebranching.format -- to extract ticket number from branch name# Create PR with structured description
gh pr create --title "<title>" --body "$(cat <<'EOF'
## Summary
<2-3 bullets of what changed>
## Test Plan
- [ ] <verification steps>
EOF
)"
If the project has the pr-create skill, defer to it for PR creation.
Then: Cleanup worktree (Step 5)
Report:
Keeping branch <name>. Worktree preserved at <path>.
Do not clean up the worktree.
Confirm first:
This will permanently delete:
- Branch: <name>
- All commits: <commit-list>
- Worktree at <path> (if applicable)
Type 'discard' to confirm.
Wait for exact confirmation. Do not proceed without it.
If confirmed:
git checkout <base-branch>
git branch -D <feature-branch>
Then: Cleanup worktree (Step 5)
For Options 1, 2, and 4:
Check if working in a worktree:
git worktree list
If the current directory is a worktree (not the main working tree):
# Navigate out of the worktree first
cd <main-working-tree-path>
# Remove the worktree
git worktree remove <worktree-path>
If the project uses a worktree management command (check jig.config.md or project scripts), use that instead.
For Option 3: Keep the worktree intact.
| Option | Merge | Push | Keep Worktree | Cleanup Branch |
|---|---|---|---|---|
| 1. Merge locally | Yes | No | No | Yes (soft delete) |
| 2. Create PR | No | Yes | Yes (for PR updates) | No |
| 3. Keep as-is | No | No | Yes | No |
| 4. Discard | No | No | No | Yes (force delete) |
| Mistake | Consequence | Fix |
|---|---|---|
| Skipping test verification | Merge broken code, create failing PR | Always verify tests before offering options |
| Open-ended questions | "What should I do next?" is ambiguous | Present exactly 4 structured options |
| Automatic worktree cleanup | Remove worktree when user might need it | Only cleanup for Options 1 and 4 |
| No confirmation for discard | Accidentally delete work | Require typed "discard" confirmation |
| Merging without pulling latest | Merge conflicts discovered after merge | Always pull latest before merging |
| Not running tests after merge | Merge introduced regressions | Test the merged result before deleting branch |
Never:
Always:
Called by:
sdd (terminal state) -- after all tasks complete and final review passesteam-dev (terminal state) -- after all tasks complete and integration review passesRelated skills:
verify -- used in Step 1 to verify tests passpr-create -- can be used in Option 2 for more structured PR creationreview -- should have been completed before reaching this skillAfter the chosen option is executed and cleanup is done, suggest:
"Work complete. If this was a feature or complex improvement, consider running
/postmortemto capture lessons learned."
Do not auto-invoke the postmortem -- just suggest it.