From readwise
Drafts long-form book reviews from Readwise Reader highlights of target book and user's library, extracting claims to synthesize summary, critique, and original arguments.
npx claudepluginhub readwiseio/readwise-skills --plugin readwiseThis skill uses the workspace's default tool permissions.
Draft a long-form book review from a user's Reader highlights — not just the target book,
Analyzes Readwise highlights, tags, and Reader documents to surface one surprising insight about reading patterns and interests.
Guides systematic book reading with knowledge compilation from chapters, mastery testing, spaced repetition reviews, querying, and cross-book comparisons. Builds Markdown wiki under project root.
Queries Readwise for highlights, quotes, annotations, full document text, and article content. Adds highlights or tagged documents to notebooks. Auto-activates on search or fetch requests.
Share bugs, ideas, or general feedback.
Draft a long-form book review from a user's Reader highlights — not just the target book, but pulling in related highlights from their entire library to build original arguments.
The goal is a review that's more interesting than the book itself: summary + critique + original ideas, where the original ideas come from connecting the book to everything else the user has read.
Check if Readwise MCP tools are available (e.g. mcp__readwise__reader_list_documents). If they are, use them throughout. If not, use the equivalent readwise CLI commands instead (e.g. readwise list, readwise read <id>, readwise highlights <id>, readwise search <query>). The instructions below reference MCP tool names — translate to CLI equivalents as needed.
Check for persona file. Read reader_persona.md in the current working directory if it exists. Use it to understand the user's interests, reading goals, and voice — this shapes the review's framing, what connections to prioritize, and what the user is likely to care about. If no persona file exists, proceed without it and ask the user about their purpose for reading the book if it's not obvious from their highlights.
Parse the argument as a book title or search term.
/book-review Merchant Kings
/book-review 7 Powers
Search Reader for the target book:
mcp__readwise__reader_search_documents(query="[book title]", category_in=["epub", "pdf"])
If no results, broaden to all categories. If multiple matches, list them and ask the user to pick.
mcp__readwise__reader_get_document_highlights(document_id="[book_id]")
Read every highlight. Count them. If fewer than 10, warn the user — may not be enough material for a substantive review. Ask whether to proceed or wait.
mcp__readwise__reader_get_document_details(document_id="[book_id]")
Pull title, author, summary, cover image. You'll need these for the final output.
Process every highlight into an atomic claim. This is the step that turns "I highlighted this paragraph" into structured, searchable research material.
For each highlight:
Claim quality standards:
Good claims are specific, searchable facts or assertions:
Bad claims are vague or generic:
After processing all highlights, review the full list. Reject and rewrite any that are:
Store the claims as a working list grouped by theme. This becomes your outline.
This is what makes the review more than a summary. For each major theme cluster from Phase 2, search the user's full Reader library for related content.
For each theme cluster (aim for 3-6 themes):
mcp__readwise__reader_search_documents(query="[theme keywords]", limit=20)
Pull highlights from the top hits:
mcp__readwise__reader_get_document_highlights(document_id="[related_doc_id]")
You're looking for:
mcp__readwise__reader_search_documents(query="[book author name]")
Check if the user has read other work by the same author. Prior context enriches the review.
For each relevant highlight from a related document, extract a claim the same way as Phase 2. Tag it with its source document so you can cite it properly.
Result: You should now have:
Fill gaps that the user's library doesn't cover. Keep this focused — the library research is the core, web research is supplemental.
A great book review has three elements (per the ACX Book Review Contest wisdom):
The original ideas come from Phase 3 — the related highlights from the user's library. This is the whole point of the skill.
[Opening: What the book is and why it matters — a specific fact or scene, not a vague hook.
Leave a %% TODO %% for the user to add how they found the book and why they read it
if context wasn't already in the document note.]
## [Thematic section 1 — informative header, not clever]
[Summarize the book's argument on this theme. Use block quotes from the book's highlights.
Then EXPAND: bring in related material from the user's other reading. This is where the
review becomes more than a summary — it's synthesis.]
> "Block quote from the book" — Author, *Book Title*
[The user also highlighted something in [Related Document] that complicates/supports this:
weave it in naturally. Cite the source with a URL link to the original source, NOT the Reader link.]
## [Thematic section 2]
[Same pattern: book's argument → user's related reading → synthesis.
Each section should advance an argument, not just list facts.]
## [Thematic section 3+]
[Keep going. Organize by theme, not by chapter. Every section should have at least
one connection to something outside the book itself.]
## What the Book Gets Wrong (or Misses)
[Honest critique. Use the user's other reading as evidence where it contradicts
or complicates the book. This is where the related-document research pays off most.]
## Further Reading
- Description with [embedded link](url) for sources worth exploring that were NOT
linked above but are related to the core themes of this review.
You are drafting FOR the user, not impersonating them:
%% TODO %%.%% TODO: [what the user should add] %% for personal hooks. These signal where the user needs to fill in their own experience.Err long. 2,000-10,000 words for a substantial book. The ACX contest data shows longer reviews with genuine insight outperform shorter ones. Depth > brevity, as long as every paragraph earns its place. If the user's highlights are sparse (10-20), aim for 1,000-2,000 instead.
(url) or (link)Separate pass. Do not skip. Do not combine with Phase 5.
Re-read the full draft and fix every instance of:
Never use these. Find concrete alternatives.
| Banned | Use instead |
|---|---|
| Additionally | "Also" or restructure |
| Crucial / Pivotal / Key (adj) | Be specific about why it matters |
| Delve / Delve into | "examine", "look at", or just start |
| Enhance / Fostering | Be specific about what improved |
| Landscape (abstract) | Name the actual domain |
| Tapestry (figurative) | Name the actual pattern |
| Underscore / Highlight (verb) | State the point directly |
| Showcase | "shows", "demonstrates" |
| Vibrant / Rich (figurative) | Be specific |
| Testament / Enduring | Just state the fact |
| Groundbreaking / Renowned | Be specific about what's notable |
| Garner | "get", "earn", "attract" |
| Intricate / Intricacies | "complex" or describe the actual complexity |
| Interplay | "relationship", "tension", or describe it |
| Serves as / Stands as | Use "is" |
| Nestled / In the heart of | Just name the location |
| Pattern | Fix |
|---|---|
| "Not just X, it's Y" / "Not A, but B" | State Y directly |
| Rule of three ("innovation, inspiration, and insights") | Use the number of items the content needs |
| "-ing" analysis ("highlighting the importance of...") | State the importance directly |
| "From X to Y" (false ranges) | List the actual items |
| Synonym cycling (protagonist/hero/central figure) | Pick one term, reuse it |
| "Despite challenges, the future looks bright" | State the actual situation |
| "Exciting times lie ahead" | End with a specific fact |
| "X wasn't Y. It was Z." (dramatic reveal) | Collapse to single positive statement |
| "The detail that stopped me in my tracks" | Start with the fact |
| "genuinely revolutionary" | Use a specific descriptor |
| Any melodramatic one-liner meant to sound profound | Delete it |
| "I'd forgotten I knew" | Delete. Never frame knowledge as rediscovered. |
Create the review as a new document in Reader:
mcp__readwise__reader_create_document(
url="https://reader-review.internal/[slug]-[ISO-timestamp]",
title="[book title] — Review Draft",
author="Ghostreader",
category="article",
summary="Review draft based on [N] highlights from [Book Title] and [M] related documents",
html="[converted HTML of the review]",
notes="DRAFT for editing. Based on highlights from: [list source document titles]"
)
Return the document URL to the user.
The whole point of Phase 3 (library search) is that the review should contain ideas the author of the book never had. The user's reading history is a unique lens:
This is how you get "original ideas" — the third element that separates a competent review from an impressive one. The user's library IS the original thinking.