Menu
Adversarial review/drafting of persuasive technical prose.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
| name | persuasive-writing |
| description | Adversarial review/drafting of persuasive technical prose. |
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.
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.
Before writing, attack the core claim:
If the thesis can't survive this, say so and help reframe.
| 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? |
Default: you draft each section, then challenge your own draft before showing it. If the user supplies sections, spar on theirs instead:
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.
Read as a skeptical reviewer looking for weaknesses:
Present the 3-5 most damaging weaknesses, ranked by impact. For each:
| 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.
Concrete and specific. Not "be more rigorous" but "section 3 claims X scales linearly — add benchmarks or qualify the claim."
Flag when you detect:
Name the technique, explain why it crosses the line, offer an honest alternative that's still persuasive.
Use when executing a multi-step plan and each implementation step should be delegated to subagents and independently reviewed.
Use when reviewing local changes — the working-copy diff, a branch, a commit, or a GitHub PR by number — with fresh reviewer subagents that return structured findings.
Use when a test failure, regression, exception, hang, wrong result, or unexpected behavior needs diagnosis — gathers evidence, traces the relevant path, and verifies the cause before recommending a fix.
Resolve jj (Jujutsu) conflicts. Use when jj log/status shows conflicted revisions, a rebase/squash/abandon reports 'new conflicts appeared', or files contain jj conflict markers.
Use when you want to work in an isolated jj working copy — parallel task, experimental scratch, subagent with its own tree. jj's equivalent of git worktrees: creating a workspace, working inside it from anywhere, and cleaning up without losing history.
Find things to improve in the current project
