Skip to content

Gryz Skill Library

Editorial review

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.