Every team has rules about what may change and who has to approve it. Most of them live in someone's head, in a wiki, or in a file an AI agent may or may not read. Smeldr keeps them as three things it can keep track of and put in front of the right person.
Decisions are what you have decided, for example "we never log session tokens". A Decision is proposed, and then ratified by someone with the right to. Once ratified it cannot be edited. If it changes, a new Decision replaces it, and the old one stays on record.
Roles say who may do what. Someone with the right to ratify decides which Decisions stand. An area-approver can approve a change in one part of your code. You can give an AI agent that right for one Area, for as long as you say, and take it back whenever you like.
Rules tie it to your code. An Area covers paths in a repository, for example everything under deploy/. The Decisions you place in an Area, in its Domain or on the Organization govern those paths. The Area's approval mode says what happens to a change that touches them: it only gets a comment, it must be approved before it merges, or it is checked after the merge.
When a pull request arrives, Smeldr's GitHub App works out which Decisions apply to the files it touches, lists them (by address) on the pull request, and puts the change in front of the right approver. Smeldr does not read your code against the text of the Decisions. The approver does that, and an approver can be a person or an AI agent that a person has given the right. The check reports the approver's answer to GitHub. In an Area that requires approval, you make that check required in GitHub's branch protection, and from then on GitHub will not merge the pull request until the approver has answered. If the change touches nothing covered, the check passes and nobody is bothered. The approver answers from the command line or over MCP.
We tried it on a public test repository, Smeldr/gated-merge-test, with three pull requests. The approver was a person.
The first touched a covered file. It waited, the approver said yes, and it merged.
The second touched the same files. The approver said no and gave a reason, and it was never merged.
The third touched files in an Area we had set to check after the merge. It went in straight away, and three seconds later Smeldr raised a flag for the approver: this was merged without a yes.
Every answer is kept with who gave it, whether that was a person, an agent or a job, and the reason when one was given.
Set it up. You need a GitHub App and a few environment variables on your own Smeldr server. You write no code. The steps are in the setup guide. Two things to know: use core v1.176.0 or later, and give the App the permission "Pull requests: read and write", because Smeldr leaves one comment on each pull request.
Released in core v1.175.0 with smeldr.dev/github v0.1.0.