Page fixes arrive as pull requests on your repository
With the Attensira GitHub App installed, the crew ships each page fix as a draft pull request, labelled attensira, on the repository your page lives in. It never pushes to your default branch and touches no CI files. A merge happens when you press Merge, or on its own for safe changes you set to auto-merge.
7 days free · card required
BlockedWrote the full pull request body: before and after verbatim, the evidence, and a line on why you might reject it. Needed: the repository path that serves attensira.com.
Choices: Connect GitHub
Our repository is not connected yet, so the crew wrote the pull request and stopped instead of guessing.
Web engineerattensira.com workspace, read over the Attensira MCP · - Web engineer · Finds the file behind the page, writes the edit on a fresh branch and opens the pull request.
Analyst · Re-reads the prompts attached to a merged fix at +7, +14 and +30 days.
How does a finding become a pull request?
One finding, one branch, one push. Nothing the crew does can change once you are looking at it, so reviewing the diff is reviewing the final thing.
A finding
The crew finds something worth fixing on a page: a tracked question the page does not answer, a stale claim, nothing citable. A finding whose source file it cannot locate becomes an Inbox row, not a guess.
The source file
It finds the file that produces the page in the repositories you attached, even when the site is not at the root. A marketing site, docs and app in three repositories is the normal case.
A branch and a pull request
It writes the edit on a new branch used once, and opens a pull request against your default branch saying which page, which finding and why this edit answers it.
You review and merge
Approving the change opens the pull request; merging is a second, separate yes. The Inbox shows the live diff, checks and deploy preview, then Mark ready for review and Merge.
What does a pull request from the crew look like?
A draft on a fresh branch, labelled attensira, with the checks your repository runs. A line that states a fact about you, like a price, is flagged as a claim and waits for you, even when you have switched on auto-merge for safe edits.
Answer “How much does Ledgerly cost?” at the top of /pricing
attensira3 checks passedclaim waits for you: names a price
content/pricing.mdx
- unchanged: # Pricing
- added: Ledgerly starts at $12 per seat a month, with a 14-day trial.
- unchanged: Every plan includes unlimited invoices and clients.
Web engineer · Opened the pull requestExample · Ledgerly, a fictional brandWhat may the crew change, and what may it not?
Every change is classed from the diff itself, never by the agent about its own work.
| Safe changes | Structured data, meta and social tags, alt text, internal links and heading levels. In Act mode, or with auto-merge for safe changes switched on, these may go ahead without asking. |
|---|---|
| Claims | A price, a percentage, a number with a unit, a promise word, a competitor or product name, rewritten heading words. These wait for a person in every mode. |
| Source files | In .ts, .tsx and .js only the words inside string literals, and always as a claim. Import paths, directives and any other code are refused. |
| Never | Your default branch, a second push to one branch, CI configuration or workflow files. There is no Actions, Administration or secrets permission. |
| Your merge automation | New connections open pull requests as GitHub drafts, which most auto-merge rules ignore, and every one carries the attensira label for a rule on your side. |
| No repository access? | The fix arrives as new wording to paste, with Request access from my developer: a draft email in your own mailbox with the install link and the three permissions. |
What does the GitHub App never do?
Opening pull requests is the whole of its write access. These limits have no exceptions, including for fixing its own work.
- It never pushes to your default branch; every change is on a fresh branch of its own.
- It never pushes twice to a branch. A red build or a merge conflict is shown on the Inbox row and left for a person.
- It never touches CI configuration, workflow files or anything that changes how your builds run.
- Merging is a signed-in person's click in the dashboard. The REST API and MCP cannot merge or mark a pull request ready.
- A closed pull request declines the work and is not opened again, unless you reopen it.
What do engines say a tool that opens pull requests is?
Perplexity on 3 Oct reads “GEO tool that opens pull requests” as geospatial code: GeoTools docs and GitHub repositories. Nobody has written the page that answers the question as meant, which makes it one to write.
Question: GEO tool that opens pull requests
Perplexity answered: A GEO tool that opens pull requests is typically any platform or integration that creates and manages PRs directly from GEO-enabled workflows, often via a repository hosting service or CI/CD action. For example, you can open PRs from GitHub repositories related to GEO projects using the platform’s standard pull request flow.
Sources cited
- 1docs.geotools.org
- 2, 3, 5, 6, 7, 8, 9, 10github.com
- 4ansvisor.com
Not namedAttensira is missing from this Perplexity answer.
Researcher · Stored the answerattensira.com stored Perplexity answer, read over the Attensira MCP · · 10 linksWhat else do people ask about the GitHub App?
Can Attensira merge a pull request on its own?
Which permissions does the App ask for?
My site is a Next.js app in a monorepo. Does that work?
What happens after a fix merges?
Does it work with Lovable?
Install the App. Review the first pull request this week.
7 days free · card required