Most People Use AI to Write Faster
Most people use AI to write faster. Type a prompt, get a draft, edit, ship. The thinking happens silently while you skim the output to see if it works.
That's the wrong use of the tool.
What I do instead: I argue with Claude before any writing starts. I built a skill called sparring-partner that pressure-tests my thinking before a single word of draft gets produced. Raw ideas in, critique back, rinse and repeat until the idea is sharp. Only then does the writing begin.
The result: drafts come out faster because the thinking is already done. The drafts are better because they're built on ideas that survived the critique.
This post is what the skill does and how to build your own.
The Workflow
Step one: I share raw, unstructured thoughts. A confused argument, a decision I'm working out, a position I want to take but don't fully trust yet. The kind of thing that goes in a Slack DM to a smart friend.
Step two: Claude, running the sparring-partner skill, returns a critique. What's sharp, what's weak, what's missing. Specific claims that don't hold up. Counterarguments I haven't considered. Lazy reasoning I was getting away with in my head.
Step three: I respond. Defend, concede, refine, sometimes scrap entirely. Rinse and repeat.
Step four: Once the idea has held up under three or four rounds of pushback, only then do I ask for drafts. The skill produces three distinctly different versions with tradeoffs explained. I pick one. The writing starts.
That's the loop. Total time before any writing: maybe twenty minutes. Total time saved on rewriting later: every minute I would have spent trying to figure out what I wanted to say while typing.
A Concrete Example
Last week I was sharpening a technical case study before sending it to a client lead. The argument: a parallel-fetch architecture was the right call for a multi-API orchestration build. Strong claim, weak setup.
Sparring-partner came back: "Right choice for what? You haven't named the constraint that made sequential calls non-viable. If sub-second responsiveness is the bar, say that up front. If it's not, the case is softer than you think."
Had to admit the constraint was implicit. I'd been assuming the reader would infer it. The version I sent named sub-second responsiveness explicitly in the first paragraph and built the rest of the case around it. Same architecture, sharper argument.
The lead's first response back was "this hooks fast." Closest thing to a compliment in a year of those reviews.
The One Rule That Makes It Work
The whole skill rests on one constraint: it's not allowed to rewrite my idea without permission.
Default Claude behavior is helpful. You share half-formed thinking, it produces a polished version. Feels great. But the "polished version" is Claude's interpretation of what you might have meant, not the thing you'd say if you'd thought harder. The polish hides the gaps you should have seen. By the time you notice, you've already invested in editing the wrong draft.
The sparring-partner skill blocks that path. It can't draft, summarize, or "improve" the input. It can only critique. Until I explicitly say "OK, give me drafts now," it pushes back on the idea, never on the language.
That single rule is what makes the skill compound. The first round of pushback teaches Claude what I care about (specifics, counterarguments, audiences). The fifth round catches gaps the first round didn't. By the tenth round, on the tenth piece I write, the critique has gotten sharp in a way generic "improve this" prompts never do.
What the Skill Looks Like
The skill is a SKILL.md file in my Cowork workspace. The shape is roughly:
- A trigger: when I share raw ideas, treat them as input for critique, not as a prompt to expand or rewrite.
- A protocol: identify what's sharp, what's weak, what's missing. Ask one clarifying question if a gap matters. Wait for my response before continuing.
- A list of forbidden moves: don't rewrite, don't draft, don't produce three versions, don't skip ahead to "here's what I'd say instead."
- An exit condition: only when I explicitly ask for drafts does the skill switch modes and produce three distinctly different versions with tradeoffs.
That's it. Maybe forty lines of markdown, in its own SKILL.md file. Resist the urge to dump it inline into your CLAUDE.md or AGENTS.md. Those should stay lightweight, just a directory that tells the agent which skills exist. The skill content lives in its own file. Older guides used to recommend loading context directly into CLAUDE.md, but updated research showed models often perform worse with bloated spec files. Keep them thin and let skills live separately.
Build your own version and tune the forbidden-moves list to whatever Claude does that you don't want it to do. Mine includes "don't end with a motivational summary" because I noticed Claude likes to wrap critiques with "you've got the makings of a strong argument here," which is a polite lie that tells me nothing.
Why This Belongs in a Course on Building With AI
The reason I keep coming back to this skill: it's the clearest example of a workflow where the AI's default behavior is wrong, and a small set of rules fixes it.
Most people who try to build with AI hit some version of this problem. The model is too eager to help. It produces output before you've finished thinking. The output is usually fine in isolation and wrong for what you're trying to do. The fix isn't a smarter model. It's a clearer set of rules about when the model is allowed to do what.
That's what Skills are for. Plan mode is for. The whole pattern is the same: write the guardrails down where the model will read them, kept in the right place (skills get their own files; lightweight CLAUDE.md or AGENTS.md just lists them). Then the model can stop guessing about your intent and do the part of the work it's good at.
Sparring before drafting is one example. Plan-mode red-teaming before code is another. Schema-enforced output (the trick that made Stellar work) is another. They're all the same move: write the rules down so the model can stop guessing.
Think Harder, Not Faster
Most people use AI to write faster. Better is to think harder before you write at all. The skill is what makes that practical.