brainstorming
Apply when generating ideas, exploring solution space, or facilitating divergent thinking before committing to an approach.
Apply when closing out a feature branch — pre-merge checklist, rebase, CI verification, cleanup, and post-merge steps.
$ npx -y skills add sordi-ai/skill-everything --skill branch-finishing --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/branch-finishingContext preview
The summary Claude sees to decide when to auto-load this skill.
Apply when closing out a feature branch — pre-merge checklist, rebase, CI verification, cleanup, and post-merge steps.
name: branch-finishing description: Apply when closing out a feature branch — pre-merge checklist, rebase, CI verification, cleanup, and post-merge steps. license: MIT version: 1.0.0 tokens_target: 1400 triggers: - finish branch - pre-merge checklist - branch cleanup loads_after: - git-conventions supersedes: []
**Purpose:** Ensures every feature branch is cleanly rebased, reviewed, and merged without introducing regressions or leaving stale local state behind.
---
1. **Rebase before merge.** Always rebase onto the target branch immediately before requesting merge to catch regressions introduced since the branch was cut. Reference: ERR-2026-024 2. **Resolve conflicts locally.** Before pushing a rebase, resolve every conflict locally and run the full test suite; never push a branch with unresolved markers. 3. **CI green before review.** Ensure all CI checks pass on the latest push before requesting a human review; do not ask reviewers to look at a red branch. 4. **Self-review diff.** Before opening a PR, run `git diff main...HEAD` and read every changed line; catch debug prints, commented-out code, and accidental file inclusions yourself first.
5. **Squash fixup commits.** Before merge, squash or fixup any `wip:`, `fixup!`, or `tmp:` commits so the branch history is clean; use `git rebase -i` to consolidate. 6. **Issue closing keywords.** Use `Closes #NNN` or `Fixes #NNN` in the PR body so the linked issue auto-closes on merge; never leave issues open manually after a successful merge. 7. **Changelog update.** After any user-visible change, add an entry to `CHANGELOG.md` (or the project's equivalent) before marking the PR ready for review. 8. **Version bump.** If the project uses semantic versioning, bump the version in the appropriate manifest file as part of the branch before merge, not as a follow-up commit.
9. **Draft until CI passes.** Keep the PR in draft state until all CI checks are green and the self-review is complete; convert to ready-for-review only when the branch is genuinely merge-ready. 10. **Remove draft status explicitly.** Use `gh pr ready <number>` to convert from draft; do not rely on reviewers noticing a draft PR that was silently updated.
11. **Delete remote branch after merge.** After a successful merge, delete the remote branch with `git push origin --delete <branch>` or enable auto-delete in repository settings; stale remote branches pollute the branch list. 12. **Delete local branch after merge.** After confirming the remote merge, delete the local tracking branch with `git branch -d <branch>` to keep the local workspace clean. 13. **Post-merge verification.** After merge, pull `main` locally and run the test suite once to confirm the integrated state is green; do not assume CI on the PR branch is sufficient.
14. **Prefer rebase over merge commits.** Avoid merge commits on feature branches; use `git rebase` to maintain a linear history unless the team explicitly requires merge commits.
---
Git-versioned agent memory: agents that never make the same mistake twice. Anthropic-Skill folder standard, multi-runtime (Claude Code, Cursor, Gemini CLI, OpenCode).
Repo: sordi-ai/skill-everything
Apply when generating ideas, exploring solution space, or facilitating divergent thinking before committing to an approach.
Apply when writing or refactoring code. Generic rules to prevent the most common review comments — function length, naming, error handling, security, and…
Apply when designing database schemas, writing migrations, or reviewing table structure. Covers naming, keys, indexes, constraints, nullability, and migration…
Apply when diagnosing a bug, reproducing a failure, or performing root cause analysis. Covers systematic isolation, binary search, logging strategy, and…
Apply when writing or reviewing Dockerfiles, docker compose files, or container build pipelines. Covers layer caching, multi-stage builds, security hardening,…
Apply when documenting project-specific knowledge. Template for ADRs, naming conventions, business rules, and tech-stack quirks.