read

read skill 개요

read가 하는 일

read skill은 URL이나 PDF를 가져와 깔끔한 Markdown으로 돌려주므로, 브라우저에서 일일이 복사하지 않고도 웹 콘텐츠를 검토, 인용, 출처 표기, 재사용할 수 있습니다. 이 skill은 read 워크플로우에 맞춰 설계되었습니다. 링크를 받아 읽기 쉬운 텍스트로 바꾸고, 나중에 따로 요청하지 않는 한 분석은 하지 않습니다.

이 skill에 가장 잘 맞는 경우

실제로 해야 할 일이 “이 페이지를 읽어줘” 또는 “이 문서를 추출해줘”에 가깝다면 read skill이 적합합니다. 특히 유료벽이 있는 페이지, JS가 많은 사이트, PDF, X/Twitter 링크, 그리고 WeChat과 Feishu 같은 중국권 플랫폼에서 강점이 있습니다. 요약, 번역, 비교, 저장 전에 안정적으로 콘텐츠를 수집해야 하는 Workflow Automation에도 잘 맞습니다.

무엇이 다른가

가장 큰 차별점은 라우팅입니다. read는 하나의 범용 프롬프트를 억지로 적용하는 대신, 소스에 따라 가져오는 방식을 선택합니다. GitHub, PDF URL, WeChat 기사, 로컬 파일은 종종 서로 다른 처리 방식이 필요하기 때문에 이 점이 중요합니다. 또한 개인정보 보호 단계와 기본값으로는 분석을 하지 않는 정책을 강조해, 후속 자동화에서 더 예측 가능하게 동작합니다.

read skill 사용 방법

read skill 설치하기

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를 살펴보세요.

skill에 맞는 입력을 주기

read skill은 단일하고 명확한 대상에 가장 잘 동작합니다. 즉, URL 하나, PDF 링크 하나, 또는 로컬 PDF 경로 하나가 가장 좋습니다. 출력 품질을 원한다면 “이걸 읽어줘”보다 소스와 원하는 결과를 함께 적어 주세요. 예를 들면 “이 WeChat 기사를 읽고 Markdown만 반환해줘” 또는 “이 PDF를 가져오고 인용할 수 있도록 제목 구조를 유지해줘”처럼 쓰는 편이 좋습니다.

라우팅 로직을 제대로 활용하기

대상이 GitHub 콘텐츠라면, 깔끔한 소스 추출이 필요할 때 raw 파일 URL이나 gh를 우선하는 것이 좋습니다. mp.weixin.qq.com은 먼저 프록시 체인을 거치고, 그다음 WeChat 스크립트를 대체 경로로 사용합니다. x.com이나 twitter.com은 프록시 경로를 쓰는 편이 좋고, 로컬 PDF는 추출 경로가 맞습니다. 이런 라우팅은 일반적인 브라우저 프롬프트보다 read usage의 핵심 장점입니다.

먼저 읽고, 그다음 저장 여부를 결정하기

기본적으로 read는 파일로 저장하지 않고 내용을 화면에 표시합니다. Markdown 산출물이 꼭 필요할 때만 저장을 요청하고, 그때는 ~/Downloads/{title}.md처럼 제목 기반 경로를 쓰세요. read를 리서치나 자동화 흐름에 연결한다면, 다음 단계가 표시용 출력인지 저장된 파일인지 먼저 맞춰 두는 것이 좋습니다.

read skill FAQ

read는 그냥 범용 가져오기 프롬프트인가요?

아닙니다. 범용 프롬프트도 페이지 텍스트를 요청할 수는 있지만, read에는 소스 기반 라우팅, 개인정보를 고려한 가져오기 단계, 플랫폼별 스크립트가 포함되어 있습니다. 그래서 일반적인 브라우저 추출이 잘 처리하지 못하는 페이지에서도 실패 확률을 낮춰 줍니다.

언제 read를 쓰지 말아야 하나요?

이미 repo 안에 있는 일반 텍스트처럼 웹에서 가져올 필요가 없는 콘텐츠에는 read를 쓰지 마세요. 또한 원문을 실제로 가져오기 전에 해설, 해석, 요약을 먼저 원할 때도 적합하지 않습니다.

read는 초보자도 쓰기 쉬운가요?

URL와 명확한 목표만 있으면 그렇습니다. 초보자가 가장 많이 하는 실수는 “이 링크 확인해줘”처럼 막연하게 요청하면서 Markdown 출력이 필요한지, 저장 파일이 필요한지, 후속 분석이 필요한지 밝히지 않는 것입니다. read 가이드는 단순하지만, 입력은 구체적이어야 합니다.

read는 Workflow Automation에 잘 맞나요?

네, 특히 다음 단계가 정제된 원문에 의존할 때 강합니다. 기사, PDF, 플랫폼 게시물을 수집한 뒤 태깅, 요약, 번역, 보관으로 넘기는 자동화 파이프라인에 잘 맞습니다. 워크플로우가 결정적인 소스 캡처를 필요로 한다면 read는 실용적인 프런트엔드 skill입니다.

read skill 개선 방법

소스 맥락을 더 정확하게 주기

가장 효과적인 입력 개선은 소스 명확성입니다. 정확한 URL을 포함하고, PDF인지 페이지인지 밝혀 주며, 로그인 벽, 중국권 플랫폼, GitHub 파일처럼 까다로운 소스인지도 적어 주세요. 소스를 더 정확하게 설명할수록 skill이 약한 경로를 선택할 가능성이 줄어듭니다.

출력 제약을 처음부터 명시하기

Markdown만 필요하면 그렇게 말하세요. 내용을 저장해야 한다면 가져오기 전에 미리 밝혀 주세요. 인용에 적합한 형식이 필요하면 제목과 링크를 가능한 한 유지해 달라고 요청하세요. read는 원문을 출력하도록 설계된 skill이므로, 이런 제약은 추가 설명보다 더 중요합니다.

흔한 실패 모드를 점검하기

주요 실패 원인은 잘못된 경로를 쓰는 것, 로컬 전용 가져오기로 JS가 많은 페이지를 처리하려는 것, 또는 원문이 캡처되기 전에 read에게 요약을 시키는 것입니다. 또 다른 흔한 문제는 차단되었거나 비어 있는 페이지를 프록시 경로로 바꾸지 않고 그대로 가져오려는 경우입니다. 이런 경우 대개 필요한 것은 더 긴 프롬프트가 아니라 더 나은 소스 선택입니다.

가져오기에서 후속 작업으로 이어가기

좋은 read 워크플로우는 먼저 가져오고, 그다음 두 번째 프롬프트로 분석, 추출, 비교를 요청하는 방식입니다. 첫 결과가 너무 지저분하면 소스를 다듬거나 플랫폼을 더 구체적으로 지정하세요. 구조가 빠져 있다면 다른 가져오기 방법이나 저장 경로를 요청하면 됩니다. read usage에서는 같은 요청을 돌려 말하는 것보다 작은 프롬프트 수정이 더 큰 개선을 주는 경우가 많습니다.