Menu
(support) Discover connected analytics sources, pull data, write .seo/data/ snapshots, and visualize results with deltas vs prior pulls.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Run the full autonomous pipeline against a work item — plan, implement, verify, PR, post-PR review + QA, wrap-up. Takes a GitHub issue
The Notion bridge for work items — creates a Notion work item mirroring a GitHub issue, uploads artifacts (item.md, refs/, plan.md, wrapup.md) to it, and pulls a work item's artifacts down to ./tmp/<id>/. Used by /create-feature, /create-epic, /create-issue (publish) and /do (pull before work, upload after). Use when a work item needs to be published to, updated in, or fetched from Notion.
Create Excalidraw diagram JSON files and PR visual overviews that make visual arguments. Use when the user wants to visualize workflows, architectures, concepts, pull request changes, before/after behavior, or a shareable explainer image for reviewers.
Dispatches one Codex (GPT-5.6) sub-agent via `codex exec` — implementer, backend-verifier, plan-reviewer, code-reviewer, code-researcher, or investigator — and returns its report. Used by /do, /discussion, and /create-issue whenever one of these roles runs; not normally invoked by the user directly. Use when a pipeline stage needs its Codex sub-agent dispatched, resumed for a fix round, or re-run.
Captures a discussed multi-phase workstream as an Epic Spec work item ready for /do. For a single-outcome change use /create-feature instead.
Captures a discussed feature as a lean Feature Ticket work item ready for /do. For multi-phase workstreams use /create-epic instead.
| name | seo-data-pull |
| description | (support) Discover connected analytics sources, pull data, write .seo/data/ snapshots, and visualize results with deltas vs prior pulls. |
| allowed-tools | ["Read","Write","Bash","PowerShell","Glob","Grep","Agent","WebSearch","WebFetch","mcp__posthog__*","mcp__composio__*"] |
| when_to_use | This is a support skill. Don't invoke it directly. Other SEO skills (seo-briefing, seo-readability-pass, seo-authority-pass, seo-content-strategy, seo-content-drafting) call it as their first step when they need fresh data. If .seo/data/ is stale or missing, any SEO skill should run this first. |
| model | claude-opus-4-6 |
Discover what analytics, search, and SEO tools are connected, pull data from
all of them, write structured snapshots to .seo/data/, and present a
formatted visualization with deltas vs prior pulls.
This is a support skill. It runs as the initial stage of other SEO skills, not as a standalone workflow.
.seo/data/ with fresh snapshots from every connected source.If a source isn't connected, note the gap. Never fail because a source is missing. Work with what's available.
Before pulling new data, check for the most recent prior snapshot:
.seo/data/manifest.md — check the timestamp. If fresh (<24h), skip
the full pull and jump to Step 7 (visualize from existing data)..seo/archive/ — find the most recent dated directory (e.g.,
.seo/archive/2026/06/24/data/). If one exists, read the prior
analytics.md and search-console.md to extract baseline numbers for
delta comparison.Store the prior metrics in memory for use in Step 7.
Success criteria: Know the prior pull's key metrics (clicks, impressions, pageviews, visitors, downloads) or know this is the first pull.
Check what analytics, search, and SEO tools are available:
List what's connected and what's not.
Then discover the schema. Don't assume generic $pageview is all that's
available. Query the analytics source for:
download_started, signup, cta_clicked)git_email, plan, company)$referring_domain, $geoip_org)This discovery step makes the pull intelligent without hardcoding any specific
project's schema. A project with download_started events gets download
funnels; a project without them gets pageview-only analytics.
Success criteria: Know exactly which sources are available AND what data dimensions each source can provide.
From whatever analytics source is connected, pull everything the discovered schema supports:
Core (always pull):
Referrers (always pull):
If custom conversion events exist (discovered in Step 2):
If person-level properties exist:
If geo/org properties exist on events:
If the project has published packages (discovered from package.json, setup.py, or project config):
If a public code repository exists (discovered from project config):
Write everything to .seo/data/analytics.md.
If no analytics source is connected, write a stub noting the gap.
Success criteria: .seo/data/analytics.md exists with the deepest data
the discovered schema supports — not just pageviews.
From Google Search Console (if connected):
Write to .seo/data/search-console.md.
Success criteria: .seo/data/search-console.md exists.
From Ahrefs, Semrush, or similar (if connected via Composio):
Write to .seo/data/seo-tool.md.
If no SEO tool is connected, write a stub noting the gap and what data is therefore unavailable.
Success criteria: .seo/data/seo-tool.md exists.
Write .seo/data/manifest.md listing:
Success criteria: .seo/data/manifest.md exists. Any SEO skill can read
this to know what data is available.
This is the most important step. Do NOT skip it. After writing the data files, present a formatted dashboard to the user. This output goes directly into the conversation — it is NOT written to a file.
Format:
## Dashboard — {date}
### Headlines
| Metric | Current | Prior | Δ |
|------------------|---------|--------|---------|
| GSC clicks (28d) | 687 | 648 | +6% ▲ |
| Impressions | 18,521 | 17,696 | +5% ▲ |
| Pageviews (30d) | 6,199 | 5,800 | +7% ▲ |
| Unique visitors | 2,387 | — | — |
| Downloads (7d) | 1,109 | 980 | +13% ▲ |
| Stars | 236 | 224 | +12 ▲ |
### Top Pages (GSC)
| Page | Clicks | Imp | CTR | Pos |
|------|--------|-----|-----|-----|
### Referrers (7d)
| Source | Views | Uniques |
|--------|-------|---------|
### LLM Channel (7d)
| Source | Views | Uniques |
|--------|-------|---------|
### User Segments (if person properties discovered)
{render whatever segments the schema discovery found — work emails,
plan tiers, geo clusters, org names. Adapt the table shape to the data.}
### Notable Changes
- {bullet points highlighting what moved, new entries, records}
### Instrumentation Suggestions
{Based on what the schema discovery found AND what it didn't find,
suggest 1-3 concrete, platform-agnostic improvements that would make
future pulls richer. Focus on gaps that block clearer funnels or
audience understanding.}
Examples of good suggestions:
- "No conversion event found. Adding a `signup_completed` or
`download_started` event would let future pulls show conversion
rates by page and referrer."
- "Person properties have no company/org field. Enriching users with
a `company` or `domain` property (via reverse-email lookup, form
field, or SSO claim) would unlock audience segmentation by org."
- "Referrer data exists but no UTM parameters are tracked. Adding
`utm_source`/`utm_medium`/`utm_campaign` to links would separate
organic from paid and show which campaigns drive conversions."
- "Pageviews exist but no session-level events (session_start,
session_end). Adding session tracking would enable time-on-site
and bounce rate metrics."
- "Conversion events exist but aren't tied to the page that drove
them. Passing `source_page` or `referrer_path` as a property on
conversion events would close the attribution loop."
Rules for suggestions:
- Only suggest what the CURRENT schema is missing — don't repeat
suggestions for things already tracked
- Be specific about what to name the event/property and what it
unlocks ("would let future pulls show X")
- Keep it to 1-3 suggestions, prioritized by impact on funnel
clarity or audience understanding
- These are suggestions, not demands — the user accepts or ignores
them, and the skill adapts to whatever schema exists next time
Delta rules:
Success criteria: The user sees a formatted, scannable dashboard in the conversation with deltas highlighted, plus actionable suggestions for improving their instrumentation over time.
If .seo/experiments.md exists, check if any experiments reference pages or
queries that were just pulled. If an experiment's review date has passed and
it has no "Result" section yet, flag it in the manifest as "experiment awaiting
measurement" so the briefing skill knows to evaluate it.
Success criteria: Manifest notes any experiments that need evaluation.
Data snapshots are considered stale after 24 hours. If .seo/data/manifest.md
exists and its timestamp is within 24 hours, other skills can skip re-pulling
and jump directly to Step 7 (visualize from existing data).
If it's older, re-run from Step 1.
The .seo/ directory MUST be committed to the repo after every pull. This is
not optional. If .seo/ stays local-only, future worktrees and sessions lose
access to prior snapshots, breaking delta comparisons and experiment tracking.
After writing data files, stage and commit .seo/ as part of the normal
workflow. If there's a PR flow, include it in the PR. If pushing directly,
commit it alongside content changes. Never leave .seo/ as untracked local
files.
Different analytics platforms have different API surfaces. Some have multiple (legacy and modern). During the discovery step, test which API surface works and note it in the manifest. If one endpoint returns errors, try alternatives before reporting the source as unavailable.
Always commit the .seo/ directory to the working branch after a data pull.
Git history provides the historical record that future briefings use to measure
experiment impact. Never add .seo/ to .gitignore.