Run the normal guarded ship flow, then monitor beta deployments, the docs production lane, release tails, and any explicitly requested manual production promotion. Use when standard `/ship` needs post-merge verification.
Scanned 9/3/2026
Install to Claude Code
npx -y skills add BuilderIO/agent-native --skill ship-and-monitor --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Ship And Monitor?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/builderio-ship-and-monitor)More formats (shields.io, HTML) on the badges page.
---
name: ship-and-monitor
description: >-
Run the normal guarded ship flow, then monitor beta deployments, the docs
production lane, release tails, and any explicitly requested manual
production promotion. Use when standard `/ship` needs post-merge verification.
user-invocable: true
scope: dev
metadata:
internal: true
---
# Ship and Monitor
Use the normal `/ship` workflow, then add the post-merge monitoring described
below. Read `.agents/skills/ship/SKILL.md` and follow every step through
`/new-branch`; `/ship` intentionally ends after merge and branch rotation.
## Deployment split
Merges to `main` trigger `.github/workflows/deploy-beta-sites-prebuilt.yml`,
which builds in GitHub Actions and uploads prebuilt artifacts to the independent
Netlify beta sites at `beta.*.agent-native.com`. Netlify Git-connected
auto-builds are disabled, so do not wait for Netlify build queues or
deploy-preview checks; verify the Actions run and its per-site smoke checks.
Production promotion is manual. A healthy beta deploy is not proof that
production changed, and a production deploy is not expected unless an explicit
manual promotion was started for the task. The public docs site is the
temporary exception: matching `main` changes trigger
`.github/workflows/deploy-docs-production.yml`, which publishes
`www.agent-native.com` directly and then disables its Git-connected Netlify
builds. There is no beta docs site today.
Use `.github/workflows/deploy-production-sites-prebuilt.yml` or the targeted
`promote-netlify-deploy.yml` workflow to promote a critical fix and let it
manage Netlify lock transitions. Do not manually remove or clear a Netlify lock
as a deployment step; clearing one is not the production promotion.
## Post-merge monitoring
After `/new-branch`:
1. Confirm the merged PR and merge commit are present in `origin/main`.
2. Check every workflow attached to that commit, the beta deployment status,
and package publication when applicable. Wait for publication and use an
independent beta URL smoke check when the affected surface is observable.
3. If the task changed docs, verify the docs production workflow and
`www.agent-native.com` separately. If the task explicitly included manual
promotion of another production site, verify that promotion and its URL
separately. Otherwise report those other production sites as intentionally
not promoted, not as blocked by Netlify.
4. Re-read the merged PR for new review or bot feedback. If actionable
post-merge feedback or a release/deploy failure appears, fix it on the fresh
branch, run the smallest meaningful check, and invoke `/ship` for the
follow-up.
Keep configured, source-tested, built-runtime, beta-deployed, production-
promoted, and observed-live claims separate. A merge or green test is not live
proof.
## Related skills
- `/ship` for the normal guarded flow without post-merge monitoring.
- `/ship-now` for the fast admin-merge path, which already includes monitoring.
- `/new-branch` for the required branch rotation after merge.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!