CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

phoenix-typescript

TypeScript conventions and patterns for any TypeScript code in the Phoenix monorepo — including js/packages/, js/app/, and any other TS directories. Use this skill whenever writing, reviewing, or modifying TypeScript code — new functions, types, exports, tests, or refactors. Also trigger when the user asks about TS patterns, naming conventions, or best practices for this project.

66

Quality

83%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

75%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 well-crafted conventions skill: imperative, repo-specific rules with concrete bad/good code examples, no filler library comparisons, and clean section organization in a single self-contained file. Weakest spots are mild conceptual padding in section intros, one truncated code example, and content long enough that example material could be split into reference files.

Suggestions

Trim the conceptual intro sentences ("TypeScript's type system is most valuable when it catches bugs at compile time rather than runtime", "Self-documenting names eliminate mental parsing for the next reader") — Claude already knows these; the rules and examples stand on their own.

Complete the truncated fetchSpans example (add the function body or close the signature) or reduce it to just the JSDoc + destructuring pattern it exists to illustrate.

At ~118 lines, consider moving the longer worked examples (the zoomOut defaults example, the bad/good naming pairs) into a references/ file, keeping SKILL.md as the rules overview with clearly signaled one-level-deep links.

DimensionReasoningScore

Conciseness

The body is dense with repo-specific rules and bad/good code pairs that earn their tokens, but a few sentences explain concepts Claude already knows — e.g. "TypeScript's type system is most valuable when it catches bugs at compile time rather than runtime" and "Self-documenting names eliminate mental parsing for the next reader". Not a 5 because those trimmable rationale sentences and the ~30-line zoomOut example add mild padding; not a 3 because the vast majority of lines are non-inferable repo conventions.

4 / 5

Actionability

Guidance is highly concrete and executable: imperative rules ("Variables must not use single letters", "Import lodash utilities via path imports", "Use Partial<Record<K, V>> for sparse maps") paired with complete bad/good code examples. Not a 5 because the fetchSpans snippet is truncated mid-function (no body or closing brace) and "check sibling packages for existing utilities" gives no concrete discovery step.

4 / 5

Workflow Clarity

The application sequence is clear: "Before writing new code, explore the directory you're working in to understand existing patterns — then follow these rules", reinforced by the Reuse section's check-before-writing guidance. No validation checkpoints are present, but this is a conventions-consultation skill with no destructive or batch operations, so the anchor-4 fit (clear sequence, minor checkpoint gaps) is better than anchor 3, which requires genuinely ambiguous or poorly defined steps.

4 / 5

Progressive Disclosure

No bundle directories (references/, scripts/, assets/) exist, and the skill is a self-contained ~118-line document with clear section headers (Naming, Functions, Type Safety, Imports, Reuse) and a framing intro. The guideline's automatic 5 is reserved for skills under 50 lines; at this length the good/bad example blocks and the zoomOut reference example could arguably live in a reference file, so anchor 4 (good structure, most content appropriately placed) is the best fit.

4 / 5

Total

16

/

20

Passed

Description

87%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 strong description: it explicitly states what it provides (TS conventions/patterns), where it applies (Phoenix monorepo and its TS directories), and when to trigger (writing/reviewing/modifying TS, or asking about patterns/conventions), in third-person imperative voice. The only gaps are a summary-level capability statement and a few missing natural trigger terms like .ts/.tsx.

DimensionReasoningScore

Specificity

The description lists several specific covered areas — "new functions, types, exports, tests, or refactors" plus "TS patterns, naming conventions, or best practices" — grounded in concrete directories (js/packages/, js/app/). It falls short of a 5 because the capability statement itself ("TypeScript conventions and patterns") is summary-level rather than enumerating the concrete convention areas the skill actually covers (naming, type safety, imports, reuse).

4 / 5

Completeness

Both what and when are explicit and concrete: what — "TypeScript conventions and patterns for any TypeScript code in the Phoenix monorepo"; when — "Use this skill whenever writing, reviewing, or modifying TypeScript code" plus a second explicit trigger clause ("Also trigger when the user asks about TS patterns, naming conventions, or best practices"). This matches the anchor-5 example structure of capability sentence followed by explicit trigger phrases.

5 / 5

Trigger Term Quality

Good natural-term coverage: "TypeScript", "TS", "TypeScript code", "naming conventions", "best practices", "refactors", "types", "tests" — all phrasings a user would naturally say, including the TS abbreviation. Not a 5 because file extensions (.ts, .tsx) and common variations like "lint" or "cleanup" are missing.

4 / 5

Distinctiveness Conflict Risk

The skill is scoped to a clear niche — "any TypeScript code in the Phoenix monorepo" with named directories — so its triggers (Phoenix, js/packages/, js/app/) are distinct and unlikely to fire for a generic TypeScript skill or non-Phoenix work. Minor overlap with hypothetical general TS-convention skills exists, but the explicit project scoping keeps conflict risk minimal.

5 / 5

Total

18

/

20

Passed

Validation

87%

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

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

metadata_field

'metadata' should map string keys to string values

Warning

Total

14

/

16

Passed

Repository

Arize-ai/phoenix

Path

.agents/skills/phoenix-typescript/SKILL.md

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.