About finish-work
A project wrap-up skill for developers working in a repository or monorepo package. It verifies changes, stages relevant files, and guides commit messages, with safeguards for no-commit requests and pushes.
Key features
- 01Run project checks and fix failures
- 02Stage only relevant changes
- 03Use a structured commit message
- 04Honor explicit no-commit requests
- 05Avoid pushing without permission
Use cases
- 01Finishing an implemented change
- 02Verifying and committing a fix
- 03Preparing a commit draft without committing
Install
Copy the command and run it in a terminal.
npx skills add https:/After installing, type/finish-workin Claude Code to confirm it loaded.
Details
From the project READMEFinish work
Run in the project root, or in each changed monorepo package (app/, processing/, etc.).
Workflow
- Verify: read
scripts.checkinpackage.json, runbun run check, fix the root cause, and rerun until green.lint/formatmay rewrite files. - Keep fixes together: stage lint/format changes with the functional changes; never make a separate "lint" or "format" commit.
- Write the commit message using the format below.
- Default: commit. Run the commit path below unless the user clearly did not want a commit.
- Draft only when no-commit intent is clear. Show the message and stop; do not run
git commit.
No-commit intent includes: explicit deferral ("don't commit", "draft only", "message only", "what would the commit be"), check/fix-only asks ("run check", "fix lint", "fix CI" with no wrap-up), review or question-only turns, or the user saying they will commit themselves.
When intent is ambiguous, prefer committing — especially after implementing changes or when the user invoked finish-work to wrap up. When another skill calls finish-work with a stricter commit rule (e.g. user-changelog: commit only on request), that rule wins.
Commit path: git status, git diff, and git log -5 in parallel; stage relevant files only; git commit via HEREDOC; git status to verify.
Safety: no push unless asked. No --no-verify. No amend of pushed commits, except the lint/format amend below. Do not stage secrets or unrelated dirty files.
Already committed and verify only fixed lint/format: when the changes are purely lint/format and clearly belong to HEAD, git commit --amend --no-edit (if HEAD was already pushed, say that the push now needs --force-with-lease; do not push). Otherwise ask.
E2E is not in check. For UI/routes/auth changes, also run bun run e2e (or check-full when defined). See skill playwright-skill.
Script names: skill tech-stack → references/package-json-scripts.md.
Commit message
<Topic>: <Desc>
- <user-facing outcome bullet>
Ping https://github.com/org/repo/pull/123
- Topic: scope (
Map,Auth,Processing,Dev, etc.). FMC internal-only changes (deps, CI, tooling) useDev. - Desc: imperative outcome, not filenames.
- Body: bullets of what users/operators see, do, or get after this lands. Include why when the conversation established it. Stay at outcome level; do not list files, symbols, refactors, or diff steps. Bodies feed skill
user-changelog, so they must be readable without the patch. - Ping: if user cited a PR/issue, add one
Ping <full-url>line per item.
Example:
Region map: clamp initial viewport to bounds
- Users: map fits selected region on load instead of generic Germany view (confusing deep links)
- Preserve explicit zoom in URL so shared links do not jump
Ping https://github.com/FixMyBerlin/tilda-geo/issues/5678
Internal-only (no user-visible change): maintainer bullets ok; omit user bullets when none apply.
Related
skill close-worktree (land worktree → develop; calls this skill if dirty) | skill unslop-code (post-LLM cleanup; calls this skill per phase commit) | skill playwright-skill | skill tech-stack | skill review-dependabot | skill user-changelog