access-review

name	access-review
description	Run a semi-automated Probo access review campaign. Use when the user wants to review access entries, decide approve/revoke/escalate, or resume an in-progress campaign with MCP and .probo/access-reviews/ notes.
compatibility	Requires Probo MCP (OAuth 2.0) and file write access for .probo/access-reviews/

Access review

Run a semi-automated access review for campaign $ARGUMENTS (or ask the user for the campaign name). Review entries only — do not create, start, cancel, or close campaigns.

Before executing, read these files relative to this skill directory:

• references/mcp-tools.md — MCP tool names, inputs, pagination
• references/decision-rubric.md — semi-auto decision rules
• references/notes-format.md — working memory file schema

Preconditions

1. A Probo MCP server must be connected. The plugin ships two hosted servers, probo-us and probo-eu; self-hosted instances are configured in the agent. If tools fail with auth errors, stop and tell the user to complete OAuth sign-in for that server (Claude Code: /mcp or claude mcp login probo-us; Codex: codex mcp login probo-us; OpenCode/Cursor: configure MCP in settings then authenticate).
2. Resolve the server, then the organization. These are separate choices: one server can hold several organizations, and the caller can have organizations on more than one server. Settle both before any campaign call, because listAccessReviewCampaigns requires organization_id.
   • Server. Use the server for the region the user names, or the only connected server when there is one. Otherwise call listOrganizations on each connected server and take the server whose organizations uniquely match the one the user named. Never infer the region from a merely non-empty result — when the match is not unique, show each server with the organizations it returned and ask which to use.
   • Organization. Once the server is settled, call listOrganizations on it unless an earlier probe already returned its organizations. Take the unique name match, or the only organization when the server returns one. Otherwise list them and ask the user to pick.
3. Resolve the campaign from $ARGUMENTS (name match or GID) within that organization. If the campaign is ambiguous, list listAccessReviewCampaigns results and ask the user to pick one.
4. Campaign status must be IN_PROGRESS or PENDING_ACTIONS. Stop with a clear message for DRAFT, COMPLETED, or CANCELLED.

Working notes file

Create or resume .probo/access-reviews/<campaign-slug>.md per references/notes-format.md. Create .probo/access-reviews/ if missing.

Workflow

1. Orient

• Call getAccessReviewStatistics for the campaign.
• Summarize totals and pending count for the user.
• If no pending entries, report completion and stop.

2. Fetch batch

• Call listAccessEntries with campaign_id, filter.decision: PENDING, size: 50.
• Use last_cursor from the notes file when resuming.

3. Classify each entry

Apply references/decision-rubric.md:

Class	Action
Auto	Queue for recordAccessReviewEntryDecisions
Ambiguous	Present to user; do not write yet
Skip	Log in notes only (no API write)

Hold auto decisions in memory until step 4 succeeds — do not append them to the notes file yet.

4. Write auto decisions

• Batch via recordAccessReviewEntryDecisions when possible.
• Non-APPROVED decisions must include decision_note.
• On MCP error, stop and do not advance last_cursor or update entry notes.
• After a successful API response, append each recorded auto decision to the notes file ## Entry notes table.

5. Present ambiguous entries

Show email, roles, flags, proposed decision, rationale. Record only after explicit user confirmation.

6. Checkpoint

Update notes: last_cursor, session log, updated_at. Ask to continue if next_cursor is set.

Hard rules

• Never call closeAccessReviewCampaign or campaign setup mutations unless the user explicitly requests setup work outside this skill.
• Never invent entry IDs or decisions — use MCP responses only.
• Never record non-APPROVED without decision_note.