Skip to content

Capabilities

Propagation

When a new article lands on The Marketing Show (or an existing one changes), propagation is the process of scanning the rest of the site for places that should now link to that article, and for places that the new article should link to. The output is a set of inline wiki-links that keep the knowledge graph dense without hand-curation.

The output is always presented as a set of red/green diffs — like a GitHub pull request — for review before any file is touched.

  • After creating any new article in ~/apps/themarketingshow/content/.
  • After rewriting or adding a section to an existing article.
  • After fixing a link or restructuring prose that might affect graph connections.
  • When you say: “propagate,” “run the links,” “connect this,” “propagate this post.”
/propagate

With no argument, Claude finds the most recently edited article in content/. To propagate a specific file, pass its path.

RequirementWhere
The Marketing Show repo~/apps/themarketingshow/
Dev server running (for visual review)cd ~/apps/themarketingshow && npm run dev on port 3000
Affiliate config~/apps/themarketingshow/src/config/affiliates.ts
Marketing stack map~/apps/themarketingshow/src/data/marketing-stack.ts
  • Skill definition: ~/.claude/commands/propagate.md
  • Authoritative SOP: ~/apps/themarketingshow/CLAUDE.md under Propagation Is Mandatory (SOP) and Propagation Report Format.
  1. Read the target article. Extract the top 15-20 significant keywords — tools, people, concepts, brand names. These are the search terms.
  2. Search the entire content/ folder. Every entity, every subfolder. Not just the category the article landed in.
  3. Read and evaluate each match. Decide if a wiki-link belongs in each candidate file. Quality over quantity — do not force connections.
  4. Check the affiliate config. Every tool mentioned should have a wiki-link if an internal page exists. If an affiliate applies, pair wiki-link with an explicit affiliate CTA.
  5. Check the marketing stack map. Does the new article warrant a map entry? Not everything does. Tutorials and one-off tips usually do not.
  6. Update the new article. Add wiki-links to existing pages the article mentions (outbound edges).
  7. Propose as diffs. Present file-by-file red/green diffs — one fenced diff block per change. No “also considered” list. No “no change” narration.
  8. Wait for explicit approval. No file is touched until James says “yeah” or “apply.”
  9. Apply, open changed pages, commit. Each changed page gets opened in the browser with a #:~:text= highlight so James can verify visually before the commit lands.

Every proposal follows the same shape:

Entities searched: yt-dlp, Whisper, ffmpeg, ...
### `path/to/file.md`
One-line reason for the change.
```diff
- Original sentence with enough context for the change to make sense.
+ Rewritten sentence with the new [[wiki-link]] or context woven in.

Apply these?

GitHub renders the `diff` fence red and green. VS Code's markdown preview does too. The visual match between proposal and final commit is the whole point.
## Example Session

James: propagate the new YouTube transcript post

Claude: Running /propagate. Reading the post, extracting entities.

Entities searched: yt-dlp, Whisper, ffmpeg, youtube-transcript-api,
OpenAI, transcript, transcribe, captions, YouTube, Claude
### content/ai/claude.md
The "YouTube to Everything Workflow" section tells readers to
"let it auto-transcribe" but leaves the actual how to imagination.
The new post is exactly that how.
```diff
- Upload an unlisted video to [[YouTube]], let it auto-transcribe,
- then paste the transcript into a Claude Project.
+ Upload an unlisted video to [[YouTube]], [[three-ways-pull-youtube-transcript
+ |pull the auto-generated transcript]], then paste it into a Claude Project.
```
... (three more diffs) ...
Apply these?

James: yeah Claude: [applies all five edits] [opens each changed page with highlight] Pages up for visual check. Commit when you say.

## Rules (Enforced by the Skill)
- **Propagation is mandatory.** If you touch a page, you propagate it. No exceptions for "short" articles or "minor" edits.
- **Search the ENTIRE `content/` folder.** Not just the category subfolder.
- **Wiki-link only to pages that exist.** If the target does not exist, use plain text or check `content/root/backlog.md` — if the topic is already queued there, mention it; otherwise propose adding it.
- **No self-referential wiki-links.** A page cannot wiki-link to itself.
- **No wiki-links in headings.** Headings stay plain text.
- **Inline and natural.** Links woven into prose, not dumped in a "See Also" section at the bottom.
- **Diff-only reporting.** The report shows only files that change. No roll-up of near-misses, no "I considered X but skipped it" narration.
## Known Gaps / TODOs
- **No automatic trigger on article save.** Propagation still has to be invoked manually. A file-watcher that prompts "new article detected, want to propagate?" would close the loop.
- **No cross-repo propagation.** An article on themarketingshow.com might warrant a wiki page on `internal.themarketingshow.com`, or vice versa. The skill only scans one repo at a time.
- **Entity extraction is heuristic.** The "top 15-20 keywords" step is Claude's judgment, not a deterministic NLP pass. Occasional misses happen, especially for obscure tool names buried deep in an article.
## Related
- [Create a Blog Post](/capabilities/create-blog-post/) — generates the article that propagation then connects into the graph.
- [Get a YouTube Transcript](/capabilities/youtube-transcripts/) — the article whose propagation was the first run through the tightened diff-based flow (2026-04-18).