Add /deploy and /rollback skills#3219
Conversation
Close the release-to-deploy loop by adding skills that trigger and monitor the deploy.yml workflow via `gh workflow run`, replacing the manual "go click the button" instructions in /release and /release-finalize. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
Are those needed? Are those correct rollback and deploy skills? We handle deploy as part of the release skill but we do not have |
|
(TL;DR - please don't do this before resolving my worries !! giving an AI deploy/rollback access is incredibly risky) I'm highly concerned by a lack of human in the loop here - what does an autonomous "/deploy" or "/rollback" actually mean in practice? Let me check I understand: Claude reads local code/logs/PRs -> decides to use a deployment tool -> executes infrastructure changes What prevents a prompt injection from a poisoned dependency or malicious PR description? - an attacker could hide instructions telling the agent to trigger an unauthorised deployment or teardown. How do you know Claude is going to do what you expect it to do, like deploying the correct branch to the correct environment? (its non deterministic) What are the accesses for the cloud/deployment credentials used - how are they isolated from the agent so they can't be stolen if the agent's context window is compromised? Are these skills going to be wired into automated CI, or strictly run locally by engineers? |
2 participants
Summary
/deploy [version]— trigger and monitor ArgoCD deployment viagh workflow run deploy.yml/rollback [version]— roll back to a previous version with commit diff visibilityUpdates
/releaseand/release-finalizeto reference/deployinstead of manual workflow instructions.Depends on #3218.
Test plan
gh workflow run deploy.yml --ref v<VERSION>syntax matches deploy.yml (github.ref_name)/release-finalize→/deploy→/check-health