Share verified, portable AI agent skills across any model

Your team builds up real know-how for getting an AI agent to do a job well: the prompt, the steps, the checks, the gotchas that took three tries to learn. The moment you want to hand that to a teammate or reuse it next quarter, you hit two problems. That know-how usually lives as a file each person copies, so versions drift and no one is sure whose copy is current. And none of the usual ways to share it check whether the work actually met your standard. The instructions travel; the standard and a single source of truth do not.

Goodeye fixes both. It hosts your agent skills, verifies their output against a standard you author, and keeps them in sync across your team, on any model over a CLI, an MCP server, or a REST API. This hub walks through what that means, how sharing actually works, and how a teammate knows the work cleared your standard before they ever read the output.

What hosted, verified, and in sync mean for a shared skill

Three properties make a shared skill trustworthy and reusable, and most stores ship none of them together.

Hosted means the skill lives in one place, not as a file each teammate copies. Goodeye holds the canonical skill: its runbook, its verifiers, and its versions. Point your agent at it and you run the current version, not whatever copy happened to land on someone's disk.

Verified means a check travels with the skill. A Goodeye verifier judges the agent's output against a criterion you wrote, the thing that defines a finished result for the task: the right tone, the correct figures, a format that parses, a claim backed by its source. It runs inside the agent's loop at generation time, so when the output misses, the agent revises and re-runs before a human ever sees it. A teammate who runs your shared skill gets a result already checked, not a hopeful set of instructions.

In sync means a team runs one skill, not five drifting copies. Grant it to a teammate or a team and their agent pulls the hosted skill with its verifiers attached, so everyone runs the same steps against the same checks. Improve the skill and the next run picks up the change, with no file to re-send.

Portability rides along. A Goodeye skill reaches the agent over three peer surfaces (CLI, MCP, REST), so the same skill runs whether the agent sits on Claude, on ChatGPT's models, or anywhere else. Goodeye hosts the runbook and the checks; it does not own the model, and there is no GUI to log into, because the skill runs wherever your agent already runs.

Keep one bit of vocabulary straight as you read on: the thing Goodeye hosts and shares is a skill, a markdown runbook plus its verifiers, and the public form of a skill is called a template.

Here is how the common ways to share agent work stack up on verification and portability, plus forking:

How can my team share and reuse AI agent skills?

A skill starts private to you. Reuse runs on two paths, and you pick by who should get it.

Share it directly with a named teammate or team through a grant. There are three roles in increasing order of capability: view (read, run, and audit the skill), edit (also save new versions, teach, and optimize), and admin (also manage grants). The semantic verifiers a skill references cascade with the grant, so a teammate's agent runs the same hosted skill against the same checks, and because a verifier you can reach is fully readable, collaborators can see and improve the grader instead of guessing at a black box.

Or publish a snapshot publicly as a template under your handle. A template is the public, immutable, versioned form of a skill, addressed as @handle/slug. Anyone, and any agent, can find it, fetch it, and run it. At publish time each verifier the skill references is frozen into the template, so a published template runs against the exact checks you shipped.

To make a shared template your own, fork it. Forking copies a template version into a new private skill you own, with lineage back to the source, so you can edit and tune it without touching the original. The public templates page is where this starts: browse, run one, then fork the ones worth keeping.

Where can I find reusable AI agent skills that are verified to work?

Browse the public templates. Each is addressed as @handle/slug, and you can fetch and run one without an account; you sign in when you want to fork it or save work of your own. Because a published template's verifier definitions are public, you can read exactly how a template grades its output (the criterion and the example pass and fail cases) before you commit to forking it. That is the practical answer to "is this shared thing any good": you can see the standard it holds itself to, then run it and watch the verifier return a verdict.

Already keep local skill files on disk under ~/.claude/skills/? Those are directory-shaped (a SKILL.md plus sibling files), which is exactly what Goodeye imports. Point the publish step at the directory and the local skill file lands as a hosted skill you can then add verifiers to and share.

How do I know a shared AI agent skill actually meets your standard?

This is the part the stores skip. A Claude skill or a custom GPT is a set of instructions. It tells the agent what to do, but nothing checks whether the result cleared your bar. A teammate runs it, it does something plausible, and nobody knows whether it met the standard you cared about.

A verifier is what closes that gap, and Goodeye gives you three types that usually combine in one skill:

• Structural checks confirm the shape: required fields present, valid JSON, the right number of rows. Deterministic, inline in the runbook, free.
• Functional checks run code against the output: a test passes, a number lands in range, a regex matches, a hash compares equal. Also deterministic, inline, free.
• Semantic checks handle the judgments that need reading and reasoning: tone, factuality against a source, whether an image matches a brief. A semantic verifier is one judgment evaluated by an LLM judge, calibrated with a handful of example pass and fail cases so its verdicts stay consistent with yours.

The semantic verifier is the one that matters for subjective work, where there is no test to run. It runs in the agent's loop, returns a pass or fail with the judge's reasoning, and the skill gates its next step on that verdict. When you share the skill, the verifier travels with it, so whoever forks and runs your template gets work held to the same standard. See how verifiers are authored and how a skill wires them in.

How do I share AI agent skills across different models like Claude and ChatGPT?

Stop treating the shared thing as a vendor feature and start treating it as an artifact you own. Host the work once as a model-agnostic skill in Goodeye, not a model-specific one bound to a single vendor, and attach the checks that travel with it.

A Goodeye skill reaches your agent three ways. A coding agent that runs shell commands (Claude Code, Cursor, a CI job) uses the CLI directly. A chat or connector client (Claude on the web, ChatGPT, Claude Desktop) connects over the MCP server. A service or integration calls the REST API with a key. The same operations exist on all three surfaces, so the same skill runs on whichever model your agent uses, and a teammate on a different model runs it the same way.

That portability is what makes shared work outlast a single model. When a better model ships, or your team standardizes on a different one, the skill does not need rebuilding, because it was never bound to the old one. For the side-by-side on how this compares to single-vendor stores, read the vendor-agnostic alternative to Claude skills and the GPT Store.

Where to start

If you want shared agent work that a teammate can trust on sight, you need all three: hosted so your team runs one current copy, verified so it arrives held to your standard instead of merely described, and portable so it runs where your agents run. Browse the public templates and fork one to see the loop in action, or walk through getting started to point your agent at Goodeye and run a shared skill on your own model. The sub-topics below go deeper on each piece.