warp-key-value-expansion
Skill76 starsChanged 20 days agoApache-2.0View on GitHub
/warp-deploy-select-keys writes a per-ticket key-context artifact (~/.hyperlane/key-contexts/<ticket-id>.yaml) with, per protocol, a keys.<protocol>.name, keys.<protocol>.source, and derived keys.<protocol>.address. Every downstream skill that runs a signing CLI command references a key as a <KEY<PROTOCOL>VALUE> placeholder and must expand it the same way — this skill is the single source of that mapping so the copies can't drift. Substitute <KEY<PROTOCOL>VALUE> (e.g. <KEYETHEREUMVALUE>, <KEYSEALEVELVALUE>) per the artifact's source field for that protocol: Always invoke the CLI via pnpm --silent … for any command that takes…
Files
Warp Key-Value Expansion
/warp-deploy-select-keys writes a per-ticket key-context artifact (~/.hyperlane/key-contexts/<ticket-id>.yaml) with, per protocol, a keys.<protocol>.name, keys.<protocol>.source, and derived keys.<protocol>.address. Every downstream skill that runs a signing CLI command references a key as a <KEY_<PROTOCOL>_VALUE> placeholder and must expand it the same way — this skill is the single source of that mapping so the copies can't drift.
Expansion legend
Substitute <KEY_<PROTOCOL>_VALUE> (e.g. <KEY_ETHEREUM_VALUE>, <KEY_SEALEVEL_VALUE>) per the artifact's source field for that protocol:
source field | Expansion of <KEY_VALUE> | Notes |
gcp-secret | "$(gcloud secrets versions access latest --secret=<name>)" | The raw private key is consumed inline by the CLI process and never lives in conversation logs or shell history. |
env-var | "$<name>" | The env var must be exported in the shell session before running the command. |
keystore | "$(cat <path>)" for a plaintext-key file. For an encrypted keystore, halt with a clear error and ask the user to supply an env-var / gcp-secret form or the derived private key directly. | Encrypted-keystore unlocking is not yet plumbed through the warp-deploy chain (Phase 2 wiring). |
pnpm --silent is mandatory for any --key.<protocol> command
Always invoke the CLI via pnpm --silent … for any command that takes a --key.<protocol> flag. Without --silent, pnpm prints an execution banner of the form $ node ./dist/cli.js <cmd> … --key.ethereum 0x<rawkey> after shell substitution — that banner echoes the resolved argv (including the raw key) into stdout, defeating the gcloud secrets versions access / cat substitution that is supposed to keep the raw key out of logs. --silent suppresses the banner entirely. This is non-negotiable for sign commands; the leak applies to every --key.<protocol> flag in the warp-deploy/update chain.
Disclose the key at every [CONFIRM:] gate
Before any [CONFIRM:] gate that precedes a signing command, display the resolved secret NAME (or env-var name) and the corresponding derived address from the artifact. The human approving the gate must see both — which key was picked, and which signer that key produces. That disclosure is the safeguard against wrong-key foot-guns; never show the raw key value itself.
Consumers
/warp-deploy-select-keys (its own address-derivation commands), /warp-deploy-validate-owners, /warp-deploy-init-route, /warp-deploy-update-owners, /warp-update, /warp-update-extend — every skill that expands a --key.<protocol> flag.
In this repository49 other files it gives its agents.
- AGENTS.mdAGENTS.md
- add-registry-changesetSkill
- build-docker-imageSkill
- classify-onchain-ownerSkill
- code-reviewSkill
- debug-messageSkill
- debug-rpc-providerSkill
- debug-validator-checkpoint-inconsistencySkill
- denylist-stuck-messagesSkill
- fetch-linear-ticketSkill
- fetch-safe-tx-batchSkill
- find-docker-imageSkill
- fix-merkle-root-mismatchSkill
- fix-rpc-urlsSkill
- gcp-logsSkill
- hyperlane-message-utilsSkill
- hyperlane-utilsSkill
- inline-pr-commentsSkill
- investigate-merkle-root-mismatchSkill
- investigate-stuck-messagesSkill
- registry-yaml-sort-policySkill
- security-reviewSkill
- self-relay-hyperlane-messageSkill
- set-moonpay-standing-quotesSkill
- start-http-registrySkill
- stop-http-registrySkill
- svm-warp-alt-manageSkill
- svm-warp-program-upgradeSkill
- tob-reviewSkill
- verify-warp-contractsSkill
- warp-balancesSkill
- warp-deploy-fund-deployerSkill
- warp-deploy-init-routeSkill
- warp-deploy-nexusSkill
- warp-deploy-register-routeSkill
- warp-deploy-select-keysSkill
- warp-deploy-send-testSkill
- warp-deploy-update-ownersSkill
- warp-deploy-validate-ownersSkill
- warp-forkSkill
- warp-manage-offchain-quotesSkill
- warp-route-checkSkill
- warp-run-logSkill
- warp-simulate-svm-txsSkill
- warp-update-extendSkill
- warp-update-proposeSkill
- warp-update-resolve-artifactsSkill
- warp-updateSkill
- warp-verify-onchain-configSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

