Varlock Secrets Guard Skill
Secure environment variable management for Claude sessions, ensuring secrets never leak into terminal output, logs, Git commits, or Claude's context.
The skill's core principle is minimal exposure: it forbids echo/cat .env/printenv, declines to modify secrets directly, and discloses data flow clearly, with MIT license and upstream Varlock attribution. Deducted for: unverified curl|sh install script without integrity checks, exec() integrations with 1Password/AWS expanding attack surface, no rollback/recovery guidance, and unverified publisher identity.
Happy path (varlock load/run) plus troubleshooting (command not found, schema validation failure) is covered with readable failure feedback. Deducted for: static documentation only — no tests, no CI evidence, no behavioral verification; output formats (masked glyphs) depend on upstream versions and may drift.
Triggers and scenarios (secrets, .env, API keys, credentials) are explicit, and refusal scenarios define non-fit boundaries. Deducted for: core dependency on varlock CLI and varlock.dev install script whose reachability from mainland China is unverified with no mirror alternative; no Chinese-language support noted.
Well-structured with progressive disclosure, troubleshooting, quick reference, integration notes, version 1.0.0, MIT license, and upstream credits. Deducted for: no changelog, no declared maintenance responsibility or update path, a future-dated 'last updated' stamp (2025-12-22), and references to local clerk/docker skills that are unverified assumptions.
If Varlock behaves as documented, the skill directly completes secure env-var management, with usable npm/CI/Docker integration patterns. Deducted for: static review cannot verify outputs; marginal value presupposes the user adopts Varlock; cost/benefit is not quantified.
Commands and annotations are auditable against upstream varlock.dev docs and README credits are clear. Deducted for: no tests, CI runs, or third-party execution evidence; all 'never exposed' guarantees are author claims without independent reproduction.
- Installation relies on curl | sh from a remote script; inspect the script or install Varlock via a package manager instead.
- Effectiveness depends entirely on actual Varlock CLI behavior, which was not executed; 'never exposed' is a design goal, not a proven guarantee.
- Reachability of varlock.dev and raw GitHub from mainland China is unverified; core function may be network-limited.
- The 'last updated' date is future-dated relative to typical review time and there is no changelog — weak version governance.
- Integration references to local clerk/docker skills are assumptions; those files may not exist in the user's environment.
What does this skill do, and when should you use it?
An open-source (MIT) Claude Code skill that wraps the Varlock tool to enforce secure secret-handling patterns. It defines explicit rules blocking risky behaviors like echoing secrets, reading .env directly, or hardcoding credentials into commands, and redirects Claude to safe commands such as varlock load and varlock run. Shipped as a single SKILL.md file, it suits any development workflow involving API keys, database passwords, or sensitive configuration.
Instructs Claude to follow security rules when handling environment variables: validate configuration with varlock load (output shows masked values), execute commands with injected env via varlock run, read the value-free .env.schema instead of .env, and help update the schema when variables are missing. When users ask to view or modify secrets directly, it responds with built-in refusals that redirect them to manual updates.
- Developers using Claude Code whose project .env holds third-party API keys (Stripe, Clerk, etc.) and want to keep keys out of the conversation context
- Teams wiring secrets into CI/CD or Docker, who can follow the skill's GitHub Actions and Dockerfile integration examples
- Engineering teams pulling secrets from 1Password or AWS Secrets Manager and injecting them after schema validation
- Anyone debugging authentication who wants Claude to check key presence and format without ever printing the value
What are this skill's strengths and limitations?
- Rules are concrete, with many correct/incorrect command examples that are easy for a model to follow
- Single-file SKILL.md install with a one-liner command
- Includes integration examples for CI/CD, Docker, 1Password, and AWS Secrets Manager
- MIT licensed with no usage restrictions
- Requires the user to install the Varlock CLI separately; the skill is ineffective without it
- No test suite or cross-platform verification is documented in the repo
- Security rules are prompt-level constraints that cannot technically force Claude to avoid reading .env
- Platform-specific details (e.g., Windows) are not documented
How do you install this skill?
Prerequisite: install the Varlock CLI (curl -sSfL https://varlock.dev/install.sh | sh -s -- --force-no-brew and add ~/.varlock/bin to PATH). One-line skill install: mkdir -p ~/.claude/skills/varlock && curl -sSL https://raw.githubusercontent.com/wrsmith108/varlock-claude-skill/main/skills/varlock/SKILL.md -o ~/.claude/skills/varlock/SKILL.md. Alternatively, git clone the repo and copy skills/varlock into ~/.claude/skills/.
How do you use this skill?
Run varlock init in your project to generate .env.schema, annotating variables with @sensitive, @type, etc. The skill activates when Claude sessions mention trigger phrases like environment variables, secrets, .env, or API key. Common safe commands: varlock load (validate with masked output), varlock load --quiet, varlock run -- npm start. No additional configuration beyond automatic triggering is documented.
How does this skill compare with similar options?
The skill wraps Varlock by DMNO (varlock.dev). Without Claude Code, you can use the Varlock CLI directly; this skill's value is injecting safe operational conventions into Claude sessions.