publication-ready-article-editor
Skill1 starsChanged 4 months agoMITView on GitHub
Edit an existing article draft into accurate, coherent, publication-ready copy while preserving supported facts, intended meaning, and authorial voice. Use this skill when the user provides an existing article draft and wants article-level structural editing, substantive editing, line editing, copyediting, proofreading, or final publication QA. Do not use for writing an article from scratch, translation, summarization, title-only generation, isolated sentence or short-message rewriting, or keyword research.
In this repository9 other files it gives its agents.
The file
Show its rules and text
We split this skill into the rules it gives an agent
26 rules. About 0 are common, 23 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈23
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 18
Never fabricate facts, quotations, citations, links, names, dates, metrics, research, or test results.
- Distinctive: line 19
Do not silently strengthen a claim or convert attribution, inference, allegation, or opinion into verified fact.
- Distinctive: line 20
Treat source files as immutable unless the user explicitly authorizes in-place editing.
- Distinctive: line 21
Follow the host agent's tool, network, approval, and privacy policies.
- Distinctive: line 22
Keep internal reasoning, private data, and editorial process residue out of the article.
- Distinctive: line 43
Review first: When the user asks to analyze, discuss, or confirm structure before editing, return diagnosis and recommendations only.
- Distinctive: line 44
Diagnostic only: When the user explicitly asks only for evaluation or critique, explain strengths, risks, and prioritized improvements …
- Distinctive: line 45
Final review: When the article is already near completion, prioritize facts, terminology, repetition, transitions, language, formatting, …
- Distinctive: line 47
Do not produce a full edited article in Review first or Diagnostic only mode.
- Distinctive: line 52
Read the complete draft. Identify its core question, core job, central takeaway, reader journey, evidence, voice traits, and publication …
- Distinctive: line 62
Do not begin cosmetic polishing while a material structure or evidence problem remains unresolved.
- Distinctive: line 73
Proofread: check headings, lists, steps, links, captions, references, spacing, duplicated or missing words, and formatting.
- Distinctive: line 75
Delete repetition before compressing every paragraph evenly.
- Distinctive: line 80
Keep quotations exact except for clearly signaled, permissible omissions.
- Distinctive: line 81
Keep claim, source, and attribution close enough for readers to connect them.
- Distinctive: line 84
When current facts materially affect accuracy and the environment permits, verify them using appropriate sources.
- Distinctive: line 85
Do not browse when the user prohibits it.
- Very specific: line 87
Use [VERIFY] only as an internal editing marker.
- Distinctive: line 89
verify and correct the claim when possible.
- Distinctive: line 92
if the unresolved issue makes publication unsafe, label the result Draft — verification required, not publication-ready.
- Distinctive: line 99
Remove internal production residue from the final article unless the article itself discusses that material:
- Distinctive: line 110
Keep necessary reader-facing labels, code identifiers, technical versions, citations, and examples when they are genuine article content.
- Distinctive: line 115
Read references/editorial-checklist.md before delivery and resolve every applicable item.
- Very specific: line 123
no internal residue or [VERIFY] remains in the article.
- Distinctive: line 130
Follow the selected mode:
- Very specific: line 137
Write None under Verification required when no items remain.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Publication-Ready Article Editor
<!-- parity: purpose -->Purpose
Turn an existing draft into effective, publishable prose without inventing support or erasing the author's voice. Handle business and brand articles, industry analysis, technical explainers, tutorials and how-to guides, knowledge articles, opinion essays, newsletters, thought leadership, and professional blog posts.
<!-- parity: guardrails -->Non-negotiable guardrails
- Require an existing article draft. Do not expand this workflow into writing a new article from scratch.
- Preserve supported facts, intended meaning, material nuance, and the author's recognizable voice unless the brief explicitly changes them.
- Never fabricate facts, quotations, citations, links, names, dates, metrics, research, or test results.
- Do not silently strengthen a claim or convert attribution, inference, allegation, or opinion into verified fact.
- Treat source files as immutable unless the user explicitly authorizes in-place editing. Never delete, rename, move, or overwrite source material by default.
- Follow the host agent's tool, network, approval, and privacy policies. Obey an explicit no-browse or offline instruction.
- Keep internal reasoning, private data, and editorial process residue out of the article.
<!-- parity: intake -->Establish the editorial brief
Identify:
- article type, target reader, channel, core job, and desired reader action;
- requested editing depth, voice, locale, length, format, and deadline;
- claims, terminology, quotations, or passages that must remain unchanged;
- supplied sources, factual sensitivity, recency needs, and tool or network constraints;
- requested interaction mode.
Infer low-risk preferences from the draft and request. Ask only when a missing answer materially changes scope, safety, or output.
<!-- parity: mode-routing -->Route the editing mode
Choose the mode from the user's request:
- Direct edit — default. Complete the appropriate editing passes and return the revised article.
- Review first. When the user asks to analyze, discuss, or confirm structure before editing, return diagnosis and recommendations only. Wait for confirmation before rewriting the full article.
- Diagnostic only. When the user explicitly asks only for evaluation or critique, explain strengths, risks, and prioritized improvements without producing a replacement article.
- Final review. When the article is already near completion, prioritize facts, terminology, repetition, transitions, language, formatting, and publication residue. Avoid unnecessary structural or voice-level rewriting.
Do not produce a full edited article in Review first or Diagnostic only mode.
<!-- parity: diagnosis -->Diagnose before rewriting
Read the complete draft. Identify its core question, core job, central takeaway, reader journey, evidence, voice traits, and publication risks. Identify a controlling idea or thesis only when the article type calls for one.
Separate:
- structural problems from sentence-level problems;
- factual and attribution risk from style;
- intentional voice from accidental inconsistency;
- necessary depth from background, repetition, and digression;
- article content from internal production material.
Do not begin cosmetic polishing while a material structure or evidence problem remains unresolved.
<!-- parity: edit-workflow -->Edit in passes
Apply only the passes the selected mode and draft need:
- Structure and substance: align the opening, sequence, headings, examples, steps, and ending with the article's core job. Do not force every article into an argument-and-thesis shape.
- Evidence: align claims with inspected support; preserve attribution and qualification; resolve or isolate unsupported claims.
- Line edit: improve paragraph focus, flow, emphasis, rhythm, precision, and reader orientation while preserving voice.
- Copyedit: correct grammar, usage, punctuation, capitalization, spelling, terminology, and style consistency.
- Proofread: check headings, lists, steps, links, captions, references, spacing, duplicated or missing words, and formatting.
Delete repetition before compressing every paragraph evenly. Do not make sections artificially equal in length. Allow core information to develop fully; tighten background, transitions, and repeated explanation. Do not rewrite an already accurate, natural sentence merely to demonstrate editing effort.
<!-- parity: fact-handling -->Handle facts, sources, and [VERIFY]
- Keep quotations exact except for clearly signaled, permissible omissions.
- Keep claim, source, and attribution close enough for readers to connect them.
- Preserve qualifiers such as “may,” “estimated,” and “according to.”
- Distinguish verified, attributed, inferred, and unverified claims.
- When current facts materially affect accuracy and the environment permits, verify them using appropriate sources.
- Do not browse when the user prohibits it. When external access is unavailable, preserve uncertainty and report the item separately; never fill the gap by invention.
Use [VERIFY] only as an internal editing marker. Before delivery:
- verify and correct the claim when possible;
- otherwise reduce certainty conservatively when that remains accurate;
- otherwise remove the marker from the article and list the issue under Verification required;
- if the unresolved issue makes publication unsafe, label the result Draft — verification required, not publication-ready.
The final article must contain no [VERIFY] marker.
<!-- parity: publication-cleanup -->Perform publication cleanup
Remove internal production residue from the final article unless the article itself discusses that material:
- project or file numbers;
V1,V2, or other version labels;- draft, final, review, or approval status labels;
- revision notes, reviewer comments, confirmation notes, and internal TODOs;
- writing briefs, file paths, and internal communications;
- alternative-title lists and SEO keyword lists;
- GEO or SEO execution-strategy language;
- channel notes, publication strategy, and editorial notes.
Keep necessary reader-facing labels, code identifiers, technical versions, citations, and examples when they are genuine article content.
<!-- parity: qa -->Run final quality assurance
Read references/editorial-checklist.md before delivery and resolve every applicable item. Re-read the output as the target reader.
Confirm that:
- the opening sets an honest expectation and the article fulfills its core job;
- sequence and depth fit the article type;
- claim states remain accurate;
- authorial voice survives;
- no internal residue or
[VERIFY]remains in the article; - any unresolved issue is disclosed outside the article;
- the readiness label matches the remaining risk.
<!-- parity: delivery -->Deliver
Follow the selected mode:
- Direct edit: return the clean revised article, concise material editorial notes, Verification required, and material assumptions.
- Review first: return diagnosis, a proposed structure or prioritized recommendations, open questions, and the confirmation needed before full editing.
- Diagnostic only: return evaluation and prioritized recommendations only.
- Final review: return the lightly corrected final copy plus only material remaining risks or verification items.
Write None under Verification required when no items remain. Keep editorial notes separate from the article. Do not provide routine copyedit logs unless requested. When editing a file, preserve its format where practical and identify the new output path.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

