oss-kit

Curated agent skills for open source maintainers.

• 61 rules. Each states the check it is scored by and the one skill that fixes it.
• Seven areas. Documentation, community files, CI, security posture, release publishing, changelog discipline, and the agent skills a repository ships.
• Both forges. 57 of the 61 rules score GitHub and GitLab alike. Three are GitHub-only, one is GitLab-only, and every rule says which.
• Eleven ecosystems, answered seven ways. npm, PyPI, RubyGems, crates.io, Go modules, Packagist, NuGet, Maven Central, Hex, pub.dev, and container images. Each one gets its own detection, badge, license field, CI commands, lockfile, release flow, and version syntax.

Install the kit:

npx skills add svyatov/oss-kit

Then ask your agent:

Audit this repository against the oss-kit standard.

It answers with the gaps and nothing else, each keyed to the rule it missed and routed to the skill that fixes it. Rules that already pass do not appear:

Audited 52 applicable rules: 49 pass, 2 fail, 1 unknown, 9 not applicable
(7 PUB, the project publishes no package; 1 GitLab-only; 1 where the
ecosystem does not encode the major version in package identity).

1. R-COM-04 fail, no SECURITY.md, run oss-community
2. R-SEC-01 fail, two uses: lines in .github/workflows/validate.yml pin a tag rather than a SHA, run oss-harden
3. R-SEC-05 unknown, the maintainer's signing key was not reachable, run oss-harden

Where to start

Run oss-audit first. It scores the whole repository and names which of the other skills to run, so you do not have to guess which gap matters.

Starting from an empty repository there is nothing to score yet, so work in this order instead:

1. oss-community for the license, code of conduct, contributing guide, and security policy
2. oss-readme for the README
3. oss-ci for tests, linting, and builds on push and on every change request
4. oss-harden for pinned action SHAs, workflow permissions, and branch protection
5. oss-changelog for CHANGELOG.md and the first tagged release
6. oss-publish if you ship a package, whether you push it to a registry or publish it by pushing a tag

oss-writing and oss-skill are not steps in that sequence. Reach for oss-writing whenever you are about to write a commit, a pull request, or a paragraph of docs. Reach for oss-skill only if your repository ships agent skills of its own.

You can also ask for a skill by name when you already know the job. Use oss-readme for a README, oss-community for community files, and oss-ci for continuous integration.

Skills

Each skill page on the documentation site carries the full description, including the validator oss-skill bundles. That validator runs on Node 22 or later, or on Bun, with nothing installed.

More install paths

One skill at a time:

npx skills add svyatov/oss-kit --skill oss-readme

Claude Code, GitHub Copilot CLI, and VS Code read .claude-plugin/marketplace.json. In Claude Code or Copilot CLI, type these two commands at the prompt:

/plugin marketplace add svyatov/oss-kit
/plugin install oss-kit@oss-kit

Every other supported harness has a native install path in the install guide.

Read the standard without installing anything

Every current rule is written down in STANDARD.md, also rendered at oss-kit.svyatov.com/standard. Each rule states what to do, why, what to check for, and which skill fixes it. Read it and disagree with it before you install anything.

Each of the eleven ecosystems has a page of its own, stitched from what all seven skills that answer per ecosystem know about it. One page carries the detection, the badge, the license field, the CI commands, the lockfile, the release flow, and the version syntax. Start at npm.

oss-kit is scored against its own standard, and AGENTS.md records the reason for every rule that does not reach a skills repository.

Help and project status

Start in Discussions. Questions, disagreement with a rule, and anything you are not sure is a defect belong there.

Open an issue when something is broken, when you want to propose a rule, or when you want to propose a skill change. Each of the three has a form.

To report a security vulnerability, follow SECURITY.md instead of either.

oss-kit is maintained. It is below 1.0.0, so incompatible changes still ship in minor releases; the Versioning section below says exactly what is covered.

Contributing

See CONTRIBUTING.md for the setup, test, and pull request steps.

Changelog

Every notable change is recorded in CHANGELOG.md.

Versioning

oss-kit follows Semantic Versioning over four things:

• the name of every skill and its skills/<name>/ path
• the rule IDs in STANDARD.md and what each rule requires
• the path, argument, and exit codes of the validator at skills/oss-skill/scripts/validate.mjs
• the manifest paths each supported host reads

Four things are outside it, and they change in any release:

• the wording of a skill body
• the layout of a skill's references/ directory
• the documentation site
• the maintenance code under scripts/ and tests/

Renaming or removing a skill, renaming a rule ID, or tightening what a rule requires is an incompatible change. A repository that passed yesterday can fail today. Adding a skill or a rule is not. While the version stays below 1.0.0, an incompatible change ships in a MINOR release.

License

MIT. See LICENSE. A skill that derives from third-party work carries a sources.json. It names what the skill came from, who holds copyright alongside the maintainer, and how this fork differs.