Share verified, portable AI agent skills and workflows 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. Most ways to share agent work lock it to one vendor's product and one vendor's models. And none of them check whether the shared work actually met your standard. The instructions travel; the standard does not.

Goodeye fixes both. It shares AI agent work as a workflow that is verified and portable: held to a bar you author, and runnable 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 "verified and portable" mean for shared agent work

Two properties make shared work trustworthy and reusable, and most stores ship one without the other.

Verified means a check travels with the work. 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 work gets a result already checked, not a hopeful set of instructions.

Portable means the work is not tied to one model or one vendor's store. A Goodeye workflow reaches the agent over three peer surfaces (CLI, MCP, REST), so the same workflow runs whether the agent sits on Claude, on ChatGPT's models, or anywhere else. Goodeye does not own the model; it owns the runbook and the checks. There is no GUI to log into, because the workflow runs wherever your agent already runs.

Keep one distinction straight as you read on. A "skill" is the SKILL.md authoring format that packages instructions for an agent. The thing Goodeye stores and shares is a workflow: a markdown runbook plus its verifiers. When you share a workflow publicly, that public form is called a template.

How can my team share and reuse AI agent skills and workflows?

A workflow 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 workflow), edit (also save new versions, teach, and optimize), and admin (also manage grants). The semantic verifiers a workflow references cascade with the grant, so a teammate's agent can run 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 workflow, addressed as @handle/slug. Anyone, and any agent, can find it, fetch it, and run it. At publish time each verifier the workflow 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 workflow 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 agent skills 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, supply an outcome, and the skill lands as a private workflow 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 workflow:

• 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 workflow gates its next step on that verdict. When you share the workflow, 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 workflow 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. Author the work once as a model-agnostic workflow, not a model-specific skill or GPT, and attach the checks that travel with it.

A Goodeye workflow 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 workflow 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 workflow 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 both halves: portable so it runs where your agents run, and verified so it arrives held to your standard instead of merely described. 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 workflow on your own model. The sub-topics below go deeper on each piece.