CtrlK
BlogDocsLog inGet started
Tessl Logo

phoenix-client-development

Development guide for the @arizeai/phoenix-client TypeScript SDK — run and resume experiments, manage OpenTelemetry tracer providers with stack-based attach/detach, and write vitest unit and integration tests. Use when adding features to phoenix-client, debugging experiment lifecycle or provider cleanup, modifying dataset/prompt/session/span APIs, or writing tests for the js/packages/phoenix-client/ directory.

75

1.21x
Quality

76%

Does it follow best practices?

Impact

92%

1.21x

Average score across 2 eval scenarios

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./js/packages/phoenix-client/.agents/skills/phoenix-client-development/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

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

The body is admirably concise and well-organized, but it functions as an overview pointing to four rule files that are not shipped, leaving its actionable and workflow guidance incomplete. Shipping the referenced rule files would substantially raise the content score.

Suggestions

Ship the referenced rule files (rules/experiments.md, rules/prompts.md, rules/tracing.md, rules/testing.md) — they are named in the Rule Files table but absent from the bundle, so the progressive-disclosure navigation currently leads to missing files.

Add a brief, sequenced development workflow with an explicit validation checkpoint (e.g., read existing patterns in the target module → implement → run `pnpm --filter phoenix-client test` → only proceed when tests pass).

Include at least one copy-paste-ready code example per API area inline, or ensure the deferred rule files contain executable examples, since the body currently gives executable guidance only for running tests.

DimensionReasoningScore

Conciseness

The body is lean and assumes Claude's competence — a one-line orientation, a single directive, a rule-file table, and one test command — with no padding and no explanation of concepts Claude already knows.

5 / 5

Actionability

Provides one concrete executable command (`pnpm --filter phoenix-client test`) and specific test conventions (vitest, test/ dir, *.test.ts), but the bulk of development guidance for experiments/tracing/prompts is deferred to rule files that are not present, leaving the body's own guidance incomplete.

3 / 5

Workflow Clarity

Only an implicit read-code → write → test sequence exists; there are no explicit checkpoints or validation steps, and the multi-domain scope means the simple-skill exception does not cleanly apply.

3 / 5

Progressive Disclosure

The Rule Files table is well-signaled and one level deep, but the referenced files (rules/experiments.md, rules/prompts.md, rules/tracing.md, rules/testing.md) do not exist in the bundle, so the navigation leads nowhere and the detail content is neither inlined nor actually available.

3 / 5

Total

14

/

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, well-scoped description that clearly states concrete capabilities and provides explicit, natural trigger phrases tied to a specific SDK. Its only weakness is that several API areas (datasets, prompts, sessions, spans) appear as trigger contexts rather than enumerated actions.

DimensionReasoningScore

Specificity

Lists several concrete actions — "run and resume experiments", "manage OpenTelemetry tracer providers with stack-based attach/detach", "write vitest unit and integration tests" — but does not enumerate actions for datasets/prompts/sessions/spans (those appear only as trigger contexts), leaving minor coverage gaps.

4 / 5

Completeness

Explicitly answers both what (run/resume experiments, manage OTel providers, write vitest tests) and when ("Use when adding features..., debugging..., modifying dataset/prompt/session/span APIs, or writing tests...") with concrete trigger phrases.

5 / 5

Trigger Term Quality

Natural developer phrases like "adding features to phoenix-client", "debugging experiment lifecycle", "provider cleanup", and "writing tests for the js/packages/phoenix-client/ directory" give good keyword coverage, though synonyms and file extensions are not exhaustively covered.

4 / 5

Distinctiveness Conflict Risk

Tightly scoped to the named @arizeai/phoenix-client SDK and the specific js/packages/phoenix-client/ path, giving a clear niche with distinct triggers and minimal conflict risk with other skills.

5 / 5

Total

18

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_field

'metadata' should map string keys to string values

Warning

Total

15

/

16

Passed

Repository
Arize-ai/phoenix
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.