coding-standards

Use when writing or reviewing TypeScript in this repo. Covers the no-`any` rule and where to put new types, the uppercase-acronym style guide, and the rules for code comments (no historical context). (project)

Quality

78%

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

Fix and improve this skill with Tessl

tessl review fix ./.agents/skills/coding-standards/SKILL.md

Quality

Content

81%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.

A tight, example-driven standards document: specific type-placement paths, a casing do/don't table, and good/bad comment examples with a practical smell test. The only weak spot is the thin API Design section, which drops to vague directives where the rest of the skill is concrete.

Suggestions

Make the API Design section concrete like the others — e.g., a do/don't method-name example and a snippet showing validation with the custom error classes in packages/shared/src/errors/.

Trim small redundancies: drop 'and that should be a final resort' and fold the smell-test trigger words into the bad-examples block.

Consider moving the six comment examples to a reference file (e.g., references/comment-examples.md) to bring SKILL.md closer to overview length.

Dimension	Reasoning	Score
Conciseness	Overall lean with concrete tables and examples and no padding about concepts Claude already knows; minor redundancy only — 'and that should be a final resort' repeats 'unless absolutely necessary', and the smell-test paragraph ('If your comment contains "to avoid", "to fix"...') partially restates the bad examples above it. Not 3: the trimmable material is minor; not 5: those small redundancies exist.	4 / 5
Actionability	Highly concrete guidance throughout: exact file paths ('packages/shared/src/types.ts', 'packages/sandbox/src/clients/types.ts'), a do/don't table ('SandboxRPCAPI' vs 'SandboxRpcApi'), good/bad comment examples, a library-casing exception, and a checkable smell test. Not 5: the API Design section is comparatively vague — 'Use clear, descriptive names' and 'Validate inputs' give high-level hints without a do/don't example or how to validate.	4 / 5
Workflow Clarity	Each rule is unambiguous and the no-`any` section gives a clear numbered decision process (1. look for an existing type, 2. define one in the right location, 3. use it everywhere). This is a standards/reference skill with no destructive or batch operations, so no validation checkpoints are required, and the simple-skill exception applies. Not 4: no step is ambiguous or missing.	5 / 5
Progressive Disclosure	Well-organized sections with clear headers, no nested references, no bundle files to misroute, and all inline content is core to the rules. Not 5: the body is ~75 lines and the six comment examples (~30 lines) could arguably live in a reference file; per the under-50-lines guideline the extra bulk leaves a minor organization gap.	4 / 5
	Total	17 / 20 Passed

Description

75%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 solid description with an explicit 'Use when...' trigger, a clear inventory of what the skill covers, and good repo-level scoping. It falls just short of the top anchors on trigger synonyms, task-level trigger specificity, and full coverage of the body's actual content.

Suggestions

Add natural trigger synonyms such as 'naming conventions', 'camelCase', or 'TS' so users phrasing the need differently still match.

Mention the API design guidance (descriptive method names, input validation, custom error classes) so the description's coverage matches the body.

Sharpen the 'when' clause with concrete tasks, e.g. 'Use when adding types, writing code comments, or reviewing TypeScript changes in this repo.'

Dimension	Reasoning	Score
Specificity	Lists several concrete coverage areas — 'the no-`any` rule and where to put new types, the uppercase-acronym style guide, and the rules for code comments' — each specific and domain-grounded. Not 5: the API design guidance present in the body is omitted, and coverage is phrased as topics rather than actions, so minor gaps remain.	4 / 5
Completeness	Explicitly answers both parts: 'Use when writing or reviewing TypeScript in this repo' (when) and 'Covers the no-`any` rule... uppercase-acronym style guide, and... code comments' (what). Not 5: the 'when' clause is broad and could name concrete trigger tasks (adding a type, writing a comment, reviewing a PR); not 3 because a real 'Use when...' trigger clause is present.	4 / 5
Trigger Term Quality	Includes natural terms users would say: 'writing or reviewing TypeScript', 'types', 'code comments', 'style guide'. Not 5: misses common synonyms and variations users might actually say ('TS', 'naming conventions', 'camelCase', 'code review').	4 / 5
Distinctiveness Conflict Risk	Clearly scoped with 'in this repo' and '(project)', targeting a specific rule set, so mostly distinct with minor overlap risk. Not 5: the trigger 'writing or reviewing TypeScript' is broad enough to overlap with a general TypeScript style/linting skill.	4 / 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: cloudflare/sandbox-sdk
Path: .agents/skills/coding-standards/SKILL.md
Commit: 831b8c5

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