The skill rewrites tool descriptions without certifying their meaning
A tool description that drops an exception can send an agent down the wrong path. ASD-STE100 Skill asks Claude Code to simplify English while keeping conditions and uncertainty intact. The README targets error messages, system prompts, and instructions passed between agents. Its most useful rule is restraint: if shorter wording loses required precision, the assistant should retain the wording and explain the trade-off.
Our checkout was only 7 files, roughly 487 source lines, and 0.1 MB. Most of what you adopt is a writing policy, examples, and a Python linter. There is no new model to deploy in the documented workflow. That makes the skill easy to inspect, but the rewriting still depends on Claude following the instructions. A short policy file cannot establish that a model preserved every condition in your original text.
What happened when we ran it
Our sandbox installed commit 32511c6 in 5 seconds, adding 35 packages and using 38 MB on disk. The build succeeded in 1 second. We measured it on October 11, 2026, using an unprivileged Debian container with 3 CPUs, 8 GB of RAM, the uv Python 3.12 Bookworm image, and no secrets. Those results show that the measured repository setup completed without an install or build failure.
Tests were skipped because our run found no tests script or target. The scan also found 0 CI workflow files, no Dockerfile, and no tests directory. Pip-audit reported 0 known vulnerabilities. That audit result concerns known dependency advisories in the measured environment. It says nothing about whether a rewritten instruction is safe or faithful. Don't turn the successful build into a claim that the skill's language behavior passed a suite.
Strict mode and explanatory prose need different treatment
The skill selects Strict mode for procedures and tool descriptions, and STE-flavored mode for READMEs or explanatory prose. Both favor explicit actors and simple sentence structure. STE-flavored mode relaxes fixed word-use discipline so ordinary explanation has some room to breathe. By default the assistant returns the rewrite alone, with a short note when it deliberately retains a phrase. You can request a before-and-after table naming the rules behind each change.
The 38 MB measured environment is small enough that footprint shouldn't decide adoption. The better question is what you're editing. This skill is useful for making a function description less ambiguous, particularly when an exception is buried inside a long sentence. The README excludes creative and marketing writing because the style is deliberately literal. Applying it to a personal essay would solve a problem the essay probably doesn't have.
The Python linter checks patterns and leaves semantic review to you
The linter source checks semicolons, long sentences, selected phrasal verbs, and other structural patterns. Some findings are advisory. It deliberately avoids treating uncertainty words as style defects, and the README says it cannot compare an original with a rewrite. An instruction that changes permission into obligation may still satisfy sentence-length and punctuation checks. A clean lint result is therefore a limited statement about form.
Our 1-second build does not close that gap. Open issue 17 concerns this exact ste-lint.py: sentence segmentation around quotations and abbreviations, wrapped sentences, column drift after inline code, and argument parsing. PR 20 proposes corrections and remains open. Treat those as reported upstream defects, separate from our lab result, which contains no executed test target.
The official STE dictionary is absent by design
The project borrows principles from Simplified Technical English, but the README explicitly says it does not reproduce ASD's official approved dictionary. Dictionary-dependent guidance is advisory. The skill can favor plain words and consistent terminology without establishing that each word is approved under the standard. A maintenance-documentation team requiring formal STE compliance needs the actual standard and a review process that checks it, rather than a reassuring project name.
That boundary is visible in a repository of roughly 487 source lines: this is a small clarity aid with regex checks, not a language-compliance service. For ordinary agent instructions, the narrow scope is reasonable. Have someone compare the original and rewrite for lost negation, conditions, identifiers, and uncertainty. Those comparisons are our recommended adoption check, not an accuracy result from the sandbox. Keep the original available until you approve the replacement.
Claude Code is documented; Codex support remains a proposal
The README documents installing through npx skills add danyuchn/asd-ste100-skill or cloning into Claude's personal skills directory. The skills CLI sends anonymous installation telemetry, and the README gives DISABLE_TELEMETRY=1 as an opt-out. Rewriting needs a configured Claude Code environment. The standalone linter uses Python's standard library. Open PR 21 proposes Codex support, so don't mistake that contribution for merged installation guidance.
GitHub showed 4,375 stars and 5 open issues and PRs. The last push was October 4, 2026, followed by October issue and contribution activity. The latest-release endpoint returned no published release, which does not establish abandonment. Our 5-second install makes a trial inexpensive. Choose Vale or textlint for configurable prose checks in a documentation workflow. Choose this skill when you want Claude to draft clearer instructions, then check the exception you most need it to preserve.