A pull request passes every existing check: unit tests, integration tests, lint, type-check, a coverage floor, the security scanner. The reviewer approves. The PR merges. Two weeks later, during a production incident, the team discovers that the change quietly violated a declared constraint about cache coherence that nobody on the PR had context for. The bug was not caught by any check, because none of the checks knew about the constraint. The constraint existed, in Ribo, as a declared artifact. No automation connected the declaration to the merge gate.
That disconnect is a specific kind of failure. Every other quality dimension your team cares about has a CI check behind it. Declared intent does not, because there is no off-the-shelf GitHub Action that consumes MCP. The fix is not a new Action; it is a pattern that composes what already works.
There is no first-party MCP client in Actions
As of this writing, GitHub does not publish an actions/mcp-client or a similar first-party consumer. There is github/github-mcp-server, but that is the opposite direction: it exposes GitHub's data over MCP to external agents, not MCP servers to Actions workflows.
The working pattern uses what is already in the ecosystem. Claude Code ships as a GitHub Action via anthropics/claude-code-action, with claude_args that accept a --mcp-config flag. GitHub's Copilot coding agent carries its own MCP configuration, so any workflow that triggers the coding agent inherits its MCP sources. Either can become the thing that runs during CI and consults Ribo.
The pattern we recommend uses Claude Code, because it is the simplest to reason about as a workflow step: a self-contained runtime that reads the PR diff, reads Ribo through MCP, and emits a verdict.
What a DNA-conformance check actually is
Think of the check as one more layer in your CI pipeline, not a replacement for any existing check. Tests verify that code does what it says. DNA-conformance verifies that what the code says is consistent with what the team declared the system should be.
Concretely, the workflow step does four things. It takes the diff from the PR. It asks Claude Code to identify which declared artifacts govern the changed code paths. It asks Claude Code to evaluate whether the changes are consistent with those artifacts, with specific attention to constraint, contract, algorithm, compliance, and evaluation layers. It returns a structured verdict: which artifacts were consulted, which conflicts (if any) were identified, and whether the PR should be considered conformant.
The output is a CI check that appears alongside your existing checks. When conformance fails, the failure includes artifact citations. The developer reading the failure knows which declaration the change contradicts and can either adjust the code or propose an update to the declaration. Both are legitimate resolutions; what mattered was that the disagreement became visible before merge.
Role-appropriate projection for a CI agent
CI runs under an organization-owned token, not a developer token, which means the trust surface is slightly different. The agent running inside the Action has no interactive user; it reads the diff, makes its queries, and emits a verdict. This cleans up two trade-offs that a developer-laptop token has to live with: the secret lives in GitHub Actions secrets with proper rotation, and there is no risk of a developer machine being compromised and exfiltrating the token.
Ribo's DNA splits into thirteen layers. For the CI conformance agent, expose eight: intent, contract, algorithm, evaluation, compliance, constraint, tradeoff, and glossary. This is a tighter cut than the review projection used for CodeRabbit. The CI agent makes a conformance judgment, not an authoring recommendation, so it does not need integration artifacts the way a coding agent does; it does need evaluation, so it can reason against the rubric the reviewer will apply next.
Withhold integration, monitor, reporting, pace, and escalation. Integration matters more for authoring agents than for conformance judgment. Monitor, reporting, pace, and escalation are operational and not review-time concerns.
Mint a separate github-actions token with its own allowed_kinds list, so audit logs cleanly separate which calls came from which surface.
How to wire it up
First, mint the CI token in the Ribo console. Go to Agents, create an agent named github-actions-<org>-<repo>. Set scopes to artifact:read. Set projectIds to the Ribo project covering this repository. Set allowed_kinds to the eight-layer CI projection: intent, contract, algorithm, evaluation, compliance, constraint, tradeoff, glossary. Capture the bearer token.
Second, store the token in GitHub Actions secrets. Add it to the repository's secrets (or the org's, for reuse across repositories) under a name like RIBO_MCP_TOKEN. Rotate on your normal cadence.
Third, create an .mcp.json file in the repository that Claude Code will read. The file is small: one entry pointing at Ribo, authenticated by the secret.
| File | Contents |
|---|---|
.mcp.json (repo root) | Defines a single ribo server entry with type: "http", url: "https://mcp.ribo.dev/context/mcp", and an Authorization: Bearer ${RIBO_MCP_TOKEN} header. |
Fourth, add the conformance step to your workflow. The step invokes anthropics/claude-code-action@v1 with a prompt that describes the conformance task, points at the .mcp.json file via claude_args: "--mcp-config .mcp.json", and has access to the PR diff through the normal Actions context. The action emits Claude Code's response; you decide whether to treat a failed conformance check as blocking (branch protection) or advisory (a visible comment without blocking merge). Most teams start advisory and tighten to blocking once they trust the signal.
The Claude Code GitHub Actions docs cover the current action inputs and permissions model and should be considered authoritative for the YAML schema.
What the conformance check looks like on a PR
When a conformance check runs against a normal PR that is internally consistent, it emits a green check and a short summary: "Reviewed against three artifacts; no conflicts detected." The developer sees it alongside the other green checks and moves on.
When a conformance check detects drift, it emits a red check and a structured comment: "This PR modifies the cache invalidation path in pkg/session/handler.go. Contract artifact ct_cache_coherence declares that session writes must invalidate the paired profile entry before returning. The current change returns before invalidation, which will produce stale-read behavior on the next profile fetch. Consider routing through writeSessionWithInvalidation() from pkg/cache/coherent.go, which the contract references as the canonical write path, or proposing an update to the contract if the coherence guarantee is no longer intended."
The comment is verbose by design. The developer needs enough context to know whether the right next step is to change the code or to propose a revised declaration. Both are valid; the conformance check is not a veto, it is a visibility step.
What this gets you at scale
Every check you add to CI is a contract with your future self: a class of bugs you promise will never merge silently again. DNA-conformance is that contract for decisions the team has declared. The bugs it catches are the ones where a change slipped past review because the reviewer did not hold the context the declaration captured. Over months, those bugs are some of the most expensive a team ships, because by the time they fire in production, the context that would have caught them is even further away than it was at review.
Gating merges on conformance is not an additional tax on developers. It is an automated version of the work a careful reviewer does when they happen to have time, done consistently, with citations. It is the missing layer in the CI pipeline for teams that have done the work of declaring intent.
GitHub Actions does not have a native MCP client. Claude Code running inside a workflow step does. Plumb Ribo through it and declared intent becomes a required check, not an optional conversation.