🎯 wild-scan¶

Pain-quote harvester for the "From the Wild" content series. Searches Reddit, HN, Stack Overflow, dev.to, and other communities for SPECIFIC QUOTES of real people struggling with a topic (e.g., learning DevOps). Indexes quotes by theme, scores them for content potential, and generates "From the Wild" content briefs with instructional repo specs. Run weekly to fuel the content loop.

License: MIT | Security: CLEAN

Install¶

brunnr install wild-scan

Tags: Content & Research

Security Scan¶

CLEAN — 0 findings

This skill passed all 7+1 threat class checks with no findings.

File Info¶

Property	Value
Path	`skills/wild-scan/SKILL.md`
Size	20.1 KB
SHA-256	`5d4114ccee2e9661d080df0ebd0c0970566c0d4682822ebaf2cf6e5f6c5c78be`
README	`skills/wild-scan/README.md`

Skill Prompt¶

Wild Scan¶

Harvest real pain quotes from the internet, index them, and turn the best ones into "From the Wild" content briefs — each backed by a GitHub instructional repo that demolishes the pain point with working code.

Step 0: Load Conventions¶

Before doing ANYTHING, read the shared conventions file:

Read ${SKILLS_DIR}/_conventions.md

This file defines: canonical vault path, folder-to-type mapping, frontmatter contract, valid statuses, tag hierarchy, cross-reference syntax, and the PipelineEnvelope schema. All output from this skill MUST conform to those conventions. If there is a conflict between this SKILL.md and _conventions.md, the conventions file wins.

When to Use¶

Sourcing real quotes for the weekly "From the Wild" content series
Finding specific pain points to target with instructional repos
Building a quote index before writing content
Validating whether a topic has real, quotable pain (not just assumed pain)
Refilling the content pipeline with fresh pain signals

Trigger Phrases¶

"Scan the wild for [topic] pain points"
"Find me quotes about [topic] struggles"
"Run a wild scan on [topic]"
"What are people complaining about re: [topic]?"
"/wild-scan [topic]"
"From the wild: [topic]"

Prerequisites¶

Before starting, establish three things with the user:

Topic focus — What specific area to harvest (e.g., "learning Kubernetes from scratch", "CI/CD pipeline debugging", "Terraform state management"). The more specific, the better the quotes.
Learning stage — Who is struggling? Beginners? Mid-level engineers transitioning to DevOps? Senior devs dealing with tool complexity?
Repo angle — What kind of instructional repo would solve these? (e.g., "step-by-step deploy pipeline", "real-world K8s manifests with commentary", "production-grade Terraform modules with explanation")

If the user provides only a topic, ask about stage and repo angle before proceeding. If they say "just go" or provide all three, proceed directly.

Workflow¶

Topic + Stage + Repo Angle (from user)
    |
Phase 1: Search Planning (define queries, platforms, subreddits)
    |
Phase 2: Quote Harvesting (web search — real quotes required)
    |
Phase 3: Quote Scoring (specificity, intensity, solvability, engagement)
    |
Phase 4: Theme Clustering (group by pain theme)
    |
Phase 5: Content Brief Generation ("From the Wild" post outlines)
    |
Phase 6: Repo Spec (instructional repo that demolishes the pain point)
    |
Output: JSON index + Markdown quote collection + Content briefs → vault

Phase 1: Search Planning¶

Define the search strategy before harvesting anything.

Produce a search plan: - Topic boundaries (what's in scope, what's adjacent but excluded) - Target platforms and specific communities (subreddits, HN, SO tags, etc.) - Search queries (see references/search-playbook.md for templates) - Pain language to target (frustration indicators, help-seeking patterns) - Learning stage filter (what level of quote are we looking for?)

Present this to the user for a quick confirmation. Scope adjustments here prevent harvesting irrelevant quotes.

Platform Priorities¶

Platform	Why	Best For
Reddit	Unfiltered, emotional, high engagement signals via upvotes	Raw pain, frustration, "I wish..."
Hacker News	Technical depth, experienced engineers	Structural critiques, "the real problem is..."
Stack Overflow	Behavioral signals (workarounds, repeated questions)	"How do I actually..." pain
Dev.to / Hashnode	Learning-focused, personal stories	"What I wish I knew...", tutorial critique
Twitter/X	Hot takes, viral frustration threads	Punchy quotes, zeitgeist pain
Discord / Slack (public)	Direct community chatter	Unguarded pain, real-time frustration

Phase 2: Quote Harvesting¶

This phase requires extensive web search. Use real quotes. Do NOT fabricate or paraphrase.

For each platform in the search plan, run targeted searches using the queries from Phase 1. See references/search-playbook.md for search query templates.

Harvesting Rules¶

Exact quotes only. Copy the actual text. Do not paraphrase, summarize, or "clean up" quotes. Typos and all. The rawness is the point.
Attribution required. Every quote needs: username (or anonymized handle), platform, community/subreddit, date (if available), and engagement metrics (upvotes, likes, comments).
Engagement threshold. Prioritize quotes with social proof — upvotes, replies, "same here" responses. A 200-upvote Reddit comment is more valuable than a 2-upvote one because the pain is validated.
Minimum harvest: 15 quotes per run. Aim for 20-30. Cast a wide net; scoring will filter.
No corporate blogs, no marketing content, no course landing pages. We want real humans, not content marketers performing empathy.
Recency matters. Prefer quotes from the last 12 months. Older quotes are acceptable if the pain is clearly still active (check for recent duplicates).
Capture context. Don't just grab the quote — note what thread/question it was responding to. The context shapes how we use it.

What Makes a Quote Worth Harvesting¶

Harvest these: - "I've been doing tutorials for 6 months and I still can't deploy to production" - "Every Terraform tutorial assumes you already know networking. WHERE DO I LEARN NETWORKING?" - "I spent 3 days debugging a YAML indentation error in my K8s manifest. I am losing my mind." - "Serious question: how did any of you actually learn CI/CD? Every resource I find is either 'hello world' or 'here's our enterprise pipeline with 47 stages'"

Skip these: - "DevOps is hard" (too vague) - "I don't like Kubernetes" (no specific pain) - "Check out my new course!" (marketing, not pain) - "The industry needs better tools" (editorializing, not suffering)

Per-Quote Capture Format¶

For each harvested quote, record:

Field	Required	Description
`quote`	Yes	Exact text of the quote
`author`	Yes	Username or handle (e.g., "u/devops_mike")
`platform`	Yes	Reddit, HN, SO, dev.to, Twitter, Discord, other
`community`	Yes	Specific subreddit, HN thread, SO tag, etc.
`url`	Yes	Direct link to the quote (or thread if quote is a comment)
`date`	Best effort	When the quote was posted
`engagement`	Yes	Upvotes, likes, replies, "same" responses
`context`	Yes	What thread/question the quote was responding to
`pain_category`	Yes	One of: tutorial-gap, tool-complexity, real-world-gap, career-transition, information-overload, environment-setup, debugging-hell, missing-fundamentals

Phase 3: Quote Scoring¶

Score every harvested quote on four dimensions. See references/scoring-rubric.md for detailed calibration.

Dimension	Weight	What It Measures
specificity	2x	How specific is the pain? "K8s is hard" = 2. "I can't figure out how to pass secrets from GitHub Actions to my EKS cluster without hardcoding them" = 9.
intensity	2x	How much does this person hurt? Measured by emotional language, effort described, desperation level.
solvability	2x	Can we actually demolish this with a repo? "My company won't adopt DevOps" = 1. "I need a working CI/CD pipeline template" = 10.
engagement	1x	Social proof. Upvotes, replies, "same here" responses. Validates the pain is shared.

Overall score = weighted average: (specificity*2 + intensity*2 + solvability*2 + engagement) / 7

Scoring Discipline¶

Each score MUST be justified with one sentence. Example:

specificity: 8 — "Calls out the exact gap: passing secrets from GitHub Actions to EKS. Not a vague complaint." intensity: 7 — "Used 'losing my mind', described 3 days of debugging. Real suffering, not casual grumbling." solvability: 9 — "A secrets-management tutorial with working GitHub Actions + EKS config would directly solve this." engagement: 6 — "47 upvotes, 12 replies including 3 'same here' responses. Validated pain."

Phase 4: Theme Clustering¶

Group scored quotes into pain themes. A theme is a recurring structural problem that multiple quotes point to.

Theme Format¶

Field	Description
`theme`	Name of the pain theme (e.g., "The Tutorial-to-Production Gap")
`thesis`	One sentence: what structural failure creates this pain?
`quote_count`	How many quotes cluster here
`avg_score`	Average score of quotes in this cluster
`top_quotes`	The 2-3 highest-scoring quotes in this theme
`repo_angle`	What kind of instructional repo would demolish this entire theme?

Clustering Rules¶

Every quote must belong to exactly one theme
A theme needs at least 2 quotes to be valid (1 quote = anecdote, 2+ = pattern)
Themes should be structural, not surface-level. "YAML is annoying" is surface. "Configuration-as-code tools have a documentation gap between 'getting started' and 'production-ready'" is structural.
If a theme has 5+ quotes and an average score above 7, it's a gold theme — flag it for priority content

Phase 5: Content Brief Generation¶

For each theme with avg_score >= 6 (and especially gold themes), generate a "From the Wild" content brief.

"From the Wild" Post Format¶

The content series follows a consistent structure:

1. THE QUOTE (screenshot-worthy, raw, real)
   "I've been doing tutorials for 6 months and I still can't deploy
    a real app to production..." — u/frustrated_junior, r/devops, 234 upvotes

2. THE DIAGNOSIS (what's actually going wrong — the structural problem)
   Every tutorial teaches tools in isolation. Nobody shows the full path
   from code → CI → deploy → observe → iterate. The gap isn't knowledge,
   it's integration.

3. THE HACK (the repo that demolishes it)
   "So we built this." → link to repo
   3-5 key decisions highlighted with code snippets

4. THE WALKTHROUGH (enough to prove it works)
   Step-by-step of the critical path, with git tags for each stage

5. THE CTA
   "Found another one? Drop it in the comments."
   (This is how you crowdsource future quotes)

Brief Fields¶

For each content brief, produce:

Field	Description
`title`	Post title. Punchy, specific. NOT "DevOps is Hard." YES: "Found Another One: 'Every Tutorial Stops at Hello World'"
`featured_quote`	The lead quote for the post (highest-scoring in the theme)
`supporting_quotes`	1-2 additional quotes that reinforce the same pain
`diagnosis`	2-3 sentences: what structural failure creates this pain?
`repo_name`	Proposed GitHub repo name (kebab-case, descriptive)
`repo_description`	One-line repo description
`channel`	Where to post: LinkedIn, blog, Substack, Reddit
`estimated_words`	Target length by channel
`series`	"From the Wild"
`difficulty`	easy, medium, hard — how hard is the repo to build?

Phase 6: Repo Spec¶

For each content brief, spec the instructional repo that demolishes the pain point.

What Makes a Repo "Battle Axe" Level¶

This is NOT a tutorial repo. This is a working, production-grade reference that happens to be teachable. The difference:

Tutorial Repo	Battle Axe Repo
`console.log("Hello World")`	Structured logging with correlation IDs
"Deploy to Heroku"	Multi-environment deploy with rollback
Single `main.tf`	Modular Terraform with state management
No tests	CI pipeline with test, lint, security scan
README says "getting started"	README says "here's what production looks like"
Stops at "it works locally"	Includes monitoring, alerting, runbook

Repo Spec Format¶

Field	Description
`name`	Repo name (kebab-case)
`tagline`	One-line description for GitHub
`pain_addressed`	Which quote(s) this repo directly answers
`structure`	Key directories and files with purpose
`progressive_steps`	Git tags or branches for step-by-step learning (e.g., `step-01-basic` through `step-08-production`)
`key_decisions`	3-5 architectural decisions with "why X not Y" explanations
`battle_axe_features`	What makes this production-grade, not tutorial-grade
`prerequisites`	What the user needs to know before using this repo
`estimated_build_time`	How long to build this repo

Progressive Step Design¶

Every repo MUST have progressive steps via git tags:

step-01-scaffold     — Basic project structure, nothing works yet
step-02-local        — Works locally, manual everything
step-03-containerize — Dockerized, but still manual deploy
step-04-ci           — Automated tests on push
step-05-cd           — Automated deploy on merge to main
step-06-secrets      — Secrets management (not hardcoded)
step-07-monitor      — Logging, metrics, health checks
step-08-production   — The full thing: rollback, alerting, runbook

Each step has its own README section explaining not just WHAT changed but WHY. The "why" is what separates this from every other tutorial.

Output¶

The scan produces files saved to the Obsidian vault:

Vault path: ${VAULT}/

1. Quote Index: `{vault}/Writing/From-The-Wild/{topic-slug}-{YYYY-MM-DD}.md`¶

The indexed collection of all harvested quotes, scored and themed.

---
type: wild-index
date: YYYY-MM-DD
status: active
topic: "[topic focus]"
stage: "[learning stage]"
quote_count: N
theme_count: N
gold_themes: N
tags:
  - content/from-the-wild
  - hunter/domain/{domain-slug}
---

### Wild Scan: [Topic]

**Date**: [date]
**Topic**: [topic focus]
**Stage**: [learning stage]
**Quotes harvested**: N
**Themes identified**: N
**Gold themes**: N (avg score >= 7 with 5+ quotes)

#### Gold Themes

##### 1. [Theme Name] (Avg Score: X/10, N quotes)
**Thesis**: [structural failure]
**Repo angle**: [what would demolish this]

> "[Top quote text]"
> — [author], [community], [engagement]

> "[Second quote]"
> — [author], [community], [engagement]

##### 2. [Next gold theme...]

#### All Themes (Ranked)

| Rank | Theme | Quotes | Avg Score | Top Pain Category | Repo Angle |
|------|-------|--------|-----------|-------------------|------------|
| 1 | [name] | N | X.X | [category] | [angle] |
| ... | ... | ... | ... | ... | ... |

#### Quote Log (All Quotes, Scored)

##### Theme: [Theme Name]

| Score | Quote (truncated) | Author | Platform | Engagement | Category |
|-------|-------------------|--------|----------|------------|----------|
| 8.4 | "I spent 3 days..." | u/name | r/devops | 127 upvotes | debugging-hell |
| ... | ... | ... | ... | ... | ... |

#### Full Quotes

##### Quote 1 (Score: X.X)
> "[Full quote text]"

- **Author**: [username]
- **Platform**: [platform]
- **Community**: [subreddit/thread]
- **URL**: [link]
- **Date**: [date]
- **Engagement**: [upvotes, replies]
- **Context**: [what thread this was in]
- **Pain category**: [category]
- **Scoring**: specificity X, intensity X, solvability X, engagement X

##### Quote 2...
[repeat for all quotes]

2. JSON Index: `{vault}/Writing/From-The-Wild/wild-scan-{topic-slug}-{YYYY-MM-DD}.json`¶

Structured data following the schema in references/output-schema.json.

3. Content Briefs: `{vault}/Writing/Content-Briefs/ftw-{topic-slug}-{theme-slug}-{YYYY-MM-DD}.md`¶

One brief per gold theme (or per theme with avg_score >= 6).

---
type: content-brief
status: backlog
series: "From the Wild"
channel: linkedin, blog
estimated_words: 1500
created: YYYY-MM-DD
ready: true
wild_scan_ref: "{topic-slug}-{YYYY-MM-DD}"
theme: "[theme name]"
tags:
  - content/from-the-wild
  - content/brief
  - content/series/from-the-wild
  - hunter/domain/{domain-slug}
---

### Found Another One: "[Featured Quote Snippet]"

#### The Quote
> "[Full featured quote]"
> — [author], [community], [engagement]

##### Supporting Quotes
> "[Supporting quote 1]"
> — [author], [community]

> "[Supporting quote 2]"
> — [author], [community]

#### The Diagnosis
[2-3 sentences: what structural failure creates this pain? Not a restatement of the quote — the WHY behind it.]

#### The Hack (Repo Spec)
**Repo**: `[repo-name]`
**Tagline**: [one-line description]

##### Structure
[Key directories and files]

##### Progressive Steps
[Git tag progression from basic → production]

##### Key Decisions
1. [Decision]: [Why X not Y]
2. [Decision]: [Why X not Y]
3. [Decision]: [Why X not Y]

##### Battle Axe Features
- [Feature that makes this production-grade]
- [Feature that makes this production-grade]
- [Feature that makes this production-grade]

#### Post Outline
1. **Hook**: The quote itself (screenshot-formatted)
2. **Diagnosis**: [2-3 sentences]
3. **Solution**: "So we built this" → repo link
4. **Walkthrough**: [3-5 key steps highlighted]
5. **CTA**: "Found another one? Drop it in the comments."

#### Channel Adaptations
- **LinkedIn** (400 words): Lead with quote, tight diagnosis, link to repo, CTA
- **Blog** (1500 words): Full walkthrough with code snippets from repo
- **Reddit** (self-post): Post directly in the subreddit where the quote came from. Value-first, no self-promotion smell.

#### Build Estimate
- **Repo difficulty**: [easy/medium/hard]
- **Estimated build time**: [time]
- **Prerequisites for builder**: [what you need to know to build this repo]

Cumulative Index¶

Each wild-scan run produces a new date-stamped file. Over time, the Writing/From-The-Wild/ folder becomes a searchable quote database.

To find previously harvested quotes on a topic:

Glob: Writing/From-The-Wild/*kubernetes*.md
Grep: "tutorial-gap" in Writing/From-The-Wild/

To avoid re-harvesting the same quotes, check existing indices before running a new scan:

Read {vault}/Writing/From-The-Wild/ → scan for duplicate quotes

Integration with Content Planner¶

Content briefs generated by wild-scan are compatible with content-planner's brief format. After a wild-scan run:

Content briefs land in Writing/Content-Briefs/ with series: "From the Wild"
Content-planner picks them up on its next scan
They appear on Content-Plan.kanban.md in the Backlog column
The weekly "From the Wild" post gets scheduled like any other content piece

This means: run wild-scan weekly → content-planner schedules the best brief → you build the repo → you write the post → publish.

Quality Checklist¶

Run this before delivering results:

[ ] Minimum 15 real quotes harvested (not paraphrased, not fabricated)
[ ] Every quote has: exact text, author, platform, community, URL, engagement, context
[ ] No corporate blog quotes, no marketing content, no course landing pages — real humans only
[ ] Every quote scored with per-dimension justification (not just a number)
[ ] Quotes clustered into themes with structural theses (not surface-level groupings)
[ ] Gold themes (5+ quotes, avg score >= 7) flagged and prioritized
[ ] Content briefs generated for all themes scoring >= 6
[ ] Each brief has a repo spec with progressive steps and battle-axe features
[ ] Repo specs include "why X not Y" decisions (not just "what to build")
[ ] Brief titles are punchy and specific (not generic)
[ ] Channel adaptations included for each brief (LinkedIn, blog, Reddit)
[ ] JSON output validates against references/output-schema.json
[ ] All files saved to correct vault paths
[ ] No duplicate quotes from previous wild-scan runs (check existing indices)

Resources¶

references/¶

output-schema.json — JSON Schema for the structured wild-scan output
scoring-rubric.md — Detailed calibration guide for the 4 scoring dimensions
search-playbook.md — Search query templates by platform, topic patterns, and pain-language indicators

README¶

Wild Scan: Pain Quote Harvesting for the "From the Wild" Content Series¶

The best content doesn't start with "I have an idea." It starts with "I found someone screaming into the void — and I know how to help."

The Premise¶

Here is the content strategy most technical educators follow: sit down, think of something you know, write about it, publish it, hope someone cares. It works sometimes. It fails more often. The failure mode is always the same — you wrote about what you found interesting, not about what they are struggling with. The gap between those two things is the gap between content that resonates and content that disappears.

Wild Scan inverts the process. Instead of starting with your expertise and looking for an audience, you start with the audience's pain and bring your expertise to it. The raw material is not your knowledge. It is someone else's suffering. Specifically: real quotes from real humans in real communities — Reddit, Hacker News, Stack Overflow, dev.to, Twitter — expressing real frustration with real problems.

The output is a scored, themed index of pain quotes, each one a potential seed for a piece of content that writes itself. The format: "From the Wild." Found another one. Here is a real person struggling. Here is what is actually going wrong. Here is a GitHub repo that demolishes the problem. You are welcome.

The "From the Wild" Content Format¶

Every "From the Wild" post follows the same structure. The structure is the brand.

1. THE QUOTE¶

Start with the real quote. Exact words. Unedited. Typos and all. This is the hook, the empathy signal, and the proof of market all in one.

"I've been doing tutorials for 6 months and I still can't deploy a real app to production. Every tutorial stops at 'hello world' and I'm left with no idea how to handle logging, monitoring, secrets, or anything that matters in a real environment." — u/frustrated_junior, r/devops, 234 upvotes

The rawness is deliberate. A polished paraphrase says "I understand your problem." An exact quote says "I found you. You are not alone. And I am about to fix this."

2. THE DIAGNOSIS¶

Two to three sentences explaining the structural failure that creates this pain. Not "tutorials are bad." That is a complaint, not a diagnosis. The diagnosis identifies the mechanism:

Every tutorial teaches tools in isolation. Docker over here. Terraform over there. GitHub Actions in a separate tab. Nobody shows the integration — the full path from code change to production deploy to observable system. The gap is not knowledge. It is assembly.

The diagnosis is what separates this format from every other "I feel your pain" content. You are not commiserating. You are explaining why the pain exists at a structural level.

3. THE HACK¶

"So we built this." Link to the repo. This is where the battle axe comes out.

The repo is not a tutorial. It is a working, production-grade reference implementation that happens to be teachable. The difference matters:

Tutorial Repo	Battle Axe Repo
`console.log("Hello World")`	Structured logging with correlation IDs
"Deploy to Heroku"	Multi-environment deploy pipeline with rollback
Single `main.tf`	Modular Terraform with remote state and locking
No tests	CI with test, lint, security scan, build
README says "getting started"	README says "here is what production looks like"
Stops at "it works on my machine"	Includes monitoring, alerting, and a runbook

4. THE WALKTHROUGH¶

Three to five key steps from the repo, highlighted with code snippets. Enough to prove the repo works and to give the reader a taste of the depth. Not a full tutorial — just the critical path.

5. THE CTA¶

"Found another one? Drop it in the comments."

This is how you crowdsource future quotes. Every "From the Wild" post generates leads for the next one. The audience becomes the scanning engine.

The Discipline¶

Why Quotes Beat Ideas¶

The content marketing world runs on ideas. "I should write about Terraform state management." That is an idea. It might be good. It might not. You will not know until you publish it and watch the analytics.

Quotes are not ideas. Quotes are evidence. When you start with a quote — a real human, in a real community, expressing real frustration, validated by real engagement (upvotes, replies, "same here" responses) — you are not guessing whether the topic resonates. You know it resonates. The engagement metrics are right there. The emotional language is right there. The pain is pre-validated.

This is the same principle that drives product signal detection (see the signal-scan skill). The difference is scope and cadence:

	Signal Scan	Wild Scan
Scope	Broad market analysis across 7 signal types	Focused pain-quote harvesting
Output	Market opportunities + ship candidates	Content briefs + repo specs
Cadence	Per-domain, as needed	Weekly, feeding the content loop
Goal	Decide what to build	Decide what to write about

Wild Scan is the content engine that signal-scan is the product engine. Same philosophy — start with evidence, not assumptions — applied to a different problem.

The Evidence Hierarchy¶

Not all quotes are equal. The scoring system (see references/scoring-rubric.md) formalizes this, but the intuition is simple:

Strongest evidence: - Specific problem + emotional language + high engagement + directly solvable with a repo - Example: "I spent 3 days debugging a YAML indentation error in my K8s manifest. I am losing my mind." (r/kubernetes, 189 upvotes)

Strong evidence: - Specific problem + moderate engagement + solvable - Example: "Does anyone have a working example of GitHub Actions deploying to EKS with secrets management? Every tutorial I find uses hardcoded values." (r/devops, 67 upvotes)

Moderate evidence: - General frustration + high engagement - Example: "Kubernetes has the worst learning curve of any tool I have ever used." (r/devops, 312 upvotes)

Weak evidence: - Vague complaint + low engagement - Example: "DevOps is hard." (r/devops, 4 upvotes)

The scoring system quantifies this intuition across four dimensions: specificity, intensity, solvability, and engagement. See the rubric for calibration tables.

The Canon¶

The "From the Wild" format draws on several content strategy traditions. Understanding them helps you execute the format with more precision.

Gary Vaynerchuk — Document, Don't Create¶

Vaynerchuk's core content philosophy: instead of sitting down to "create content," document what you are already doing. Wild Scan adapts this: instead of creating content from your expertise, document what you find in the wild. The shift from creation to documentation makes the process faster, more authentic, and more sustainable. You are a reporter, not an inventor.

Nathan Barry — Teach Everything You Know¶

Barry's philosophy (which powered ConvertKit's growth): teach everything you know, publicly, for free. The generous act of teaching builds trust, audience, and eventually revenue. Wild Scan fits this perfectly — each "From the Wild" post is an act of generous teaching triggered by someone else's pain. You are not gatekeeping. You are responding to a cry for help with a working repo.

Sahil Lavingia — The Minimalist Entrepreneur¶

Lavingia's framework: build in public, start with community, solve real problems for real people. Wild Scan is the content expression of this philosophy. The quotes come from the community. The repos solve real problems. The posts are public building. The CTA ("found another one?") closes the loop back to community.

Patrick McKenzie (patio11) — Writing for Engineers¶

McKenzie demonstrated that engineers can build significant audiences by writing about the intersection of engineering and business with brutal honesty and specificity. His writing is never generic. It is always grounded in specific experiences, specific numbers, specific failures. Wild Scan enforces this discipline by starting every piece with a specific quote from a specific person in a specific community — not with a generic take.

Swyx (Shawn Wang) — Learn in Public¶

Wang's "Learn in Public" essay argues that the fastest way to learn is to share what you learn as you learn it. Wild Scan extends this: learn what others are struggling with, publicly solve it, and document the solution. Every "From the Wild" post is a public learning artifact — you find a pain point, research the proper solution, build the repo, and publish both the problem and the solution. You learn by teaching. The audience learns by watching you solve real problems in real time.

The Content-Market Fit Hypothesis¶

Just as products need product-market fit, content needs content-market fit. Most content fails not because it is bad, but because nobody needed it. Wild Scan's thesis is that content-market fit is achievable before you write a single word — by starting with validated demand (the quote, the upvotes, the engagement) rather than with your own sense of what might be interesting.

The quote is your content-market fit test. If 200 people upvoted someone's frustration with a topic, 200 people will read your solution to that frustration. The demand is pre-proven. All you have to do is supply the solution.

How the Skill Works¶

Phase 1: Search Planning¶

You provide a topic focus (e.g., "DevOps career transition for sysadmins learning to code"), a learning stage (e.g., "early career, some Linux experience, weak on coding"), and a repo angle (e.g., "production-ready infrastructure projects that double as portfolio pieces").

The skill builds a search plan: which platforms, which communities, which search queries, which pain-language indicators. See references/search-playbook.md for the full query template library.

Phase 2: Quote Harvesting¶

Extensive web search across Reddit, HN, Stack Overflow, dev.to, and Twitter. Minimum 15 quotes per run, aiming for 20-30. Every quote captured with: exact text, author, platform, community, URL, engagement metrics, context, and pain category.

Pain categories: - tutorial-gap — Tutorials exist but do not prepare you for real work - tool-complexity — Tools are too complex to learn effectively - real-world-gap — Gap between learning materials and production reality - career-transition — Struggling to break into or transition within the field - information-overload — Too many resources, no clear path - environment-setup — Cannot get the tools working locally - debugging-hell — Spending disproportionate time debugging config/infra - missing-fundamentals — Lacking prerequisite knowledge that tutorials assume

Phase 3: Quote Scoring¶

Four weighted dimensions:

Dimension	Weight	What It Measures
Specificity	2x	How precisely does the quote identify a pain point?
Intensity	2x	How much does this person actually hurt?
Solvability	2x	Can we demolish this with a repo?
Engagement	1x	Social proof that the pain is shared

Overall: (specificity*2 + intensity*2 + solvability*2 + engagement) / 7

Phase 4: Theme Clustering¶

Quotes are grouped into pain themes — recurring structural problems that multiple quotes point to. A theme needs at least 2 quotes. Gold themes (5+ quotes, avg score >= 7) are flagged for priority content.

Phase 5: Content Brief Generation¶

For each theme scoring >= 6, a "From the Wild" content brief is generated with the post structure, channel adaptations (LinkedIn, blog, Reddit), and estimated word count.

Phase 6: Repo Spec¶

For each brief, a detailed instructional repo spec: name, structure, progressive git tags, key architectural decisions ("why X not Y"), and battle-axe features that make it production-grade.

The Scoring System¶

The scoring system is intentionally weighted toward solvability. A heartbreaking quote about imposter syndrome might score 10 on intensity, but if you cannot solve it with a repo, it scores 1-2 on solvability. The overall score drops. This is by design — the purpose of the score is not to measure how bad the pain is. It is to measure how good a "From the Wild" post it would make.

Solvability Is the Filter¶

The solvability dimension has explicit auto-caps (maximum score of 3) for patterns that cannot be addressed with an instructional repo:

"My company won't adopt DevOps" → organizational, not educational
"Nobody is hiring juniors" → economic, not educational
"Imposter syndrome is killing me" → psychological, not educational
"I don't have time to learn" → scheduling, not educational
"The technology keeps changing" → existential, not educational

And explicit boosters (+1-2 points) for patterns that map perfectly to a repo:

Person names a specific template they wish existed (+2)
Person describes exactly what the solution would look like (+2)
Person has tried multiple resources and lists what is missing (+1)
Person says "I would pay for..." (+1)

The Engagement Paradox¶

High engagement (upvotes, replies) validates that the pain is shared. But engagement alone is not enough. "DevOps is hard" might get 500 upvotes because everyone agrees — but it scores 1 on specificity and 2 on solvability. The weighted formula ensures that viral-but-vague quotes do not dominate the index.

The ideal quote has all four: specific (you can build a repo for it), intense (the person is in real pain), solvable (a repo directly addresses it), and validated (others agree).

The Battle Axe Repo¶

The repo is the product. The post is the wrapper. This inversion is critical. Most content creators write a blog post and maybe link to a repo as an afterthought. In "From the Wild," the repo is the main event. The post exists to explain why the repo exists and to give the reader enough context to use it.

Progressive Git Tags¶

Every repo uses git tags to enable progressive learning:

step-01-scaffold     — Project structure, nothing works yet
step-02-local        — Works locally, manual everything
step-03-containerize — Dockerized, but still manual deploy
step-04-ci           — Automated tests on push
step-05-cd           — Automated deploy on merge
step-06-secrets      — Secrets management (not hardcoded)
step-07-monitor      — Logging, metrics, health checks
step-08-production   — The full thing: rollback, alerting, runbook

The reader can git checkout step-01 and follow the progression. Each step has a README section explaining not just WHAT changed but WHY. The "why" is the differentiator. Every other tutorial shows you the commands. This shows you the reasoning.

"Why X Not Y" Decisions¶

Every repo includes 3-5 explicit architectural decisions documented in a DECISIONS.md or in the README:

#### Decision: GitHub Actions over Jenkins
**Why**: Jenkins requires hosting and maintaining a server. For a repo
that teaches CI/CD concepts, the infrastructure meta-problem (maintaining
Jenkins itself) obscures the actual lesson. GitHub Actions is free for
public repos, zero-infrastructure, and YAML-based — which means the CI
config lives with the code and is version-controlled by default.

**Tradeoff**: GitHub Actions is GitHub-locked. Jenkins is portable. We
chose teachability over portability because the concepts (pipeline stages,
artifact management, environment promotion) transfer to any CI system.

These decisions are content in themselves. Each one is a potential LinkedIn post.

The Weekly Loop¶

Wild Scan is designed for weekly cadence:

Monday:     Run /wild-scan "{topic focus}"
            → 20 scored quotes, 4 themes, 2 gold themes, 2 content briefs

Tuesday:    Pick the best brief. Start building the repo.
            (Or add to an existing repo — a new "step" or module)

Wednesday:  Finish the repo. Push to GitHub.
            Write the "From the Wild" post draft.

Thursday:   Publish on LinkedIn and/or blog.
            Cross-post the repo link in the subreddit where the quote came from.

Friday:     Check engagement. Read comments. Harvest new quotes from the comments
            for next week's scan.

The CTA at the end of every post — "Found another one? Drop it in the comments." — turns the audience into scanners. Each post generates leads for the next one. The flywheel accelerates.

Over Time¶

After 12 weeks, you have: - 12+ published "From the Wild" posts - 12+ GitHub repos (or modules within repos) - 200+ indexed pain quotes across themes - A growing audience that sends you quotes proactively - A portfolio of production-grade instructional repos - Content-market fit data: which themes get the most engagement?

The repos compound. Each new repo links to related repos. The collection becomes a curriculum. The curriculum becomes the foundation for a paid product (course, community, or both). The content loop feeds the product pipeline.

Integration with the Pipeline¶

Wild Scan is part of the hunter product-discovery pipeline:

signal-scan ──→ decision-log ──→ persona-extract ──→ offer-scope ──→ pitch
                                       │
                                       └──→ content-planner
                                                   ↑
                                            wild-scan ──→ Writing/From-The-Wild/
                                                     └──→ Writing/Content-Briefs/

How it connects:

Signal-scan identifies broad market opportunities. Wild-scan dives deep into the pain language within those opportunities.
Persona-extract defines who is hurting. Wild-scan finds their actual words.
Content-planner schedules content from GitHub activity and buildlog. Wild-scan adds a third source: community pain quotes.
Content briefs from wild-scan use the same format as content-planner briefs, so they appear on the same kanban board.

Vault Structure¶

Writing/
├── From-The-Wild/                    ← wild-scan output (quote indices)
│   ├── devops-career-2026-02-11.md
│   ├── kubernetes-beginner-2026-02-18.md
│   └── wild-scan-*.json
├── Content-Briefs/                   ← shared with content-planner
│   ├── ftw-tutorial-gap-2026-02-11.md
│   └── ftw-k8s-complexity-2026-02-18.md
└── Content-Plan.kanban.md            ← content-planner picks up briefs

Quick Start¶

/wild-scan "DevOps career entry — sysadmins learning to code"

The skill will: 1. Build a search plan targeting relevant subreddits and communities 2. Harvest 15-30 real pain quotes with engagement metrics 3. Score each quote on specificity, intensity, solvability, and engagement 4. Cluster quotes into pain themes 5. Generate "From the Wild" content briefs for themes scoring >= 6 6. Spec instructional repos for each brief 7. Save everything to the Obsidian vault

Then pick the best brief, build the repo, and write the post.

🎯 wild-scan¶

Install¶

Security Scan¶

File Info¶

Skill Prompt¶

Wild Scan¶

Step 0: Load Conventions¶

When to Use¶

Trigger Phrases¶

Prerequisites¶

Workflow¶

Phase 1: Search Planning¶

Platform Priorities¶

Phase 2: Quote Harvesting¶

Harvesting Rules¶

What Makes a Quote Worth Harvesting¶

Per-Quote Capture Format¶

Phase 3: Quote Scoring¶

Scoring Discipline¶

Phase 4: Theme Clustering¶

Theme Format¶

Clustering Rules¶

Phase 5: Content Brief Generation¶

"From the Wild" Post Format¶

Brief Fields¶

Phase 6: Repo Spec¶

What Makes a Repo "Battle Axe" Level¶

Repo Spec Format¶

Progressive Step Design¶

Output¶

1. Quote Index: {vault}/Writing/From-The-Wild/{topic-slug}-{YYYY-MM-DD}.md¶

2. JSON Index: {vault}/Writing/From-The-Wild/wild-scan-{topic-slug}-{YYYY-MM-DD}.json¶

3. Content Briefs: {vault}/Writing/Content-Briefs/ftw-{topic-slug}-{theme-slug}-{YYYY-MM-DD}.md¶

Cumulative Index¶

Integration with Content Planner¶

Quality Checklist¶

Resources¶

references/¶

README¶

Wild Scan: Pain Quote Harvesting for the "From the Wild" Content Series¶

Table of Contents¶

The Premise¶

The "From the Wild" Content Format¶

1. THE QUOTE¶

2. THE DIAGNOSIS¶

3. THE HACK¶

4. THE WALKTHROUGH¶

5. THE CTA¶

The Discipline¶

Why Quotes Beat Ideas¶

The Evidence Hierarchy¶

The Canon¶

Gary Vaynerchuk — Document, Don't Create¶

Nathan Barry — Teach Everything You Know¶

Sahil Lavingia — The Minimalist Entrepreneur¶

Patrick McKenzie (patio11) — Writing for Engineers¶

Swyx (Shawn Wang) — Learn in Public¶

The Content-Market Fit Hypothesis¶

How the Skill Works¶

Phase 1: Search Planning¶

Phase 2: Quote Harvesting¶

Phase 3: Quote Scoring¶

Phase 4: Theme Clustering¶

Phase 5: Content Brief Generation¶

Phase 6: Repo Spec¶

The Scoring System¶

Solvability Is the Filter¶

The Engagement Paradox¶

The Battle Axe Repo¶

Progressive Git Tags¶

"Why X Not Y" Decisions¶

The Weekly Loop¶

Over Time¶

Integration with the Pipeline¶

Vault Structure¶

Quick Start¶

1. Quote Index: `{vault}/Writing/From-The-Wild/{topic-slug}-{YYYY-MM-DD}.md`¶

2. JSON Index: `{vault}/Writing/From-The-Wild/wild-scan-{topic-slug}-{YYYY-MM-DD}.json`¶

3. Content Briefs: `{vault}/Writing/Content-Briefs/ftw-{topic-slug}-{theme-slug}-{YYYY-MM-DD}.md`¶