agentleFS
MuvonMuvon/octomind-tap/skills/content-formats/SKILL.md

content-formats

Skill6 starsChanged 8 months agoApache-2.0View on GitHub

Blog post formats by search intent: how-to, listicle, comparison, review, guide, case study. Use when planning or drafting a post meant to rank.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before drafting a format that needs experience (review, comparison, best-of, how-to, case study), ask the author once, as a short list: …

    line 70
  2. Very specific:

    If the author can't supply it, change the format (reported synthesis, interview, labelled opinion), add a named expert's input with …

    line 71
  3. Distinctive:

    Prefer updating or consolidating a weak page over publishing a near-duplicate.

    line 90

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

Overview

Pick the page format the searcher expects before writing a word. Google, Bing, and the AI answer engines that build on their indexes reward the page that does the searcher's task best, and the task decides the shape: steps for a how-to, a verdict and a table for a comparison, a definition in the first sentence for a glossary entry. Use this skill when planning, outlining, drafting, or refreshing an article or blog post meant to rank and be cited. Answer-first passage craft and crawler setup live in content-geo; claim verification lives in content-grounding.

Mental model

Three questions settle a piece: what the searcher wants to do (know, compare, decide, do, go), what shape the current results page rewards, and what this author can add that the ranking pages lack. Format follows the first two; whether to publish at all follows the third. Google's AI guide frames the third as commodity versus non-commodity content: a page "based on common knowledge, which could originate from anyone" competes with every other page and with the AI answer itself, while "unique expert or experienced takes" give engines a reason to cite it. Experience is evidence the author holds (tests, photos, data, decisions, failures), never a tone the writer adds.

Rules

Read the results page first

  1. Classify intent from the query and its results, not the keyword alone: Know (explain), Know Simple (one-line answer), Do (task, download, calculate), commercial investigation (compare, choose), Website (a specific brand or page), Visit (local). A query can carry two.
  2. In the top 10, note the dominant content type (guide, list, product page, tool), format (steps, table, list, essay), and angle (for beginners, cheapest, tested, this year). Match the type and format; differ on the angle.
  3. Note the features: AI Overview, People Also Ask, Discussions and forums, video, shopping, Top stories. The web search tool is not Google; Google-only features stay unverified without a screenshot, Search Console data, or a SERP-data tool.
  4. Note the dates on ranking pages. Breaking news, recurring events, current prices, and product models need fresh pages; evergreen explanations do not.
  5. Name the gain this piece adds in one sentence. If you can't, report that before drafting instead of writing a commodity page.

Format by intent

Intent signalFormatMust includeFails when
"how to", "set up", "fix" (Do)How-to / tutorialPrerequisites, numbered steps with the expected result after each, troubleshooting for the errors people actually hit, versions testedSetup prose before step 1; steps nobody on the team ran
"best", "top N" (commercial)Best-of listSelection criteria and a how-we-chose or how-we-tested note; per pick: who it suits, key facts, price with an as-of date, one drawback, first-hand evidenceParaphrased manufacturer specs; your own product ranked first without disclosed criteria
"X vs Y" (commercial)ComparisonVerdict in the first screen, comparison table, "choose X if / choose Y if", where each loses, test data or sourced specsA hedged no-verdict ending; undisclosed affiliation
"alternatives to X" (switching)Alternatives pageWhy people leave X, criteria, X's real strengths, when not to switch, disclosure of who wrote itOne templated page per competitor
"[product] review"Single reviewOwn photos or screenshots, measurements, benefits and drawbacks from own use, comparison to rivals and to the previous model, who should skip itReviewing a product nobody on the team used
Broad topic, many sub-questions (Know)Guide / pillarOne section per real sub-question, each answering first and standing alone; table of contents; links to deeper cluster pagesPadding to a length target; duplicating what cluster pages cover in full
"what is X" (Know Simple)Glossary / definitionDefinition in the first sentence, then what the one-line answer can't give: example, misconception, edge case, related termsA page that is only the definition; mass-produced term pages
"statistics", "benchmark", "survey"Data studyMethod up front: sample, dates, tools, limits; key numbers in HTML text and tables; charts with a text summary; downloadable data; a named authorData shown only in images or PDFs; numbers without a denominator
"case study", "how [company] did X"Case studyStarting point, what was done, measured result with timeframe, what failed, named customer with permission, what results are typicalExceptional results presented as typical; undisclosed incentives
Many short related questionsFAQ pageReal customer or support questions; each answer's first sentence stands aloneBoilerplate questions written to hold keywords
"template", "checklist", "example" (Do)Template / checklistThe usable artifact in HTML, a filled-in example, how to adapt itCore content only inside a PDF or image
"calculator", "estimate", "how much" (Do)Calculator-style pageYour own logic with formula, assumptions, and sources visible; a worked example; limits; expert review on money or health topicsAn embedded third-party widget with nothing added; near-identical variants per city or number
Recent event or releaseNews / updateVisible date and byline, what changed and when, what it means for the reader, link to the primary announcementRe-dated old posts; speculation stated as fact
Contested question, strategyOpinion / analysisClear thesis, the author's credentials or stake, evidence per claim, the strongest counterargumentGeneric takes; claimed expertise the author lacks

Mixed results page: serve the dominant format and cover the runner-up in a section. Forum threads on top: searchers want lived experience, so lead with the author's own account or recommend joining those communities over another explainer.

Experience comes from the author

  • First-hand claims ("we tested", "I ran", "in our account") need the author's record: notes, data, screenshots, logs, or that person's explicit account. Researching a product is not using it. Google's rater guidelines rate a page built on "a false claim of personal, independent testing" Lowest and overstated experience Low; the FTC's 2024 rule bans reviews from people without actual experience.
  • Before drafting a format that needs experience (review, comparison, best-of, how-to, case study), ask the author once, as a short list: what they did and when, versions and settings, numbers, what went wrong, photos or screenshots, who else was involved.
  • If the author can't supply it, change the format (reported synthesis, interview, labelled opinion), add a named expert's input with consent, or leave a placeholder such as [FIRST-HAND: result of the 30-day test] in internal drafts. Placeholders never ship.
  • Tests, rankings, and reviews carry a methodology note: who tested, what was bought or provided free, how long, the weighted criteria, what was excluded, when it was last re-checked.
  • Images: write a shot list of original screenshots or photos, captioned with what each proves. Stock images prove nothing; alt text describes the image, not keywords.
  • How the piece was made: Google suggests AI or automation disclosure where readers would reasonably ask "How was this created?" Be specific about what the AI did, what a human checked, and which sources were used; in trust studies, vague AI labels cost more reader trust than disclosures that list sources.
  • Bylines name a real person with a bio page and credentials that fit the topic; money and health topics need fitting credentials or a named expert reviewer. Never invent authors, credentials, or headshots.

Depth, titles, and intros

  • No word-count targets. Google's self-assessment asks whether you write to a word count because Google prefers one, and answers "(No, we don't.)" Cover what the task needs, match the scope of pages that satisfy the query, add the gain, and cut sections that only restate them.
  • Title tag: the page's real promise, specific, not exaggerated, with a year only if the content was re-checked for that year. Google sets no length limit but truncates by width and rewrites boilerplate, inaccurate, or stuffed titles. Keep the H1 close to the title.
  • Meta description: a unique one- or two-sentence summary of what the page delivers. Google builds most snippets from page content, so the intro matters more.
  • Intro: the answer, verdict, or result first, then who it's for and why to trust it, in a few sentences. Bing's guidelines ask for essential information near the top, and usability research shows readers scan the first lines and headings.
  • Headings say what the section answers; specific beats clever.
  • Internal links go only to real pages the user supplied or the sitemap lists, with descriptive anchors. Never invent internal URLs; write [internal link: topic] when the URL is unknown.

Dates and refreshes

  • Show "Published" and, after a substantive change, "Last updated"; keep datePublished and dateModified in sync with them. Google's self-assessment flags changing dates "when the content has not substantially changed."
  • Refresh when facts, prices, versions, screenshots, or the results-page format have changed, or when impressions hold while clicks fall. Keep the URL and the original intent, re-verify every dated claim, add what changed, and list the changes.
  • Prefer updating or consolidating a weak page over publishing a near-duplicate; Google's core-update guidance calls deleting content a last resort.

Examples

Query "notion vs obsidian for research notes". Wrong: a long explainer of each app ending "it depends on your needs". Right: a two-sentence verdict; a table of sync, offline use, price with an as-of date, plugins, and export; "choose Notion if / choose Obsidian if"; where each failed in the author's own six-week trial, with screenshots; a no-affiliation disclosure.

Query "what is a canary deployment". Wrong: the definition restated five ways to reach a length. Right: the definition first, then the rollout percentages and rollback trigger the team actually uses and the two failures they hit.

Experience. Wrong: "We tested 12 VPNs for 30 days" when the brief contains no test. Right: ask the author for the test log; if none exists, retitle as "12 VPNs compared on published audits and pricing" with sources and an as-of date.

Checklist

  • Intent classified; dominant type, format, and angle of the top results noted; Google-only features marked unverified without evidence.
  • Format chosen from the table, its must-include elements present, its failure modes absent.
  • The gain over ranking pages named in one sentence and visible in the first screen.
  • Every first-hand claim traces to the author's record; missing experience led to a format change or a placeholder, never invention.
  • Tests, rankings, and reviews carry a methodology note; affiliations and AI assistance disclosed where readers would ask.
  • No word-count padding; title, H1, intro, and headings state the real promise.
  • Internal links point only to known URLs.
  • Dates visible and honest; a refresh re-verified facts and listed what changed.

Composition / References

Same-domain skills: content-geo (answer-first passages, crawlers, AI citation), content-grounding (claim triage and sources), content-voice (register and first-person ownership). Keyword selection and clustering belong to the SEO domain; this skill starts from a chosen query.

Reviewed 2026-10-24. This is a review date, not a publication date for the sources below.

Re-validate when Google's people-first, reviews, or AI guidance, the rater guidelines, or Bing's guidelines change.

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.