read

read スキルの概要

read がすること

read スキルは URL または PDF を取得し、きれいな Markdown にして返します。ブラウザから手でコピーしなくても、Web コンテンツを確認したり、引用したり、再利用したりできます。read ワークフロー向けに作られており、リンクを渡して読みやすいテキストに変換し、あとで必要になるまで分析はしません。

このスキルに最適なケース

実際の目的が「このページを読む」「この文書を抜き出す」なら、read スキルが向いています。特に、ペイウォール付きページ、JavaScript が多いサイト、PDF、X/Twitter のリンク、WeChat や Feishu などの一般的な中国系プラットフォームに強みがあります。要約、翻訳、比較、保存の前に、確実にコンテンツを取り込みたい Workflow Automation では特に有効です。

何が違うのか

最大の差分はルーティングです。read は 1 つの汎用プロンプトに押し込めるのではなく、ソースに応じて取得方法を選びます。GitHub、PDF URL、WeChat 記事、ローカルファイルでは、それぞれ別の扱いが必要になることが多いため、この違いは重要です。また、プライバシーの段階分けと「分析しない」既定動作を重視しているため、下流の自動化でも挙動が読みやすくなります。

read スキルの使い方

read スキルをインストールする

npx skills add tw93/Waza --skill read でインストールします。導入後はまず SKILL.md を読み、実際の取得ルールと保存ルールは references/read-methods.md と references/save-paths.md で確認してください。プラットフォーム固有の動作が必要なら、scripts/fetch.sh、scripts/fetch_weixin.py、scripts/fetch_feishu.py、scripts/fetch_local.py を見れば分かります。

適切な入力を与える

read スキルは、1 つの明確な対象に対して最もよく働きます。URL、PDF リンク、ローカルの PDF パスのいずれかを指定してください。出力品質を上げたいなら、単に「読んで」ではなく、ソースと欲しい結果を明確に書きます。たとえば「この WeChat 記事を読んで Markdown のみ返して」や「この PDF を取得して、引用しやすいよう見出しは維持して」のような指示が有効です。

ルーティングロジックをうまく使う

対象が GitHub のコンテンツなら、きれいにソース抽出したいときは raw ファイル URL か gh を優先してください。mp.weixin.qq.com では、まず proxy のカスケードが走り、WeChat 用スクリプトはフォールバックとして使われます。x.com や twitter.com では proxy ルートを使い、ローカル PDF には抽出ルートが適切です。このルーティングこそが、汎用的なブラウザ向けプロンプトに対する read usage の核となる強みです。

先に読み、保存は必要なときだけ行う

既定では、read はファイルとして保存せず、内容をインラインで表示します。Markdown の成果物が本当に必要なときだけ保存を指示し、その場合は ~/Downloads/{title}.md のようなタイトルベースのパスを使ってください。read をリサーチや自動化のフローに組み込むなら、次のステップが「表示のみ」を想定しているのか「保存済みファイル」を想定しているのかを先に確認しておくと安心です。

read スキル FAQ

read は単なる汎用の取得プロンプトですか？

いいえ。汎用プロンプトでもページ本文の取得は頼めますが、read にはソースに応じたルーティング、プライバシーを考慮した取得レベル、プラットフォーム固有スクリプトが含まれています。そのため、標準的なブラウザ抽出では取りこぼしやすいページでも失敗しにくくなります。

どんなときに read を使うべきではありませんか？

リポジトリ内にすでにある平文テキストで、Web 取得が不要な場合は使わないでください。また、元のテキストを取得する前にコメント、解釈、要約が欲しい場合にも適していません。

read は初心者向けですか？

はい。URL と明確な目的があれば使いやすいです。初心者がやりがちな失敗は、「このリンクを確認して」のように曖昧に指示して、Markdown 出力が欲しいのか、保存したいのか、後続の分析まで必要なのかを書かないことです。read の使い方はシンプルですが、入力は具体的である必要があります。

read は Workflow Automation に向いていますか？

はい。特に次の処理が、きれいなソーステキストを前提にしている場合に向いています。記事、PDF、各種プラットフォーム投稿を集めてから、タグ付け、要約、翻訳、アーカイブを行うような自動化パイプラインに合っています。ワークフローで決定的なソース取得が必要なら、read は実用的な先頭工程のスキルです。

read スキルを改善するには

ソース情報をより具体的に伝える

最も効果が大きい改善は、ソースを明確にすることです。正確な URL を含め、PDF かページかを示し、ログイン壁、中国系プラットフォーム、GitHub ファイルのような扱いにくい内容があるならその点も書いてください。ソースの説明が具体的であるほど、スキルが弱いルートを選ぶ可能性は下がります。

出力条件を先に伝える

Markdown のみが必要なら、そのように書いてください。保存したいなら、取得前にその旨を伝えます。引用しやすい形式が必要なら、見出しやリンクをできるだけ維持するよう依頼してください。read はソーステキストを出力するためのもので、解釈するためのものではないので、余計な説明よりもこうした条件のほうが重要です。

よくある失敗パターンに注意する

主な失敗は、誤ったルートを使うこと、ローカル専用取得で JavaScript が多いページを処理できると期待すること、ソースを取得する前に要約を求めることです。もう 1 つ多いのは、ブロックされているページや空のページを proxy パスに切り替えずに取得しようとするケースです。そうなったときは、長いプロンプトにするより、ソースの選び方を見直すほうがたいてい有効です。

取得から次の処理へつなげる

read のよい使い方は、まず取得し、そのあとで分析、抽出、比較のために 2 回目のプロンプトを出すことです。最初の出力がノイズ過多なら、ソースを絞るかプラットフォームを明示します。構造が足りないなら、別の取得方法や保存パスを指定してください。read usage では、同じ依頼を言い換えるより、小さなプロンプト変更のほうが結果を大きく改善することがよくあります。