GitHub delivery

Close the loop from decided to shipped

Your roadmap knows what you decided to build. It rarely knows what actually got built. Zentrik links GitHub pull requests to the ideas and initiatives that started them, so delivery finally lives next to the decision.

See it in your workspace or schedule a walkthrough

The gap

Deciding lives in one system. Building lives in another.

Product tools are good at turning signals into decisions. Whether the decision actually shipped has always lived somewhere else, in GitHub, invisible to the tool that made the call.

Without the loop

A roadmap full of decisions, and no reliable answer to the simplest question a stakeholder asks. Did we ship it?

With the loop

Every initiative shows the work in flight and the work that reached production, tied to the pull requests that delivered it.

How it works

Your engineers already say what a pull request delivers

Zentrik listens to the one place they already write it, then does the filing. No new tool, no status column to keep alive.

Deterministic today. The same records are ready for smarter matching as the loop matures.

01
Name the work in the pull request
One line, the way you would reference an issue: Zentrik: closes IDEA-42. A branch named jab/idea-42 works too.
02
A webhook does the filing
The moment the pull request opens or merges, Zentrik records the link and keeps it current. There is no board to maintain and no status column to drag.
03
Delivery lands next to the decision
The idea that was a plan now shows what is in flight and what reached production, on the same page as the evidence and the reasoning that started it.

Wiring it up? Read the GitHub setup guide for the trailer convention, delivery states, and admin steps.

Precision

Careful on purpose, because a wrong link is worse than none

pull request body

feat: ship the delivery timeline

Mirrors the approach we sketched for IDEA-138 in the docs.

Zentrik: closes IDEA-42

Only the trailer line counts. The prose mention of another idea is ignored.

closes vs relatesIt links what you meant, not what you mentioned: The verb decides the intent. closes completes the idea; a bare mention or an explicit relates just connects. A pull request that merely talks about an idea in prose never claims to finish it.
merge ≠ productionA merge is not a customer seeing it: Zentrik reads your release rhythm from history and separates a merge, a pre-production release, and code that is actually live. It matches how your repository works instead of assuming one flow.
suggests, never decidesStarts are facts, completion is your call: The first open pull request moves work to in progress, because that is simply true. Marking something done stays a suggestion, because whether the work satisfied the decision is a judgment only you should make.

Environments

Zentrik knows a merge is not the finish line

Most teams merge to a staging branch and promote to production on their own cadence. Zentrik reads that rhythm from your release history, so an initiative reads as delivered only when the work truly shipped. Repositories without a promotion flow are treated simply, where merged means shipped.

The bigger picture

Delivery closes a loop that starts at the first signal

Zentrik already carries a signal from raw feedback to a shipped decision. Delivery is not a tracker bolted on the side. It is the stage that turns we decided to build this into here is proof we did, and feeds the next decision.

Bring GitHub into the room where you decide what to build

Connect the repository where your product actually gets built, and watch your roadmap start answering the question everyone asks.