phoenix-frontend
Frontend development guidelines for the Phoenix AI observability platform. Use when writing, reviewing, or modifying React components, TypeScript code, styles, or UI features in the app/ directory. Triggers on any frontend task — new components, UI changes, styling, accessibility fixes, form handling, or component refactoring. Also use when the user asks about frontend conventions or component patterns for this project. For design system rules (error display, layout, dialogs, tokens), use the phoenix-design skill.
67
82%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a strong skill description that clearly defines its scope (frontend development for the Phoenix AI platform), lists concrete triggering actions, and explicitly differentiates itself from the related phoenix-design skill. It uses proper third-person voice throughout and provides both 'what' and 'when' guidance with natural trigger terms that developers would use.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: writing/reviewing/modifying React components, TypeScript code, styles, UI features, new components, UI changes, styling, accessibility fixes, form handling, component refactoring. These are concrete, actionable capabilities. | 3 / 3 |
Completeness | Clearly answers both 'what' (frontend development guidelines for Phoenix AI observability platform) and 'when' with explicit triggers ('Use when writing, reviewing, or modifying...', 'Triggers on any frontend task...', 'Also use when the user asks about frontend conventions...'). Also includes a helpful boundary clause directing to phoenix-design for design system rules. | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural terms users would say: 'React components', 'TypeScript code', 'styles', 'UI features', 'frontend', 'accessibility fixes', 'form handling', 'component refactoring', 'app/ directory'. These are terms developers naturally use when requesting frontend work. | 3 / 3 |
Distinctiveness Conflict Risk | Clearly scoped to the Phoenix AI observability platform's app/ directory for frontend work, and explicitly delineates its boundary from the phoenix-design skill for design system rules. This dual scoping (project-specific + explicit skill boundary) makes it highly distinctive and unlikely to conflict. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
64%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 overview skill that efficiently routes Claude to the right rule files based on task type. Its main weakness is that the referenced rule files are not provided in the bundle, and the skill body itself lacks concrete executable examples — the URL state guidance would benefit from a code snippet, and the verification workflow could be more explicit with validation checkpoints.
Suggestions
Add a brief concrete code example for URL state encoding (e.g., using React Router's useSearchParams) to make that section fully actionable
Include the referenced rule files in the bundle so the progressive disclosure pattern is verifiable and complete
Make the workflow more explicit with numbered steps and a validation checkpoint, e.g., '1. Explore existing patterns → 2. Read relevant rule file → 3. Implement → 4. Verify with agent-browser → 5. Check shared component usages if applicable'
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is lean and efficient. It assumes Claude's competence with React/TypeScript, avoids explaining what components or Relay are, and every section earns its place. The routing table for rule files is a particularly efficient pattern. | 3 / 3 |
Actionability | The skill provides concrete guidance on URL state and verification steps, but the core actionable content is delegated to rule files that aren't provided in the bundle. The URL state section gives a clear principle but lacks a concrete code example. The verification step mentions `agent-browser` but doesn't show exact usage. | 2 / 3 |
Workflow Clarity | There's a clear sequence implied (explore existing patterns → read relevant rules → implement → verify), and the verification section mentions checking usages of shared components. However, there are no explicit validation checkpoints or feedback loops for error recovery, and the workflow is more implicit than explicitly sequenced. | 2 / 3 |
Progressive Disclosure | The routing table to rule files is a well-structured progressive disclosure pattern with clear signals for when to read each file. However, none of the referenced rule files are provided in the bundle, making it impossible to verify they exist or contain appropriate content. The skill itself is appropriately concise as an overview, but the missing bundle files weaken confidence in the references. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
metadata_version | 'metadata.version' is missing | Warning |
metadata_field | 'metadata' should map string keys to string values | Warning |
Total | 9 / 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.