finishing-branch

Name: finishing-branch
Author: krzysztofsurdy

17installs1forks

How to install finishing-branch?

krzysztofsurdy/code-virtuoso/finishing-branch

$npx -y skills add krzysztofsurdy/code-virtuoso --skill finishing-branch

Installs into the current project.

Summary

End-to-end workflow for finishing a development branch. Use when implementation is complete and the branch is ready to ship - runs verification checks, reviews the diff, picks the integration path (direct merge, pull request, squash-and-merge, stacked PR), writes the PR/merge mes

Files · 1

View on GitHub

SKILL.md

1	# Finishing a Development Branch
2
3	The code is written. Tests are green locally. Now what? The gap between "done coding" and "merged to main" is where branches rot, conflicts accumulate, and mistakes happen. This playbook is the systematic bridge: verify, review, integrate, clean up. Every time, in order, nothing skipped.
4
5	Never push without green. Never merge without review evidence.
6
7	## When to Use
8
9	- Implementation is complete and you are ready to integrate
10	- You need to decide between merge, squash, rebase, or PR
11	- A branch has been sitting and needs to be wrapped up
12	- You are finishing work in a worktree and need to clean up
13	- You are managing stacked branches and need to land them in order
14
15	## Quick Start
16
17	```bash
18	# Verify everything passes
19	git diff --stat main...HEAD
20	make test && make lint && make typecheck
21
22	# Push and open a PR (adjust target as needed)
23	git push -u origin HEAD
24	gh pr create --fill
25	```
26
27	If you need more control, follow the phases below.
28
29	---
30
31	## Phase 1: Working-Tree Sanity
32
33	Before anything else, ensure the working tree is in a known-good state.
34
35	```bash
36	# Check for uncommitted changes
37	git status
38
39	# Check for forgotten stashes
40	git stash list
41
42	# Ensure you are on the right branch
43	git branch --show-current
44
45	# Verify upstream tracking is set
46	git rev-parse --abbrev-ref --symbolic-full-name @{u}
47	```
48
49	\| Check \| Pass Condition \| Fix \|
50	\|---\|---\|---\|
51	\| No uncommitted changes \| `git status` shows clean tree \| Commit or stash intentionally \|
52	\| No orphaned stashes \| `git stash list` is empty or all stashes are accounted for \| Apply or drop stale stashes \|
53	\| Correct branch \| Branch name matches your work \| `git checkout <branch>` \|
54	\| Upstream set \| Tracking branch exists \| `git push -u origin HEAD` on first push \|
55	\| No untracked noise \| No generated files, build artifacts, or editor files \| Add to `.gitignore` or remove \|
56
57	---
58
59	## Phase 2: Pre-Push Verification
60
61	Run the full verification suite before pushing. Order matters - fail fast on the cheapest checks first.
62
63	```bash
64	# 1. Lint (fastest, catches formatting/style issues)
65	make lint # or: npm run lint, cargo clippy, flake8, etc.
66
67	# 2. Type checking (catches type errors without running code)
68	make typecheck # or: npx tsc --noEmit, mypy, phpstan, etc.
69
70	# 3. Unit tests (fast feedback on logic correctness)
71	make test # or: npm test, pytest, phpunit, cargo test, etc.
72
73	# 4. Integration / end-to-end tests (slower, catches wiring issues)
74	make test-integration
75
76	# 5. Build (ensures the artifact compiles / bundles cleanly)
77	make build # or: npm run build, cargo build --release, etc.
78	```
79
80	If any step fails, stop and fix before proceeding. Do not push broken code.
81
82	See [Pre-Push Checks Reference](references/pre-push-checks.md) for the full verification order, CI parity tips, and conflict detection.
83
84	---
85
86	## Phase 3: Diff Review
87
88	Self-review the full diff before handing it to others. You will catch things automated tools miss.
89
90	```bash
91	# Full diff against the target branch
92	git diff main...HEAD
93
94	# Commit-by-commit review (more granular)
95	git log --oneline main..HEAD
96	git show <commit-hash>
97
98	# Stat summary (spot unexpectedly large changes)
99	git diff --stat main...HEAD
100
101	# Check for secrets or sensitive data
102	git diff main...HEAD \| grep -iE '(password\|secret\|token\|api.key\|private.key)' \|\| true
103	```
104
105	### Self-Review Checklist
106
107	- [ ] No debug code left behind (`console.log`, `dd()`, `print_r`, `var_dump`, `TODO`)
108	- [ ] No commented-out code that should be deleted
109	- [ ] No secrets, tokens, or credentials in the diff
110	- [ ] No unrelated changes mixed into the branch
111	- [ ] Commit messages are clear and follow project conventions
112	- [ ] New files are in the correct directories
113	- [ ] Tests cover the changes (not just existing tests passing)
114
115	---
116
117	## Phase 4: Integration Strategy Selection
118
119	Choose how to integrate based on your team's workflow, the branch's history, and the target branch.
120
121	\| Strategy \| When to Use \| Command \|
122	\|---\|---\|---\|
123	\| Pull Request \| Team requires review, CI gates, or audit trail \| Push + open PR (see Phase 6) \|
124	\| Direct merge \| Trunk-based, solo project, or pre-approved change \| `git checkout main && git merge --no-ff <branch>` \|
125	\| **Squash and m

People who liked this also viewed

6 picks

Type

finishing-branch

17installs1forks

View on GitHub

How to install finishing-branch?

krzysztofsurdy/code-virtuoso/finishing-branch

$npx -y skills add krzysztofsurdy/code-virtuoso --skill finishing-branch

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Finishing a Development Branch
2
3	The code is written. Tests are green locally. Now what? The gap between "done coding" and "merged to main" is where branches rot, conflicts accumulate, and mistakes happen. This playbook is the systematic bridge: verify, review, integrate, clean up. Every time, in order, nothing skipped.
4
5	Never push without green. Never merge without review evidence.
6
7	## When to Use
8
9	- Implementation is complete and you are ready to integrate
10	- You need to decide between merge, squash, rebase, or PR
11	- A branch has been sitting and needs to be wrapped up
12	- You are finishing work in a worktree and need to clean up
13	- You are managing stacked branches and need to land them in order
14
15	## Quick Start
16
17	```bash
18	# Verify everything passes
19	git diff --stat main...HEAD
20	make test && make lint && make typecheck
21
22	# Push and open a PR (adjust target as needed)
23	git push -u origin HEAD
24	gh pr create --fill
25	```
26
27	If you need more control, follow the phases below.
28
29	---
30
31	## Phase 1: Working-Tree Sanity
32
33	Before anything else, ensure the working tree is in a known-good state.
34
35	```bash
36	# Check for uncommitted changes
37	git status
38
39	# Check for forgotten stashes
40	git stash list
41
42	# Ensure you are on the right branch
43	git branch --show-current
44
45	# Verify upstream tracking is set
46	git rev-parse --abbrev-ref --symbolic-full-name @{u}
47	```
48
49	\| Check \| Pass Condition \| Fix \|
50	\|---\|---\|---\|
51	\| No uncommitted changes \| `git status` shows clean tree \| Commit or stash intentionally \|
52	\| No orphaned stashes \| `git stash list` is empty or all stashes are accounted for \| Apply or drop stale stashes \|
53	\| Correct branch \| Branch name matches your work \| `git checkout <branch>` \|
54	\| Upstream set \| Tracking branch exists \| `git push -u origin HEAD` on first push \|
55	\| No untracked noise \| No generated files, build artifacts, or editor files \| Add to `.gitignore` or remove \|
56
57	---
58
59	## Phase 2: Pre-Push Verification
60
61	Run the full verification suite before pushing. Order matters - fail fast on the cheapest checks first.
62
63	```bash
64	# 1. Lint (fastest, catches formatting/style issues)
65	make lint # or: npm run lint, cargo clippy, flake8, etc.
66
67	# 2. Type checking (catches type errors without running code)
68	make typecheck # or: npx tsc --noEmit, mypy, phpstan, etc.
69
70	# 3. Unit tests (fast feedback on logic correctness)
71	make test # or: npm test, pytest, phpunit, cargo test, etc.
72
73	# 4. Integration / end-to-end tests (slower, catches wiring issues)
74	make test-integration
75
76	# 5. Build (ensures the artifact compiles / bundles cleanly)
77	make build # or: npm run build, cargo build --release, etc.
78	```
79
80	If any step fails, stop and fix before proceeding. Do not push broken code.
81
82	See [Pre-Push Checks Reference](references/pre-push-checks.md) for the full verification order, CI parity tips, and conflict detection.
83
84	---
85
86	## Phase 3: Diff Review
87
88	Self-review the full diff before handing it to others. You will catch things automated tools miss.
89
90	```bash
91	# Full diff against the target branch
92	git diff main...HEAD
93
94	# Commit-by-commit review (more granular)
95	git log --oneline main..HEAD
96	git show <commit-hash>
97
98	# Stat summary (spot unexpectedly large changes)
99	git diff --stat main...HEAD
100
101	# Check for secrets or sensitive data
102	git diff main...HEAD \| grep -iE '(password\|secret\|token\|api.key\|private.key)' \|\| true
103	```
104
105	### Self-Review Checklist
106
107	- [ ] No debug code left behind (`console.log`, `dd()`, `print_r`, `var_dump`, `TODO`)
108	- [ ] No commented-out code that should be deleted
109	- [ ] No secrets, tokens, or credentials in the diff
110	- [ ] No unrelated changes mixed into the branch
111	- [ ] Commit messages are clear and follow project conventions
112	- [ ] New files are in the correct directories
113	- [ ] Tests cover the changes (not just existing tests passing)
114
115	---
116
117	## Phase 4: Integration Strategy Selection
118
119	Choose how to integrate based on your team's workflow, the branch's history, and the target branch.
120
121	\| Strategy \| When to Use \| Command \|
122	\|---\|---\|---\|
123	\| Pull Request \| Team requires review, CI gates, or audit trail \| Push + open PR (see Phase 6) \|
124	\| Direct merge \| Trunk-based, solo project, or pre-approved change \| `git checkout main && git merge --no-ff <branch>` \|
125	\| **Squash and m

People who liked this also viewed

6 picks

Type