app-deploy

name	app-deploy
description	Start (or mark the start of) an application deploy and begin live status tracking. Invoke this whenever a deployment is kicked off so the deploy-watch monitor begins signaling in the background when the deploy completes or fails. Use for "deploy the app", "ship it", "watch this deploy"; prefer deploy-watch-setup first when a project uses internal/custom deploy commands or package scripts that provider auto-detect cannot classify exactly.
hooks	{"PreToolUse":[{"matcher":"Bash","hooks":[{"type":"command","command":"\"${CLAUDE_PLUGIN_ROOT}\"/skills/app-deploy/scripts/confirm-deploy.sh"}]}]}

app-deploy

Invoking this skill starts the plugin's deploy-watch monitor through on-skill-invoke:app-deploy. The monitor auto-detects the current deployment and reports in the background when the deploy reaches a terminal state. You do not poll it; it pushes notifications. Detection precedence:

1. A committed .claude/deploy-status.sh (created by the deploy-watch-setup skill) - preferred; it emits a single canonical status line, so classification is exact. Run that skill once to scope tracking to a project's own (often internal) deploy tooling.
2. A command set via the deploy_status_command option.
3. Provider auto-detection: GitHub Actions on the current branch, Fly, or Vercel.

Agent decision path

1. Check whether tracking is scoped. If .claude/deploy-status.sh exists, use it. If the repo appears to deploy through internal tooling, package scripts, Make/Just targets, Kubernetes/Helm wrappers, or a custom CLI, run deploy-watch-setup first unless the user explicitly wants best-effort provider tracking for this session.
2. Find the deploy entrypoint before acting. Inspect local signals such as package.json scripts, pyproject.toml, Makefile, justfile, CI workflows, Docker/k8s/Helm files, and documented internal packages. Do not invent a deploy command from provider markers alone.
3. Separate starting from watching. If the deploy already started, do not run it again; invoke this skill to mark/watch it. If it has not started, confirm the exact command, target environment, and required env vars before running anything that ships code.

When this skill runs:

1. Kick off the deploy if it has not started. Use the project's real deploy command (for example gh workflow run, flyctl deploy, vercel deploy, or whatever the user names). Confirm with the user before running anything that ships code - do not deploy unprompted.
2. Confirm tracking is live. Tell the user which source is being watched (scoped script, configured command, or provider fallback) and that the monitor will surface a "Deploy COMPLETED" or "Deploy FAILED" notification automatically.
3. React to the monitor, do not re-poll. When deploy-watch reports completion, continue the workflow (smoke tests, announce success). When it reports failure, dispatch the deploy-investigator subagent with the notification text; it pulls the failing run's logs read-only and reports the evidence.

Notes:

• While this skill is active, a frontmatter PreToolUse hook (scripts/confirm-deploy.sh) forces a permission prompt on commands that ship code - the confirm-before-deploy rule is enforced by the harness, not just by this text.
• The monitor starts on the first /app-deploy of a session and then stays running, so it covers later deploys too — invoking the skill again does not spawn a second watcher.
• "Done" detection follows the deploy_detect_mode option: keyword matching on the status command's output (default) or the command's exit code, which suits blocking commands like kubectl rollout status or gh run watch.
• Provider fallbacks are useful demos, but project-scoped status is the reliable path for internal deploy systems and multi-service repositories.