القائمة
Review a draft for big-picture issues—argument, structure, stakes, and payoff. Invoke with /dev-edit after drafting or with any draft the user provides.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Reads your writing through the meanest, least-charitable lens. Challenges every claim, questions every assumption, pokes holes in the logic. Use for later drafts when you want hard feedback.
Run a multi-round deliberation between reviewers. Unlike /panel (which synthesizes), /debate has reviewers respond to each other's arguments across rounds until tensions resolve or reach acknowledged stalemate.
Checks writing for clarity and accessibility. Flags jargon without explanation, hand-wavy process descriptions, and skipped steps. Ensures content is specific enough for experts AND clear enough for newcomers. Use when reviewing technical or process-heavy writing.
Scan any Every draft for recurring editorial-review failures: clarity and evidence gaps, argument problems, mechanics red flags, second-order AI tells, and, for Working Overtime only, column-specific voice tics and structural throat-clearing. Use when reviewing or polishing Every writing before submission. Reports findings with line-level diagnoses and suggested fixes. Pairs with ai-check and every-style.
Cuts ruthlessly. Flags every adjective, adverb, and unnecessary word. Demands you kill your darlings.
Reviews for suspense and tension. Where's the bomb under the table? What does the reader know that someone doesn't?
| name | dev-edit |
| description | Review a draft for big-picture issues—argument, structure, stakes, and payoff. Invoke with /dev-edit after drafting or with any draft the user provides. |
| user_invocable | true |
Review a draft for big-picture issues: argument, structure, stakes, and payoff. Focus on whether the piece works, not whether the sentences are polished.
Questions to consider (not all apply to every piece):
| Area | Questions |
|---|---|
| Structure | Does each section earn its place? Does the order make sense? |
| Argument | Is it logically clear and supported? Any holes? |
| Evidence | What backs each major claim? Personal experience? A linked study? A specific example? Where is the support thin or missing? |
| Outsider read | If a reader who doesn't know the writer and doesn't read Every picked this up cold, what would they push back on? What would feel like in-group shorthand? |
| Opening | Does the hook work? Is the thesis clear? Is there a promise? |
| Stakes | Why should the reader care? Why does the writer care? |
| Payoff | Does the piece deliver on what it promises? |
Use judgment. A personal essay doesn't need argument scrutiny. A how-to doesn't need stakes analysis. Focus on what matters for this piece.
Two diagnostic tests for whether the piece holds together. Run both when the structure feels off — or proactively for any piece with subheads.
For each subsection: write a one-sentence summary of what it argues. Then re-read the subsection. Anything not in service of that one sentence — cut it.
When invoked by the agent:
This test catches: orphaned good lines that belong elsewhere, padding from earlier drafts, two arguments tangled inside one subsection.
If someone stopped the writer in a hallway, could they explain the piece in 20 seconds? Now compare that pitch to the thesis/promise as stated in the intro.
When invoked by the agent:
If the pitch and the intro don't match, one of them is wrong. Usually the intro drifted during revision and needs to catch up to what the piece became.
For each major claim, ask: what is this backed by?
| Support type | Verdict |
|---|---|
| Personal experience the writer lived through | Strong — let it stand |
| A linked study, dataset, or named source | Strong — let it stand |
| An expert quote or named practitioner | Strong — let it stand |
| A specific named example (company, person, moment) | Strong — let it stand |
| "Studies show…" / "experts agree…" / "many people say…" without specifics | Weak — flag |
| Only the writer's authority, when the writer isn't established on this specific thing | Weak — flag |
| Nothing — assertion floats free | Weak — flag |
It's fine to write about something the writer isn't an expert in. It's not fine to make claims without support and rely on confident tone to carry them. Flag floating claims explicitly — the writer can add evidence, soften the claim, or remove it.
## Developmental Edit Report
### Opening
🔴 **Critical:** [Issue]
[Why it matters]
🟡 **Consider:** [Issue]
[Explanation]
### [Section Name]
🟢 **Minor:** [Issue]
[Explanation]
---
Where would you like to start?
Severity:
## Quick Dev Edit
**Working well:** [2-3 things]
**Needs attention:**
1. [Main issue + why]
2. [Second issue + why]
**Overall:** [Ready for line edit / Needs another pass / Major restructure needed]
Use quick assessment for shorter pieces, time pressure, or when invoked as part of a composition.
After the report:
Don't force resolution of every issue. The writer decides what matters.
When invoked programmatically:
[Skill-specific lessons will be added here as they're captured]