一键导入
seo-project-setup
Set up a durable local SEO workspace with project context, notes, goals, positioning, preferences, MCP checks, and Search Console data intake.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Set up a durable local SEO workspace with project context, notes, goals, positioning, preferences, MCP checks, and Search Console data intake.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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").
| name | seo-project-setup |
| description | Set up a durable local SEO workspace with project context, notes, goals, positioning, preferences, MCP checks, and Search Console data intake. |
Help the user set up a local SEO workspace for one website or SEO project. The folder is where the agent saves notes, goals, exports, briefs, reports, preferences, and project context over time. This is a workspace and context setup workflow, not a full audit.
Be friendly, practical, and structured. Ask questions in small batches. Explain why each item matters only when useful. Do not overwhelm a beginner with jargon.
Suggest that the user choose or create a local folder for SEO work, for example:
~/SEO/<company-or-site>/~/Documents/SEO/<company-or-site>/Explain that keeping notes, exports, briefs, scraped pages, reports, and preferences in one folder helps the agent build context over time. Future SEO workflows can use that folder rather than starting from a blank conversation.
Recommended starter structure:
seo-workspace/
README.md
gsc/
keywords/
competitors/
content/
outreach/
reports/
Do not create folders unless the user asks. If file tools are available and the user asks, create a simple structure and a short README.md with the current goals, known sites, and user preferences for how the agent should approach SEO for this project.
Ask for:
Ask the user what they want from SEO:
Ask for success metrics and timeframe. If goals are vague, help turn them into measurable goals such as "increase non-branded organic signups" or "rank top 10 for 20 buying-intent terms."
Ask what research they have already done about the company, product, audience, and competitors. Request any notes, docs, customer interviews, positioning docs, pitch decks, landing pages, or strategy memos they can share.
Probe for:
If the user has not done this yet, offer to help research positioning using the company website, competitor pages, reviews, forums, and web search.
After the user has described the company, website, goals, and positioning, check that OpenSEO MCP is configured and mapped to the right project:
whoami if available.list_projects to confirm the user can access projects.Do not run research tools just to test connectivity; whoami and list_projects are enough.
GSC is the richest first-party signal: existing impressions, near-ranking terms, cannibalization, and pages that already have search demand.
Preferred (hosted): connect it natively. On the project's Integrations page, connect Google Search Console and pull live data with get_search_console_performance. Once connected, the agent reads it directly in keyword-research and keyword-clustering — no manual files to maintain.
Fallback (self-hosted, or if the user prefers files): ask the user to export CSVs from Search Console into the SEO working folder.
Recommended exports:
Ask them to drop files into gsc/ and use names like:
gsc/queries-last-3-months.csv
gsc/pages-last-3-months.csv
gsc/queries-last-16-months.csv
gsc/pages-last-16-months.csv
Ask for or discover:
After intake, recommend one next OpenSEO workflow:
keyword-research: when the user needs ideas from seed topicskeyword-clustering: when they have keywords or GSC data to map to pagescompetitive-landscape: when the market is unclearcompetitor-analysis: when they know a competitor to studylink-prospecting: when they have a linkable asset or target pageUse a checklist with statuses:
| Step | Status | Notes | Next action |
|---|
Then summarize:
get_search_console_performance confirms it (it returns a "not connected" message otherwise).