agentleFS
CreceraDigitalCreceraDigital/crecera-skills/skills/keyword-guidelines/SKILL.md

keyword-guidelines

Skill0 starsChanged 3 months agoMITView on GitHub

Produce a "Keyword Guidelines [keyword]" content brief for a target search query. Pulls top-10 SERP results via DataforSEO, parses each competitor page, then outputs content structure ranges, important terms with frequency ranges, questions to answer, deduped competitor topics, and topic-grouped facts. Drop-in replacement for Surfer SEO's content-editor export. Outputs a human-readable .txt and a structured JSON. Use whenever the user asks for keyword guidelines, content guidelines, a content brief, SEO content optimization targets, or word/heading/term counts for a target keyword.

The file

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 4 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    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. Very specific:

    If a file with the same name already exists in the output directory, append a (YYYY-MM-DD) suffix before the extension (e.g.

    line 17
  2. Very specific:

    Call mcp__dataforSEO__serp_organic_live_advanced with the keyword.

    line 87
  3. Distinctive:

    If filtering drops below 8 URLs, pull from positions 11–15 to backfill.

    line 96
  4. Distinctive:

    If a parse fails (timeout, blocked, 4xx), drop the URL and continue.

    line 104
  5. Very specific:

    Use the keyword verbatim inside the brackets — preserve spaces and the user's original casing.

    line 145
  6. Distinctive:

    Top 10 is the default sample: Don't go higher without the user asking — it doubles parse cost and Surfer itself defaults to 10.

    line 157
  7. Distinctive:

    Don't fabricate facts: If a fact bullet doesn't appear in source content, drop it.

    line 162

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

Keyword Guidelines

Drop-in replacement for Surfer SEO's content-editor guidelines export. Same output shape, different engine. Works entirely through DataforSEO MCP tools + a local Python analyzer + one LLM pass for fact extraction.

Output contract

For a given keyword + location, produce two files in the working directory:

  1. Keyword Guidelines [{keyword}].txt — human-readable brief, same paste format as Surfer's content-editor export. The keyword inside the brackets is the user's verbatim search query (not slugified — spaces are preserved).
  2. Keyword Guidelines [{keyword}].json — structured equivalent for pipelines.

If a file with the same name already exists in the output directory, append a (YYYY-MM-DD) suffix before the extension (e.g. Keyword Guidelines [internal communication] (2026-05-20).txt) to avoid clobbering prior runs.

Both files contain five sections in this exact order:

  • CONTENT STRUCTURE — character / image / heading / paragraph / word ranges (min–max across top 10)
  • IMPORTANT TERMS TO USE — up to 300 terms (1–5 grams) with per-term usage frequency ranges
  • QUESTIONS TO ANSWER — 4–10 direct questions pulled from SERP people_also_ask + question-shaped competitor H2/H3s
  • TOPICS TO COVER — up to ~80 deduped competitor headings (all H1/H2/H3) + PAA, source-tagged. Mirrors Surfer's "Topics & Questions" panel. Each competitor topic shows a (N×) page-count when it appears across multiple competitors.
  • FACTS TO INCLUDE — topic-grouped factual claims extracted from competitor content

The .txt format must exactly match the Surfer layout shown below — downstream tooling parses it positionally. The TOPICS TO COVER section is an extension beyond Surfer's native .txt export (Surfer exposes this in the UI but not the export); parsers that don't recognize it should skip it cleanly.

Surfer .txt format (target)

## CONTENT STRUCTURE
* Characters: 8719 - 14037
* Images: 7 - 23
* Headings: 12 - 22
* Paragraphs: 24 - Infinity
* Words: 1333 - 1533

## IMPORTANT TERMS TO USE
_Make sure to include those as many times as stated._
* deskless workers: 33 - 57
* deskless workforce: 4 - 8
...

## QUESTIONS TO ANSWER
* What is a deskless employee?
* What is office peacocking?
...

## TOPICS TO COVER
_Drawn from competitor headings and People Also Ask. Pick the ones relevant to your angle._

### From People Also Ask
* What is a deskless employee?
* ...

### From competitor headings
* What Is Internal Communication? (And Why It's Important) (3×)
* 11 reasons why internal communication is important at work
* How to improve internal communications (2×)
* ...

## FACTS TO INCLUDE
_Facts are grouped by topics._
### Technology for Deskless Workers
* Fact A
* Fact B

### Job Satisfaction and Retention
* Fact A
...

Note: when the maximum paragraph count is unbounded relative to the median (Surfer's heuristic), emit Paragraphs: N - Infinity. Apply the same rule when max > 2× median.

Inputs

  • keyword (required) — the target search query, e.g. deskless workers
  • location_code (optional, default 2840 US) — DataforSEO location code
  • language_code (optional, default en)
  • output_dir (optional, default current working directory)

Workflow

Step 1 — Fetch SERP

Call mcp__dataforSEO__serp_organic_live_advanced with the keyword. Pull the top 10 organic results. Capture the raw response to _work/serp.json.

From the same response, extract any people_also_ask items — these become Question candidates.

Filter the 10 URLs to remove obvious non-content matches before parsing:

  • Skip YouTube, Reddit, LinkedIn, Twitter, Facebook (different content shapes)
  • Skip PDFs (.pdf in URL)
  • Skip homepages where the path is / (rare on commercial keywords but possible)

If filtering drops below 8 URLs, pull from positions 11–15 to backfill. You want 8–10 article-shaped competitors.

Step 2 — Parse each competitor

For each surviving URL, call mcp__dataforSEO__on_page_content_parsing with url set to that URL. The response includes parsed page content, headings, and structural data.

Save each parsed result to _work/pages/{slugified-url}.json.

If a parse fails (timeout, blocked, 4xx), drop the URL and continue. Need ≥ 7 successful parses to proceed; below that, surface the issue and ask the user whether to widen the SERP pull.

Step 3a — Count images (optional but recommended)

DataforSEO's markdown output strips <img> tags, so the analyzer can't count images from parsed page text. Run this helper to fetch each URL directly and count images in the main content area:

python scripts/count_images.py --urls _work/serp.json --out _work/image_counts.json

Skip this step if you don't care about the Images range — the rest of the brief is unaffected.

Step 3b — Run the analyzer

python scripts/analyze.py --pages _work/pages --serp _work/serp.json --keyword "{keyword}" --out _work/analysis.json --image-counts _work/image_counts.json

Omit --image-counts if you skipped 3a. The analyzer produces structure ranges (trimmed: drops the lowest and highest sample when N≥8 to avoid outlier-driven wide ranges), term frequency ranges, question candidates, and the deduped topic list.

Step 4 — Extract facts

This is the only LLM-driven step. Read the parsed body text from all surviving pages (cap at ~3K words per page to fit context) and call this prompt:

Below is content from {N} top-ranking pages for the keyword "{keyword}". Extract factual claims — statistics, percentages, dollar figures, dated events, definitions, named methods, named sources. Skip opinions and generic advice. Group facts into 3–6 topic clusters that emerge naturally from the content. For each cluster, give it a short Title Case heading and 3–8 bullets. Each bullet must be a single complete sentence stating one fact, written in neutral encyclopedic voice. Do not cite the source page in the bullet — just state the fact.

Output in this exact format:

### {Topic Heading}
* Fact bullet 1.
* Fact bullet 2.

Save the raw LLM output to _work/facts.md.

Step 5 — Render outputs

python scripts/render.py --analysis _work/analysis.json --facts _work/facts.md --keyword "{keyword}" --out-txt "{output_dir}/Keyword Guidelines [{keyword}].txt" --out-json "{output_dir}/Keyword Guidelines [{keyword}].json"

Use the keyword verbatim inside the brackets — preserve spaces and the user's original casing. If the keyword contains any of \\ / : * ? " < > | (filesystem-reserved characters on Windows), replace them with - before writing. If the target file already exists, append a (YYYY-MM-DD) suffix before the extension.

Step 6 — Report

In the chat reply, list:

  • Both output file paths
  • Top 10 URLs that were analyzed (and any dropped, with reason)
  • Counts: terms extracted, questions found, fact clusters identified
  • One-sentence sanity check: "Word range 1333–1533, 80 terms, 4 questions, 5 fact clusters — matches Surfer shape."

Constraints

  • Top 10 is the default sample. Don't go higher without the user asking — it doubles parse cost and Surfer itself defaults to 10.
  • N-gram range is 1–5. Surfer extracts phrases like transportation and manufacturing industries and lack of employee engagement — capping at 3 misses these. The boundary stop-word filter (first/last token must be a content word) keeps noise out at the higher n-gram lengths.
  • Stop-word filter is aggressive. Cut articles, prepositions, copulas, and SEO-junk words ("read more", "learn more", "click here"). The analyzer ships a built-in list — extend only if a brand-specific term keeps getting filtered.
  • Term must appear in ≥ 3 pages. Single-page artifacts (one competitor's brand name, one outlier) do not belong in the export.
  • Frequency ranges are min–max occurrences across pages that contain the term. Not average. Surfer's "33 - 57" means the lowest page using "deskless workers" used it 33 times and the highest used it 57 times.
  • Don't fabricate facts. If a fact bullet doesn't appear in source content, drop it. The LLM step is extraction, not invention.

Failure modes to watch

  • Cloudflare / bot blocks on parsing — common on enterprise SaaS pages. The DataforSEO parser handles most but not all. If 3+ URLs fail, switch to mcp__dataforSEO__on_page_instant_pages as a fallback.
  • PAA absent from SERP — some keywords return no people_also_ask block. In that case, mine questions from competitor H2/H3 text matching ^(What|How|Why|When|Where|Is|Are|Can|Do|Does|Should)\b.
  • Term inflation from boilerplate — site nav and footer text can inflate term counts. The analyzer attempts to strip nav/footer via heuristics (short repeated blocks across pages of the same domain) but it isn't perfect. If a term feels boilerplate-driven, manually drop it.
  • Empty fact clusters — thin SERPs (forum-heavy, mostly Reddit / Quora) yield few extractable facts. Surface this in the report rather than padding with generic statements.

When NOT to use this skill

  • The user wants competitor strategy analysis (positioning, USPs, conversion angles) — use competitor-positioning instead.
  • The user wants topical clusters across many keywords — use topical-map-dfseo2.
  • The user wants to rewrite an existing page based on the SERP — use snippet-rewrite or aeo-page-optimizer.

This skill produces targets, not strategy. It's the thing you hand to a writer alongside the actual brief.

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.