agentleFS
Nightflight6Nightflight6/open-agent-skills/skills/en/publication-ready-article-editor/SKILL.md

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.

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
  1. Distinctive:

    Never fabricate facts, quotations, citations, links, names, dates, metrics, research, or test results.

    line 18
  2. Distinctive:

    Do not silently strengthen a claim or convert attribution, inference, allegation, or opinion into verified fact.

    line 19
  3. Distinctive:

    Treat source files as immutable unless the user explicitly authorizes in-place editing.

    line 20
  4. Distinctive:

    Follow the host agent's tool, network, approval, and privacy policies.

    line 21
  5. Distinctive:

    Keep internal reasoning, private data, and editorial process residue out of the article.

    line 22
  6. Distinctive:

    Review first: When the user asks to analyze, discuss, or confirm structure before editing, return diagnosis and recommendations only.

    line 43
  7. Distinctive:

    Diagnostic only: When the user explicitly asks only for evaluation or critique, explain strengths, risks, and prioritized improvements …

    line 44
  8. Distinctive:

    Final review: When the article is already near completion, prioritize facts, terminology, repetition, transitions, language, formatting, …

    line 45
  9. Distinctive:

    Do not produce a full edited article in Review first or Diagnostic only mode.

    line 47
  10. Distinctive:

    Read the complete draft. Identify its core question, core job, central takeaway, reader journey, evidence, voice traits, and publication …

    line 52
  11. Distinctive:

    Do not begin cosmetic polishing while a material structure or evidence problem remains unresolved.

    line 62
  12. Distinctive:

    Proofread: check headings, lists, steps, links, captions, references, spacing, duplicated or missing words, and formatting.

    line 73
  13. Distinctive:

    Delete repetition before compressing every paragraph evenly.

    line 75
  14. Distinctive:

    Keep quotations exact except for clearly signaled, permissible omissions.

    line 80
  15. Distinctive:

    Keep claim, source, and attribution close enough for readers to connect them.

    line 81
  16. Distinctive:

    When current facts materially affect accuracy and the environment permits, verify them using appropriate sources.

    line 84
  17. Distinctive:

    Do not browse when the user prohibits it.

    line 85
  18. Very specific:

    Use [VERIFY] only as an internal editing marker.

    line 87
  19. Distinctive:

    verify and correct the claim when possible.

    line 89
  20. Distinctive:

    if the unresolved issue makes publication unsafe, label the result Draft — verification required, not publication-ready.

    line 92
  21. Distinctive:

    Remove internal production residue from the final article unless the article itself discusses that material:

    line 99
  22. Distinctive:

    Keep necessary reader-facing labels, code identifiers, technical versions, citations, and examples when they are genuine article content.

    line 110
  23. Distinctive:

    Read references/editorial-checklist.md before delivery and resolve every applicable item.

    line 115
  24. Very specific:

    no internal residue or [VERIFY] remains in the article.

    line 123
  25. Distinctive:

    Follow the selected mode:

    line 130
  26. Very specific:

    Write None under Verification required when no items remain.

    line 137

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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:

  1. Direct edit — default. Complete the appropriate editing passes and return the revised article.
  2. 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.
  3. Diagnostic only. When the user explicitly asks only for evaluation or critique, explain strengths, risks, and prioritized improvements without producing a replacement article.
  4. 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:

  1. 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.
  2. Evidence: align claims with inspected support; preserve attribution and qualification; resolve or isolate unsupported claims.
  3. Line edit: improve paragraph focus, flow, emphasis, rhythm, precision, and reader orientation while preserving voice.
  4. Copyedit: correct grammar, usage, punctuation, capitalization, spelling, terminology, and style consistency.
  5. 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:

  1. verify and correct the claim when possible;
  2. otherwise reduce certainty conservatively when that remains accurate;
  3. otherwise remove the marker from the article and list the issue under Verification required;
  4. 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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.