Borrowing it
Nothing to install: this file belongs to paladini/harness-score. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/paladini/harness-score/main/.cursor/skills/release/SKILL.mdgit clone --depth 1 https://github.com/paladini/harness-scoreWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/paladini/harness-score/release)<a href="https://agentmods.dev/skills/paladini/harness-score/release"><img src="https://agentmods.dev/badge/skills/paladini/harness-score/release/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/paladini/harness-score/release"><img src="https://agentmods.dev/badge/skills/paladini/harness-score/release.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to high
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- high Tool Misuse · line 49 Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).Fix: Validate all tool parameters against an allowlist. Reject dangerous parameter values (shell=True, --force, -rf /) and use safe defaults.
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00037 | $0.00899 |
| Opus 5.5 | $0.00015 | $0.00360 |
| Sonnet 5.5 | $0.00007 | $0.00180 |
| Haiku 4.5 | $0.00004 | $0.00090 |
Grade A, and why
release scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
What it actually says
Releasing harness-score
Release artifacts are English unless the user explicitly requests another
language: changeset bodies, CHANGELOG.md entries, and GitHub release notes.
Credit contributors with explicit @handle lines in the changeset when they
are not the merge author.
- Confirm every user-facing change has a changeset with an English summary and explicit contributor credit when applicable. Commit metadata alone is not sufficient attribution.
- On a clean release branch from
main, runnpm run release:prepare -- --summary "One sentence explaining why this release matters.". This versions the package from changesets, mirrors the version intoTOOL_VERSION,jsr.json,package-lock.json, both byte-identical GitHub Action entrypoints, and the Action README, runs all release gates, and writes a polished preview under.release/. Review both the diff and the rendered notes.plugins/cursor/.cursor-plugin/plugin.json(+ entry inplugins/cursor/CHANGELOG.md) — only if Cursor plugin content changed, it has its own release trackplugins/claude-code/.claude-plugin/plugin.json— only if Claude Code plugin content changed; no separate publish step, a version bump- push to
mainis the entire release (the marketplace is this repo)
- push to
- Open and merge a
release: vX.Y.ZPR. Do not create a tag or release from the unmerged branch. - After merge, dispatch
.github/workflows/prepare-release.ymlfrommainwith the exact version, a short title, and the one-sentence summary. It reruns the gates, validates every version surface, generates release notes from the changelog, preserves contributor credit, creates the immutable tag, and opens a draft release. - Review the draft in GitHub. Select Publish this Action to the GitHub Marketplace, using Code quality as the primary category and Continuous integration as the secondary, then publish. This checkbox is manual because GitHub exposes no Marketplace publication API.
- Publishing fires
.github/workflows/release.yml, which validates the public release notes and publishes to all three registries:- npmjs.org as
harness-score, via Trusted Publishing — the user configures this once on the package's npmjs.com settings page (repo + workflow filename), then every CI run authenticates automatically, bypassing the 2FA/OTP prompt entirely. - GitHub Packages as
@paladini/harness-score(automatic, uses the built-inGITHUB_TOKEN, no secret needed — the repo's Actions "Workflow permissions" must be set to Read and write). - JSR as
@paladini/harness-score(automatic via OIDC — but the scope must be claimed once by the user at jsr.io/new before the first publish succeeds).
- npmjs.org as
- The workflow moves the stable major Action tag only after every registry
succeeds, then verifies npm, GitHub Packages, JSR, the GitHub Release, the
stable tag, the Marketplace listing, and Pages. Never move
v1manually before those gates pass. If a job fails, use Re-run failed jobs, not a full rerun that would try to republish immutable registry versions. - Cursor Marketplace: the listing updates from the repo — remind the user
to resubmit at https://cursor.com/marketplace/publish only if
plugins/cursor/metadata changed. Claude Code has no separate marketplace to resubmit to — see step 2. - Docs deploy automatically via
.github/workflows/pages.ymlon push tomain; verify the public Pages site separately.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago Changed · +5 lines 11d40e28c523
- 1mo ago Changed · +1 lines f2fc5167b383
- 2mo ago First seen · 60 lines · 37 tokens per session scan A 39478eb3890d
release is a skill published in the GitHub repository paladini/harness-score (613 stars, last pushed 2d ago), licensed MIT. It adds 37 tokens to every session and 899 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
changelog-generator
Automatically creates user-facing changelogs from git commits by analyzing commit history, categorizing changes, and transforming technical commits into clear, customer-friendly release notes. Turns hours of manual changelog writing into minutes of automated generation.
share-a-library
Use when a managed library is ready to publish to GitHub and hand to teammates as an install command. Run the GitHub publishing steps, then return the exact shareable install command.
prepare-release
Use this skill whenever preparing agentsmesh for an npm release — whether first publish, patch, minor, or major. Triggers on: 'prepare release', 'ready to publish', 'ship version', 'release prep', 'get this to npm', 'bump version', 'cut a release', 'what's needed to publish'. Runs a strict ordered checklist: test…
release-manager
Tier: POWERFUL Category: Engineering Domain: Software Release Management & DevOps.
package-release-engineering
Use when preparing, validating, or documenting the release workflow for a TypeScript library published to npm, including semver, changelog, tagging, and publish safety.
homebrew-packaging
Use when preparing or maintaining Homebrew distribution for a CLI associated with a TypeScript library, including formula updates, archive naming, checksums, and release compatibility.