Redshift
Security checks across static analysis, malware telemetry, and agentic risk
Overview
This is a coherent Redshift CLI guide for managing secrets, with sensitive secret and key handling clearly tied to its stated purpose.
This skill is appropriate if you want an agent to help with Redshift secret-management commands. Before installing, make sure you trust the Redshift CLI binary, keep Nostr credentials in a secure secret store, and require confirmation before showing raw secrets, writing secret files, deleting secrets, or running commands with injected secrets.
Static analysis
No static analysis findings were reported for this release.
VirusTotal
64/64 vendors flagged this skill as clean.
Risk analysis
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If used on the wrong project or command, the agent could expose, overwrite, or delete application secrets.
The documented commands can mutate or delete secrets and inject secrets into processes. This is central to the skill's purpose, and the file includes user-control guidance, but the operations are high impact.
redshift secrets set API_KEY sk_live_xxx ... redshift secrets delete KEY1 KEY2 -y ... redshift run -- npm start
Confirm the project, environment, secret names, and any command to be run before allowing the agent to execute Redshift operations.
Anyone or any agent with access to these credentials may be able to access or change the associated secrets.
The skill handles Nostr private-key or bunker credentials for authentication. This is expected for Redshift, but those credentials can authorize access to managed secrets.
redshift login --nsec nsec1... ... CI/CD: set REDSHIFT_NSEC or REDSHIFT_BUNKER env vars instead of redshift login.
Use dedicated scoped credentials where possible, store them only in approved secret stores, and avoid passing private keys directly on the command line.
Secret metadata or encrypted secret payloads may be handled by configured relays, so relay choice and key protection matter.
The skill discloses that secret data is stored through external Nostr relays, with client-side encryption. This is purpose-aligned but is still a sensitive external data flow.
Secrets are client-side encrypted ... and stored on Nostr relays — no central server.
Use trusted relay configuration, protect the encryption/authentication keys, and avoid exposing plaintext via raw output, files, logs, or clipboard unless necessary.
A compromised or untrusted CLI binary could access or alter secrets.
The skill depends on an external redshift CLI binary. There is no bundled installer or automatic execution shown, but users should verify the binary because it will handle secrets.
"requires": { "bins": ["redshift"] } ... "installHint": "Install from https://redshiftapp.com or build from source: https://github.com/accolver/redshift"Install Redshift only from trusted sources, verify the project and release provenance where possible, and keep the CLI updated.