phoenix-otel-development
Guide for the phoenix-otel TypeScript package — OTel registration, stack-based global provider management, and provider lifecycle.
48
52%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./js/packages/phoenix-otel/.agents/skills/phoenix-otel-development/SKILL.mdQuality
Discovery
32%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 identifies a specific package (phoenix-otel) and lists topic areas but lacks concrete actions and explicit trigger guidance. It would benefit significantly from a 'Use when...' clause and more natural trigger terms like 'OpenTelemetry', 'tracing', and 'instrumentation'. The description reads more like a table of contents than actionable selection guidance.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user asks about setting up OpenTelemetry tracing with phoenix-otel, configuring trace providers, or instrumenting a TypeScript application.'
Include natural trigger terms users would actually say, such as 'OpenTelemetry', 'tracing', 'instrumentation', 'observability', 'trace exporter', and 'spans'.
Replace topic-area language with concrete actions, e.g., 'Register and configure OTel tracer providers, push/pop providers on the global stack, manage provider shutdown and cleanup.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (phoenix-otel TypeScript package) and some actions (OTel registration, stack-based global provider management, provider lifecycle), but these are more like topic areas than concrete actions. It doesn't list specific operations like 'register a tracer provider', 'push/pop providers from the stack', etc. | 2 / 3 |
Completeness | Describes what the skill covers at a high level but completely lacks a 'Use when...' clause or any explicit trigger guidance for when Claude should select this skill. Per rubric guidelines, a missing 'Use when...' clause should cap completeness at 2, and since the 'what' is also somewhat weak, this scores a 1. | 1 / 3 |
Trigger Term Quality | Includes relevant terms like 'phoenix-otel', 'OTel', 'TypeScript', and 'provider lifecycle', but misses common variations users might say such as 'OpenTelemetry', 'tracing', 'instrumentation', 'telemetry setup', or 'observability'. | 2 / 3 |
Distinctiveness Conflict Risk | The mention of 'phoenix-otel' package specifically is fairly distinctive, but the broader terms like 'TypeScript package' and 'provider lifecycle' could overlap with other OpenTelemetry or provider management skills. The niche is somewhat clear but not sharply defined. | 2 / 3 |
Total | 7 / 12 Passed |
Implementation
72%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured, concise skill that serves effectively as a routing document to more detailed rule files. Its main weakness is the lack of any concrete code examples or executable guidance in the SKILL.md itself — the reader must consult rule files for all substantive instructions. The progressive disclosure and conciseness are strong.
Suggestions
Add a minimal executable code example showing basic `register()` usage so the skill provides immediate actionable guidance without requiring rule file consultation.
Consider adding a brief sequenced workflow for common tasks (e.g., 'Adding a span processor: 1. Register provider → 2. Add processor → 3. Verify export') with validation checkpoints.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Very lean and efficient. The opening sentence establishes purpose and architectural role without over-explaining. No unnecessary concepts are taught. Every line serves a purpose. | 3 / 3 |
Actionability | Provides a concrete test command and mentions dual-module output, but lacks executable code examples for the core tasks (registration, provider lifecycle). The actual actionable guidance is deferred entirely to rule files. | 2 / 3 |
Workflow Clarity | The rule file table provides clear routing for when to consult each file, and the build/test command is explicit. However, there's no sequenced workflow for common development tasks like adding a new span processor or managing provider lifecycle, and no validation checkpoints. | 2 / 3 |
Progressive Disclosure | Excellent progressive disclosure structure: a concise overview with a well-organized table pointing to three clearly-scoped rule files, each with a description of when to read them. References are one level deep and clearly signaled. | 3 / 3 |
Total | 10 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
metadata_field | 'metadata' should map string keys to string values | Warning |
Total | 10 / 11 Passed | |
- Repository
- Arize-ai/phoenix
- Commit
924117e
- 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.