Share an AI agent skill privately and revoke access

You have built a skill that gets an AI agent to do a real job well: the runbook, the verifiers that hold its output to your standard, the gotchas you only learned by hitting them. Now one specific person needs it. A new engineer joining the team, a contractor for a three-week project, a teammate in another timezone. You do not want to publish it to the world, and you do not want to email a file that immediately drifts out of date and skips your checks. You want to hand this person access to the real, current skill, and be able to take that access back later. This guide walks through exactly how to do that: grant a named person or team access at the right role, and revoke it when it should end.

Private by default, shared by grant

A Goodeye skill is private to you the moment you save it. It is not listed anywhere, and no one else can fetch or run it until you say so. There are two ways to share, and they answer different questions.

A grant gives a named user or team access to your private skill. Nothing goes public; you name who gets in, at what role, and you can revoke it. This is the path for a teammate, a contractor, or your team.

A published template is the public, immutable form of a skill, addressed as @handle/slug, that anyone can find and fork. That is the right tool when you want reach, not access control. If that is what you are after, see sharing verified, portable skills and the public templates page instead. The rest of this guide is about grants.

The distinction matters because most "how do I share this" advice reaches for a public directory or store. Grants are the opposite: no public surface, a specific recipient, and a revoke command.

Share with one person

To share with a single teammate, grant them access by email, @handle, or user UUID:

goodeye skills grant my-skill alice@example.com view

The three arguments are the skill (its name or UUID), the grantee, and the role. Alice is emailed a link to the skill, and from then on her agent pulls the hosted version over the CLI, an MCP server, or the REST API, with the skill's verifiers attached, so she runs exactly what you authored and checked. You cannot grant a role higher than your own. The same operation is available as the grant_skill MCP tool and as POST /v1/skills/{id_or_slug}/grants over REST.

Choose what they can do: view, edit, admin

Every grant carries one of three roles, in increasing order of capability. Pick the least that does the job.

Give a teammate who just needs to run the skill view. Give someone improving it edit. Reserve admin for people who should be able to re-share it. The verifiers a skill references cascade with the grant automatically: a view grant lets the grantee read and run those verifiers, and edit or admin lets them deploy new verifier versions too. Because a verifier you can reach is fully readable, a collaborator can see and improve the grader instead of guessing at a black box. See skills for the full role reference.

Share with a whole team at once

When more than one person needs a skill, grant it to a team instead of granting each person separately. Create the team once, add members, then grant the skill to the team handle:

goodeye teams create my-team
goodeye teams add-member my-team @alice
goodeye skills grant my-skill @my-team view

Every current and future member gains the role you set on the grant, so onboarding a new engineer is a single add-member away from them running the team's skills, with no re-granting per skill. Adding a member creates an invitation the recipient accepts with goodeye invitations accept <id>; see Teams for the full member and invitation flow. When a person holds several grants (a direct one plus a team one), the most permissive access wins.

Give a contractor access, then revoke it

The reason to prefer a grant over a copied file is that a grant is revocable. Here is the full arc for a time-boxed engagement.

Grant the contractor the minimum role, usually view:

goodeye skills grant my-skill @contractor view

By default the grant is version-floored: the contractor sees the version that was current when you shared and any later ones, but none of the earlier history. If you deliberately want to share the full version history, pass --include-history. A later role change does not re-scope what they can already see.

Check who currently has access at any time:

goodeye skills grants my-skill

The listing shows each grantee, their role, whether the access came through a team, and the history scope. When the engagement ends, revoke the direct grant:

goodeye skills revoke-grant my-skill @contractor

Revoking removes their access to the skill and, with it, the cascaded access to the skill's verifiers. The contractor can also drop their own access with goodeye skills leave my-skill if they no longer need it. Note that leave and revoke-grant only remove a direct grant; if someone still has access through a team, remove them from the team (or revoke the team's grant) to fully cut it off. Every one of these operations is also available as an MCP tool (grant_skill, revoke_skill_grant, list_skill_grants, leave_shared_skill) and over the REST API.

Where to start

If you need to hand one person or one team access to a skill without posting it publicly, the pattern is: keep the skill private, grant the named recipient the least role that does the job, and revoke when it should end. Grants keep everyone on the same hosted version with its verifiers attached, so shared work stays current and stays checked. Point your agent at Goodeye with getting started, then read the skills sharing reference and Teams for the full detail on roles, version floors, and cascaded verifier grants.