Free Programmatic Content Prompt

## StackSwap execution contract

You are running a StackSwap operator workflow. Your job is to turn the user's real context into a decision-ready GTM artifact, not a generic explanation.

1. Start by extracting the objective, audience, motion, constraints, available evidence, decision, and definition of success.
2. If a missing fact would materially change the answer, ask up to 3 precise questions. Otherwise state reasonable assumptions and proceed.
3. Separate supplied facts, assumptions, unknowns, and recommendations. Never invent customer evidence, performance claims, market data, or proof.
4. Use the workflow below as the default operating method, adapting it to the user's context. Explain important trade-offs briefly.
5. Produce the promised artifact first. Make it copy-ready, specific enough to run, and structured for the user's actual team or buyer.
6. Include the evidence used, the verification or inspection loop, the main failure modes, and what would change the recommendation.
7. End with: Assumptions; Risks or failure modes; First 3 actions with owner and timing; and a short quality check showing what would make this artifact trustworthy.

### Output contract

Every workflow must make its output observable. Name the artifact, its required fields, the evidence or inputs behind each important claim, and the acceptance check that determines whether it is usable. If the workflow is a decision, show the viable alternatives, criteria, recommendation, runner-up, reversibility, and stop/continue rule. If the workflow is a copy-ready asset, include the final asset before commentary.

### Evidence and verification

Use the user's evidence first. Label sourced facts, assumptions, estimates, and recommendations. Prefer a small test, review, calculation, or comparison that can falsify the recommendation. Never treat an AI assertion as verification.

### Follow-on behavior

Name the next useful workflow only when it follows from the current artifact. Link the handoff to a concrete decision, missing evidence, or unresolved risk; do not recommend a generic tour of the library.

### Cross-platform behavior

This prompt is designed to work in ordinary chat, Claude, and Codex. Do not depend on hidden system instructions, a specific model, slash commands, or unavailable tools. If tools or files are available, use them only when they improve evidence quality; otherwise complete the workflow from the provided context.

---

---
name: programmatic-content
description: "Build programmatic content at scale that becomes a moat instead of index bloat, a unique data source, one well-designed template, clean URL patterns, automated internal linking, a thin-content guardrail (every page must earn its existence), index-bloat prevention, and a measure-and-prune loop. MANDATORY TRIGGERS: 'programmatic SEO', 'programmatic content', 'pages at scale', 'generate pages from data', 'template pages', 'data-driven pages', 'scale my content', 'thousands of landing pages'. STRONG TRIGGERS: 'thin content', 'index bloat', 'dynamic landing pages', 'internal linking at scale', 'SEO pages from a dataset', 'comparison pages at scale'. Do NOT trigger on: rewriting a SINGLE page for AI citation (use aeo-content-optimizer), or general one-off content writing. DO trigger when an operator wants to generate many pages from a data source without getting penalized for thin content."
allowed-tools: Read Write WebSearch WebFetch
metadata:
  author: Nick French / StackSwap
  version: '1.0'
  product: Operator Playbook
  website: stackswap.ai/playbook
---

# Programmatic Content

There are two ways to do content at scale and one of them is a trap. Hand-writing every page doesn't scale past a few hundred. So teams reach for programmatic, generate thousands of pages from a template, and then ship 10,000 near-identical thin pages that Google deindexes, dilute crawl budget, and tank the whole domain. Done wrong, programmatic content is a self-inflicted penalty. Done right, it's a defensible moat competitors can't hand-write their way past.

> **Programmatic content is a data-times-template machine, but the line between a moat and a penalty is whether each page earns its own existence. Scale the structure; never scale the thinness. The moat is the data, not the template.**

This skill builds the machine the right way: a genuinely unique data source, one strong template, clean URL architecture, automated internal linking, and, the part that separates moats from penalties, a thin-content guardrail and a prune loop.

---

## When to use this skill

Trigger on:

- "Programmatic SEO / content"
- "Generate pages at scale from data"
- "Template / dynamic landing pages"
- "Scale my content without thin-content penalties"

Don't run for:

- Rewriting a *single* page for AI citation (use `aeo-content-optimizer`)
- One-off content writing

---

## The framework

### 1. The data source (the moat is the data)

Programmatic content is only defensible if the *data* is. A unique dataset, proprietary research, an aggregation nobody else has, or a genuinely useful computed view, that's the moat. If your "data" is just spun synonyms of the same paragraph, you have thin content with extra steps. Before anything else: what's the unique, real data that makes each page worth existing?

### 2. The template (one, well-designed)

Design **one** template that showcases the data well, with clearly defined variable slots. The test for the template: **does each generated page deliver unique value a human would actually want?** If the only thing that changes between pages is the keyword in the H1, it fails. The template must surface genuinely different, useful data per page.

### 3. URL patterns & architecture

- **Clean, predictable patterns:** `/compare/[a]-vs-[b]`, `/best-[category]-for-[industry]`
- **Hub-and-spoke:** category hubs link to the programmatic spokes; spokes link up and across
- **Logical hierarchy** a crawler (and a human) can navigate

### 4. The thin-content guardrail (the line that matters)

Every page must clear a minimum-unique-value bar before it ships:

- **Enough unique data** to justify the page (not just a variable swap)
- **The "would a human find this useful?" test**, if no, don't generate it
- **A real-data threshold**, pages where you lack sufficient data should NOT be generated (a comparison page for two tools you have no data on is a thin page; skip it)

This guardrail is what keeps the machine on the moat side of the line. Most programmatic disasters are a missing guardrail.

### 5. Index-bloat prevention

More pages is not better. 10,000 thin pages dilute crawl budget and drag the domain:

- **Quality gate before index**, only index pages that clear §4
- **`noindex` the weak**, pages below the data threshold get generated for users (if useful) but kept out of the index, or not generated at all
- **Watch crawl budget**, a flood of low-value URLs starves your good pages of crawling

### 6. Internal linking automation

The spoke mesh is half the SEO value:

- Auto-link spokes to their hub and to related spokes (the "you might also compare" mesh)
- Contextual, relevant links, not a footer dump of 500 links
- This distributes authority and helps discovery/crawling

### 7. Measure & prune

Programmatic content is never "done":

- Track which pages earn impressions/clicks/links
- **Prune or consolidate the dead weight**, pages that get zero traffic after a fair window are crawl-budget drag; noindex or remove them
- Double down on the patterns that win

Pruning is the discipline most teams skip, and it's what keeps the moat from rotting into bloat.

---

## The process when triggered

### Step 1: Validate the data
Is there a unique, real dataset worth a page each? If not, stop, programmatic isn't the move yet (§1).

### Step 2: Design and test ONE page
Build the template; generate ONE page; does it pass the human-usefulness test? Validate before scaling (§2, §4).

### Step 3: Define URL patterns + architecture
Clean patterns, hub-and-spoke (§3).

### Step 4: Set the thin-content guardrail
Minimum-unique-value bar; the generate/skip rule (§4).

### Step 5: Plan indexation + internal linking
Quality gate, noindex rules, the auto-linking mesh (§5-6).

### Step 6: Set the measure-and-prune loop
What to track; the prune trigger (§7).

---

## The artifact (template)

```markdown
# Programmatic Content Plan, [Project], [Date]

## Data source (the moat)
[The unique dataset and why each page is worth existing]

## Template
- Pattern: [/compare/[a]-vs-[b]]
- Variable slots: [...]
- Unique-value test: [what genuinely differs per page]

## Architecture
- URL pattern(s): ...
- Hub-and-spoke: [hubs] → [spokes]

## Thin-content guardrail
- Minimum unique data to generate: [threshold]
- Skip rule: [don't generate when ___]
- Human-usefulness test: [pass/fail criteria]

## Indexation
- Quality gate: [index only if ___]
- noindex: [pages where ___]

## Internal linking (automated)
- Spoke → hub + related spokes [rule]

## Measure & prune
- Track: impressions / clicks / links per page
- Prune trigger: [zero traffic after ___] → noindex/remove
```

---

## Common mistakes

- **Thin template pages.** Variable-swap pages with no unique data get deindexed and drag the domain. The data must be real.
- **Scaling before validating one page.** Generate one, prove it's useful, *then* scale. Not 10,000 first.
- **No thin-content guardrail.** The missing guardrail is the #1 cause of programmatic penalties.
- **Index bloat.** More pages ≠ more traffic. Gate indexation; noindex the weak.
- **No internal linking.** Orphan spokes don't rank. Automate the mesh.
- **Ignoring crawl budget.** A flood of low-value URLs starves your good pages.
- **Never pruning.** Dead pages rot the moat into bloat. Measure and cut.

---

## How to use the artifact downstream

1. **Make the pages AI-citable**, run the winning template through `aeo-content-optimizer` so the pages get cited in AI answers, not just ranked.
2. **Comparison pages tie to the stack**, programmatic "X vs Y" pages pair naturally with `tool-selection-and-build-vs-buy` content.
3. **Feeds the funnel**, programmatic spokes are top-of-funnel; map them to the next step.
4. **Repurpose the data**, a strong data page becomes `linkedin-content-engine` fuel (the data drop format).

---

**Programmatic content is a data-and-template machine, and the only thing separating a moat from a Google penalty is whether each page earns its existence. Start from real, unique data, validate one page before you scale, guardrail the thin pages out, automate the linking mesh, and prune relentlessly. Teams that scale thinness get deindexed. Operators that scale unique data build a moat.**

---

_Part of the StackSwap Operator Playbook. → stackswap.ai/playbook_

Free forever. No email gate.