How it works
Every Thursday a new challenge is published: one specific thing on your website that is commonly broken without anyone noticing, and a fifteen-minute way to find out whether yours is. Each one gives you the problem, what you need, a safe inspection workflow that observes before it changes anything, a prompt you can hand to Claude Code for the repository-side reading, an example of what the evidence looks like, the completion criteria, and the mistakes people make.
You do it on your own site. At the end you tick the criteria you met and save the record to My Projects in your browser. The record is *self-reported* — the site cannot see your inbox or your deployment history, and it does not pretend to. Several challenges pair with a lab where the same fault is planted in a controlled site; matching the lab's answer is recorded separately, as *verified against example*.
What you get out of it
A site that has been checked, one thing at a time, on a schedule — and a written record of what was checked, when, with what result. That record is the thing most small sites do not have, and it is what makes next month's check a comparison instead of a guess.
Reminders, if you want them
The form below adds you to a separate list that receives one email when a challenge is published — at most one a week. It is the same store email system the guides list uses, with its own tag, so unsubscribing from one does not affect the other. No signup is needed to take the challenges: the schedule is on this page, every published challenge is in the archive, and there is an RSS/Atom feed.