ℹ
Purpose & Capability
Functionality (search markets, create Polymarket orders via Decker) matches the description and would legitimately require a key capable of signing transactions. However the SKILL.md references an OPENCLAW_SECRET used in Decker API calls even though the skill metadata declares no required env vars/credentials — this mismatch is unexplained.
!
Instruction Scope
Runtime instructions tell operators to export a MetaMask private key and place it into Decker settings, and to invoke a Decker API endpoint that embeds OPENCLAW_SECRET in a GET query string. These steps involve collecting and transmitting highly sensitive secrets and encourage insecure handling (secrets in URL), which extends beyond benign query/lookup behavior.
✓
Install Mechanism
Instruction-only skill with no install spec or downloaded code. Low installation risk because nothing is written or executed by the skill files themselves.
!
Credentials
Skill metadata declares no required env vars, yet SKILL.md uses DECKER_API_URL and expects OPENCLAW_SECRET to be supplied in the request. The requirement to extract a wallet private key is plausible for signing, but the skill does not document where or how secrets should be provided securely, nor does it declare the secret in the manifest — this is disproportionate and under-specified.
✓
Persistence & Privilege
always:false and no install-time persistence requested. The skill can be invoked by agents as normal, but that autonomous use combined with sensitive secret handling increases risk; the skill itself does not request elevated platform privileges.
What to consider before installing
This skill appears to implement Decker↔Polymarket trading but it has important inconsistencies and insecure guidance you should consider before installing:
- The SKILL.md references OPENCLAW_SECRET (sent in a GET URL) but the skill manifest lists no required credentials — ask the author to explicitly declare required secrets and explain how they are protected.
- The instructions tell users to export their MetaMask private key and put it into Decker settings. Exporting raw private keys is risky. Prefer integrations that use WalletConnect, a hosted signer with clear security controls, or hardware wallets; never paste private keys into third-party services unless you fully trust and have audited them.
- Embedding secrets in a GET query string leaks them to logs and intermediaries. Request that the developer switch to POST with secrets in request body or better: use authenticated headers and avoid including secrets in URLs.
- Verify Decker's trustworthiness and how it stores keys (encryption at rest, access controls, key usage audit logs). If possible, test with a separate wallet holding minimal funds first.
- Ask the publisher for: (1) explicit list of required env vars/credentials in the manifest, (2) explanation of how secrets are transmitted/stored, and (3) safer usage patterns (no secret-in-URL, recommend non-export signing flows).
Because of these unresolved issues, treat the skill with caution until the developer provides clarification and improves secret handling.
