Programmatic SEO Page Systems . Agency OS

What it does

Produces a pSEO strategy document, a page template, and the populated dataset that together generate a set of ranking pages from one repeating keyword pattern. It picks from 12 playbooks (locations, comparisons, integrations, personas, glossary, directory, templates, curation, conversions, examples, translations, profiles), designs the URL structure and schema markup, plans the hub-and-spoke internal linking, and sets the indexation strategy. It also emits a pseo-plan-v1 schema block recording the playbook, keyword pattern, planned page count, data sources and build stack. Whether the pages actually go live depends on your stack, which it confirms before designing anything.

Say this to start

This skill has no button. You start it by saying what you want. Any of these will do it:

> programmatic SEO

> pSEO

> location pages

> comparison pages

> generate 100 pages

> templated landing pages

When to reach for it

one keyword pattern repeats across many variables
you hold data nobody else has
a client wants city or suburb pages
competitor comparison pages for a crowded market
integration or persona pages for a product
a glossary or directory built from a real dataset

When NOT to use it

If you actually want	Use this instead
designing and building a single landing page	`frontend-design`
fewer than roughly 30 pages, which is a landing-page project not a pSEO one	`frontend-design`
keyword volume and difficulty research on its own	`keyword-research`
writing one editorial article	`blog-writer`
coding the template's actual HTML and CSS	`frontend-design`
fitting the page set into the site's pillar and content structure	`content-system-architect`

Before you start

What you need	Why
A way to build pages from data: a site codebase you can edit (Astro, Next.js, Hugo, Eleventy, or a plain HTML build script), or a CMS with bulk-page capability (a WordPress custom post type, Webflow CMS collections, or an API or CSV import)	with neither, you get a strategy document, a template and a data file for someone else to implement, not live pages	Required
The dataset itself: one row per page, carrying every field the template renders. For a locations playbook that means per-city local providers, local pricing and local regulations. For comparisons it means real feature-by-feature data on each product. For a directory it means the actual entries and their attributes	a dataset that only holds the variable (the city name, the competitor name) produces the same page repeated, which is the thin-content failure this skill exists to avoid	Required
An answer on where the data came from and how it stays current: first-party, product-derived, user-generated, licensed, or public	the skill ranks defensibility by source and a stale dataset produces a decaying page set	Required
A repeatable keyword pattern with its variables named, e.g. `[service] in [city]`, plus how many unique combinations exist	without the pattern there is nothing to template and no way to size the opportunity	Required
`context.md` in brand memory stating the website and tech stack	the skill confirms the stack against its platform requirements before it designs anything	Required
`brand/[workspace]/verified-claims.md` with any number, result or testimonial that will appear in page copy, marked `consent: ok-as-stated`	unbacked specifics get genericised or marked as a proof gap, and a template claim repeats on every page	Required
`ica-output.md` for search intent and audience language, and `owner-profile.md` for positioning	without them the intro and CTA on each page read as generic filler	Optional
`keyword-plan.md` from a prior keyword-research run	patterns anchor to already-validated targets instead of estimated demand	Optional

How it runs

Stack checkBefore designing anything, it confirms you have a codebase or a bulk-page CMS. If you do not, it says so plainly and offers the honest fallbacks: strategy and handoff, a scoped manual batch of the 10 to 25 highest-value pages, or a stack change scoped as its own separate project.
Load contextDetects whether the workspace is your agency (_default) or a client (client--*), loads the brand files subject to freshness rules, and reads past learnings.md entries tagged programmatic-seo.
Initial assessmentAsks what the product is, who the audience is, what a visitor should do on these pages, what repeatable search patterns exist, how many pages that implies, who currently ranks, and whether the site's authority can realistically compete.
Playbook selectionMatches what the workspace actually has to one of the 12 playbooks. Proprietary data points to Directory or Profiles, a local presence to Locations, a crowded competitor set to Comparisons. Playbooks layer, so 'best coworking spaces in San Diego' is Curation plus Locations.
Pattern and data workValidates aggregate demand and head-versus-long-tail distribution for the pattern, then defines what data populates each page and how it stays current. It will not invent search-volume numbers and labels any estimate [ESTIMATED].
Template designSpecifies URL structure (subfolders, never subdomains), title and meta templates, the content outline, and the uniqueness levers: conditional sections that render only when the data supports them, per-page analysis, and per-page proof drawn from the verified-claims registry.
Linking and indexationPlans hub-and-spoke internal linking with cross-links between related pages and no orphans, adds breadcrumbs and page-type schema (FAQPage, Product, LocalBusiness, BreadcrumbList), and splits sitemaps by page type so indexation is measurable per playbook.
Quality gate and outputRuns the pre-launch checklist on content, proof, technical, linking and indexation, including the two-tier claim check on the template AND on a sample of generated pages. Then writes the strategy document, template and dataset and logs them to assets.md.

What you get

Strategy document: opportunity analysis, chosen playbook or playbooks, data plan, implementation plan, content guidelines. Saved to brand/[workspace]/content/pseo/ in flat mode or brand/[workspace]/products/[slug]/content/pseo/ in product mode
File named [YYYY-MM-DD]-pseo-[playbook]-[topic-slug].md
Page template: URL structure, title and meta templates, content outline with uniqueness levers, and the schema markup to embed
The populated dataset as a CSV or JSON file, when data work is in scope
Internal linking architecture: hub-and-spoke plan, sitemap split by page type, breadcrumb structure
A pseo-plan-v1 schema block recording playbooks, keyword_pattern, page_count_planned, data_sources, url_structure, stack, template_path and status
An entry in assets.md dated and tagged programmatic-seo

Honest limits

Read this before you rely on it

Weak data produces thin pages at scale, and this is the real risk. If your dataset holds only the variable and no per-row facts, every page is the same page with a word swapped. That is the skill's own first-listed common mistake, it fails the pre-launch content gate, and at scale it is doorway-page and thin-content territory rather than simply underperformance. The fix is more data per row, or fewer pages, not a cleverer template.
Bad facts multiply. Wrong data at scale means wrong pages at scale. The skill requires you verify data quality before generation and cannot check the truth of your dataset for you. The same applies to claims: one fabricated specific in the template repeats on every page, which is why the two-tier claim check runs on the template and on a sample of output.
It does not deploy anything. Without a codebase or a bulk-page CMS you receive strategy, template and data files, and the skill is explicit that it must never claim pages are live or built when only templates and data exist.
It will not promise traffic or rankings. Every benchmark number in the skill's own reference material is an internal rule of thumb and may not appear in client-facing copy unless the verified-claims registry backs it.
It does not generate real search-volume or difficulty data, so cannibalisation and over-generation need your judgement. Multiple pages targeting the same keyword, and pages built where no demand exists, are failure modes it names but cannot detect on its own. Chain keyword-research for real numbers, otherwise every figure is flagged [ESTIMATED].

Where people go wrong

The mistake	Do this instead
Bringing a spreadsheet that is just a list of cities or competitor names and expecting pages from it	Bring one row per page with several genuine fields per row: local pricing, local regulations, real feature values, actual entries. If you cannot fill the row, that page should not exist.
Chasing a page-count target	Treat any number as a rule of thumb, not a goal. A small set of pages that each earn their place beats a large set of thin ones, and the thin ones drag the good ones down.
Publishing every combination the pattern allows	Prioritise high-volume patterns for generation and internal-link weight, and noindex the very thin variations instead of publishing them.
Putting the page set on a subdomain	Use subfolders. Subfolders consolidate domain authority, subdomains split it. `site.com/templates/resume/`, not `templates.site.com/resume/`.
Running this for a 15-page build	Below roughly 30 pages, treat it as a landing-page project and chain `frontend-design` instead.
Assuming the strategy document means pages exist	Confirm who is running the generation and where. Strategy, template and data are files, not a live page set.

Worth knowing

Build the uniqueness levers into the template as conditional sections that render only when a row actually holds that data. Rows with richer data then produce visibly richer pages, instead of every page arriving at the same shape with different words in the slots. Pair that with one piece of per-page analysis or insight, and the page set stops looking templated to both readers and crawlers.