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

72%

Does it follow best practices?

Impact

—

No eval scenarios have been run

Securityby

Passed

No known issues

Optimize this skill with Tessl

npx tessl skill review --optimize ./.agents/skills/coding-standards/SKILL.md

Quality

Discovery

67%

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 does a good job of explicitly stating when to use the skill and covering several specific convention areas. However, it reads more as a list of topics than concrete actions, and the trigger terms could be broader to capture more natural user queries. The scoping to 'this repo' helps with distinctiveness but the TypeScript domain is still fairly broad.

Suggestions

Rephrase topic labels as concrete actions, e.g., 'Enforces the no-`any` rule, guides placement of new type definitions, applies uppercase-acronym naming conventions, and strips historical context from code comments.'

Add more natural trigger term variations such as 'TS', 'type definitions', 'interfaces', 'linting', 'coding standards', or 'style conventions'.

Dimension	Reasoning	Score
Specificity	Names the domain (TypeScript) and several specific areas (no-`any` rule, type placement, uppercase-acronym style, comment rules), but these are more like topic labels than concrete actions. It doesn't list specific actionable capabilities like 'enforces no-any lint rule' or 'places new types in X directory'.	2 / 3
Completeness	Clearly answers both 'what' (covers no-any rule, type placement, uppercase-acronym style, comment rules) and 'when' ('Use when writing or reviewing TypeScript in this repo'). The explicit 'Use when...' clause is present and specific.	3 / 3
Trigger Term Quality	Includes relevant keywords like 'TypeScript', 'writing', 'reviewing', 'no-any', 'types', 'code comments', and 'style guide', which are terms a user might naturally use. However, it misses common variations like 'linting', 'type definitions', 'interfaces', 'TS', or 'coding standards'.	2 / 3
Distinctiveness Conflict Risk	It's scoped to TypeScript conventions in a specific repo, which helps, but 'writing or reviewing TypeScript' is broad enough to potentially overlap with other TypeScript-related skills (e.g., testing, architecture). The specific style rules mentioned (acronym casing, no-any) add some distinctiveness but could still conflict with a general TypeScript coding skill.	2 / 3
	Total	9 / 12 Passed

Implementation

77%

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

This is a solid project-specific coding standards skill with clear, actionable guidance across TypeScript typing, naming conventions, and comment style. The do/don't examples with tables and code blocks are particularly effective. Minor weaknesses include some unnecessary explanatory text that Claude doesn't need and a somewhat thin API Design section that could be either expanded or referenced externally.

Suggestions

Remove explanatory sentences like 'This catches errors at compile time instead of runtime' — Claude already understands why `any` is problematic.

Either expand the API Design section with concrete examples (like the other sections have) or remove it if it's covered elsewhere.

Dimension	Reasoning	Score
Conciseness	Mostly efficient but has some unnecessary explanation. The line 'This catches errors at compile time instead of runtime and keeps the codebase consistent' explains something Claude already knows. The 'smell test' section, while useful, adds some verbosity. The comment examples are well-structured but slightly over-explained.	2 / 3
Actionability	Provides concrete file paths for type placement, clear do/don't tables for acronym casing, and specific code examples for good vs bad comments. The no-`any` section gives a clear 3-step process with exact locations. All guidance is specific and directly applicable.	3 / 3
Workflow Clarity	The no-`any` section provides a clear numbered sequence (look for existing type → define new one in correct location → use everywhere). For a coding standards skill, the workflows are appropriately simple and unambiguous. No destructive or batch operations require validation checkpoints.	3 / 3
Progressive Disclosure	Content is well-organized with clear sections and headers, but everything is inline in a single file. The API Design section at the end feels thin and could either be expanded with a reference to a separate file or removed. No bundle files are provided, so there's no external reference structure, but the content length (~80 lines) is borderline for needing separation.	2 / 3
	Total	10 / 12 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 — 11 / 11 Passed

Validation for skill structure

No warnings or errors.

Repository: cloudflare/sandbox-sdk
Commit: 3b58a22

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