read
by tw93The read skill fetches URLs and PDFs as clean Markdown for reading, quoting, citation, and downstream work. It is built for read usage on paywalled pages, JS-heavy sites, X/Twitter, GitHub files, Chinese platforms, and Workflow Automation flows that need reliable source text before analysis. Use the read guide when you want source capture, not commentary.
This skill scores 84/100, which means it is a solid listing candidate for directory users. It gives a credible, agent-friendly workflow for fetching URLs and PDFs into clean Markdown, with enough routing and fallback detail that an agent can trigger it with less guesswork than a generic prompt.
- Strong triggerability: explicit when_to_use/dispatch_intent covers URLs, PDFs, and common user intents in English and Chinese.
- Operationally clear workflow: routing rules distinguish Feishu, Weixin, GitHub, X/Twitter, PDFs, and a fallback proxy cascade.
- Real execution leverage: included scripts and method references show concrete fetch paths, privacy tiers, and save-path behavior.
- No install command in SKILL.md, so setup/adoption depends on users figuring out runtime dependencies from scripts and references.
- Some branches rely on external proxies or platform-specific APIs, so success may vary on JS-heavy, paywalled, or credentialed sources.
Overview of read skill
What read does
The read skill fetches a URL or PDF and returns clean Markdown, so you can inspect, quote, cite, or reuse web content without manually copying from a browser. It is built for the read workflow: take a link, turn it into readable text, and avoid analysis unless you ask for it later.
Best fit for this skill
Use the read skill when your real job is “read this page” or “extract this document,” especially for paywalled pages, JS-heavy sites, PDFs, X/Twitter links, and common Chinese platforms such as WeChat and Feishu. It is a strong fit for Workflow Automation when you need dependable content ingestion before summarizing, translating, comparing, or saving.
What makes it different
The main differentiator is routing: read chooses a fetch method based on the source instead of forcing one generic prompt. That matters because GitHub, PDF URLs, WeChat articles, and local files often need different handling. It also emphasizes privacy tiers and a no-analysis default, which makes it more predictable for downstream automation.
How to Use read skill
Install the read skill
Install with npx skills add tw93/Waza --skill read. After install, start by reading SKILL.md, then check references/read-methods.md and references/save-paths.md for the actual fetch and save rules. If you need platform-specific behavior, inspect scripts/fetch.sh, scripts/fetch_weixin.py, scripts/fetch_feishu.py, and scripts/fetch_local.py.
Give the skill the right input
The read skill works best with a single, direct target: a URL, a PDF link, or a local PDF path. If you want output quality, specify the source and the result you want, not just “read this.” Stronger prompts look like: “Read this WeChat article and return the Markdown only,” or “Fetch this PDF and keep headings intact for citation.”
Use the routing logic well
If the target is GitHub content, prefer raw file URLs or gh when you want clean source extraction. For mp.weixin.qq.com, expect the proxy cascade first and the WeChat script as fallback. For x.com or twitter.com, use the proxy route; for local PDFs, extraction is the right path. This routing is the core read usage advantage over a generic browser prompt.
Read first, then decide whether to save
By default, read displays content inline rather than saving a file. Ask to save only when you explicitly need a Markdown artifact, and then use a title-based path like ~/Downloads/{title}.md. If you are chaining read into a research or automation flow, confirm whether the next step expects display-only or a saved file.
read skill FAQ
Is read just a generic fetch prompt?
No. A generic prompt can ask for page text, but read includes source-based routing, privacy-aware fetch tiers, and platform-specific scripts. That reduces failure on pages that standard browser extraction handles poorly.
When should I not use read?
Do not use read for plain text that is already in the repo and does not need web fetching. It is also not the right choice if you want commentary, interpretation, or a summary before the source text is actually fetched.
Is read beginner-friendly?
Yes, if you have a URL and a clear goal. The biggest beginner mistake is giving a vague instruction like “check this link” without saying whether you want the markdown output, a saved file, or follow-up analysis. The read guide is simple, but the input needs to be specific.
Does read work well for Workflow Automation?
Yes, especially when the next step depends on clean source text. It fits automation pipelines that collect articles, PDFs, or platform posts before tagging, summarizing, translating, or archiving. If your workflow needs deterministic source capture, read is a practical front-end skill.
How to Improve read skill
Give better source context
The most useful input improvement is source clarity: include the exact URL, note whether it is a PDF or a page, and say if you expect tricky content such as login walls, Chinese platforms, or GitHub files. The better you describe the source, the less likely the skill is to choose a weaker path.
State the output constraints up front
If you need Markdown only, mention that. If you want the content saved, say so before the fetch. If you need citation-friendly formatting, ask for headings and links to be preserved as much as possible. These constraints matter more than extra explanation because read is designed to output source text, not interpret it.
Watch for common failure modes
The main failure modes are using the wrong route, expecting local-only fetching to handle JS-heavy pages, or asking read to summarize before the source is captured. Another common issue is trying to fetch pages that are blocked or empty without switching to the proxy path. When that happens, the fix is usually better source selection, not a longer prompt.
Iterate from fetch to follow-up
A good read workflow is fetch first, then ask a second prompt for analysis, extraction, or comparison. If the first output is too noisy, refine the source or specify the platform; if it is missing structure, ask for a different fetch method or a save path. For read usage, small prompt changes often improve results more than rephrasing the same request.