implement-posix-command

Implement a new POSIX command as a builtin in the safe shell interpreter

Quality

67%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./.claude/skills/implement-posix-command/SKILL.md

Quality

Content

77%Weight 40%Scale 1-3

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

The body is highly actionable with an exemplary sequenced, gated workflow and concrete code, but it is a long monolithic file with no progressive disclosure into reference files and some concept explanations Claude does not need. Splitting detail-heavy sections into bundle references and trimming known-concept explanations would improve it.

Suggestions

Move large reusable templates (test helpers, fuzz seed-catalog sources, the GNU-equivalence coverage table) into files under references/ and link to them one level deep to improve progressive disclosure.

Trim explanations of concepts Claude already knows, such as the Go import-cycle rationale and what `cat -A`/`cat -v` reveal, keeping only the project-specific consequences.

Consider consolidating the repeated GATE CHECK boilerplate into a single stated convention referenced by each step to reduce token weight.

Dimension	Reasoning	Score
Conciseness	The ~600-line body is largely concrete project-specific guidance, but includes some explanation Claude already knows (e.g. the Go import-cycle rationale, what `cat -A` reveals, pflag mechanics) and could be tightened; it is mostly efficient yet padded in places, matching the level-2 anchor and not level 3 due to the overall verbosity.	2 / 3
Actionability	It provides fully executable, copy-paste-ready material: exact file paths, complete Go test-helper and fuzz-test code blocks, a concrete YAML scenario schema, and exact shell commands; this matches the level-3 anchor and is well above the pseudocode level-2 example.	3 / 3
Workflow Clarity	Ten steps are explicitly sequenced with parallel/sequential gating, per-step GATE CHECK calls to TaskList, and validation feedback loops (run tests, fix failures, re-run, second-pass review); this matches the level-3 anchor with explicit checkpoints and error-recovery loops.	3 / 3
Progressive Disclosure	No bundle files exist in references/scripts/assets, and all ~600 lines live inline in a single SKILL.md with sections but no one-level-deep references to separate detail files; the structure is organized (so above level 1) but content that could be split out (test-helper templates, fuzz-seed catalogs, GNU-equivalence tables) is inline, matching the level-2 anchor.	2 / 3
	Total	10 / 12 Passed

Description

57%Weight 40%Scale 1-3

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

The description is clear and distinctive about its niche but is a single-action statement with no explicit "Use when..." trigger guidance, capping completeness. Adding a trigger clause and enumerating the concrete actions would raise specificity and completeness.

Suggestions

Add an explicit trigger clause, e.g. "Use when adding a new POSIX command to the safe shell interpreter as a Go builtin."

List the concrete actions involved (research POSIX behavior, implement the builtin, add tests, harden against unsafe flags) rather than the single verb "Implement".

Include natural user phrasings such as "add a shell command" or "implement a builtin" to improve trigger-term coverage.

Dimension	Reasoning	Score
Specificity	Quotes "Implement a new POSIX command as a builtin in the safe shell interpreter" — it names a concrete domain (POSIX command, builtin, safe shell interpreter) and a single action (implement), but does not list multiple specific concrete actions, matching the level-2 anchor; not level 3 because there is only one verb and no enumeration of actions.	2 / 3
Completeness	It answers "what" (implement a POSIX command as a builtin) but provides no "Use when..." trigger, so "when" is entirely missing; per the guideline a missing explicit trigger clause caps completeness at 2, and it cannot reach level 3 without an explicit when clause.	2 / 3
Trigger Term Quality	Keywords like "POSIX command", "builtin", and "safe shell interpreter" are relevant but lean toward technical jargon and miss common user variations (e.g. "add a command", "shell builtin"); not level 1 because the terms are on-topic, not level 3 because coverage of natural phrasings is thin.	2 / 3
Distinctiveness Conflict Risk	The narrow niche of implementing POSIX commands as builtins inside this specific safe shell interpreter has distinct triggers and is unlikely to fire for unrelated skills, matching the level-3 anchor; it is clearly more specific than the level-2 "could still overlap" example.	3 / 3
	Total	9 / 12 Passed

Validation

87%

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 — 14 / 16 Passed

Validation for skill structure

Criteria	Description	Result
skill_md_line_count	SKILL.md is long (611 lines); consider splitting into references/ and linking	Warning
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	14 / 16 Passed

Repository: DataDog/rshell
Path: .claude/skills/implement-posix-command/SKILL.md
Commit: c5b036b

Reviewed: 6 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.