~/opencode · OpenCode Prompts: 13 SEO Use Cases

dark

OpenCode Prompts: 13 SEO Use Cases

Companion to paper.md. Each section is a complete, copy-pasteable OpenCode custom command. Save each one as a markdown file in .opencode/commands/ (per-project) or ~/.config/opencode/commands/ (global), then run it in the TUI with / + filename.

Command syntax notes:

1.SEO Article Writer seo-article.md

Draft-to-publish pipeline with a quality checklist gate. The agent writes to a markdown file and stops; you edit, approve, and publish.

---
description: Write a SEO article from a brief with a quality checklist gate
agent: build
---

Write a complete SEO article for the topic: $ARGUMENTS

## Process
1. Read @content-brief.md and @style-guide.md if they exist in the repo root; if not, ask me for the target keyword, primary intent, audience, and desired word count before starting.
2. Research the current SERP for the target keyword to identify subtopics and entities competitors cover.
3. Draft the article and save it to `content/drafts/{slug}.md`.
4. Run the quality checklist below against your own draft and report PASS/FAIL per item.
5. If any item fails, fix it before presenting the final draft.

## Quality checklist (all items must PASS)
- [ ] Primary keyword in title tag, H1, meta description, and first 100 words
- [ ] One clear H1; logical H2/H3 hierarchy; no skipped heading levels
- [ ] Word count within +/-15% of the brief target
- [ ] At least one concrete statistic, cited to a named source (never invented)
- [ ] Covers at least 3 subtopics found in competitor SERP research
- [ ] Internal links to 2-5 existing relevant pages (verify they exist in @sitemap.xml or the repo)
- [ ] No fluff, no keyword stuffing, no duplicate paragraphs
- [ ] E-E-A-T signals: author name, date, and a "why this is trustworthy" line where relevant

## Output format
Report: draft file path, checklist results, and a one-paragraph summary of what you wrote and why. Do NOT publish anything. I will review and approve.

Usage: /seo-article "on-page SEO checklist for 2026"

2.On-Page Optimizer onpage-optimize.md

Rewrite titles, metas, and heading structures across many pages from a single command. Emits a reviewable diff.

---
description: Rewrite title tags, meta descriptions, and headings across pages
agent: build
---

Optimize on-page SEO elements for the pages in $ARGUMENTS (a file path or glob).

## Process
1. Load the target pages (from the given file/glob, or export them from the CMS as HTML/MD into `seo/input/` first).
2. For each page, extract: current title tag, meta description, H1, H2s, and the page's primary keyword (from @seo/keyword-map.csv if present).
3. Rewrite each element per the rules below.
4. Write all proposed changes to `seo/output/onpage-changes.md` as a table (page, element, current, proposed, reason).
5. Do NOT modify any page file. I will review the table and apply.

## Rules
- Title: 50-60 characters, primary keyword near the front, brand suffix optional, no keyword stuffing
- Meta description: 140-160 characters, action-oriented, includes primary keyword and one differentiator
- H1: contains primary keyword variant, describes exactly what the page delivers, never duplicated site-wide
- H2s: support search intent (question/informational for blogs, feature/comparison for product pages)
- Preserve any existing internal links; flag any duplicate titles you find across the set

## Output format
A markdown table plus a short list of cross-page issues (duplicates, thin titles, missing metas). No page files touched.

Usage: /onpage-optimize seo/input/pages/*.md

3.Technical SEO Auditor seo-audit.md

Repeatable, diffable technical audit run against the repo itself. Run on every deploy.

---
description: Run a full technical SEO audit against the codebase
agent: build
model: anthropic/claude-3-5-sonnet-20241022
---

Run a full technical SEO audit of this repository and write the report to `seo/reports/audit-{date}.md`.

## Checks (run each, record evidence)
1. **robots.txt** — exists, reachable, no accidental "Disallow: /" on production content, sitemap referenced
2. **Sitemap** — valid XML, matches the actual route map, no 404 URLs, no noindex pages listed
3. **Canonicals** — every template/page emits a self-referencing canonical; check for self-consistency with the router
4. **Indexability** — find any pages blocking indexing (noindex meta, X-Robots-Tag) and list them with reasons
5. **Core Web Vitals inputs** — scan client bundles and images: largest images lack width/height or lazy-loading, render-blocking resources, CLS-prone layout shifts
6. **Redirects** — check redirect map for chains and loops
7. **Structured data** — every page emitting schema passes a JSON-LD validity check (see /schema-generate)

## Evidence
Run the actual commands (e.g. `npm run build`, grep for `noindex`, validate the sitemap with an XML parser) and paste real output. If a check cannot be run, say so explicitly.

## Output format
Per check: STATUS (PASS / FAIL / NOT RUN), evidence, and the exact file/line to fix. End with a prioritized fix list (P0 = blocks indexing, P1 = hurts performance, P2 = hygiene).

Usage: /seo-audit

4.Technical SEO Fix Executor seo-fix.md

Implement the fixes the audit found — in a reviewable PR-style change, never directly on production.

---
description: Implement technical SEO fixes as a reviewable diff
agent: build
---

Implement the SEO fixes described in $ARGUMENTS (a report file or a paste of the audit findings).

## Fixes I can apply
- robots.txt: add/remove/disallow rules, add sitemap reference
- Sitemap: regenerate from the route map, remove noindex URLs
- Canonicals: correct or add canonical URLs in templates
- Redirects: fix chains/loops in the redirect map
- Structured data: fix invalid JSON-LD (validate after)
- Performance inputs: add width/height or lazy-loading to images, remove render-blocking resources where safe

## Process
1. For each fix, make the minimal change in the source (not generated output).
2. Re-run the relevant audit check (from the /seo-audit command) to prove the fix works.
3. Group all changes into a single diff summary and show it to me.
4. Do NOT commit, push, or deploy. I will review and merge.

## Guardrails
- Never touch production infrastructure
- Never change URLs or remove pages without explicit confirmation
- If a fix requires a decision I haven't made, flag it and stop for that item

## Output format
Per fix: file changed, what changed, audit re-check status. End with "READY FOR REVIEW — no changes committed."

Usage: /seo-fix seo/reports/audit-2026-08-02.md

5.Schema Generator schema-generate.md

Generate and validate JSON-LD for a page in one pass.

---
description: Generate and validate JSON-LD structured data for a page
agent: build
---

Generate JSON-LD structured data for: $ARGUMENTS (a page file or URL).

## Process
1. Read the page content and extract: entity type(s), title, description, key facts, publish/modified dates, images, breadcrumbs, and any relevant identifiers.
2. Choose the schema types that actually apply (Article, Product, FAQPage, LocalBusiness, BreadcrumbList, etc.). Do not add types the page does not support.
3. Generate the JSON-LD and save it to `seo/schema/{slug}.json`.
4. Validate the JSON syntax and required properties for each type. Fix any errors.
5. Show me the final JSON-LD with the validation result. Do not inject it into any page.

## Rules
- Required fields per type must be present and correctly typed
- FAQPage only if the page genuinely has questions + answers (no SEO-only FAQs)
- Article schema must include author, datePublished, dateModified, and mainEntityOfPage
- Prices, ratings, and review data must come from real source data — never invent them

## Output format
The validated JSON-LD block, the schema types chosen and why, and the validator result (pass/fail with errors).

Usage: /schema-generate content/pages/landing.md

6.Programmatic SEO Generator pseo-generate.md

Template + data → thousands of pages with thin-content gates. Run in preview mode first.

---
description: Generate programmatic SEO pages from a template and data file
agent: build
subtask: true
---

Generate programmatic SEO pages from the template and data in $ARGUMENTS (template file + data file, space-separated).

## Inputs
- Template: a markdown/HTML file with placeholders like {{name}}, {{city}}, {{description}}
- Data: a CSV/JSON file with one row per page to generate

## Process
1. Read the template and data file. Confirm the placeholder set matches the data columns.
2. Generate one page per data row into `content/pages/` following the existing URL structure.
3. Run the quality gates below over the whole generated set.
4. Report gate results and the list of generated files. Do NOT publish or commit.

## Quality gates (per page, must PASS)
- [ ] Unique content: body shares less than 40% word-overlap with any other generated page
- [ ] Minimum length: at least 300 words of genuinely unique, useful content
- [ ] No placeholder values left unresolved (empty {{ }} anywhere)
- [ ] Title/meta unique across the set
- [ ] One internal link to a hub/category page that actually exists
- [ ] Human value check: the page answers a real question a searcher would ask for this row

## Guardrails
- If any gate fails at scale, stop and propose a template/data fix rather than forcing pages through
- This is explicitly NOT a tool to mass-produce thin pages. Google's scaled content abuse policy penalizes those.
- Flag any data rows that would produce near-duplicate or useless pages so I can exclude them.

## Output format
Gate pass rates (X/Y pages), the top failure reasons, generated file count, and a preview list of 5 sample URLs for me to review.

Usage: /pseo-generate templates/location.md data/locations.csv

7.Keyword Strategist keyword-strategy.md

Keyword research, intent clustering, and topic-cluster output — a working document, not a decision.

---
description: Research keywords, cluster by intent, and output a content strategy map
agent: build
---

Research the keyword space for: $ARGUMENTS (a seed keyword or business/domain description).

## Process
1. Identify the seed topic and its obvious variants (head term, long-tail, questions, geo/qualifier modifiers).
2. For each keyword, classify search intent: informational / transactional / commercial-investigation / navigational.
3. Cluster keywords into topic clusters with a suggested hub page and spokes.
4. Cross-reference against @seo/keyword-map.csv (if present) to mark keywords already covered vs. gaps.
5. Write the plan to `seo/output/keyword-strategy.md`.

## Output format
- A table: keyword, intent, estimated priority (based on relevance + coverage gap, not made-up volume numbers), suggested page type, suggested hub
- A cluster map: hub → spokes with internal-linking hints
- An explicit "do not chase" list (irrelevant, low-intent, or brand-trademark terms)
- Sources for any volume/trend claims, or "estimate, not verified" where I lack data

## Note
I make the strategy decisions. You provide the raw material and structure. Do not invent volume figures; where you have no data source, label the priority as judgment-based.

Usage: /keyword-strategy "home remodeling services"

8.Competitor Gap Analyst competitor-gap.md

Diff competitor SERP coverage against your own content inventory.

---
description: Compare competitor coverage against your site and surface content gaps
agent: build
---

Run a competitor gap analysis for: $ARGUMENTS (a list of competitor domains and the topic/market).

## Process
1. For each competitor domain, fetch or load their published URLs/sitemaps relevant to the topic (from web search or @seo/input/).
2. Extract the subtopics and entities each competitor covers.
3. Load our content inventory (@seo/content-inventory.csv) and diff: what they cover that we do not.
4. Score each gap by (a) how many competitors cover it, (b) how central it is to the topic, (c) whether our site has the authority to rank for it.
5. Write the result to `seo/output/competitor-gaps.md`.

## Output format
- Gap table: subtopic, which competitors cover it, our current status (absent / thin / partial), opportunity score
- Top 10 gaps worth filling, with a recommended page type and target keyword each
- Anything competitors cover that you think we should deliberately NOT chase, with reasoning

## Note
Use real fetched data where possible. Where a competitor's coverage is inferred from search snippets, mark it as such.

Usage: /competitor-gap competitor1.com competitor2.com "project management software"

9.Content Refresh Agent content-refresh.md

Detect decay, draft updates against current sources, queue for review.

---
description: Detect stale content and draft updated versions for review
agent: build
---

Refresh stale content for the pages in $ARGUMENTS (a list, or a file/glob of page paths).

## Process
1. For each target page, compare its publish/update date against the current date and flag anything older than the threshold (default 12 months; override in arguments).
2. Where traffic/engagement data exists (@seo/traffic-data.csv), flag pages with declining or low engagement.
3. For each flagged page, identify what is outdated: superseded statistics, changed facts (prices, policies, features, dates), or weakened structure.
4. Rewrite only the outdated sections against current sources, preserving the page's intent and URLs. Add a "Last updated" note.
5. Save drafts to `content/refresh/{slug}.md` and show a change summary.

## Guardrails
- Do NOT change the URL, permalink, or redirect any refreshed page
- Never invent updated statistics — pull them from real sources and cite them
- Preserve existing internal links and inbound link value (keep anchor text where reasonable)
- If a page is beyond refresh (irrelevant, should redirect), say so instead of forcing an update

## Output format
Per page: what changed, what sources the update uses, old-vs-new key facts. End with a recommend-publish / recommend-redirect / recommend-delete verdict per page.

Usage: /content-refresh content/blog/*.md

11.Local SEO Generator local-seo.md

Location pages, GBP schema, and citations from one source of truth.

---
description: Generate local SEO assets (location pages, GBP schema, citations) from a location data file
agent: build
---

Generate local SEO assets for all locations in $ARGUMENTS (a CSV/JSON of locations).

## Data model (require these columns)
name, slug, address, city, region, postal_code, country, phone, lat, lng, hours, services, description, url

## Process
1. Read and validate the location data file — flag any missing required fields.
2. Generate for each location:
   a. A location page at `content/locations/{slug}/index.md` from @templates/location-template.md
   b. LocalBusiness JSON-LD at `seo/schema/{slug}.json` (validate it)
   c. A citation row (name, address, phone, website, category) for the directory sheet at `seo/output/citations.csv`
3. Generate a location index/hub page linking all locations.
4. Report counts and a review list. Do not publish.

## Rules
- NAP (name/address/phone) must be identical across page, schema, and citation rows
- Hours, services, and description must come from the data file — never invent a location
- Location pages must pass the pSEO quality gates from the /pseo-generate command (unique content, no empty fields)
- Schema must validate; flag any location that would produce invalid data

## Output format
Per-location checklist (page generated, schema valid, citation row ready), total counts, and a list of data-quality issues to fix before generating.

Usage: /local-seo data/locations.csv

12.AI Search Readiness ai-readiness.md

llms.txt, AI-crawler policy, and OKF-style knowledge layer — built and audited, not "hacked."

---
description: Build the machine-readable AI layer: llms.txt, AI crawler policy, structured knowledge file
agent: build
---

Make this site ready for AI search consumption: $ARGUMENTS (optional scope, e.g. a section).

## Process
1. **llms.txt**: generate/update `public/llms.txt` from the content inventory — a curated list of the site's most useful pages with one-line descriptions, grouped by section. Keep it under ~50 entries, best content only.
2. **AI crawler policy**: review robots.txt and confirm explicit decisions for the major AI crawlers (GPTBot, Google-Extended, ClaudeBot, PerplexityBot, CCBot). Output a policy table: bot → allow/deny → rationale. Change nothing without my approval.
3. **Structured knowledge file**: if appropriate, generate a machine-readable knowledge document (OKF-style: entity, description, source URLs, key facts with citations) for the site's core entities into `seo/ai/knowledge.json`.
4. **Answer-readiness spot check**: pick 5 key pages and verify they can answer a factual query directly (clear statement + cited stat + entity clarity) without requiring the AI to infer.

## Honest framing
- llms.txt, OKF, and crawler policy are serving layers for AI assistants — they are NOT ranking signals and will not move your position in AI Overviews on their own
- The ranking work is content quality and structure; this command makes your site correctly *represented* and *served*

## Output format
The generated llms.txt, the crawler policy table (marked PENDING REVIEW where I did not change anything), the knowledge file path, and the 5-page readiness assessment.

Usage: /ai-readiness

13.AI Visibility Monitor ai-visibility-report.md

Track citations in AI answers and generate the team's dashboard on a schedule.

---
description: Generate a scheduled SEO + AI-visibility performance report
agent: build
---

Generate the SEO and AI-visibility report for: $ARGUMENTS (date range, default last 30 days).

## Process
1. Load available signals:
   - Keyword/traffic data from @seo/data/rankings.csv and @seo/data/traffic.csv (or a connected data source)
   - Core Web Vitals regression flags from the last /seo-audit report
   - AI visibility: brand mention/citation counts from the AI-visibility tracker export @seo/data/ai-visibility.csv (if present)
2. Compute deltas vs. the previous period and flag anything moving >10%.
3. Generate the report at `seo/reports/performance-{date}.md` with the structure below.

## Report structure
- Executive summary (3 bullets: what moved, what broke, what to do next)
- Rankings table (keyword, current, previous, delta, trend direction)
- AI visibility table (channel: ChatGPT/Perplexity/AI Overviews; mention count; share-of-voice; top cited pages) — note if data is absent
- Technical health (CWV regressions, crawl blockers, open P0 fixes)
- Recommended actions (top 5, ranked)

## Guardrails
- Never invent metrics — where a data source is missing, write "NO DATA" and explain how to wire it in
- Keep it a document for a human to read; do not auto-send or auto-decide

## Output format
The report file path and a 3-line summary I can paste into Slack.

Usage: /ai-visibility-report last 30 days

Putting It Together: A Minimal Agent Pipeline

The commands above compose. A weekly loop:

/seo-audit            → fixes for /seo-fix
/keyword-strategy     → gaps for /seo-article
/seo-article ...      → drafts for review
/schema-generate ...  → markup for approved drafts
/internal-links all   → links after publishing
/ai-visibility-report → the team dashboard

Run each on its own, review every diff, and keep the human as the last gate before anything touches the indexed web.