ShipSprint + GitHub
A branch tied to a card moves it the moment work starts. A merged pull request closes it. No status field for anyone to remember to update.
The board and the repo, reading from the same activity
Most "GitHub integrations" mean a webhook that posts a notification into another tool: a pull request opens, a message appears somewhere, and the board itself still needs a human to drag the card. ShipSprint's GitHub sync goes a step further than a notification. Tie a branch to a card, and starting work on that branch is what moves the card into progress. Merge the pull request, and that's what closes it. The board's state comes from what actually happened in the repository, not from someone remembering to update a field after the fact.
That matters most for the numbers that get built on top of it. Burndown charts and cycle-time analytics are only honest if the timestamps behind them are real, and a card that gets moved a day after the merge happened, or never gets moved at all, quietly corrupts both. Sync removes that gap: the card's history is the commit history, so a forecast built from it is built from what the team actually shipped, not from how promptly someone updated a board.
It also removes a specific kind of friction engineers complain about constantly: being asked to maintain two records of the same fact. A developer who has to open a PM tool and manually mark a ticket "done" after already closing it in GitHub is doing double bookkeeping for no reason. With sync in place, closing the pull request is the only action required. The board catches up on its own.
What the sync actually does
Four mechanics, not a notification feed.
Reference the card when you cut the branch, and the card moves into progress automatically the moment work begins, no manual drag required.
Merging is the completion signal. The card closes when the code lands, which is the same moment the team would consider the work actually done.
Sprint burndown and cycle-time analytics are calculated from that same merge activity, so the charts reflect what shipped rather than what got tidied up on a board afterward.
Delivery forecasts are calculated from the team's measured velocity as sprints close, and since sprint closure now tracks actual merges, the forecast is one step closer to the codebase than a manually-updated board ever gets.
Where this genuinely isn't enough
Sync moves a card on two events: branch created, pull request merged. It doesn't track intermediate states like "in code review" or "approved, awaiting deploy" on its own, since those aren't GitHub events with a single obvious mapping to a board column. A team that wants a review-specific column populated automatically will still need someone to move a card into it, or will need to treat "PR opened" as the trigger for that column instead, which is a coarser signal than a human reviewer's judgment.
It's also worth saying plainly: this connects branches and pull requests to cards. It doesn't import your entire GitHub Issues backlog, sync issue labels as board tags, or mirror GitHub's own project boards. If your team's whole workflow already lives inside GitHub Issues and Projects, evaluate whether moving that workflow into ShipSprint is worth it before assuming this bridges the two systems completely.
What this looks like day to day
- An engineer cuts a branch referencing the card number, and the card moves to "In progress" without anyone touching the board.
- A pull request merges at 6pm, and the card closes at 6pm, not the next morning when someone remembers to update it.
- A sprint review opens with the burndown chart already reflecting last night's merges, instead of someone reconciling the board against the repo first.
- A delivery forecast for next month is visibly built from the last several sprints' actual merge pace, not from a plan made once at kickoff.
- A reviewer still moves a card into "In review" by hand, since that step doesn't have a single GitHub event to hang off automatically.
Common questions
Team and Business. It isn't included on the Free plan. See the pricing page for the full breakdown.
This integration is specifically for GitHub. If your team is on GitLab, check with support before assuming equivalent behavior, since the two aren't the same integration.
It closes the card. Nothing is deleted, so the full history, comments and time logged against it stay intact and searchable afterward.
Yes, that's a separate connection using MCP, the open standard assistants use to call real tools. See the Claude integration page for detail.
The sync is built around branch-and-merge activity, so a workflow without pull requests won't get the same automatic close-on-merge behavior. Cards would need to be moved manually in that case.
Related pages
See it on your own work.
A workspace your whole company will actually use is 60 seconds away. No card, no risk, nothing to install.
14-day full-access trial · sample project included · no card required