agentleFS
flexim-ioflexim-io/seo-writers/skills/audit-content-library/SKILL.md

audit-content-library

Skill1 starsChanged 3 months agoApache-2.0View on GitHub

Audit the current content library before Article Brief approval and again before chief-editor review. Use read-only Flexim access, a complete export, or an explicit declaration of an empty library to assess semantic overlap, gaps, competing drafts, update opportunities, and internal links. Return an evidence-linked portfolio decision and differentiation contract. Do not mutate articles, CMS, or the editorial contract.

The file

Show its rules and text

We split this skill into the rules it gives an agent

20 rules. About 0 are common, 17 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈17

    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:

    Run twice for every article:

    line 12
  2. Distinctive:

    Use in this order:

    line 35
  3. Very specific:

    Read the shared audit coverage contract.

    line 47
  4. Very specific:

    Call list_content_types and identify the actual post collection.

    line 61
  5. Very specific:

    Call get_content_type and verify title or name, slug, status, content, description, SEO metadata, dates, and relations.

    line 62
  6. Distinctive:

    When Flexim is unavailable, accept a complete export only if it contains:

    line 74
  7. Distinctive:

    every published record in scope and active drafts separately.

    line 76
  8. Distinctive:

    search intent and question.

    line 96
  9. Distinctive:

    Do not call normal topical adjacency cannibalization.

    line 113
  10. Distinctive:

    Write one internal sentence:

    line 119
  11. Distinctive:

    Treat it as a hypothesis until compared with the corpus.

    line 123
  12. Distinctive:

    Use titles, descriptions, metadata, taxonomy, and previews only to shortlist.

    line 127
  13. Distinctive:

    Do not default to new content.

    line 142
  14. Distinctive:

    Keep corpus IDs, labels, and reasoning in production fields.

    line 159
  15. Distinctive:

    Create a new snapshot. Include newly published posts, changed pages, and active drafts.

    line 165
  16. Distinctive:

    Read only title and reader Markdown first.

    line 169
  17. Distinctive:

    Check whether the draft:

    line 173
  18. Distinctive:

    Use empty values for phase-inapplicable fields.

    line 251
  19. Distinctive:

    Treat a preview as complete text.

    line 256
  20. Distinctive:

    Call every topical neighbor cannibalization.

    line 257

≈ “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 the content library

Purpose

Determine which independent reader job a proposed article should own in the current content portfolio, then prove that the completed text kept that role. Compare reader situations, intent, useful action, scope, evidence, and product role—not keywords alone.

Run twice for every article:

  1. pre-brief, before the Article Brief is approved;
  2. pre-chief-editor, after edit-article and before chief-editor-review.

Responsibility

audit-content-library:

  • inventories every published post and active draft separately;
  • finds nearest content by reader, situation, intent, useful action, scope, evidence, and product role;
  • reads the complete Markdown of every plausible neighbor;
  • distinguishes wording similarity from competition for the same reader job;
  • recommends new content, differentiation, update, consolidation, internal linking, or deferral;
  • creates a differentiation contract for the Article Brief;
  • keeps corpus terms, IDs, overlap labels, and contract fields production-only, while writing separate plain-language reader handoffs;
  • checks the edited article against that contract and a fresh corpus snapshot;
  • returns exact entry IDs and anchors as evidence.

It does not mutate or publish records, change the Article Brief or article promise, treat an old post as current primary evidence for a product claim, infer search demand without supplied data, replace the other editorial gates, expose production labels as reader wording, or recommend consolidation from a shared keyword alone.

Inputs and priority

Use in this order:

  1. explicit user corrections;
  2. current published CMS corpus and active drafts;
  3. proposed topic, Suggested Topic, or approved Article Brief;
  4. edited reader Markdown for pre-chief-editor;
  5. verified search or performance data when supplied;
  6. editorial policy, taxonomy, and internal-link rules;
  7. model assumptions.

Titles, descriptions, and SEO metadata are shortlist signals only. Decide overlap from complete Markdown.

Read the shared audit coverage contract. Default to reportDetail: findings; retain complete corpus evidence and anchored comparisons while grouping non-colliding inventory entries by explicit exclusion reason. Do not shorten the work by omitting plausible neighbors or required full reads.

Modes

  • pre-brief: locate the proposed article in the portfolio; return a decision, differentiation contract, exclusion zones, and internal-link plan.
  • pre-chief-editor: compare the actual edited article with published neighbors, active drafts, and the differentiation contract; return exact drift and the smallest editor action without rewriting.
  • automatic: ask no questions; infer phase from whether reader Markdown is supplied; return ready or blocked without inventing a missing corpus.

Corpus sources

Flexim is recommended but not mandatory.

Read-only Flexim

  1. Call list_content_types and identify the actual post collection.
  2. Call get_content_type and verify title or name, slug, status, content, description, SEO metadata, dates, and relations.
  3. Query every published record using pagination until complete.
  4. Query active drafts separately.
  5. Record ID, title, slug or URL, status, description, metadata, dates, and a short preview for every entry.
  6. Build a plausible-neighbor shortlist.
  7. Fetch the complete entry for every shortlisted item. A query preview is never sufficient.
  8. Record collection, filters, check time, counts, page coverage, IDs, and updatedAt values in corpusSnapshot.

Allowed operations are read-only schema, query, listing, and full-entry reads. Never call create, update, delete, upload, publish, or topic-status mutations.

Complete CMS export

When Flexim is unavailable, accept a complete export only if it contains:

  • every published record in scope and active drafts separately;
  • stable record identity, status, full Markdown, title, URL or slug, and relevant dates;
  • collection and export provenance;
  • export time and evidence that pagination or batching is complete.

Return blocked if full content, statuses, or coverage cannot be established. A partial folder of articles is not a complete corpus merely because it is local.

Confirmed empty library

For a new content project, accept the owner's explicit declaration that the complete content scope has zero published articles and zero other active drafts, including content outside Flexim. Record the scope, source statement, and date in corpusSnapshot, with source: empty_declaration. No CMS, empty export file, or schema creation is required.

Having no CMS, no connected tools, or an empty local folder does not prove an empty library. If the scope or declaration is missing, request that information in interactive modes; in automatic, return the precise blocker. If available records contradict the declaration, resolve the discrepancy before claiming complete coverage.

For a confirmed empty library, return zero counts, no nearest posts, and no internal links; do not invent pages or claim API pagination occurred. Assess the proposed reader job, evidence, and differentiation normally. At pre-chief-editor, check whether any other content was created or published since the first declaration and identify the article under review separately. The article under review is not a competing draft of itself. Record the refreshed evidence; a prior declaration alone is not current coverage after a context boundary.

Comparison model

For the candidate and every close neighbor, normalize:

  • reader and situation;
  • search intent and question;
  • useful action or outcome;
  • scope and exclusions;
  • structure and promised form;
  • evidence and information gain;
  • product role;
  • next step and internal-link role;
  • freshness and current product state.

Classify overlap:

  • lexical: similar language, distinct reader job;
  • topical: shared subject, distinct useful action;
  • partial-job: one article covers a meaningful subset of the same action;
  • same-job: same reader, situation, action, and promise;
  • duplicate: substantially the same job, scope, evidence, and form.

Do not call normal topical adjacency cannibalization. Search cannibalization risk requires meaningful competition for the same intent and outcome, not just related terms.

pre-brief process

1. State the proposed owned job

Write one internal sentence:

For [reader in situation], help them [complete action] within [scope] using [distinct evidence or form].

Treat it as a hypothesis until compared with the corpus.

2. Shortlist and read neighbors

Use titles, descriptions, metadata, taxonomy, and previews only to shortlist. Read complete Markdown for every plausible collision and for pages that could provide or receive an internal link.

3. Build the overlap map

For each neighbor record exact supporting anchors and compare reader, situation, intent, useful action, scope, evidence, product role, and next step. State what overlaps, what differs, and whether the difference is visible to a reader before choosing a recommendation.

4. Choose a portfolio decision

  • create-new: the article owns a distinct job and evidence.
  • differentiate: the article is useful but needs explicit boundaries.
  • update-existing: an existing page already owns the job and should be improved.
  • consolidate: multiple pages split one job without a useful distinction.
  • internal-link-only: the need is already served; improve navigation instead.
  • defer: evidence, demand, or portfolio value is insufficient.

Do not default to new content.

5. Write the differentiation contract

Define:

  • owns: exact reader job the article owns;
  • mustCover: essential questions and evidence;
  • mustNotDuplicate: neighboring jobs, sections, and claims to avoid;
  • uniqueEvidence: evidence or examples that make the article additive;
  • collisionRule: the observable condition that would make the draft compete with a named page;
  • internal-link handoffs in both production and reader language.

An internal-link handoff must name source and destination roles, placement anchor, reader reason, natural anchor direction, and whether the destination is published. Never link readers to a private draft.

6. Hand off to the Article Brief

Keep corpus IDs, labels, and reasoning in production fields. Transfer only the decision, owned job, boundaries, must-cover evidence, collision rule, and reader-language internal-link plan into the Brief.

pre-chief-editor process

1. Refresh the corpus

Create a new snapshot. Include newly published posts, changed pages, and active drafts. Never reuse the old snapshot as current state without checking.

2. Recover the article's actual job

Read only title and reader Markdown first. Infer actual reader, situation, promise, useful action, scope, evidence, product role, and next step. Do not copy the intended job from the Brief.

3. Compare actual and contracted roles

Check whether the draft:

  • still owns the contracted job;
  • entered a neighbor's exclusion zone;
  • dropped unique evidence;
  • widened into a generic overview;
  • repeats another page's structure or conclusion;
  • creates a clear, honest link handoff;
  • contains corpus or audit language that should remain production-only.

4. Return a verdict

  • pass: role and boundaries hold;
  • narrow: remove a specific overlapping span;
  • reposition: actual job drifted and needs a chief-editor contract decision;
  • update-existing: the draft should become an update rather than a new page;
  • verify: corpus freshness or one exact comparison is incomplete;
  • blocked: a critical portfolio conflict cannot be resolved within audit scope.

Give exact reader anchors and the smallest chief-editor action. Do not edit the article.

Readiness gates

Return ready only when corpus coverage is complete and evidenced, published items and drafts are separate, every plausible neighbor has been read in full, comparisons use reader jobs rather than keywords alone, the portfolio decision is supported, the differentiation contract or final verdict is precise, and production language is isolated.

Return blocked when corpus completeness, record status, full neighboring content, or a critical identity is unavailable; when several pages are ambiguous and cannot be distinguished; or when the proposed job cannot be defined without changing an approved Brief.

Missing optional search-volume data is a warning, not a blocker. Never invent it.

Output

Return one compact report with status and phase, complete corpus coverage and snapshot, proposed or actual owned job, all plausible neighbors with full-read identities and exact comparison anchors, overlap level and reason, portfolio decision or final verdict, differentiation contract, internal-link handoffs, material findings with priority and minimum action, warnings, blockers, and nextStage. Summarize the nearest pages without a count quota. In pre-chief-editor, include coverageFingerprint, reader/input identities, and independent worker provenance. Do not duplicate the same comparison in a second narrative and YAML report.

For automatic, return:

status: ready | blocked
phase: pre-brief | pre-chief-editor
corpusSnapshot:
  source: flexim | cms_export | empty_declaration
  scope: "..."
  sourceRef: "..."
  collection: "..."
  checkedAt: "ISO-8601"
  publishedFound: 0
  publishedInventoried: 0
  draftsFound: 0
  pagesChecked: 0
  fullEntriesRead: []
candidate:
  title: "..."
  proposedOwnedJob: "..."
  actualOwnedJob: "..."
nearestPosts: []
overlapMap: []
decision: create-new | differentiate | update-existing | consolidate | internal-link-only | defer
differentiationContract:
  owns: "..."
  mustCover: []
  mustNotDuplicate: []
  uniqueEvidence: []
  collisionRule: "..."
internalLinkHandoffs: []
readerLanguageHandoffs: []
draftVerdict: pass | narrow | reposition | update-existing | verify | blocked
warnings: []
blockers: []
qa:
  corpusInventoryComplete: true | false
  draftsCheckedSeparately: true | false
  shortlistedFullTextRead: true | false
  readerJobCompared: true | false
  snapshotFresh: true | false
  articleBriefPreserved: true | false
  productionLanguageIsolated: true | false
nextStage: article_brief | chief_editor_review | update_existing | consolidation_review | blocked

Use empty values for phase-inapplicable fields. Never invent them.

Do not

  • Compare titles, slugs, or keywords alone.
  • Treat a preview as complete text.
  • Call every topical neighbor cannibalization.
  • Recommend a new article by default.
  • Link readers to a draft or unavailable page.
  • Reuse old claims without current primary evidence.
  • Copy corpus-report language into reader Markdown.
  • Rewrite the article inside the audit.
  • Mutate CMS even when a duplicate is obvious.

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.