Add /deploy and /rollback skills

.claude/skills/deploy/skill.md

@@ -0,0 +1,109 @@
+---
+name: deploy
+description: Deploy substrate-relay to production via ArgoCD
+metadata:
+  argument-hint: "[version]"
+---
+
+# Deploy
+
+Deploy a substrate-relay version to production via the ArgoCD deploy workflow.
+
+## Usage
+
+```
+/deploy              # Auto-detect version from Cargo.toml or latest git tag
+/deploy v1.8.16      # Deploy a specific version
+```
+
+## Prerequisites
+
+- The version must have a corresponding git tag (created by `/release-finalize`)
+- The Docker image `paritytech/substrate-relay:v<VERSION>` must exist on Docker Hub
+- The `gh` CLI must be authenticated with permission to trigger workflows
+
+## Procedure
+
+### Step 1: Determine Version
+
+If `$ARGUMENTS` contains a version (e.g. `v1.8.16`), use it. Strip the `v` prefix for comparisons if needed.
+
+Otherwise, auto-detect:
+
+```bash
+grep '^version' substrate-relay/Cargo.toml
+```
+
+Or use the latest git tag:
+
+```bash
+git tag -l 'v*' --sort=-v:refname | head -1
+```
+
+Confirm the resolved version with the user.
+
+### Step 2: Verify Docker Image Exists
+
+Check Docker Hub for the image:
+
+```bash
+curl --fail --silent "https://hub.docker.com/v2/repositories/paritytech/substrate-relay/tags/v<VERSION>" | head -c 200
+```
+
+If the image does not exist, abort and suggest:
+- If the tag exists but the image doesn't: check the `build-tag.yml` workflow status
+- If the tag doesn't exist: run `/release-finalize` first
+
+### Step 3: Show Deployment Plan
+
+Show the user what will happen:
+
+- **Version**: `v<VERSION>`
+- **Docker image**: `paritytech/substrate-relay:v<VERSION>`
+- **Environment**: `parity-chains` (production)
+- **ArgoCD app**: `bridges-common-relay`
+- **Packages**: `headers-a`, `headers-b`, `parachains-a`, `parachains-b`, `messages-a`, `messages-b`
+
+Check what is currently deployed (last successful deploy run):
+
+```bash
+gh run list --workflow=deploy.yml --status=success --limit=3
+```
+
+**Ask user for confirmation before proceeding.** This is a production deployment.
+
+### Step 4: Trigger Deploy Workflow
+
+The deploy.yml workflow uses `github.ref_name` as the version, so trigger it with the correct ref:
+
+```bash
+gh workflow run deploy.yml --ref v<VERSION>
+```
+
+### Step 5: Monitor Deployment
+
+Find and watch the triggered run:
+
+```bash
+gh run list --workflow=deploy.yml --limit=3
+```
+
+Then monitor it:
+
+```bash
+gh run watch <RUN_ID>
+```
+
+If the run fails:
+- Check the logs: `gh run view <RUN_ID> --log-failed`
+- Common failures: Docker image not found, ArgoCD auth issues, environment approval pending
+- Report the failure and suggest next steps
+
+### Step 6: Post-Deploy
+
+After the workflow succeeds, report:
+- Deploy workflow run URL
+- Version deployed: `v<VERSION>`
+- Environment: `parity-chains`
+
+Suggest next step: run `/check-health all` to verify relay health after deployment.

.claude/skills/release-finalize/skill.md

@@ -125,6 +125,4 @@ Report completion:
 - Docker image: `paritytech/substrate-relay:v<VERSION>`
 - GitHub Release URL
 
-Suggest next steps:
-1. Deploy via ArgoCD: go to [deploy.yml](https://github.com/paritytech/parity-bridges-common/actions/workflows/deploy.yml) and run workflow with the new version tag
-2. After deployment: run `/check-health all` to verify relay health
+Suggest next step: run `/deploy v<VERSION>` to deploy to production via ArgoCD.

.claude/skills/release/skill.md

@@ -70,13 +70,9 @@ After merge, `/release-finalize` handles:
 - Waiting for Docker build to complete
 - Creating GitHub Release with bundled chain versions
 
-### Step 6: Deploy via ArgoCD
+### Step 6: Deploy
 
-After `/release-finalize` completes:
-
-1. Go to [deploy.yml](https://github.com/paritytech/parity-bridges-common/actions/workflows/deploy.yml)
-2. Run workflow with the new version tag
-3. This deploys to ArgoCD app `bridges-common-relay` with packages: `headers-a`, `headers-b`, `parachains-a`, `parachains-b`, `messages-a`, `messages-b`
+After `/release-finalize` completes, run `/deploy v<VERSION>` to deploy to production via ArgoCD.
 
 ### Step 7: Post-Deploy Verification
 

.claude/skills/rollback/skill.md

@@ -0,0 +1,105 @@
+---
+name: rollback
+description: Roll back substrate-relay to a previous version
+metadata:
+  argument-hint: "[version]"
+---
+
+# Rollback
+
+Roll back the production substrate-relay deployment to a previous version.
+
+## Usage
+
+```
+/rollback              # Interactive: list recent tags and ask which to roll back to
+/rollback v1.8.15      # Roll back to a specific version
+```
+
+## Prerequisites
+
+- The target version must have a Docker image on Docker Hub
+- The `gh` CLI must be authenticated with permission to trigger workflows
+
+## Procedure
+
+### Step 1: Determine Target Version
+
+If `$ARGUMENTS` contains a version (e.g. `v1.8.15`), use it.
+
+Otherwise, list recent tags and ask the user to pick:
+
+```bash
+git tag -l 'v*' --sort=-v:refname | head -10
+```
+
+Also identify what is currently deployed:
+
+```bash
+gh run list --workflow=deploy.yml --status=success --limit=5
+```
+
+Present the user with the recent versions and ask which one to roll back to.
+
+### Step 2: Verify Docker Image Exists
+
+Check Docker Hub for the target version's image:
+
+```bash
+curl --fail --silent "https://hub.docker.com/v2/repositories/paritytech/substrate-relay/tags/v<TARGET_VERSION>" | head -c 200
+```
+
+If the image does not exist, abort and explain that this version cannot be deployed.
+
+### Step 3: Show Rollback Plan
+
+Show what will change:
+
+- **Current version** (from last successful deploy): `v<CURRENT>`
+- **Rollback target**: `v<TARGET_VERSION>`
+- **Docker image**: `paritytech/substrate-relay:v<TARGET_VERSION>`
+- **Environment**: `parity-chains` (production)
+- **ArgoCD app**: `bridges-common-relay`
+
+Show the commits between the two versions so the user understands what is being rolled back:
+
+```bash
+git log --oneline v<TARGET_VERSION>..v<CURRENT>
+```
+
+**Ask user for confirmation before proceeding.** This is a production rollback.
+
+### Step 4: Trigger Deploy Workflow
+
+Use the same deploy workflow with the older version tag:
+
+```bash
+gh workflow run deploy.yml --ref v<TARGET_VERSION>
+```
+
+### Step 5: Monitor Rollback
+
+Find and watch the triggered run:
+
+```bash
+gh run list --workflow=deploy.yml --limit=3
+```
+
+Then monitor it:
+
+```bash
+gh run watch <RUN_ID>
+```
+
+If the run fails:
+- Check the logs: `gh run view <RUN_ID> --log-failed`
+- Report the failure and suggest next steps
+
+### Step 6: Post-Rollback Verification
+
+After the workflow succeeds, report:
+- Deploy workflow run URL
+- Rolled back from `v<CURRENT>` to `v<TARGET_VERSION>`
+- Environment: `parity-chains`
+
+Suggest next step: run `/check-health all` to verify relay health after rollback.