القائمة
Adversarial review/drafting of persuasive technical prose.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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
