Reusable skills audit
This one is internal. Enter the password to read it.
Not quite. Try again.
What you keep doing by hand that should be a skill
You asked me to look through the last 30 days across all your projects and find the work worth turning into skills every project can reuse. Here's what the evidence actually says, ranked.
How I measured it. Two passes, because "we talked about it a lot" and "we rebuilt it a lot" are different things.
First, every commit across all your repos since 29 June: 4,599 commits in 72 active projects. I clustered the subject lines by theme and counted how many separate projects each theme touched. Breadth across projects is the signal for a shared skill; volume in one project usually just means one big build.
Second, and this turned out to be the stronger evidence: I looked for the same
script filename existing in several projects. A file that got copy-pasted is a
missing skill by definition. Then I hashed the copies to see whether they'd drifted
apart, which is the failure mode that already bit you with open_md.py
(six copies, three versions, and the stale ones shipped broken pages with no error
to explain why).
The drift problem, first, because it's already costing you
Four scripts have been copied between projects and are now different in each one. Nobody decided this. It happened one useful moment at a time.
1. The hub page builder, 4 copies, 4 different versions
Every copy is a different length. There is no shared original.
610 lines YouTubeIntelligenceFeed/build_hub_page.py 392 lines NotebookLMSkills/scripts/build_hub_page.py 297 lines AnnettesHealth/build_hub_page.py 235 lines LauraRISE/scripts/build_hub_page.pyPublishing to the hub is the single rule you enforce most, so of course four projects each grew their own way of doing it. The 235-line version is missing 375 lines of whatever the biggest one learned.
2. The citation checker, 3 copies, 3 versions, and the weak one is in the wrong place
184 lines in ResearchLibrary. 156 lines in MenopausePracticeGrowth, inside the newsletter audit folder.
This is the one I'd fix first. Your standing rule is to run
check_citations.py on any draft that came from outside, because
ChatGPT fabricates citations. But the project doing newsletter audits is running
a version that's 28 lines shorter than the real one, and only 2 of your projects
have the tool at all, while citation problems showed up in commits across 17.
Tonight is the proof: your testosterone site has an R-squared figure credited to a paper that reports no such number, and a pellet dosage credited to a 1945 paper that isn't about it. Both are live right now.
3. The transcriber, 5 copies, 5 versions, ranging 38 to 371 lines
MenopauseContentRepurposer, LearningFromX, testosteroneinwomen, NotebookLMSkills, YoutubeCoaching.
4. The SES email sender, 6 copies, 3 versions
BoneVoyageRevival, MyExecAssistant, NotTooOldForAI, SponsorLab.
Mostly solved as of today: the new send-email skill is the one
rail now. These six are the legacy copies to retire, not a new skill to build.
The skills worth building, ranked
| Rank | Skill | Evidence | Status today |
|---|---|---|---|
| 1 | publish-to-hub | 4 drifted copies of the builder; hub work in 12 projects, 153 commits | No skill. A topics doc plus four hand-rolled scripts. |
| 2 | verify-citations | Citation work in 17 projects; tool in only 2, in 3 versions | Script exists, unreachable from most projects, drifted. |
| 3 | launch-seo-plumbing | Sitemap/robots/indexing in 26 projects. 23 have robots.txt, only 2 have a sitemap generator. | No skill. Rebuilt per project. |
| 4 | preship-validate | validate.config.json in 20 projects; validator commits in 17 | Validator exists and you own it. No skill wraps it, so each new project needs the config written from memory. |
| 5 | hero-block-optimizer | Headline/subhead/CTA work in 19 projects, 122 commits | Built once for Vitalency as one-off scripts, never generalized. |
| 6 | brand-mark-set | Favicon assets in 18 projects, favicon commits in 12 | Direction is locked; generating the set is still manual each time. |
| 7 | redirect-map | _redirects in 11 projects; 301 commits in 10 | No skill. Folds naturally into number 3. |
Why these seven and not the rest
The loudest theme by far was em-dash and AI-slop cleanup: it appears in
67 of 72 projects. I'm not recommending it, because the
no-ai-slop skill shipped today and already covers the editing. What
67 projects tells you is something else, and worth saying plainly: the cleanup keeps
happening because it isn't wired into the ship path anywhere. The fix isn't another
skill, it's making the linter a gate in the projects that publish.
Three themes came up a lot and are genuinely already covered, so I left them off:
Cloudflare deploys (deploy-site, and 10 projects have
siteshipper.yml), email sending (send-email, today), and
transcripts (youtube-transcript, though the five drifted copies above
suggest projects aren't reaching for it).
One I deliberately did not recommend as a gate: contrast checking. It showed up in 15 projects, and you had the automated check removed on 29 July after reviewing what it flagged. Rebuilding it as a blocking gate would be relitigating a decision you already made. If you want it, it should be a tool you point at a page on purpose, not something that fails a build.
What I'd do next
Build number 2 first, verify-citations, even though it isn't the biggest. It's the one where being wrong is published under your name, and there are two live examples on your own site tonight. It's also the smallest of the seven, because the real work already exists in ResearchLibrary and mostly needs to be consolidated to one version and made reachable.
Then number 1, publish-to-hub, because four drifting copies of
your most-enforced rule is the same shape as the open_md.py incident,
and that one cost you broken pages with no error message to explain them.