Skill packs › Skill

Positive Mentions Harvester

Find and check praise for a person or firm. Use when reviews, press, talks or kind words are spread across sources. Keep one proof list and choose what is safe to share.

Skill file positive-mentions-harvester.md · last updated Sep 6, 2026

Show people the real proof behind your good name. This guide puts praise and mentions in one checked list, so you can choose what to share. Start with the source links and any proof list you already use.

The path: Source proof → Correct person → Clear class and score → Safe reuse queue.

Use the owned positive-mentions guide for the full method. A mention records what a named source says; appearing on a show does not by itself establish praise.

Use this when a person or company has scattered testimonials, third-party praise, press, reviews, speaking clips, or social shoutouts and needs one evidence-backed system of record. This skill collects and processes existing proof; it does not invent praise, treat every appearance as an endorsement, or publish private evidence.

Inputs

• Positioning brief from business-brand-strategist, including the intended customers (the buy box) and the

claims the proof must support. Use the positioning task to supply that checked brief.

• The existing canonical mentions inventory. If one exists, update it in place; do not

start a second tracker.

• Verified entity names, aliases, languages, profile links, clients, podcasts, events,

topics, and date ranges to search.

• Source material already held: exact quotes, reviews, transcripts, screenshots, video

timestamps, emails, and permission receipts.

• The public entity home and other approved serving pages that consume the inventory.

Canonical roles and boundaries

Keep one row-level operational source of truth. A public page is a selected display of that inventory, not a second ledger.

Use these classes consistently:

• Mention: a named source makes a positive, attributable statement or concrete claim

about the subject, backed by a reviewable source.

• Mention candidate: a potentially positive item still missing exact language,

primary evidence, permission, identity resolution, scoring, or deduplication.

• Appearance candidate: evidence that the subject appeared somewhere. Promote it to

a mention only when the source actually says something positive about the subject.

• Duplicate / rejected: a repeated, mismatched, inaccessible, contradicted, or

otherwise unusable record retained for audit history rather than silently deleted.

HOLD is the public-serving gate, not a replacement lifecycle class. Keep the record as a mention candidate or appearance candidate, preserve the reason it is held, and recheck it when the missing identity, evidence, or permission arrives.

Steps

1. Open the canonical inventory first. Confirm its owner, columns, current schema,

last reviewed date, and accepted vocabulary. Append there. If no inventory exists, create one governed table before harvesting; never create per-source or per-agent competing trackers.

1. Sweep every source and language. Search the verified name and aliases against

clients, events, topics, podcasts, publications, review platforms, social networks, owned archives, and supplied private material. Record exactly which sources, languages, and date ranges were searched.

1. Capture the primary evidence. Store the exact quote or concrete claim, speaker,

speaker role and organization, source title, platform, normalized evidence URL, publication date, capture date, format, timestamp when applicable, and a concise note explaining what the source proves. For relationship and appearance records, also preserve the scene, why it mattered, any source-backed human beat, the narrowest supported relationship verb, and a compact public receipt. Search snippets and AI summaries are discovery aids, not primary evidence.

1. Resolve identity and deduplicate. Confirm the source and subject are the intended

people. Use the stable dedupe key source platform + normalized evidence URL + speaker + date + quote hash; merge variants into one record while retaining aliases and audit notes.

1. Classify the record. Mark it as mention, mention candidate, appearance candidate,

duplicate, or rejected. An episode credit, event listing, or photograph proves an appearance, not praise.

1. Record evidence and permission state. Use only these permission values:

GRANTED_PUBLIC_RECEIPT, GRANTED_ATTESTED_NO_DIRECT_RECEIPT, USER_REPORTED_UNVERIFIED, PUBLIC_SOURCE, or UNKNOWN. Keep the exact permission receipt or attestation locator private. Never publish Gmail, Zoom, Basecamp, private Drive, private Docs, or other access-controlled URLs.

1. Score Who / Where / What. Give each dimension 0–10 using the canonical

inventory’s current notes, record the three component scores, and calculate the total. Do not substitute buy-box relevance for a dimension; use relevance as a routing note or tie-breaker after the authority score.

1. Apply the promotion gate. A mention may move from candidate to reusable praise only

when it has a named source, exact positive language or concrete claim, live primary evidence, resolved identity, semantic deduplication, Who / Where / What score, permission state, and approved reuse destinations. An appearance may be reused only as an appearance when primary media proves the exact moment, identity and permission are resolved, and the relationship term stays within that evidence. Anonymous, initials- only, domain-only, unknown-permission, or private-source claims stay HOLD and out of public surfaces.

1. Rank and route. Sort qualified records by Who / Where / What, then send approved

records to the entity home, topic pages, schema-supported proof, sales assets, or Dollar-a-Day testing. The score decides selection and order, not public tone: a high Who score cannot rescue weak What, and a recognizable face does not transfer authority by proximity. Record every reuse destination in the canonical row so public displays remain derived views, not independent lists.

1. Log gaps and leave a receipt. Route unsupported buy-box claims to

reputation-gap-analyzer; record search coverage, additions, merges, rejections, unresolved blockers, and the next review date. A weekly or monthly job is only Activated or Observed when a real scheduler and timestamped run receipt prove it.

The Who / Where / What 30-point scale

Keep the component scores visible. A total with no Who / Where / What breakdown is not auditable.

• 24–30: lead with it — homepage, pinned posts, first boosts.
• 15–23: supporting proof — topic pages, follow-up sequences.
• Under 15: retain in the archive or candidate pool; do not let weak proof dilute

the strongest proof.

Public serving format

Show the moment, not the resume. A proof card or short section should carry:

1. the real scene;
2. why the moment matters to the reader;
3. the named person and only the role relevant to that scene;
4. one true human beat from the source; and
5. a compact receipt with source, date, format, and link.

Use one short page-level key to distinguish appearance, collaboration, and attributable praise. Do not repeat a legal-sounding disclaimer under every item. Run two editorial checks: remove the famous name and confirm a useful story remains (the trophy-name test), then read the full page and confirm it states supported facts instead of repeatedly arguing what they do not prove (the courtroom test). Keep a local qualifier only when its absence would materially mislead.

Output

• One deduplicated canonical table with row-level provenance, lifecycle state, permission

state, Who / Where / What components, total score, and reuse destinations.

• A ranked lighthouse shortlist and an approved public-serving queue.
• Story-ready serving fields for every public record: scene, meaning, relevant role,

source-backed human beat, evidence-bounded relationship term, and compact receipt.

• A candidate / blocker queue that preserves appearances, unknown permissions, weak

evidence, and identity collisions without overstating them.

• A reputation gap list and a timestamped run receipt.

Definition of done (QA checklist)

Quality assurance (QA) means checking the actual output against the source and agreed requirements; use the Article Guidelines for any public-facing proof page.

• The existing canonical inventory was updated in place, or one governed inventory

was created; no competing row-level list remains.

• Every promoted mention names the correct source and subject and includes the exact

positive statement or concrete claim.

• Anonymous, initials-only, and domain-only praise remains HOLD; no appearance is

relabeled as praise or a durable relationship.

• Every promoted mention has live primary evidence, a normalized URL, date, format,

and timestamp when applicable.

• Every record has a lifecycle class, permission state, dedupe key, Who / Where /

What components, total score, and reuse destinations.

• Appearance-only records remain appearances or candidates, not endorsements.
• Private evidence locators and permission receipts remain private; public pages use

only public-safe sources.

• Public views are derived from the canonical inventory and ordered strongest first.
• Public proof passes the trophy-name and courtroom tests and uses one page-level key

instead of repeated defensive disclaimers.

• Search coverage, unresolved gaps, next review date, and run receipt are recorded.
• The result links back to the definitive article and the stable Task Library entry.

Example(s)

These are the source owner’s dated examples and serving destinations. Preserve their reported scope; this source update does not independently recertify their current contents, count a new run or promote the inherited Task Library contributor status.

• Dennis Yu is the worked example. The private team workbook named *Dennis Yu

Positive Mentions — Canonical Inventory* is the single row-level operational ledger; its access-controlled locator is deliberately not published in this skill.

• Dennis Yu’s public serving inventory

demonstrates the classification boundary. In the 2026-08-23 audit it exposed 217 public records: 41 curated mentions, 32 mention candidates, and 144 appearance candidates. Those classes must not be collapsed into “217 endorsements.”

• Dennis Yu’s entity-home mentions wall is the selected

buyer-facing proof display, while his reviews remain a distinct review surface.

• Dennis Yu’s appearance inventory records

podcast participation. An appearance becomes a positive mention only when the source contains attributable positive language.

Run with an agent

• Loop to coverage: keep sweeping until the defined names, languages, sources, and

date ranges are exhausted. Never claim “complete” when a known source is inaccessible.

• Self-verify: no record enters the serving queue without passing the promotion gate;

keep candidate and rejected records visible in the ledger.

• Compound from the ledger: read the positioning brief and canonical inventory first,

then append and re-score deltas instead of rebuilding from memory.

• Log every run: preserve search coverage, changes, misses, and errors so the next run

can improve the method.

• Current automation boundary: a recurring positive-mentions harvest is Available as

a documented job design, not Activated or Observed until a scheduler definition and a successful timestamped run receipt exist.

A skill is a written recipe; an agent is the AI worker using it with actual tools and access. Give the worker this file, the existing inventory, the source scope and the allowed actions. Ask for the checked rows, evidence, holds and next owner. The installation guide covers reusable setup. A ZIP or plugin does not grant source access or activate a schedule.

See boil-the-ocean.md for the full operating principles.

Handoff and Content Factory context

Pass the canonical row changes, search coverage and unresolved evidence to the actual inventory owner. The reputation gap task receives the unmet proof needs. The public-page or promotion owner receives only the approved source-backed reuse queue with its rights and destinations; routing a record is not publishing or spending.

This supports the Content Factory: Produce, Process, Post and Promote. Real sources are gathered in Produce, checked and shaped in Process, released only with authority in Post, and selected proven work may enter Promote. This harvest supplies checked proof; it does not claim that every row became a public page or ad.

Record the real execution

Open one execution ID when work begins, with the exact starting recipe revision and actual search scope. Write the meta article, the record of this execution with the sources inspected, rows changed, checks, failures and next owner. Writing is required; public release follows existing authority. Link this recipe and its Task Library record.

Keep internal research passes, QA, retries, revisions and meta writing on that same ID. A blocked run stays open with the missing source or permission and its owner, without an invented finish time. The dated public example counts below remain historical volume, not a new execution or an ID-deduplicated run count. Use the evidence to propose the smallest supported recipe improvement.

Fictional teaching example

This example illustrates the method and is not a real client result. A workshop photo shows a founder on stage, while an interview includes a host’s exact praise of her work. The first row remains an appearance; the second can become a mention only after its identity, evidence, permission, dedupe and score gates pass. An inaccessible private note stays on HOLD. The public queue contains only the checked permitted records.

Notes — Dennis’s method

• The more material you paste in, the better this gets. Boil the ocean: every podcast, every event, every thank-you email.
• Who / Where / What decides proof strength. The buy box decides where strong proof is

useful; do not merge those two judgments into one opaque score.

• Lighthouse moments are the priority output: after the evidence gate and Who / Where /

What ranking, the strongest useful stories become the pieces you test first with Dollar-a-Day.

• Re-score when sources, URLs, permissions, or the positioning brief change. A recurring

cadence is a commitment only after it has an owner, scheduler, and observed receipt.

Definitive article & links

• Hub: https://blitzmetrics.com/how-to-collect-organize-positive-mentions-to-build-authority/
• Short alias: https://blitzmetrics.com/positive-mentions/
• Stable Task Library entry: https://local-service-spotlight.github.io/task-library/?task=positive-mentions-harvester
• Run order: business-brand-strategist → this skill →

reputation-gap-analyzer → knowledge-panel-entity-seo → dollar-a-day-strategist

• Evidence QA: evidence-verification

Learned in the field

Appended automatically by the self-improvement loop (Skill-Learnings/): dated lessons from real runs. Newest at the bottom.

July 29, 2026 (from: jagodapasko.com second pass, July 29, 2026)

On July 29, 2026 a client’s audit from six weeks earlier recorded 2 proof items, 24 authority points, 0 power proof, and described her third-party footprint as very thin. A single afternoon of searching found national television coverage on two networks, a broadcast documentary segment, three long-form interviews on three independent channels, and a verified fundraiser documenting 210+ evacuations. None of it was hidden. All of it was in Polish, and most of it lived on other people’s channels rather than her own.

A proof library built from English-language search of a non-English person is a measurement artefact, not a finding. So before scoring anyone’s authority:

1. Search the name in every language the person has lived and worked in, including with

and without diacritics, and search their brand or company name separately.

1. Search for the events as well as the person — the coverage may name the work rather

than the individual, and their own outbound links (a fundraiser page, a media page, a LinkedIn post) often point straight at press that no name-search returns.

1. Treat “third-party footprint is thin” as a **hypothesis that must survive a

native-language search**, never as a conclusion from an English result set. Say which languages were searched, so the next run can see the gap instead of inheriting it.

1. Verify every video with oEmbed before publishing it — it returns the exact title, the

real channel, and whether the thing is still public. Titles get paraphrased from memory otherwise, and paraphrasing someone else’s video title onto a client’s press page is how a credibility asset turns into an error.

Reject search summaries that conflict with primary sources. One auto-generated summary in this run asserted the client had been “a TV director turned brain-injury recovery mentor.” It was a different person with a similar name, and it contradicted a verified twenty-year finance career. A name collision inside a research tool will happily produce fluent, specific, false biography — check every claim against a source that names the person unambiguously before it reaches a published page.

Other skills: ai-search-visibility · boil-the-ocean · client-access-checklist · client-relationship-cadence · content-agent · content-factory

The full run order is on the skill-pack directory. Every skill here is one task from the Task Library — the library is the catalogue of what can be done; a pack is the subset you install; an agent is who runs it.