get-env-var

get an env var, fetch a secret, missing env var, missing token/API key, load secrets from Infisical, infisical. Fetch secrets from the team's Infisical workspace into the shell environment so subsequent commands can use them.

Quality

85%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

96%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

An excellent single-file skill body: lean, fully executable, with genuine validation checkpoints and error-recovery rules, plus safety constraints that anticipate real failure modes. The only marginal note is that a couple of sections (setup vs. usage) could be split or trimmed to keep the body comfortably within the short-skill range.

Dimension	Reasoning	Score
Conciseness	Every section contributes non-obvious operational knowledge Claude cannot infer — repo-linked `.infisical.json` with default `dev` environment, why `--plain` listing leaks multi-line values, and the empty-stdout failure mode outside the repo root. There is no padding and no explanation of concepts Claude already knows, matching the lean anchor 5.	5 / 5
Actionability	All guidance is copy-paste ready: `export NAME="$(infisical secrets get NAME --plain --silent)"`, `infisical run -- <command>`, the jq name-listing, the `wc -c` non-empty check, and the `gh secret set` forwarding pipe, with placeholders (`NAME`, `<slug>`, `<owner>/<repo>`) clearly marked. Fully executable and covering the common cases — anchor 5.	5 / 5
Workflow Clarity	The workflow includes explicit validation checkpoints (auth check with a login recovery path, byte-count existence check) and an explicit error-recovery rule ("If a secret does not exist, STOP and tell the user exactly which secret name and environment to add; do not invent values"). The destructive write path (`gh secret set`) is guarded by a warning about silent empty-stdout storage, so the destructive/batch cap does not apply. This matches the feedback-loop-rich anchor 5.	5 / 5
Progressive Disclosure	Sections are clear, well-ordered, and everything inline genuinely belongs inline (no separate-file content). It is not a 5 only because the body runs roughly 60 lines, just past the under-50-lines heuristic under which a single-file skill earns the top score; good structure with a minor organizational gap fits anchor 4.	4 / 5
	Total	19 / 20 Passed

Description

73%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong, niche-specific description with good natural trigger keywords and an explicit statement of what it does. Its main gaps are a single-action capability description (the skill body covers listing, forwarding, and injection too) and the absence of an explicit "Use when..." clause.

Suggestions

Enumerate the skill's other concrete capabilities in the description — e.g. listing secret names without printing values and forwarding secrets to consumers such as `gh secret set` — to raise specificity from one action to several.

Convert the keyword-style triggers into an explicit trigger clause, e.g. "Use when a command reports a missing env var/token/API key or the user asks to load secrets from Infisical."

Add a couple of common synonym phrasings users naturally say, such as "credential not set" or "environment variable undefined", to broaden trigger coverage.

Dimension	Reasoning	Score
Specificity	"Fetch secrets from the team's Infisical workspace into the shell environment so subsequent commands can use them" names the domain plus one concrete action; the leading keyword list adds no capabilities. It is not a 4 because the description never mentions the other actions the skill supports (listing secrets, forwarding to a consumer, injecting into a command).	3 / 5
Completeness	The "what" is explicit and concrete, and the "when" is conveyed through trigger keywords ("missing env var, missing token/API key"), which functions as trigger guidance. Not a 5 because there is no explicit "Use when..." clause; not a 3 because the when is directly stated via keywords rather than merely implied.	4 / 5
Trigger Term Quality	"get an env var, fetch a secret, missing env var, missing token/API key, load secrets from Infisical, infisical" covers natural verb and symptom phrasing well, but misses common variations such as "credential" or "secret not set/found". Good coverage with a few natural terms missing fits anchor 4 rather than the comprehensive anchor 5.	4 / 5
Distinctiveness Conflict Risk	"Fetch secrets from the team's Infisical workspace" carves out a clear niche (Infisical-backed secret retrieval) with distinct triggers, so risk of firing for an unrelated skill is minimal. Matches anchor 5 cleanly.	5 / 5
	Total	16 / 20 Passed

Validation

100%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: different-ai/openwork
Path: .opencode/skills/get-env-var/SKILL.md
Commit: 417244c

Reviewed: 2 days ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.