Fixes for AI search arrive as pull requests in your own repository
Attensira finds the pages AI answers are not citing, writes the fix, and opens a pull request against the repository that page actually lives in. It is a first-party GitHub App, granted only the repositories you select. It never merges, never pushes to your default branch, and never pushes twice.
The agent creates a fresh branch for a single finding and pushes to it once. Your default branch is never written to.
Several repositories per project
Marketing site, docs site and app are usually three repos. Attach all of them and each pull request lands where its page lives.
Labelled and reviewable
Every pull request we open carries the attensira label, and draft mode keeps it out of merge automation until you say so.
We never merge
Merging is yours. A red build or a merge conflict is surfaced on an Inbox row and left there for a human.
The problem is not knowing. It is shipping.
Every tool in this category can tell you that ChatGPT names a competitor and not you. Almost none of them close the loop. The finding lands in a dashboard, someone copies it into a ticket, the ticket waits for a content sprint, and three weeks later the page that was not answering the question still is not answering it. The measurement was never the bottleneck.
If your site lives in a Git repository, the bottleneck is a diff nobody wrote. That is the part Attensira does. The agent locates the file behind the page, writes the change, pushes it to a branch of its own, and opens a pull request against your default branch. From that moment it is an ordinary pull request in your repository, sitting in the review flow your team already uses, with the checks your team already runs.
It is also where the honest limit sits. Attensira does not decide that the change is right. You do, by reading the diff. Nothing lands in your codebase that a person on your side did not merge.
How the connection works
1
Install the GitHub App
From the project's GitHub settings, press Connect GitHub. GitHub takes over and asks which account or organisation to install into. This is a first-party GitHub App: the App is ours, the installation is yours, and it is visible and revocable from GitHub's own settings at any time. It is not an OAuth app, and it is not brokered through a third-party connector.
2
Grant only selected repositories
Choose the repositories whose content you want changed. GitHub holds that list, not Attensira, so changing it later happens on GitHub's installation page rather than inside our product. Anything you did not grant is invisible to the agent.
3
Attach the repositories to a project
Back in Attensira, pick which of the installed repositories this project may open pull requests against. A project can have several. That is the normal case: a marketing site, a docs site and the app itself are often three separate repos, and a finding on your pricing page belongs in a different repository from a finding on a quickstart page.
4
A finding becomes a branch
The agent identifies something to fix on a page — a tracked Prompt the page does not answer, a claim that has gone stale, a page with nothing citable on it — then locates the source file in one of the attached repositories, writes the edit, and pushes it to a branch created for that one finding.
5
A pull request, labelled and watched
It opens the pull request against your default branch with a body saying which page, which finding, and why the edit answers it, and applies the attensira label. Afterwards Attensira keeps reading the pull request state — open, checks failing, merged, closed — and shows it on the matching Inbox row.
What one pull request actually looks like
Here is the shape of a real run, in the product's own vocabulary. A Prompt such as "best CRM for a two-person sales team" is tracked against ChatGPT and Perplexity. Each Prompt, Model and country combination runs at most once per workspace-local calendar day, at a sampling depth of one answer per day on Starter and three on Growth and Business, so a week of runs is a sample of dozens of answers rather than a single lucky one.
Across that window your brand is named in some answers and your own domain is attached as a Citation in fewer of them. Mention rate and Citation rate share the same denominator and Attensira deliberately never collapses them into one score, because the gap between them is the finding: models know you and are not reading your page.
The agent traces the shortfall to a page, finds the MDX file that produces it in the docs repository you attached, and writes an edit that answers the question the Prompt actually asks. It pushes one branch, opens one pull request, applies the attensira label, and stops. Your CI runs. If the build is red or the branch conflicts with something that landed after the pull request was opened, the Inbox row says so and nothing further happens until a human acts.
No number on this page is a performance promise. Models are non-deterministic, and Attensira cannot attribute a mention or a citation to a visit, a signup or revenue — the documentation says so on its limitations page, and so do we.
Four rules that make the diff the whole surface
The point of these rules is that nothing we do can change once you are looking at it. Reviewing our diff is reviewing the final thing.
It never merges a pull request
Merging is a human decision on your side of the line, every time.
It never pushes to your default branch
Every change is on a fresh branch created for one finding.
It never pushes twice to the same branch
One finding, one branch, one push. A pull request we opened is final from our side, which means the diff you are reading is the whole of it. The rule has no exception for fixing our own work: a failed check is surfaced and left, not silently amended.
It never touches CI configuration
No workflow files, and nothing else that changes how your builds run.
Exactly three permissions
Permission
Access
What it is for
Contents
Read and write
Read the files behind a page, and push our branch
Pull requests
Read and write
Open the pull request, and read its state afterwards
Metadata
Read
Mandatory for every GitHub App; lists the repositories you granted
What it does not do
There is no Actions permission, no Administration permission, and no access to your secrets. If GitHub's consent screen shows you something outside the three permissions above, you are not installing our App.
Attensira cannot read your branch protection settings and will not predict what your merge automation does with our pull request. If your repository auto-merges on green, ours will merge too. Draft mode exists for exactly that: with it on, every pull request we open is a GitHub draft, which most merge automation ignores until you mark it ready for review.
A finding whose source file cannot be located does not become a pull request. It becomes an Inbox row saying so, which is the honest outcome rather than a guessed edit in the wrong file.
Disconnecting, or uninstalling the App from GitHub, ends access immediately. Pull requests already opened stay exactly as they are — they are your pull requests, and nothing is closed, withdrawn or rewritten on the way out. What stops is everything future, and the merged, closed and CI state on existing Inbox rows freezes where it was.
Which plans include it
Included on every plan: Starter, Growth and Business.
What does vary by plan is how much evidence sits behind a finding: sampling depth, how many Prompts you can track and how far back your history goes. Those numbers live on the pricing page, read from the same ladder the billing system uses.
