OpenAgentSkill: a resolver and trust layer for Agent Skills, not another registry

The gap OpenAgentSkill is aimed at: choosing a Skill, not finding one

Agent Skills are easy to publish and, as the README puts it, increasingly hard to evaluate. That sentence is the whole product thesis. A repository can be popular, recently updated and well documented and still be the wrong choice for a particular agent task, and none of those three signals tells an agent whether the Skill's install path is safe to run unattended. OpenAgentSkill positions itself as the decision layer between discovery and execution rather than a static directory. The audience is therefore narrow and specific: teams running Codex, Claude Code or Cursor agents that pull in third-party Skills, and who need the selection step to be inspectable after the fact. If a human reads every Skill before it is installed, most of this is overhead. The value appears when the install decision is made by the agent itself.

Resolve, rank, receipt: the pipeline the README documents

The flow diagram in the README is short enough to follow literally. An agent task hits the Resolve API, which performs candidate retrieval, then applies task fit plus Trust Score v5, then returns a best Skill with alternatives, an audit and install receipt, a sandboxed agent run, and outcome feedback that loops back into ranking. Ranking is described as combining task relevance with repository evidence, install readiness, maintenance, license clarity, risk signals and real agent outcomes. Two details in that list matter more than the rest. Install readiness implies the resolver knows how a Skill is meant to be installed and can emit that command, which is what makes the receipt meaningful rather than decorative. Real agent outcomes means the ranking is partly a function of reported runs, which is a feedback loop and also a dependency: the loop only carries signal if agents actually report. The public Resolve Evals page is named as the evaluation surface, but the README does not describe its methodology, so how the scoring is validated is not something I can confirm from this material.

The HTTP surface: one GET, three formats, one POST back

The integration path is deliberately small. The README's copy-ready block tells an agent to call GET https://www.openagentskill.com/api/agent/resolve with query parameters task, agent, max_risk and format, inspect the recommended skill, alternatives, Trust Score v5, audit URL, risk level, install command and install receipt, then after one narrow run POST the outcome to /api/agent/outcome. The same resolver is offered as JSON, plain text and a compact lockfile format, and the demo uses format=text with max_risk=medium and agent=codex. The max_risk parameter is the interesting one: it is a client-side declaration of tolerance, so an agent can refuse to be handed anything above medium. Whether the server enforces that as a filter or merely annotates the result is not stated. The outcome endpoint takes fields visible in the SDK example: event_id, skill_slug, task, outcome and dry_run. The README lists successful, failed, blocked and setup-required as outcome states, and setup-required is the honest one, since a Skill that fails because the environment lacked a dependency is not the same as a Skill that fails on its own terms.

Running the CLI: a pinned tarball, not an npm install

The documented install is unusual and worth reading twice. Rather than npm install, the README runs the CLI straight from a GitHub Release tarball via npx, pinned to cli-v0.3.0: npx --yes https://github.com/Leon-Drq/openagentskill/releases/download/cli-v0.3.0/openagentskill-0.3.0.tgz resolve "extract tables from PDF reports" --agent codex. The same pinned URL is reused for find "browser automation", add <skill-slug> --agent codex --dry-run, and outcome-contract. Pin-by-URL means the version is explicit in every invocation and there is no registry resolution step, which is a reasonable posture for a tool that inspects other tools. It also means every command line is long enough that teams will wrap it in a shell alias or a script, and that alias becomes the real version pin. The CLI is described as refusing blocked Skills, requiring explicit confirmation before execution, and supporting --no-telemetry. The --dry-run flag on add is the one I would use first: it produces a reviewed install plan without executing anything. Source and usage detail are said to live in packages/cli/README.md, which is not reproduced here.

The SDK is source-first, and the README says so

The TypeScript SDK is dependency-free and lives in packages/sdk. The README example imports from a relative path, './packages/sdk/openagentskill.mjs', constructs a client with a baseUrl, calls client.resolve('audit a repository', { agent: 'codex', maxRisk: 'medium' }) and then reports an outcome using plan.feedback.event_id and plan.recommendation.best_skill.slug. That relative import is the tell: the README states the SDK package is prepared for npm publication but is not presented as published until the public registry release is verifiable. So today the realistic consumption path is vendoring the .mjs file or using the CLI. That is a fine choice for a small surface, and it removes a supply-chain hop, but it also means upgrades are manual. If you vendor the SDK you own the diff. There is no version negotiation, no lockfile for the SDK itself, and no deprecation channel other than reading the repository.

Where this breaks down: the trust score is mostly self-reported evidence

The most important limitation is stated by the project itself. OpenAgentSkill does not claim third-party code is safe, and it helps agents make a better, inspectable decision before installation. A Trust Score v5 is therefore a triage input, not a verdict, and treating it as a gate would be a misreading of what the README promises. The second limitation is the feedback loop. Ranking incorporates real agent outcomes, but outcomes are posted by the same agents doing the installing, with no described verification step in this material. A Skill that reports success because its dry run completed is not the same as one that succeeded on a real task, and the SDK example passes dry_run: true alongside outcome: 'success', which is exactly the kind of pair a scoring system has to distinguish carefully. The third is coverage: the resolver can only rank what has been indexed, and nothing here describes the crawl or submission pipeline in enough detail to estimate how much of the Skill ecosystem is represented. Finally, the model assumes network access at decision time. An air-gapped or offline agent run cannot call the Resolve API, and the README offers no local index or cached snapshot as a fallback.

Compared with the obvious alternative: a curated list plus manual review

The alternative most teams actually use is a hand-maintained allowlist of Skills, reviewed once by a person and pinned by commit hash, with no resolver in the loop. The difference in approach is where the judgement lives. An allowlist encodes a decision made in advance by a human and is cheap to enforce, but it does not scale to a task the list did not anticipate, and it goes stale silently. OpenAgentSkill moves the decision to request time and makes it task-specific, which is strictly more expressive, and pays for that with a dependency on a live service and on scoring you did not build. The honest framing is that these are complementary: an allowlist is a policy, a resolver is a search. A team that already has a tight allowlist gets less from OpenAgentSkill than a team whose agents are picking Skills off the open web today. The project's own Skill Packs page, which composes reviewed Skills into reusable workflows, is closer in spirit to the allowlist model, and the README does not explain how a pack's review status relates to an individual Skill's Trust Score.

Maintenance, licence and what to check before adopting

The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission text are retained; that is a description of the licence terms, not legal advice, and anyone embedding the resolver in a shipped product should read the LICENSE file and the terms of the hosted API separately, since the MIT grant covers the code and not the service. On maintenance cost, the visible surface is small: a CLI at 0.3.0 with three releases between August and September 2026, an SDK that is source-only, and an HTTP contract. The recurring cost is not upgrading the client, it is the outcome reporting. If you adopt the loop, you are committing to emit outcome events, and a loop that nobody feeds degrades into a plain search index. The CLI's --no-telemetry flag suggests telemetry is on by default, so decide deliberately which mode you are in rather than discovering it later. Before adopting, check the resolve endpoint against your own task phrasing, read one audit URL end to end to see whether the evidence behind a score is legible to you, and confirm the outcome contract with the CLI's outcome-contract command, since that command exists precisely to make the reporting schema explicit.

Editorial conclusion

Adopt OpenAgentSkill if your agents install third-party Skills unattended and you want a single HTTP call that returns a ranked candidate, a risk level and a receipt you can log before anything executes. Do not adopt it as a security control: the README states plainly that the project does not claim third-party code is safe, so a low risk level is a triage signal, not a clearance. Before wiring it into a pipeline, verify three things yourself: that the resolve endpoint returns a usable answer for your own task phrasing, that the audit URL behind the recommended Skill points at evidence you can read, and that the outcome POST is something your environment permits, since the CLI exposes --no-telemetry and you need to know which path you are on.

Frequently asked questions

Official sources

1. Leon-Drq/openagentskill on GitHub
2. License: MIT
3. Project website
4. README
5. Releases