Keeping the Bluesky drafts up to date

TL;DR

• Drafts live in dev/bluesky-post-drafts.md (a checklist; tick items off as you post them).
• You’ll be notified automatically: when a new publication appears on the homepage feed, a GitHub issue titled “📝 New publications need Bluesky drafts” is opened/updated (label bluesky-drafts).
• To handle it, open a Claude Code web session on this repo and paste the prompt in § Prompt to paste. Claude appends the drafts and updates the ledger; the issue auto-closes on the next run.

How the detection works

The site rebuilds weekly (and on every push to main) via the Update Website workflow, which pulls fresh publications from each team member’s ORCID profile → PubMed and force-pushes the rendered www/ to the live branch.

After that build, the Check Bluesky Drafts workflow (.github/workflows/check-bluesky-drafts.yml) runs:

1. It reads the rendered www/index.html from the live branch and extracts the DOIs in the “Recent publications” feed.
2. It compares them against dev/bluesky-pubs-seen.txt — a snapshot of every publication already triaged.
3. Any DOI not in that ledger is reported as new. If there are new ones, it opens (or updates) the tracking issue. If there are none, it closes the issue.

Note: scheduled / workflow_run triggers only fire from workflows on the default branch (main), so this won’t run until merged to main. You can always run it manually from the Actions tab (“Run workflow”) once it’s on main.

dev/check_new_publications.py does the parsing/diffing. You can run it locally against a rendered page:

python3 dev/check_new_publications.py www/index.html dev/bluesky-pubs-seen.txt

Prompt to paste

When the tracking issue fires (or any time you want a refresh), start a Claude Code session on this repo and paste:

Update the Bluesky drafts. Read dev/bluesky-post-drafts-INSTRUCTIONS.md and follow the “Procedure for Claude” section: find publications on the homepage feed that aren’t in dev/bluesky-pubs-seen.txt, draft a ≤300-char Bluesky post for each in the same style as the existing entries in dev/bluesky-post-drafts.md, add their DOIs to the ledger, then commit and push.

You can also do the same for new blog posts under posts/ — just ask Claude to “also draft posts for any blog posts in posts/ that aren’t already in the drafts file.”

Procedure for Claude

When asked to update the drafts:

1. Get the current feed. The live site host is usually blocked in the web sandbox, so don’t rely on fetching https://wakeforestid.com/. Instead read the rendered homepage from the live branch via the GitHub tools, e.g. mcp__github__get_file_contents for www/index.html at ref: refs/heads/live (it’s large — it will be saved to a file you then parse). Each publication is a <div class="publication-card"> with a publication-title (h3), publication-authors (p), and publication-meta (p, contains Journal / Publish Date / DOI / PMID).
2. Diff against the ledger. Read dev/bluesky-pubs-seen.txt (bare lowercase DOIs, # comments ignored). Any feed DOI not present is “new.” Running python3 dev/check_new_publications.py <saved-index.html> dev/bluesky-pubs-seen.txt does this for you and prints the new ones.
3. Draft a post per new publication, matching the existing style under the # Recent Publications section of dev/bluesky-post-drafts.md:
   • Markdown checkbox: - [ ] **Title** (Journal, Year · LastNames) then a blockquote > line with the post text ending in https://doi.org/<doi>.
   • ≤300 characters for the blockquote text including the DOI link. Verify with a quick script before saving.
   • Name section members in the post (faculty as “Dr. Lastname”; Michael DeWitt by name). Section members are the people with ORCID IDs in people/*.qmd.
   • For duplicate records of the same work (e.g. a guideline co-published across journals, an executive summary, or a publisher correction), write one consolidated post and still add all of those DOIs to the ledger.
4. Update the ledger. Append every new DOI you handled (drafted or deliberately skipped) to dev/bluesky-pubs-seen.txt so it stops being reported.
5. Commit and push to the working branch. Do not open a PR unless asked.

Files