neo-identity-update

Repeatable protocol for updating Neo's identity (what Neo IS) coherently across ALL surfaces that encode it — README, VISION, learn/benefits, package.json, GitHub repo metadata, portal app, and the build-generated SEO files. Treats FACTS (version, MCP-server count, Node req, dates) as single-source-derive, FRAMING (taglines, positioning) as audience-segmented against a canonical apex, and ACTIONS / CTAs as governed next-step surfaces. Triggers: Use when changing Neo's tagline / positioning / description / keywords / pillar story / CTAs; when a maintainer says 'update the identity / README / branding / how we describe Neo'; when a shipped capability outgrows the current framing; or when a fact (version, server count, requirement) drifts across surfaces. Foundation: ADR 0018.

Quality

86%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

72%Weight 40%Scale 1-3

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-architected routing overview: concise, transparent about its reference structure, and explicit about non-negotiables. The executable workflow and validation checkpoints are deliberately delegated to update-protocol.md, which costs the body some actionability and inline workflow clarity.

Suggestions

Inline a 3–4 line condensed step sequence (Scope → Enumerate surfaces → Apply mechanic per class → V-B-A/CTA gates → cross-family review PR) so the body conveys the workflow shape without forcing an immediate file open.

Add one concrete verification command to the body (e.g. the seam-keyed grep used to confirm surface coverage) so a reader can act before opening update-protocol.md.

State the validation feedback loop (validate → fix → re-validate, or the cross-family-review merge gate) inline as an explicit checkpoint rather than only as a non-negotiable.

Dimension	Reasoning	Score
Conciseness	The body is lean — a short problem statement, a single MUST-read routing directive, and a compact non-negotiables list — and assumes Claude's competence without explaining concepts it already knows; every token earns its place.	3 / 3
Actionability	It gives concrete routing (an explicit path to update-protocol.md) and specific rules ("edit the generator buildScripts/docs/seo/generate.mjs"), but the executable steps, grep commands, and validation scripts are deferred to the reference rather than present in the body.	2 / 3
Workflow Clarity	The body flags one validation checkpoint ("every identity-surface PR needs a cross-family review") and routes to a sequenced protocol, but the step sequence and the V-B-A / liveness validation checkpoints live in update-protocol.md, not in the body itself.	2 / 3
Progressive Disclosure	A clear overview that transparently maps every reference — update-protocol.md plus the four payloads (surface inventory, facts ledger, framing-governance, CTA-governance) — with explicit paths and role labels, so navigation is easy even though routing runs through a hub; all referenced files exist in ./references/.	3 / 3
	Total	10 / 12 Passed

Description

100%Weight 40%Scale 1-3

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong, information-dense description: it states the concrete capability, gives explicit natural-language triggers, and carves out a clearly distinct niche. Its only weakness is verbosity — it is long for a description field — but every clause carries load rather than padding.

Dimension	Reasoning	Score
Specificity	It enumerates concrete identity surfaces ("README, VISION, learn/benefits, package.json, GitHub repo metadata, portal app, and the build-generated SEO files") and three distinct treatment classes (FACTS / FRAMING / ACTIONS), naming multiple specific concrete targets rather than vague language.	3 / 3
Completeness	Both halves are explicit: WHAT (a repeatable protocol treating FACTS/FRAMING/ACTIONS across all surfaces) and WHEN (an explicit "Triggers: Use when..." clause with several concrete triggering situations).	3 / 3
Trigger Term Quality	Natural maintainer phrasing is well covered — "update the identity / README / branding / how we describe Neo", "changing Neo's tagline / positioning / description / keywords / pillar story / CTAs", and "a fact drifts across surfaces" are terms a user would actually say.	3 / 3
Distinctiveness Conflict Risk	The niche is highly specific — cross-surface identity coherence governed by ADR 0018 with FACTS/FRAMING/ACTIONS mechanics — making it unlikely to fire for unrelated skills; the triggers are scoped to identity/branding changes, not generic edits.	3 / 3
	Total	12 / 12 Passed

Validation

93%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
relative_links	Relative link issues: 1 suspicious	Warning

	Total	15 / 16 Passed

Repository: neomjs/neo
Path: .agents/skills/neo-identity-update/SKILL.md
Commit: c1ce853

Reviewed: 8 days ago

Table of Contents

Discovery Implementation Validation

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.