Route any website you need to visit through markdown.new by prefixing the URL. **WHEN TO USE:** - You would normally open a website link to read content (docs, blog posts, changelogs, GitHub issues, etc.) - You need a cleaner, Markdown-friendly view for copying notes or summarizing
62
72%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/markdown-url/SKILL.mdQuality
Discovery
67%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 reasonably well-structured with an explicit 'WHEN TO USE' section that clearly separates triggers from capabilities. Its main weakness is that the core capability is narrow (URL prefixing) and the trigger terms could overlap with other web-reading or content-fetching skills. Adding more distinctive trigger terms and clarifying what makes this different from general web browsing would strengthen it.
Suggestions
Add more natural trigger terms users might say, such as 'read a webpage', 'fetch page content', 'convert webpage to markdown', 'clean view of a URL'.
Clarify distinctiveness by explicitly stating when NOT to use this skill (e.g., 'Do not use for API calls or programmatic web scraping') to reduce conflict with similar web-access skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names a specific mechanism ('route through markdown.new by prefixing the URL') and mentions some use cases (docs, blog posts, changelogs, GitHub issues), but the core action is somewhat singular—it's essentially just 'prefix URLs with markdown.new'. It doesn't list multiple distinct concrete actions. | 2 / 3 |
Completeness | The description clearly answers both 'what' (route websites through markdown.new by prefixing the URL for a cleaner Markdown view) and 'when' (explicit 'WHEN TO USE' section with specific trigger scenarios like reading docs, blog posts, changelogs, GitHub issues, or needing a Markdown-friendly view). | 3 / 3 |
Trigger Term Quality | Includes some natural terms like 'website link', 'docs', 'blog posts', 'changelogs', 'GitHub issues', 'Markdown-friendly view', 'summarizing'. However, it misses common user phrasings like 'read a webpage', 'fetch URL', 'browse', 'scrape', or 'convert to markdown'. The term 'markdown.new' is specific but not something users would naturally say. | 2 / 3 |
Distinctiveness Conflict Risk | The skill is fairly specific to the markdown.new tool, which helps distinguish it. However, the triggers around 'reading website content' and 'summarizing' could overlap with general web browsing or web scraping skills. The mention of 'docs' and 'GitHub issues' could also conflict with documentation or GitHub-specific skills. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a solid, actionable skill with clear workflow sequencing, explicit failure handling, and concrete examples. Its main weakness is moderate verbosity — some sections could be tightened without losing clarity, and the policy/failure sections, while valuable, add bulk that could be organized more efficiently. Overall it's a well-structured skill that gives Claude unambiguous guidance.
Suggestions
Tighten the Policy section by consolidating the 'when to use' and 'when to skip' lists into a compact table or shorter bullet format to reduce token usage.
Remove slight redundancy between the 'Rewrite Rule' section and the 'Agent Workflow' section — the rewriting instruction appears in both and could be consolidated.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient but has some redundancy — the rewrite rule, examples, and agent workflow overlap in explaining the same concept. The policy section is thorough but could be tightened; some bullet lists feel slightly padded (e.g., listing obvious cases like 'login, OAuth, checkout, payment'). | 2 / 3 |
Actionability | The rewrite rule is concrete and unambiguous with clear examples showing input→output. The workflow steps are specific, the fallback behavior is explicit, and the CLI helper provides an executable command. Claude knows exactly what to do in each scenario. | 3 / 3 |
Workflow Clarity | The workflow is clearly sequenced (rewrite → visit → extract → use), includes explicit failure signals and fallback behavior with a retry policy (attempt once, then fall back). The block/failure signals section acts as a validation checkpoint, and the fallback sequence is well-defined with error recovery. | 3 / 3 |
Progressive Disclosure | The content is well-organized with clear section headers, but everything is inline in a single file. The policy section and block/failure signals could potentially be split out for a cleaner overview. However, given no bundle files are provided and the skill is moderate in length, this is acceptable but not ideal. | 2 / 3 |
Total | 10 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
d3983b1
Table of Contents
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.