brainstorming
Collaborative design exploration that refines ideas into validated specs through iterative questioning. Use before any creative work including creating…
Git branch completion workflow. Use when implementation is complete, tests pass, and a feature branch needs to be integrated via merge, pull request, or cleanup.
$ npx -y skills add izyanrajwani/agent-skills-library --skill finishing-a-development-branch --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/finishing-a-development-branchContext preview
The summary Claude sees to decide when to auto-load this skill.
Git branch completion workflow. Use when implementation is complete, tests pass, and a feature branch needs to be integrated via merge, pull request, or cleanup.
name: finishing-a-development-branch description: Git branch completion workflow. Use when implementation is complete, tests pass, and a feature branch needs to be integrated via merge, pull request, or cleanup.
Determine test runner from project structure:
Run tests. If any fail, report `⊘ BLOCKED:TESTS` with failure count and stop. Do not proceed to Step 2.
Find the branch this feature diverged from:
# Check which branch has the closest merge-base
for candidate in main master develop; do
if git rev-parse --verify "$candidate" >/dev/null 2>&1; then
MERGE_BASE=$(git merge-base HEAD "$candidate" 2>/dev/null)
if [ -n "$MERGE_BASE" ]; then
echo "Candidate: $candidate (merge-base: $MERGE_BASE)"
fi
fi
doneSelect the candidate with the most recent merge-base (closest ancestor). If multiple branches share the same merge-base or detection is ambiguous, ask: "This branch could target `main` or `develop`. Which should it merge into?"
**Store the result** - subsequent steps reference `<base-branch>` meaning this determined value.
Present exactly these 4 options:
Implementation complete. 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?
git checkout <base-branch> git pull git merge <feature-branch>
**If merge conflicts:**
⊘ BLOCKED:CONFLICTS Merge conflicts in: - <conflicted files> Cannot auto-resolve. User must: 1. Resolve conflicts manually 2. Run tests 3. Re-run this workflow
Stop. Do not proceed.
**If merge succeeds:**
# Verify tests on merged result <test command> # If tests pass, delete feature branch git branch -d <feature-branch>
Then: Cleanup worktree (Step 5). Report `✓ MERGED`.
**Verify `gh` CLI is available:**
if ! command -v gh &>/dev/null; then echo "gh CLI not installed. Install from https://cli.github.com/ or push manually and create PR via web." exit 1 fi gh auth status || echo "gh not authenticated. Run: gh auth login"
Extract title from first commit on branch (original intent):
MERGE_BASE=$(git merge-base HEAD <base-branch>) TITLE=$(git log --reverse --format=%s "$MERGE_BASE"..HEAD | head -1) git push -u origin <feature-branch> gh pr create --title "$TITLE" --body "$(cat <<'EOF' ## Summary <2-3 bullets of what changed> ## Test Plan - [ ] <verification steps> EOF )"
Report `✓ PR_CREATED` with PR URL. **Keep worktree intact** for continued work during review.
Report `✓ PRESERVED` with branch name and worktree path.
**Do not cleanup worktree.**
**Confirm first:**
This will permanently delete: - Branch <name> - All commits: <commit-list> - Worktree at <path> Type 'discard' to confirm.
Wait for exact confirmation. If not received, abort.
If confirmed:
git checkout <base-branch> git branch -D <feature-branch>
Then: Cleanup worktree (Step 5). Report `✓ DISCARDED`.
**For Options 1 and 4 only:**
# Check if currently in a worktree (not main repo) if [ "$(git rev-parse --git-common-dir)" != "$(git rev-parse --git-dir)" ]; then # Get worktree root (handles invocation from subdirectory) WORKTREE_ROOT=$(git rev-parse --show-toplevel) cd "$(git rev-parse --git-common-dir)/.." git worktree remove "$WORKTREE_ROOT" fi
**For Options 2 and 3:** Keep worktree intact.
| Option | Merge | Push | Keep Worktree | Cleanup Branch | |--------|-------|------|---------------|----------------| | 1. Merge locally | ✓ | - | - | ✓ | | 2. Create PR | - | ✓ | ✓ | - | | 3. Keep as-is | - | - | ✓ | - | | 4. Discard | - | - | - | ✓ (force) |
On completion, report exactly one:
| State | Output | Meaning | |-------|--------|---------| | `✓ MERGED` | Branch merged to `<base>`, worktree cleaned | Option 1 success | | `✓ PR_CREATED` | PR #N at URL | Option 2 success | | `✓ PRESERVED` | Branch kept at path | Option 3 success | | `✓ DISCARDED` | Branch deleted, worktree cleaned | Option 4 success | | `⊘ BLOCKED:TESTS` | N test failures | Cannot proceed | | `⊘ BLOCKED:CONFLICTS` | Merge conflict in files | Cannot proceed |
**Blocking conditions (stop immediately):**
**Mandatory confirmations:**
**Cleanup rules:**
**Never:**
**Called by:**
**Pairs with:**
🛠️ Enhance programming workflows with a curated library of agent skills for tasks like code review, debugging, and planning for efficient project execution.
Repo: izyanrajwani/agent-skills-library
Collaborative design exploration that refines ideas into validated specs through iterative questioning. Use before any creative work including creating…
Dispatches one subagent per independent domain to parallelize investigation/fixes. Use when you have 2+ unrelated failures (e.g., separate failing test files,…
Disciplined plan execution for implementation tasks. Use when executing a saved implementation plan, following step-by-step instructions from a plan document.
Assesses and responds to incoming code review feedback on PRs (reviewer comments, requested changes), especially when suggestions are unclear, technically…
Use when you need to request a code review for a PR/MR and want a consistent review brief (context, scope, risk areas, test instructions, acceptance criteria)…
Sequential subagent execution with two-stage review gates for implementation plans. Use when executing multi-task plans in current session, when tasks need…