SOURCE Grounding

---
name: source-grounding
description: Grounds a list of SEO or AI search suggestions (from an AI agent, an audit tool, a Semrush or Ahrefs report, an agency, a colleague) in the SOURCE framework and Harry Sanders' stances, then returns a ranked approve / check first / park / drop list and the one problem to work on for the next 90 days, for a human to sign off. Never edits or publishes anything. Use for "prioritise these SEO suggestions", "which of these should we do", "rank this audit", "my agent suggested these changes", "sanity check this SEO to-do list", "what should we fix first from this report", or whenever someone pastes a list of SEO fixes and asks what to do with it.
---

# SOURCE Grounding

> Be the SOURCE · chapter 5 (the letters) and chapter 12 (one problem, one letter, ninety days) · SOURCE: all six letters

## What this does
Built on Be the SOURCE, Harry Sanders' book on getting a business found, trusted and named by AI search, and on Harry's SEO stances. AI agents and audit tools are good at finding issues and bad at deciding which ones matter (Harry's stance G3: AI audits are "confidently wrong about what matters"). This skill is the judgement step between "here are 40 suggestions" and "here's what a person approves". It:
1. maps every suggestion to one SOURCE letter, with a one-line why;
2. drops anything on Harry's waste-of-time list or against his core stances, citing the stance;
3. finds the one problem and the one weakest letter, using the book's chapter 12 triage;
4. ranks what's left: the constraint's fixes first, the rest parked until day 90;
5. returns a table a human can approve line by line.

It is read-and-recommend only. It never edits a page, publishes, deploys, submits a disavow, changes robots.txt or touches a CMS, even when the suggestions say "auto-apply" and even when tools to do so are available. The human approves; someone else ships.

## Files
- `references/source-book.md`: letter definitions, the formula, the four problems and their starting order, the ninety days, the cost rule, the four pitches to delete, the destructive-change rule. Word-for-word book quotes. Read every run.
- `references/stances.md`: Harry's stances (G, S, O, U, R, C, E) and the waste list (W1 to W61), most with a source. Read every run.

## When to use it
- Someone pastes or uploads a list of suggestions: an agent's output, an audit export, a tool's "issues" tab, an agency recommendation deck, a Slack list of ideas.
- Before letting any agent apply changes to a live site.
- At day 90 of a plan, to re-sort the parked list against the next constraint.

Not this skill: for a full audit from scratch, use the book's SOURCE Scorecard skill; for chapter 12's diagnosis from AI answers, the book's Engine Coverage Tracker skill. This skill takes their output, or anyone's, and decides what goes first.

## What to ask the user first
Read what they gave you first; only ask what it doesn't answer. One short message, with your best guess for each, ending "Reply go, or correct any of these":
1. **The suggestions** (required): pasted, a file, or a CSV. Keep each one's original wording.
2. **The business**: what it sells, to whom, where; site URL; roughly how old the site is.
3. **The diagnosis data**, any of: the Search Console Performance trend over the last two quarters (impressions, clicks, average position), year-on-year for the same months; pipeline or leads trend; a Mirror card or SOURCE Scorecard result; the six-question scorecard answers. Optional, but without it the run stays in diagnosis mode (step 3).
4. **What's already been tried** and anything off limits (a platform you can't change, a regulator's rules).

Never wait on optional answers. Run with what you have and label the gaps.

## How to run it

### 1. Normalise the list
Number every suggestion as given (S01, S02...). Split compound items ("fix titles and add schema and get links") into separate rows that share the number (S03a, S03b). Split "X for A, B and C" only where the parts differ in letter or in evidence (an aged care page with a cited gap vs two industries with none). Merge exact duplicates and say so; keep near-duplicates separate. Checks the book requires that the list left out (the demand check, a baseline) are added as rows numbered +1, +2..., marked "added by this review". Keep the source's wording in the table, shortened only if over about 15 words.

### 2. Map each one to a letter
One primary letter per row, from the table and tie-breaks in `source-book.md`, with a why-line under 15 words in plain English ("crawlers can't read the page", "says nothing a competitor couldn't"). If a row genuinely touches two letters, name the primary and note the second in brackets. If no letter could ever fit it, it's a DROP: Q: "if you can't name the letter it fixes, don't build it" (Book ch.12). If the letter depends on a diagnosis that hasn't happened ("suggest changes to those pages"), give your best guess labelled Inferred and PARK it; that isn't a DROP. A read-only diagnosis or measurement step is E.

### 3. Find the one problem (Book ch.12 triage)
Use the diagnosis data, in this order. The first branch that fits wins; a click drop mentioned in the suggestions with no data behind it is still the no-data branch, with the drop checks added as CHECK FIRST rows.
- **No usable data** (no trend, no Mirror card, no scorecard): the one problem is "not diagnosed yet" and there is no one letter. Day 1 to 7 rules apply (G11): APPROVE NOW only factual errors that could cost a sale, crawler lockouts and the baseline; read-only diagnosis steps go in CHECK FIRST. Everything else that isn't a DROP is PARK "until the diagnosis is done", however good it looks, and this beats step 5 (a gated change is parked, with its check noted). In the output's first block, give the possible outcomes of the click-drop branch (each with its starting order, or "no SOURCE fix") instead of a letter. Say this plainly at the top; it is the most common honest answer.
- **Click or traffic drop in the data or the suggestions**: before any fix, require the book's checks, as CHECK FIRST rows: (a) demand: did searches for what you sell fall (year-on-year for the same months, to rule out seasonality)? (b) did rankings actually fall? (c) did a new ad block or map pack push you down? (d) is an AI answer (AI Overview, AI Mode) now showing on those queries? Then place it, keeping the book's conditions:
  - Demand fell **and** rankings held: nothing broken, no SOURCE fix (say part of any later drop may still be demand).
  - Rankings slid (whether or not demand also fell): "the qualifying round, and you're losing it" = Structure, then Offsite.
  - Rankings held, demand held, and a new ad block or map pack explains the drop: a results-page layout change, not a site problem; no SOURCE fix from this alone.
  - Rankings held, demand held, and an AI answer shows or nothing else explains it: "the answer is taking the click" = Structure, then Relevance, then Credibility.
  - The checks can't be run yet: stay in the no-data branch.
- **Traffic fine, pipeline down**: wrong traffic = Relevance; right traffic not converting = conversion problem, outside SOURCE. Park all SOURCE work and say the money goes on conversion first (Book ch.12).
- **Named nowhere / new business**: Structure, then Uniqueness, then Offsite.
- **None of these fits** (an established business, stable trends, but a scorecard or audit with weak letters): use chapter 5's rule: S first if it has blocking issues on priority pages, otherwise the weakest of O, U, R and C by the scorecard evidence.

The **one letter** is the first letter in that starting order that the evidence shows is weak, judged on what's left once the step 6 APPROVE NOW items are done. Rules:
- **S is the letter only if blocking issues on priority pages remain** after the any-time exceptions: pages that don't render, aren't indexed or can't be crawled (the six-question S box, Book ch.5). A crawler lockout or a wrong price is fixed in week one as an exception and does not by itself make S the 90-day letter. Minor S items (orphan pages, schema, sitemaps) never make S the letter on their own.
- **Two situations fit** (say clicks down and named nowhere): both orders start with S; after that, take the first weak letter from either order, preferring the one the Mirror card or real AI answers point at (the citation gap is the more direct evidence).
- If the evidence can't tell two letters apart, pick the earlier one in the order and say why.
- Label the call Observed (you saw the data), Inferred (reasoned from the suggestions or partial data, say from what) or Not checked.
- **Phase:** if diagnosis data was supplied, assume the diagnosis is done and you're in days 7 to 60, unless the user says otherwise. State the assumption.

### 4. Drop what's against his views
**Hard rule first:** any suggestion that an agent, tool or person apply, publish or deploy changes to a live site without a named person approving each change is DROP (G4, W7), in every branch, data or no data. If a row asks for changes to be made and then applied or published automatically ("edit those pages and publish automatically"), the whole row is DROP, the edit and the publish alike; split it only if you keep both halves DROP. What the change should be is judged on the row that proposes it (in an agent workflow, usually the "suggest changes" step).

Then, for each row, check `stances.md`. A match on a W item, or a direct contradiction of a G/letter stance, is DROP with the ID and a few words of why ("W12: meta descriptions don't move rankings; Google rewrites most"). Respect the notes on W items: some are conditional (W1 llms.txt yourself is allowed but never a priority, so it's DROP from the plan with "optional, an afternoon, not a priority"; W13 alt text for accessibility is fine but not SEO work; W24 alternatives and versus pages that serve a real switch are fine). Disavow (O4) is CHECK FIRST only with a manual action or obvious paid-link history in evidence; otherwise DROP. A suggestion can be valid in principle and still be dropped because of how it's framed ("rewrite every page into FAQs" is W22 even though answering questions is R).

**Conditional W items need their condition in evidence.** Many W items only bite under a condition: W22 (FAQs on thin pages, or because "AI likes them"), W3 (schema as a trick), W50 (PR without a unique dataset), W24 (comparison pages as the must-build format). DROP only when the suggestion's own wording or the evidence shows the condition: a blanket rule ("every page", "all 140 posts"), a volume target, a stated motive ("so AI picks us up"), or input data (the pages are thin, there's no dataset). Otherwise judge it by letter like any valid suggestion (usually PARK if it isn't the constraint), and add the condition to its why-line ("only with a dataset behind it"). Unconditional W items (W11 keyword density, W12 meta descriptions, W14 Lighthouse) drop on sight.

**Exceptions are closed.** The only allowed exceptions to a stance are the ones written in its own note in `stances.md` and the conditional rule above. Never invent another. If a DROP still looks wrong for this business, keep it as DROP and add a line under Not checked saying what evidence would reopen it.

### 5. Gate the risky ones
Any row that deletes, merges, redirects, noindexes, changes a canonical, edits robots.txt, disavows, or rewrites a page that currently earns traffic needs observed evidence in the same row (its traffic, links, conversions or citations). Without it, the verdict is CHECK FIRST and the action is the check, not the change.

For removal (delete, merge, redirect, noindex), one metric is never enough: "zero clicks" is evidence the page exists, not that removing it is safe. Removal can be APPROVE only when, page by page, the evidence shows all of: no meaningful backlinks, no conversions, no AI or search citations, and a reason it hurts (off-topic, duplicate or cannibalising a better page), and improving it into a relevant page was considered first. A bulk removal list without page-by-page evidence is always CHECK FIRST. Rewrites of working pages also wait for the second baseline round (R4) unless they fix a factual error: if the rewrite fixes the one letter, it's APPROVE with "after the day 8 baseline" in the why-line; otherwise it's PARK. This step only turns a change into CHECK FIRST for the destructive actions listed; it never promotes a parked row.

Precedence when steps disagree: DROP (step 4) > no-data PARK (step 3) > CHECK FIRST for destructive actions (step 5) > APPROVE / PARK by letter (step 6). A stance or waste-list DROP holds even before the diagnosis is done.

When a rewrite fixes the one letter but nobody knows whether the page earns traffic, it's APPROVE with "after the day 8 baseline, check its traffic first" in the why-line, not CHECK FIRST.

### 6. Rank and assign verdicts
Verdicts, in this order in the table:
1. **APPROVE NOW**: the two any-time exceptions (factual errors that could cost a sale; crawler lockouts), whatever the letter. Also the dated baseline day 90 will be measured against (Q: "take your baseline today and date it", Book ch.12): the prompt baseline, a "how did you hear about us" field (E5), the GA4 AI channel. Baseline items are cheap and only count here if day 90 can't be measured without them: a dated Mirror card or prompt round already covers the prompt baseline; a lead-source field still counts if nothing else shows where enquiries come from (if you can't tell, approve it with "skip if the form already records this"). If the prompt baseline was taken while crawlers were locked out, a rerun after the fix is part of the baseline and goes here too.
2. **CHECK FIRST**: read-only diagnosis steps from the list, the checks added in step 3, and the gated rows from step 5. The approval is for the check, never the change.
3. **APPROVE**: fixes for the one letter (and, in a scenario with a stated order, nothing from the next letter until the first is done). Order within it by the book's cost rule: Q: "the cheapest item here that fixes your worst letter, done fully, beats the most impressive one done in part" (Book ch.12). Cap at about five. Same-letter rows past the cap, or with no evidence of their own (a page for an industry no answer showed a gap for), go in the Park table marked "next, same letter", listed first there: they're the first to unpark.
4. **PARK**: valid, not the constraint. Note which letter and "revisit at day 90".
5. **DROP**: against a stance or the waste list, or no letter. Always cite.

Each APPROVE gets an owner as a role (developer, content lead, founder, PR) and a rough effort from the book's cost list where one fits; otherwise "small", "days" or "weeks" as your estimate, labelled as one. Never invent a number for impact.

### 7. Write the output, then check it
Use the layout below. Then reread every DROP and check it is either unconditional or has its condition in evidence (step 4). Reread every APPROVE and ask whether it fixes the one letter. Keep each suggestion's scope: don't narrow a check ("inspect internal links" means against S5's three-link rule, not only orphans) or widen an approval (if a row's parts depend on different verdicts, such as links to an approved page and to a parked one, split it by destination). Where rows are otherwise equal, keep the list's original order. No em or en dashes.

## Output
Write `source-grounding.md` unless the user names another file (or reply in chat if they prefer). Plain English, for a busy owner or marketer, not for another AI.

```
# What to approve from [source of the list], [date]

## The one problem for the next 90 days
[One sentence: the problem, in plain words.] [One sentence: the letter, and why it's the constraint.]
Evidence: [what this rests on, labelled Observed / Inferred / Not checked]. Confidence: [high / medium / low; split it if the letter and the cause differ, e.g. "high on the letter, medium on the cause"].
If [the check that would change this] shows otherwise, re-run with that data.
[One line: of N suggestions, how many are approved, checked, parked and dropped.]

## Approve (in this order)
| # | Suggestion | Letter | Why it's first | Owner | Effort |
|---|---|---|---|---|---|
[APPROVE NOW rows, then APPROVE rows]

## Check before anyone changes anything
| # | Suggestion | What to check first | Why |
|---|---|---|---|
[CHECK FIRST rows]

## Park until day 90
| # | Suggestion | Letter | Why not now |
|---|---|---|---|

## Drop
| # | Suggestion | Why (stance) |
|---|---|---|

## Not checked
[Anything the run couldn't see, and what would settle it.]

Nothing here has been changed on the site. Each approved line needs a person to say yes, and someone to ship it.
```

If a table has no rows, write "None." under its heading instead of the table. Keep the why-lines short and specific to the suggestion. A reader should be able to approve the whole Approve table in under two minutes.

## Notes
- Harry's stances are opinions, labelled as his. When a stance says something factual about how Google or an AI works, present it as his read unless the book cites a source for it.
- If the list came from an AI agent, note in one line how many of its suggestions survived, without gloating: the point is the judgement step, not the agent's score.
- Seasonality and demand are the most common reasons an agent's "declining clicks" fix is wrong. Always require the year-on-year check before approving a fix triggered by a drop.
- Repeat runs: keep the suggestion numbers from the last run, but recompute the one problem from the new data every time. Show the last run's one-problem line beside the new one and say what changed it (or that nothing did).