CtrlK
BlogDocsLog inGet started
Tessl Logo

release-mac-app

macOS app release: Sparkle, notarization, GitHub Release, Homebrew, closeout.

64

Quality

76%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/release-mac-app/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

82%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is a dense, highly actionable operations manual: executable commands, fully enumerated manifest keys, explicit failure-resume and verification rules, with real bundle scripts backing every referenced path. Weaknesses are mild: the manifest/1Password reference material is inlined rather than split out, the release workflow is never presented as an explicit ordered sequence, and one or two passages could be tightened.

Suggestions

Move the long manifest key and 1Password field documentation into a references/manifest.md (referenced one level deep from SKILL.md) to slim the main body.

Add a short ordered workflow section (e.g. 1. status check → 2. notes → 3. build/package → 4. appcast + verify → 5. draft release + check-assets → 6. publish → 7. Done checklist) so the command sequence is explicit rather than inferred from listing order.

Break the MAC_RELEASE_CODESIGN_* keychain paragraph into bullet points or move it to a reference file; it packs a dozen distinct behaviors into one run-on sentence.

DimensionReasoningScore

Conciseness

The body never explains concepts Claude already knows and is densely operational throughout ("Never print private key material", "Upload app/dSYM assets to a draft before publication"). It is not anchor 5 because a few passages could be trimmed: the codesign keychain paragraph (line 81) is a run-on covering a dozen behaviors, and the 1Password rules partially restate manifest field semantics.

4 / 5

Actionability

Commands are copy-paste ready with full paths and subcommands (status, notes, changelog-html, make-appcast, verify-appcast, check-assets, release, codesign-run, package-run), and every manifest key is enumerated with defaults, examples, and semantics (e.g. "MAC_RELEASE_SPARKLE_OP_REF — exact `op://Vault/Item/field` reference..."). Concrete coverage of the common cases, matching anchor 5.

5 / 5

Workflow Clarity

The Commands section order (status → notes → changelog → appcast → verify-appcast → check-assets → release) implies a clear sequence, and validation is genuinely present (verify-appcast, check-assets, the "Done" checklist, and the resume-on-failure rule that preserves release state). It is not anchor 5 because there is no explicit ordered walkthrough of a full release tying the commands together; not anchor 3 because checkpoints are explicit, not merely implicit.

4 / 5

Progressive Disclosure

Structure is good (Rules / Commands / Manifest / Done), the 76KB of implementation is properly externalized into scripts/mac-release and scripts/lib/mac_release.sh (both verified to exist), and the body documents the interface rather than the implementation. It is not anchor 5 because ~60 lines of manifest and 1Password field reference are inlined in SKILL.md rather than split into a references/ file (none exists in the bundle).

4 / 5

Total

17

/

20

Passed

Description

70%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description is compact and concrete, naming the full release pipeline with distinctive, low-conflict trigger terms. Its main weakness is the complete absence of a "when to use" clause, which both caps completeness and leaves triggering entirely to inference.

Suggestions

Append an explicit trigger clause, e.g. "Use when releasing, shipping, or publishing a macOS app, generating a Sparkle appcast, notarizing a build, or publishing a Homebrew cask."

Add common user synonyms such as "publish", "ship", "sign", and "appcast" so natural-language triggering matches a wider range of phrasings.

Mention Developer ID signing / keychain preparation explicitly, since it is a core part of the workflow but currently only implied.

DimensionReasoningScore

Specificity

"Sparkle, notarization, GitHub Release, Homebrew, closeout" lists several concrete, named actions covering the release pipeline. It sits at anchor 4 rather than 5 because signing and appcast generation are only implied, not stated; it is above anchor 3 since far more than 1-2 concrete actions are named.

4 / 5

Completeness

The "what" is clear (Sparkle, notarization, GitHub Release, Homebrew, closeout for macOS apps), but there is no "Use when..." clause or equivalent explicit trigger guidance, which per the judging guideline caps completeness at 3. It is not anchor 2 because the "what" is concrete and comprehensive, and not anchor 4 because "when" is entirely absent rather than merely imprecise.

3 / 5

Trigger Term Quality

Terms like "macOS", "app release", "notarization", "GitHub Release", and "Homebrew" are phrases users would naturally say. It falls short of anchor 5 because common variations such as "publish", "ship", "sign", "appcast", or a file extension like ".app" are missing, while covering more than the partial coverage of anchor 3.

4 / 5

Distinctiveness Conflict Risk

The combination of Sparkle appcast updates, Apple notarization, GitHub Releases, and Homebrew distribution is a clear niche with distinct triggers and minimal conflict risk with any other skill.

5 / 5

Total

16

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
steipete/agent-scripts
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.