Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/plainlang/plain-forge/check-plain-envnpx skills add plainlang/plain-forge --skill check-plain-envgit clone --depth 1 https://github.com/plainlang/plain-forgeWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00120 | $0.06413 |
| Opus 5 | $0.00060 | $0.03207 |
| Sonnet 5 | $0.00024 | $0.01283 |
| Haiku 4.5 | $0.00012 | $0.00641 |
Grade F, and why
check-plain-env scanned grade F with 4 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Harvests environment variableshighData exfiltration
Enumerating or grepping the environment for keys collects credentials unrelated to what the mod says it does.
- `CODEPLAIN_API_KEY` env var **set** — `printenv CODEPLAIN_API_KEY >/dev/null && echo set || echo missing` (never echo the value). Asks for rootmediumPrivilege escalation
A mod that escalates privileges can change anything on the machine, not only the project.
| Java | `brew install openjdk@21` then follow the post-install `sudo ln -sfn ...` step | Downloads and executes remote codehighSupply chain
curl | sh runs whatever the server returns today, which is not necessarily what it returned when this was reviewed.
When emitting an install command, **match the host OS** detected in Step 1. Prefer the OS's first-party package manager. Don't suggest `curl | sh` style installs unless there is no alternative. Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
When emitting an install command, **match the host OS** detected in Step 1. Prefer the OS's first-party package manager. Don't suggest `curl | sh` style installs unless there is no alternative. How it starts
The opening of the file, as written. The whole thing — 289 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Check Plain Env
Always use the skill load-plain-reference to retrieve the ***plain syntax rules — but only if you haven't done so yet.
This skill answers one question: **does the host machine have everything the *plain project needs to render and test? It reads the project, derives the requirement list, probes the machine, and returns a report. It never installs anything itself — that decision belongs to the user.
When to run
- **First time you open a *plain project on a new machine — before the first
codeplain <module>.plainor./test_scripts/run_unittests*.shinvocation. This is the most common case. - At the start of
forge-plainPhase 3 environment verification —forge-plainhistorically did this inline; delegate to this skill instead so the same check runs the same way everywhere. - After
add-feature— when the new feature brought in a new dependency (a new framework, a new service, a new package manager) the project didn't need before. - Before a real render — alongside
plain-healthcheck.plain-healthcheckanswers "are the specs renderable?"; this skill answers "can this machine render them?". Both should pass. - Onboarding — when a teammate (or CI runner, or fresh dev container) is about to start using the project.
- Debugging a confusing failure — when a test script exits with "command not found", "module not found", "could not connect", or similar before any test runs.
- On demand — whenever the user asks "what do I need to install for this project?".
This skill is read-only and observational. It does not edit .plain files, scripts, or configs, and it never invokes install commands on the user's behalf.
What this skill does NOT do
- It does not install anything. It only suggests install commands and lets the user run them.
- It does not generate scripts, modify
config.yaml, or change project files. Useimplement-*-testing-script,init-config-file, etc. for that. - It does not start services (databases, brokers, Docker daemons). It only checks whether the right binaries and (optionally) running endpoints are reachable.
- It does not validate the specs themselves (syntax, dry-run, complexity). Use
plain-healthcheckfor that — the two skills are complementary. - It does not print secrets. Check whether an env var is set (e.g.
printenv FOO >/dev/null && echo set || echo missing), never echo its value.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 289 lines · 120 tokens per session scan F 06ca6931e16c
check-plain-env is a skill published in the GitHub repository plainlang/plain-forge (55 stars, last pushed 5d ago), licensed MIT. It adds 120 tokens to every session and 6,413 once invoked, about $0.0006 per session on Opus 5. A static security scan graded it F with 4 findings (harvests environment variables, asks for root, downloads and executes remote code). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
auto-perf-optimize
Run agent-driven VS Code performance or memory investigations. Use when asked to launch Code OSS, automate a VS Code scenario, run the Chat memory smoke runner, capture renderer heap snapshots, take workflow screenshots, compare run summaries, or drive a repeatable scenario before heap-snapshot analysis.
chat-perf
Run chat perf benchmarks and memory leak checks against the local dev build or any published VS Code version. Use when investigating chat rendering regressions, validating perf-sensitive changes to chat UI, or checking for memory leaks in the chat response pipeline.
chat-pet-sprite-creation
Use when creating or changing VS Code chat pet sprite art, sprite sheets, state animations, eye treatments, Stable/Insiders variants, or pet transitions under src/vs/workbench/contrib/chat/browser/widget/media/chatPet.
cpu-profile-analysis
Analyze V8/Chrome CPU profiles (.cpuprofile) and DevTools trace files (Trace-.json). Use when: profiling performance, investigating slow functions, comparing code paths, finding bottlenecks, analyzing timeToRequest, understanding call trees from sampling profiler data, analyzing layout/paint/rendering, investigating…