finishing-branch
Skill1 starsChanged 5 months agoMITView on GitHub
Use when completing development on a feature branch -- verifies quality, presents completion options, and cleans up
- Commits and pushes
2 other projects use a version of this.
Adopted by
Most recently taken up by
- krzysztofsurdy/code-virtuosotheir own version, first seen Nov 1, 2026
- wpank/aitheir own version, first seen Feb 10, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- krzysztofsurdy/code-virtuoso★ 36same name
- wpank/ai★ 11same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository30 other files it gives its agents.
- .codex/AGENTS.mdAGENTS.md
- compound-engineeringSkill
- compound-engineeringSkill
- agent-browserSkill
- agent-native-architectureSkill
- agent-native-auditSkill
- brainstormingSkill
- cavemanSkill
- compound-docsSkill
- compound-engineeringSkill
- compounding-operating-systemSkill
- compound-refreshSkill
- create-agent-skillsSkill
- document-reviewSkill
- file-todosSkill
- frontend-designSkill
- gemini-imagegenSkill
- git-worktreeSkill
- grill-meSkill
- ideateSkill
- i-have-adhdSkill
- laravel-conventionsSkill
- orchestrating-swarmsSkill
- rcloneSkill
- resolve-pr-parallelSkill
- setupSkill
- skill-creatorSkill
- systematic-debuggingSkill
- ubiquitous-languageSkill
- xml-tag-structureSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 6 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Distinctive: line 22
All implementation tasks are complete
- Distinctive: line 36
Run all quality checks and report results:
- Distinctive: line 62
If there are uncommitted changes:
- Distinctive: line 83
Verify the default branch is up to date
- Distinctive: line 89
Do not merge yet
- Distinctive: line 95
Ask the user which option they prefer.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Finishing a Development Branch
A structured skill for completing work on a feature branch. Ensures all quality checks pass, presents clear options for what to do next, and handles cleanup.
Announce at start: "I'm using the finishing-branch skill to complete this work."
When to Use
- All implementation tasks are complete
- You are ready to ship or merge a feature branch
- Referenced at the end of
workflows:workPhase 4 - Referenced by
/lfgpipeline
When NOT to Use
- Work is still in progress (finish tasks first)
- You are on the default branch (nothing to finish)
The Process
Step 1: Final Verification
Run all quality checks and report results:
# 1. Run full test suite (detect project test command)
# npm test | pytest | cargo test | phpunit | go test | etc.
# 2. Run linting (detect project linter)
# eslint | ruff | clippy | pint | etc.
# 3. Check for uncommitted changes
git status
# 4. Check for untracked files that should be committed
git ls-files --others --exclude-standardReport results clearly:
- Tests: X passed, Y failed (if any fail, stop here and fix first)
- Linting: pass/fail (if fail, fix first)
- Uncommitted changes: list them
- Untracked files: list them
Do NOT proceed if tests or linting fail. Fix issues first, then return to Step 1.
Step 2: Commit Remaining Changes
If there are uncommitted changes:
git add <relevant files>
git commit -m "feat(scope): final changes before merge
[description of what's included]"Stage files selectively -- do not blindly git add . if there are files that should not be committed.
Step 3: Present Completion Options
Present the user with clear options:
Option A: Create a Pull Request (recommended for team projects)
- Push branch and generate PR description
- Include summary of changes, testing notes, screenshots (if UI)
- Include Post-Deploy Monitoring section
Option B: Merge to default branch (for solo projects or pre-approved changes)
- Verify the default branch is up to date
- Merge the feature branch
- Push the result
Option C: Keep the branch (for work that needs more review)
- Push the branch for others to review
- Do not merge yet
Option D: Discard the branch (if work is no longer needed)
- Confirm with user (this is destructive)
- Delete the branch
Ask the user which option they prefer. Do not assume.
When invoked by an orchestrator without user interaction available: Default to Option A (Create PR). Do not stall waiting for user input -- proceed with creating the PR automatically.
Step 4: Execute the Chosen Option
Option A: Create PR
git push -u origin [branch-name]Generate a PR/MR description:
## Summary
- What was built and why
- Key decisions made
## Changes
- [List major changes with file references]
## Testing
- Tests added/modified
- Manual testing performed
## Post-Deploy Monitoring & Validation
- **What to monitor:** [logs, metrics, dashboards]
- **Expected healthy behavior:** [what success looks like]
- **Failure signals:** [what to watch for]
- **Validation window:** [how long to monitor]
## Screenshots
[If UI changes, include before/after screenshots]
---
[](https://github.com/aegntic/compound-engineering)Option B: Merge
# Update default branch
git checkout [default-branch]
git pull origin [default-branch]
# Merge feature branch
git merge [feature-branch] --no-ff -m "Merge [feature-branch]: [description]"
# Push
git push origin [default-branch]
# Clean up local branch
git branch -d [feature-branch]Option C: Keep Branch
git push -u origin [branch-name]
echo "Branch pushed. Ready for review."Option D: Discard
# Confirm with user first!
git checkout [default-branch]
git branch -D [feature-branch]
echo "Branch discarded."Step 5: Clean Up
If a git worktree was used:
# Return to main working directory
cd [main-worktree-path]
# Remove the worktree
git worktree remove [worktree-path]
# Prune worktree references
git worktree pruneUpdate plan status (if a plan file was used):
- Change
status: activetostatus: completedin the plan's YAML frontmatter - This marks the plan as done so it is not picked up by future
/workflows:worksessions
Update execution session (if STATE.md exists):
- Set
status: completedin STATE.md - Record completion timestamp
Step 6: Summary
Present a clear completion summary:
## Branch Complete: [branch-name]
- Action taken: [PR created / Merged / Kept / Discarded]
- Tests: [X passed]
- Commits: [N commits]
- Files changed: [N files]
- PR/MR: [link if created]
- Worktree: [cleaned up / N/A]
- Plan status: [updated to completed / N/A]Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

