markdown-url
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
78
72%
Does it follow best practices?
Impact
Pending
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 effectively communicates both what the skill does and when to use it, with a clear 'WHEN TO USE' section. However, the core capability description is somewhat thin—it's essentially one action (prefix URLs with markdown.new)—and the broad scope of 'any website' could create conflicts with other web-related skills. Trigger terms cover some natural variations but miss common user phrasings for web content retrieval.
Suggestions
Add more natural trigger terms users would say, such as 'fetch webpage', 'read URL content', 'browse site', 'get page content', or 'visit link'.
Narrow the scope or add clearer boundaries to reduce conflict risk with other web-fetching or browsing skills—e.g., specify that this is specifically for converting web pages to clean Markdown rather than general web access.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | It describes 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—routing URLs through a proxy—rather than listing multiple concrete actions. | 2 / 3 |
Completeness | 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, 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 phrases like 'fetch webpage', 'read URL', 'browse', 'scrape', or 'visit link' that users would naturally say. | 2 / 3 |
Distinctiveness Conflict Risk | The skill is somewhat distinctive with the 'markdown.new' mechanism, but the broad trigger of 'any website you need to visit' could overlap with general web browsing, web scraping, or URL fetching skills. The scope is quite wide which increases conflict risk. | 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 well-structured, actionable skill with clear examples and a robust fallback workflow. Its main weakness is moderate verbosity — the policy, fallback, and notes sections have overlapping content that could be consolidated. The concrete URL rewrite examples and explicit failure signals are strong points that make this immediately usable.
Suggestions
Consolidate the 'Policy', 'Block/Failure Signals', 'Fallback Behavior', and 'Notes/Exceptions' sections into a single 'When to use / Fallback' section to reduce redundancy.
Remove the 'Notes / Exceptions' section entirely — its content about API endpoints and local paths is already covered by the Policy section or is obvious to Claude.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient but has some redundancy — the policy section, fallback behavior, and notes/exceptions overlap in explaining when not to use markdown.new. The block/failure signals section is useful but could be more compact. Some phrasing like 'do not drop the original scheme' is helpful context Claude might not infer. | 2 / 3 |
Actionability | The rewrite rule is concrete with clear examples showing input→output transformations. The workflow steps are specific and executable, the policy provides concrete categories of when to use/skip, and block/failure signals are enumerated with specific HTTP codes and error messages. | 3 / 3 |
Workflow Clarity | The agent workflow is clearly sequenced (rewrite → visit → extract → use), with explicit fallback behavior and failure detection signals. The feedback loop of attempt → detect failure → fall back is well-defined with specific block signals triggering the fallback. | 3 / 3 |
Progressive Disclosure | The content is well-structured with clear sections and headers, but it's somewhat long for what is essentially a URL-rewriting rule with a fallback policy. The policy and notes/exceptions sections could potentially be consolidated. The CLI helper reference at the end is a nice touch but the overall document could benefit from being more compact rather than needing progressive disclosure. | 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.
- Repository
- am-will/codex-skills
- Commit
ca2c3b3
- 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.