mcpbeat Sign in

Finishing A Development Branch Agent Skill

Use when verified work has an Aegis-created branch/worktree to integrate or clean up, or the user explicitly requests merge, PR, or branch lifecycle handling.

1k tokens
context cost
the whole folder, loaded on every use
1
files
instructions only
0
copies elsewhere
how many repositories repackaged it
894
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/GanyuanRan/Aegis --skill finishing-a-development-branch

The instruction itself

14 sections, as written by the author

Finishing a Development Branch

Overview

Integration choice and checkout lifetime are separate. Verify first, mutate only

task-owned resources, then prove what was removed or retained.

Core principle: fresh evidence -> authorized integration -> ownership-aware

cleanup -> Git/path readback.

Announce at start: explain which branch/worktree lifecycle is being closed.

Step 1: Environment and Ownership Detection

Read the task's TaskStartSnapshot and current repository state. Record:

  • root, HEAD, branch/detached state, upstream divergence, and active Git ops;
  • staged/unstaged/untracked paths and the task-owned delta;
  • git worktree list --porcelain;
  • branch/worktree creator, task ownership, base branch, and cleanup trigger.

Stop on conflicts, detached state, failed verification, dirty/untracked state in

a cleanup target, or unknown ownership. Do not infer the base from the names

main or master; use task records, repository authority, or explicit user

direction. Never auto-stash, reset, clean, pull, rebase, amend, force-push, or

bypass hooks.

If no task-created branch/worktree exists and integration was not requested,

skip this workflow: report the local task commit plus Task clean and

Repository clean; do not invent merge/PR ceremony.

Step 2: Fresh Verification

Run the smallest current-authority test set that proves the completed task. If

it fails, preserve all work and return to diagnosis. Do not present the branch

as ready.

Step 3: Choose the Authorized Outcome

When a task branch actually needs disposition, present only applicable choices:

  • merge into the recorded base locally;
  • push and create/update a PR;
  • keep the branch for later integration;
  • discard the exact task-owned branch/worktree.

Push, PR, remote deletion, release, and force operations require explicit user

authorization. Discard requires a fresh, exact typed confirmation naming branch,

worktree path, and commits/delta to lose. Generic agreement is insufficient.

Step 4: Execute Without Hidden Mutation

Local merge

Verify the target checkout is safe, switch to the recorded base, merge without an implicit pull,

and rerun verification on the merged result. If integration

or verification fails, preserve both histories and stop.

Push or PR

Push only the authorized task branch and create/update the PR with summary and

fresh test evidence. PR creation does not itself prove merge and does not

require the temporary worktree to remain.

Keep branch

Retain the branch. Remove a clean task-created temporary worktree by default;

retain it only for an explicit ongoing-checkout need and report why.

Discard

After exact confirmation, remove only the named clean task-owned worktree, then

the named branch. If either differs from the confirmation, stop and ask again.

Step 5: Prove Integration Before Branch Deletion

Use evidence matching the merge strategy:

  • merge/fast-forward: prove the task tip is an ancestor of the recorded base;
  • squash/rebase: use fresh PR merge metadata plus strategy-appropriate patch

equivalence (git cherry for rebased commits; stable patch-id or bounded

changed-path/tree comparison for squashes), not an ancestor-only test;

  • unmerged/open PR: keep the branch unless discard was exactly confirmed.

Never delete a branch merely because a PR was opened or a similarly named

commit exists.

Step 6: Cleanup in Dependency Order

For a clean task-owned resource:

  • move to another safe registered checkout; never remove the current working directory;
  • remove/unregister the worktree first with git worktree remove <exact-path>;
  • read back git worktree list --porcelain;
  • verify the exact path no longer exists;
  • only then delete an integrated or exactly confirmed branch;
  • read back branch refs, HEAD, and repository status.

Do not use routine --force, global git worktree prune, wildcard deletion, or

cleanup of resources absent from the task ownership record. On Windows, Git may

unregister a worktree while its directory remains locked: re-check registration

and the exact resolved path, remove only a proven task-owned clean residual when

safe, otherwise retain it and report the lock/path. Never widen deletion scope.

Final Git Receipt

Report:

  • current branch and commit SHA/message, or the reason no commit exists;
  • Task clean: yes|no and Repository clean: yes|no independently;
  • branch/worktree created, removed, or retained, with evidence/reason;
  • integration evidence and any remaining user action.

Task clean means no uncommitted task-owned delta remains. Repository clean

means no staged, unstaged, or untracked repository state remains.

This is a local Git receipt, not authoritative completion or merge truth beyond

the evidence read back.

Integration

Called only when branch/worktree integration or explicit lifecycle handling is

in scope. Pairs with using-git-worktrees and

verification-before-completion.

Other skills for the same job

different authors, same section of the catalogue
MCP Builder
by anthropics
vendor ×13

Guide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate external APIs or services, whether in Python (FastMCP) or Node/TypeScript (MCP SDK).

30k tokens scripts
Changelog Generator
by frostant
×9

Automatically creates user-facing changelogs from git commits by analyzing commit history, categorizing changes, and transforming technical commits into clear, customer-friendly release notes. Turns hours of manual changelog writing into minutes of automated generation.

774 tokens
Finishing A Development Branch
by ZhanlinCui
×7

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup

1k tokens
MCP Builder
by JayZeeDesign
×7

Guide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate external APIs or services, whether in Python (FastMCP) or Node/TypeScript (MCP SDK).

37k tokens scripts
Vercel React Native Skills
by vercel-labs
vendor ×6

React Native and Expo best practices for building performant mobile apps. Use when building React Native components, optimizing list performance, implementing animations, or working with native modules. Triggers on tasks involving React Native, Expo, mobile performance, or native platform APIs.

39k tokens
Vercel React Best Practices
by ratacat
×5

React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.

34k tokens
Next Best Practices
by vercel-labs
vendor ×4

Next.js best practices - file conventions, RSC boundaries, data patterns, async APIs, metadata, error handling, route handlers, image/font optimization, bundling

20k tokens
Using Git Worktrees
by ZhanlinCui
×4

Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification

1k tokens

How to use it

Copy the folder

Take ganyuanran/finishing-a-development-branch from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.