EnglishBlitz

TOEIC Link Writing — Prompt Deconstruction: Parsing the Task Requirements Before You Draft

The fastest way to lose points on a writing task is to answer a slightly different question than the one asked. A prompt that says "compare and recommend" is not answered by a response that only compares; a prompt that asks for two reasons is not satisfied by one developed reason. This guide shows how to deconstruct a writing prompt into its task verb, its required components, and its constraints before writing a single sentence, so the response is scored against the question it was actually built to answer. It includes the common mis-reads that quietly cap scores and a four-week drill for making prompt parsing automatic.

EnglishBlitz Editorial Team·

TOEIC Link Writing — Prompt Deconstruction: Parsing the Task Requirements Before You Draft

There is a category of lost points that has nothing to do with English ability and everything to do with reading. The candidate writes fluent, well-structured, grammatically clean prose — and answers a question the prompt did not ask. The prompt asked them to recommend one of two options; they wrote a balanced comparison and never recommended. The prompt asked for two supporting reasons; they developed one reason beautifully and stopped. In both cases the writing is strong and the score is capped, because task response — did the answer do what the task required — is scored independently of how well it was written.

This failure is entirely preventable, and preventing it costs about ninety seconds. Before drafting, you deconstruct the prompt into its parts and confirm what a complete answer must contain. This guide shows how to run that deconstruction, what the parts are, and how to make the habit automatic so it survives the pressure of the clock.

Why a good answer to the wrong question scores low

A rater evaluates a response against the task, not against an abstract standard of good writing. If the task requires a recommendation and the response offers none, the response has not completed the task, and no amount of polish on the comparison recovers those points. This is why the strongest-sounding responses sometimes score in the middle band: fluency masks the fact that a required component is missing, and the writer, having produced a lot of confident prose, never notices the gap.

The defense is to treat the prompt as a specification with required fields, and to refuse to draft until you can name every field. A response built from a parsed specification answers the question asked. A response built from a quick skim answers the question remembered — and memory, under time pressure, drops exactly the components the prompt added to make the task specific.

The three things to extract from every prompt

Deconstruct every prompt into three parts before drafting.

The task verb. Find the word that says what to do: compare, recommend, describe, explain, agree or disagree, propose, respond. The task verb determines the shape of the whole response. Compare wants both sides weighed; recommend wants a choice made and defended; agree or disagree wants a stance taken, not a survey of both positions. Circle the task verb first, because everything else serves it. Getting the shape right is what lets the thesis statement and topic sentence engineering do its job — a thesis can only forecast a shape the task verb actually asked for.

The required components. Find the countable requirements: two reasons, one example, both advantages and disadvantages, a specific situation from your experience. These are the fields a complete answer must fill. A prompt that says "give two reasons" has made the number a scored requirement; one reason, however well developed, leaves a field empty. List the components explicitly so the draft has a checklist to satisfy.

The constraints. Find the boundaries: the audience (a colleague, a manager, a customer), the register (a formal email, an opinion essay), the perspective (your own experience, a general argument), and any content limits. These do not change what you argue but they change how it must be framed, and a response in the wrong register for the stated audience reads as not having understood the task.

The common mis-reads that cap scores

A handful of prompt mis-reads recur often enough to name.

Answering "compare" as if it were "recommend," or the reverse. Some prompts want a weighing with no verdict; some want a verdict. Writing the wrong one leaves either a missing recommendation or an unwanted, unsupported one.

Dropping the second required component. When a prompt asks for two of something, the second is the one that gets lost — the writer develops the first at length, runs low on time, and never delivers the second. Parsing the components up front reserves room for both.

Ignoring the audience or register cue. A prompt that specifies an email to a manager has specified a register; a response in essay register for that prompt has not met the task, even if the argument is sound.

Over-reading a simple prompt. The opposite error: inventing requirements the prompt never stated and spending time satisfying them. Parse what is there, not what might be there.

Every one of these is a reading error, and every one is caught by naming the task verb, the components, and the constraints before drafting. The parsed prompt then feeds directly into the body plan — each required component becomes a paragraph with its own controlling sentence, which is where topic sentence and paragraph unity control turns the specification into structure.

The four-week drill

Week one — highlight the three parts. On ten past prompts, mark the task verb, the required components, and the constraints without writing any response. Build the reflex of seeing a prompt as three fields rather than a paragraph of instructions.

Week two — write the specification line. For each prompt, write a single line before drafting: "Task: recommend one option. Components: a choice + two reasons + one example. Constraints: formal email to a manager." Draft only after the line is written.

Week three — self-check against the specification. After drafting, return to the specification line and confirm every field was filled. Mark any missing component. This trains the revision-time check that catches a dropped requirement while there is still time to add it.

Week four — parse under the clock. Do full timed responses with the specification line written in the first ninety seconds and checked at the end. The endpoint is a writer who never drafts against a remembered prompt, only against a parsed one — and therefore never answers the wrong question.