Using Veripsa with Codex, Copilot, and Claude-style agents

You do not need this rule for Veripsa to work. If an agent can already merge pull requests, you may put the following lightweight guidance in a file it already reads — such as CLAUDE.md or AGENTS.md — so it interprets the advisory consistently:

## Optional Veripsa advisory guidance

Veripsa automatically posts its check and comment after the GitHub App is
installed. No agent-side setup or per-PR command sequence is required.

If this agent already participates in merges, use the Veripsa signal as
advisory context:

- Clear to land is not merge approval. Continue the normal review, CI, and
  branch-protection path.
- Heads up or Wait in line names related open work. Report the suggested order
  before merging out of order.
- Paused (acknowledge to proceed) is a material collision waiting for a human.
  Do not merge past it or add the acknowledgement label yourself; hand the
  decision to a human. Acknowledged means a human already recorded it.
- Unknown, missing, pending, or stale is not Clear. Ask a human when the
  distinction affects the merge decision.
- Only a GitHub ruleset or branch-protection policy can make the check block a
  merge. Veripsa does not block merges by itself.
- The `veripsa-ack` label is an optional, auditable human override. Never add
  it unless a human explicitly asks you to record that decision.

Prefer a raw file? Open the pasteable AGENTS.md template. This does not add a Veripsa command ritual. It only helps a merge-capable agent read the same GitHub PR signal a human would.

If your GitHub plan and organization settings support GitHub-native coding-agent workflows, keep the work inside GitHub: write an issue, assign or mention the agent, let it open a branch and pull request, then continue changes in the PR comments. Veripsa does not care which agent produced the PR. It watches the open PR traffic and posts the merge-control signal in GitHub.

Keep your existing operating path. Veripsa posts into the pull request automatically. Avoid asking agents to bypass CI, branch protection, or required checks.

• Clear to land — no overlap Veripsa can see with other open PRs. Continue the normal review, CI, and branch-protection merge path.
• Heads up — this PR may overlap another; read the comment, and if it is fine, proceed. Advisory, not a stop.
• Wait in line — a likely or direct collision is ahead, and the comment names which PR should land first. Land in that order (one agent rebases onto the other once) instead of merging out of order and redoing work after both land.
• Paused (acknowledge to proceed)— a material collision posted with GitHub's action_required conclusion. It is waiting for a human decision: never merge past it or add the veripsa-ack label yourself. Acknowledged means a human already recorded that decision.
• Unknown— Veripsa cannot tell (an unsupported area, or context still becoming available). It is an honest “don’t know,” not a guarantee there is no collision — treat it as a prompt to check with a human.

If the Veripsa check is missing, still pending, failing to load, or older than the PR state you are about to merge, do not treat that as Clear to land. Re-run once or ask the human.

When two open PRs touch the same code, Veripsa suggests which one to land first — the more foundational change, so the other revises once rather than twice. Following that order is where most of the saved rework comes from: the second PR rebases onto the first cleanly, instead of both landing out of order and someone re-doing the overwritten change later.

Normal advisory use requires no acknowledgement. If your team wants an auditable record that it deliberately proceeded past a specific overlap, adding the veripsa-acklabel records that decision. Use it as a conscious call — “I have seen this specific overlap and am landing deliberately” — not as a reflex to silence the check. It records an acknowledgement, not an approval; if the overlap later changes, Veripsa surfaces the signal again. In your agent rule, reserve the label for an explicit human decision.

By default the check and its comment appear but do not block the merge button — the heads-up itself is the value, and you stay in control. If you want a Wait in line to actually hold a merge until it is acknowledged, mark the Veripsa check as a required status check in your GitHub branch protection. Your branch-protection policy is the enforcer; Veripsa stays advisory. (On private repos, required checks need a paid GitHub plan; public repos get them free.)

One concern per PR keeps the overlap signal tight. A sprawling PR that touches ten files overlaps more open work and gives you a noisier heads-up; a small, single-purpose PR gives a precise one — and lands faster, so it frees the lane for the PRs queued behind it.

Veripsa is advisory — it does not hard-block a merge by itself, and it does not review your code for bugs or design (that is a different job). It is content-free: it never stores or shows your source file bodies, only the minimal metadata needed to run the advisory (see Trust). It coordinates pull requests within a single repository today. Free to install — add it to your repo with no agent-side setup required. Add the rule above only if it matches your team's existing merge automation.