| name | deploy |
| description | Deploy a merged PR or commit to an environment. TRIGGER when: chained by workflow-deploy or another skill; user explicitly invokes /deploy with a PR number, commit SHA, or ref. SKIP: interactive guided deployments (use workflow-deploy). |
Step 0 — Load configuration
Check if /tmp/ops-suite-session/config.json exists:
- If yes, read it (pre-parsed by session-start hook).
- If no, read
${XDG_CONFIG_HOME:-$HOME/.config}/ops-suite/config.yaml (preferred) or the plugin's config.yaml (legacy), parse it, and write to /tmp/ops-suite-session/config.json for other skills to reuse.
If neither exists, tell the user to run /ops-suite:configure (or copy config.example.yaml to ~/.config/ops-suite/config.yaml and fill in their values). Stop here.
Extract:
deploy.ci_provider — determines which adapter to load
deploy.image_tag_source — how to find the image tag (run-id, commit-sha, tag)
deploy.migration_tool — whether migrations need to run
environments — available environments
Also read the reference at references/commands.md (in this skill's directory) for the step-by-step process.
Step 1 — Load adapter
Read the adapter file at adapters/{deploy.ci_provider}.md (in this skill's directory).
If the adapter does not exist, tell the user that the CI provider {deploy.ci_provider} is not yet supported and stop.
Step 2 — Identify the change to deploy
If $ARGUMENTS contains a PR number:
- Use the adapter to check the PR state (must be merged)
- Extract the merge commit SHA
If $ARGUMENTS contains a commit SHA or branch ref:
- Verify it exists and is reachable from the main branch
If nothing is provided, ask the user for a PR number or ref.
Step 3 — Determine target environment
If $ARGUMENTS contains an environment name, use it.
Otherwise, list available environments from config and ask the user.
IMPORTANT: If the CI workflow auto-deploys to dev on merge (check the build run for a deploy-dev job),
inform the user that dev was already deployed automatically. Then:
- Ask the user to confirm dev is healthy before proceeding to prod.
- Do NOT deploy to prod until the user explicitly confirms dev is working.
- If the user asks to deploy directly to prod without verifying dev, warn them and ask for confirmation.
Never chain merge → prod deploy without explicit approval for each environment.
Step 4 — Find the build artifact
Using the adapter's commands and deploy.image_tag_source:
- run-id: Find the CI run associated with the merge commit, extract the run ID
- commit-sha: Use the merge commit SHA directly as the image tag
- tag: Find the latest git tag on the merge commit
Verify the build completed successfully before proceeding.
Step 5 — Check current state
Use the adapter to show:
- What is currently deployed in the target environment
- What will change (diff between current and new)
Step 6 — Confirm deployment
ALWAYS ask the user for explicit confirmation before deploying.
Display:
Ready to deploy:
Change: PR #{pr_number} — {pr_title}
Image tag: {image_tag}
Target: {environment}
Current tag: {current_tag}
Proceed? (yes/no)
Step 7 — Deploy
Use the adapter's deploy command to trigger the deployment.
Monitor the deployment progress using the adapter's status commands.
Step 8 — Post-deploy verification
After deployment completes, run the following read-only checks automatically:
-
Use ops-suite:service-status with arguments: {service} {env_name}.
Use session state from /tmp/ops-suite-session/ — do not re-ask for environment.
- If unhealthy → report immediately
-
Use ops-suite:service-logs with arguments: {service} {env_name}.
Check for errors in last 5 minutes.
- If errors found → report but continue
Step 9 — Report and suggest next steps
Deployment Summary:
PR: #{pr_number} — {pr_title}
Environment: {environment}
Image tag: {image_tag}
Status: {success/failed}
Duration: {time}
Post-deploy checks:
Service health: {ok/degraded}
Error check: {clean/errors found}
If deploy.migration_tool is not "none", add:
Next steps:
→ Run `/ops-suite:db-migrate {env_name}` to check and apply pending migrations.