A reusable authorization skill

Example skill · Version 1

Review workspace authorization

Owner

Repository engineering lead.

Trigger

A change reads, creates, updates, or deletes a workspace-owned resource.

Inputs

The agreed specification, changed code, workspace membership policy, resource ownership model, approved test identities, and relevant test commands.

Output

A review record linking enforcement code, checks performed, results, open findings, and the human review decision.

Run these steps

1. Trace the request. Locate the server entry point, authenticated identity, requested workspace, permission check, and resource lookup. Follow the path into the service and persistence layers.
2. Bind permission to ownership. Check that the caller’s role belongs to the target workspace. Check that an existing resource is scoped to that same workspace before it is returned or changed.
3. Challenge the ordinary success case. Use an allowed administrator, a denied member, and an administrator from another workspace. For each case, inspect the response and any state change.
4. Check alternate paths. Follow retries, duplicate handling, and changed background entry points. An early return must preserve the same boundary.
5. Write the review. Attach the actual commands and results, code references, and remaining questions. Let a second engineer decide whether the evidence supports approval.

Stop and ask the owner when

The membership policy is missing, ownership cannot be traced, a boundary check fails, or the required environment cannot run the checks. Keep the finding open and name the missing evidence. Do not replace an unavailable check with an assumed pass.

Try it on the invitation change

Pay particular attention to the duplicate branch. Returning an existing invitation is still a resource read, so it must happen after authorization for the requested workspace. Ask the second engineer to explain that ordering without relying on the author’s narration.

Version 1 adoption check

Have another engineer run the written routine on a second change. Record unclear steps and missing inputs, revise the skill, and retain the reviewed version alongside the repository. Revisit it when the permission model changes.