agentsclimarketplace

Finishing a branch

Skill NjoyimPeguy/augments/skills/deployment/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, 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.

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.