Approvability

Disabled by default. Enable per repo in Settings → Repos → Approvability.

How It Works

When a PR is opened or updated, Macroscope evaluates up to three criteria before auto-approving. Ownership (via CODEOWNERS) is disabled by default; Eligibility and Correctness are always active. All active criteria must pass for auto-approval — if any fail, the PR can still be approved manually.

The verdict

Every PR gets a comment leading with one of four verdicts, followed by a sentence giving Macroscope’s own assessment of the PR and the reasoning behind it. The verdict is what happened to the PR; the assessment is Macroscope’s view of it, and the two are separate because a PR Macroscope finds approvable can still go unapproved because of how your workspace is configured.

Verdict	Meaning
Approved	Approvable, nothing blocking, and automatic approval is on. Macroscope posted a real GitHub approval.
Would Approve	Approvable, but something held it — automatic approval is off, an ownership requirement, outstanding correctness findings, a correctness review that could not report, or a correctness review a limit stopped from running. The comment lists everything blocking it.
Not approved	The eligibility agent judged the PR not a candidate for automatic approval, and says why.
Skipped	Macroscope reached no verdict at all — a protected path, a diff too large to analyze, an unparseable result, or a spend limit that stopped the check itself.

A Would Approve verdict is not a hedge on your code: Macroscope found the PR eligible and is telling you which setting or requirement stopped the approval.

1. Eligibility

Is this PR a good candidate for auto-approval? Macroscope evaluates the changes, code ownership, git blame history, and the author’s role. If your repo has a CODEOWNERS file, Macroscope factors in the author’s relationship to changed files.

Typically eligible: docs, tests, code behind feature flags, simple bug fixes, copy changes.
Not eligible: large refactors, schema changes, security/auth/billing code, breaking changes.

2. Correctness

Are there unresolved correctness findings at or above your repo’s Minimum Blocking Severity? By default, correctness is a hard gate: an unresolved correctness finding at or above your repo’s Minimum Blocking Severity blocks automatic approval. Resolving the final blocking review thread clears that gate automatically. If nothing else blocks approval and automatic approval is enabled, Macroscope approves the PR without requiring a new commit or Approvability run.

If resolving the final blocking thread does not update an existing PR, rerun Approvability once from the Checks tab.

The way to disable this is to set Minimum Blocking Severity to Off, which stops outstanding comments from automatically blocking approvability. The approvability agent then makes a non-deterministic evaluation based on all the information available, including outstanding correctness comments — so it may still return Not approved on their merits. Your custom instructions control how it weighs them; see also Letting Eligibility decide correctness instead, which tells the agent to leave correctness out of the judgment altogether. By default, a correctness review that cannot report blocks as well: if the review finds issues but is unable to post them, Approvability reports Would Approve rather than approving on findings nobody can see, and says so explicitly: the assessment was made without those findings, and the missing review is listed as a blocker. Off covers this case too — it removes the deterministic failure whatever the review found, and whether or not it managed to post it — as does telling Macroscope to ignore correctness in your guidelines. With either, Eligibility decides alone. Whether a review that never ran blocks depends on why it never ran, and the line is not about severity:

You turned it off — correctness disabled for the repo, an excluded target branch, a skipped author, or simply no reviewable code in the PR. Nothing was owed, so nothing is missing: these never block, and approvals continue exactly as before.
A limit stopped it — a spend limit, a cost limit, an exhausted credit balance, or the per-PR cap on automatic reviews. Here a review was expected and did not happen, so Macroscope is missing an input it normally weighs. These now hold the PR at Would Approve rather than approving without it. See When a limit stops the correctness review.

Comments an earlier review already posted still count either way: they stay outstanding until resolved, so a review that never ran does not clear a blocker a previous one raised — and if there are such comments, they are what the PR is held on, not the missing review.

When a limit stops the correctness review

If a spend limit, cost limit, credit balance, or the per-PR cap on automatic reviews stops a correctness review from running, that PR is held at Would Approve instead of being approved. Macroscope normally weighs a correctness verdict when deciding approvability; a limit means the review was expected and did not happen, so the verdict is missing rather than clean. This is not a severity question, and there is nothing in the PR to fix — no finding was produced. The comment names the limit that stopped the review and links the setting that clears it:

What stopped it	What clears it
Monthly spend limit, or an exhausted credit balance	Raise the limit or add credits in Billing settings. A manual review does not help here — the workspace cap applies to it too.
Per-review or per-PR cost limit	Raise the limit in Billing settings, or comment `@macroscope-app review this PR` to bypass the limit and review this PR now.
Per-PR cap on automatic correctness reviews	Raise the limit in repo settings, or comment `@macroscope-app review this PR` to bypass the cap and review this PR now.

Repos that have correctness disabled are unaffected and keep approving as before — see the two cases listed under Correctness above. A repo that hits a limit stops auto-approving until the limit clears or is raised; once a correctness review runs again, the next Approvability run approves normally.

Both ways of taking correctness out of the gate cover this too. With Minimum Blocking Severity: Off, or with custom rules telling Macroscope to ignore correctness, a limit-stopped review does not hold the PR — Eligibility decides alone, and the comment notes that no correctness review stood behind the verdict.

When a limit stops the Approvability check itself

The section above is about a limit stopping the correctness review — Approvability still runs and holds the PR at Would Approve, naming the missing input. A limit can also stop Approvability itself, which looks different: there is no verdict and no comment, only a check run concluded skipped.

What stopped it	What you see	What clears it
Monthly spend limit, or an exhausted credit balance	The check is concluded skipped, naming the limit	Raise the limit or add credits in Billing settings
Correctness per-PR cost limit	The check is concluded skipped, reporting what the PR has cost so far against the cap	Raise the cap in Billing settings, or comment `@macroscope-app review this PR`

A skipped check never fails, so using Approvability as a required status check will not block a merge because a limit was reached — a red check nobody on the PR can turn green would only block the wrong person. Worth knowing about the per-PR cost limit specifically: it totals only Code Review spend on the PR. Approvability’s own spend does not add to it, so Approvability can be stopped by a cap it never contributed to. This applies to every workspace, including one that has never touched the setting — the Correctness per-PR cap cannot be turned off and defaults to $50. That is intentional rather than an oversight. Approvability reads the correctness review’s findings to reach a verdict, so once the cap has stopped correctness on a PR, continuing to run Approvability would produce a verdict from incomplete input — worse than reporting no verdict at all. The separate Check Run Agents per-PR limit does not affect Approvability. Reaching it stops agents on the PR and leaves the Approvability check alone. See What the Correctness per-PR cap counts. The Eligibility agent runs even when correctness is already blocking. Its verdict cannot change the outcome, but it tells you something correctness cannot: whether Macroscope would have approved the PR but for the findings, or would have held it anyway. That is the difference between a Would Approve verdict and a Not approved one.

Minimum Blocking Severity

Minimum Blocking Severity is a per-repo setting that controls which severity of unresolved correctness comments blocks auto-approval. Outstanding correctness comments at or above the configured severity block approval; comments below the threshold do not. Choose from Low, Medium, High, Critical, or Off — the default is Medium. Off removes the deterministic gate entirely: correctness never fails a PR on its own, whatever the review found — 🔴 Critical included — and whether or not it managed to post it. Two things it does not do:

It does not silence correctness review. Findings are still posted on the PR as usual; they just stop holding up approval by themselves.
It does not override the Eligibility agent. The agent still runs, still sees the findings, and still reports its view — so a 🔴 Critical finding describing a real defect can still send the PR to human review, on the strength of what it says rather than its badge.

That second point is the distinction worth holding on to: Off removes the automatic block, not the judgment. If you want correctness excluded from the judgment as well, use Letting Eligibility decide correctness instead. Find it in Settings → Repos → Approvability (shown once Approvability is enabled). Only a GitHub Admin can change it. A comment counts as outstanding until its review thread is resolved on GitHub, or the comment is deleted. Comments with no recorded severity are treated as Medium. The threshold applies to the Eligibility judgment as well: a Macroscope correctness comment below it does not, on its own, send the PR to human review. Comments at or above the threshold still do, and so does anything else that warrants review — a comment from a human reviewer or another tool, or the nature of the changes themselves.

Check Run Conclusion

Check Run Conclusion is a per-repo setting that controls how the approvability check reports a PR it does not approve: Neutral (the default) or Failure. It is the settings-page equivalent of the conclusion front matter field, for teams that cannot commit .macroscope/approvability.md into every repository.

Neutral — the check is informational. It reports the verdict and never blocks merging.
Failure — the check fails, so adding Macroscope - Approvability Check as a required status check blocks the merge until the PR becomes approvable. Only the two outcomes the author can clear ever fail — a Not approved verdict, and outstanding correctness findings at or above your Minimum Blocking Severity. A Skipped verdict never fails, whatever this is set to. Neither does a correctness review a limit stopped: it holds the PR at Would Approve but concludes Neutral, because the author cannot clear a workspace limit and a red check they cannot turn green would only block the wrong person.

Everything documented under Using approvability as a required status check applies identically however you set it, including the full list of outcomes on each side and how a failure is cleared. In particular, PRs held by protected configuration paths still conclude Neutral, so this setting can never make a configuration PR unmergeable. Find it in Settings → Repos → Approvability (shown once Approvability is enabled). Only a GitHub Admin can change it. It also has a workspace default and can be applied across many repos at once from Settings → Repos with repos selected — the same batch flow as Minimum Blocking Severity.

Front matter always wins. If .macroscope/approvability.md sets conclusion, that value applies and this setting is ignored for that repo — including conclusion: neutral, which is how a single repo opts out of a workspace-wide Failure. A file that omits conclusion does not override anything, so repos keep whatever the setting says even when they have guidelines for other purposes.The workspace default seeds newly added repos. Changing it does not move repos that already exist — batch-edit them for that.

Letting Eligibility decide correctness instead

This is the stronger of the two ways to stop correctness from gating approval, and unlike Minimum Blocking Severity: Off it is not a setting: state it in your custom eligibility rules. If your .macroscope/approvability.md explicitly says correctness issues must not factor into approvability, Macroscope stops treating correctness as a gate for that repo and lets the Eligibility judgment weigh the findings on its own:

Correctness issues and bugs found by code review must NOT factor into the
approvability decision. Judge this PR on the nature of the change alone.

This has to be explicit about correctness issues or bugs. Guidelines that only mention external reviewers’ comments do not qualify, and silence or ambiguity leaves the gate on. The difference from Off is what each asks of the agent: Off stops correctness from failing the PR automatically but leaves the agent weighing the findings, whereas this tells the agent to leave them out of the judgment altogether. It also keeps the choice visible in the repo rather than in a settings page.

Results appear as Macroscope - Approvability Check in the Checks tab and as a PR comment with detailed reasoning.

Custom Eligibility Rules

Add a .macroscope/approvability.md file to your repo to define rules on top of the defaults. Your custom rules are additive — they are combined with the built-in eligibility criteria, not a replacement.

Plain text rules

The simplest approach is a plain markdown file with your rules:

If a PR changes files in any of the following paths, DO NOT auto-approve:
- services/auth
- services/billing
- targets/auth

Front matter configuration

For more control, add YAML front matter to configure the approvability agent’s behavior:

---
tools:
  - github_api_read_only
  - modify_pr
conclusion: neutral
---

If a PR changes files in any of the following paths, DO NOT auto-approve:
- services/auth
- services/billing
- targets/auth

If the verdict is "not approved" and the PR touches services/auth/,
request a review from @security-team.

Supported fields

Field	Default	Description
`tools`	`[]`	Additional tools for the approvability agent. The agent always has file browsing and git tools; this field adds more capabilities.
`conclusion`	Check Run Conclusion setting, or `neutral`	Controls the check run result when a PR is not approved. `neutral` (recommended) means the check is informational — it never blocks merging. To gate merge on human approval, use GitHub’s required reviewers. `failure` makes the check hard-block merge via required status checks — see caveats before enabling. `failure` does not apply to PRs held by protected configuration paths, which always conclude `neutral`. Setting this field here overrides the Check Run Conclusion repo setting; omit it to let that setting apply.
`waitsFor`	Correctness, Check Run Agents & external review tools	Additional check run names that must complete before approvability runs. Even when unset, approvability automatically waits for the Correctness check, every Check Run Agent on the commit, and recognized third-party review tools (Cursor BugBot, Greptile) before deciding — this field adds prerequisites on top of those. Supports `["*"]` wildcard to wait for all check runs. See Waiting for Other Checks.
`waitsForTimeout`	`20`	How long to wait for prerequisites to finish, in minutes (`1`–`60`). Only meaningful when `waitsFor` is set.
`waitsForDiscoveryTimeout`	`1` (60 seconds)	How long to wait for a prerequisite to appear on the commit before treating it as absent, in minutes (`1`–`60`). Raise this when a check is published conditionally or late — see Check Run Agents for the full explanation and the trade-off. With named prerequisites it is a deadline and costs nothing once they appear; with `waitsFor: [""]` it is a floor paid on every run*, so every PR’s verdict is delayed by that window — that combination warns on the check run page. Capped at `waitsForTimeout`. Only meaningful when `waitsFor` is set.
`neverApprove`	`[]`	Additional paths that are never auto-approved when a PR changes them. Glob patterns, same syntax as Check Run Agent `include`/`exclude`. This list only ever adds to the always-on protection on your approvability file — see Protecting review configuration.
`alwaysApprove`	`[]`	Paths that skip the eligibility agent, but only when every file the PR changes matches one of them. Glob patterns, same syntax as `neverApprove`. Skips the agent, not the other approval conditions — see `alwaysApprove`.

Available tools

Tools extend what the approvability agent can do beyond its defaults (file browsing and git tools):

github_api_read_only — search code and read GitHub metadata
modify_pr — request reviewers or post PR reviews
slack — post messages to Slack channels
launchdarkly — check feature flag status
web_tools — search the web
issue_tracking_tools — query linked Jira/Linear tickets

The modify_pr tool enables instructions like “request a review from @security-team when the verdict is not approved.” Without it, the agent can only analyze and report — it can’t take actions on the PR.

Waiting for other checks

By default, approvability waits for the Correctness check, any Check Run Agents, and recognized third-party review tools (Cursor BugBot, Greptile) before making its decision, so their findings are considered in the verdict. Use waitsFor to also wait for additional CI steps — for example, linters, deployment checks, or other external tools not covered by the built-in list — whose results should influence the approval verdict. Wait for specific checks:

---
waitsFor:
  - "CI / lint"
  - "Macroscope - Security Review"
conclusion: neutral
---

If CI lint or the security review flagged issues, DO NOT auto-approve.

Wait for all checks (wildcard mode):

---
waitsFor:
  - "*"
---

Consider findings from ALL CI steps when deciding whether to auto-approve.

Wildcard mode waits for every check run on the commit except Macroscope - Approvability Check itself. This is useful when you have multiple Check Run Agents posting review comments and want approvability to consider all of their findings. Custom timeout: The default wait is 20 minutes. Set waitsForTimeout to change it (1–60 minutes):

---
waitsFor:
  - "deploy-to-staging"
waitsForTimeout: 45
---

A prerequisite also has to appear on the commit within a shorter discovery window (60 seconds by default) or it is treated as absent. If one of your checks is published conditionally — behind an earlier job, or by a workflow queued while a previous run is still cancelling — set waitsForDiscoveryTimeout to give it longer:

---
waitsFor:
  - "pre-commit / pre-commit"
waitsForDiscoveryTimeout: 10
---

The cost of a longer window is that a check which never appears at all takes that long to give up on. See Check Run Agents for the full explanation. Combining a longer window with waitsFor: ["*"] costs more than that. With named prerequisites the window is a deadline for appearance — once they appear the window is over, and the wait continues only until they conclude — but a wildcard wait has no names to look for, so it must outlast the window before it can conclude that every check on the commit has finished. Every PR’s approvability verdict is then delayed by at least that window, whether or not anything was actually published late. That combination warns on the check run page; it is a warning rather than a refusal, because for a check that really is published that late it may be what you want. Behavior summary:

Scenario	What happens
Prerequisites complete	Approvability proceeds with its eligibility assessment, considering review comments posted by the waited-for checks.
Prerequisite never appears within the discovery window (60 seconds by default)	The prerequisite is treated as absent and approvability proceeds. Check that the name in `waitsFor` matches the check run name exactly as it appears on GitHub; if the step is real but published late, raise `waitsForDiscoveryTimeout`.
Prerequisite does not complete within timeout	Approvability proceeds without waiting further. Increase `waitsForTimeout` if the step is slow.
Circular dependency	Detected at parse time. For example, if a CRA has `waitsFor: ["Macroscope - Approvability Check"]` and approvability has `waitsFor: ["*"]`, the cycle is detected and the affected CRA skips with a descriptive error.

Approvability always waits for the Correctness check and recognized third-party review tools (Cursor BugBot, Greptile) regardless of waitsFor — this field controls additional prerequisites beyond those built-in waits. Named mode supports up to 10 entries.

Using approvability as a required status check

Most teams should leave conclusion at the default (neutral) and use GitHub’s required reviewers to gate merge on human approval. The approvability check surfaces the verdict; the reviewer requirement does the blocking. This is the simplest and most predictable setup.

If you want the approvability check itself to hard-block merge when a PR is not approved, turn the conclusion to failure and add Macroscope - Approvability Check as a required status check in your branch protection rules. There are two ways to turn it on, and they behave identically from here on:

Set the Check Run Conclusion repo setting to Failure. This needs no file, has a workspace default, and can be applied to many repos at once.
Set conclusion: failure in .macroscope/approvability.md front matter. This is per-repo, lives in source control, and overrides the setting.

Be aware of how GitHub handles this combination. When the check concludes failure (merge blocked). Only two outcomes fail the check, and both are ones the author can clear by acting on the PR:

The approvability agent returned a verdict of Not approved.
Correctness findings are posted on the PR and still outstanding at or above your repo’s Minimum Blocking Severity. Setting that to Off removes this outcome entirely, leaving the agent’s verdict as the only way the check fails.

When the check concludes neutral or skipped (merge NOT blocked). GitHub counts success, skipped, and neutral as passing a required status check. Approvability deliberately concludes neutral instead of failure whenever the hold is something the author cannot clear by changing the PR — failing on those would leave the PR permanently unmergeable:

The PR modifies .macroscope/approvability.md, modifies a path protected by neverApprove (see Protecting review configuration), or modifies CODEOWNERS without owning it.
The diff is too large to analyze, or the agent returned no usable response.
Correctness could not report: it found issues but was unable to post them, reached no verdict, or never ran.
The PR was authored by Macroscope, or auto-approval is switched off for the repo.
The approvability agent itself errored or timed out.

It concludes skipped — likewise passing — when approvability is disabled for the PR (draft PR, repo setting off, skipped author), when a billing or usage limit is reached, and when a push leaves the diff unchanged (for example a rebase, where the prior analysis is reused).

conclusion: failure gates on the verdict, not on availability. If the agent errors, times out, hits a usage limit, or otherwise cannot reach a verdict, the check concludes neutral and GitHub allows the merge — it is not a fail-closed gate. If you need a PR to stay blocked whenever Macroscope cannot decide, use GitHub’s required reviewers instead.

Clearing a failure. How you clear it depends on which of the two outcomes failed the check.

Outstanding correctness findings — resolve them. Resolving the final blocking thread clears the correctness gate automatically. If nothing else blocks approval, Macroscope updates the Approvability check and comment and, when automatic approval is enabled, approves the PR. Reopening a blocking thread withdraws that approval.
A Not approved verdict — re-trigger the check. Resolving comments says nothing about that verdict, so the conclusion stands until approvability re-evaluates the PR: a new commit, a re-run from the Checks tab, or an @macroscope mention.

One thing that looks like it should clear a failure does not: a PR review approval alone does not clear a failing required status check. GitHub treats approvals and status checks as independent gates, so a human approval leaves the check exactly where it was.

The legacy path macroscope_approvability.md at the repo root is still supported for backward compatibility, but .macroscope/approvability.md is the recommended location. Front matter is only supported in the .macroscope/approvability.md path — the legacy path treats the entire file as plain text rules.

Protecting review configuration

Macroscope reads .macroscope/approvability.md from the pull request’s most recent commit, so an edit takes effect in the PR that makes it. A PR that changes the rules Macroscope approves by should not then be approved using the rules it just changed. Two things prevent that.

Your approvability file is always held for a human

Any PR that adds, edits, renames, or deletes .macroscope/approvability.md (or the legacy macroscope_approvability.md) gets the verdict Skipped, automatically — the eligibility agent never runs on it. Macroscope decides this before the approvability agent runs, so nothing written in the file — custom rules, front matter, or instructions to approve config changes — can change the outcome. This is always on. There is no setting that turns it off, and that is deliberate: it is what makes your own neverApprove list trustworthy. What the hold protects is the eligibility rules — the instructions the agent reads to decide whether a PR is approvable. Those live only in the file, so editing them always goes through code review. Check Run Conclusion is not one of them: it changes how a verdict is reported, never how it is reached, and it can only ever make the check stricter than the neutral default. That is why it is safe to expose as a setting, and why the rules themselves are not.

`neverApprove` — additional protected paths

Use neverApprove to extend that protection to any other path you want a human to look at:

---
neverApprove:
  - .macroscope/ignore.md
  - .macroscope/check-run-agents/**
  - .github/workflows/**
  - CODEOWNERS
---

Approve routine dependency bumps and documentation changes.

Any PR that changes a file matching one of these patterns gets the verdict Skipped, without the agent running. Patterns use the same glob syntax as Check Run Agent include/exclude: a pattern with no / matches at any depth (CODEOWNERS matches CODEOWNERS and docs/CODEOWNERS), and ** matches across directories. Matching is case-sensitive. A pattern Macroscope cannot parse is skipped, with a warning in the check run details — check there after editing the list, since a skipped pattern protects nothing. Renames and deletions count as changes to both the old and the new path, so moving a protected file out of the way still holds the PR.

neverApprove can only add paths. It cannot remove or narrow the protection on your approvability file, and no setting can — and it takes priority over alwaysApprove, so a path in both lists is held. This is also why the list is safe to trust: a PR cannot quietly delete an entry from it without editing .macroscope/approvability.md, which is itself always held for a human.

What these holds do — and don’t do

A hold from either rule means the PR is not auto-approved and is marked Skipped. It does not block merging on its own: these checks conclude neutral even when you have set conclusion: failure — in front matter or through the Check Run Conclusion setting — so a PR that updates your Macroscope configuration can never be made unmergeable by the check itself. Merge protection stays with your GitHub required reviewers rules, which is where it belongs — a human reviews the change and merges it. For the full list of what concludes failure versus neutral, see Using approvability as a required status check.

`alwaysApprove` — skipping the agent for routine paths

Some changes do not need a judgment call. Lockfile bumps, vendored dependencies, generated code, a translations directory — if a PR touches nothing else, there is nothing for the eligibility agent to weigh. alwaysApprove names those paths. When every file a PR changes matches one of the patterns, Macroscope finds the PR approvable without running the agent, and the run is free:

---
alwaysApprove:
  - "**/*.lock"
  - vendor/**
  - "**/*.pb.go"
---

Approve routine dependency bumps and documentation changes.

All, not any

This is the opposite of how neverApprove matches, and the difference is the point. neverApprove fires when any changed file matches — one protected file is enough to hold the whole PR. alwaysApprove fires only when every changed file matches. A PR that updates vendor/ and changes your scheduler is not a vendor PR, so it goes to the agent exactly as it would have. That also means a partial match costs you nothing and changes nothing. If you are unsure whether a pattern is too broad, the worst case is that PRs you expected to skip the agent do not. Renames count as changes to both the old and the new path, so moving a file out of a covered directory is not covered — the destination is a path you did not list.

What it skips, and what it does not

alwaysApprove skips the eligibility agent. It does not skip anything else that has to be true before Macroscope approves a PR:

Still applies	Effect
Correctness findings at or above your Minimum Blocking Severity	The PR is not approved. The verdict is Would Approve.
Approvability not enabled for the repo	The PR is not approved. The verdict is Would Approve.
The PR was authored by Macroscope	The PR is not approved. The verdict is Skipped.
Every wait — Correctness, Check Run Agents, external review tools, `waitsFor`	Approvability still waits for all of them before deciding.

One hold does not apply. A diff too large to analyze does not stop a fully covered PR: that hold exists because the agent cannot read the change, and on these paths there is nothing for it to read. A large vendored dependency bump is exactly the shape that is both too big to analyze and entirely covered. The review still runs. What you are switching off is the judgment about whether the change is worth a human’s attention, not the analysis of whether it is correct.

Precedence

Three rules are evaluated before alwaysApprove, and none of them can be overridden by it:

Your approvability file. A PR that adds, edits, renames, or deletes .macroscope/approvability.md is held for a human — including the PR that adds alwaysApprove itself. See Protecting review configuration.
neverApprove. If a path appears in both lists, or a PR matches both, neverApprove wins and the PR is held.
CODEOWNERS changed by a non-owner. Held, unchanged.

So alwaysApprove: ["**"] — “approve everything” — still cannot approve a PR that rewrites your approval rules, cannot strip a protection you added, and cannot clear a CODEOWNERS change. The ordering is what makes the list safe to write.

Patterns use the same glob syntax as neverApprove and Check Run Agent include/exclude: a pattern with no / matches at any depth, ** matches across directories, and matching is case-sensitive. A pattern Macroscope cannot parse is skipped, with a warning in the check run details — check there after editing the list, since a skipped pattern means files it would have covered go back to the agent.

Pricing

Approvability is billed in agent credits at a flat 30 credits ($0.30) per run. The price does not depend on the size of the PR or on what the run cost to produce — every verdict costs the same. You are only charged when a verdict needs the agent. Whenever Macroscope can reach the verdict on its own, no agent runs and the run is free:

Outcome	Charge
The Eligibility agent judged the PR	30 credits
The PR changes your approvability configuration	Free
The PR matches a `neverApprove` pattern	Free
Every file in the PR matches an `alwaysApprove` pattern	Free
The PR changes `CODEOWNERS` and the author is not an owner	Free
The diff is too large to analyze	Free

Most free runs show a Skipped verdict, but the two are not the same thing. If the agent ran and could not return a usable verdict, the result is Skipped and the run is still charged — what you pay for is the agent being asked, not the verdict it managed to produce. Every approvability check run states what it cost on its details page, including the runs that cost nothing:

**Agent Credits:** 30 credits
Approvability runs at a flat rate of 30 credits whenever the agent is asked for a verdict.

Approvability draws on the same balance and the same 1000 free credits per month as every other agent feature, and is subject to your workspace’s monthly spend limit and per-PR cost limit. When either limit is reached the check run is marked Skipped with the reason, and nothing is charged.

The $0.30 figure is the price at the standard rate of $0.01 per credit. Workspaces on a negotiated credit rate pay 30 credits at their own rate.

Setup

Enable Approvability in Settings → Repos.
(Recommended) Add a CODEOWNERS file to your repo.
(Optional) Add a .macroscope/approvability.md file with custom eligibility rules and front matter configuration.

Macroscope cannot approve its own PRs.

Getting Started

Agent

Code Review

Status

Support

How It Works

The verdict

1. Eligibility

2. Correctness

When a limit stops the correctness review

When a limit stops the Approvability check itself

Minimum Blocking Severity

Check Run Conclusion

Letting Eligibility decide correctness instead

Custom Eligibility Rules

Plain text rules

Front matter configuration

Supported fields

Available tools

Waiting for other checks

Using approvability as a required status check

Protecting review configuration

Your approvability file is always held for a human

`neverApprove` — additional protected paths

What these holds do — and don’t do

`alwaysApprove` — skipping the agent for routine paths

All, not any

What it skips, and what it does not

Precedence

Pricing

Setup

​How It Works

​The verdict

​1. Eligibility

​2. Correctness

​When a limit stops the correctness review

​When a limit stops the Approvability check itself

​Minimum Blocking Severity

​Check Run Conclusion

​Letting Eligibility decide correctness instead

​Custom Eligibility Rules

​Plain text rules

​Front matter configuration

​Supported fields

​Available tools

​Waiting for other checks

​Using approvability as a required status check

​Protecting review configuration

​Your approvability file is always held for a human

​neverApprove — additional protected paths

​What these holds do — and don’t do

​alwaysApprove — skipping the agent for routine paths

​All, not any

​What it skips, and what it does not

​Precedence

​Pricing

​Setup

How It Works

The verdict

1. Eligibility

2. Correctness

When a limit stops the correctness review

When a limit stops the Approvability check itself

Minimum Blocking Severity

Check Run Conclusion

Letting Eligibility decide correctness instead

Custom Eligibility Rules

Plain text rules

Front matter configuration

Supported fields

Available tools

Waiting for other checks

Using approvability as a required status check

Protecting review configuration

Your approvability file is always held for a human

`neverApprove` — additional protected paths

What these holds do — and don’t do

`alwaysApprove` — skipping the agent for routine paths

All, not any

What it skips, and what it does not

Precedence

Pricing

Setup