Menü
Discover keyword opportunities, evaluate metrics and SERPs, and save/tag promising terms.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | keyword-research |
| description | Discover keyword opportunities, evaluate metrics and SERPs, and save/tag promising terms. |
Turn seed topics into a prioritized keyword opportunity set using OpenSEO MCP data. The output should help the user decide what to target, what to save, and what to research next.
projectIdIf projectId is missing, use list_projects first. If the target market/location/language is unclear and would materially affect keyword metrics, ask the user; otherwise use the MCP tool defaults.
research_keywords: primary discovery tool. Use 1-5 seeds per call and prefer 150 results unless the user asks for exhaustive research.get_keyword_metrics: hydrate up to 700 known keywords with volume, keyword difficulty (KD), search intent, CPC, and monthly trends in one call. Use it to score candidate or known terms — including the Search Console striking-distance queries from step 1.get_ranked_keywords: pull exact ranking keyword rows when a target domain or page is part of the research brief.get_search_console_performance: when Search Console is connected, start from the project's real first-party demand — queries already earning impressions and near-ranking ("striking distance") terms. Request a high rowLimit and filter average position 5-20 client-side, since the API sorts by clicks and can't filter by position. Then hydrate those striking-distance queries with get_keyword_metrics to attach difficulty and intent.get_serp_results: inspect SERPs for the top candidate terms, especially when intent is ambiguous.search_local_businesses, get_local_serp_results, and get_google_business_questions: use for local SEO topics when a business/location radius matters.list_saved_keywords: avoid duplicating already-saved work or use existing tags as context.save_keywords: save selected keywords only after explicit user confirmation.get_search_console_performance (high rowLimit, default lookback), filter to striking-distance positions (~5–20) client-side, and hydrate those queries with get_keyword_metrics to attach KD and intent. That ranked, hydrated list is your fastest opportunity set — work it before broad discovery.search_local_businesses and get_local_serp_results for the most important location/keyword set instead of relying only on national keyword/SERP data.research_keywords for exploratory seeds. Use bulk calls when possible.get_keyword_metrics to hydrate a fixed keyword list — or the striking-distance queries from step 1 — with volume, KD, and intent before prioritizing.get_ranked_keywords when the user provides a domain/page and wants opportunities based on current rankings, near-misses, or competitor-owned terms.get_serp_results for high-potential or ambiguous keywords when SERP intent would change the recommendation; keep the default check small.topic:<topic>, intent:<intent>, or page:<slug>.Start with the highest-signal recommendation:
Then include a compact table:
| Keyword | Intent | Volume | KD | CPC | Priority | Notes |
|---|
End with next actions, including whether to run keyword clustering, create a content brief, or save the chosen keywords.
unknown.save_keywords without explicit confirmation.Log genuine, recurring repository friction to .agents/PAPERCUTS.md — confusing setup, a flaky repo command or script, a misleading in-repo error, stale generated files, or a non-obvious gotcha that will cost the next contributor time. Also use to review, deduplicate, and resolve existing entries. Gate hard before logging: only friction the repository itself can fix counts. Never log the agent's own sandbox/permission errors, shell-scripting mistakes, transient flakiness, or third-party tool quirks the repo can't change.
Log genuine, recurring repository friction to .agents/PAPERCUTS.md — confusing setup, a flaky repo command or script, a misleading in-repo error, stale generated files, or a non-obvious gotcha that will cost the next contributor time. Also use to review, deduplicate, and resolve existing entries. Gate hard before logging: only friction the repository itself can fix counts. Never log the agent's own sandbox/permission errors, shell-scripting mistakes, transient flakiness, or third-party tool quirks the repo can't change.
Evaluate verified findings from merge-ready, Greptile, pull-request, CI, security, billing, and other code reviews, then promote durable review gaps into the version-controlled .greptile configuration. Use when a review uncovers a recurring or high-risk repository invariant that Greptile does not capture, when Greptile repeatedly produces a false positive, or when asked to audit or update OpenSEO's Greptile rules and context.
Take a branch from "code exists (or is about to)" to "ready for Ben's final review" — multi-axis subagent review with verified findings, fixes, ci:check, checkpoint commits, and an updated PR. Use whenever the user says a feature/fix/branch should be "merge ready", asks to get changes ready for review, or appends this to a build request ("build X and make it merge-ready").
Cut an OpenSEO release — bump the version, draft user-facing release notes from commits since the last tag, run a review + subagent-verification pass, and open a "release: vX.X.X" PR. Use when the user asks to prepare a release, bump the version, or write release notes.
Take a branch from "code exists (or is about to)" to "ready for Ben's final review" — multi-axis subagent review with verified findings, fixes, ci:check, checkpoint commits, and an updated PR. Use whenever the user says a feature/fix/branch should be "merge ready", asks to get changes ready for review, or appends this to a build request ("build X and make it merge-ready").