How it’s built
Almost all of this was built by AI, with very little human input
One person maintains this archive, but they write almost none of it by hand. The research, the writing, the fact-checking, and the publishing are done by Claude Code, an AI agent that can read, search the web, write files, run checks, and open pull requests on its own. The human mostly points it in a direction and reviews the result.
This page explains, in plain language, how that works, and how, if you’d like, you can put the same kind of AI to work to contribute, even if you’ve never used it to build anything before.
The short version
Most websites are built by people typing code and content. This one is mostly built by asking an AI to do it. A maintainer opens Claude Code, describes a goal in ordinary English (say, “find and document real campus emergency alerts from this era”), and the AI takes it from there: it searches the web, reads the sources, writes each case into the project’s exact format, runs the project’s quality checks, and commits the result.
The remarkable part is how little steering it needs. The human isn’t writing the cases; they’re acting more like an editor and a director: pointing at a topic, setting the quality bar once, and reviewing what comes back. The work compounds: every session leaves the archive a little larger and a little better.
The scale so far
That is more than 1.5 million words of researched, sourced, and format-checked writing across 2,705 cases and 6,027 individual alert messages, of which 1,431, or 24%, are reproduced verbatim from a primary source. It was assembled over a couple of months in hundreds of small, reviewable commits. For comparison, 1.5 million words is roughly twenty novels.
Documenting 2,705 incidents and 6,027 individual alerts to this standard, each one researched, sourced, and fact-checked, would normally be months of work for a researcher or a small team. Here, the AI did nearly all of that heavy lifting: the reading, the cross-checking, the writing, the revising. The person behind it mostly decided what to work on next and reviewed what came back: hours of direction, not months of labor. The ongoing cost is just one paid personal Claude subscription (the Max tier), a single flat monthly plan quietly doing the work of far more. That gap, between how hard the AI works and how little the human has to, is the whole point.
What the AI actually does
Researches real incidents
It web-searches official alert archives, after-action reports, and student-newspaper coverage, and cross-checks the facts against multiple independent sources before writing a word.
Writes each case to a strict format
It produces a structured file per incident, preserving alert text exactly as sent (typos and all), tagging each message, and pairing every claim with a source link.
Checks its own work
A validator script enforces the rules: sources present, timestamps sane, no fabricated wording. The AI keeps fixing until it passes with zero errors and zero warnings.
Ships it for human review
It commits the work and opens a pull request: a proposed change the maintainer can read, question, and approve before it ever goes live.
Want to help? Here’s exactly how
You do not need to know how to code, and you don’t need to understand this project’s files. The whole job is: get your own AI pointed at a copy of this project, choose one of two tracks, paste its prompt, and let it work. It does the research, the writing, and the self-checking; at the very end you click one button to send your additions over for review.
You don’t need to add much, either. Even a few well-researched cases is a genuine contribution, and small additions are the easiest to review and accept. There is no quota and no pressure. Nothing you do is published automatically: every contribution is reviewed first, so you truly cannot break anything by trying.
What you’ll need first
A GitHub account (free). Sign up here. GitHub is the website where this project’s files live and where your additions get sent for review.
A paid Claude plan that includes Claude Code (the Pro plan or higher). See plans. Claude Code is the AI that does the work; it isn’t available on the free tier. This is the one part that costs money: the same kind of plan that built this archive.
The easy way: in your browser, nothing to install
Make your own copy of the project. Open this link and click “Create fork.” This puts a personal copy (a “fork”) in your own GitHub account, and you’ll work on that copy, never the original.
Open Claude Code on the web. Go to claude.ai/code and sign in with your paid Claude account.
Connect your GitHub account. The first time, it will ask to connect to GitHub: approve installing the Claude GitHub App and give it access to your forked copy of this project. (You only do this once.)
Start a task on your fork. Begin a new session and choose your copy of the repository. It’ll be named
your-username/campusalertarchive.Turn on “Auto accept edits.” Near the message box there’s a small mode menu; set it to Auto accept edits so the AI can work straight through without stopping to ask about every step.
Pick a track below, paste its prompt, and send it. Then simply wait. It will search the web, do the work, and check itself. This can take a while, which is completely normal; you can close the tab and come back.
Send it in with one click. When it finishes, it will have saved your additions to a new “branch” on your fork. Go to your fork on GitHub and click the green “Compare & pull request” button. Check that the line at the top points the base to
kjpacct202/campusalertarchive(the original), then click “Create pull request.” That’s the only thing it needs from you at the end.
That’s it. The maintainer reviews every pull request before anything goes live, and may ask the AI to refine or re-check it, so there’s no way to accidentally publish something wrong.
Prefer your own computer? (a bit more setup)
If you’d rather run it locally: install Claude Code, plus Git, Node.js (needed to run the project’s checker), and the GitHub CLI; run gh auth login once to sign in. Fork and clone the project, run npm install, then start claude in that folder (press Shift+Tab until it shows “accept edits”) and paste the same prompt. It will push a branch and either open the pull request or hand you the link to do it.
Pick a track, then copy its prompt
There are two ways to help. Both use the same setup above; just copy the prompt for the one you want and paste it into Claude Code. Each prompt already encodes the quality bar, the self-check, and the pull-request flow, so you don’t need to edit it.
Find verbatim text
Hunt down the exact official wording of alerts we currently only have paraphrased, and upgrade them to verified verbatim. This directly raises the share of the archive that is confirmed word-for-word.
Show the full prompt
You are helping me improve the Campus Alert Archive, an open archive of VERBATIM US campus emergency alerts. My job in this session is FACT-CHECKING: finding the exact official wording of alerts that are currently only reconstructed or paraphrased, and upgrading them to verified verbatim. You are working in a copy of MY fork of the project (this may be Claude Code on the web, or a local clone — either way, "origin" is my fork). Work carefully and never fabricate anything. IMPORTANT — I am an EXTERNAL CONTRIBUTOR, not the maintainer. CLAUDE.md and the .claude/ folder contain maintainer-only instructions (for example "always push to main", deploying to Vercel, internal "skills", and references to "Kevin"). IGNORE all of those. Only ever work on a NEW feature branch and propose changes through a pull request — never commit or push to the main or master branch of any repo. STEP 1 — Learn the rules: - Read CLAUDE.md (the quality bar; ignore its git / deploy / maintainer sections) and lib/types.ts (the AlertMessage schema, especially isVerbatimConfirmed, verbatimText, sourceUrl, sourceDescription, characterCount, and confidence). STEP 2 — Pick targets: - Search data/cases/*.json for alerts where "isVerbatimConfirmed": false. These are reconstructed or paraphrased, not yet verified word-for-word. Choose 3-8 of them to investigate, ideally well-documented incidents that are likely to have a public official record. STEP 3 — Hunt for the exact wording (web search required): - If you do NOT have web-search access in this environment, stop and tell me — do not guess. - Search the institution's official emergency-alert archive, campus-police / Clery pages, after-action reports, and student-newspaper articles that QUOTE the alert text. - Treat text as verbatim ONLY if you find the exact wording in a real, citable source. Preserve it exactly — typos, caps, punctuation, line breaks. Never normalize or "clean up" the wording. STEP 4 — Upgrade only what you can verify: - When you find the exact text: replace that alert's verbatimText with the exact wording, set "isVerbatimConfirmed": true, set sourceUrl to the page you found it on and sourceDescription to a short label (e.g. "UF Alert Archive"), and recompute characterCount to equal verbatimText.length. Set the case confidence to "high" only if the source is official (alert archive / official alert account / after-action report / Clery ASR). - If you CANNOT find the exact wording, leave that alert unchanged. Never invent or guess wording to make it "verbatim". Verifying fewer than you started with is completely fine. - Where helpful, add an inline [source](url) link in the case context, and update the case's lastUpdated date. STEP 5 — Validate until clean: - Run: `node scripts/validate-cases.mjs` — it MUST report 0 errors AND 0 warnings. Fix anything attributable to your edits. (If you truly cannot run node here, re-check each change against lib/types.ts by hand and tell me you couldn't run the validator.) STEP 6 — Propose the change as a pull request (NEVER to main): - Create a NEW feature branch, e.g. `factcheck/<short-topic>`. - Stage and commit ONLY the case files you changed, with a clear message listing which alerts you upgraded to verbatim and the sources you used. - Push the branch to my fork (origin). - If you are able to open a pull request yourself (a GitHub integration, or the `gh` CLI), open it against kjpacct202/campusalertarchive with base branch `main`, and give me the link. Otherwise confirm the branch is pushed, tell me its exact name, and give me the link to open the PR myself (base repo = kjpacct202/campusalertarchive, base = main). - Then STOP. Never push to any main or master branch.
Add new cases
Research real campus emergencies that aren't documented yet and add them as new cases, ideally with verbatim alert text. Great for filling gaps in eras, regions, and incident types.
Show the full prompt
You are helping me contribute new cases to the Campus Alert Archive, an open archive of VERBATIM US campus emergency alerts. My job in this session is CASE-FINDING: adding real campus emergencies that aren't documented yet. You are working in a copy of MY fork of the project (this may be Claude Code on the web, or a local clone — either way, "origin" is my fork). Work carefully and never fabricate anything. IMPORTANT — I am an EXTERNAL CONTRIBUTOR, not the maintainer. CLAUDE.md and the .claude/ folder contain maintainer-only instructions (for example "always push to main", deploying to Vercel, internal "skills", and references to "Kevin"). IGNORE all of those. Only ever work on a NEW feature branch and propose changes through a pull request — never commit or push to the main or master branch of any repo. STEP 1 — Learn the rules (read these before writing anything): - CLAUDE.md — the mission and the non-negotiable quality bar (but ignore its git / deploy / maintainer sections, per above) - lib/types.ts — the exact CaseStudy / AlertMessage schema - a few files in templates/ and several recent files in data/cases/ as worked examples STEP 2 — Add 3-5 NEW, real cases as JSON files in data/cases/, each meeting this bar: - Use web search to verify every incident against 2+ independent sources BEFORE writing. If you do NOT have web-search access in this environment, stop and tell me — never guess from memory. - Avoid duplicates: run `ls data/cases/ | grep <institution-slug>` and confirm the incident/date isn't already in the archive. - Prefer gaps: the archive over-represents large universities and active-shooter incidents. Cases from community colleges, HBCUs, tribal colleges, small or rural schools, US territories, older incidents, and NON-shooting events (severe weather, fires, hazmat, public health, etc.) are especially valuable. - Filename: YYYY-MM-DD-institution-slug.json (the date is the incident date). - Preserve alert text EXACTLY as sent — typos, caps, punctuation. Never invent or "clean up" wording. - isVerbatimConfirmed: true ONLY when you found the exact wording in a real source, and then set that alert's sourceUrl. Otherwise false, with confidence medium or low. - context: 2-4 inline [text](url) source links; summary: 1-2. - No placeholder midnight/noon timestamps; if the exact time is unknown use timestampApprox; always use the correct timezone. - Set characterCount equal to verbatimText.length for every alert. - Confidence "high" only with an official archive / official alert account / after-action report / Clery ASR. STEP 3 — Validate until clean: - Run: `node scripts/validate-cases.mjs` - It MUST report 0 errors AND 0 warnings. Fix anything attributable to your files, then re-run until clean. (If you truly cannot run node in this environment, carefully re-check each file against lib/types.ts by hand and tell me you weren't able to run the validator.) STEP 4 — Propose the change as a pull request (NEVER to main): - Create a NEW feature branch, e.g. `contribute/<short-topic>`. - Stage and commit ONLY your new data/cases/*.json files, with a clear message listing the institutions + incident types you added. - Push the branch to my fork (origin). - If you are able to open a pull request yourself (a GitHub integration, or the `gh` CLI), open it against kjpacct202/campusalertarchive with base branch `main`, and give me the link. - If you can't open it directly, that's fine: confirm the branch is pushed, tell me its exact name, and give me the link to open the PR myself (base repo = kjpacct202/campusalertarchive, base = main) so I can click "Create pull request." - Then STOP. Never push to any main or master branch.
New to this? Track 1 (finding verbatim text) is the easiest place to start, since the cases already exist and you’re just confirming the exact wording.
Authenticity is the entire point of this archive, so the prompt above holds your AI to one firm rule: never invent or polish an alert. When the exact wording of a message can’t be found, the case is still welcome; it just stays clearly labeled as reconstructed, with an honest confidence rating. That same standard is why a person reviews every contribution before it’s published, so you can try this out without worrying about getting anything wrong.
Curious about the bigger picture? Read more about why this archive exists.