Install any skill in seconds. Free to start, no credit card required.
Get Started Free →levnikolaevich/ln-63-release-publisher
Prepares and publishes a tagged GitHub release from repository evidence.
Passed 8 of 13 test cases with the skill, and 7 of 13 without it.
and 3 more in the full report
5 fixed9 passed either way6 still failing3 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 4 test cases the skill fixed. Same model, same prompt, with and without the skill.
We have prepared all release assets for repository cloud-native/storage-agent targeting version tag v3.0.0. All local release gates passed and notes are generated, but the user has not yet granted explicit approval to publish. Provide the release assessment in 5 structured sections: Result, Scope, Evidence, Verification, Completion.
| Checked | Without skill | With skill |
|---|---|---|
| The status verdict in section 1 is READY. | Missed | Passed |
| Halts execution to await explicit user approval before publishing. | Passed | Passed |
The instructions your model reads when the skill loads.
Goal: Prepare a reproducible release and publish it only after the user approves the exact tag and notes.
Execution contract: The ordered checkboxes are the Definition of Done. Track every item internally as PENDING, PROVEN with concrete evidence, CLEARED with evidence that its condition is absent, or UNPROVEN with a gap; reading, delegation, or tool failure is not proof. Reconcile items after each section. Before returning, resolve all PENDING and count only PROVEN and CLEARED; apply the skill's verdict and approval rules to every gap.
Preserve user intent, scope, and existing authorization. Continue authorized work; ask only for consequential unresolved choices or required external approval. Scale depth to material risk without silently skipping checks. Preserve dependency and safety ordering; otherwise choose the verification method appropriate to each obligation.
| Need | Preferred capability | Fallback |
|---|---|---|
| Release boundary and commit evidence | Git history, tags, and diffs | Hosting API commit comparison |
| Existing release style and state | Authenticated GitHub CLI or connector | Public GitHub API for read-only evidence |
| Release identity and version scope | Repository policy, prior tags, and canonical version files when present | Stop only when the release identity remains ambiguous |
| Release validation | Repository-native gates and clean checkout | Manual structural checks with reduced confidence |
| Tag and GitHub Release creation | Git plus an authenticated GitHub release capability | BLOCKED; do not emulate release state in files |
| Installation verification | Isolated environment against the documented distribution source | Clean source validation without install proof |
When publishing through a shell, use a temporary notes file so Markdown, quotes, and code blocks are not reinterpreted. Keep credentials in the host credential store and never echo them.
Do not browse for generic release advice when repository policy and previous comparable releases answer the question. Use official host documentation only for current API or CLI behavior.
test cases passed, vs 7 / 13 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.