ray-skill
Use when user says "send to Ray," "show in Ray," "debug in Ray," "log to Ray," "display in Ray," or wants to visualize data, debug output, or show diagrams in the Ray desktop application.
62
54%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./config/claude/skills/ray-skill/SKILL.mdQuality
Discovery
44%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 description excels at trigger terms and distinctiveness due to the specific 'Ray' application references and natural user phrases, but critically fails at explaining what the skill actually does. It reads entirely as a 'when to use' clause with no 'what it does' clause, making it incomplete despite having strong selection triggers.
Suggestions
Add a capability statement before the trigger clause, e.g., 'Sends data, variables, debug output, and diagrams to the Ray desktop application for visualization and inspection.'
List specific concrete actions the skill performs, such as 'formats log entries, renders Mermaid diagrams, sends collection data, displays stack traces' to improve specificity.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description lacks concrete actions describing what the skill actually does. It mentions 'visualize data, debug output, or show diagrams' but these are vague and appear only in the trigger clause, not as explicit capability statements. There is no 'what does this do' section listing specific actions. | 1 / 3 |
Completeness | While the 'when' is thoroughly covered with explicit trigger phrases, the 'what' is essentially missing. The description never explains what the skill actually does — it only says when to use it. There are no concrete capability statements about what actions the skill performs (e.g., sending data payloads, rendering charts, formatting debug output). | 1 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger phrases users would say: 'send to Ray,' 'show in Ray,' 'debug in Ray,' 'log to Ray,' 'display in Ray.' These are highly natural phrases and include good variation. Also includes broader terms like 'visualize data,' 'debug output,' and 'show diagrams.' | 3 / 3 |
Distinctiveness Conflict Risk | The repeated mention of 'Ray' as a specific desktop application creates a very clear niche. The trigger phrases are all anchored to 'Ray,' making it highly unlikely to conflict with other skills. This is distinctly identifiable. | 3 / 3 |
Total | 8 / 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 comprehensive and highly actionable reference for sending data to Ray via HTTP, with excellent concrete examples for every payload type. Its main weaknesses are redundancy (repeated origin objects, duplicate reference table) that inflates token usage, and a lack of explicit workflow sequencing with error handling. Splitting the detailed payload examples into a reference file and adding a concise workflow section would significantly improve it.
Suggestions
Remove the repeated origin object from every payload example — show it once and note it's required in each payload, or use a shorthand like '"origin": { ... }' after the first full example.
Add an explicit workflow section: 1) Check availability, 2) Construct request, 3) Send POST, 4) Verify response status, with guidance on what to do if Ray isn't running.
Move the detailed payload type examples to a separate PAYLOAD_TYPES.md reference file, keeping only the most common types (log, table, custom) inline with a link to the full reference.
Remove the summary reference table at the bottom since all information is already covered in the detailed sections above, or keep only the table and remove the verbose per-type sections.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is fairly efficient but has significant redundancy — the origin object is repeated verbatim in every single payload example, and the payload type reference table at the end duplicates information already shown in detail above. The overview sentence explaining what Ray is is unnecessary context for Claude. | 2 / 3 |
Actionability | Highly actionable with complete, copy-paste ready JSON payloads for every payload type and a full curl command example. Claude can directly construct HTTP requests from these examples without any guesswork. | 3 / 3 |
Workflow Clarity | The availability check is mentioned but not integrated into a clear workflow sequence (e.g., 'first check availability, then send'). There's no explicit error handling guidance for when Ray isn't running or requests fail. The combining payloads section explains the UUID reuse concept but lacks a step-by-step workflow. | 2 / 3 |
Progressive Disclosure | The content is a monolithic document at ~250 lines that could benefit from splitting the detailed payload type reference into a separate file. The structure with headers is decent, but the sheer volume of inline examples makes it harder to navigate quickly. | 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
- freekmurze/dotfiles
- Commit
2c6f6e8
- 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.