finishing-a-branch

Étoiles2

Forks1

Mis à jour6 juin 2026 à 14:31

Use when implementation is complete and verified and the work needs to land, to choose how to integrate it. Walks the close-out from a clean green suite to a recorded memory of what changed, then merge, pull request or cleanup as the situation calls for.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Source

sarmakska

sarmakska/slipstream

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

SKILL.md

readonly

name	finishing-a-branch
description	Use when implementation is complete and verified and the work needs to land, to choose how to integrate it. Walks the close-out from a clean green suite to a recorded memory of what changed, then merge, pull request or cleanup as the situation calls for.
slipstream	{"category":"context","requires":[],"tags":["git","workflow","completion"]}

Overview

Work is not finished when the code works; it is finished when it has landed cleanly and the next session knows it happened. The end of a branch is where good work gets lost: an un-run check, an undocumented decision, a branch left dangling. This skill closes the loop deliberately so nothing leaks.

Steps

Verify once more on the final state. Run the full suite, the build and the lint on exactly what will land. A green run earlier in the branch does not count.
Record what is durable. Save any decision, convention or gotcha from the branch with /slipstream:remember so it survives into the next session and the dashboard.
Write the integration message: what changed and why, in the project's commit and pull-request style. Keep it honest about what is and is not covered.
Choose the landing: a direct merge for small, owned changes; a pull request where review or a paper trail is wanted; a clean delete if the branch was an experiment that should not land.
Clean up after landing: remove the merged branch, confirm the main line is green, and leave the tree in the state the next session expects.

Verify

The final state passed the full checks, durable outcomes are recorded in memory, and the branch reached its chosen destination with the main line green afterwards.

Plus depuis ce dépôt

même dépôt

dispatching-parallel-agents

sarmakska/slipstream

Use when several pieces of work are genuinely independent and can run at once, to fan them out across parallel agents instead of doing them in sequence. Cuts wall-clock time and keeps each strand in its own clean context.

2026-06-172

executing-plans

sarmakska/slipstream

Use when a written plan exists and you are about to build it in the current session, to work it task by task with a checkpoint after each. Keeps execution honest against the plan instead of drifting into a freehand build.

2026-06-172

using-git-worktrees

sarmakska/slipstream

Use when work needs its own isolated checkout — parallel strands that would fight over files, or a risky change you want quarantined from the main tree. Gives each strand a real working directory on its own branch without re-cloning.

2026-06-172

using-slipstream

sarmakska/slipstream

Use whenever the user says "use slipstream", "use superpowers", or starts any task in a project that has slipstream. A hard, always-on discipline that forces scoped reads over whole-file reads to save tokens, recalls memory before acting, and records what is durable every turn so memory grows constantly.

2026-06-062

frontend-design-system

sarmakska/slipstream

Use when a site needs to look designed rather than defaulted, before building sections: establish a cohesive design system of type scale, spacing, colour, radius and shadow tokens so every component shares one premium visual language.

2026-06-062

frontend-hero-section

sarmakska/slipstream

Use when building the top of a landing page, to produce a high-impact hero with confident display type, a clear single call to action and balanced composition, the kind of opening a polished marketing site leads with.

2026-06-062

name	finishing-a-branch
description	Use when implementation is complete and verified and the work needs to land, to choose how to integrate it. Walks the close-out from a clean green suite to a recorded memory of what changed, then merge, pull request or cleanup as the situation calls for.
slipstream	{"category":"context","requires":[],"tags":["git","workflow","completion"]}

Overview

Steps

Verify once more on the final state. Run the full suite, the build and the lint on exactly what will land. A green run earlier in the branch does not count.
Record what is durable. Save any decision, convention or gotcha from the branch with /slipstream:remember so it survives into the next session and the dashboard.
Write the integration message: what changed and why, in the project's commit and pull-request style. Keep it honest about what is and is not covered.
Choose the landing: a direct merge for small, owned changes; a pull request where review or a paper trail is wanted; a clean delete if the branch was an experiment that should not land.
Clean up after landing: remove the merged branch, confirm the main line is green, and leave the tree in the state the next session expects.

Verify

The final state passed the full checks, durable outcomes are recorded in memory, and the branch reached its chosen destination with the main line green afterwards.