shelbi merge
View as markdownshelbi merge [OPTIONS] <ID>shelbi merge bridges an issue in review and a clean default branch. It is
PR-aware: if an open GitHub PR already exists for the issue's branch (the review
flow's open_pr step opens one), it lands the change through that PR with a
GitHub CLI squash-merge, so a repo whose branch protection requires PRs still
accepts it. Only when there is no GitHub remote or no open PR does it fall back
to a local squash-merge into the project's default branch (typically main)
under the generated message shelbi: merge <id> from <branch>. Pass --pr to
push the branch and open a fresh GitHub pull request instead, without merging.
A blocked push or a failed PR merge is a hard error: the command stops and does not mark the issue done, so an unshippable change is never silently left as an "accepted" card whose PR stayed open.
The command does not move the card. After a successful merge, the
orchestrator's "merged → done" sweep (or you, manually) moves the issue to
done. After a --pr open, the card stays in review until the PR
itself lands.
Arguments
| Argument | Type | Default | Description |
|---|---|---|---|
<ID> | string | — | Issue id whose branch to merge (required). |
Flags
| Flag | Type | Default | Description |
|---|---|---|---|
--pr | flag | off | Push the branch and open a fresh GitHub PR instead of merging. |
-p, --project <PROJECT> | string | env / cwd lookup | Project to operate on. |
Examples
Squash-merge a reviewed issue locally:
shelbi merge docs-write-cli-reference-pagesOpen a GitHub PR for the branch instead of merging locally:
shelbi merge docs-write-cli-reference-pages --prSee also
- Workflows
— where
ReviewandDonesit in the default workflow's lifecycle and what each transition signals. - Review workspaces — the upstream step that puts the branch in front of a reviewer before merge.