readwise-research
Skill2 starsChanged 2 months agoMITView on GitHub
Build a topic-centered research memo from the user's Readwise Reader documents and Readwise highlights. Use this whenever the user asks what they have already read, saved, highlighted, or been reading about a topic, wants a reading brief or research memo from their own library, wants evidence and tensions synthesized across Reader and Readwise, or wants topic-based shortlist/later/archive or tag suggestions. Use it even when the user does not say "Readwise" explicitly and instead says things like "I've been reading a lot about X" or "help me organize what I've read on Y." Prefer this skill over inbox-style triage when the task is organized around a theme, argument, project, or decision rather than chronology. Default to analysis first and only modify Reader after explicit user confirmation.
- Installs packages
In this repository34 other files it gives its agents.
- agent-native-redesignSkill
- assess-source-project-fitSkill
- brainstormingSkill
- coaching-engineSkill
- codex-skill-creatorSkill
- cubox-researchSkill
- dev-browserSkill
- diffusion-mapSkill
- exa-web-searchSkill
- executing-plansSkill
- general-skill-creatorSkill
- harnessSkill
- i-diagramSkill
- memosSkill
- merge-and-rebaseSkill
- paseo-relaySkill
- plan-coachingSkill
- plan-meSkill
- plan-reviewSkill
- problem-framingSkill
- prove-itSkill
- pruneSkill
- raise-ambitionSkill
- report-coachingSkill
- report-meSkill
- report-reviewSkill
- seeSkill
- shapeSkill
- subagent-driven-developmentSkill
- systematic-debuggingSkill
- test-driven-developmentSkill
- use-remote-skillSkill
- worktree-managerSkill
- writing-plansSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
44 rules. About 0 are common, 36 are distinctive, and 8 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈36
Distinctive · estimate
This author's own choices. Worth a look.
8
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 13
Use the local readwise CLI for all retrieval and write operations in this skill.
- Very specific: line 14
Use --json for any command whose output you will inspect programmatically.
- Very specific: line 15
If the CLI is missing, install it with npm install -g @readwise/cli.
- Very specific: line 16
If the CLI is present but unauthenticated, ask the user for a Readwise access token from https://readwise.io/access_token, then run …
- Distinctive: line 20
Treat this as a research task first and an organizing task second.
- Distinctive: line 21
Default to read-only analysis.
- Distinctive: line 22
If the user is asking about what they have read, saved, highlighted, or been reading lately, assume the source of truth is their Readwise …
- Distinctive: line 23
Do not start with web search or generic outside knowledge when the task is about the user's own reading history.
- Distinctive: line 24
Use documents as the primary units of analysis and highlights as evidence.
- Distinctive: line 25
If the user gives a theme but not a precise question, turn it into a working research question and say that you did so.
- Distinctive: line 26
If the request is too broad, narrow the scope and explain how you narrowed it.
- Very specific: line 27
If the user does not specify locations, search across new, later, shortlist, and archive.
- Distinctive: line 28
Prefer 3-6 deeply inspected documents over a long dump of shallow hits.
- Distinctive: line 32
Before searching, extract or infer:
- Distinctive: line 41
When the user asks vaguely, rewrite the request into a concrete working question such as:
- Distinctive: line 51
If the request is about the user's own reading, highlights, saved articles, or recent reading, begin with Readwise retrieval.
- Distinctive: line 52
Do not replace missing library evidence with web search by default.
- Distinctive: line 53
Only use external sources when Readwise results are clearly weak or empty, and label that material as an optional supplement rather than …
- Distinctive: line 54
If you do need outside context, first say that the library evidence was thin and explain why you are expanding beyond Readwise.
- Distinctive: line 58
If the prompt sounds like "I've been reading a lot about X", interpret it as a request about the user's library even if Readwise is not …
- Distinctive: line 59
If the prompt asks for tensions, disagreements, tradeoffs, or competing schools of thought, prioritize documents with highlights, notes, or …
- Distinctive: line 60
If the results are mostly tweets or small fragments, say that the evidence is fragmentary and point the user to the best full documents to …
- Distinctive: line 61
If the topic is broad, narrow by the user's real angle first, not by random keyword specificity.
- Very specific: line 67
Start with reader-search-documents because it gives the best candidate document set.
- Distinctive: line 77
Use extra filters only when they materially improve precision:
- Very specific: line 86
Run readwise-search-highlights on the same theme to surface supporting evidence, user notes, and memorable phrasing.
- Distinctive: line 93
Treat highlights as evidence, not as the final answer.
- Distinctive: line 110
look central enough to explain a recurring theme, not just mention it once
- Distinctive: line 128
Do not fetch every match in full.
- Distinctive: line 132
If the topic is too broad or returns too many weak matches:
- Distinctive: line 135
prefer the locations they care about most
- Distinctive: line 143
If Readwise retrieval returns little signal:
- Distinctive: line 148
Only then add a clearly labeled optional external supplement if the user still needs broader context.
- Distinctive: line 152
Always use this exact section structure and keep the level-2 headings verbatim:
- Distinctive: line 182
Always include every section, even if one section is thin.
- Distinctive: line 183
If there are no strong results, write that explicitly inside the relevant section instead of omitting the section.
- Distinctive: line 191
Prefer paraphrase over long quotation.
- Distinctive: line 193
If the results are weak, say so plainly and explain what broadened or narrowed search would help.
- Distinctive: line 194
Keep the memo skimmable and project-oriented.
- Very specific: line 202
add a project tag such as agent-evals or pricing
- Distinctive: line 213
Never call write actions until the user confirms.
- Distinctive: line 221
When the user confirms:
- Distinctive: line 225
Check the command result success flags.
- Distinctive: line 238
Do not use this skill when the job is primarily:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
readwise-research
Turn the user's Readwise library into a research desk. Find the most relevant documents and highlights for a topic, synthesize them into a structured memo, and only then propose any cleanup or organization actions.
Preflight
- Use the local
readwiseCLI for all retrieval and write operations in this skill. - Use
--jsonfor any command whose output you will inspect programmatically. - If the CLI is missing, install it with
npm install -g @readwise/cli. - If the CLI is present but unauthenticated, ask the user for a Readwise access token from
https://readwise.io/access_token, then runreadwise login-with-token <token>.
Core Defaults
- Treat this as a research task first and an organizing task second.
- Default to read-only analysis. Never mutate Reader unless the user explicitly confirms the proposed actions.
- If the user is asking about what they have read, saved, highlighted, or been reading lately, assume the source of truth is their Readwise library and start there.
- Do not start with web search or generic outside knowledge when the task is about the user's own reading history.
- Use documents as the primary units of analysis and highlights as evidence.
- If the user gives a theme but not a precise question, turn it into a working research question and say that you did so.
- If the request is too broad, narrow the scope and explain how you narrowed it.
- If the user does not specify locations, search across
new,later,shortlist, andarchive. Includefeedonly if they explicitly ask for it. - Prefer 3-6 deeply inspected documents over a long dump of shallow hits.
Interpret the Request
Before searching, extract or infer:
topic: the central theme, question, or projectscope: what angle matters most, such as arguments, tactics, disagreements, definitions, or exampleslocations: optional Reader locations to includetime_window: optional recency constrainttags: optional tag filteraction_mode: whether the user wants analysis only, suggestions, or confirmed mutations
When the user asks vaguely, rewrite the request into a concrete working question such as:
- "What have you already read about AI agent evaluation, and what are the main recurring ideas and disagreements?"
- "What does your reading library suggest about startup pricing, and which pieces deserve to be shortlisted for later reuse?"
- "You've been reading a lot about evergreen notes. What themes, disagreements, and tag ideas show up in your own library?"
Source-of-Truth Rule
For this skill, the user's Readwise/Reader library is the primary evidence base.
- If the request is about the user's own reading, highlights, saved articles, or recent reading, begin with Readwise retrieval.
- Do not replace missing library evidence with web search by default.
- Only use external sources when Readwise results are clearly weak or empty, and label that material as an optional supplement rather than part of the library-backed memo.
- If you do need outside context, first say that the library evidence was thin and explain why you are expanding beyond Readwise.
Retrieval Decision Rules
- If the prompt sounds like "I've been reading a lot about X", interpret it as a request about the user's library even if Readwise is not named.
- If the prompt asks for tensions, disagreements, tradeoffs, or competing schools of thought, prioritize documents with highlights, notes, or multiple matching evidence points over isolated snippets.
- If the results are mostly tweets or small fragments, say that the evidence is fragmentary and point the user to the best full documents to read next.
- If the topic is broad, narrow by the user's real angle first, not by random keyword specificity.
Retrieval Workflow
1. Search documents first
Start with reader-search-documents because it gives the best candidate document set.
CLI examples:
readwise reader-search-documents --query "ai agents evaluation" --limit 10 --json
readwise reader-search-documents --query "startup pricing" --location-in shortlist,archive --tags-in strategy --limit 10 --json
readwise reader-search-documents --query "evergreen notes" --published-date-gte 2025-01-01 --limit 10 --jsonUse extra filters only when they materially improve precision:
--location-infor explicit location constraints--tags-inor--tags-searchwhen the user names project tags--author-searchwhen the user cares about a person--published-date-*when the user asks for recent or older material
2. Search highlights in parallel
Run readwise-search-highlights on the same theme to surface supporting evidence, user notes, and memorable phrasing.
readwise readwise-search-highlights --vector-search-term "ai agents evaluation" --limit 15 --json
readwise readwise-search-highlights --vector-search-term "evergreen notes" --full-text-queries '[{"field_name":"document_title","search_term":"zettelkasten"}]' --limit 15 --jsonTreat highlights as evidence, not as the final answer. They help you find:
- phrases worth citing
- documents with dense signal
- places where the user left highlight notes
- competing framings or repeated concepts
3. Reconcile and rank candidates
Merge both search streams into a single candidate set.
Rank documents higher when they:
- appear in both document search and highlight search
- have multiple matching highlight snippets
- include non-empty highlight notes or document notes
- clearly match the user's scope or tag constraints
- look central enough to explain a recurring theme, not just mention it once
Highlight search results may not include a Reader document ID. When that happens, reconcile them back to documents using title, author, tags, or URL before fetching full document details.
4. Fetch deeper context for the strongest candidates
For the top few candidates, fetch:
- full content via
reader-get-document-details - highlights via
reader-get-document-highlights
CLI examples:
readwise reader-get-document-details --document-id <id> --json
readwise reader-get-document-highlights --document-id <id> --jsonDo not fetch every match in full. Stop once you have enough evidence to write a grounded memo.
5. Narrow if the set is too broad
If the topic is too broad or returns too many weak matches:
- tighten the query to the user's actual angle
- prefer the locations they care about most
- focus on annotated documents over unannotated ones
- reduce to the strongest recurring subthemes
State the narrowing choice briefly in the memo so the user can see your reasoning.
6. Weak-results fallback
If Readwise retrieval returns little signal:
- Say explicitly that the library evidence is thin.
- Explain how you narrowed or broadened the search.
- Offer the best next Readwise reading candidates anyway if any exist.
- Only then add a clearly labeled optional external supplement if the user still needs broader context.
Memo Structure
Always use this exact section structure and keep the level-2 headings verbatim:
# Topic Memo: <topic>
## Research Question
<one short paragraph>
## Most Relevant Sources
- <Title> by <Author> (<location>): why it matters
- <Title> by <Author> (<location>): why it matters
## Key Ideas and Evidence
- <idea or claim>
Evidence: <documents, highlights, or notes that support it>
- <idea or claim>
Evidence: <documents, highlights, or notes that support it>
## Tensions / Disagreements / Gaps
- <where sources disagree, where the evidence is thin, or what still needs reading>
## What To Read Next
- <best documents to read or reread and why>
## Suggested Reader Actions
- <specific shortlist, later, archive, or tagging suggestion>Additional memo rules:
- Always include every section, even if one section is thin.
- If there are no strong results, write that explicitly inside the relevant section instead of omitting the section.
Most Relevant Sourcesmay be bullets or a markdown table, but it must name the source title and author or source identity.Suggested Reader Actionsmust read like recommendations, not completed actions.
Writing Rules
- Synthesize. Do not dump raw search results.
- Name sources explicitly so the user can act on them.
- Prefer paraphrase over long quotation. Use short snippets only when the wording itself matters.
- Surface disagreements, uncertainty, and missing evidence instead of forcing a neat consensus.
- If the results are weak, say so plainly and explain what broadened or narrowed search would help.
- Keep the memo skimmable and project-oriented.
Suggested Reader Actions
End with concrete actions tied to the memo, for example:
- shortlist 2-3 high-value documents for reuse
- move low-signal or duplicate reads to archive
- add a project tag such as
agent-evalsorpricing - mark a batch as seen when the user is clearly done scanning it
Frame them as proposals first. Example:
- "Shortlist these two because they contain reusable frameworks."
- "Archive these three because they only repeat ideas already covered elsewhere."
- "Add the tag
evergreen-notesto this cluster so future searches are cleaner."
Mutation Policy
Never call write actions until the user confirms.
Write actions include:
reader-add-tags-to-documentreader-move-documentsreader-bulk-edit-document-metadata
When the user confirms:
- Restate the exact actions you are about to take.
- Batch document IDs into as few calls as practical.
- Check the command result success flags.
- Report what succeeded and what did not.
CLI examples:
readwise reader-add-tags-to-document --document-id <id> --tag-names "agent-evals,research"
readwise reader-move-documents --document-ids <id1>,<id2> --location shortlist
readwise reader-bulk-edit-document-metadata --documents '[{"document_id":"<id>","seen":true}]'When Not To Use This Skill
Do not use this skill when the job is primarily:
- a chronological inbox walkthrough
- a feed catch-up pass with minimal synthesis
- a quiz or memory drill
- a personal reading recap across time
Those are better handled by dedicated Readwise skills such as triage, feed catchup, quiz, or recap.
Example Requests
- "Help me整理我在 Readwise 里关于 AI agents evaluation 的阅读材料,做一份 memo,并建议哪些值得 shortlist。"
- "我最近读了很多关于个人知识管理和 evergreen notes 的东西,帮我提炼核心分歧,再给我一个标签整理建议。"
- "围绕 startup pricing 找我读过的文章和 highlights,做一页 briefing;不要直接改库,先给我建议。"
- "我最近存了不少关于 B2B SaaS pricing 的东西,帮我从我的阅读里总结 recurring ideas 和 gaps。"
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

