handle_integrity_check v1.0.0

name: "handle_integrity_check" description: "Check a new username or handle before adopting it across platforms: validate each candidate against per-platform username rules, find the closest form that works everywhere, scan for hidden and look-alike Unicode characters that invite spoofing or break pasted logins, compare candidates against existing handles for confusability, and record the final handle set in one registry. Use when picking a handle, rebranding, renaming an account, auditing a handle someone pasted to you, or checking whether two handles are confusingly alike."

Purpose

A handle picked for one platform usually breaks on another, and a handle picked by eye can hide characters nobody saw. This skill runs one candidate list through three gates in order: platform format rules, character integrity (invisible characters, confusables, mixed script, normalization surprises), and cross-platform adoption (closest universal form, per-platform variants, claim order, and a written registry). It ships a platform rules table in references/platform-rules.md and a runnable scanner in scripts/handle_check.py.

The scanner checks format and character integrity offline. It does not and cannot check availability. A format pass never means a name is free.

Workflow

1. Collect candidates in raw form

• Get the candidates exactly as they will be typed or pasted, including any candidate copied out of a chat, doc, or logo file. Pasted candidates are the risky ones: they can carry zero width characters that nobody can see.
• Write down the target platform list before checking. The default set is X, Instagram with Threads, TikTok, YouTube, Discord, Twitch, GitHub, and Bluesky. Drop platforms the user does not care about and say which ones were dropped.
• Note any existing handles the new one must not be confused with: the user's current handles, a previous brand, a collaborator, or a well known account in the same niche. These are the comparison set for step 4.

2. Run the scanner on every candidate

Run from the skill directory:

python3 scripts/handle_check.py musefm "muse.fm" "muse-fm"
python3 scripts/handle_check.py --file candidates.txt

• Read three things in the output: the integrity verdict (fail lines are hard stops), the per-platform pass and fail table, and the universal candidate line.
• A candidate with an integrity failure never gets adopted in that form, even if every platform row passes. Fix the string first, then re-run.
• Keep the raw scanner output for the final report. Do not summarize away a failure.

What the scanner screens for, and why each item matters:

• Invisible and control characters: U+200B zero width space, U+200C, U+200D, U+FEFF, U+00AD soft hyphen, U+2060 word joiner, bidi controls U+202A to U+202E and U+2066 to U+2069, U+3164 Hangul filler, U+2800 Braille pattern blank. A handle containing one displays as one string and compares as another, so mentions, logins, and searches break in ways nobody can see.
• Confusable characters, using a simplified Unicode UTS #39 skeleton: normalize to NFD, map each character through a confusables table, compare the result. Cyrillic a (U+0430) skeletons to Latin a, Cyrillic o, e, p, c, x and Greek omicron do the same for their Latin twins. Two strings are confusable when their skeletons are equal.
• Mixed script in one handle, such as Latin plus Cyrillic. Even when each character is harmless alone, a script mix is the shape of a spoof.
• NFKC surprises: fullwidth, ligature, and mathematical styled characters fold to plain letters under NFKC normalization. If a platform normalizes on save, the stored handle differs from the pasted one.
• Ambiguous ASCII: l, I, and 1 in one handle, or O and 0. Not a security failure, a readability one. The handle will be misread aloud, in screenshots, and in low resolution avatars.

The bundled confusables map is a high risk subset, not the full file. For a high stakes audit, download confusables.txt from the Unicode security data directory and extend the map in scripts/handle_check.py, then re-run.

3. Settle the form: universal first, split on purpose second

• Start from the universal intersection in references/platform-rules.md: 5 to 15 characters, lowercase letters and digits only, no separator. That is the only shape that passes X, Instagram, TikTok, YouTube, Discord, Twitch, GitHub, and a Bluesky .bsky.social label at the same time.
• If the desired name needs a separator, know what each choice costs before choosing: period fails X, Twitch, GitHub, and Bluesky. Underscore fails GitHub and Bluesky. Hyphen fails X, Instagram, TikTok, Discord, and Twitch.
• When no single form works, build the closest form per failing platform by applying, in this order: strip the separator, swap the separator for that platform's allowed one, shorten from the least meaningful end to fit the tightest length cap (X at 15 is usually the binding one), then add a short meaningful suffix. Re-run the scanner on every derived form.
• Reject derived forms that change the reading: a suffix that turns the handle into someone else's name, a truncation that spells a different word, or a digit swap (0 for o, 1 for l) that creates the exact look-alike problem this skill exists to prevent.
• Threads needs no variant and no separate check. Its username mirrors the linked Instagram username, so the Instagram form is the Threads form.

4. Compare against the existing set

Check the finalist against every handle collected in step 1:

python3 scripts/handle_check.py --compare candidate existinghandle

• Equal skeletons mean confusable. Do not adopt a finalist that skeletons equal to an existing handle unless it is the user's own handle on another platform and the sameness is the point.
• Skeleton equality is a floor, not a ceiling. Also eyeball one-edit neighbors: one letter added, dropped, swapped, or doubled, and the multi-character visual pairs rn and m, cl and d. A handle one edit away from a bigger account in the same niche invites misdirected mentions even though no rule is broken.
• Run the comparison in the other direction too: think about who could spoof the new handle once it has an audience. If a trivial look-alike variant exists (a doubled letter, an underscore version, a Cyrillic twin that display fonts render identically), note it in the registry as a watch item, and where a platform allows a second account, consider claiming the most obvious variant defensively.

5. Verify availability live, platform by platform

• Check availability inside each platform's own username field or signup flow, most restrictive first: X, then Bluesky and GitHub, then Twitch, TikTok, Instagram, YouTube, Discord. The restrictive platforms are where the form is likeliest to be taken or rejected, and their answer can change which variant becomes the lead form.
• Record one of three states per platform: available, taken, or could not verify. Captchas, login walls, and rate limits produce could not verify, never a guessed available.
• A taken result restarts step 3 with the next variant. Do not silently drift: if X ends up with one form and Instagram with another, that split goes in the registry as a decision, with the reason.

6. Claim in order and record the handle set

• Claim promptly once the set is settled, in the same restrictive-first order. An available handle is not reserved by checking it.
• Before renaming an existing account, read the change-window notes in references/platform-rules.md: some platforms lock the next change for weeks, a released old handle can be claimed by someone else, and profile URLs change. List where the old URL is published before the rename, not after.
• Write the registry entry (see Output Contract) the same day. A handle set that lives in chat history is a handle set that gets lost.

Output Contract

Deliver all four parts:

1. Candidate table: each candidate, its integrity verdict, and its per-platform pass and fail summary, from the actual scanner output.
2. The settled handle set: the universal form if one exists, otherwise the per-platform forms with the reason for each split.
3. Confusability report: skeleton comparisons against the existing set, one-edit neighbors worth noting, and any defensive variants to watch or claim.
4. Registry entry, one row per platform, ready to save:

platform,handle,profile_url,date_claimed,display_name,old_handle,notes
x,musefm,https://x.com/musefm,2026-10-30,Muse FM,,universal form
instagram,musefm,https://instagram.com/musefm,2026-10-30,Muse FM,,threads mirrors this
bluesky,musefm.bsky.social,https://bsky.app/profile/musefm.bsky.social,2026-10-30,Muse FM,,label only in handle column if your registry prefers it, be consistent

For the worked example above, musefm at 6 lowercase letters passes every platform row in the scanner, which is what a clean run looks like. muse.fm fails X, Twitch, GitHub, and Bluesky. muse-fm passes only YouTube, GitHub, and Bluesky.

Operating Rules

1. Never report a handle as available from a format check, a search result, or a third party checker site. Availability comes only from the platform's own field, checked live, or it is reported as could not verify.
2. Never adopt or recommend a candidate with an invisible, control, or confusable character in it, and never fix one by silently retyping it. Show the user the code point, remove it, and re-run the scanner on the cleaned string.
3. Never present skeleton equality as proof two handles are safe. It catches character level spoofs. One-edit and visual pair look-alikes need the human pass in step 4.
4. Keep the raw form and the canonical form both in the registry when they differ, for example a display capitalization versus the lowercase handle every platform actually stores.
5. Re-check references/platform-rules.md against current platform help before a real rename. The table is dated research, and the in-app field wins any disagreement.
6. Do not buy, sell, or broker handles, and do not suggest evading a platform's reserved word or impersonation rules. A blocked name gets a new candidate, not a workaround.