The second that your draft is “done,” you’re probably overeager for some fast feedback. But your colleagues generally won’t drop everything to read/review your work immediately. And they are likely too busy – or too kind – to point out every little thing that could be improved.
LLMs are always available to provide feedback (tokens permitting) and will review countless revisions without a single sigh or eyeroll. With careful prompting, they can perform a rigorous review and point out issues that human reviewers might miss.1 They’re particularly good at noticing things that are obvious to you and your team, but not so clear to an outside reader.2 And they won’t hold a grudge if you totally ignore their suggestions.
This article shares a series of prompts for getting objective feedback from an LLM. They’re designed for tech blogs (and based on tips from Writing for Developers) but can likely be adapted for other purposes.
Usage tips:
Preface the prompt(s) with an intro explaining:
Your goal for this article
Your target reader
Your preference for analytical, critical feedback rather than sycophancy
Use as many or as few as you want. Some writers want to work through relentless criticism before they publish. Others just want to fix any glaring issues and ship it.
If you’re short on time, focus on the triage prompt for some quick wins.
Beta testers got better results by iterating over the prompts one by one. But feel free to bundle them up into a skill, a workflow, whatever works best for your process.
Please ignore (or laugh at, or argue with…) any feedback that you disagree with!
What are the 3-5 most impactful things I can do to optimize this blog post before I publish it?
Review how this blog post is achieving its goal ([why you wrote it]). Share what’s working, then a high-level assessment of what could be improved to better achieve that goal.
Is it immediately clear who this article is for and why the reader should care about it?
Does the title set any false expectations? Does it highlight the most interesting terms/technologies from the body? Is it interesting enough to earn a click from [target reader]?
Would the opening intrigue [target reader]? Does the beginning of the article tell the reader what to expect and why my perspective on this topic is interesting?
How well does the blog post deliver what the title and introduction promise?
Does the article offer readers exclusive information or perspectives that they can’t get from an LLM, documentation, or an existing article?
Create a structured reverse outline of this blog post so I can confirm whether my thoughts are coming across.
Summarize this blog post so I can confirm whether my thoughts are coming across.
Does the ending give the reader something to do, try, or contemplate? Or does it just stop?
BONUS: If you went through the “let the LLM interview you” prep process, ask it to evaluate your draft versus your interview responses, point by point (copy paste the summary).
Does this blog post provide sufficient technical depth for [target reader]? What additional explanations, examples, etc., are needed?
Are there any claims, opinions, superlatives, or other subjective statements in this blog post that are not properly supported with evidence? List all that you find and suggest ways to support them.
Perform a technical review of this blog post. Is anything incorrect, incomplete, or misleading?
Review every code sample, command, and technical snippet. Are they complete enough to be useful? Are they accurate for the language/framework?
Are there any technical terms that [target reader] might not know (and should be defined or linked)?
Are there any logical gaps in this article?
What questions might [target reader] have after reading this blog post?
Is the complete article intriguing to [target reader]? What parts would they be most (and least) interested in?
Are there any parts that are not essential to my goal of [goal]?
Does this post have a clear narrative arc? Where might the reader lose momentum?
Does it flow logically from one section to the next? Where might the reader get confused or lost?
If the reader just scans the title, headings, and subheadings, will they get a good idea of what this article actually covers?
Does my voice and experience come through in this article? Does the article share a human’s point of view, or does it read like documentation or an LLM response?
What big blocks of text might be difficult for the reader to process?
Name 3 or fewer places where I might want to add subheadings, tables, bulleted lists, visualizations, etc., to improve readability. If it’s fine as is, say so.
Identify the most complex sentences, including those that are extra long, use a complex structure that impacts readability, or are otherwise clunky. Explain why each is confusing. Explain how to clarify it. (Draw on the Paramedic Method as appropriate, but do not assume the user knows what this is. Do not mention the Paramedic Method; just explain its concepts where relevant. Explain your clarification strategies clearly and simply to someone who is not a language geek.) For each complex sentence: 1. Explain the problem. 2. Create a similar example with old-school Bugs Bunny and/or ACME Corporation themes. Keep the same structure, but try to replace as many of my words as possible. 3. Suggest at least 3 revision options using your Bugs Bunny example. Before responding, check your revision options against the full list at https://tropes.fyi/tropes-md and rephrase as needed to avoid those LLM writing patterns.
Identify sentences that sound like corporate comms or like they were created by a committee. For each identified sentence: 1. Explain the problem. 2. Create a similar example with old-school Bugs Bunny / ACME Corporation themes. Keep the same structure, but try to replace as many of my words as possible. 3. Suggest at least 3 revision options using your Bugs Bunny example. Before responding, check your revision options against the full list at https://tropes.fyi/tropes-md and rephrase as needed to avoid those LLM writing patterns.
TIP: You can catch a lot of clunky/awkward sentences by just reading the post out loud. Actually vocalize the words, even in a whisper. Be as dramatic as you can bear, emphasize the prepositions, and try to complete each sentence in one breath. :)
Review this blog post for localization and global translation blockers. Focus ONLY on egregious problems – critical blockers where a non-native English speaker who is active in the tech community would completely misunderstand the meaning.
Review this blog post [URL] for disability accessibility (a11y) compliance. Output a concise list of the issues found. Explain exactly who they exclude, why, and how to fix them.
Review this blog post from the perspective of a typical Hacker News reader. First, share a summary of how it might be received and why. Then, list some comments readers are likely to make about it.
Review this blog post from the perspective of [your competitor | your boss | some influencer …]
Review this blog post against the recommendations in [On Writing Well, Zinsser | Writing for Developers, Sarna and Dunlop | Style: Lessons in Clarity and Grace, Williams | another writing book you like]
TIP: Share relevant parts of the book as context.
