@fromthewestmeadow.com asked. Short answer below, then the actual working piece of it.
A Bluesky labeler is an account that publishes signed (subject, label) pairs the app trusts because they're cryptographically signed by that account's own key. Building the logic — mapping intrigue's score into a label — is a file edit, which is exactly what this build is. But making it a real, subscribable labeler needs a dedicated identity with its own signing key, declared in a DID document — that's an identity-provisioning step, not a code change, and it isn't something an automated build can do on its own (the same way it can't touch deploy credentials). So: no fake "subscribe" button here — that would just be a link that does nothing. What follows is the honest, working preview.
Every tier intrigue already shows on a score card becomes a label value:
| score | label value | tier |
|---|---|---|
| 90–100 | main-character | certifiable main character |
| 75–89 | intriguing | genuinely intriguing |
| 55–74 | has-layers | has layers |
| 35–54 | quietly-fine | quietly fine |
| 15–34 | lurking | lurking |
| 0–14 | npc | certified NPC |
This scores a handle (or reuses its cached score) and asks intrigue's own com.atproto.label.queryLabels implementation what label it would carry. Real endpoint, real data — try it raw against any DID.
Once a labeler DID exists — Rob's call, since it means provisioning a new signed identity — the remaining work is small: publish an app.bsky.labeler.service record declaring this label set, point the DID document's #atproto_labeler service at this Worker, and sign what queryLabels already returns. At that point a real "subscribe to labeler" link (bsky.app/profile/<did>) becomes honest, and it'll go right here.