Run any Skill in Manus with one click

Get Started

release

Stars564

Forks55

UpdatedJuly 12, 2026 at 03:44

Build, sign, notarize, and publish a Prowl release.

Installation

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.

Run Skill in Manus

Source

onevcat

onevcat/Prowl

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	release
description	Build, sign, notarize, and publish a Prowl release.

Release

Build, sign, notarize, and publish a Prowl release.

Verify current branch is main: git branch --show-current
- If not on main, abort and tell the user to switch first
Verify working tree is clean: git status --porcelain
- If dirty, list the changes and ask whether to proceed or abort
Sync the docs to the code being released — before the version bump and tag:
- Run the sync-docs skill. It diffs docs/.sync-meta.json's last_synced_commit against the current main HEAD (the code about to ship), updates any docs whose implementation changed, and sets last_synced_commit to the current HEAD — the exact commit being released, recorded before the bump/tag.
- Commit the result as its own commit (only docs/**, which includes docs/.sync-meta.json; never git add .): e.g. git commit -m "Sync docs for <VERSION>". This is required: release.sh aborts on a dirty tree, and the doc commit must land on main now so it is an ancestor of the tag and ships inside the release.
- Ordering is load-bearing: docs first, then bump + tag. Never tag first. The baseline points at the released code (the pre-doc-commit HEAD), not at the later doc/bump/CHANGELOG commits — that is correct and intentional (those commits touch no implementation files, so the next sync starts from a tight, accurate diff range).
- If sync-docs reports "needs human decision" items, resolve or defer them before continuing.
- Most releases change little or no implementation, so this step is usually a no-op doc-wise (just a baseline bump). Keep it cheap — see the sync-docs skill's cost notes.
Determine the version:
- If $ARGUMENTS is provided, use it as the version (e.g., 2026.3.18)
- Otherwise, default to today's date format and confirm with the user before proceeding
Generate release notes: ./scripts/release-notes.sh <VERSION>
- This script compares HEAD against the previous release tag, gathers commits and PR descriptions, and generates user-facing notes via LLM into build/release-notes.md.
- Read the generated build/release-notes.md, show the content to the user, and wait for explicit confirmation. If the user wants changes, edit the file directly.
- Do NOT proceed to the next step until the user confirms the release notes.
Run the release script: ./scripts/release.sh <VERSION>
- The script reads build/release-notes.md (required — refuses to run without it).
- It handles: version bump, build, sign, notarize, DMG, appcast, GitHub Release, and Prowl-Site update. If the tag already exists (e.g., from a prior interrupted run), it skips the bump step automatically.
Report the GitHub release URL and remind the user to verify:
- The DMG downloads and installs correctly
- Sparkle update check works (launch app → Check for Updates)

More from this repository

same repository

prowl-cli

onevcat/Prowl

Use the Prowl CLI (`prowl`) to inspect or control a running Prowl GUI app and the agent sessions it hosts. Prowl runs several coding agents in parallel, each in its own pane/tab/worktree, so reach for this whenever the user wants to act on a pane other than the current one — check on, coordinate, read from, focus, send text or keys to, open, or close another pane, tab, worktree, split, window, or sibling/neighboring agent. Covers colloquial framings that never say "prowl": "check what the agent in my other window is doing", "are any of my agents running side by side still working or idle?", "tell the agent in my left split to rerun the tests", "send npm run build to the build tab and grab the output", "open ~/proj in a fresh tab", "close that scratch tab I left open". Not for ordinary editing or building inside the Prowl source repo, and not for how-to questions about Prowl's settings, preferences, or keybindings — only when the task is to actually drive panes in the live Prowl app.

2026-07-21564

write-ai-doc

onevcat/Prowl

Create and maintain curated docs-ai/ records for substantial features and non-trivial, decision-shaping fixes (numbered entries with 000-plan.md before implementation and 001-action.md after). Do not use for reviews, audits, routine investigations, working notes, or status reports unless onevcat explicitly asks for a docs-ai/ record.

2026-07-13564

check-upstream-changes

onevcat/Prowl

Check upstream (supabitapp/supacode) for new changes since the last reviewed baseline.

2026-07-12564

self-verify-prowl

onevcat/Prowl

Bootstrap-verify Prowl changes by launching a debug app with a dedicated PROWL_CLI_SOCKET and driving it from the current Prowl session. Use after implementing Prowl app, terminal, Active Agents, or CLI changes when Codex should validate behavior end-to-end in a separate Prowl instance, including opening worktrees, creating tabs, running commands or agent sessions, reading panes, and falling back to a single-window screenshot of the debug app when the prowl CLI is insufficient.

2026-06-26564

sync-docs

onevcat/Prowl

Keep the agent-facing manual under docs/ in sync with the implementation. Diff-driven from a committed commit baseline; makes conservative, minimal edits only where the code has actually changed user-facing behavior. Run on demand or as part of release prep.

2026-06-07564

Release

Build, sign, notarize, and publish a Prowl release.

Verify current branch is main: git branch --show-current

If not on main, abort and tell the user to switch first

Verify working tree is clean: git status --porcelain

If dirty, list the changes and ask whether to proceed or abort

Sync the docs to the code being released — before the version bump and tag:

Run the sync-docs skill. It diffs docs/.sync-meta.json's last_synced_commit against the current main HEAD (the code about to ship), updates any docs whose implementation changed, and sets last_synced_commit to the current HEAD — the exact commit being released, recorded before the bump/tag.
Commit the result as its own commit (only docs/**, which includes docs/.sync-meta.json; never git add .): e.g. git commit -m "Sync docs for <VERSION>". This is required: release.sh aborts on a dirty tree, and the doc commit must land on main now so it is an ancestor of the tag and ships inside the release.
Ordering is load-bearing: docs first, then bump + tag. Never tag first. The baseline points at the released code (the pre-doc-commit HEAD), not at the later doc/bump/CHANGELOG commits — that is correct and intentional (those commits touch no implementation files, so the next sync starts from a tight, accurate diff range).
If sync-docs reports "needs human decision" items, resolve or defer them before continuing.
Most releases change little or no implementation, so this step is usually a no-op doc-wise (just a baseline bump). Keep it cheap — see the sync-docs skill's cost notes.

Determine the version:

If $ARGUMENTS is provided, use it as the version (e.g., 2026.3.18)
Otherwise, default to today's date format and confirm with the user before proceeding

Generate release notes: ./scripts/release-notes.sh <VERSION>

This script compares HEAD against the previous release tag, gathers commits and PR descriptions, and generates user-facing notes via LLM into build/release-notes.md.
Read the generated build/release-notes.md, show the content to the user, and wait for explicit confirmation. If the user wants changes, edit the file directly.
Do NOT proceed to the next step until the user confirms the release notes.

Run the release script: ./scripts/release.sh <VERSION>

The script reads build/release-notes.md (required — refuses to run without it).
It handles: version bump, build, sign, notarize, DMG, appcast, GitHub Release, and Prowl-Site update. If the tag already exists (e.g., from a prior interrupted run), it skips the bump step automatically.

Report the GitHub release URL and remind the user to verify:

The DMG downloads and installs correctly
Sparkle update check works (launch app → Check for Updates)