The skill is finished. The release is not.
Failed tests stay visible.

One install gives your agent the second half of the prompts-to-skill pair: it takes a skill that is already drafted and tuned, runs its trigger test cases and records what passed, sets the version and CHANGELOG, builds the zip, writes the README, and ends with a per-platform install checklist. A failing test sends the skill back to tune-skill instead of getting a quiet edit here.

8 release steps 3 preconditions 2 reference files 0 API keys

for coding agents · free, open, no auth

install

Copy one line. Release with the results attached.

Detects Claude Code, Cursor, Codex, Qoder and more, then writes the skill into the right folder. Install tune-skill alongside it: precondition 1 reads that validator, and this repo does not carry it.

npx skills add arm-pz/prompts-to-skill-release --skill prompts-to-skill-release

the run

Eight steps. The report counts what did not run.

SKILL.md holds the eight steps, references/release-steps.md the detail, readme-template.md the skeleton step 6 fills in. It packages and documents one thing and stops there: drafting belongs to prompts-to-skill, auditing a skill that exists to tune-skill, naming and the GitHub listing to findable.

Preconditions 3

It stops and reports unless all three hold. A gate marked "written, not run" counts as a warning, not a pass.

  • folder, name field and H1 match
  • validator shows no FAIL
  • prompts-to-skill logged Gate A and B
  • you said zip, repo, or both

Test & record 1-2

Every case in evals.json and the tune-skill table gets one of four results: pass, fail, reviewed-only, not-run.

  • no pass without running it
  • reasoning only? say "reviewed, not executed"
  • failures go back to tune-skill
  • re-run only the affected cases

Version 3

The first release is 0.1.0. An existing version field is left alone unless you ask for a bump.

  • one CHANGELOG entry
  • date in it
  • test counts in it

Package 4

The skill folder is the archive root, so unzipping gives skill-name/SKILL.md.

  • exclude .DS_Store
  • exclude __pycache__ · *.pyc
  • exclude evals holding personal data
  • verify with unzip -l

Discovery check 5

Three prompts that should trigger it, in your own words, and one that should not although it shares keywords.

  • judged from the description text
  • recorded as a read-through
  • no live-session claim unless tested

README, checklist, publish 6-8

The handover. Step 8 runs only if you ask for it, and then hands the live repo to findable for the name decision and listing.

  • README from the template
  • says which file placement it chose
  • checklist per platform: Claude app · Claude Code · Qoder · other agents · GitHub
  • ends by confirming the skill is visible

house rules

What it refuses to do.

Failures stay in the report

The report carries counts for pass, fail and reviewed-only, and a not-run case is named in its first line. The rule is one the skill sets on itself: a failed test means the skill is not ready, and the report says so rather than tidying it away.

It does not edit your skill

Step 2 sorts every failure into a description problem or a body problem and sends both back to tune-skill. Nothing about the skill's behaviour changes during a release. The skill that authors the draft is prompts-to-skill; this one only ships it.

Nothing shipped unasked

Publishing is step 8 and runs only on request. The archive is verified with a listing before anyone calls it packaged, and the discovery check is recorded as a read of the description, not as proof the skill surfaced in a live session.

Release it with the results still attached.

Free, open, and it never edits the skill you wrote. You decide what gets published.

Install prompts-to-skill-release Read the source