Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add Pixel-Process-UG/superkit-agents --skill finishing-a-development-branchgit clone --depth 1 https://github.com/Pixel-Process-UG/superkit-agentsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/pixel-process-ug/superkit-agents/finishing-a-development-branch)<a href="https://agentmods.dev/skills/pixel-process-ug/superkit-agents/finishing-a-development-branch"><img src="https://agentmods.dev/badge/skills/pixel-process-ug/superkit-agents/finishing-a-development-branch/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/pixel-process-ug/superkit-agents/finishing-a-development-branch"><img src="https://agentmods.dev/badge/skills/pixel-process-ug/superkit-agents/finishing-a-development-branch.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00060 | $0.01950 |
| Opus 5.5 | $0.00024 | $0.00780 |
| Sonnet 5.5 | $0.00012 | $0.00390 |
| Haiku 4.5 | $0.00006 | $0.00195 |
Grade A, and why
finishing-a-development-branch scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 264 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Finishing a Development Branch
Overview
Provide a structured, safe process for completing work on a development branch, including verification, merge strategy selection, and cleanup. This skill ensures no branch is merged without passing tests, and every destructive operation requires explicit user confirmation.
When to Use
- All planned work on a feature branch is complete
- A branch is ready for code review or merge
- Cleaning up after development work is finished
- Preparing a pull request for team review
Phase 1: Verify All Tests Pass
[HARD-GATE] Do NOT proceed to any merge or PR activity without passing verification.
Before any merge or PR activity, invoke verification-before-completion to confirm:
- All tests pass (unit, integration, e2e as applicable)
- No lint errors or warnings
- Build succeeds
- No untracked files that should be committed
# Run the project's full verification suite
# Do NOT skip this step even if "tests were passing earlier"
If verification fails, STOP. Fix the failures before proceeding. Do NOT create PRs or merge branches with failing tests.
STOP — Verification must pass before continuing to Phase 2.
Phase 2: Determine Base Branch
Identify the branch to merge into, using this detection logic:
Auto-Detection
# Check for common base branch names
git branch -a | grep -E 'remotes/origin/(main|master|develop)$'
# Check what branch was the fork point
git log --oneline --decorate --graph HEAD...main --first-parent 2>/dev/null
git log --oneline --decorate --graph HEAD...master --first-parent 2>/dev/null
Base Branch Selection Decision Table
| Condition | Base Branch | Confidence |
|---|---|---|
main exists |
main |
High |
Only master exists |
master |
High |
develop exists and project uses GitFlow |
develop |
Medium |
| Multiple candidates found | Ask user | Required |
| None of the above exist | Ask user | Required |
Verify Base Branch is Up to Date
git fetch origin
git log HEAD..<base-branch> --oneline
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 264 lines · 60 tokens per session scan A 493763634e55
finishing-a-development-branch is a skill published in the GitHub repository Pixel-Process-UG/superkit-agents (3 stars, last pushed 7mo ago), licensed MIT. It adds 60 tokens to every session and 1,950 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
git-workflow-and-versioning
Structures git workflow practices. Use when making any code change. Use when committing, branching, resolving conflicts, splitting uncommitted work in a messy working tree into clean atomic commits, opening or reviewing a pull request (PR), pushing to a remote, or when you need to organize work across multiple…
finishing-a-development-branch
A process for finishing a completed development branch. A branch is a separate line of code changes that can later be merged or submitted as a pull request.
shipping-and-launch
A production-release checklist and planning guide for putting software in front of real users. It covers testing, security, monitoring, staged rollout, and rollback, which means returning to the previous working version.
release-checks
Portable release checklist skill for the Cursor packaged example.
obsidian-ops
Operations, syncing, versioning, and release management for Obsidian projects. Load when running builds, syncing references, bumping versions, or preparing for release.
shipping-and-launch
Prepares production launches. Use when preparing to deploy to production. Use when you need a pre-launch checklist, when setting up monitoring, when planning a staged rollout, or when you need a rollback strategy.