agentsclimarketplace

Finishing a development branch

Skill bg-szy/TOP-SKILLS/skills/marketplace/finishing-a-development-branch

全球最大的 Claude Code 技能聚合库 · 收录 3900+ 来自 12+ 来源的技能,提供在线搜索与趋势分析看板 / The world's largest Claude Code skill aggregation hub — 3900+ skills from 12+ sources with online search and trend dashboard

Install
npx -y skills add bg-szy/TOP-SKILLS --skill finishing-a-development-branch

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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.

SKILL.md

5.4 KB, ~1.4k tokens by cl100k_base, as published. Nobody here has run it

Finishing a Development Branch

The Process

Step 1: Verify Tests

Determine test runner from project structure:

  • package.jsonnpm test or yarn test
  • Cargo.tomlcargo test
  • pyproject.toml / setup.pypytest
  • go.modgo test ./...
  • Makefile with test target → make test

Run tests. If any fail, report ⊘ BLOCKED:TESTS with failure count and stop. Do not proceed to Step 2.

Step 2: Determine Base Branch

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
done

Select 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.

Step 3: Present Options

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?

Step 4: Execute Choice

Option 1: Merge Locally

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.

Option 2: Push and Create PR

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.

Option 3: Keep As-Is

Report ✓ PRESERVED with branch name and worktree path.

Do not cleanup worktree.

Option 4: Discard

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.

Step 5: Cleanup Worktree

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.

Quick Reference

OptionMergePushKeep WorktreeCleanup Branch
1. Merge locally--
2. Create PR--
3. Keep as-is---
4. Discard---✓ (force)

Terminal States

On completion, report exactly one:

StateOutputMeaning
✓ MERGEDBranch merged to <base>, worktree cleanedOption 1 success
✓ PR_CREATEDPR #N at URLOption 2 success
✓ PRESERVEDBranch kept at pathOption 3 success
✓ DISCARDEDBranch deleted, worktree cleanedOption 4 success
⊘ BLOCKED:TESTSN test failuresCannot proceed
⊘ BLOCKED:CONFLICTSMerge conflict in filesCannot proceed

Guardrails

Blocking conditions (stop immediately):

  • Tests failing → ⊘ BLOCKED:TESTS
  • Merge conflicts → ⊘ BLOCKED:CONFLICTS

Mandatory confirmations:

  • Option 4 (Discard): Require typed "discard" confirmation

Cleanup rules:

  • Options 1, 4: Clean up worktree and branch
  • Options 2, 3: Preserve worktree

Never:

  • Proceed with failing tests
  • Merge without verifying tests on result
  • Delete work without typed confirmation
  • Force-push without explicit request

Integration

Called by:

  • subagent-driven-development (Step 7) - After all tasks complete
  • executing-plans (Step 5) - After all batches complete

Pairs with:

  • using-git-worktrees - Cleans up worktree created by that skill

Gives 1 of the 12 instructions most pr commit review skills give in ~1.4k tokens

Counted across 888 of the 1,342 authors here whose files we hold, read 2026-08-06

  • use conventional commits formatin 123 of 888, across 110 files
  • keep subject line under 72 charactersin 60 of 888, across 46 files
  • delete branches after mergein 50 of 888, across 37 files
  • use imperative mood in subject linein 50 of 888, across 41 files
  • use imperative mood in commit messagesin 45 of 888
  • generate a conventional commit messagein 42 of 888
  • make atomic commitsin 37 of 888, across 25 files
  • run tests before committinghere, and in 36 of 888, across 24 files
  • run project test suite to verify clean baselinein 35 of 888, across 7 files
  • run detected project setup commandsin 34 of 888, across 6 files
  • wrap commit body at 72 charactersin 32 of 888, across 25 files
  • split unrelated changes into separate commitsin 32 of 888, across 27 files

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.