agentsclimarketplace

Finishing a branch

Skill NjoyimPeguy/augments/plugins/augments/skills/finishing-a-branch

A collection of rigorous, phase-isolated SDLC skills to tether autonomous agents to real-world engineering standards.

Install
npx -y skills add NjoyimPeguy/augments --skill finishing-a-branch

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when a change's checks are verified green and you're ready to wrap the branch — clean commits, a real PR description, and a merge/keep/discard decision. If done or tested is only asserted, not yet run, verify first (verifying-completion). Skip mid-development — this is the wrap-up.

SKILL.md

2.8 KB, 587 tokens by cl100k_base, as published. Nobody here has run it

Finishing a Branch

Take a working branch to a merge-ready state. The order is fixed — gate, tidy, describe, decide, clean up — and nothing destructive happens before the thing it depends on is confirmed.

When to use

  • A change is complete and its checks have been run and pass (not merely claimed), and you're ready to merge, open a PR, or set the branch aside.
  • Skip mid-development — this is the wrap-up, not a checkpoint.

Procedure

  1. Gate on green. Run the tests and checks fresh; read the output. If anything fails, STOP and fix it before any step below. A merge-ready branch has passing checks, not "should be passing".
  2. Tidy the history. One logical commit per coherent change. Imperative subject ≤ ~72 chars; the body says why, not what (the diff is the what). Squash fixup noise. Do not force-push a branch with shared history unless explicitly asked.
  3. Write the PR description. First check whether the repo carries a PR template (a PULL_REQUEST_TEMPLATE file or directory under .github/, docs/, or the root, in any case): if one exists, fill it — its sections are the contract and override the default below, and a PR that ignores it reads as not having looked. If several templates could apply, stop and ask which. With no template, two sections, no more:
    • ## Summary — 2–3 bullets: what changed and why.
    • ## Test Plan — how it was verified. A reader should grasp the change without opening the diff.
  4. Decide, explicitly — surface the choice once; don't open-end it:
    • Merge it — only after green checks and review (requesting-code-review; its self-review path covers a trivial mechanical diff). If it ships to a running system, release-readiness is the next gate before deploy.
    • Open a PR and leave the branch for review.
    • Keep it as-is, or discard it.
  5. Clean up only what you created, and only after the merge is confirmed. Remove a workspace/worktree before deleting its branch, never the reverse (see using-task-branches). Never delete a branch or workspace you didn't create, and never discard without explicit confirmation.

Common mistakes

  • Presenting merge options while checks are red — the gate comes first.
  • A force-push that rewrites shared history nobody asked you to rewrite.
  • A PR body that restates the diff instead of explaining the why and the test plan.
  • Deleting a branch before the worktree that references it (the delete fails), or cleaning up a workspace the harness owns.

Gives 2 of the 12 instructions most pr commit review skills give in 587 tokens

Counted across 888 of the 1,342 authors here whose files we hold, read 2026-08-07

  • use conventional commits formatin 127 of 888, across 115 files
  • keep subject line under 72 charactershere, and in 62 of 888, across 48 files
  • delete branches after mergein 51 of 888, across 38 files
  • use imperative mood in subject linein 51 of 888, across 42 files
  • use imperative mood in commit messagesin 44 of 888
  • verify directory is ignored before creating worktreein 43 of 888, across 12 files
  • generate a conventional commit messagein 43 of 888
  • add unignored worktree directories to gitignorein 42 of 888, across 10 files
  • make atomic commitsin 39 of 888, across 27 files
  • run tests before committinghere, and in 36 of 888, across 25 files
  • verify clean test baselinein 35 of 888, across 9 files
  • split unrelated changes into separate commitsin 35 of 888, across 30 files

Said here and by no other author read

  • write a summary and test plan if no template
  • make an explicit merge or keep decision
  • clean up only created workspaces and branches

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.