Contribute a skill.

The rules are not negotiable

These skills are executable supply-chain input for other people’s agents. Every rule below exists because breaking it puts someone else’s repository at risk.

1. 01

   Never invent evidence

   Every claim in catalog.json must be something you actually verified. Do not list evidence you did not produce, metrics you did not measure, compatibility you did not exercise, or a security review that did not happen. An unrun check is not a pass.

   How it is enforced. Reviewed by a human. Fabricated evidence is grounds for rejection, not revision.

2. 02

   State permissions and boundaries honestly

   Declare filesystem access, external writes, and network access truthfully. If your skill instructs an agent to write outside the repository, call a paid API, or touch credentials, say so in the manifest.

   How it is enforced. Validated shape; the values themselves are reviewed by a human.

3. 03

   Stay provider-neutral

   SKILL.md is portable instruction text. Do not hard-code one vendor's tool names, model identifiers, or proprietary APIs into the instructions. Provider-specific presentation belongs in agents/.

   How it is enforced. Reviewed by a human.

4. 04

   Publish your limitations

   verification.limitations is required and must be real. State what the skill cannot judge, what was not exercised, and where its guidance stops. A skill with no stated limits will be sent back.

   How it is enforced. Required by schema; contents reviewed by a human.

5. 05

   Never mutate a published version

   A released archive is immutable. If the package content changes at all, increment the version. Editing files under an already-published version is rejected automatically.

   How it is enforced. Enforced by generation; the build fails on a modified published archive.

6. 06

   No destructive or covert behaviour

   Skills run with full agent permissions. Instructions that exfiltrate data, disable safety checks, evade detection, install unreviewed remote code, or take destructive action without confirmation are refused outright.

   How it is enforced. Reviewed by a human. Refused, not revised.

Package layout

One directory under skills/. The directory name is the slug, and it must be lowercase hyphen-case under 64 characters.

skills/<your-skill-slug>/
├── SKILL.md            # required — YAML frontmatter + portable instructions
├── catalog.json        # required — validated public metadata
├── agents/
│   └── openai.yaml     # provider display metadata
└── reference/          # optional — bundled files your skill declares

SKILL.md must open with frontmatter

The name must match the directory exactly, or the build rejects the package.

---
name: your-skill-slug
description: What the skill does, and when an agent should reach for it.
---

Gates your pull request must pass

Run all of these locally before opening a pull request. A red gate is a blocked merge.

Choosing a maturity level

Status is a promise to the person installing your skill. Claim the level you can evidence, not the one you hope for.

experimental

The shape may change. Interface and guidance are still moving.

beta

Structurally validated and exercised, with evidence still accumulating.

stable

Exercised against real input with recorded evidence, and the instructions are settled.

What happens next

1. Open a pull request with the package and passing gates.
2. A maintainer reviews the instructions, declared permissions, evidence, and limitations.
3. On merge, generation publishes the archive and discovery index. Your skill becomes installable from the domain and appears in the catalogue automatically.

Found a security problem instead? Report it privately to security@bespoketech.com.ng rather than opening a public issue.