merge-branch
This skill is invoked when the user wants to merge an issue branch into the current branch and clean up its worktree/branch. Helper scripts under <SKILL_DIR>/scripts/ handle plan and issue resolution; you handle the git commands and the user confirmation step. <SKILL_DIR> is the directory containing this SKILL.md.
Hard rules — never violate:
- Never use
--squashor--ff-only. Alwaysgit merge --no-ff. - Never push, rebase, reset, amend, skip hooks, or skip signing.
- Never run
git merge --abortwithout explicit user approval — conflicts are resolved in place when possible (see Step 4). - Never force-delete (
git branch -D) or--forcea worktree removal without explicit user approval. - Never delete the branch before removing its worktree —
git branch -drefuses a branch that is checked out elsewhere. - Never take a raw branch name from the prompt — always resolve it from
plans/<plan>/issues/index.jsonvia the helper script. - Always ask the user for explicit approval before running the merge.
- When resolving conflicts autonomously, never guess at semantic intent — if you cannot tell which side is correct from surrounding context, stop and surface the specific conflict to the user.
-
Resolve the plan and issue.
Run
node <SKILL_DIR>/scripts/resolve-plan.mjs [--plan <name>]. Stdout = plan name. Exit 2 with a list = multiple plans; ask the user.The user's prompt should include the issue id (e.g. "merge branch 6"). If missing, ask. Then run
node <SKILL_DIR>/scripts/resolve-issue.mjs --plan <plan> --id <id>. Stdout = JSON{ id, slug, status, worktreePath }. The script normalises6→"006"and errors with available ids if no match. Ifslugequals the current branch, stop — can't merge into itself.
More from rodrigooslp/skills
work-on-issue
Implement a documented issue file end-to-end — read the right context, do only the in-scope work, run quality gates, mark the issue done, and produce a structured completion report. Use whenever the user asks you to implement, work on, or complete a numbered issue — for example "work on issue 004", "implement issue 012", or "you're agent on issue 007".
11prd-to-issues
Break a PRD into independently-grabbable issues using tracer-bullet vertical slices, saved as markdown files in the plan's `issues/` folder along with an `index.json` tracker. Use when the user wants to convert a PRD to issues, create implementation tickets, or break down a PRD into work items.
7review-issues
Review an issue set by spawning two subagents (one for implementer review, one for PRD-coverage review), consolidating their feedback into actionable items. Use when the user wants to review issues, validate the issue breakdown, check issues against the parent PRD, or mentions "review issues".
5review-prd
Review a PRD by spawning two subagents (one for product/design gaps, one for implementability), consolidating their feedback into actionable items. Use when the user wants to review a PRD, validate a product requirements document, check a PRD before breaking it into issues, or mentions "review PRD".
5use-conventional-commits
>
5write-a-prd
Create a PRD through user interview, codebase exploration, and module design, then save it to the plans folder. Use when user wants to write a PRD, create a product requirements document, or plan a new feature.
4