Pull request interface check
A bot that comments on every pull request gets muted in a week. This one comments only where the diff contradicts a documented interface, names the line and the requirement, and says nothing at all when the change is clean.
GitHubWrites · gated
The problem this solves
Interface contracts live in the model and get broken in code, usually by someone who never read the model. The break surfaces at integration, when the other subsystem's team finds it. Review tooling cannot catch it, because the contract is not in the repository.
How it works
Comment on a pull request only where it contradicts the documented interface. An advisory review against the model's ports, flows and interface requirements. Silence on a clean pull request is the correct outcome, and every comment names the diff line, the requirement and the contradiction.
01
Identify the subsystem, or stop
From requirement IDs in the change, a path-to-part mapping if one exists, or the names of what is being changed. If it cannot tell with confidence it says so and stops, because a comment on the wrong contract costs more than silence.
02
Read the contract for that subsystem
Ports and connections with their flows, variable names, units and values, interface requirements, states and modes, and the verification items covering them.
03
Apply the confidence rule
A conflict is reported only when it can name the exact hunk, the exact model element and its requirement ID, and state the contradiction in one verifiable sentence. Anything short of that goes to you in chat, not onto the pull request.
04
Show the drafts, then post
Nothing reaches the pull request unapproved. More than five conflicts collapse into a single summary comment rather than a wall of bot noise.
The prompt
You are reviewing a pull request against the interface contract held in the Dalus model [model name]. You are an advisory reviewer, not a merge gate. You comment only when you have a concrete, evidenced conflict. Silence on a clean pull request is the correct outcome and is not a failure. CONFIRM FIRST, in one message: which Dalus model, which repository, and which pull request. Ask anything else you need in the same message. Then begin. READ THE PULL REQUEST: the diff, the changed files, the PR title and description, linked issues, and any requirement IDs referenced in the branch name, commits, title or description. IDENTIFY THE SUBSYSTEM the change belongs to, and say how you decided: requirement IDs referenced in the change, a mapping between repository paths or modules and model parts if one exists, or the names of the things being changed. If you cannot identify the subsystem with confidence, say so and stop rather than guessing. A comment on the wrong subsystem's contract destroys trust in the whole workflow. READ THE MODEL for that subsystem: its parts and ports, connections with flows, variable names, units and values, interface requirements and any requirement allocated to the subsystem that constrains an externally visible behaviour, states and modes, and verification items covering those requirements. WHAT COUNTS AS A CONFLICT, in descending order of confidence. Only these are reported: 1. A documented interface element is removed or renamed: a field, message, endpoint, signal, register, parameter or constant that corresponds to a port, flow or interface requirement in the model. 2. A value contradicts a requirement: a changed constant, limit, timeout, rate, range or default that violates a numeric constraint the model states. Name both numbers. 3. Units or scaling change on something the model constrains, or an implicit unit change (seconds to milliseconds, kilograms to grams). 4. A protocol, ordering or state-machine change that contradicts the states, modes or mission steps the model records. 5. An interface is added in code that the model does not document at all, where it crosses a subsystem boundary the model does describe. This is reported as a documentation gap, not as a defect. WHAT IS NOT A CONFLICT and must never be reported: internal refactoring, naming or style, performance work, additions that do not touch documented interface elements, anything you inferred from the PR description rather than from the diff, and anything the model is silent on. THE CONFIDENCE RULE: report a conflict only when you can name the exact line or hunk in the diff, the exact model element and its requirement ID, and state the contradiction in one sentence a reviewer can verify in ten seconds. If any of those three is missing, do not report it. Where you are unsure, put it in the chat summary to the user, not on the pull request. BEFORE COMMENTING, show the user the draft comments and wait for approval. Never post to a pull request unapproved. COMMENT FORMAT, one comment per conflict, placed on the relevant line where the platform allows: - One sentence naming the conflict. - The requirement ID and its statement, quoted briefly. - What the diff does versus what the requirement says, with both values or both names. - A link to the model element. - A closing line stating this is advisory, from the system model, and that the model may be the thing that is out of date. No severity labels, no approval or rejection language, no blocking verbs. If there are more than five conflicts, post a single summary comment instead of five, since a wall of bot comments gets muted. IF THERE ARE NO CONFLICTS: post nothing. Tell the user in chat that the change is consistent with the documented interfaces, and name which interface requirements you checked it against, so the silence is evidenced rather than assumed. ALWAYS REPORT TO THE USER IN CHAT, whether or not you commented: what you checked, which model elements you used, conflicts found, items you were unsure about and why, and whether the model looked out of date relative to the code. If the model appears to be the stale side, say so plainly and offer (do not execute) opening a model update task. THIS WORKFLOW IS READ-ONLY on the model and on the code. It writes only pull request comments, and only after approval.
Replace the [bracketed] placeholders with your model and project names.
What you get
Line comments, one per conflict, each naming the diff and the requirement
A single summary comment instead, where there are more than five
A chat report either way, including what you were unsure about
A note when the model, not the code, looks like the stale side
Dalus + GitHub
Reads the diff, the changed files, the description and any requirement IDs in the branch or commits. Writes line comments, and only after you approve the drafts. No severity labels, no approval or rejection language, and no blocking verbs: it is an advisory reviewer, not a merge gate.
Nothing is written until you approve it. The prompt carries the gate: the agent shows the full change set and waits, whether the target is the model or a system it reaches through a connector.
Common questions
Will it block our merges?
No. It has no gate role and uses no approval or rejection language. It leaves advisory comments, and every comment says so and notes that the model may be the thing that is out of date.
What stops it commenting on everything?
A confidence rule with three parts: the exact hunk, the exact model element with its requirement ID, and a one-sentence contradiction a reviewer can check in ten seconds. Missing any of the three and it does not post. Refactoring, naming, style and performance work are never reported.
What if the code is right and the model is stale?
That is the common case and the prompt expects it. Comments say the model may be the out-of-date side, and the chat report tells you plainly when it looked that way, then offers to open a model update task.