OverviewHistoryStatsSecurity
npx skills add ...
Documentation
SKILL.md
npx skills add every-app/open-seo --skill seo-project-setup
Populate a project's shared OpenSEO context — site scope, goals, positioning, competitors, key pages, and preferences — plus MCP checks and Search Console intake.
npx skills add every-app/open-seo --skill seo-project-setup
Interview the user once about one website or SEO project, and store the answers in that project's shared context in OpenSEO with update_project_context. That context is read by every other skill, by SAM in the app, and by the user on the project's Context settings page — so it survives new sessions, new machines, and new agents. This is a 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.
Two project-context MCP tools do all the writing. Both are free — they spend no credits.
get_project_context(projectId): everything already known about the project, plus a missingSections list.update_project_context(projectId, updates): a list of patch ops. The ones this skill uses:
{ section: "business_overview" | "current_goal" | "positioning" | "writing_preferences", content }{ addCompetitors: [{ domain, name?, notes? }] }{ addKeyPages: [{ url, role: "hub" | "spoke" | "money" | "other", topic?, notes? }] }{ customSection: "<slug>", title?, content } for anything that does not fit a typed section{ appendResearchLog: { summary } } when this session spends creditsWrite in batches as the interview progresses — do not hold every answer until the end. Sections are prose (~4,000 characters each), so a few tight paragraphs, not a transcript.
Writes need a projectId, so do this first:
whoami if available.list_projects to confirm the user can access projects.create_project.Do not run research tools just to test connectivity; whoami and list_projects are enough.
Call get_project_context. Show the user a short summary of what OpenSEO already knows and what is missing. Confirm or correct existing entries rather than re-asking questions that are already answered — this skill is often re-run after another skill filled in part of the context.
Ask for:
Write the durable parts to business_overview: what the business does, who it is for, the target markets/locales, and the site's current stage.
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."
Write the result to current_goal, including the metric and timeframe.
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.
Write to positioning: audience, the problem, the differentiator, and any claims the user wants defended. Ask about voice, banned words or phrases, and topics to avoid, and write those to writing_preferences — content-drafting workflows read that section.
Turn the competitors and substitutes from step 5 into addCompetitors entries: one row per domain, with a short notes line on why they matter ("direct competitor, owns the comparison pages"). If the user is unsure who competes in search, find_serp_competitors on a handful of seed keywords will name them — confirm the list with the user before saving, and log the spend.
Competitors saved here are reused by competitive-landscape, competitor-analysis, and link-prospecting.
Ask for or discover:
Save the pages that actually matter with addKeyPages — money pages, topic hubs, and the linkable assets. This is a curated shortlist, not a site inventory: 10 to 30 URLs is normal. Give each one a role and, where known, the topic it targets.
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 a local working folder (see step 9).
Recommended exports:
Ask them to drop files into gsc/ and use names like:
Project knowledge lives in OpenSEO, not on disk. A local folder is still useful for the things that are actually files: GSC CSV exports, crawls, drafts, briefs, and reports.
If the user wants one, suggest ~/SEO/<company-or-site>/ or a folder beside the website/content repo, with a structure like:
Do not create folders unless the user asks, and do not duplicate goals, positioning, or competitors into a local file — that is what the project context is for.
After intake, recommend one next OpenSEO workflow:
seo-audit: when the site already exists and the user wants to know what to fix or do first, especially if they are new to SEOkeyword-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:
Tell the user they can read and edit everything saved here on the project's Context settings page.
get_search_console_performance confirms it (it returns a "not connected" message otherwise).