Menu
Use this skill when preparing a Toastty app release build, including Ghostty artifact installation, signed DMG creation, and drafting release notes from the recorded release diff.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use this skill when publishing an existing Toastty release artifact to GitHub Releases, using already-authored release notes and tagging the recorded release commit.
Use this skill when building, launching, or validating a live Toastty dev/debug/test app instance with runtime isolation, instance.json targeting, local smoke automation, and local or remote GUI validation.
Use this skill when the user asks for /worktree-create or wants to spin the current Toastty thread into a new git worktree and Toastty workspace, optionally run explicit repo setup, persist a handoff or plan file, and launch a new agent session (codex by default) in the new workspace.
Use this skill when listing recent Toastty diagnostics submissions, fetching, saving, or analyzing a submitted Toastty diagnostics report by report ID, or summarizing a local diagnostics JSON file. It retrieves reports through the Toastty diagnostics Worker admin API, summarizes logs, automation audit calls, redaction state, socket health, and avoids exposing admin secrets or dumping full log bodies.
Use this skill when the user explicitly wants to design, generate, or refine a custom Toastty orchestrator skill for a specific workflow, including workflow-specific coordination across Toastty workspaces, panels, managed agents, artifacts, and cooperative workspace scoping.
Use this skill when selecting, running, or reporting Toastty verification after code, project, dependency, build, test, UI/runtime, menu, shortcut, automation, or agent-instruction changes. It chooses the right mix of remote smoke validation, remote xcodebuild tests, local helpers, live GUI checks, Computer Use, and the global qa subagent for deeper user-perspective QA.
| name | toastty-release |
| description | Use this skill when preparing a Toastty app release build, including Ghostty artifact installation, signed DMG creation, and drafting release notes from the recorded release diff. |
Use this workflow when the user asks to cut or prepare a Toastty release build artifact.
scripts/release/release.sh.Dependencies/GhosttyKit.Release.xcframeworkDependencies/GhosttyKit.Release.metadata.env
Confirm the metadata's GHOSTTY_SOURCE_REPO still exists and contains the
recorded GHOSTTY_COMMIT; release verification reads license material from
that exact source snapshot.Sources/App/Resources/ThirdPartyNotices.txt matches the pinned
production web-panel dependencies, recorded Ghostty commit, Sparkle pin, and
Toastty license. scripts/release/release.sh installs production web-panel
packages and runs scripts/release/generate-third-party-notices.mjs --check.
If the check is stale, regenerate and commit the notice file before retrying,
because the release script requires a clean Toastty checkout.sv exec -- scripts/remote/validate.sh --smoke-test smoke-uisv exec -- scripts/remote/test.sh --
Use ./scripts/automation/check.sh only when the user explicitly asks for a local gate, the remote path is unavailable, or you are intentionally validating local-only release workflow changes.scripts/release/release.sh with the requested TOASTTY_VERSION, TOASTTY_BUILD_NUMBER, and signing/notary secrets.artifacts/release/<version>-<build>/release-metadata.env, artifacts/release/<version>-<build>/ghostty-metadata.env, artifacts/release/<version>-<build>/sparkle-metadata.env, and artifacts/release/<version>-<build>/Toastty-<version>.dmg all exist and are non-empty, then read the metadata files.RELEASE_SOURCE_COMMIT is available in the local clone before inspecting history or writing notes..agents/skills/toastty-release/assets/release-notes-template.md as the starting structure for RELEASE_NOTES_PATH.artifacts/release/**/release-notes.md files, prioritizing the most recent releases, so the new notes follow Toastty's established house style.RELEASE_PREVIOUS_TAG to RELEASE_SOURCE_COMMIT.artifacts/release/<version>-<build>/release-notes.md at RELEASE_NOTES_PATH, grounded in the recorded metadata rather than the current HEAD.artifacts/release/<version>-<build>/release-notes.md if they want changes before publication.artifacts/release/<version>-<build>/artifacts/release/<version>-<build>/release-metadata.envartifacts/release/<version>-<build>/ghostty-metadata.envartifacts/release/<version>-<build>/sparkle-metadata.envartifacts/release/<version>-<build>/release-notes.mdartifacts/release/<version>-<build>/Toastty-<version>.dmg../toastty-publish/SKILL.md and follow that workflow.scripts/release/release.sh is the source of truth for build-time provenance.Dependencies/GhosttyKit.Release.metadata.envscripts/release/release.sh; prefer the remote smoke and test wrappers unless the user explicitly scopes the gate to a local run or the remote path is unavailable.HEAD.artifacts/release/<version>-<build>/release-metadata.envartifacts/release/<version>-<build>/ghostty-metadata.envartifacts/release/<version>-<build>/sparkle-metadata.envartifacts/release/<version>-<build>/release-notes.mdartifacts/release/<version>-<build>/Toastty-<version>.dmgartifacts/release/<version>-<build>/ intact between the build and publish phases.artifacts/release/<version>-<build>/ and use repo-relative paths for every generated artifact. Do not refer to artifact files by bare filename only, such as release-notes.md or Toastty-<version>.dmg.RELEASE_NOTES_PATH, convert it to the equivalent repo-relative path before presenting it to the user.Preferred install pattern:
GHOSTTY_XCFRAMEWORK_VARIANT=release \
GHOSTTY_BUILD_FLAGS="-Demit-macos-app=false -Demit-xcframework=true -Dxcframework-target=universal -Dsentry=false" \
GHOSTTY_XCFRAMEWORK_SOURCE=/path/to/GhosttyKit.xcframework \
./scripts/ghostty/install-local-xcframework.sh
When the source path is inside a Ghostty git checkout, the installer auto-detects the Ghostty commit and source cleanliness. If not, provide GHOSTTY_COMMIT and, if necessary, GHOSTTY_SOURCE_DIRTY=0.
{{placeholder}} tokens rather than copying them literally.artifacts/release/**/release-notes.md files, prioritizing the most recent releases, and mirror that structure and voice unless the user asks for a deliberate format change.release-metadata.env is the source of truth for:
RELEASE_SOURCE_COMMITRELEASE_PREVIOUS_TAGRELEASE_PREVIOUS_COMMITRELEASE_NOTES_PATHghostty-metadata.env or the mirrored Ghostty fields in release-metadata.env so the notes include the shipped Ghostty commit and build flags.# v<version>Release date: <Month D, YYYY>Toastty commit: \``Previous release: \`orPrevious release: First public release`## Highlights## Changes## Upgrade Notes## Embedded Ghostty## Highlights only when the release has multiple headline features or a broader product shift. For narrower releases, skip Highlights and go straight to Changes.## Changes bullets. Use short ### subsections inside Highlights only when a major release needs a little extra explanation, config context, or a short example.## Upgrade Notes for migration steps, changed shortcuts, config additions, shell-integration refreshes, or behavior caveats. If there is nothing actionable, explicitly say that no manual migration is required for the release.RELEASE_SOURCE_COMMIT.RELEASE_SOURCE_COMMIT is reachable in the local clone.RELEASE_NOTES_PATH, is non-empty, and has no leftover {{placeholder}} tokens.