Your Board Is Already Wrong
It's 3pm on Wednesday. Your kanban board shows three features "in progress." But one of those features had a PR merged yesterday — nobody moved the card. Another hasn't had a commit in five days — it's actually blocked, but the card still says "in progress." The third is genuinely in progress, but the PR is a draft that won't be ready until Friday.
Your board is wrong. Not because anyone lied — because the board and the code live in different systems, and humans are the integration layer. And humans forget. They context-switch. They drag cards during standup but miss the one they started after lunch.
The information about what's actually happening exists. It's in GitHub — branches, commits, PRs, reviews, merges. The problem isn't data. It's plumbing. Your board doesn't read GitHub, so you manually translate between the two systems, poorly, several times a day.
What Automatic Status Sync Looks Like
The ideal workflow has zero manual board updates. Instead:
Branch created → In Progress. When an engineer creates a branch linked to a spec item, the board card moves automatically. No standup update needed. No drag-and-drop ceremony.
PR opened → In Review. The card moves to "In Review" the moment a PR is opened. The board shows who opened it, when, and what spec section it addresses.
PR merged → Shipped. Merge to main = done. The card moves to "Shipped." The spec updates to reflect that this requirement was implemented. The timestamp is the merge time, not "whenever someone remembered to move the card."
PR diverges → Drift flag. This is the part no current tool does well. When a PR implements something differently than the spec describes, a drift flag appears on the card. The PM sees it without opening GitHub.
What Exists Today (And What's Missing)
Jira + GitHub integration requires Jira Premium ($16/user/month) for automatic transitions. Standard Jira shows linked PRs in the ticket detail but doesn't move cards. You still drag manually. And the integration requires smart commit messages or branch naming conventions that every team configures differently and nobody follows consistently.
Linear + GitHub auto-links PRs via branch naming (e.g., feature/LIN-123-add-notifications). This is genuinely useful — the PR appears in the Linear issue automatically. But status transitions are partial: Linear can mark an issue as "done" when a PR merges, but doesn't distinguish between "in progress" and "in review." And there's no spec connection — the PR links to the issue, not to a specification.
GitHub Projects is GitHub's own project management layer. It's tightly integrated (obviously), with auto-status from PRs, workflow automations, and timeline views. But it's a project tracker, not a product management tool — no spec writing, no feedback ingestion, no AI assistance. And the UI, while improved, still feels like an afterthought compared to dedicated PM tools.
What's missing from all of them:
Spec-level linking. PRs should connect to spec sections, not just tickets. The spec has acceptance criteria the PR should satisfy. The ticket is a pointer — the spec is the contract.
Drift detection. No mainstream tool compares PR content against spec assertions. They link the artifacts; they don't validate them against each other.
Computed status beyond merge. "In progress" should mean "commits in the last 48 hours." If a branch hasn't been touched in a week, the card should flag it as stale — not sit silently in the "In Progress" column until someone notices during standup.
Spec update on merge. When a PR merges, the spec should reflect what shipped. Not manually — automatically. The spec should know that Section 3.2 was implemented, with a link to the PR that did it.
Building This With GitHub Apps
If you want to build this yourself, here's the architecture:
A GitHub App listens to webhook events: create (branches), pull_request (opened, merged, closed), pull_request_review (approved, changes requested). Each event triggers a status update in your PM tool via API.
The linking convention matters. Options:
- Branch naming:
feature/SPEC-123-add-notifications— parse the spec ID from the branch name - PR description: Template that includes a spec reference —
Implements: SPEC-123, Section 3.2 - Commit messages: Conventional commits with spec references —
feat(notifications): add email channel [SPEC-123]
Branch naming is the most reliable because it's set once at branch creation. PR description templates work but depend on the engineer filling them out. Commit messages are noisy and easy to forget.
For drift detection, the GitHub App reads the PR diff and the linked spec, uses an LLM to compare them, and posts a review comment or check annotation with any discrepancies.
The Practical Impact
Teams that implement automatic GitHub-to-board sync report the same outcomes:
Standups get shorter. When the board reflects reality, you don't spend 15 minutes hearing "I updated my card" from six people. The board is already current. Standup becomes "anything blocked?" — which is what it was always supposed to be.
PMs stop asking "what's the status?" The question that every engineer hates. With auto-sync, the answer is always visible. The PM opens the board, sees real-time status derived from actual code activity, and doesn't need to interrupt anyone.
Stale work surfaces automatically. A card that's been "in progress" for two weeks with no commits is a signal — either it's blocked, it's deprioritized, or it's harder than expected. Without auto-sync, this card sits silently until someone notices. With computed status, staleness is flagged automatically.
Drift is caught early. The PM sees a drift flag on a card and can intervene before the PR merges. "The spec says authentication is required on this endpoint, but the PR doesn't include it — is that intentional?" One comment, five minutes, prevents a security gap that would have been caught in production.
Stop Being the Integration Layer
Your brain has better things to do than translating between GitHub and your board. The data exists. The APIs exist. The webhook infrastructure exists. The only reason your board is manually updated is that nobody built the bridge.
Your PM tools don't talk to each other — and the GitHub-to-board connection is the most painful gap. Every engineer updates GitHub as a natural part of their workflow (branches, commits, PRs). Nobody updates the board as a natural part of their workflow. Stop fighting human nature. Let the board read GitHub.