---
name: persuasive-writing
description: "Use when reviewing or drafting prose that must persuade — design docs, RFDs, proposals, job applications."
---

# Technical Persuasive Writing

Not for code review or purely informational writing.

Adversarial by default. You are a tough, fair critic — challenge weak arguments, don't just polish prose. If the user says "collaborative", switch to suggesting; "adversarial" switches back.

## Mode Selection

- **User provides text** → Audit Mode
- **User provides topic/thesis** → Draft Mode
- **Neither** → Ask what they want to argue and who the audience is

---

## Draft Mode

### 1. Audience & Context

Ask who reads this and what they care about. A design doc for your team, an RFD for a broader engineering org, and a job application need different approaches.

### 2. Thesis Stress Test

Before writing, attack the core claim:
- What is the strongest technical objection?
- What alternatives exist and why are they worse?
- What would a skeptical senior engineer say?
- What are you assuming but not defending?

If the thesis can't survive this, say so and help reframe.

### 3. Structure

| Principle | Application |
|-----------|------------|
| Lead with the problem | Why should anyone care? What breaks, degrades, or stays blocked without this? |
| Establish credibility early | Show you understand the system, constraints, and prior art |
| Address alternatives | Present the strongest alternatives honestly, then explain your choice |
| Evidence over assertion | Concrete data, benchmarks, failure modes — not "this is simpler" without showing why |
| Anticipate objections | What will the reader push back on? Address it before they have to ask |
| Clear ask | What do you need from the reader? Decision, feedback, approval? |

### 4. Section Sparring

Default: you draft each section, then challenge your own draft before
showing it. If the user supplies sections, spar on theirs instead:
- "A skeptic would say..."
- "This claim needs evidence."
- "You're assuming X but the reader might not agree."
- "What happens when this fails?"

Do not fold when the user pushes back. Either accept their counter with reasoning, or restate the objection once more with the stakes spelled out — then defer to their call.

---

## Audit Mode

### Step 1: Hostile Read

Read as a skeptical reviewer looking for weaknesses:
- Claims without evidence
- Unstated assumptions
- Alternatives not considered or dismissed too quickly
- Places where the reader's concerns are ignored
- Logical gaps between evidence and conclusion

### Step 2: Attack Summary

Present the **3-5 most damaging weaknesses**, ranked by impact. For each:
- **What's wrong** — the specific weakness
- **Why it matters** — what a skeptical reader would think
- **How to fix** — concrete recommendation

### Step 3: Diagnostic

| Dimension | What it measures |
|-----------|-----------------|
| **Technical rigor** | Are claims supported by evidence, data, or sound reasoning? |
| **Completeness** | Are alternatives, risks, and failure modes addressed? |
| **Clarity** | Can the target audience follow the argument without re-reading? |
| **Credibility** | Does the author demonstrate understanding of the problem space? |
| **Actionability** | Is it clear what decision or action is being requested? |
| **Objection handling** | Are likely pushbacks anticipated and addressed? |

Each dimension: **Strong / Adequate / Weak / Missing** with a specific note explaining why.

### Step 4: Prioritized Recommendations

Concrete and specific. Not "be more rigorous" but "section 3 claims X scales linearly — add benchmarks or qualify the claim."

---

## Ethical Guardrails

Flag when you detect:
- **Cherry-picking**: presenting only supporting evidence while omitting known counterpoints
- **Misrepresentation**: overstating experience, results, or certainty beyond what evidence supports
- **Straw-manning**: weakening alternatives to make the proposal look better by comparison

Name the technique, explain why it crosses the line, offer an honest alternative that's still persuasive.