A useful critique comes from a request that supplies what the model cannot see: who the piece is for, what it is meant to do, and which draft this is. Then ask for located problems rather than a verdict, keep each request to one question, and do not mention that the work is yours.
Flow diagram of 5 steps: Set the context in one short paragraph, Test comprehension before asking for opinion, Ask one narrow, located question, Make it argue the other side, Revise, then re-ask in a fresh conversation.
A draft handed over on its own arrives with no indication of who it is for, what it is trying to do, or how finished it is. The model still has to produce a critique, so it invents a reader — generally educated, mildly interested, with no particular stake — and evaluates the piece against that. Most disappointing AI feedback is not a failure of the model. It is an accurate review of your draft as read by a person who does not exist.
The fix is unglamorous: state three things before you paste anything. Who is going to read this and what they already know. What the piece is supposed to achieve — inform, persuade, get somebody to turn up on a Saturday, make a case to a committee that has already said no once. And which draft this is, because the useful note on a first draft is that the argument runs out halfway, while the useful note on a fifth is that a term shifts meaning between section one and section three. Ask for both at once and you get neither properly.
Constraints matter as much as goals, and people leave them out because saying them aloud feels like making excuses. If the piece has to fit 400 words, cannot name the organisation involved, has to be readable by somebody who has never heard of the subject, or has to stay under a minute read aloud, say so. Without that, a good share of the notes will be suggestions to add material you have no room for, and you will spend the read discarding them rather than using them.
Note the two or three defects you already think are there, and do not include them in the opening request. If the model finds them unprompted, the notes are tracking something real and the rest of them are worth more attention. If it misses all three, you have learned how much weight the pass deserves before you start acting on it. Volunteering your suspicions up front destroys that test, because a model asked whether a specific problem exists will nearly always agree that it does.
Requests fall into two families. One asks the model to judge: is this good, is it ready, rate it out of ten. The other asks it to point at something in the text: which paragraph is weakest, where does a reader lose the thread, which sentence would you cut first. The first family produces answers that cannot be checked and cannot be acted on. The second produces a claim about a specific location, which you can go and look at, and then either accept or dismiss on your own judgement.
Forced choice is the strongest single move available. A request for the weakest paragraph, singular, cannot be satisfied with even-handed praise — something has to be nominated. Asking for the three weakest is already worse, because the third will be padding included to fill the shape of the request. The same holds for asking which claim is least supported, or which sentence a hostile reader would quote back at you. Making the model choose is what stops a reply spreading itself thinly across everything.
What different requests actually return
| What you ask | What comes back | Why |
|---|---|---|
| "What do you think of this?" | A summary, some praise, three generic suggestions | Nothing in the request narrows the task, so it does the safest available thing |
| "Rate this out of ten" | A number near seven, then notes bent to justify it | The score arrives first and the reasoning gets fitted to it afterwards |
| "Does the opening work?" | Usually yes, with supporting reasons | A yes-or-no question about your own draft invites agreement |
| "Which paragraph is weakest, and why?" | One paragraph, named, with a reason you can check | Forced choice makes even-handed praise unavailable |
| "Summarise the argument back to me" | A summary that either matches what you meant or does not | Tests comprehension rather than opinion, so the answer is checkable |
| "Make the case that this should not be published" | The objections a sympathetic read never surfaces | Assigning a position removes the pull towards approval |
Some requests fail in ways that are invisible from the reply, because the reply still looks like feedback. The most common is the leading question. "Is the second section too long?" and "How does the second section handle pace?" are not the same request — the first names a defect and asks for confirmation, and confirmation is generally what comes back. If you have a hypothesis, test it by asking the neutral version and seeing whether your suspicion turns up on its own.
Saying the work is yours has a smaller version of the same effect. Feedback on "my draft" comes back softened, prefaced with what is working well, and reluctant to nominate anything as bad. The same text pasted flatly, or presented as something you have been asked to assess, tends to be read more coldly. This is not a trick played on the model so much as declining to hand it a reason to be encouraging.
Then there is the instruction to be brutal. Asking for savage or ruthless honesty does change the output, but it changes the register rather than the accuracy: the same observations arrive with more contempt, plus a few manufactured complaints added to meet the tone you requested. Harshness reads as rigour and is not evidence of it. What raises quality is narrowing the question, not raising the volume.
A request covering structure, clarity, tone, evidence and the title returns a paragraph on each, and every one of them is shallower than a single question would have produced. The reply is long, so it reads as thorough. Splitting the same five concerns across five short requests costs a couple of minutes and returns notes specific enough to act on, because the model is no longer budgeting one answer across five competing topics.
People often paste an outline or a summary of what they are planning and ask what could be improved. That returns feedback on the outline, which is almost always encouraging, because an outline has none of the problems that live in actual sentences. If the piece is too long to paste at once, review it in sections and say which section this is and what preceded it, rather than asking the model to work from a paraphrase of your own writing.
None of these requests is worth much in isolation. What makes the difference is running them in an order where each pass checks something the last one could not, and stopping at the point where the notes stop surprising you.
Audience, purpose, constraints, which draft this is. Four sentences is enough, and it is the highest-return thing you will do, because every later request in the conversation inherits it.
Ask it to summarise the argument and say what the piece wants the reader to do. If that summary is wrong, stop there — the problem is in the draft, and no amount of stylistic notes will repair a piece whose point does not survive a careful read.
Which paragraph is weakest and why. Where is the reader holding something in their head that has not been explained yet. Which claim would need a source before you could publish it. One per request, each answered fully.
Ask for the strongest case against publishing the piece as it stands. This surfaces the objections a helpful read is structured to avoid, and it is the pass that most often turns up something you had not already thought of.
A model that has already praised your draft reads the next version generously, because the earlier exchange is still in front of it. Start clean, paste only the revised text, and check whether the note you believe you fixed comes back anyway.
There is a point where each pass returns rephrased versions of the last, and continuing past it produces churn rather than improvement — small smoothing edits that make the piece more even and slightly less like you wrote it. Two consecutive passes that surface nothing new is a reasonable signal that the mechanical part is finished and the remaining questions, about whether the thing is true and whether it matters, need a person.
Everything above assumes you are typing requests into a general-purpose tool. Submitting an idea here works differently, and the difference is worth stating plainly: you do not write the prompt. The form takes a title, a category and format, and a description, and the automated review runs on those. There is no follow-up question, no second pass, and no way to tell it what you were going for. The description is the entire input.
That makes the description carry the job the context paragraph does everywhere else. The form asks what the idea is about, why it matters and who would benefit, and those three are not decoration — an idea described with no audience will attract a note about clarity or engagement that is really a note about the description. The review reads for clarity, originality, social impact, engagement and feasibility, so a submission that never says who this is for, or what would physically have to be made, has left two of those five with nothing to work from.
The form also offers an optional AI Description Helper, which rewrites what you have typed into something more broadcast-ready. That is a generator rather than a reviewer, and it is better treated as a draft to edit than a replacement to accept. Take it unchanged and the thing being read, scored and voted on is no longer quite the idea you had — usually smoother, usually more general, and missing the specific detail that made it worth submitting.
Two honest limits. Kind Channel is new, the community is small and nothing has aired, so there is no body of submissions to draw patterns from; nothing here comes from measuring which descriptions score well on this platform, because there is not yet enough to measure. And the automated notes decide nothing on their own — community votes determine what gets made. A description written to satisfy the review rather than to interest the people voting is optimising for the wrong reader.
Three things it cannot work out from the text: who the piece is for and what they already know, what it is meant to achieve, and which draft this is. Add the constraints that feel like excuses — a word limit, a subject you are not allowed to name, a reader with no background in the topic. Without them the model invents a generic reader and reviews the draft against that, which is where most vague and unusable feedback comes from.
It changes the tone rather than the accuracy. Asking for savage or ruthless criticism returns the same underlying observations delivered with more contempt, often with a few manufactured complaints added to match the register you asked for. Harshness reads as rigour without being evidence of it. What genuinely improves a critique is narrowing the question — asking which single paragraph is weakest, rather than requesting an unsparing assessment of the whole piece.
Because the answer is divided between them. A request covering structure, tone, evidence and title returns a paragraph on each, and four shallow paragraphs look substantial while carrying less than one specific answer would. Length in the reply is easily mistaken for depth. Splitting those concerns into separate requests costs a few extra minutes and returns notes precise enough to act on, since nothing is being rationed across competing topics.
Not as the first request. A score tends to be produced before the reasoning, and the notes that follow are fitted to justify the number rather than derived from the text, which makes the most detailed part of the reply the least trustworthy part. If you want a rating, ask for the critique first and the score afterwards, in a separate request. Ratings work better for tracking one piece across revisions than for judging it once.