agentleFS
flexim-ioflexim-io/seo-writers/skills/audit-paragraph-structure/SKILL.md

audit-paragraph-structure

Skill1 starsChanged 3 months agoApache-2.0View on GitHub

Audit and rewrite paragraph, list, and table structure in articles, documentation, essays, and technical prose. Use as a required independent gate after edit-article, or whenever every paragraph must be checked for one governing thought, scanability, informative openings, sufficient development, and clean endings, while lists remain linked, parallel, ordered, grouped, and non-repetitive. Preserve approved meaning, claims, sources, and author voice. Do not use for article strategy, new research, or publishing.

The file

We split this skill into the rules it gives an agent

12 rules. About 0 are common, 8 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈8

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Check the text at the level of semantic blocks so a reader can scan the material, select the relevant part, and understand each paragraph …

    line 8
  2. Very specific:

    Use the text, Article Brief and explicit corrections, claim permissions and sources, editorial policy and channel rules, and mode: audit, …

    line 29
  3. Distinctive:

    Read the shared audit coverage contract for report detail, input identities, complete coverage, and independent provenance.

    line 31
  4. Very specific:

    If unspecified, “check the paragraphs” means audit.

    line 52
  5. Distinctive:

    After the topic, provide only the support the reader needs: mechanism, evidence, example, condition, limitation, or consequence.

    line 68
  6. Distinctive:

    Use no word-count limit. Judge weight relative to neighboring blocks, idea complexity, and medium.

    line 80
  7. Distinctive:

    Do not turn unrelated paragraphs into a list or create decorative groups.

    line 97
  8. Distinctive:

    Read only headings, first sentences, lists, and tables.

    line 115
  9. Very specific:

    Run the relevant gates for every L-ID and T-ID, including lead, parallelism, order, grouping, and repetition.

    line 123
  10. Very specific:

    Keep passing blocks unchanged.

    line 127
  11. Distinctive:

    After repairs, reread headings, first sentences, lists, and tables.

    line 131
  12. Distinctive:

    Treat a short paragraph as incomplete by length alone.

    line 192

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

Audit paragraph structure

Check the text at the level of semantic blocks so a reader can scan the material, select the relevant part, and understand each paragraph without searching adjacent blocks for its subject.

This is a narrow independent gate after edit-article. The Article Brief, macrostructure, and claim permissions already exist. It does not replace draft-article, edit-article, or visual-storytelling, and it never changes shared reader Markdown directly.

Responsibility

audit-paragraph-structure:

  • inventories every prose paragraph and proves complete coverage;
  • checks one governing task, opening, development, and ending per paragraph;
  • splits mixed thoughts and joins dependent fragments;
  • audits scanability through first sentences;
  • checks list linkage, parallelism, order, grouping, and repetition;
  • checks tables as repeated-field structures;
  • rewrites only failing units;
  • returns corrected copy and an external audit manifest.

It does not change the Brief, reader, promise, intent, or product role; rebuild the full article; invent evidence; verify claims without an allowed source; add visuals; publish; or force uniform length and three-part form on every paragraph.

Inputs and priority

Use the text, Article Brief and explicit corrections, claim permissions and sources, editorial policy and channel rules, and mode: audit, rewrite, or automatic.

Read the shared audit coverage contract for report detail, input identities, complete coverage, and independent provenance. This reference is a reporting contract, not another auditor's context.

Priority: explicit user correction, approved Brief, verified source, editorial policy, current text, model assumption.

Units

  • prose paragraph: continuous prose between blank lines;
  • list lead: sentence or paragraph that establishes the list's grammar and meaning;
  • list item: one homogeneous unit;
  • table: repeated fields checked both as a whole and by row;
  • code block: reproducible material, not a paragraph; audit only its surrounding explanation;
  • heading: navigation, not a paragraph; verify that the first block fulfills it.

Assign stable external IDs: P001 for paragraphs, L001 for lists, and T001 for tables. Never insert IDs into reader Markdown or invent new internal markers.

Modes

  • audit: inspect every unit and return a manifest without rewriting.
  • rewrite: inspect every unit, repair only failures, and return copy plus manifest.
  • automatic: ask no questions, run the full process, and return ready or blocked.

If unspecified, “check the paragraphs” means audit; “check and fix” means rewrite.

Paragraph gates

1. One governing thought

State the paragraph topic in one short sentence. Every sentence must develop it, provide evidence, expose a limit, or derive an action.

Split when the subject materially changes, an independent claim appears, an exception needs its own argument, or an aside hides a thematic break. Merge adjacent paragraphs when the second has no independent topic and only continues an unfinished sentence, argument, or enumeration.

2. Informative opening

Imagine the reader sees only the first sentence. Prefer an opening that names the paragraph's subject and decision. Pronouns and conjunctions are not mechanically forbidden, but repair this, that, it, however, or but when the reader must search backward to find the topic. A transition may open the paragraph when it also names the new subject.

3. Development

After the topic, provide only the support the reader needs: mechanism, evidence, example, condition, limitation, or consequence. Remove a restated thesis. Move a useful sentence that belongs to another paragraph.

4. Ending

For a complex technical or abstract paragraph, test:

topic or claim → development → conclusion or action

The final sentence should answer “what follows?” without repeating the opening. Do not add a ceremonial ending to a complete one- or two-sentence paragraph.

5. Visual weight and rhythm

Use no word-count limit. Judge weight relative to neighboring blocks, idea complexity, and medium. Split a heavy paragraph only at a real thought boundary. Do not create random short fragments or make every paragraph equal.

6. Section fit

Confirm that the paragraph fulfills the nearest heading and does not duplicate information already gathered elsewhere. Consolidate a scattered topic or explicitly separate distinct aspects.

List gates

Check six properties:

  1. homogeneity: every item answers one question and belongs to one category;
  2. lead linkage: the lead plus any item forms one grammatical and semantic whole;
  3. parallelism: items serve the same syntactic role and, where helpful, begin with the same part of speech and key term;
  4. sequence: order follows action, time, priority, dependency, or another explicit logic;
  5. grouping: a long list uses categories that help the reader act;
  6. repetition: common wording moves to the lead or subheading unless repetition preserves clarity.

Do not turn unrelated paragraphs into a list or create decorative groups.

Table gates

Treat a table as a list with repeated fields. Rows must compare on one axis; column headings must stand alone; values within a column should use parallel form when it aids scanning; row order must be clear or explained; every row and column must support comparison or decision; and nearby prose must not repeat the entire table.

Process

1. Fix the contract

Identify reader, useful action, title, scope, claims, and product role from the supplied contract. Reference that exact input rather than restating it in the report. Return EDITORIAL_CONFLICT when the problem requires changing it.

2. Build the inventory

Walk reader Markdown top to bottom. Assign every paragraph, list, and table an ID. Give each unit one exact locator in the supplied snapshot: nearest heading plus a unique excerpt or occurrence/line location. In expanded detail, also record the first 6–12 words; a compact inventory does not need both locators and a second first-words column.

3. Run a scan pass

Read only headings, first sentences, lists, and tables. Confirm that the reasoning and required actions remain findable without linear reading.

4. Audit every paragraph

For every P-ID, check topic and result (pass, rewrite, split, merge, move, remove, or blocked). In default reportDetail: findings, preserve every anchored ID in coverageInventory, group passing IDs in passedUnits, and give an individual diagnosis and minimum action only for non-passing units. Never group failures or hide unchecked paragraphs in a pass range. In expanded, provide topic, reason, and action per paragraph; include corrected text only when requested in rewrite mode.

5. Audit every list and table

Run the relevant gates for every L-ID and T-ID, including lead, parallelism, order, grouping, and repetition.

6. Repair minimally

Keep passing blocks unchanged. Preserve facts, links, qualifications, technical values, and author register in every repair. Track ID changes such as P014 → P014a + P014b or P021 + P022 → P021.

7. Repeat the scan pass

After repairs, reread headings, first sentences, lists, and tables. Verify that topics appear early and block order is understandable.

8. Prove coverage

Compare found and checked counts. ready requires 100% coverage, with code and service handoff explicitly excluded.

Statuses

Return ready only when every prose paragraph, list, and table is individually inventoried and covered by a passing group or finding; mixed ideas are split and dependent fragments joined in proposed repairs; openings support scanning; changes preserve Brief and claims; and reader Markdown contains no audit IDs or internal markers. Compact coverage does not waive any unit's gates.

Return blocked only when repair requires a contract change, invented evidence, removal of a required qualification, or an author decision between incompatible meanings. Length and style preference alone never block.

Output

For audit, return status, found and checked counts, excluded units, complete anchored coverageInventory, grouped passedUnits, paragraph/list/table findings, and critical blockers. Use the shared contract's snapshot, coverageFingerprint, and worker provenance. Do not repeat successful checks as prose.

Keep the compact inventory to ID and locator, and refer to it for covered units. Record the scan result once; any failed scan belongs in the relevant finding. Use references to the Brief and reader snapshot for controls, not a repeated contract or paragraph-by-paragraph explanation of the fingerprint. A findings-only report does not require the expanded manifest or the complete automatic example below to be printed.

For rewrite, also return corrected reader Markdown without IDs and a change log.

Expanded manifest forms (on request):

IDAnchorFirst wordsTopicResultReason or action
IDAnchorTypeResultGates and action

For automatic, return:

status: ready | blocked
editedMarkdown: |
  ...
coverage:
  proseFound: 0
  proseChecked: 0
  listsFound: 0
  listsChecked: 0
  tablesFound: 0
  tablesChecked: 0
paragraphManifest: []
structureManifest: []
changes: []
warnings: []
blockers: []
qa:
  fullCoverage: true | false
  oneTopicPerParagraph: true | false
  scanPassClear: true | false
  listsParallel: true | false
  claimsPreserved: true | false
  internalIdsRemoved: true | false
nextStage: chief_editor_review | edit_article | blocked

Do not

  • Split at random for visual lightness.
  • Force equal paragraph size or formal conclusions.
  • Ban conjunctions or pronouns without context.
  • Treat a short paragraph as incomplete by length alone.
  • Mix the audit manifest into reader Markdown.
  • Restyle the whole article for a local problem.
  • Replace editorial judgment with a mechanical rule.

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.