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 bostonaholic/rpikit --skill finishing-workgit clone --depth 1 https://github.com/bostonaholic/rpikitWrote 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/bostonaholic/rpikit/finishing-work)<a href="https://agentmods.dev/skills/bostonaholic/rpikit/finishing-work"><img src="https://agentmods.dev/badge/skills/bostonaholic/rpikit/finishing-work/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/bostonaholic/rpikit/finishing-work"><img src="https://agentmods.dev/badge/skills/bostonaholic/rpikit/finishing-work.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to high
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- high Tool Misuse · line 200 Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).Fix: Validate all tool parameters against an allowlist. Reject dangerous parameter values (shell=True, --force, -rf /) and use safe defaults.
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.00042 | $0.01506 |
| Opus 5 | $0.00021 | $0.00753 |
| Sonnet 5 | $0.00008 | $0.00301 |
| Haiku 4.5 | $0.00004 | $0.00151 |
Grade A, and why
finishing-work 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 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.
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 — 281 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Finishing Work
Verify tests, present options, execute chosen workflow, clean up.
Purpose
Implementation without proper completion leaves work in limbo. This skill provides structured options for finishing work: merge locally, create PR, defer for later, or discard. Each option has specific procedures and cleanup requirements.
Prerequisites
Before using this skill, verify:
- All implementation steps completed
- All verifications passed
- Code review completed (if applicable)
- Security review completed (if applicable)
Do not proceed with failing tests. Fix them first.
The Completion Workflow
Step 1: Verify Tests Pass
Run the full test suite:
Run: [project test command]
Verify: Exit code 0, all tests pass
If tests fail: Stop. Do not proceed until tests pass.
Step 2: Identify Base Branch
Determine the target branch for integration:
Common targets:
- main (most common)
- master (legacy naming)
- develop (gitflow)
- [feature-branch] (nested features)
Check git configuration or ask if unclear.
Step 3: Present Options
Present exactly four options without elaboration:
- Merge locally - Merge to base branch on local machine
- Create pull request - Push and open PR for review
- Keep for later - Leave branch as-is to continue later
- Discard work - Delete branch and changes
Use AskUserQuestion to get user's choice.
Step 4: Execute Chosen Option
Option 1: Merge Locally
1. Checkout base branch
git checkout [base-branch]
2. Pull latest changes
git pull origin [base-branch]
3. Merge feature branch
git merge [feature-branch]
4. Run tests on merged result
[project test command]
5. If tests pass, push
git push origin [base-branch]
6. Delete feature branch
git branch -d [feature-branch]
git push origin --delete [feature-branch]
Never merge without verifying tests pass on the result.
Option 2: Create Pull Request
1. Push feature branch
git push -u origin [feature-branch]
2. Create PR using gh CLI
gh pr create --title "[title]" --body "[description]"
3. Report PR URL to user
4. Keep branch active for PR review
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 · 281 lines · 42 tokens per session scan A 866d0098f13a
finishing-work is a skill published in the GitHub repository bostonaholic/rpikit (20 stars, last pushed 4d ago), licensed MIT. It adds 42 tokens to every session and 1,506 once invoked, about $0.0002 per session on Opus 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-08-30.
Other skills, from other repositories
implement
Drive a single workshop ticket through the inner SWE↔Tester loop. Resolves the ticket from implementyourself/tasks/, creates an implementing/from-scratch branch (a fixed default — not derived from the ticket; subsequent tickets stack on top), launches the software-engineer agent to implement it, then routes by…
fanout
Run independent subtasks in parallel — one git worktree and one implementation sub-agent per task, each opening its own PR — then cross-review every PR. polly never merges; the human does.
changelog
Turn a range of commits or merged PRs into a changelog entry grouped by change type. Use when the user asks for release notes, a changelog, or "what changed" between two points.
pod-init
Initialize CocoPlus project bundle in the current directory. Creates .cocoplus/ directory structure, copies all templates, initializes AGENTS.md, project.md, flow.json, and creates the initial git commit. Run this once per project before using any other CocoPlus command.
ship
Enter the Ship phase of CocoBrew. Reads review.md approval, generates structured commit, creates semantic version tag, optionally creates PR via gh CLI, and records deployment details. Requires approved review.
lean-review
CocoLean diff-scoped over-engineering audit — scans uncommitted git diff and applies five classification tags (delete/stdlib/native/yagni/shrink) to identify unnecessary surface area before commit.