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 krzysztofsurdy/code-virtuoso --skill finishing-branchgit clone --depth 1 https://github.com/krzysztofsurdy/code-virtuosoWrote 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/krzysztofsurdy/code-virtuoso/finishing-branch)<a href="https://agentmods.dev/skills/krzysztofsurdy/code-virtuoso/finishing-branch"><img src="https://agentmods.dev/badge/skills/krzysztofsurdy/code-virtuoso/finishing-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/krzysztofsurdy/code-virtuoso/finishing-branch"><img src="https://agentmods.dev/badge/skills/krzysztofsurdy/code-virtuoso/finishing-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.00148 | $0.02846 |
| Opus 5 | $0.00074 | $0.01423 |
| Sonnet 5 | $0.00030 | $0.00569 |
| Haiku 4.5 | $0.00015 | $0.00285 |
Grade B, and why
finishing-branch scanned grade B with 2 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 11d 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.
Strips warnings and disclaimersmediumAnti-refusal
Omitting safety caveats hides risk from the user and is a common jailbreak preamble.
- [ ] Build completes without warnings Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
# Using Bitbucket's REST API via curl How it starts
The opening of the file, as written. The whole thing — 327 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Finishing a Development Branch
The code is written. Tests are green locally. Now what? The gap between "done coding" and "merged to main" is where branches rot, conflicts accumulate, and mistakes happen. This playbook is the systematic bridge: verify, review, integrate, clean up. Every time, in order, nothing skipped.
Never push without green. Never merge without review evidence.
When to Use
- Implementation is complete and you are ready to integrate
- You need to decide between merge, squash, rebase, or PR
- A branch has been sitting and needs to be wrapped up
- You are finishing work in a worktree and need to clean up
- You are managing stacked branches and need to land them in order
Quick Start
# Verify everything passes
git diff --stat main...HEAD
make test && make lint && make typecheck
# Push and open a PR (adjust target as needed)
git push -u origin HEAD
gh pr create --fill
If you need more control, follow the phases below.
Phase 1: Working-Tree Sanity
Before anything else, ensure the working tree is in a known-good state.
# Check for uncommitted changes
git status
# Check for forgotten stashes
git stash list
# Ensure you are on the right branch
git branch --show-current
# Verify upstream tracking is set
git rev-parse --abbrev-ref --symbolic-full-name @{u}
| Check | Pass Condition | Fix |
|---|---|---|
| No uncommitted changes | git status shows clean tree |
Commit or stash intentionally |
| No orphaned stashes | git stash list is empty or all stashes are accounted for |
Apply or drop stale stashes |
| Correct branch | Branch name matches your work | git checkout <branch> |
| Upstream set | Tracking branch exists | git push -u origin HEAD on first push |
| No untracked noise | No generated files, build artifacts, or editor files | Add to .gitignore or remove |
Phase 2: Pre-Push Verification
Run the full verification suite before pushing. Order matters - fail fast on the cheapest checks first.
What ships with it
5 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 11d ago First seen · 327 lines · 148 tokens per session scan B ee032790cb39
finishing-branch is a skill published in the GitHub repository krzysztofsurdy/code-virtuoso (21 stars, last pushed 3mo ago), licensed MIT. It adds 148 tokens to every session and 2,846 once invoked, about $0.0007 per session on Opus 5. A static security scan graded it B with 2 findings (strips warnings and disclaimers, makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
code-history
Trace the git history of specific code — when a function, pattern, or file was added, modified, or removed, and the intent behind each change. Use when the user asks when or why a piece of code changed, wants the evolution of a function, or needs the commit or PR that introduced a behavior. Read-only; not for plain…
quick-pr
Split a minor change from the current work into a separate worktree and open a PR without interrupting your flow. Use when an unrelated small fix (typo, lint rule, config tweak) is sitting in a feature branch and the user wants it shipped on its own — "quick PR", "split this out", "ship this separately". Requires…
openclaw-parallels-smoke
End-to-end Parallels smoke, upgrade, and rerun workflow for OpenClaw across macOS, Windows, and Linux guests. Use when Codex needs to run, rerun, debug, or interpret VM-based install, onboarding, gateway smoke tests, latest-release-to-main upgrade checks, fresh snapshot retests, or optional Discord roundtrip…
openclaw-ghsa-maintainer
Maintainer workflow for OpenClaw GitHub Security Advisories (GHSA). Use when Codex needs to inspect, patch, validate, or publish a repo advisory, verify private-fork state, prepare advisory Markdown or JSON payloads safely, handle GHSA API-specific publish constraints, or confirm advisory publish success.
openclaw-release-maintainer
Maintainer workflow for OpenClaw releases, prereleases, changelog release notes, and publish validation. Use when Codex needs to prepare or verify stable or beta release steps, align version naming, assemble release notes, check release auth requirements, or validate publish-time commands and artifacts.
write-pr
Draft a pull request title and body from the current branch's diff and commit history, following the project's PR template and title conventions. Use when the user is about to open a PR and wants ready-to-paste content, or asks to write, draft, or fill in a PR description. Read-only — never opens or pushes the PR.