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)
83
79%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.agents/skills/coding-standards/SKILL.mdQuality
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 has a clear 'Use when' clause and identifies specific conventions it covers, which is good for completeness. However, it describes rules/topics rather than concrete actions Claude performs, and the trigger scope ('writing or reviewing TypeScript') is broad enough to potentially conflict with other TypeScript-related skills. The trigger terms are adequate but could include more natural variations.
Suggestions
Reframe the description around concrete actions: e.g., 'Enforces no-`any` typing rules, guides type file placement, applies uppercase-acronym naming conventions, and strips historical context from code comments.'
Add more natural trigger term variations such as 'TS', 'type definitions', 'coding standards', 'style conventions', or 'linting rules' to improve discoverability.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (TypeScript in this repo) and mentions several specific conventions (no-`any` rule, type placement, uppercase-acronym style, comment rules), but these are references to rules rather than concrete actions Claude performs. It's more specific than vague but doesn't list multiple concrete actions like 'enforce', 'refactor', or 'lint'. | 2 / 3 |
Completeness | The description explicitly 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 'Use when...' clause is present and clear. | 3 / 3 |
Trigger Term Quality | Includes relevant terms like 'TypeScript', 'writing', 'reviewing', 'code comments', and 'types', which are natural keywords. However, it misses common variations like 'TS', 'type definitions', 'interfaces', 'linting', 'style guide', or 'coding standards' that users might naturally say. | 2 / 3 |
Distinctiveness Conflict Risk | It's scoped to TypeScript conventions in a specific repo, which helps distinctiveness. However, 'writing or reviewing TypeScript' is broad enough that it could overlap with other TypeScript-related skills (e.g., testing, architecture). The specific rule mentions (no-any, acronym style) help somewhat but the overall trigger is still fairly broad. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
92%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a strong, well-crafted coding standards skill that delivers project-specific rules concisely with excellent examples. The do/don't tables, concrete file paths, and smell test heuristic make it highly actionable. The only weakness is the slightly thin API Design section and the lack of any progressive disclosure structure, though the content length is modest enough that this is a minor issue.
Suggestions
Either expand the API Design section with concrete examples (e.g., a before/after of a well-designed SDK method) or remove it and reference a separate API_DESIGN.md file for fuller treatment.
Consider linking to the actual error classes mentioned in `packages/shared/src/errors/` or providing a brief example of proper error handling to make the API Design section as actionable as the other sections.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is lean and efficient. It doesn't explain what TypeScript is, what types are, or other concepts Claude already knows. Every section delivers project-specific rules concisely. The tables and examples are compact and informative. | 3 / 3 |
Actionability | Provides concrete file paths for where to place types, specific do/don't tables for naming conventions, and real TypeScript code examples showing good vs bad comments. The 'smell test' keywords list is immediately actionable for self-review. | 3 / 3 |
Workflow Clarity | The no-`any` section has a clear 3-step process with decision logic. The comments section provides a clear smell test for self-validation. For a coding standards skill (non-destructive, non-batch), the workflows are appropriately sequenced and unambiguous. | 3 / 3 |
Progressive Disclosure | The 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, though for a skill of this size (~80 lines) it's borderline acceptable. | 2 / 3 |
Total | 11 / 12 Passed |
Validation
100%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
f03920a
- Reviewed
Table of Contents
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.