Review a draft document for structure, clarity, completeness, and audience fit, then return prioritized findings the author can act on — not a line-by-line copy edit. Use when the user asks to "review this draft", "what's missing from this doc", or "is this ready to publish/send". Do NOT use for a quick grammar/typo pass on a short piece of text — use clear-writing for that; this skill is for a whole document's structure and argument.
v1 · authored by Gryz · writing
Use it from any MCP-connected agent
Connect Gryz MCP, then call list_skills and get_skill({ name: "editorial-review" }). Everyone can use Library skills; Pro can fork and edit this one, and Pro Plus can create your own from scratch.
# Editorial review
Review a whole document's structure, clarity, completeness, and audience fit —
not a copy edit of individual sentences.
## When to use
- "Review this draft", "what's missing from this doc", "is this ready to
publish/send", or the user pastes a PRD, blog post, or announcement and
asks for feedback before it goes out.
## Do NOT use for
- A quick grammar or wording pass on a short piece of text — use
clear-writing for that. This skill evaluates the whole document's shape,
not individual sentences.
## Review checklist
1. **Structure.** Does the document have a clear opening (what is this and
why does it matter), a body that supports that opening, and a close (what
happens next / what's the ask)? Flag sections that are out of order or
missing.
2. **Clarity of the core claim.** Can you state the document's single main
point in one sentence after reading it once? If not, say so — that's the
biggest finding, ahead of any wording issue.
3. **Completeness for the audience.** What would a first-time reader need
that isn't here — context, a definition, a link, a number? What's here
that a first-time reader doesn't need?
4. **Audience fit.** Is the tone, technical depth, and length appropriate for
who will actually read this (exec skim vs. engineer deep-read vs. public
post)?
5. **Evidence and specificity.** Are claims backed by a number, example, or
link, or are they asserted without support?
## How to respond
Return **prioritized findings**, most important first — not a scrolling list
of every nit. Structure the response as:
- **Biggest issue** (if any) — the one thing that would most improve the
document.
- **Structural findings** — ordering, missing sections, redundant sections.
- **Content gaps** — what's missing for the stated audience.
- **Minor** — small wording or formatting notes, grouped at the end, kept
short.
Never rewrite the whole document unprompted — point at what to fix and let
the author decide how.
## Examples
**Input:** a 400-word "Q3 roadmap" doc that opens with implementation
details and only mentions the goal in the last paragraph.
**Response:**
- Biggest issue: the goal is buried. Move the last paragraph (why this
roadmap exists) to the top — readers need the "why" before the "what."
- Structural: the "risks" section has no owner or mitigation, just a list of
worries.
- Content gap: no mention of what's explicitly out of scope, which the exec
audience will ask about first.
- Minor: "Q3" is used before it's defined as a fiscal quarter.