Changelog

All notable changes to this project are documented in this file.

The format is based on Keep a Changelog 2.0.0, and this project follows Semantic Versioning over the public API declared in the README.

0.17.0 - 2026-08-21

Added

• The Go modules reference covers the GoReleaser path. goreleaser release already builds into dist/, writes the checksum file, creates the release, and uploads everything, so the section’s go build, go version -m, sha256sum, and gh release upload steps are done and only the attestation is left. The subsection names the checksum file’s default template, since subject-checksums attests exactly what one manifest lists, and the two settings that break the step rather than rename its input: checksum.disable writes no manifest and checksum.split writes one file per artifact. It carries fetch-depth: 0 on the checkout, which GoReleaser requires and the default shallow checkout does not give, and it says that the sboms: block answers R-PUB-05 as it ships, since the default generator is syft and the default arguments write spdx-json, leaving the workflow only to put syft on the PATH. It also states the job boundary this collapses, because one GoReleaser step both compiles the binaries and writes them to the release, leaving R-SEC-13’s tag restriction as the only control between a push and a published asset. A run following the file against a GoReleaser project had to improvise the attest step, and improvised it wrong.
• oss-publish Step 6 names actions/attest as the GitHub action and says not to write actions/attest-build-provenance into a new workflow. The wrapper was named nowhere a reader of the skill reached, only inside a sources.json provenance entry, so a run recalling it from elsewhere found nothing in the skill contradicting it. Upstream keeps the wrapper for workflows already using it; its v4 is a composite action whose only step calls actions/attest.

Fixed

• The Go modules CI reference names supported Go lines in its matrix. It showed 1.24 and 1.25, both of which fell out of support before the file was last verified, so a reader copying the example got a matrix of two unsupported releases while the paragraph below it stated the policy correctly. The example now carries 1.26 and 1.27 with the date they were true on, and a sentence sends the reader to https://go.dev/dl/?mode=json, which returns exactly the supported lines, rather than to the literal list. Go ships a major release about every six months, so any list written into a file is wrong within one of them.

0.16.0 - 2026-08-14

Changed

• oss-writing gives the commit and change-request body a fourth slot, what this change does about the problem, answered in the same breath as the problem is raised. The present-tense rule now scopes to the problem clause, git’s imperative rule for the fix returns beside it, and a body that has to describe more than one change is the signal to split the commit rather than the description. Measured over twelve cases against the unedited skill, the edit carried more facts on 6 of 12 paired passes over the band where a change has separable parts and fewer on 1, and it narrowed a spread that had returned 4, 1, and 4 facts on one case across three fresh generations.

Removed

• oss-writing no longer bans a tool attribution trailer. The rule argued accountability: a trailer records who answers for a change, and a tool cannot. Disclosure is a separate question, and the rule never reached it. Two projects now require what the rule forbade. The Linux kernel asks for an Assisted-by trailer where a coding tool helped write a patch, and rust-lang asks for LLM disclosure in a change request description. In such a repository the skill told a contributor to drop a required line, against its own first instruction to read the local contract. references/linting.md and scripts/prose.mjs drop the matching check, which sat in the --house tier.

Fixed

• oss-writing presents a 72-character commit header as a setting rather than as what @commitlint/config-conventional ships. The preset limits the header to 100 characters, so a reader trusting the old claim skipped the override and accepted 100-character subjects.
• oss-writing states the runtime scripts/prose.mjs needs, Node 22 or later, or Bun. The skill said the script needs nothing installed without naming one.

0.15.0 - 2026-08-11

Added

• oss-harden counts a repository’s workflow files as source in an analyzed language. R-SEC-09 now reaches a repository whose application language no analyzer supports. Step 11 read as CodeQL over application code alone, and reported such a repository outside the rule while nothing examined its workflows.
• The GitHub reference names CodeQL’s actions language and zizmor as the analyzers for those files. It maps zizmor’s audits onto the five rules the kit otherwise scores by reading the files: R-SEC-01, R-SEC-02, R-SEC-07, R-SEC-14, and R-PUB-02.
• The RubyGems reference covers Bundler’s own cooldown setting under R-SEC-14. It gives the three precedence layers and the Gemfile form. Two conditions leave a configured cooldown covering less than it reads. A version whose gem server emits no created_at stays resolvable. From Bundler 4.0.15, a version already in Gemfile.lock is exempt on every resolution path.
• The RubyGems reference states the install-time code execution that R-SEC-15 places outside itself, and gives the command that counts the installed gems holding it.

Changed

• The documented install is npx skills add svyatov/oss-kit. The --skill '*' flag existed to preselect nine loose rows in the picker, and 0.14.0 replaced those rows with one select-all row, so the flag now only repeats what a single keystroke does.
• oss-skill says a repository documenting a whole-collection install groups its skills through a plugin manifest rather than through --skill '*'. The reference recommended the flag, which was the only answer before the CLI read a manifest for groupings.
• oss-harden prices GitHub Code Quality at its general availability rate, says the product reaches organization-owned repositories on GitHub Team or GitHub Enterprise Cloud only, and gives the setup command that decides whether the code_quality ruleset rule can be added at all. The paragraph was written during the public preview, when the cost was deferred and the availability limit was unstated.

Fixed

• The RubyGems reference no longer says bundle config set --local frozen true writes the setting where a reviewer and CI can read it. bundle gem generates a .gitignore ignoring /.bundle/, so on a gem skeleton nothing commits that file. The reference now says to read the ignore file first, and names BUNDLE_FROZEN as the setting that reaches CI.
• The GitHub reference’s contents list links to its dependency updates heading again. That heading gained R-SEC-14 and the anchor was left behind.

0.14.0 - 2026-08-11

Changed

• .claude-plugin/plugin.json lists all nine skills in a skills array. npx skills groups a repository’s skills under one select-all row only when a plugin manifest names each skill directory, and it matches a skill’s own directory, so a single ./skills/ entry grouped nothing. Installing oss-kit offered nine separate rows before this.

Security

• oss-audit marks the output of scripts/collect.mjs as untrusted input. Heading text, the line before a fenced block, link text, and job names are quoted from the repository under audit, which somebody other than the person running the audit wrote, and they reached the audit with nothing saying which side of the trust boundary they sat on. The script now opens its output with that statement and the skill says the same at the point it tells a reader to run it. Stripping the prose is not available, because several rules are scored on it.

Fixed

• oss-harden pins the uses: entries a shipped composite action carries, not the workflow lines alone. A repository whose action.yml names an unpinned action passed Step 3 with a mutable reference left in place.
• oss-harden says a Dependabot cooldown below three days shortens the delay. Step 5 said such a value replaced the platform default with something slower, which is the reverse of what it does.
• oss-harden sends a repository that receives fork pull requests to CodeQL advanced setup. GitHub excludes fork pull requests from default setup, so recommending it left R-SEC-09 open on the path every external contribution takes.

0.13.0 - 2026-08-07

Changed

• Breaking: R-PUB-02 requires Maven Central credentials to become available only after a native forge publication gate. A USER_MANAGED Portal stop alone no longer passes because the same user token can publish through the Portal API.
• oss-publish configures one publication gate by default. It uses npm staged approval for one package, a forge gate for packages released together, and a forge gate with automatic Maven Central publication. It preserves existing extra gates until the maintainer accepts a migration.
• GitLab release examples use one protected blocking manual job by default. Deployment approval rules remain an optional extra gate because GitLab also requires a manual job start after approval.

Fixed

• npm staged publication examples use ./package/*.tgz, so npm reads the values as local tarball paths.
• PyPI and pub.dev examples use the release environment name consistently.

0.12.0 - 2026-08-04

Changed

• Breaking: R-SEC-14 scores what the delay covers, not just that the key is set. Dependabot’s cooldown reaches every dependency while include is absent and narrows to what include names once it is present, both lists take wildcards, and exclude wins, so exclude: ["*"] left a block that read as configured and delayed nothing. Renovate hollows out the same way through a packageRules entry overriding the top-level minimumReleaseAge. A repository whose resolved coverage leaves its dependencies outside the delay fails from now on.
• Breaking: R-SEC-14 reads a Dependabot cooldown below three days as a failure. The floor was one day, and Dependabot now applies three on its own, so every value between the two replaced the platform default with something slower while passing the rule. Dependabot accepts 1 to 90 days, so no repository can write a zero and the affected range is 1 and 2. Renovate keeps the one-day floor, having no default to fall below.
• R-SEC-14 accounts for the three-day cooldown Dependabot applies on its own. Its reason told a maintainer that an updater with no cooldown opens its pull request inside the window a compromised release lives in, and that stopped being true on 2026-07-14, when GitHub made the delay the default for version updates whether or not dependabot.yml configures one. A maintainer on Dependabot checked the repository, found the stated danger absent, and the rule lost the argument it needs to be followed. The rule now rests on the two arguments that survive: a written value outlasts a platform default, and it is a decision a reader can audit. The check gains a reading instruction rather than a new requirement, so no repository’s verdict changes. Dependabot with no cooldown block is reported as an unwritten control, and Renovate with no minimumReleaseAge as an open window, because that option still defaults to no delay. oss-harden carries the dates and the GitHub Enterprise Server floor.

0.11.0 - 2026-08-04

Added

• R-SEC-14 asks the dependency updater to wait before proposing a version published minutes ago, through Dependabot’s cooldown or Renovate’s minimumReleaseAge. What ends a registry compromise is other people looking, and that takes hours; an updater with no cooldown opens its pull request inside that window, so a project diligent about merging bumps is the one that installs the bad version first. Neither setting delays a fix for a known vulnerability. The rule is scored against the updater configuration, so it is one observation per repository, and oss-harden’s npm reference carries the package manager side, where three managers ship their own knob in three different units.
• R-SEC-15 asks CI to install dependencies without running the code they ship, which is the step the September 2025 npm worm used to spread. It is satisfied by the flag or by the committed allowlist: --ignore-scripts or allowScripts for npm, enableScripts for Yarn, allowBuilds for pnpm, trustedDependencies for Bun, --no-scripts --no-plugins or allow-plugins for Composer, and --only-binary for Python, where a wheel runs no packaged code and a source distribution runs the project’s build backend. Each of the other eight ecosystems was read once: Cargo, RubyGems, and Hex run dependency code with no documented way to decline it, and Maven, NuGet, Go modules, container images, and pub.dev packages run nothing during resolution, so the rule falls outside all eight rather than failing them.
• oss-harden’s npm reference answers dependency install scripts, which are the shortest path from a compromised package to a shell on the runner. All four managers now block them by default and each is configured somewhere different: npm 12 through allowScripts and npm install-scripts, Yarn through enableScripts, pnpm through allowBuilds since version 10, and Bun through trustedDependencies. npm 12 also stopped resolving git and URL dependencies by default.
• oss-audit documents the shape collect.mjs prints: seven top-level keys, and file rather than path on a workflow entry, which is the one an audit reliably guesses wrong. A filter reading a key the output does not have prints nothing and reads as a repository with nothing to report.
• oss-harden answers the case where a release tool creates the tag on a personal-account repository. The bypass actor a creation rule would need is the GitHub Actions integration, and GitHub refuses it there with 422 Actor GitHub Actions integration must be part of the ruleset source or owner organization, so the reference gives the three ways forward rather than a ruleset that cannot be written. R-SEC-13 still fails in that state, because tag creation genuinely is unrestricted.
• The site has an /ecosystems/ landing page listing all eleven with their manifests and registry. The eleven pages were reachable only from a sidebar group, and the page that introduces them is the splash page, which has no sidebar. The footer navigation carries it, along with /rules/, for the same reason.
• The 404 offers the site search. It is the header’s own search opened from a button rather than a second search component, because Starlight hard-codes the id Pagefind mounts into and two of them on one page break search rather than duplicating a control.

Changed

• This repository now meets both new rules rather than documenting itself as an exception. All three dependabot.yml entries carry a seven-day cooldown, and every bun install in CI passes --ignore-scripts.
• The seven npm ecosystem references track npm 12, released 2026-07-08, rather than npm 11. Every docs.npmjs.com/cli/v11 link now resolves to the v12 page and each claim behind it was read again there. oss-ci’s matrix example is Node 22, 24, and 26; the 20 it used to name reached end of life on 2026-04-30, and the file now says which dates turn the set over rather than leaving the next reader to find out. npm-shrinkwrap.json is no longer a lockfile: npm 12 removed the command and stopped loading the file, so oss-harden reports one as a finding, oss-changelog drops it as a version source, and oss-audit says a checkout carrying one proves a dependency tree and nothing about how it resolves.
• oss-publish’s npm reference states the Node range npm 12 requires, warns that a newly published version is not installable while npm’s publish-time malware scan runs, typically around five minutes and up to fifteen or more, and explains why the R-PUB-02 token fallback does not reach npm: classic tokens were revoked on 2025-12-09, granular tokens expire within 90 days, and a 2FA-bypass token loses direct publish around January 2027.
• R-PUB-01 now reads a run that creates the release tag itself as satisfying it, alongside one triggered by a tag push. The old Check: asked only for a tag-push trigger, which release-please, semantic-release, and changesets do not use: they trigger on a merge to the default branch and then tag, release, and publish in one run. An audit had to pass that shape on a stated rationale rather than on the Check:, which is a verdict two runs can disagree about. The rule’s threat model is unchanged, so what still fails is a publish with no release tag on either side of it, and a publish a person can run from a working tree. oss-publish’s npm reference now says to fit the publish job inside an existing release tool rather than rewriting it into a tag trigger, and names the three things that do change.
• oss-audit Step 8 says to run the closing audit in a fresh session, for the same reason each fix group gets one. It arrives at the end of the longest context in a run and needs the whole skill body, so a session that reaches it after compaction works from a truncated copy.
• The site’s GitHub link is the fifth entry in the header navigation rather than a lone anchor between the search field and the theme control, where it read as a control that does nothing. The header’s three controls now share one height and one gap; the theme select was five pixels shorter than the other two and its wrapper added eight pixels of line box on each side. The search field keeps its label and shortcut hint down to 1120px rather than collapsing to an icon at 1248px with 460px of unused room in the row.
• The homepage workflow trace links every step. Two of the four had no link, so those cards carried an empty band where the others had one, and the step naming the check now quotes its leading clause and links to the whole thing rather than setting 400 characters of rule text in a card three hundred pixels wide. A rule’s check panel has an id, so that link lands on it.
• The install command takes one authored line break under 552px instead of scrolling. Each argument sits in its own pre span, so the only break the browser is offered is a space between arguments and --skill '*' always arrives whole. Its fade is sized to the distance actually hidden, which was a constant 40px before and dimmed the last flag of a command that fit with three pixels to spare.

Fixed

• The homepage map clipped its own domain bays between 529px and 543px. The query that stacks it was set at 33rem, fifteen pixels under the width where the two-column body stops fitting. Nothing overflowed the page, because the map clips its own child, so a page-level scroll check read zero: the assertion has to target the panel.
• Every rules area page and the new ecosystems page rendered their names one character per line below 1024px. The narrow-width rack override assumes an icon column, and these two racks have none, so the name took the 19px icon track. The rule ID broke across three lines in the same override.
• Widths between 800px and 1024px had no primary navigation on a page without a sidebar. The row of links turns off at 1024px and the drawer used to turn on at 800px. The drawer is also no longer gated on the path, which left the 404, a splash page too, with no way out at any width under 1024px.
• The homepage rule route stays at every width. It was hidden below 1248px, which took the one worked example off every laptop; the map stacks it under the domain bays instead.
• The footer’s two bands, the homepage sections, and the footer’s copy column started on three different left edges. All of them now share the measure the sections established.
• Starlight’s li + li margin reached inside the workflow trace grid and offset the first card against the other three, leaving the connector dots off a single line. The second card’s connector also stood outside the frame in the two-column form, pointing at a right edge with nothing past it.
• Two display headings opened on a one-word line, “A” over “recommendation” and “One” over “responsibility”, because the 13ch measure was narrower than the longest word in them and text-wrap: balance had no arrangement to find.
• Footer navigation links, workflow trace links, and the map rail link were all under the 24px WCAG 2.5.8 floor the header navigation already carries. The lit domain bay signalled its state through colour alone.

0.10.0 - 2026-07-31

Added

• oss-audit writes oss-audit-report.md at the root of the repository it scores, untracked by default. It carries the repository facts the audit established, the prerequisites no API can perform, one verdict line per scored rule, and an execution order that groups fails by owning skill with one pull request each. A fail’s line quotes that rule’s Check: text verbatim, so a fix session works from the report alone. The eight rule-fixing skills read their group from it where it exists.
• oss-audit Step 8 audits again once the fix groups are done and diffs the two reports. Recording passes is what makes that diff possible: a verdict never written down cannot be compared.
• skills/oss-audit/scripts/collect.mjs prints the mechanically observable facts the Check: lines reference as JSON, replacing the twenty to thirty shell commands an audit spends deriving them. It parses workflow YAML with an indentation reader rather than matching lines, because a regex over job-shaped lines counts a top-level env: block’s keys as jobs.
• skills/oss-writing/scripts/prose.mjs reports the regex-decidable half of that skill: dashes, emoji, Title Case headings, and banned words, with a file and a line for each. The default tier reports what R-DOC-05 names and nothing else; --house and --length add the noisier rules.
• scripts/run-metrics.mjs reports what a run cost from its session transcript: billed context split by phase, turns, mean and peak context, compaction boundaries, tool calls ranked by result bytes, and context per rule closed.
• All nine oss-publish ecosystem references that need a GitHub deployment environment now give the gh api calls beside the settings URL. Reviewers and the tag policy are both API-settable, and one measured run spent 35 browser interactions clicking through the form the references pointed it at.
• collect.mjs reports each workflow trigger’s branches, tags, and paths filters beside the event name, which is what makes the tightened R-CI-01 observable: an event name alone cannot say whether pull_request carries a base-branch filter.
• skills/oss-harden/scripts/resolve-pin.mjs resolves an action reference to the commit SHA R-SEC-01 asks for. It dereferences an annotated tag, which points at a tag object rather than at a commit, and it reports when a ref is a branch rather than a tag, which is a finding: ruby/setup-ruby@v1 and rubygems/release-gem@v1 are both branches. Every measured run wrote this resolver from scratch and two of them got it wrong the same two ways.
• skills/oss-harden/scripts/ruleset.mjs reads, merges, and writes a GitHub ruleset, and strips the nulls GitHub reads back but rejects on write. Without that strip a fetch, edit, and PUT answers 422 Invalid property /rules/N: data matches no possible input, which every ruleset round trip hits. Its actor subcommand prints the {"actor_type": "User", "actor_id": N} form a bypass entry takes, rather than the undocumented RepositoryRole number one run guessed, shipped, and repaired with a second write.
• skills/oss-changelog/scripts/release-notes.mjs prints one version’s section out of CHANGELOG.md and exits 2 when it is absent or empty, so a release job fails rather than publishing a blank release body. oss-publish copies it into the repository beside the release workflow.
• run-metrics.mjs reports three more things. Rework rate is failed tool calls over total, split by cause, which says whether the fix is a script, a prompt, or a permission. Redundancy is the same file read twice, the same URL fetched twice, or the same command issued twice, with the count of repeats near a compaction called out separately. --reports BEFORE.md AFTER.md diffs two oss-audit-report.md files and separates verdicts the run fixed from verdicts that went pass to fail, which are findings the run itself caused. That last one is the only metric here that measures the kit’s correctness rather than its cost.
• All eleven oss-harden ecosystem references say what breaks after a lockfile is committed, which is where a measured run spent more turns than on any other fix. Each answers the same three questions from that package manager’s own documentation: whether the resolved set varies by runtime version, whether the repository holds locks the updater will not maintain, and whether the lock has to cover a platform nobody develops on. Several answer no, with the sentence that settles it, because the answers differ sharply. Cargo resolves platform-specific dependencies as if every platform were enabled and go mod tidy ignores build constraints, so both are immune to the platform question, while npm has been reported to record one platform’s variant of an optional dependency and Composer resolves against whichever PHP wrote the lock.

Changed

• oss-publish states one release workflow shape and the eleven ecosystem references conform to it: the file is .github/workflows/release.yml, the workflow is Release, the trigger is a v* tag, the environment is release, and the jobs come from test, build, publish, and github-release. That closes four inconsistencies among the references themselves. nuget’s pack job is build, pypi’s pypi and pubdev’s pub.dev environments are release, pubdev’s three-part tag pattern is v* and no longer drops a prerelease tag pub.dev itself accepts, and the asset job is github-release everywhere, so release stops naming a file, a trigger, an environment, and a job at once. It is a convention rather than a rule, and no STANDARD.md rule scores a job name. Three departures are stated where they apply: the tag-published track keeps its job in the CI workflow, Hex has no build job, and containers has no test job.
• oss-audit closes its report with the fix groups as literal next invocations, one line each, with the branch name. The advice to start each group in a fresh session was only inside oss-audit-report.md, which nobody opens at the moment that decision gets made, so all three measured runs continued in one session and paid for it in every later turn.
• oss-writing carries a branch rule: <type>/<kebab-topic> using the same Conventional Commits type its commits use, and chore/release-X.Y.Z for a release. It had none, so a measured run produced four prefixes across six pull requests and titled one ci: on a chore/ branch.
• oss-publish, oss-ci, and oss-harden name oss-writing in their scope sections. All three write commit messages, change request bodies, and issue text, and none of them named it, because oss-writing owns no rule area and so appears in no Fixed by: line.
• Breaking: R-CI-01 fails a pull_request trigger carrying a branches: filter. The filter keys on the pull request’s base branch rather than its head, so branches: [main] runs nothing at all for a pull request stacked onto another branch. A measured run passed this rule on a repository whose three stacked pull requests ran zero CI between them, including the one that rewrote the CI workflow.
• Breaking: R-SEC-01 covers every action.yml and action.yaml the repository ships, where it covered .github/workflows/ alone. A composite action’s steps take uses: exactly as a workflow job’s steps do, so an unpinned third-party action inside one was invisible to the rule. A repository whose composite action pins a tag fails from now on.
• R-COM-01 accepts any license filename the forge’s own detector resolves: a basename of LICENSE, LICENCE, UNLICENSE, or COPYING, bare or with a .md, .markdown, .txt, or .html extension. It accepted LICENSE and LICENSE.md alone, which failed a repository over LICENSE.txt and made it rename a working file.
• R-COM-05 accepts a pull request template at any of the three paths GitHub reads, and the PULL_REQUEST_TEMPLATE/ directory form in any of them. It named .github/pull_request_template.md alone. The issue-template path stays exact, because GitHub reads issue forms from .github/ISSUE_TEMPLATE/ and nowhere else.
• R-DOC-03 and R-DOC-05 delegate each file’s location to the rule that owns that file, rather than naming literal root paths. Both contradicted R-COM-02, R-COM-03, and R-COM-04, which accept a contributing guide, code of conduct, and security policy in .github/ or docs/. A repository keeping them there had those links unresolvable and that prose scored against nothing.
• oss-publish Step 2 hands the trusted publisher form over at the start with every field already filled from the reference file, rather than blocking Step 3 on a workflow filename and an environment name that Steps 3 and 4 produce. The blocking confirmation moves to the first tag push, which is the only thing that can actually publish. In a measured run the circular precondition was resolved by silently inverting the order, and the form instruction surfaced ten minutes later as one item in a three-item wrap-up, where a “done” answering the wrap-up read as the whole setup being finished.
• oss-publish states the reciprocal of its pinning hand-off. Where oss-harden has already run on the repository, this skill pins the actions it adds itself instead of handing the work to a skill with no turn left, which is how a release workflow ended up carrying unpinned uses: lines in the one job that authenticates to a registry.
• oss-publish requires a command’s flags to be confirmed against the client that will run it before a maintainer is handed it, and says what to do when a registry’s documentation and its client disagree: name both sources, report it upstream, and improvise no substitute credential path.

Fixed

• oss-publish wrote release workflows that failed R-SEC-08, a rule the kit itself owns, for four ecosystems. The rubygems, hex, crates.io, and pub.dev templates now use each package manager’s current frozen install mode rather than a bare bundle install, mix deps.get, cargo build, or dart pub get. A re-audit after one measured run scored the rule as a new failure that the run had introduced.
• oss-publish reported R-PUB-05 as satisfied by a manifest of hashes, which is R-PUB-06. The eight ecosystem references that name no SBOM generator now answer R-PUB-05 with the forge’s own SPDX export of the repository dependency graph, written beside the release assets so it is listed and attested with them, and each states the export’s two limits: it is GitHub only, so GitLab keeps the gap, and it covers the repository’s declared graph rather than the asset’s linked contents. Each also says outright that a hash manifest answers one rule and not the other.
• oss-publish’s hex reference gave mix hex.user key generate, which Hex 2.4.0 removed together with the password authentication it replaced with an OAuth device flow. hex.pm’s publishing guide still documents the command, so verifying against the registry’s own documentation confirmed the registry’s error. Step 2 now gives the https://hex.pm/dashboard/keys form with a package-scoped permission, verified against the Hex client and hex.pm sources rather than that page, and records that HEX_API_KEY is unaffected. Reported upstream as hexpm/hexpm#1787 with the fix in #1788.
• oss-publish’s rubygems reference told the reader to resolve a sigstore-cli version from what rubygems/release-gem pins. It pins none, and its default branch is v1, so the fetch that sentence invited returned 404. It now gives the registry query that works.
• oss-publish’s rubygems reference declined to choose between generated and handwritten release notes, which left the release job to be improvised. It now reads the version’s section out of CHANGELOG.md, whose structure oss-changelog already mandates, and fails the job rather than publishing an empty release body.
• oss-publish’s rubygems reference says to wait for the RubyGems index before verifying by installing. A measured run read the propagation delay as a failed publish and spent two minutes in a retry loop.
• collect.mjs read on: [push, pull_request] as a single event named [push, pull_request], and on: push as no event at all. Only the block mapping form reported the events a workflow actually triggers on, so R-CI-01 was unscoreable against either of the other two shapes on: accepts.

0.9.0 - 2026-07-31

Added

• Eleven distribution ecosystems are answered in depth by all seven skills that can act on one. oss-audit, oss-readme, oss-community, oss-ci, oss-harden, oss-publish, and oss-changelog each carry one file per ecosystem under references/ecosystems/, 77 in total, covering npm, PyPI, RubyGems, crates.io, Go modules, Packagist, NuGet, Maven Central, Hex, pub.dev, and container images. Every file is written from that ecosystem’s own documentation and ends with the date it was read.
• skills/oss-audit/ecosystems.json is the roster those files answer to. It records each ecosystem’s manifest, lockfiles, and registry facts, and declares the headings each skill’s files must carry.
• R-SEC-13 requires a released tag that cannot be moved or deleted, and restricts who may create one. On the tag-published track, creating the tag is the publish, so this is what stands in for R-PUB-04’s approval gate.
• R-PUB-07 requires a tag-published registry entry to update through the forge rather than through a token a CI job holds.
• R-CHG-07 requires the released major version to match the package identity where an ecosystem encodes it there, such as a Go module path ending /v2.
• scripts/check-ecosystems.mjs fails CI on a hole in that matrix: a missing file, a file the roster does not list, a declared heading that is absent or empty, or a malformed Verified date. scripts/ecosystem-freshness.mjs reports how stale each date is and never gates.
• The documentation site publishes one page per ecosystem, stitched from all seven skills’ files for it.

Changed

• The release area now runs on two tracks. On the registry-push track every PUB rule applies. On the tag-published track, where the registry reads the forge and no publishing credential exists, R-PUB-01 through R-PUB-04 are not applicable as a whole and R-PUB-05 through R-PUB-07 still apply. Go modules and Packagist are on that second track.
• R-SEC-08 no longer asks for a committed lockfile where the project’s build tool publishes no lockfile format, which reaches Apache Maven and not Gradle, or where the ecosystem’s own documentation directs a library package not to commit one.
• R-PUB-02 now accepts an account-scoped publishing credential with compensating controls where the registry offers no narrower scope, which is the case on Maven Central.
• oss-readme’s badge reference no longer carries a per-ecosystem table, and oss-community’s GitHub reference no longer enumerates the Tidelift platform names. Both now link the ecosystem file that owns the answer, so no fact lives in two files.

0.8.0 - 2026-07-31

Added

• oss-readme’s badge reference gains an Elixir row, img.shields.io/hexpm/v/NAME linking to the Hex package page. The endpoint returns the label hex on its own, so it needs no ?label= override the way Go’s tag badge does.
• oss-harden Step 10 names mix deps.get --check-locked beside npm ci and cargo build --locked. That is what makes CI fail on a stale mix.lock rather than quietly re-resolving it.

Changed

• R-PUB-02’s fallback now separates a registry that offers no OIDC flow at all from one whose flow nobody here has read. Both scored the same before, so a repository that could have used trusted publishing passed on a scoped token instead. Hex is the case that exposed it and the one the Check: now names: its publish page documents exactly one CI path, a long-lived HEX_API_KEY in an environment variable, and the hex client changelog through v2.5.2-dev names no OIDC, trusted publishing, or attestation. The fallback is reachable there rather than theoretical, because hexpm authorizes publishing on a package domain, so a key scoped to one package publishes that package and nothing else. What the rule requires is unchanged, and no repository that passed yesterday fails today.
• R-SEC-11’s Check: reaches the residual that comparing the dependency graph against the lockfile cannot find: an ecosystem the forge’s updater bumps on a schedule and never patches on an advisory. GitHub’s ecosystem table marks both bun and mix that way. This repository has been the bun case since it adopted Bun, which is why the generalization rests on two instances rather than on one.
• oss-writing’s check list rejects a contrast whose alternative was invented for the sentence, as in instead of returning a deck nobody asked for. The list had licensed the pattern, because its weigh-the-fact check kept any rejected alternative as a fact. The tell catalog’s empty-contrast row named only not just X, but Y, so the rather than shape passed unexamined. An alternative now survives only when it exists outside the draft, such as a prior behavior or a real endpoint. references/linting.md records that no checker can decide this, so nothing lints the phrase. Sweeping the kit’s own prose against the same test found three more instances; each now states the fact alone.
• oss-harden names that second residual where it already teaches the SBOM comparison, and shows it. elixir-ecto/ecto and phoenixframework/phoenix both report zero pkg:hex packages, and Phoenix reports 635 pkg:npm beside that zero from its JavaScript assets, so the dependency graph is running and Elixir is simply not in it. An Elixir project has no watcher at all until a scanner reads mix.lock.

0.7.0 - 2026-07-30

Nine skills were reviewed against Anthropic’s current skill-authoring baseline. This release carries the defects those reviews found, the structural sweep that followed them, and the additions that close what a description promised and a body did not have. The defects were a skill telling a reader to do one thing in one place and the opposite in another, a command that could not run where the reader was told to run it, and a step whose output another step already needed. The sweep took out what a skill stated twice, what it restated from STANDARD.md, and what carried a date that expires without telling anybody. No rule statement, Check: line, Fixed by: line, or Forges: line changed, and no repository’s score moves.

Added

• The validator warns on a frontmatter name containing the reserved words “anthropic” or “claude”, and on an XML tag in a description. Anthropic’s platform rejects both; the Agent Skills specification imposes neither, so each finding carries no rule ID and leaves the exit code alone. A skill that trips one still conforms to the specification and is still refused on upload, which is what the message says. No repository’s R-SEC-02 outcome moves, and no repository that passed yesterday fails today.
• oss-harden ships the complete request body for POST /repos/{owner}/{repo}/rulesets, marked for which fields are copied and which the reader sets. It had described four rule types in prose and shipped no body, which left the kit’s highest-stakes write to be assembled by hand. The R-SEC-12 review fields are present at their off values, so a repository with two or more principals can see what it has to turn on rather than inheriting a body that reads complete and is not. Required checks are derived from two check-runs reads rather than one, because a workflow triggered on pull_request alone never reports on a default-branch commit and drops out of the ruleset silently. PUT /repos/{owner}/{repo}/rulesets/{ruleset_id} is named, so a rerun updates instead of stacking a second ruleset beside the first.
• oss-changelog branches on what an encountered changelog declares: none, one pinned to Keep a Changelog 2.0.0, or one pinned to something else. Adding a single entry no longer migrates a project’s declared convention as a side effect.
• oss-readme and oss-ci gain the review mode both descriptions advertise. Each names its ways in, and the review branch reports what fails, anchored at the line it fails at, and changes no file. Asked to review without editing, both skills had no instructed output shape, and every downstream instruction in them writes.
• oss-ci’s GitLab reference gains a CI/CD variables section, so a run reaching the step that lists every secret has a command to give rather than inventing one. glab variable set produces an unmasked, unprotected variable by default, which is the form GitLab prints in full in a job log, so the printed command names both flags and takes the value from an environment variable. The GitHub section needs none of that, because gh secret set produces something GitHub always masks. A merge request pipeline reaches a protected variable only when both branches are protected and belong to the same project, and never from a fork, so a check that needs one on every merge request gives up either the protection or the run on forks.
• Each of the four oss-publish references gains a Step 6 section, closing the one step of the process with no reference behind it. npm generates its own bill of materials with npm sbom. The other three name no generator, because every option is a third-party tool and vetting one is the maintainer’s call, and give the hash-and-attest fallback instead. Each section puts the release assets in a third job behind the approval gate, since the build job runs the project’s own build command and the publish job holds the registry credential, so neither can carry release-asset writes without breaking the split those files exist to enforce. Read upstream before it was written: actions/attest@v4 is what its own README tells a new workflow to use, and subject-checksums attests every file a SHA256SUMS lists by name and digest, so a consumer verifies an asset rather than the manifest sitting beside it.
• oss-changelog gains a bump table covering ten changes, with a column for a stable release and one for 0.y.z, and the changelog file it prescribes, marked for which parts are copied as they stand and which come from the repository. Bump classification is this skill’s main output and had no worked example, and three of the ten are cases the prose does not reach: a raised minimum runtime, a change to error text, and a development-only dependency bump. The skill also gains a sources.json. It reproduces no wording from either specification it prescribes, and both ask for attribution: Keep a Changelog 2.0.0 is MIT and Semantic Versioning 2.0.0 is CC BY 3.0.
• oss-writing shows the timeless-prose rule with two example pairs, one dated against timeless and one carrying the same fact into documentation and into a changelog. The second is the half a reader gets wrong, because the exception is stated in prose and the contrast is what teaches it.
• oss-skill gains references/scripts.md, which teaches what R-SKL-05 does not reach: handling a failure rather than deferring it, giving every constant its reason, error messages that name what was expected, and stating whether a pointer means run or read. The upstream practice of listing a script’s packages does not transfer, since R-SKL-05 permits none, so it is retargeted to the runtime floor and the external commands the script calls, which fail the same way when absent. The validator this kit ships is the worked example.

Fixed

• oss-ci banned writing a permissions: block while its own GitHub Pages reference emitted two, so an agent following both either stripped the OIDC grant and shipped a deploy that cannot authenticate or wrote the block against an instruction not to. The ban now carries that one exception. The Pages workflow splits into build and deploy so the privileged token never shares a job with the project’s build command, both forges’ Pages blocks mark which lines are copied exactly and which are placeholders, and actions/configure-pages says where it goes: placed after the build command it exports a base path nothing reads, and the run stays green while every asset path on the deployed site resolves against the domain root.
• oss-harden’s SSH tag verification told a reader to point gpg.ssh.allowedSignersFile somewhere and stopped, so a run reported a configuration error as an unsigned tag. The sequence now fetches tags first, reads the signature format and the tagger from the tag itself, resolves which account publishes the key by asking whether the repository owner is a user or an organization, and passes the allowed-signers file inline. The caveat that a published key proves publication and never control sits on both branches and on the OpenPGP path.
• oss-publish’s GitLab publish jobs for PyPI and crates.io carried id_tokens: with no environment:, though both trusted-publisher forms take an environment name and npm.md already bound one. The binding ships with the sentence saying what it is not: both registries compare the claim’s string and nothing else, and neither form binds a ref, so an unprotected environment leaves any pushable branch satisfying every claim the registry checks. The tag-to-version guards in pypi.md and crates.md are exact commands where they were angle-bracket placeholders, and the crates.io token-exchange script records that sourcing it leaves set -eu applied to the rest of the job.
• oss-audit gated only the SKL area on its preamble, so it checked the six PUB rules one at a time against repositories the PUB preamble already places outside the area. It now reads whichever preamble an area has. A rule met by a fallback the standard marks below the bar scores as a pass whose report line names the fallback, and a retired rule is not scored at all.
• oss-skill’s validator command resolved against the repository under audit rather than the installed skill directory, so it failed wherever a reader ran it from. Validator findings now print forward slashes on every platform.
• oss-writing carried two drafting procedures pointing opposite ways, one drafting before reading the reference and one reading first. The first also gated on how much context is left, which the model cannot measure; it is gone, and its one load-bearing line moved to the Triggers block. references/linting.md named Metrics and Heading as Vale extension points, and Vale defines neither: the checks are metric and capitalization. Vale and commitlint now link to their own site and repository.
• oss-community’s 68-line agent-skills issue form had a lead-in describing what it demonstrates and nothing saying it was a demonstration, so it read as a form to copy into projects that run inside no host.

Changed

• Every skill ends with a verification loop. Read each cited rule’s Check: line against what was produced, fix what fails, start the list again, and report done only when nothing fails. oss-audit gains a counting step before its report, grep -c '^### R-' against its four status counts with retired rules subtracted from both sides, so a rule nobody checked shows up as unchecked rather than as a pass. oss-harden names its four outcome statuses as a closed set. oss-ci says that on GitHub the reference-plus-checklist is the validator, since no local one exists. oss-skill re-runs the validator after every fix and gates completion on a clean exit.
• Seven skills cite the rule IDs they own on one line instead of reproducing each statement as a sentence. The statements live in STANDARD.md. A copy elsewhere drifts from it with nothing to catch that, because the drift check compares IDs and never wording. The documentation site still lists each skill’s owned rules, derived from STANDARD.md rather than from the skill.
• Every reference file over 100 lines opens with a table of contents, and STANDARD.md gains an index of its 56 rules by area and ID range. A reader who takes the first 100 lines of a 400-line reference otherwise sees no sign that the rest exists. tests/rule-counts.test.ts derives the index’s total and every area range from the rule headings, so a stale number fails the build.
• oss-community moves the GitHub issue-form schema and the worked form into the GitHub reference, out of the one introduced as forge-independent. That reference had carried roughly 1200 words nothing on GitLab consumes, plus a duplicate of the schema list the GitHub file already had. The gh commands under repository settings now state that gh must be installed and authenticated, and that editing the description or the topics needs the Maintain or Admin role.
• oss-ci states each policy once. R-CI-02 and R-CI-03 were each stated three times, in the body and again in both reference files; the body keeps the policy and each reference keeps only the syntax that expresses it. Step 6 tells the reader to open one reference file and leave the other closed. Step 5 states the cache preference without naming a runtime setup action, which GitLab does not have.
• oss-changelog runs as nine ordered steps rather than four descriptive sections, and names the commands two of them asserted: git log against git describe --tags --abbrev=0 for the merged work, and gh pr list --state merged where gh is available. Changelog section, forge release body, and release notes had been three names for two artifacts within four lines, which is the conflation R-CHG-04 exists to prevent.
• oss-publish names the separated build-and-publish workflow as the RubyGems default, keeping rubygems/release-gem as the escape hatch with its credential exposure stated. Five claims that carried a timestamp, among them the npm and sigstore-cli versions and two GitLab beta labels, now name the documentation to re-read instead. pypi-attestations, gh attestation verify, and the npm provenance check each state what the reader has to have installed.
• oss-harden states its credential preflight once, before the first API call. On GitHub that is gh installed, authenticated, and holding admin. On GitLab it is read_api for a sweep that only reports and api for a run that repairs, with the role floor GitLab documents for each read, and the note that a read denied for role reasons can answer 404 and read like a control that is off. The Scorecard paragraph drops to a pointer at whichever reference the run chose.
• oss-readme points at references/badges.md for the badge cap, order, placement, live-fact test, and per-ecosystem URL templates, where the body had carried a summary that read complete and left the URL table unread. Its getting-started guide names the run rather than asserting it was validated: an empty mktemp -d directory, the lowest supported runtime, and the guide’s commands pasted in order.
• oss-writing keeps only the rules with a number or a named failure mode behind them. Nine went: the grammar rules on possessives, parenthetic commas, comma splices, sentence fragments, and dangling participles, plus the bare instructions to use active voice, the imperative, and second person. sources.json had recorded the last three as removed while they were still in the file.
• oss-skill teaches six practices from the authoring baseline that reached a reader nowhere: reference file naming, grouping by domain, the table-of-contents rule, third-person descriptions with the two openers that go wrong, the naming avoid-list, and the ban on time-sensitive content.
• oss-skill’s evaluation methodology moves out of the always-loaded body into references/evaluating.md, where a run auditing a repository layout no longer pays for it, and gains what the body had no room for: the shape of a task record, the two-session loop that keeps an author from grading their own instructions, and what the read order of the bundled files says about where the body points.
• Four descriptions gain trigger terms their bodies already own. oss-publish gains SBOM, signing release binaries, and checksums for release assets. oss-changelog gains the contributor phrasings breaking change, major bump, and yank. oss-writing gains the R-DOC-05 filenames and the verbs a user types. oss-audit gains opening a private repository to the public, and scoring against a named standard.

0.6.0 - 2026-07-30

Required review becomes its own rule, scoped to repositories that have somebody to do the reviewing. The standard then aligns with the OpenSSF Best Practices badge Passing criteria on four points: two new rules, and two rules that now fail a repository which passed them yesterday.

Added

• R-SEC-12 carries the approving review that R-SEC-04 used to bundle, and reaches only a repository where two or more principals hold push, maintain, or admin access. It reads that access list rather than guessing, with gh api repos/{owner}/{repo}/collaborators?affiliation=all or GitLab project members at Developer or above, and reports unknown rather than fail when the caller lacks push access and the endpoint answers 403. That takes the standard from 53 rules to 54.
• R-CI-06 requires a repository that ships executable code to define an automated test suite and the command that runs it. R-CI-01 through R-CI-05 govern where checks run and never whether the repository has any tests to run, so a repository with none passed the whole CI area while its CI verified nothing. The rule asks for existence only, because R-CI-02 already makes CI run every command the project defines and a gate clause here would restate it. A command whose whole body is an echo, a bare true, or an exit 0 does not satisfy it, since that is what a scaffolded manifest ships before anybody replaces it. A repository shipping no executable code falls outside the rule. oss-ci owns it, and now raises a missing suite instead of writing CI that runs nothing.
• R-CHG-06 requires a release that resolved a publicly known run-time vulnerability to name every one of them under Security, each by an identifier from a published advisory. The changelog area required the six Keep a Changelog groups and never this, so a reader could not learn from a release entry whether the upgrade was urgent. The scope is what reached users. A development-only dependency stays out, and a build toolchain counts as run-time wherever the project ships what that toolchain produced, because a compromised bundler injects into the artifact users install. Any published advisory identifier counts rather than a CVE alone, so a GitLab advisory or an ecosystem database identifier is accepted. A project that has fixed none falls outside the rule. oss-changelog owns it. With R-CI-06, the standard now holds 56 rules.

Changed

• Breaking: R-COM-04 caps the response window at 14 days. It accepted any stated window, so a policy promising an answer within a year satisfied it, and a window with no ceiling tells a finder nothing about when to escalate. A repository whose SECURITY.md states a longer window fails the rule from now on. The number comes from the badge criterion vulnerability_report_response, and oss-community no longer writes a window above it.
• Breaking: R-COM-02 asks the contributing guide for two more things: that a change adding functionality arrives with a test, and which document states what an acceptable contribution must satisfy. That document has to exist at the path or URL the guide names. A contributor used to learn in review that a feature needed a test. A repository whose guide is missing either clause fails the rule from now on. oss-community writes both, and asks which document to name rather than inventing requirements nobody agreed to. This repository failed the first clause, and CONTRIBUTING.md now states it.
• R-SEC-04 asks a repository of any size only for what works at any size: a change request as the only path onto the default branch, at least one passing CI status check, and no force pushes or deletion. It required an approving review, which a sole maintainer cannot supply. Every repository that met the old rule meets this one, so nothing that passed yesterday fails today. OpenSSF Scorecard’s Branch-Protection check, which R-SEC-04 already cited, states the reason in its own voice: requiring code review “is not feasible for all projects, such as those that don’t have many active participants”. Both rules now say out loud what skipping review costs, because Scorecard gates each tier on the one below it and a repository outside R-SEC-12 therefore caps at 3 of 10 rather than 8.
• oss-harden stops telling a single-maintainer project to exempt itself. It used to require the review and then add Repository admin to the ruleset’s bypass list, which left the one person the requirement named as the one person exempt from it, and every pull request reading BLOCKED while nothing was blocked. The skill now leaves required_approving_review_count at 0 where R-SEC-12 does not reach the repository, and keeps the bypass list empty, which binds the owner to the ruleset instead of exempting them. The four review parameters on the pull_request rule are grouped as review controls and go on together; required_review_thread_resolution and allowed_merge_methods need no reviewer and stay recommended for everyone.
• R-COM-06 takes the same scope. A CODEOWNERS file on a repository where one principal can merge assigns a reviewer to the only person who could have merged the change anyway, and the enforcement setting behind it now lives in a rule that does not reach there either.

0.5.2 - 2026-07-29

A change request stops being written as though it were a commit.

Changed

• oss-community derives a change-request template’s sections from what the project’s review needs, and writes the template for the forge that renders it. It had one paragraph on the subject, all of it about which fields to collect. A description is read on the forge before the diff, so the template uses headings the forge renders, one bullet per separable part of the change, and a table where the answer is a list of things and a fact about each. A repository that reuses the description as its squash commit message is no longer a reason to write one flat paragraph. Each section’s guidance goes in an HTML comment under its heading, and the template says that a heading with nothing under it should be deleted, since neither forge can require a field and an empty section reads as an unanswered one. The skill now proposes those sections to the maintainer before writing the file, which it already did for issue fields.
• oss-writing no longer lets a change-request description inherit the rules written for a commit body. The two shared one reference, and the shaping rules there assume a commit: default to silence, no markup, one paragraph per line. A description is rendered on the forge and read before the diff, so it uses the markup the forge renders, gives a change with separable parts one bullet each, and earns its length from what review needs rather than from what a commit body earns.

0.5.1 - 2026-07-29

oss-writing is rebuilt from its sources and split by artifact, and it decides a commit body from the facts a change carries rather than from the size of its diff.

Changed

• oss-writing is rebuilt from the sources it cites, which were re-read on 2026-07-28, rather than trimmed. Each source was distilled and then filtered against Anthropic’s criterion that a skill adds only context the model does not already have. It drops the RFC 2119 section, the per-artifact table covering issues and ADRs, the body-trigger ladder, the ban on narrating the author’s route to a fix, and the restatement of Conventional Commits. It gains Git’s three-part body order, the status quo in the present tense, git show -s --pretty=reference for citing a prior commit, the Google style guide’s timeless-language word list, the ban on inflecting a code element, and putting a condition before its instruction. The body is 101 lines where it was 208, and what left it is now loaded per artifact from four references: commits and change requests, code review, documentation, and a linting map. references/commits-and-prs.md is renamed to references/commits-and-change-requests.md. Forge scope is GitHub and GitLab, so the artifact is a change request rather than a pull request.
• oss-writing earns a commit body from the facts a change carries rather than from the size of its diff. The consequence condition reaches a change whose safety rests on a fact the diff cannot show: a version bump that is metadata-only, a removed symbol with no callers, an edit leaving the built artifact byte-identical. The diff shows what moved and cannot show that nothing broke. Measured on 59 commit tasks with the stratum label stripped from the prompt, the skill went from writing 0 of 7 earned bodies to 7 of 7, while still writing none of the 27 that were not earned. The previous wording suppressed a body whenever the diff looked small, which is the wrong question. The check list also opens with a step that counts the longest sentence, which took the worst prompt from four over-length sentences to one.
• oss-writing ships references/linting.md, which maps each mechanically checkable rule onto a checker and, more usefully, names the rules no checker can decide: whether a claim is true, whether a body was earned, whether a bolded bullet is a label or a claim. The tell catalog gains the intensifiers very, simply, and just, and the filler phrases in the event that, at this point in time, and a number of. A review comment may open with a Conventional Comments label where the repository has adopted that convention, with the two-sentence body unchanged behind it. All three came from a comparison against an independently researched skill draft; the linting map and the flattened word list are the parts that draft carried and this one did not.
• The sources.json in each derived skill records how the fork differs from its upstream now, rather than every edit that got it there. oss-writing had 34 entries, 16 of them appended one per commit. Two pairs cancelled outright: one entry recorded adding guidance for error messages and log lines, and another recorded dropping it. Across the four files 61 entries become 33. AGENTS.md states the rule, and tests/authored-docs.test.ts now parses each file, so the prose in it is checked for the dashes the house style forbids.

Removed

• oss-writing no longer covers error messages, log lines, and code comments, and its description no longer claims them. Those strings live inside source files, and this kit does not edit code. A project that wants them held to a standard needs a skill that owns the code, not this one.
• oss-writing no longer warns that a forge can be configured to reuse a change-request description as the permanent commit message, and references/forge-rendering.md, which carried that behavior along with GitHub’s 76-column rewrap and the single-newline difference between the two forges, is deleted. The setting is invisible from a clone, so the warning covered a real hazard, but per-forge mechanics are too specific to hold lines in a skill that loads on every invocation. The one clause that changes what gets typed stays in the body: keep the subject to 72 characters or fewer, counting any number the forge appends on squash.

0.5.0 - 2026-07-28

Three new rules take the standard to 53, and two of them ask for evidence no file in the repository can show.

Added

• R-SEC-10 and R-SEC-11 add the detection half of the SEC area, taking the standard from 51 rules to 53. Every SEC rule before them scored a file or a setting, so a repository could pin every action, commit a lockfile, and guard its default branch while secret scanning and dependency alerting sat switched off, and oss-audit scored it green. Both state an outcome and let the Check enumerate per-forge evidence, so a GitLab Free project reaches R-SEC-10 through the pipeline secret-detection template rather than being told to buy Ultimate. A repository that gates CI on a clean oss-audit run starts failing the day it upgrades, until it enables the two controls or records why neither reaches it.
• R-COM-09 requires the issue chooser to name the project’s non-defect channel, taking the standard from 50 rules to 51. A project that opens a discussion forum and leaves .github/ISSUE_TEMPLATE/config.yml silent has two channels and one visible door, so the questions keep arriving as issues and the forum stays empty. The rule reaches only a project that already runs such a channel, since whether to run one is the project’s decision and not the standard’s business, and it deliberately says nothing about blank_issues_enabled, which is a separate switch. It is GitHub-only because contact_links is.
• oss-community documents discussion category forms, which GitHub reads from .github/DISCUSSION_TEMPLATE/<category-slug>.yml using the same form schema as an issue form with three top-level keys instead of seven. The skill covered the issue chooser and the issue forms and said nothing about them, so a project routing questions to Discussions had no way to learn that the destination can collect structured reports too. The reference also carries the repository, organization, and per-category Discussions URL shapes, since contact_links needs one and they are easy to confuse.

Changed

• oss-harden derives which detection controls apply from the forge, its tier, and the ecosystems the project ships, rather than checking a fixed list, and it reports a control as enabled only after reading the value back. GitHub’s repository PATCH answers 200 while silently discarding a field the repository has no entitlement for, and security_and_analysis is absent rather than disabled for a caller without admin, so a run that trusted the write, or read a missing key as off, would report a control that is not on and a gap that may not exist. The skill also closes with what the maintainer has to enable by hand, kept separate from the rule findings so an unmet rule and an available extra do not read alike.
• The README sends questions to Discussions and keeps Issues for a defect, a rule proposal, or a skill change. The two used to share the tracker. The chooser now says the same thing, and it also answers the case no form covers: 02-rule-proposal.yml requires a mechanical check, so somebody who thinks a rule is wrong without having one to offer had nowhere to file. The blank issue is off, which was not available before Discussions existed, because hiding it would have closed the only channel a question had.

0.4.0 - 2026-07-28

Every rule now names the upstream it rests on, or argues its own case, and four new rules take the standard to 50.

Added

• Four rules, taking the standard from 46 to 50. R-PUB-05 requires a release that carries a built asset to carry a software bill of materials describing it. R-PUB-06 requires those assets to be signed, or listed by hash in a signed manifest; it is separate from R-SEC-05, which covers the tag object and not the files attached to the release. R-COM-08 requires a documented statement of who decides and what happens if they stop, and a single-maintainer project satisfies it by saying so. R-DOC-10 requires the README to name one thing that sets the project apart, backed by a boundary, a measured number, or an alternative named outright; it restores a clause oss-readme dropped from the skill it was forked from, and gives that skill’s longest section, the facts list, a rule to be scored by.
• Every rule holding this standard’s own position now records the argument for it: what was observed, and what would retire the rule. tests/rule-sources.test.ts fails when a rule with no upstream source carries no argument, and each rule page on the docs site prints that argument where a sourced rule prints its sources. scripts/rule-freshness.mjs measures against the rules that have a source, since a rule with nothing to re-read can never be verified and held the number below 100% permanently.
• CONTRIBUTING.md has a Governance section, which is how this repository satisfies its own R-COM-08: one maintainer decides and releases, contributions arrive from forks because nobody else has write access, and no succession is arranged.
• Each rule page on the docs site now shows where its opinion comes from: the upstream sources it was last read against, the date, and what that reading did and did not cover. A rule with no upstream says so in those words instead of rendering an empty list.

Changed

• Breaking: R-DOC-02 requires the README’s usage example to show what it returns, in a comment inside the block or in a block directly below it. A README whose example ran but printed nothing satisfied the old check. oss-readme has asked for the result since it was written, so the rule was the weaker of the two and an audit passed what the skill would have rejected. The line count stays in the skill: a rule that fails a README over an eleven-line example is a rule people route around.
• Breaking: the release and publishing area applies to any repository shipping a built artifact to people who did not build it, where it previously applied only to repositories publishing to a package registry. A repository attaching built assets to a forge release was excluded by the old preamble and is now in scope for the whole area. R-PUB-02 carries its own registry scoping, since trusted publishing has nothing to authenticate to without one. A repository shipping only source is still outside the area.
• oss-writing bans a clause that tells the reader how to weigh a fact just stated, such as and that is the finding rather than a gap to paper over. The tell catalog covered only the upbeat form of this, and only as a whole sentence, so the defensive form passed every check the skill ran. Omit needless words now names the clause and the sentence alongside the word.

Fixed

• oss-writing illustrates the allowed bolded-claim bullet with a claim about this project. It had borrowed a well-known project’s benchmark line verbatim, which reads as a claim oss-kit is making, and oss-readme carried the same borrowed line.
• oss-readme names no third-party project. Its worked opener was an edited quote of a well-known project’s README, altered to demonstrate the install-then-example order R-DOC-02 requires: the bullets lost the bold the skill’s own Bullet shape section asks for, and an install block was added where that project has none. Both worked examples now come from this repository’s own README, which passes the rules it teaches, where a famous opener would carry a logo or a translation row above its first sentence and teach the departure along with the shape.
• The rule counts quoted in prose are derived from STANDARD.md rather than typed. tests/rule-counts.test.ts fails when README.md or skills/oss-readme/SKILL.md states a total, or a both-forges count, that the standard no longer holds, and rejects any other rule count in either file so a third sentence cannot go stale unnoticed. Both had already drifted: the slate in oss-readme offered 45 rules and 40 of 41 on both forges. They are the two files that exemplify R-DOC-04, so they were the last two that should have carried an unchecked number.
• The worked oss-audit output in the two files that already quote a rule total is checked by its arithmetic rather than its wording. A breakdown states no total, so Audited 41 applicable rules: 38 pass, 2 fail, 1 unknown, 5 not applicable named nothing a count of rules could be compared against and stayed green while the standard grew. tests/rule-counts.test.ts now reads those numbers out and requires applicable plus not applicable to be the whole standard, the three verdicts to sum to the applicable count, and the parenthesised PUB figure to match the area. The example in oss-audit’s own skill is corrected but left unguarded, because that file quotes no total and its reader is an agent learning the shape of the output.
• The three worked oss-audit outputs count the standard they audit against. README.md and skills/oss-readme/SKILL.md split 46 rules after the standard reached 50, and skills/oss-audit/SKILL.md had been splitting 39 since before this release, so each showed a total no version of the standard has ever held.
• skills/oss-readme/sources.json describes what the fork actually changed. It recorded references/badges.md as revised from upstream, but upstream is a single SKILL.md with no references directory at the pinned SHA or on main, so that file is new here. It also left out the three divergences that matter most: upstream deletes every badge and this fork keeps three, upstream asks the opening block for three things and R-DOC-01 keeps one, and upstream puts the example before any install step where R-DOC-02 reverses them.
• oss-community names every DOC rule that belongs to oss-readme. Its boundary sentence still read R-DOC-01 through R-DOC-04, written when the area ended at R-DOC-05, so R-DOC-06 through R-DOC-09 appeared to belong to nobody.
• The site’s changelog page publishes released versions only. The generator copied this file whole, so the page carried an Unreleased heading that renders empty between releases and advertises uninstallable work the rest of the time, along with a comparison link that moves on every merge to main.
• The site’s changelog page links the README’s Versioning section on GitHub. It is the one generated page with no sibling page to point at, so the relative target shipped raw and answered 404.

0.3.1 - 2026-07-28

Changed

• oss-writing gates the commit and change-request body behind a closed trigger list instead of listing what a body carries. The default is now no body at all, and one of six named conditions has to hold before one exists. The old table read as a checklist to cover, which is where padded git prose came from.
• oss-writing moved the GitHub and GitLab render mechanics into references/forge-rendering.md, loaded only when a description is about to become a squash commit message. The body keeps one forge-agnostic rule: forge fields take one paragraph per line, unwrapped.
• oss-writing states a subject budget of 72 characters, counting any number the forge appends on squash. It also makes the sentence and paragraph figures hard limits, where they were signals to split. Git’s 50-character subject predates the type(scope): prefix, which spends 15 to 20 of those characters.
• oss-writing no longer bans naming the failure a change targets. Recording the run that went wrong is a reproduction, which Git’s own guidance asks for; only the author’s route to the fix is noise.

Fixed

• The site’s home page no longer clips the domain map on a narrow window. Between 418px and 526px the map kept its two-column form inside a narrower container, which cut off the count column, the right edge of every bay, and the active bay’s marker.
• Running prose on the site is capped at 58ch rather than 72ch, which measures about 70 characters a line instead of 84. Code blocks, tables, and install commands keep the full pane.
• Every rule page’s Fixed by cell links to the owning skill’s list of rules rather than to the top of its page, and a skill that names its rules only in prose gets a generated list to link to. Header navigation links also clear the 24px target floor from WCAG 2.5.8.
• The README skills table keeps every skill name on one line. GitHub’s table layout was squeezing the name column to the width of community because the descriptions in the second column took the whole budget; they are now one line each, and the skill pages carry the detail.

0.3.0 - 2026-07-27

Five new rules, and oss-audit now reports the gaps alone rather than every rule it checked.

Added

• A tell catalog at skills/oss-writing/references/tells.md, 22 lexical patterns with what to write instead of each. It took the kill list out of the always-loaded body, roughly a third of the skill’s rules, because the lexical tells are the part a model cannot reproduce from judgment and the composition rules are the part it can. It loads when a draft reads padded, generic, or promotional, rather than on every invocation, and it is published at oss-kit.svyatov.com/skills/oss-writing/tells.
• Four composition rules in oss-writing, each of which costs a non-native reader more than a native one: name the referent, cap noun stacks at three, one instruction per step, keep the articles. Paraphrased from ASD-STE100, which is cited and never reproduced.
• A normative statements section in oss-writing. Uppercase MUST, SHOULD, and MAY carry their RFC 2119 and RFC 8174 meanings only where the document claims them; a README that shouts MUST has invented a requirement nobody is checking.
• R-COM-07, the forge project page says what the project is and where it lives. A search result, a social card, and the forge’s own project lists show the description and the topics and render none of the README, so a project with an empty description is findable only by someone who already has the link. oss-community gains a step for it, and both reference files gain the field limits, the commands, and the feature tabs each forge exposes.
• A reference at skills/oss-community/references/report-fields.md for deriving what a bug report has to collect. It carries the test for whether a field belongs, the five places in a repository that name the axes a defect can differ on, and which form element carries which kind of fact.
• Issue forms for this repository, replacing the two Markdown templates. A bug report now asks for the harness and the model, without which a report cannot distinguish a skill whose instructions are wrong from a host that loads skills from a different path. A rule proposal collects the five parts a STANDARD.md rule needs, so a proposal arrives with the check that decides whether it can be scored at all.
• A test that scans the skills tree and the root documents for em dashes, en dashes, and --. It reads prose only, stripping fenced blocks and inline code, so a rule can still name the pattern it forbids. The tree had none, and now nothing can add one unnoticed.
• Four documentation rules, all fixed by oss-readme. R-DOC-06, the README names what the project covers and where it runs, so a reader can tell in five seconds whether they are in the audience. R-DOC-07, every fenced code block carries a language tag and, when its destination is not a shell, a sentence above it naming where it goes. R-DOC-08, the README links a public, searchable channel for questions and defect reports. R-DOC-09, the README says whether the project is maintained.
• A procedure in oss-readme for building the facts list: sweep the repository for candidates, record the source file of each, sort them into the five questions a reader is asking, then present the slate and stop for the maintainer to pick three to five. The writer no longer chooses alone.
• A section in oss-readme for projects with more than one entry point, which name one thing to run first and cover the empty-repository case separately. It rests on no external convention and says so, because the published README guidance does not address such projects at all.
• A note in oss-writing that GitHub turns a single newline into a line break in an issue, a pull request, or a discussion, and into a space in a Markdown file. Prose hard-wrapped the way a repository file is written therefore renders ragged once it is pasted into a pull request description. GitLab does not share the behavior, so the fault is invisible until someone opens the pull request on GitHub.

Changed

• The release and publishing area is scoped to repositories that publish a package, the way the agent skills area is scoped to repositories that ship skills. Without a preamble the area had no stated precondition, and oss-audit is told not to infer one, so every repository shipping through git tags alone failed four rules for having no publish step to secure. R-CI-04 and R-CHG-05 gain the same sentence R-SEC-09 and R-SKL-05 already carried: a check with nothing to look at puts the rule out of scope rather than passing it on an empty set. Two auditors were reaching two different counts on one repository.
• R-SEC-05 names where the maintainer’s signing key comes from, per forge, and says that a missing gpg.ssh.allowedSignersFile is the check failing to run rather than the tag failing to verify. The rule asked for a key to be imported and never said from where, so a correctly signed tag audited as unknown on every checkout that had not been set up by hand beforehand.
• R-CI-02 compares checks rather than command strings. A project may run a documented check in CI through a second runtime or through the script its documented alias wraps, which this repository does to prove its validator works on Node and not only on Bun. A documented command with no CI job behind it still fails, which is the drift the rule exists to catch.
• oss-audit says in its count line why the not-applicable rules were skipped, grouped by reason. The count already reported how many, and a reader could not tell a rule that does not reach their repository from one the audit dropped.
• oss-audit reports the gaps and nothing else. The per-rule table listed every passing rule, so a repository meeting 28 of 34 rules answered with 28 rows nobody reads and then repeated the four that matter in a prioritized list below. The report is now a count line, which is the whole output on a repository with nothing to fix, followed by one line per fail and then per unknown, in priority order, each naming the evidence and the skill that fixes it. Every rule is still checked and every finding still carries its evidence; what changed is what reaches the screen.
• This repository’s pull request template is written as the commit message it becomes. GitHub is set to squash with the pull request body as the commit message, so the old template’s headings and ticked checkboxes are permanent in git log, one of them broken mid-sentence by hard wrapping. The template now prompts for paragraphs and seeds one Affects: trailer, and it asks for what CI cannot report: the run behind a skill change, and whether the public API narrows. The checklist moved to CONTRIBUTING.md, since every check it asked contributors to confirm already runs on every pull request.
• oss-writing says that a pull request description may be the commit message. A repository can set the squash commit message to the pull request body, no clone reveals that it did, and where it is set a heading, an unticked checkbox, or an HTML comment left in the body is permanent in history. GitHub does not strip comments, so template guidance can survive in git log while rendering as nothing on the pull request page. It also rewraps the body at roughly 76 columns without splitting a word, so hard wrapping a description arrives wrapped twice, which is where a commit body broken mid-sentence comes from.
• oss-community says what a change-request template should ask for. A checkbox asking whether the contributor ran the tests duplicates a required check and reads as satisfied whether or not it is, so the step now says to read the project’s pipeline first and ask only for what no job produces.
• The install command passes --skill '*', in the README, the install guide, the site’s copy button, and oss-audit. The skills CLI is interactive by default, so the bare command opened a picker and the reader selected all nine skills by hand, which is not what a command labelled “install the kit” should ask of anyone. --all would go further and answer the agent and scope questions too, and those are the reader’s to answer. skills/oss-skill/references/hosts.md gains the flags this rested on.
• R-SEC-04 accepts a repository ruleset as evidence on GitHub, not only a classic branch protection rule. Its check now reads repos/{owner}/{repo}/rulesets alongside the classic endpoint, which answers 404 Branch not protected on a repository guarded by a ruleset. Any repository that passed before still passes; a repository on the form GitHub now recommends stops auditing as a fail.
• oss-harden reaches for a ruleset’s code scanning rule on R-SEC-09, alongside the required status check rather than instead of it. A required check asks whether the analysis reported; the rule asks what it found, and it also blocks when the tool is unconfigured, which is the case a required check cannot express because deleting the analysis setup removes the check rather than failing it. The reference carries both threshold enums, the command that confirms the tool’s reported name, and the note that a name matching nothing blocks every merge. GitHub Code Quality’s equivalent rule is described with its licensing and Actions cost, and with the fact that the REST reference does not document it yet.
• oss-harden sets up branch protection on GitHub as a ruleset, with classic protection kept as the form to read rather than to create. The reference file gains the four rule types that carry R-SEC-04, the ~DEFAULT_BRANCH condition, the migration order that never leaves the branch unguarded, and the four pull_request parameters worth setting past what the rule requires, including why allowed_merge_methods is not redundant with the repository’s own merge checkboxes. It also answers the question a ruleset cannot: no rule keys on who clicks merge, the update rule that reads like the answer covers direct pushes only, and repository access is where restricting merges actually happens. It also gains the bypass list, which inverts the classic admin exemption: a ruleset binds everyone unless an actor is listed, so a single-maintainer project that requires one approving review and lists nobody cannot merge anything at all.
• oss-readme judges a fact by the reader question it answers rather than by the kind of evidence behind it. The old list admitted a benchmark, a size, a code comparison, and a screenshot, all of them properties of the artifact, which left no slot for what a project covers or what it needs from you. Those two are now the slots most often missing, and the first is mandatory wherever a project has a boundary.
• oss-writing separates a bolded label from a bolded claim. - **Performance:** it is faster is still banned, because the stub displaces the sentence. - **Fast.** 50% faster than X. is allowed, because there the bold is the claim and the rest is its evidence. Delete everything after the bold to tell which one you wrote.
• oss-readme says why it keeps the badge row below the tagline when the projects it takes its structure from put badges above the title. R-DOC-01 exists to spend a reader’s first five seconds on the sentence, and the divergence holds only because the badge cap is three.
• Every hard constraint in oss-writing now says what goes wrong when it is broken. A bare prohibition is weaker than the same prohibition with its reason attached.
• The README leads with what the kit is, then one install command and one worked example, in that order. The install variants and the per-host plugin commands moved below the example, because three install blocks used to run back to back before a reader saw the kit do anything.
• The README states the facts a reader picks a tool on: the rule count, the routing from a gap to the skill that fixes it, the 500-line ceiling on a skill body, and the single bundled script that needs nothing installed.
• The README links the rendered install guide and standard on oss-kit.svyatov.com rather than the Markdown sources under site/. A reader on GitHub was being sent to a source file when a published page exists.
• oss-community derives the fields of an issue template from the project rather than from a generic bug-report shape. The facts a maintainer needs are the variables that decide whether a defect reproduces, and the repository names them: the CI matrix, the manifest’s supported-version ranges, the hosts the install guide claims, and the follow-up questions on closed issues. The step now presents that slate before writing anything, and calls out the variable the maintainer’s own setup holds fixed, which is the field they are least able to notice is missing.
• oss-community prefers a GitHub issue form over a Markdown template on a public repository, and marks the fields a maintainer cannot triage without as required. A template made of headings enforces nothing, so a contributor can delete every heading and satisfy R-COM-05 with an empty issue. Markdown stays the documented fallback for a private repository and for GitLab, which has no form schema at all.
• oss-community no longer names a Contributor Covenant version. It reads the steward’s site for whatever version is current, because a version number in a skill body goes stale the moment the steward publishes the next one. An older version already in a repository still satisfies R-COM-03 when its reporting contact works, so the skill says so rather than replacing a working file.
• oss-community handles a license file that has no manifest to match, which is the case for every private or unpublished package. R-COM-01 still needs the file to exist and to name its license, so the step reads the file itself and cross-checks the other places a repository states one.
• The four skills derived from third-party work credit the maintainer alongside the upstream holder in their sources.json. Each file named only upstream, which understates one side of a joint work after the rewrites those same files document. The unread license_override and license_override_reason fields are gone, and the README credits list is now a line pointing at sources.json, so attribution lives in one place per skill instead of a list that grows with every borrowing.

0.2.0 - 2026-07-27

Added

• oss-skill bundles a validator at scripts/validate.mjs that checks a repository against R-SKL-01 through R-SKL-05. It needs Node 22 or later, or Bun, and nothing installed: it imports only Node built-in modules, reads files, and makes no network call.
• STANDARD.md gains R-SKL-05, a script a skill ships uses sh or Node with no dependencies, because it runs on the reader’s machine rather than the author’s, and R-SKL-06, every host a repository claims support for has a committed manifest or a documented install command.
• Plugin manifests for Codex CLI at .codex-plugin/plugin.json and Cursor at .cursor-plugin/plugin.json, Codex’s own marketplace at .agents/plugins/marketplace.json, and an .opencode/skills symlink. Each host now finds the skills where it scans.
• A documentation site generated from STANDARD.md and the skills, served at oss-kit.svyatov.com and redeployed on every push to main. Every rule has its own page, so a rule can be linked and read without installing anything.
• Install, getting started, and adoption guides on that site. The install guide covers every claimed harness, one section each.
• oss-ci covers static-site deployment, for GitHub Pages and GitLab Pages. It carries no rule, since no rule requires a project to publish a site, so the skill asks before writing a deploy and writes none for a project that only builds a site as a check.
• The README declares the public API that Semantic Versioning covers: skill names and paths, rule IDs and what they require, the bundled validator’s command line, and the manifest paths each host reads.

Changed

• R-SKL-02 now names the validator oss-skill bundles. The rule already accepted any specification validator, so what it requires has not changed.
• oss-harden reads the upstream project’s newest release before pinning an action, component, or image, and reports a lagging major to the user instead of freezing it. R-SEC-01 and R-SEC-06 accept a SHA regardless of the age of the tag behind it, so a stale pin used to pass unquestioned and then read as audited.
• The README install section shows the two fastest commands and links to the install guide.
• Every plugin and marketplace manifest describes oss-kit as Curated agent skills for open source maintainers, the same line the site carries. The manifests called it an opinionated quality bar, so the pitch a reader saw depended on whether they arrived through a plugin browser or the site.
• Security reports go through GitHub private vulnerability reporting, now enabled on this repository. Email stays the fallback.
• CONTRIBUTING.md names the documentation site build. CI requires that check, and the guide used to say the repository has no build step, so a contributor who touched site/ passed every documented command and still failed the merge.

Removed

• The skills-ref validator is no longer installed in CI or named in the contributing guide. The bundled oss-skill validator replaces it, so the project no longer depends on a tool whose upstream describes it as for demonstration only.

0.1.0 - 2026-07-23

Added

• STANDARD.md defines the 38 numbered rules the skills in this kit check a repository against, each with a check a tool can run and the skill that fixes a gap.
• oss-writing rewrites commit messages, pull requests, issues, and documentation prose into plain, active, marketing-free sentences.
• oss-readme orders a README so the install command and a working example come before motivation, and links the license, changelog, and contributing guide.
• oss-ci writes GitHub Actions or GitLab CI/CD configuration for lint, test, and build, matched to the runtime versions a project claims to support, with lockfile-keyed caching and job timeouts.
• oss-publish sets up trusted publishing, build provenance, and an approval gate for npm, RubyGems, PyPI, and crates.io releases, on both GitHub Actions and GitLab CI/CD.
• oss-community writes the community and governance files: CONTRIBUTING, CODE_OF_CONDUCT, SECURITY.md, issue and merge request templates, and CODEOWNERS.
• oss-harden pins GitHub Actions to commit SHAs, sets least-privilege workflow permissions, keeps untrusted input out of shell commands, configures Dependabot or Renovate, locks dependency resolution to a committed lockfile, runs static analysis on pull requests, and checks branch protection and signed release tags.
• oss-changelog keeps a changelog in Keep a Changelog format, decides the semantic version bump for a change, and drafts release notes from merged work.
• oss-audit scores a repository against STANDARD.md, reports each gap with the rule it fails, and names the skill that fixes it.
• oss-skill fixes the structure of a repository that ships agent skills: the top-level skills/ layout, SKILL.md conformance to the Agent Skills specification, oversized bodies that belong in references/, and the license field an extracted skill carries with it.