Add release Skill and corresponding sub-skills together with the prepare script

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

@@ -0,0 +1,128 @@
+---
+name: release-finalize
+description: Tag, publish, and verify a merged substrate-relay release
+---
+
+# Release Finalize
+
+After a release PR has been merged, create the git tag, verify the Docker build, and create a GitHub Release.
+
+## Usage
+
+```
+/release-finalize
+```
+
+No arguments required. The skill reads the version from `substrate-relay/Cargo.toml` on the current branch.
+
+## Prerequisites
+
+- The release PR must be merged to `master`
+- You should be on (or able to switch to) the `master` branch with the merged changes
+
+## Procedure
+
+### Step 1: Verify State
+
+Ensure we're on `master` with the latest changes:
+
+```bash
+git checkout master
+git pull
+```
+
+Read the version:
+
+```bash
+grep '^version' substrate-relay/Cargo.toml
+```
+
+Check that the version doesn't already have a tag:
+
+```bash
+git tag -l "v<VERSION>"
+```
+
+If the tag already exists, inform the user and skip to Step 4.
+
+### Step 2: Create Annotated Tag
+
+**Ask user for confirmation before proceeding.**
+
+Show the user what will happen:
+- Tag: `v<VERSION>`
+- This will trigger the `build-tag.yml` workflow
+- Docker images will be pushed to Docker Hub
+
+Create the tag:
+
+```bash
+git tag -a v<VERSION> -m "Release v<VERSION>"
+```
+
+### Step 3: Push Tag
+
+**Ask user for confirmation before pushing.**
+
+```bash
+git push origin v<VERSION>
+```
+
+This triggers the `build-tag.yml` pipeline which builds and pushes:
+- `docker.io/paritytech/substrate-relay:v<VERSION>`
+- `docker.io/paritytech/bridges-common-relay:v<VERSION>`
+
+### Step 4: Wait for Docker Build
+
+Monitor the build-tag pipeline:
+
+```bash
+gh run list --workflow=build-tag.yml --limit=5
+```
+
+Wait for the run to complete. Check status periodically:
+
+```bash
+gh run watch <RUN_ID>
+```
+
+### Step 5: Create GitHub Release
+
+Collect bundled chain versions for the release notes:
+
+```bash
+grep 'spec_version' relay-clients/client-*/src/lib.rs
+```
+
+Create the release:
+
+```bash
+gh release create v<VERSION> --title "Release v<VERSION>" --notes "$(cat <<'EOF'
+Docker reference: `paritytech/substrate-relay:v<VERSION>`
+
+Bundled Chain Versions:
+
+- Rococo: `<spec_version>`
+- Westend: `<spec_version>`
+- Kusama: `<spec_version>`
+- Polkadot: `<spec_version>`
+- Rococo Bridge Hub: `<spec_version>`
+- Westend Bridge Hub: `<spec_version>`
+- Kusama Bridge Hub: `<spec_version>`
+- Polkadot Bridge Hub: `<spec_version>`
+- Rococo Bulletin: `None` (must be specified in CLI)
+- Polkadot Bulletin: `None` (must be specified in CLI)
+EOF
+)" --generate-notes
+```
+
+### Step 6: Post-Release
+
+Report completion:
+- Tag: `v<VERSION>`
+- 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

.claude/skills/release-pr/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: release-pr
+description: Create a release PR from prepared release changes
+---
+
+# Release PR
+
+Create a release pull request from changes prepared by `/release-prepare`.
+
+## Usage
+
+```
+/release-pr
+```
+
+No arguments required. The skill detects the release details from the current workspace changes.
+
+## Prerequisites
+
+- Changes from `/release-prepare` must be present in the working tree (not yet committed)
+- Working tree should be on a clean base (no unrelated uncommitted changes)
+
+## Procedure
+
+### Step 1: Detect Release Details
+
+Read the current state to determine what was changed:
+
+```bash
+git diff --name-only
+```
+
+From the diff, identify:
+- Which chain was updated (check `relay-clients/client-bridge-hub-*/src/lib.rs` for spec_version changes)
+- The new relay version from `substrate-relay/Cargo.toml`
+- The new spec_version from the modified `lib.rs`
+
+If no release-related changes are detected, inform the user and suggest running `/release-prepare` first.
+
+### Step 2: Final Verification
+
+Run build and lint checks:
+
+```bash
+cargo check --workspace
+SKIP_WASM_BUILD=1 cargo clippy --all-targets --locked --workspace
+```
+
+If either fails, report the errors and stop. Do not create a PR with failing checks.
+
+### Step 3: Read All Bundled Chain Versions
+
+Collect spec_version from every relay-client for the PR body:
+
+```bash
+grep 'spec_version' relay-clients/client-*/src/lib.rs
+```
+
+### Step 4: Create Branch and Commit
+
+```bash
+git checkout -b release-v<RELAY_VERSION>
+git add relay-clients/ substrate-relay/Cargo.toml Cargo.lock
+git commit -m "Release v<RELAY_VERSION>"
+```
+
+Use the actual relay version read from `substrate-relay/Cargo.toml`.
+
+### Step 5: Push and Create PR
+
+```bash
+git push -u origin release-v<RELAY_VERSION>
+```
+
+Create the PR with the `A-release` label:
+
+```bash
+gh pr create --title "Release v<RELAY_VERSION>" --label "A-release" --body "$(cat <<'EOF'
+## Summary
+- Bump substrate-relay version to <RELAY_VERSION>
+- Update <CHAIN_NAME> spec_version: <OLD> → <NEW>
+- Regenerate runtime codegen
+
+## Bundled Chain Versions
+<table of all chain spec_versions>
+
+Docker reference: `paritytech/substrate-relay:v<RELAY_VERSION>`
+
+## Test plan
+- [ ] CI passes (fmt, clippy, check, test, deny)
+- [ ] Verify spec_version matches on-chain runtime
+- [ ] Verify codegen_runtime.rs regenerated correctly
+EOF
+)"
+```
+
+### Step 6: Report
+
+Output:
+- PR URL
+- Summary of changes included
+- Remind: "After PR is merged, run `/release-finalize` to tag and publish"

.claude/skills/release-prepare/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: release-prepare
+description: Prepare a BridgeHub runtime upgrade for substrate-relay
+argument-hint: "<BridgeHubKusama|BridgeHubPolkadot> <runtime-version>"
+---
+
+# Release Prepare
+
+Prepare the workspace for a BridgeHub runtime upgrade by running the automated script and verifying the result.
+
+## Usage
+
+```
+/release-prepare BridgeHubKusama v1.1.6
+/release-prepare BridgeHubPolkadot v1.4.1
+```
+
+`$ARGUMENTS` must contain two values: the chain name and the Fellows runtimes release version (vX.Y.Z).
+
+## Procedure
+
+### Step 1: Validate Arguments
+
+Parse `$ARGUMENTS` into `CHAIN` (first word) and `VERSION` (second word).
+
+Valid chains: `BridgeHubKusama`, `BridgeHubPolkadot`.
+Version must match `vX.Y.Z`.
+
+If arguments are missing or invalid, explain the usage and ask the user.
+
+### Step 2: Record Current State
+
+Before making changes, read the current values for comparison:
+
+```bash
+grep 'spec_version' relay-clients/client-bridge-hub-kusama/src/lib.rs
+grep 'spec_version' relay-clients/client-bridge-hub-polkadot/src/lib.rs
+grep '^version' substrate-relay/Cargo.toml
+```
+
+### Step 3: Run the Release Script
+
+Execute the preparation script:
+
+```bash
+./scripts/prepare-bridge-hub-release.sh $CHAIN $VERSION
+```
+
+This script will:
+1. Download the WASM runtime from polkadot-fellows/runtimes
+2. Update `spec_version` in the relay-client `lib.rs`
+3. Regenerate `codegen_runtime.rs` using runtime-codegen
+4. Apply the BlakeTwo256 workaround and format
+5. Bump the substrate-relay patch version
+
+If the script fails, report the error and suggest remediation.
+
+### Step 4: Verify Build
+
+Run workspace checks to confirm the changes compile:
+
+```bash
+cargo check --workspace
+```
+
+If it fails, inspect the errors. Common issues:
+- Missing type imports in codegen (BlakeTwo256 fix may need adjustment)
+- Version mismatch between runtime and expected types
+
+### Step 5: Report Results
+
+Summarize the changes:
+
+- **Chain**: which chain was updated
+- **Spec version**: old → new
+- **Relay version**: old → new
+- **Files modified**: list from git diff
+- **Build status**: pass/fail
+
+Suggest next step: run `/release-pr` to create the release PR.

.claude/skills/release/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: release
+description: Guide the substrate-relay release lifecycle
+argument-hint: "[BridgeHubKusama|BridgeHubPolkadot] [runtime-version]"
+---
+
+# substrate-relay Release
+
+Orchestrate the full release lifecycle for substrate-relay. This skill chains the sub-skills `/release-prepare`, `/release-pr`, and `/release-finalize` into a single flow.
+
+Reference `RELEASE.md` for upstream documentation.
+
+## Usage
+
+```
+/release                                    # Interactive: detect or ask which chain
+/release BridgeHubKusama v1.1.6            # Direct: specify chain and runtime version
+```
+
+If `$ARGUMENTS` contains a chain name and version, pass them through. Otherwise, detect the need or ask the user.
+
+## Procedure
+
+### Step 1: Verify Release Need
+
+Determine why a release is needed:
+
+1. Check if version guard alerts are firing (suggests chain runtime upgrade):
+   - Look for `"Aborting relay"` in recent logs
+2. Check recent commits for chain version bumps: `git log --oneline -20`
+3. Check if any relay-client `SimpleRuntimeVersion` constants are outdated
+
+If `$ARGUMENTS` provides a chain and version, skip detection and proceed to Step 2.
+
+If no arguments and no clear signal, ask the user which chain needs updating and what Fellows runtime version to use. Valid chains: `BridgeHubKusama`, `BridgeHubPolkadot`.
+
+### Step 2: Prepare Release
+
+Run the `/release-prepare` skill logic:
+
+1. Execute `./scripts/prepare-bridge-hub-release.sh <CHAIN> <VERSION>`
+2. Run `cargo check --workspace` to verify
+3. Report: old spec_version → new spec_version, old relay version → new relay version
+
+If this step fails, report errors and stop.
+
+### Step 3: Create Release PR
+
+Run the `/release-pr` skill logic:
+
+1. Run final checks (`cargo check`, `cargo clippy`)
+2. Create branch `release-v<RELAY_VERSION>`
+3. Stage relevant files, commit, push
+4. Create PR with `A-release` label via `gh pr create`
+5. Output the PR URL
+
+### Step 4: Wait for Merge
+
+Print:
+> PR created. After the PR is reviewed and merged, run `/release-finalize` to tag, publish the Docker image, and create a GitHub Release.
+
+Stop here. The remaining steps happen after merge via `/release-finalize`.
+
+### Step 5: Post-Merge (via /release-finalize)
+
+After merge, `/release-finalize` handles:
+- Creating annotated git tag `v<VERSION>` (with user confirmation)
+- Pushing tag to trigger `build-tag.yml`
+- Waiting for Docker build to complete
+- Creating GitHub Release with bundled chain versions
+
+### Step 6: Deploy via ArgoCD
+
+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`
+
+### Step 7: Post-Deploy Verification
+
+After deployment, run `/check-health all` to verify:
+- Finality sync resumes
+- Message delivery resumes
+- Version guard alerts clear
+- Relay balances stable