CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

phoenix-release-notes

Create Phoenix release documentation grounded in actual code changes. Use this skill whenever the user asks to write release notes, document a release, update release documentation, or mentions undocumented releases. Also trigger when the user wants to update GitHub release descriptions, add entries to the release notes page, or asks what changed in a recent Phoenix version.

68

Quality

86%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Low

Low-risk findings worth noting

SKILL.md
Quality
Evals
Security

Quality

Content

77%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 a highly actionable, well-sequenced workflow with strong validation checkpoints, but it pays for it in length: a long single-file structure with notable redundancy between the procedural steps and the closing checklist. Splitting reference material out and de-duplicating would lift the two weakest dimensions.

Suggestions

De-duplicate the Pre-Submit Checklist against the Step sections — it re-states the title format, reverse-chronological ordering, and length budgets already specified above; reference those rules instead of restating them.

Move the MDX format templates (Format A/B) and the Slack mrkdwn formatting rules into separate reference files under references/ and link to them from SKILL.md to improve progressive disclosure and shorten the main file.

Trim the duplicated reverse-chronological guidance — the Wrong/Right diagram in Step 4 and the re-statement in the checklist cover the same rule; keep one authoritative explanation.

DimensionReasoningScore

Conciseness

Mostly actionable and free of generic concept explanations, but the ~600-line body repeats rules across the Step sections and the Pre-Submit Checklist (title format, reverse-chronological order, length budgets), so it could be tightened.

3 / 5

Actionability

Fully executable guidance throughout — concrete `gh`/`grep`/`mkdir` commands, exact file paths, copy-pasteable MDX frontmatter and `<ReleaseUpdate>`/`<Card>` templates, and real version-line examples.

5 / 5

Workflow Clarity

Steps 1–9 are clearly sequenced with an explicit Verify step (Step 8), quick-validation bash snippets, feedback loops (re-run grep and fix ordering), and a pre-submit checklist — appropriate checkpoints for a batch/multi-file operation that includes `git rm`.

5 / 5

Progressive Disclosure

Well-organized with clear step and sub-section headers, but it is a single monolithic ~600-line file with no external references; content that could live in separate files (MDX format templates, Slack mrkdwn rules) is all inlined.

3 / 5

Total

16

/

20

Passed

Description

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

The description is third-person, clearly states what the skill does and when to use it, and packs in natural trigger phrases a user would realistically say. It is among the strongest reference examples for completeness and trigger coverage.

DimensionReasoningScore

Specificity

Names the domain and several concrete actions ("write release notes", "document a release", "update release documentation", "update GitHub release descriptions", "add entries to the release notes page"), though the core capability collapses to one action (creating release docs) with the rest functioning mainly as triggers, leaving minor coverage gaps.

4 / 5

Completeness

Explicitly answers both what ("Create Phoenix release documentation grounded in actual code changes") and when ("Use this skill whenever... Also trigger when...") with concrete trigger phrases.

5 / 5

Trigger Term Quality

Comprehensive natural-language triggers users would actually say — "write release notes", "document a release", "update release documentation", "undocumented releases", "GitHub release descriptions", "what changed in a recent Phoenix version" — covering synonyms and phrasings.

5 / 5

Distinctiveness Conflict Risk

Scoped to Phoenix release documentation with Phoenix-specific triggers, giving it a clear niche and minimal overlap risk with other skills.

5 / 5

Total

19

/

20

Passed

Validation

75%

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

Validation — 12 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

skill_md_line_count

SKILL.md is long (600 lines); consider splitting into references/ and linking

Warning

metadata_version

'metadata.version' is missing

Warning

metadata_field

'metadata' should map string keys to string values

Warning

relative_links

Relative link issues: 1 missing

Warning

Total

12

/

16

Passed

Repository

Arize-ai/phoenix

Path

.agents/skills/phoenix-release-notes/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.