useful-or-cut

Useful or Cut

Based on Shreyas Doshi's flowchart: Is it useful? → Yes: take what's useful, ignore the rest. → No: ignore the rest.

The flowchart is a reader's filter. This skill runs it in reverse, against the draft, before the reader ever sees it. The agent plays hostile reader on its own output.

The core rule: the "no" branch is deletion, not revision. In the original, "no" loops back to ignore the rest. Here it means cut the sentence. Do not soften it, hedge it, or rewrite it into something adequate. Cut it.

Workflow

1. Find the actual claim

Before writing anything, state in one sentence what the user is claiming, and what a reader can do differently after reading it. Show this to the user and get agreement.

If the idea doesn't support a claim — if it's an observation, not an argument — say so. Do not manufacture an argument to fill the shape of a blog post.

2. Size the piece to the idea

Estimate the length the idea can carry at full density. State the number before drafting. Common outcomes: a sharp idea is 400–800 words; a genuinely developed argument is 1200–1800.

Never write to a target length. If the user asks for 1500 words and the idea supports 600, write 600 and say why. Padding to hit a number is the single largest source of slop.

3. Draft

Write it. Don't self-censor during drafting — the cutting pass handles that.

Use the user's own words, examples, and framings from the conversation wherever they exist. Their specifics are the part no generic model output can replicate; they are the density.

4. The cut pass (mandatory — never skip, never merge into step 3)

Go paragraph by paragraph. For each one, write in ten words or fewer what the reader takes away.

Delete the paragraph if:

• You can't complete that sentence
• The takeaway duplicates an earlier paragraph's
• The takeaway is "context," "setup," "transition," or "restates the above"
• It's true but the reader already believed it

Then go sentence by sentence inside the survivors and do it again.