Skills
oss-kit currently ships 9 skills. Install the full collection, or choose the responsibility you need.
Score an open source repository against the oss-kit standard and report what is missing. Checks documentation, community files, CI, security posture, release process, changelog discipline, and the structure of any agent skills the repository ships, then names the skill that fixes each gap. Use when the user asks how healthy a repo is, what an open source project is missing, to audit or review a repository’s open source practices, or where to start improving one.
Maintain a changelog and make versioning decisions for an open source project: Keep a Changelog structure, semantic version choices, release notes generated from merged work, and deprecation policy. Use when the user asks to write or update a CHANGELOG, decide whether a change is major, minor, or patch, draft release notes, or deprecate an API. The prose style belongs to oss-writing; the publishing mechanics belong to oss-publish.
Set up continuous integration for an open source project on GitHub Actions or GitLab CI/CD. Use when the user asks to set up CI, create workflows or pipelines, add automated testing, building, or linting on push and pull requests, deploy a docs or other static site to GitHub Pages or GitLab Pages, or review existing CI configuration. Also use when the user mentions automating tests, running checks on PRs, or a build matrix, even without saying CI. Covers what runs. Security posture of those workflows belongs to oss-harden, and publishing belongs to oss-publish.
Create the community and governance files an open source project needs: CONTRIBUTING, CODE_OF_CONDUCT, SECURITY.md, issue and pull request templates, CODEOWNERS, FUNDING, and the license file. Use when starting a new open source project, opening a private repo to the public, or when a repo is missing its community health files. Covers GitHub and GitLab. README structure belongs to oss-readme.
Harden the security posture of an open source repository: pin CI actions to full commit SHAs, restrict workflow permissions, keep untrusted input out of shell commands, enable automated dependency updates, lock dependency resolution, run static analysis on pull requests, configure branch protection, enforce code owner review, and sign tags. Use when the user asks to harden a repo, improve supply chain security, fix an OpenSSF Scorecard finding, pin actions, fix a workflow script injection, or lock down CI. Covers GitHub and GitLab. Publishing belongs to oss-publish.
Set up a secure release process for an open source package so no long-lived publishing token exists to steal. Covers trusted publishing with OIDC, build provenance, and approval-gated release workflows for npm, RubyGems, PyPI, and crates.io on both GitHub Actions and GitLab CI/CD. Use for any request to publish a package, secure or harden a release process, set up trusted publishing or provenance, or create a release workflow.
Write or improve a README.md for an open source project. Use this for any request to create, rewrite, review, or polish a README, project description, or getting-started docs for a library, framework, or tool, or to make an open source project more attractive to users. Covers structure and section order. For the sentences themselves, oss-writing owns style. Do NOT use for internal or private repo docs, API reference generation, or CHANGELOG and CONTRIBUTING files.
Fix the structure, portability, and effectiveness of repositories that ship Agent Skills. Covers canonical layout, SKILL.md conformance, trigger descriptions, progressive disclosure, repeatable procedures, bundled scripts, evaluation, licensing, and host install paths. Use when a skill fails to load or trigger, produces inconsistent results, wastes context or tool calls, ships non-portable code, or needs an audit against the current Agent Skills specification and authoring guidance.
Write clear technical prose for anything that lives in a repository or on a forge: commit messages, PR titles and descriptions, PR and code review comments, issue text, READMEs, documentation, changelogs, ADRs, code comments, error and log messages. Use this whenever you are about to write or edit any of them, including short ones. A one-line commit message or a two-sentence review comment looks too small to need a skill, and that is exactly where the tells show up. Not for prose that needs a personal voice, such as blog posts, essays, or launch announcements.