finishing-a-development-branch
Use when implementation is complete, all tests pass, and the user needs to decide how to integrate the work - presents the integration candidates (merge…
Skill by transparent-pegasus
Install
Works with Claude Code, Claude apps, Codex, Cursor, Gemini CLI, GitHub Copilot, VS Code, OpenCode, Goose, Windsurf. Read the repository before you give any tool access to your data.
npx agentmarket install skill/transparent-pegasus-finishing-a-development-branch
Asks which of your tools to add it to (Claude Code, Codex, Cursor, VS Code, Windsurf, Gemini CLI, Claude Desktop) and shows the change first. See https://agentmart.dev/cli.
Get the weekly diff
The weekly diff: one email a week with new agent tools, notable updates and grade changes, plus security alerts for tools you follow. Double opt-in, one-click unsubscribe.
About
Reviews
Write a reviewNo reviews yet. Installed it? Reviews come from verified installers only. How reviews work
Permissions
What this skill can do and what it asks for, from its SKILL.md. Checked Oct 25, 2026.
- Tools
- No tools found
- Secrets
- None asked for
- Install scripts
- None found
Network hosts it talks to 1
codeload.github.com· found in install command
Files it touches
~/.claude/skills/finishing-a-development-branch
What's inside
- Skill name
finishing-a-development-branch- Description
- Use when implementation is complete, all tests pass, and the user needs to decide how to integrate the work - presents the integration candidates (merge locally, push and open a PR, push only, keep) and executes only the chosen one; never merges on its own
- License
- MIT
- Instructions
- 250 lines in SKILL.md · view on GitHub
Files (1)
- SKILL.md
SKILL.md (first lines)
# Finishing a Development Branch ## Overview **Core principle:** Verify tests → Detect environment → Present options → Execute choice → Clean up. **Announce at start:** "I'm using the finishing-a-development-branch skill to complete this work." ## Step 1: Verify Tests Run the project's full test suite (`npm test` / `cargo test` / `pytest` / `go test ./...`). **If tests fail**, report the failures and stop — the menu comes after a green suite: ``` Tests failing (<N> failures). Must fix before completing: [Show failures] ``` **If tests pass:** continue to Step 2. ## Step 2: Detect Environment ```bash GIT_DIR=$(cd "$(git rev-parse --git-dir)" 2>/dev/null && pwd -P) GIT_COMMON=$(cd "$(git rev-parse --git-common-dir)" 2>/dev/null && pwd -P) # Capture now, while still inside the workspace — Step 5 changes directory # before cleanup (Step 6) needs this value WORKTREE_PATH=$(git rev-parse --show-toplevel) ``` This determines which menu to show and how cleanup works: | State | Menu | Cleanup | |-------|------|---------| | `GIT_DIR == GIT_COMMON` (normal repo) | Standard 4 options | No worktree to clean up | | `GIT_DIR != GIT_COMMON`, named branch | Standard 4 options | Provenance-based (see Step 6) | | `GIT_DIR != GIT_COMMON`, detached HEAD | Reduced 3 options (no local merge) | Externally managed — leave in place | ## Step 3: Determine Base Branch `<BASE_BRANCH>` comes from the repository's `Herdrpowers Configuration` section. When it is declared, merge and PR targets are that branch — do not silently retarget `main` because it exists. Without a declared value, the base branch is whatever this work forked from — usually named in the plan, the conversation, or the branch's upstream. If it is not already known, ask: "This branch split from `<your best guess>` - is that correct?" Confirm before merging: merging into the wrong base is expensive to undo. ## Step 4: Present Options **Normal repo and named-branch worktree — present exactly these 4 options:** ``` Implementation complete. What would you like to do? 1. Merge back to <base-branch> locally 2. Push to origin and create a Pull Request 3. Push to origin only (no PR) 4. Keep the branch as-is (I'll handle it later) Which option? ``` **Detached HEAD — present exactly these 3 options:** ``` Implementation complete. You're on a detached HEAD (externally managed workspace). 1. Push as a new branch and create a Pull Request 2. Push as a new branch only (no PR) 3. Keep as-is (I'll handle it later) Which option? ``` Present the menu exactly as written — concise, with every option coming from the list above. Discarding the work happens only in response to the user explicitly asking for it (see "If the user asks to discard the work" below). **Present, don't presume.** Merging is one candidate among several, not the default ending. Never merge, push, or delete anything before the user names the option — and when they do, execute that option only. ## Step 5: Execute Choice ### Option 1: Merge Locally ```bash # Get main repo root for CWD safety MAIN_ROOT=$(git -C "$(git rev-parse --git-common-dir)/.." rev-parse --show-toplevel) cd "$MAIN_ROOT" # Scope check — this tree should be clean; anything here was written by mistake git status --short # Merge first — verify success before removing anything git checkout <base-branch> git pull git merge <feature-branch> # Verify tests on merged result <test command> ``` **Every unexpected modification in that `git status --short` is a scope violation, not noise.** A delegated pane whose task named a dedicated worktree has edited the main checkout instead, and it surfaced only because `git merge` refused with "Please commit your changes or stash them" — by which point the stray edit was one `git stash` away from riding into the merge commit unreviewed. Do not commit it, do not discard it: save it (`git diff > <REPORT_DIRECTORY>/stray-<task>.patch`), restore the file, finish the merge, and surface the patch to the user as its own decision. If tests fail on the merged result: stop, leave the worktree and branch in place, and investigate — nothing has been pushed, so the merge is local and recoverable.
From transparent-pegasus/herdrpowers, MIT.
More from transparent-pegasus/herdrpowers
- 0.639score
executing-plans
transparent-pegasus
Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution, or no herdr sibling…
SkillAFreshness: A★ 12Claude Code +9 - 0.639score
using-herdr-sibling-panes
transparent-pegasus
Use when inside herdr (HERDR_ENV=1), the current pane is acting as the orchestrator for the task, and idle sibling agent panes can take delegated work —…
SkillAFreshness: A★ 12Claude Code +9 - 0.633score
herdr
transparent-pegasus
Use when the user explicitly requests Herdr pane, tab, workspace, or agent operations from an existing Herdr session.
SkillAFreshness: A★ 12Claude Code +9 - 0.630score
orchestration
transparent-pegasus
Route every task received directly from the user through the pane that received it (the orchestrator) in herdr unless the user explicitly denies orchestration.
SkillAFreshness: A★ 12Claude Code +9 - 0.611score
brainstorming
transparent-pegasus
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior.
SkillAFreshness: A★ 12Claude Code +9 - 0.608score
requesting-code-review
transparent-pegasus
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
SkillAFreshness: A★ 12Claude Code +9 - 0.608score
systematic-debugging
transparent-pegasus
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
SkillAFreshness: A★ 12Claude Code +9 - 0.608score
writing-plans
transparent-pegasus
Use when you have a spec or requirements for a multi-step task, before touching code
SkillAFreshness: A★ 12Claude Code +9 - 0.604score
pane-driven-development
transparent-pegasus
Use when executing implementation plans with independent tasks by delegating each task to a fresh herdr sibling pane
SkillAFreshness: A★ 12Claude Code +9 - 0.544score
update-docs
transparent-pegasus
Use when code, config, prompt, schema, or task changes require updating Markdown files directly under docs/, such as architecture, structure, config-sync…
SkillCFreshness: C★ 12Claude Code +9 - 0.519score
receiving-code-review
transparent-pegasus
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires…
SkillCFreshness: C★ 12Claude Code +9
Signals
- Stars
- 12
- Forks
- 0
- Open issues
- 1
- Last commit (this folder)
- Aug 13, 2026 (2 months ago)
From GitHub (fetched Oct 24, 2026).
Details
- License
- MIT
- First seen
- Oct 24, 2026
- Last checked
- Oct 24, 2026
- Source
- GitHubgithub-graphql
More from transparent-pegasus
- 0.639score
executing-plans
transparent-pegasus
Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution, or no herdr sibling…
SkillAFreshness: A★ 12Claude Code +9 - 0.639score
using-herdr-sibling-panes
transparent-pegasus
Use when inside herdr (HERDR_ENV=1), the current pane is acting as the orchestrator for the task, and idle sibling agent panes can take delegated work —…
SkillAFreshness: A★ 12Claude Code +9 - 0.633score
herdr
transparent-pegasus
Use when the user explicitly requests Herdr pane, tab, workspace, or agent operations from an existing Herdr session.
SkillAFreshness: A★ 12Claude Code +9 - 0.630score
orchestration
transparent-pegasus
Route every task received directly from the user through the pane that received it (the orchestrator) in herdr unless the user explicitly denies orchestration.
SkillAFreshness: A★ 12Claude Code +9 - 0.611score
brainstorming
transparent-pegasus
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior.
SkillAFreshness: A★ 12Claude Code +9 - 0.608score
requesting-code-review
transparent-pegasus
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
SkillAFreshness: A★ 12Claude Code +9
Cite this page
finishing-a-development-branch skill. Agent Mart. https://agentmart.dev/skills/transparent-pegasus-finishing-a-development-branch (last updated 2026-10-24)