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 skills add plainlang/plain-forge --skill plain-healthcheckgit clone --depth 1 https://github.com/plainlang/plain-forgeWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/plainlang/plain-forge/plain-healthcheck)<a href="https://agentmods.dev/skills/plainlang/plain-forge/plain-healthcheck"><img src="https://agentmods.dev/badge/skills/plainlang/plain-forge/plain-healthcheck/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/plainlang/plain-forge/plain-healthcheck"><img src="https://agentmods.dev/badge/skills/plainlang/plain-forge/plain-healthcheck.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 3 findings, up to high
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- high Rogue Agent · line 93 Skill modifies its own code, configuration, or behavior at runtime. Self-modification enables an agent to escalate privileges, disable safety constraints, or install persistent backdoors.Fix: Prevent the skill from modifying its own code, SKILL.md, or configuration files. Treat skill files as read-only at runtime.
- low Excessive Agency · line 8 Skill's behavior or capabilities extend beyond its stated purpose. Scope creep allows an agent to perform actions unrelated to its documented functionality, increasing the attack surface.Fix: Limit the skill's scope to its documented purpose. Remove instructions that enable the agent to perform actions outside its stated functionality.
- low Excessive Agency · line 20 Skill's behavior or capabilities extend beyond its stated purpose. Scope creep allows an agent to perform actions unrelated to its documented functionality, increasing the attack surface.Fix: Limit the skill's scope to its documented purpose. Remove instructions that enable the agent to perform actions outside its stated functionality.
What 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.1 | $0.00137 | $0.03301 |
| Opus 5.5 | $0.00055 | $0.01320 |
| Sonnet 5.5 | $0.00027 | $0.00660 |
| Haiku 4.5 | $0.00014 | $0.00330 |
Grade A, and why
plain-healthcheck scanned grade A with 0 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 18d 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.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 142 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Plain Healthcheck
Always use the skill load-plain-reference to retrieve the ***plain syntax rules — but only if you haven't done so yet. Step 3b checks every module against those rules, and they are needed to fix what plain-parser reports in Step 3a.
When to run
Run this skill **whenever anything in the *plain project is finalized and the project is about to be left in a state the user (or another skill) might render from. That includes, but is not limited to:
- End of
forge-plain(Phase 4) — before handing off the render target. - End of
add-feature(Phase 3 final review) — before declaring the feature done. - End of
debug-specs— after applying a fix, before telling the user to re-render. - After finalizing any single edit that changes the renderable surface — e.g. after
add-concept,add-functional-spec,add-functional-specs,add-implementation-requirement,add-test-requirement,add-acceptance-test,add-template,add-resource,resolve-spec-conflict,break-down-func-spec,consolidate-concepts,refactor-module,create-import-module,create-requires-module, or any of theimplement-*-testing-scriptskills. - After hand-editing a
.plainfile, aconfig.yaml, or anything undertest_scripts/. - On demand — whenever the user asks whether the project is in a renderable state.
The healthcheck is not a forge-plain-only step. Treat it as the default closing move for any workflow that finalizes something in the project.
Do not skip this skill because "the healthcheck passed earlier" — config.yamls, scripts, and specs can all drift between runs. The healthcheck is cheap; rendering against stale specs is expensive.
Workflow
The skill is a detect → fix → re-run loop. It does not stop at the first failure; it surfaces everything wrong, fixes what it can, and only returns when either everything passes or a gap genuinely requires user input.
Step 1 — Inventory the project
- List every
.plainfile in the repo root (and any subdirectories that contain.plainfiles). Build the module graph from each file's YAML frontmatter (requires,import); Step 3a validates it. - Identify top modules — every module that is not
requires-ed by any other module. A single-stack project has one top module; a multi-part project (e.g. backend + frontend) has one top module per part. - List every
config.yamlin the repo (root and per-part directories such asbackend/,frontend/). - List every script under
test_scripts/. - Pair each top module with the
config.yamlthat governs it. The pairing rule is: the config file in the same directory as the top module wins; failing that, the repo-rootconfig.yaml. A multi-part project must have one config per part — record any top module that has no governing config as a failure.
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.
- 18d ago Changed 3f794397c4f0
- 20d ago Changed · +9 lines · +6 tokens per session b5afc68d72dc
- 1mo ago First seen · 133 lines · 131 tokens per session scan A ebae64e2dc7b
plain-healthcheck is a skill published in the GitHub repository plainlang/plain-forge (79 stars, last pushed yesterday), licensed MIT. It adds 137 tokens to every session and 3,301 once invoked, about $0.0005 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
research-engineer
An uncompromising Academic Research Engineer. Operates with absolute scientific rigor, objective criticism, and zero flair. Focuses on theoretical correctness, formal verification, and optimal implementation across any required technology.
eval-dataset-design
A guide to creating reliable test sets for AI agents. Each evaluation task includes the request, the simulated user's behaviour, a reset starting state, and a success check that can be independently verified.
tika-eval-compare
Compare extracts from two Tika builds over a corpus to detect regressions in content, encoding, exceptions, and embedded-document handling. Use for "compare before/after extracts", "eval this change against the corpus".
cua-driver
Use Cua Driver for desktop or browser tasks that are awkward or unavailable through Bash/APIs, or when the user explicitly wants GUI interaction: app testing, visual bug reproduction, form filling, calendar entry, screenshots, and demo recording. Also covers Cua setup; not OpenAI Codex Computer Use or web research.
jetson-validate-image
Use after jetson-flash-image to run static BSP checks, on-target smoke/regression tests on a flashed DUT, or both. Not for build or flash steps. Triggers: validate bsp, on-target validation.
atmos-validation
Validate Atmos projects, components, arbitrary JSON Schema inputs, EditorConfig, and GitHub Actions; use affected-file selection and native CI annotations.