Athlete Spotlight

Tag: meta article

  • How We Synced PRISM to Dennis’s Skill Packs

    Dennis handed me 250 skills. I had 21. On 2026-07-08 I downloaded Dennis Yu’s two skill packs, a 239-task library and a personal-brand agent pack, and diffed them line by line against my own operating system: 21 local skills and 24 canon frameworks, last synced to his live site on July 2.

    The surprise was not what I was missing. It was what the skill packs were missing. The downloaded packs still taught rules Dennis’s own live site retired months ago. That turned a simple import job into something better: a sync with an authority ruling, sync to the source, not the artifact.

    Reconciling the skill packs without vandalizing either side

    The assignment: reconcile Dennis’s downloadable skill packs with my system without vandalizing either. The sources were all 11 personal-brand pack files plus its README, roughly 120 of the 239 task-library skills read in full (every personal-branding, SEO-architecture, dollar-a-day, and thank-you-machine file, plus the key content-factory and website-QA files), both manifests, and the local counterpart for each.

    The goal category is the anti-reinventing-the-wheel discipline Dennis asked for on the July 7 call: ask for the latest skill packs before building anything. So before I built the athlete pack, I made sure I was building on his newest thinking, not a stale copy of it.

    How the sync ran, step by step

    1. Download and map. Both packs into a scratchpad, and a map file recording where every skill lives.
    2. Diff. A six-section comparison: what is new in the packs, where the packs beat the local system, where the local system beats the packs, the athlete-vertical candidates, the canon gap (I hold 24 frameworks, the registry lists 27), and a ranked list of sync actions.
    3. Rule on authority. When sources conflict, the order is Dennis’s live articles first, his downloaded packs second, the local system third. The packs are snapshots; the site is the master. One deliberate exception: the no-em-dash rule is local policy by design and never gets synced away.
    4. Execute the adoptions. Ten imports, same day, each new file carrying its source path and a “Dennis Yu / BlitzMetrics, adapted” attribution.
    5. Refuse the stale rules. Four pack teachings did not come in, because the live site supersedes them.
    6. Give first. The diff itself became a gift: a drafted note to Dennis flagging that his shipping packs contradict his live site in those four spots, plus a broken starter-zip link I found on the way.

    The ten adoptions included the agent operating layer, an AI-search-visibility skill, a personal-brand strategist, a 30-point mention rubric folded into my Positive Mentions System (built by Cam Hazzard, developed with Dennis Yu), four Dollar a Day patches, a recursive self-improvement QA pass, and about two dozen new website-QA checks. The four refusals: the Rank Math 70-plus threshold (live guidance is 81-plus green), the first-link-only anchor rule (retired on the entity-linking page), the Link Whisper install step (AI agents replaced it), and the 8-section homepage (the newer pattern is 9 sections with a dynamic blog loop).

    The calls I’d defend

    Live site beats the packs, even though the packs are “official.” Newest published Dennis is the master. Without that ruling I would have imported a 70-plus Rank Math threshold my own July 2 sync had already retired. Freshness is a property of sources, not of formats.

    Patch, don’t rewrite. Existing skills got cross-referenced additions, not wholesale replacement. Anti-vandalism applies to your own repo too.

    Don’t guess the missing canon. The packs cite hubs suggesting three frameworks I do not hold. Instead of inventing them, the action is to get the source repo invite and read the real list of 27.

    Defer the shiny thing. The athlete-vertical pack build was the obvious next product, and I explicitly did not build it in this session. Sync first, build second, per Dennis’s own layers: strategy, then local prototype, then cloud.

    What it cost, honestly

    Honest label: no token receipt (the metrics extractor is still an open gap), so these are documented estimates. The reading volume is the honest driver: about 120 of 239 task files read in full, not skimmed, because the whole point was catching contradictions.

    TaskAgent time (est.)Human time (est.)Agent cost (est.)Human cost (est.)
    Read ~131 pack files plus local counterparts, write the diff and mapone long session3 to 4 days of careful readinga few dollars in tokens$840 to $1,120 at $35/hr
    Execute 10 adoptions plus supersession notes~1 to 2 hours of session time1 to 2 dayslow single-digit dollars$280 to $560

    What the agent did, and what a human owns

    Autonomous: reading both packs completely, diffing against local files, drafting the authority ruling for approval, executing the imports with source attribution, and writing the supersession notes inline.

    Human required: the authority ruling itself was Cam’s call, made explicitly on 2026-07-08. Sending the give-first note to Dennis is Cam’s send. The source-repo invite is a human ask. And the deferred athlete-pack build waits for a human green light.

    What the agent read

    Pack files read: all 11 personal-brand pack files plus README, about 120 of 239 task-library skills, and both manifests. Local files read: the 21 skills, the relevant canon, and the July 2 live-site sync records. Live-site fetches: a delegation skill that was in neither pack, plus spot-verifications of entity linking and Rank Math guidance. Tokens: not measured. Voice profile: applied to this write-up.

    How it scores against our own gate

    This article ran through the same 18-step gate we use on client work. Passing now: first sentence under 10 words, zero banned words, zero em dashes, contractions throughout, and all counts traceable to the diff and sync records. Still needs a human: the featured image (the diff’s summary table is a candidate screenshot), Cam’s fact pass, and confirmation that Dennis is fine with the pack-contradiction findings going public. That last one is a real gate, not a formality.

    Put the synced system on your Claude

    The whole point of the sync was to keep the method current, then hand it to athletes. You can put the Athlete Spotlight system on your own Claude in about a minute, free Claude included. This is one of three meta articles on the wider build; the others cover how the weekly report’s site-health half was built and how positive mentions were wired into athlete sites.

    The lesson I keep coming back to: don’t sync to the artifact, sync to the source. The packs were the map; the live site was the territory. And when your teacher’s own materials drift behind his newest thinking, catching it and handing it back is the best thank-you there is.

    Built by Cam Hazzard, developed with Dennis Yu.

  • How I Connected Positive Mentions to Athlete Sites

    Two systems, one athlete. That is the whole idea. My Positive Mentions System, built by Cam Hazzard and developed with Dennis Yu, finds and scores what people say about someone online. The Athlete Spotlight site factory builds their website. For weeks they ran side by side without talking to each other, which meant the best quotes about an athlete sat in a database while their proof page waited for someone to copy and paste.

    So I wired them together, once, the safe way. This is how positive mentions now flow into an athlete’s website, read-only, human-gated, with zero copy and paste. It is the retention loop behind an Athlete Spotlight site, and it is built so the site tooling can never touch, break, or publish anything on its own.

    What I connected, and why positive mentions matter

    The assignment: make an athlete’s proof section refresh from the mentions knowledge base automatically, without ever letting automation publish, and without letting the site tooling anywhere near production data it could break. The sources were the production mentions engine (a permanent local database), the site factory’s template kit, and a wiring contract I wrote first.

    The deliverable was two small bridge scripts, pma_feed.py (286 lines) and onboard_map.py (154 lines), shipped with the site factory on 2026-07-02. The goal category is the retention loop: a proof page that stays current on its own is the reason an athlete keeps their site, and positive mentions are the raw material.

    How the loop runs, per athlete

    In steady state, the loop is five steps and it repeats every week.

    1. Intake once. A paying athlete’s intake form drives everything. If they opted in, onboard_map.py converts the intake into the mentions engine’s signup payload. One form, two systems, zero re-typing.
    2. Onboard once (human gate 1). A person pipes that payload into the engine’s front door, because it creates the subject and enables the consent-gated weekly digest. Never automation.
    3. Weekly sweeps (automatic). The engine’s existing scheduler collects mentions across YouTube, Reddit, news, and podcasts, scores them with the marketability rubric, and exports. The factory adds nothing here.
    4. Refresh the proof feed. pma_feed.py pulls the current ad-ready quotes into the athlete’s site package: a machine-readable feed plus a website-ready testimonials block, marked DRAFT in its own header.
    5. Review and publish (human gates 3 and 4). A person reads every quote, verifies attribution at the source URL, trims platform openers, then pushes the reviewed block to the live page through a logged-in session.

    Four human gates total, written into the contract as a table: onboarding consent, site-package review, quote review, and the live publish. Nothing in the loop auto-publishes, auto-emails, or writes to the mentions database.

    The calls I’d defend

    Read-only at the database level, not by promise. The bridge opens the mentions database with SQLite’s read-only mode. It cannot write, create, or migrate the database even if I ship a bug. The factory reads production; it never touches it.

    Only usable rows leave the database. The filter is the same marketability-over-sentiment rule the digest and the activation tools use. One gate, shared everywhere. “Fire episode!” is data; it is never a deliverable. The research pile and hidden rows never reach an athlete-facing surface.

    A synthetic pilot that can’t leak. The pipeline test athlete is fictional, so a fixture flag loads a clearly synthetic feed and never touches the database at all, and the onboarding script refuses fixtures outright. The fake athlete can never be onboarded into the real engine. I would rather the tooling be paranoid than fast.

    DRAFT stamped into the output itself. The testimonials block carries a DRAFT header comment, so even the file tells you it has not passed review yet. The verify-before-publish rule applies before any top-tier quote goes live.

    What it cost, honestly

    Honest label: no token receipt exists for this build (the metrics extractor is still an open gap), so these are documented estimates.

    TaskAgent time (est.)Human time (est.)Agent cost (est.)Human cost (est.)
    Wiring contract plus 2 bridge scripts (440 lines) plus fixture and tests~2 hours of session time2 to 3 days for a developerlow single-digit dollars in tokens$560 to $840 at $35/hr
    Per-athlete proof refresh, ongoingseconds per run30 to 60 min of manual quote hunting, weekly~$0 (keyless, local)$17 to $35 per week at $35/hr

    The ongoing row is the real product. The one-time build is cheap; the compounding save is weekly, per athlete, forever.

    What the agent did, and what a human owns

    Autonomous: converting intake to the onboarding payload, pulling ad-ready quotes, rendering the feed and the website block, restyling cards to the site’s design tokens, and scrubbing em dashes by construction.

    Human required: onboarding consent (gate 1), reviewing the site package (gate 2), verifying every quote’s attribution at its source URL (gate 3), and pushing the block live through a logged-in browser session (gate 4). Also profile photos: real ones, re-hosted, never hotlinked.

    What the agent read

    Read: the mentions engine’s usable-row predicate and database layout, the testimonial card shape I adapted, the template kit’s proof pattern, and the intake schema. Written: the wiring contract, the two bridge scripts, the fixture feed, and builder tests. Tokens: not measured (see the cost section). Voice profile: applied to this write-up, not needed for the scripts.

    How it scores against our own gate

    This article ran through the same 18-step gate we use on client work. Passing now: first sentence under 10 words, zero banned words, zero em dashes, contractions throughout, real numbers with estimates labeled, and the canonical parent linked (the Positive Mentions System). Still needs a human: the featured image (a screenshot of the rendered proof section is the obvious pick), Cam’s fact pass, and a live link check. Showing that list is the point of a meta article.

    See it live, and get started

    The proof loop lives inside every Athlete Spotlight website, and the mentions half of the weekly AI report runs on the same engine. This is one of three meta articles on that build; a companion covers how the report’s site-health half was built. The whole thing operationalizes the Perform stage of the Content Factory.

    When you are ready, get started for $30 per month and your proof page starts refreshing from real, verified mentions once your site is live.

    Dunking and business are the same game. You do the reps where nobody is watching (the sweeps, the scoring, the gates), so the highlight, a coach’s quote on your site, verified and current, looks effortless.

    Built by Cam Hazzard, developed with Dennis Yu.

  • How I Built the Weekly AI Report

    My mentions agent already sent a weekly email. It told an athlete what people said about them that week: new mentions, the one ad-ready quote, a game plan. Good, but half a report. An athlete’s presence online is two things, what people say about you and how your site is doing. So I built the second half, and this is the story of the weekly AI report, version one.

    This is the build behind the promise on every Athlete Spotlight weekly report: your site and your mentions, what changed and what to do next. It is part of my Positive Mentions System, built by Cam Hazzard and developed with Dennis Yu, and it runs on the MAA framework (Metrics, Analysis, Action). Here is exactly how the second half got built, with the real numbers and the honest gaps.

    What the weekly AI report needed

    The assignment was easy to say and easy to get wrong: add a “your site this week” section to the existing mentions digest without touching the email safety rails. The source material was the production digest engine (digest.py) and the MAA framework from canon. The deliverable shipped as one new module, site_signals.py, 455 lines of Python, wired into the digest and committed on 2026-07-02.

    The goal category is the honest one: a client deliverable, and the part of an Athlete Spotlight subscription that makes it worth renewing. A report that reads like a person wrote it, that a 16-year-old athlete’s parent can understand, and that never says anything we did not measure.

    How I built it, step by step

    First rule I set: free APIs only. That is a standing constraint in my system (no billing), and it forced honest engineering instead of buying a dashboard. The section collects six signal families, all real numbers.

    1. Site status: up or down, the actual HTTP status code, and response time in milliseconds, from a plain stdlib fetch with no key.
    2. Uptime over the last 7 days: from UptimeRobot’s free API, the monitor matched by hostname.
    3. Speed score out of 100, plus LCP and CLS: from Google PageSpeed Insights on mobile.
    4. SSL certificate: days until renewal, read straight off a TLS handshake.
    5. Search basics: does the homepage have a title tag and JSON-LD structured data.
    6. Week-over-week deltas on all of it, computed against a history file capped at the last 60 snapshots.

    Then the MAA shape from the framework. Metrics are the numbers above. Analysis is one short rule-based paragraph that names the weakest area and the week-over-week movement. Action is up to three concrete items, and the first one always targets the weakest signal, in a fixed priority order: site down beats SSL trouble beats slow responses beats uptime slips beats speed beats search basics.

    The safe test path matters as much as the feature. A --render-only flag writes the full HTML preview and never sends, never stamps the send date, and never writes to the history file. Previews cannot skew next week’s deltas, so I can check a report before an athlete ever sees it.

    The calls I’d defend

    Three decisions in this build I would defend to anyone.

    A 403 is not “down.” Bot protection returns 403s all day. The report states the real HTTP code the site returned instead of crying outage, and when the failure is on our side of the network, it retries once, then says “check inconclusive this week.” It never invents a confirmed outage.

    Opt-in per athlete, byte-identical otherwise. The section only renders when an athlete’s config has both a site URL and the report switch on. Without both keys, the digest output is byte-identical to the old behavior, verified by diff at build time. Existing subjects felt nothing.

    Don’t claim what we can’t measure. Google Search Console queries, clicks, and traffic need the owner’s OAuth per site. There is no free keyless path, so the report says “not yet connected” instead of faking it. The sales-copy guardrail is written into the module’s own docs: here is what is honest to say, here is what is not yet.

    What it cost, honestly

    Honest label first: I do not have a token receipt for this build. The session metrics extractor is still an open gap in my system, so the numbers below are documented estimates, not measured figures.

    TaskAgent time (est.)Human time (est.)Agent cost (est.)Human cost (est.)
    Design and build site_signals.py (455 lines) plus digest wiring~2 to 3 hours of session time2 to 3 days for a developerlow single-digit dollars in tokens$560 to $840 at $35/hr

    Running cost is the part I like: $0. Every API in the report is free tier. The two optional keys (UptimeRobot and PageSpeed) are free accounts, and the HTTP, SSL, and search-basics checks need no key at all.

    What the agent did, and what a human owns

    Autonomous: collecting every signal, computing deltas against history, writing the analysis paragraph and the three actions, rendering the branded email, and previewing safely. Also failing gracefully, so a dead API can never block the mentions half of the report.

    Human required: consent. Emailing is gated exactly like before (a real recipient plus an explicit send). Connecting UptimeRobot monitors and any future Search Console OAuth are owner actions. And the report is generated as a file first, so nothing auto-publishes anywhere.

    What the agent read

    Production code read: the digest engine, the mentions knowledge-base layer, and the subject config contract. Canon loaded: the MAA framework and the no-em-dash rule (every generated line is scrubbed by construction). External docs: the UptimeRobot API v2 and PageSpeed Insights references. Tokens: not measured (see the cost section). Voice profile: not needed for the build, applied to this write-up.

    How it scores against our own gate

    This article ran through the same 18-step article gate we use on client work. What passes now: first sentence under 10 words, zero banned AI words, zero em dashes, contractions throughout, real numbers with estimates labeled as estimates, and the canonical parent linked (the Positive Mentions System, built by Cam Hazzard and developed with Dennis Yu). What still needs a human: the featured image, a final fact pass by Cam, and live cross-link verification after publish. That honesty is the point of a meta article: show the work, including the parts a person still owns.

    See the standard, and get started

    The live standard this build serves is The Athlete Weekly AI Report, the article that defines what every Athlete Spotlight report is built to. This meta article is one of three documenting that build; the next covers how positive mentions were wired into athlete sites.

    When you are ready, get started for $30 per month and the weekly report starts once your site is live. Parents are welcome to check out on an athlete’s behalf.

    The takeaway is the same one I keep coming back to: be so good they can’t ignore you, and be honest enough that they trust you when they look. A report built on numbers nobody had to pay for, that never says anything we didn’t measure, earns that trust.

    Built by Cam Hazzard, developed with Dennis Yu.