> ## Documentation Index
> Fetch the complete documentation index at: https://docs.attensira.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Fix your site from Claude Code or Cursor

> Let the coding agent in your repository ask Attensira for patches to the pages that lose answers, apply them, and ship them, with each fix checked afterwards.

> [!WARNING]
>
> **Not on MCP yet.** `POST /v1/plan-fixes` is served on `api.attensira.com` and on `webapp.attensira.com`. The MCP server does not list `plan_fixes` yet, so an agent calls it over HTTP. A workspace on its trial can plan fixes too: planning a fix is drafting it, which a trial runs, and the planned changes ship only on your yes.

If your site lives in a repository, the coding agent you already use (Claude Code, Cursor, or any agent that can make an HTTP call or an MCP call) can fix the pages that lose answers. Attensira plans the fix; your agent applies it. We never write to your repository.

## How it works

1. Your agent sends the files it has open to [`POST /v1/plan-fixes`](https://docs.attensira.com/api/endpoints#post-/v1/plan-fixes), the REST twin of the `plan_fixes` verb.
2. Each file is planned against your workspace's red questions, the ones the engines answer without naming you. It comes back as a unified diff that `git apply` accepts, beside a change filed in your workspace (`origin: ide`, `status: drafted`).
3. Your agent applies the diff, you review it as you would any change, and it is committed.
4. Your agent calls [`act`](https://docs.attensira.com/api/endpoints#post-/v1/actions) with `ship` on the change and `{"commit_sha": "..."}`. The change is marked live on the page it was planned for, and its checks are scheduled at +3, +7, +14 and +30 days.
5. Each check reads the engines again; the change's receipt says what moved, or that nothing moved that we can prove.

## Before you start

* **A key with the right scopes.** `plan_fixes` needs `steer` and, on an API key, a `spend` scope; `act` with `ship` needs `steer`. Mint one under [API keys](https://docs.attensira.com/account/api-keys.md) and keep it out of the repository: put it in your shell's environment, not in a committed file.
* **Credits.** One credit per file that comes back with a patch, never more than `max_credits` (default 10). A file sent again unchanged, a file that moved, a file already carrying its patch and a file that comes back without a patch cost nothing.
* **Which paths may be patched.** Only paths inside your workspace's `act_path_allowlist` are ever patched. Site and build configuration (`package.json`, `*.config.*`, `vercel.json`), CI, lockfiles and dotfiles never are; they come back in `skipped` as `outside_allowlist`.

## Over REST

Any agent that can run a shell command can call the route. Send each file whole, with its git blob id, so a patch always applies to the bytes it was made from:

```bash Shell theme={null}
SHA=$(git hash-object src/pages/pricing.md)
curl -s https://api.attensira.com/v1/plan-fixes \
  -H "Authorization: Bearer $ATTENSIRA_API_KEY" \
  -H "Content-Type: application/json" \
  -d @- <<EOF
{
  "repo_context": {
    "framework": "astro",
    "routes": ["/pricing"],
    "files": [{"path": "src/pages/pricing.md", "sha": "$SHA", "excerpt": $(jq -Rs . < src/pages/pricing.md)}]
  },
  "max_credits": 5
}
EOF
```

Each entry in `patches` carries `path`, `diff` and `change` (its `uri`). Save the diff and apply it:

```bash Shell theme={null}
git apply pricing.patch && git commit -am "Name Acme on the pricing page"
```

Then ship it against the commit:

```bash Shell theme={null}
curl -s https://api.attensira.com/v1/actions \
  -H "Authorization: Bearer $ATTENSIRA_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: ship-$(git rev-parse HEAD)" \
  -d '{"ref": "attensira://ws_51ab/change/6650...", "action": "ship", "payload": {"commit_sha": "'"$(git rev-parse HEAD)"'"}, "idempotency_key": "ship-'"$(git rev-parse HEAD)"'"}'
```

## From Claude Code or Cursor

[Connect the MCP server](https://docs.attensira.com/mcp/connect.md) to your editor, and give the agent the key in its environment for the REST call. Then ask in plain words, for example:

> Ask Attensira for fixes to the pages in `src/pages` that lose answers. Send each file whole with its `git hash-object` sha to `POST /v1/plan-fixes`. Show me each diff before you apply it. After I commit, ship each change with `act` and the commit sha.

The agent reads the answer's `next` field, which says the same steps: apply, commit, then ship with `commit_sha`. The [MCP changelog](https://docs.attensira.com/mcp/changelog.md) says when `plan_fixes` joins the MCP tool list; until then the agent calls the REST route.

## When a patch no longer applies

You do nothing. Call `plan-fixes` again with the files as they are now:

* A file whose content changed is planned again, and its change is revised in place (`regenerated: true`, same change).
* A file that moved keeps its change, which now names the new path (`moved_from`).
* A file that already carries its patch is skipped as `applied`, pointing at the change to ship.

`skipped[].reason` names every other case, such as `underway` (a change to this file is already approved or on its way: ship or decline it first) or `budget_reached`.

## What it will not do

* It never pushes, commits or opens a pull request in your repository. Your agent and you do that.
* It never patches configuration, CI, lockfiles or dotfiles, or a path outside your allowlist.
* It never marks anything live on its own. A change is live when your agent ships it, and a ship that turns out false only reads as `not_live` on its checks.

## Related

* [`POST /v1/plan-fixes`](https://docs.attensira.com/api/endpoints#post-/v1/plan-fixes): every field and every skip reason.
* [MCP verbs](https://docs.attensira.com/mcp/tools.md#the-verbs)
* [Connect the MCP server](https://docs.attensira.com/mcp/connect.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.