agentleFS
grimoire-rsgrimoire-rs/grimoire-vscode/.claude/skills/finalize/SKILL.md

finalize

Skill0 starsChanged 4 months agoApache-2.0View on GitHub

Use when the user says "finalize", "/finalize", "prepare this branch for main", "clean up history", "squash the branch", or landing a branch on `main`. Rewrites Checkpoint working-phase commits into clean Conventional Commits before fast-forward merge. Flags: `--squash-all`, `--dry-run`.

  • Deletes or force-pushes

22 other projects use a version of this, 1 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use simplify, debug and 3 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • Hugging FaceSkill

    simplify

    Refactor code after tests pass. The "Refactor" phase of Red-Green-Refactor.

    Also in 3 projects that use this

  • AnthropicSkill

    debug

    Structured debugging session — reproduce, isolate, diagnose, and fix. Trigger with an error message or stack trace, "this works in staging but not prod", "something broke after the deploy", or when behavior diverges from expected and the cause isn't obvious.

    Also in 3 projects that use this

  • Microsoft AzureSkill

    verify

    End-to-end app testing pipeline for browser-based web apps on cloud browsers via Azure Playwright Workspaces: verify the live app, author tests for working flows, heal failing tests, then re-run with video and produce one consolidated report. Three phases (app verification, test authoring, test healing) plus a scoped final sanity run; each phase emits a sub-report. Use when asked to "verify my app", "make sure my app works and has good test coverage", "do a full QA pass", "add tests where I'm missing coverage", "fix failing tests and add new ones", "smoke test before deploy", "QA my deployment", or any combined verify-and-test ask. Requires Azure CLI (`az login`) and a Playwright Workspace resource ID — bootstraps configs on first invocation. Browser-based web apps with Playwright only — not for unit/API tests, native mobile/desktop, load/perf, or full accessibility audits.

    Also in 3 projects that use this

  • SentrySkill

    commit

    Create commit messages following Sentry conventions. Use when committing code changes, writing commit messages, or formatting git history. Follows conventional commits with Sentry-specific issue references.

    Also in 3 projects that use this

  • MicrosoftSkill

    handoff

    Compact the current conversation into a handoff document for another agent to pick up.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

11 rules. 0 are common, 1 is distinctive, and 10 are very specific to this project.

  • 0

    Common

    Most of the 22 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 10

    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
  1. Very specific:

    origin/main handling: If local main behind origin/main, surface before drafting plan, ask user how to proceed:

    line 64
  2. Very specific:

    Never touch origin/main directly (no force-push, no remote updates beyond fetch).

    line 72
  3. Very specific:

    Use AskUserQuestion with three options:

    line 111
  4. Very specific:

    If user picked --dry-run, print plan and stop regardless of choice.

    line 119
  5. Very specific:

    Use scripted non-interactive git rebase -i pattern — never launch $EDITOR.

    line 123
  6. Very specific:

    When --squash-all passed, skip steps 2–4, instead:

    line 148
  7. Very specific:

    After rebase, task verify must still pass on new HEAD.

    line 166
  8. Distinctive:

    No push. Never push.

    line 172
  9. Very specific:

    After successful rebase, if a Status block exists in the plan referenced by .claude/state/current_plan.md: set Step: to finalized, bump …

    line 176
  10. Very specific:

    Always capture START_SHA: before first destructive op.

    line 184
  11. Very specific:

    Never launch $EDITOR: Always scripted GIT_SEQUENCE_EDITOR + GIT_EDITOR pattern with pre-written files.

    line 188

“Common” is measured: kept by at least 6 in 10 of the 22 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

/finalize — Prepare Branch for Fast-Forward Merge

Rewrites commits in main..HEAD so branch fast-forwards onto main as clean Conventional Commits sequence. Rebasing phase of two-phase branch workflow — see workflow-git.md for full model.

Sibling /commit skill handles working phase (save progress during dev). /finalize takes messy result, produces what lands in main-branch changelog.

When To Use

SituationUse
Branch has multiple Checkpoint commits/finalize
Branch has working-phase bundles ("chore(claude): bundle skill + rules + agents")/finalize
Rebasing branch onto current main before fast-forward/finalize
Branch is one changelog entry with noise between/finalize --squash-all
Already one-concern-per-commit and rebaseddon't — fast-forward

Flags

  • --squash-all — skip per-commit analysis, collapse main..HEAD into single commit. Skill drafts one message for whole diff, asks approval.
  • --dry-run — produce classification + rebase plan, show, no execute. Useful for review.
  • --force — skip the active-phase check (still honors other refuse conditions). Use when no plan tracks the branch or Status block is intentionally stale.

Workflow

1. Snapshot state (parallel batch)

  • git rev-parse --abbrev-ref HEAD — current branch
  • git status --porcelain=v1 — working tree clean?
  • git fetch origin main --quiet 2>/dev/null then git rev-parse main and git rev-parse origin/main 2>/dev/null — detect if local main lags origin/main
  • git log --oneline main..HEAD — commits to finalize
  • git log -1 --pretty=%s main — tip of main (plan reference)
  • git rev-list --count main..HEAD — commit count
  • git diff --stat main..HEAD — diff shape
  • git merge-base --is-ancestor main HEAD; echo $? — local main ancestor of HEAD? (0 = yes, branch based on current local main; 1 = no, needs rebase onto main as part of finalize)

Refuse to proceed if:

  • Current branch is main — tell user switch to feature/worktree branch first.
  • main..HEAD empty — nothing to finalize.
  • Working tree dirty — tell user commit or stash with /commit first. No auto-stash; user must consciously save state.
  • Plan still in flight — read .claude/state/current_plan.md; if pointer present, parse the referenced plan's ## Status block. Refuse if Step is not finalized/awaiting /finalize or Active phase is not the last plan phase. --force overrides. Schema → plan-status.md.

Rebase target — always current local main. /finalize produces branch fast-forwarding onto local main HEAD. Two cases:

  1. Branch already based on current main (merge-base --is-ancestor main HEAD returns 0). Rebase only rewrites commits in main..HEAD for hygiene — no parent change, no upstream-drift conflict risk.
  2. Branch behind main (returns 1). Rebase does double duty: rewrites commits in main..HEAD for hygiene and moves branch onto current main HEAD. Conflicts here real, human resolves (see Step 4).

Both cases use git rebase -i main, replays merge-base..HEAD onto current main.

origin/main handling. If local main behind origin/main, surface before drafting plan, ask user how to proceed:

OptionEffect
Fast-forward local main first, then finalize (default)git fetch origin main && git checkout main && git merge --ff-only origin/main && git checkout <branch> then continue. Branch lands on top of latest published main.
Finalize against current local mainSkip fetch. Branch fast-forwards onto local main but may lag origin once published.
AbortStop without changes.

Never touch origin/main directly (no force-push, no remote updates beyond fetch).

2. Classify each commit in main..HEAD

For every commit in main..HEAD, assign one category:

CategorySignalAction
KeepClean Conventional Commits subject, single concern, useful changelog entryLeave alone
RewordSingle concern but subject non-conventional, typo'd, or mis-typed (e.g. fix: for real feat:)Rewrite subject only, keep diff
SquashTwo+ adjacent commits cover same concern (fix + follow-up fixup, feat + missed test, rolling checkpoint amendments)Collapse into one with drafted message
SplitOne commit mixes unrelated concernsOffer git reset HEAD^ workflow; defer to human if non-trivial
DropEmpty commit, reverted earlier in branch, pure noiseRemove
CheckpointSubject exactly CheckpointReword (single concern inside) or squash into neighbour

Classification heuristics:

  • Subject line first. Non-conventional → Reword candidate.
  • git show --stat <sha> for diff shape. Small diff, one module → likely Keep/Reword. Large diff, many modules → inspect body for multi-concern signals (- bullet lists, and, also, plus, bundle language).
  • chore(claude): commits touching only .claude/ or CLAUDE.md belong in working-phase, but on finalized branch should still be individually legitimate chore(claude): entries, not bundles.
  • git log --format=%B <sha> -1 for full message when subject ambiguous.

3. Draft the rebase plan

Present as numbered list user can scan. Example:

Rebase plan for evelynn (5 commits in main..HEAD):

  1. KEEP    a2a7072 feat(mirror): per-platform asset_type override
  2. SQUASH  b1c2d3e Checkpoint              → fold into (3)
  3. REWORD  e4f5g6h chore(claude): wip             → feat(cli): add --remote flag to catalog
  4. DROP    9a8b7c6 Revert previous wip fix  (undone later in the branch)
  5. KEEP    1234567 docs(guide): document --remote flag

Target base: main (039c066)
Final commit count: 3

Use AskUserQuestion with three options:

OptionEffect
Execute plan (default)Run scripted rebase
Edit planLet user adjust before exec (describe change in prose, redraw)
AbortStop without changes

If user picked --dry-run, print plan and stop regardless of choice.

4. Execute the rebase (non-interactive)

Use scripted non-interactive git rebase -i pattern — never launch $EDITOR. Base always current local main, so same command both rewrites internal history (per plan) and replays branch onto latest local main HEAD.

# Capture starting state for emergency rollback
START_SHA=$(git rev-parse HEAD)

# Build a rebase-todo file from the plan, then run rebase with
# GIT_SEQUENCE_EDITOR pointing at `cat` on that file, and
# GIT_EDITOR pointing at a script that replaces any commit message
# during reword/squash with the pre-drafted one.
GIT_SEQUENCE_EDITOR="cp $TODO_FILE" \
GIT_EDITOR="$MSG_SCRIPT" \
git rebase -i main

Implementation notes:

  • Generate rebase-todo file in temp dir. Each line is pick|reword|squash|fixup|drop <sha> <subject>.
  • For reword/squash, pre-write target message to files named by SHA; GIT_EDITOR script reads matching file, overwrites message.
  • On rebase conflict: stop, print conflicted file list, tell user what to do (git status, edit, git rebase --continue), exit. Do not auto-resolve.
  • On success: show rewritten git log --oneline main..HEAD and final commit count.
  • Backout: git rebase --abort (if still rebasing) or git reset --hard $START_SHA (if rebase done but user unhappy). Offer both explicitly.

5. --squash-all mode

When --squash-all passed, skip steps 2–4, instead:

  1. Draft single Conventional Commits message covering full main..HEAD diff. Read git log main..HEAD for scope/concern inspiration but result is one commit — subject describes real user-visible change, not enumerate fixups.
  2. Show drafted message. Ask approval.
  3. Execute:
    git reset --soft main
    git commit -m "$(cat <<'EOF'
    <drafted message>
    EOF
    )"
  4. Report new HEAD sha + subject.

Squash-all right when branch really one changelog entry — e.g. feature across 8 checkpoints + 3 fixups. Wrong when branch has independent concerns (refactor + unrelated bug fix) — decline, use per-commit plan instead.

6. Quality gate after rebase

After rebase, task verify must still pass on new HEAD. Run it. On fail:

  1. Show failure.
  2. User fixes (rebases can expose test interactions invisible in messy history).
  3. On fix, rerun /commit (working phase for fix) then /finalize again if more shaping needed.

No push. Never push.

7. Mark plan finalized + clear current_plan.md

After successful rebase, if a Status block exists in the plan referenced by .claude/state/current_plan.md: set Step: to finalized, bump Last update: (with new HEAD sha), delete .claude/state/current_plan.md. Skip silently when no plan / no Status block / --force was used.

8. Report

Starting → final commit count, whether task verify passed, whether Status was marked finalized and current_plan.md cleared, next step for user (git checkout main && git merge --ff-only <branch> if asked; else stop).

Safety Rules

  • Always capture START_SHA before first destructive op. Offer git reset --hard $START_SHA as recovery command if user unhappy.
  • Never force-push. Skill only rewrites local history. Human decides push.
  • Never touch commits already on origin/<branch> without explicit confirmation. Rewriting published history fine on feature branch human controls, but skill must flag (git rev-list origin/<branch>..HEAD for local-only vs published).
  • Never auto-resolve conflicts. On conflict, stop, hand back to user.
  • Never launch $EDITOR. Always scripted GIT_SEQUENCE_EDITOR + GIT_EDITOR pattern with pre-written files.

References

  • workflow-git.md — shared branch/commit hygiene: branching model, two-phase model, Checkpoint convention, land-ready definition
  • task git:merge — the fast-forward step this skill prepares for

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.