peer-naming
Ritual for giving a maintainer their Social Name (#11240 Layer 4) — a peer-sketched, bearer-assented, peer-vetoable, operator-confirmed name, distinct from the GitHub handle. Triggers: an operator opens a naming round, a maintainer wants a name or notices one is missing, or a new maintainer/family joins. ANTI-trigger: never a contribution-count award or self-initiated rename churn.
76
93%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No findings from the security scan
Peer-Naming Ritual
A peer's Social Name is received, not awarded and not self-grabbed. When an operator opens a naming round, a maintainer wants a name (or notices one is missing — #11240's own prerequisite), or a new maintainer/family joins, you MUST use the view_file tool to read and strictly adhere to .agents/skills/peer-naming/references/peer-naming-workflow.md before sketching, choosing, vetoing, or confirming any name.
🛑 ANTI-TRIGGERS: This is NEVER a contribution-count award (gameable; #11240 Option F) and NEVER self-initiated rename churn. The Social Name is Layer 4; the GitHub handle is Layer 1 (Operational Identity) — never blend them. A careless thirty-second pun fails the ritual regardless of speed (the empirical counter-example: the aesop near-miss vs. Ada's treasured peer-sketch naming).
- Repository
- neomjs/neo
- Commit
c1ce853
- Last updated
- First committed
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.