agentleFS
localoy-ailocaloy-ai/localstack/keyword-research/SKILL.md

keyword-research

Skill2 starsChanged 41 days agoMITView on GitHub

Decides what a site should target: the terms its buyers actually use, grouped by the intent behind them and mapped to the page that should own each one. Use when asked "what keywords should we target", "find keywords", "what should we write about", or "what do people search for". (localstack)

54 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use link-prospecting, seo-project-setup and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • JwuthriSkill

    link-prospecting

    Find link prospects, discover contact paths, and draft outreach from SERPs and backlink signals.

    Also in 11 projects that use this

  • JwuthriSkill

    seo-project-setup

    Set up a durable local SEO workspace with project context, notes, goals, positioning, preferences, MCP checks, and Search Console data intake.

    Also in 11 projects that use this

  • appeekySkill

    app-marketing-context

    When the user wants to create or update their app marketing context document. Also use when the user mentions "app context", "marketing brief", "app positioning", or when starting any ASO or app marketing project. This is the foundation skill — all other skills check for this context first.

    Also in 6 projects that use this

  • appeekySkill

    metadata-optimization

    When the user wants to optimize App Store metadata — title, subtitle, keyword field, or description. Also use when the user mentions "optimize my title", "ASO metadata", "keyword field", "character limits", "app description", or "write my subtitle". For keyword discovery, see keyword-research. For full ASO audits, see aso-audit.

    Also in 6 projects that use this

  • liangdabiaoSkill

    review-analysis

    对亚马逊商品评论进行深度分析,自动识别产品痛点、分析退货原因,生成改进建议和客服回复模板。Invoke when user uses /review-analysis command with a product ASIN.

    Also in 5 projects that use this

  • akii-technologies-ltdSkill

    keyword-clustering

    Cluster and organize keywords into topical groups for SEO. Use when the user asks to "cluster keywords", "group keywords", "organize keywords", "keyword mapping", "topic clusters", "keyword grouping", "build a content plan", "pillar pages", "topical authority", "semantic clustering", or pastes a list of keywords.

    Also in 12 projects that use this

  • +5 more from Jwuthri

The file

We split this skill into the rules it gives an agent

12 rules. 0 are common, 11 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 50 edited versions we read keep these.

  • 11

    Distinctive

    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:

    Check what you already know from this workspace and the conversation.

    line 43
  2. Distinctive:

    If no answer comes, do not guess your way through.

    line 45
  3. Very specific:

    Earlier runs: if keywords-<slug>.md already exists here (<slug> is the site's host or path, lowercase, dots and slashes as hyphens — …

    line 47
  4. Distinctive:

    Say only what you observed: Every claim in the output traces to something you actually read, fetched or were told.

    line 62
  5. Distinctive:

    Name your assumptions: If you had to assume something to proceed, put it at the top of what you produce, in one line.

    line 70
  6. Distinctive:

    Finish or say you did not: Do not pad to length, and do not present a first pass as a final one.

    line 74
  7. Distinctive:

    Prefer what you fetched to what you recall: When they disagree, the fetch wins and you say so.

    line 89
  8. Distinctive:

    Harvest the real phrasings: Use the search suggestions, related searches and question boxes you can actually observe for your seed terms.

    line 105
  9. Distinctive:

    No search volumes, no difficulty scores, no traffic estimates.

    line 132
  10. Distinctive:

    Every term traces to something observed: a suggestion you saw, a competitor heading you read, a phrase the business used.

    line 136
  11. Distinctive:

    Every term maps to exactly one page, and no page collects two terms that would compete with each other.

    line 141
  12. Distinctive:

    Never state a score, rating or grade you did not measure.

    line 149

“Common” is measured: kept by at least 6 in 10 of the 50 edited versions of this file we could read. “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 research

Decide what this site should try to rank for, in the buyer's words, and say which page should own each term.

What you need first

  • What the business sells — a keyword set built from a guess about the offering is confidently aimed at the wrong buyer
  • Where it sells — a service area changes which terms are worth anything and which are noise
  • Site url — a term the site already has a page for is a different recommendation from one it does not

Check what you already know from this workspace and the conversation. Ask for everything still missing in a SINGLE message, then wait.

If no answer comes, do not guess your way through. Produce whatever is genuinely useful without the missing facts, state at the top which ones you lacked, and say what would change once you have them.

Earlier runs: if keywords-<slug>.md already exists here (<slug> is the site's host or path, lowercase, dots and slashes as hyphens — acme-com), say when it was last written (its Updated: line) before you start. This run replaces it; CHANGELOG.md and git keep the history.

What you decide, and what you do not

Decide yourself — how terms are grouped, which page should own a term and what to cut. Act; do not ask and do not flag.

Decide and flag — the buyer you assumed and any term kept despite thin evidence. Proceed on a named assumption and put it at the top of the output.

Stop and wait — buying tool access and or anything that spends money. Never resolve one of these by assumption, however long the wait.

How you work

Say only what you observed. Every claim in the output traces to something you actually read, fetched or were told. If you did not check it, do not assert it.

Report what you could not do. A page that would not load, a source you could not reach, a step you skipped — these go in the output. Dropping them silently turns partial work into work that looks complete, which is worse than work that looks partial.

Name your assumptions. If you had to assume something to proceed, put it at the top of what you produce, in one line. An assumption stated is corrected in seconds; an assumption buried becomes a fact nobody checked.

Finish or say you did not. Do not pad to length, and do not present a first pass as a final one.

Before you start

Establish what you need before producing anything. A confident answer about a business you have not described is the most expensive kind of wrong: it reads as authoritative and nobody catches it until it is in front of a customer.

Sources

Cite what you used. Name the URL, document or statement behind each finding, inline, where the finding is. A sources list at the bottom that nothing points to is decoration.

Prefer what you fetched to what you recall. When they disagree, the fetch wins and you say so. When you could not fetch, say that instead of filling the gap from memory.

Do not launder a guess through a citation. Linking a plausible source next to an unverified claim is worse than the bare claim, because it borrows credibility the claim did not earn.

Procedure

  1. Write down what is being sold. In one sentence, from what you were told — not from the site's own copy. Copy tells you how the business describes itself, which is frequently not how its buyers search.
  2. Collect the seed terms. From the business description, from the site's own navigation and headings, and from what competitors' pages call the same thing. Fetch those pages; quote the terms you found and where you found them.
  3. Harvest the real phrasings. Use the search suggestions, related searches and question boxes you can actually observe for your seed terms. Record each one and where it came from. If you cannot reach a source, say so — an unreachable source is a gap in the research, not an invitation to invent.
  4. Group by intent, not by topic. Four groups: ready to buy, comparing options, learning about the problem, and looking for the business by name. Intent decides what page type wins; topic does not.
  5. Cut what cannot work. Drop terms whose results are dominated by marketplaces, directories or national brands, and say which and why. A term this site has no chance at is worse than no term, because it absorbs work.
  6. Map each surviving term to a page. An existing URL where one fits, or a page that would have to be created, named as such. A term with no plausible page is not a target.
  7. Write the report. Save to keywords-<slug>.md at the top of the working folder, starting with Updated: YYYY-MM-DD. Summary table first — term, intent group, target page, exists or to create — then the groups with the evidence for each term, then what you cut and why. Then keep the standard files. Add each page that has to be created to TODOS.md as - [ ] create a page for "<term>" (keywords <slug>).

Standard files. This folder is kept in files any agent already reads. Update them in place; never scatter output into new folders.

  • AGENTS.md — create it if missing. localstack owns only the block between <!-- localstack:start --> and <!-- localstack:end -->; rewrite that block, never anything outside it. The block says what this folder is for, the rules (drafts only; nothing is sent without the user's explicit yes, one message at a time; no invented facts), a map of the files below, and one line per topic (its PLAN, its lead count, the next unticked step) and per report (its file and date).
  • CHANGELOG.md — create it if missing (# Changelog). Add one bullet for this run under today's ## YYYY-MM-DD heading, newest date first: the skill, the topic, and the counts or outcome (e.g. - lead-search austin-dentists: 18 found, 3 skipped as already contacted).
  • TODOS.md — create it if missing (# TODOs). Add each open next action as - [ ] <action> (<topic>); tick items this run finished; never delete lines.
  • DESIGN.md — decisions meant to last (positioning, tone, channels to use or avoid). Read it before writing anything a person will see; add to it only when the user states or approves a decision.

Quality bar

  • No search volumes, no difficulty scores, no traffic estimates. You have no keyword tool. Where a number would normally go, name the check you could not run — the absence is the honest finding, and an invented number here poisons every decision downstream.
  • Every term traces to something observed: a suggestion you saw, a competitor heading you read, a phrase the business used. Terms you generated by analogy are labelled as such.
  • Priority is argued in words — closeness to a purchase, whether a page already exists, whether the results look winnable — never asserted as a rank number.
  • Every term maps to exactly one page, and no page collects two terms that would compete with each other.
  • The cut list is in the report. What you rejected is as useful as what you kept.

The output contract

These apply to the file you write, not just the reply you send.

  • Never state a score, rating or grade you did not measure. Report the values you actually observed instead — they are more useful and they are true.
  • Open with a summary table — a row per page, item or finding — so the shape of the result is readable before the detail.

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.