Finishing a development branch

Skill gustavo-meilus/superpipelines/plugins/superpipelines/skills/finishing-a-development-branch

Structured integration protocol that enforces a test-verification gate and presents branch disposition options (merge, PR, keep, or discard). Use when implementation is complete, all tests pass, and an integration decision for the development branch is pending.From its SKILL.md

Install

npx -y skills add gustavo-meilus/superpipelines --skill finishing-a-development-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

4 stars4 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.

SKILL.md

3.9 KB, 898 tokens by cl100k_base, as published. Nobody here has run it

Finishing a Development Branch — Integration Protocol

Ensures work is integrated or preserved according to explicit user choice. A mandatory test verification gate is enforced before any options are presented, preventing promotion of broken or unverified code to the base branch.

<overview> Finishing a Development Branch ensures that work is integrated or preserved according to the user's explicit choice. It enforces a mandatory test verification gate before any options are presented, preventing the promotion of broken or unverified code to the base branch. </overview> <glossary> <term name="Base Branch">The target for integration, typically `main` or `master`.</term> <term name="Worktree">An isolated directory for development; must be cleaned after integration.</term> <term name="PR Gate">Option 2, which involves pushing the branch and creating a Pull Request via `gh pr create`.</term> </glossary>

The Completion Protocol

<protocol> ### 1. VERIFY TESTS (THE GATE) - The project's primary test suite is run (e.g., `npm test`, `pytest`). - <HARD-GATE>If tests fail, STOP. Integration options cannot be presented until all tests are green.</HARD-GATE>

2. DETERMINE BASE BRANCH

The split point is identified (e.g., git merge-base HEAD main).
The base branch is confirmed with the user if ambiguity exists.

3. PRESENT STRUCTURED OPTIONS

Exactly these four options are presented without modification:
1. Merge back to [base] locally
2. Push and create a Pull Request
3. Keep the branch as-is (Handle later)
4. Discard this work

4. EXECUTE CHOICE

Option 1: Base is checked out, latest is pulled, branch is merged, tests are re-verified, and the feature branch is deleted.
Option 2: Branch is pushed to origin and a PR is created using the gh CLI.
Option 4: Explicit typed confirmation ("discard") is required before destructive deletion.

5. CLEANUP

For Options 1, 2, and 4: The associated git worktree is removed to maintain repository hygiene. </protocol>

<invariants> - NEVER proceed with integration if the verification gate fails. - NEVER cleanup the worktree for Option 3 (Keep as-is). - ALWAYS re-verify tests on the base branch after a local merge (Option 1). - ALWAYS obtain "discard" confirmation before executing Option 4. </invariants>

Completion Patterns

<patterns> | Option | Merge | Push | Cleanup Branch | Cleanup Worktree | | :--- | :--- | :--- | :--- | :--- | | **1. Merge Locally** | ✓ | - | ✓ | ✓ | | **2. Create PR** | - | ✓ | - | ✓ | | **3. Keep As-Is** | - | - | - | - | | **4. Discard** | - | - | ✓ (force) | ✓ | </patterns>

Red Flags — STOP

"I'll merge now and fix the tests later." → STOP. Integration of failing code is a SEV-0 failure.
"What should I do next?" → STOP. Present the four structured options defined in the protocol.
"Deleting worktree automatically." → STOP. Option 3 requires worktree preservation.

Rationalization Table

<rationalization_table>

Excuse	Reality
"PR handles testing anyway."	Local verification prevents broken builds and reduces CI overhead.
"It's just a one-line change."	One-line changes are the leading cause of "it worked in my head" regressions.
"Discarding is faster than cleanup."	Unconfirmed discards cause irreversible data loss.
</rationalization_table>

Reference Files

sk-worktree-safety/SKILL.md — Worktree management.
verification-before-completion/SKILL.md — Final evidence gate.
running-a-pipeline/SKILL.md — Integration point for pipeline completion.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most test skills give in 898 tokens

Counted across 1,201 of the 2,096 authors here whose files we hold, read 2026-09-06

Write a failing test before writing codein 43 of 1201, across 36 files
Run the full test suitein 36 of 1201, across 35 files
Test only one variable per experimentin 34 of 1201, across 17 files
Read product marketing context before asking questionsin 34 of 1201, across 14 files
Mock external dependenciesin 34 of 1201, across 30 files
Define primary, secondary, and guardrail metricsin 33 of 1201, across 16 files
Pre-determine sample size before startingin 31 of 1201, across 14 files
Test behavior rather than implementationin 31 of 1201, across 29 files
Formulate a hypothesis before designing a testin 30 of 1201, across 13 files
Document every test hypothesis, variant, and resultin 29 of 1201, across 11 files
Use descriptive test function namesin 25 of 1201, across 21 files
Commit to the methodology without stopping earlyin 24 of 1201, across 8 files

Said here and by no other author read

identify the base branch
present four structured integration options
re-verify tests after local merge
require explicit confirmation to discard work
remove worktree after integration or discard

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.