Agent skill · mastra-ai
pr-snapshot-release
Guide a Mastra maintainer through publishing an npm snapshot from a pull request or a specified repository branch. Use when asked to release, publish, or create a PR snapshot, branch snapshot, canary package build, or branch-specific npm tag. Performs source and branch preflight checks, requires confirmation before the irreversible publish, dispatches the existing Publish to npm workflow, monitors it, and reports installable package tags.
What it needs
About 3k tokens when loaded.
What this skill does
PR Snapshot Release Publish a snapshot from a PR or a specified branch using .github/workflows/npm-publish.yml. Snapshot publishing is manual, works only for branches in mastra-ai/mastra, and publishes real immutable package versions to npm. 1. Resolve the source Accept a PR number or URL, an explicit branch, or both. If neither is supplied, try the PR for the current branch: When the user specifies a branch, publish that branch instead of assuming the PR head branch. If both are supplied and differ, call out the override clearly. When a PR is the source, stop if it is not open and record its headRefName, headRefOid, and head repository. A workflow dispatch can only target a ref in mastra-ai/mastra. If a PR head is in a fork, explain that it cannot be published directly, but allow the user to specify an existing branch in mastra-ai/mastra instead. Do not push contributor code to an upstream branch without explicit maintainer direction. 2. Verify the exact branch revision Resolve the selected branch to an exact SHA. For a PR branch, compare it with the inspected PR head SHA. For an explicitly specified branch, record the remote SHA as headsha: If it differs, refresh the source metadata and repeat the checks. Re-run this comparison immediately before dispatch. Never publish a stale or ambiguous revision. When a PR is available, inspect gh pr checks "$pr" and mention any known failing checks in the confirmation summary. Do not block snapshot publishing on pending or failing checks. Call out when the PR is a draft. 3. Choose a custom npm tag Always use a custom tag. If the user proactively supplied one, use it. Otherwise, derive a short, memorable lowercase kebab-case tag from the purpose of the PR or branch, such as agent-builder or memory-fix; do not ask the user to choose one. Tell the user which tag will be used. Avoid generic release tags such as latest, next, or alpha. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills mastra-ai/pr-snapshot-release