NowAssistSkillConfig rejects hyphens in name (TS210), and the generated sys_one_extend_capability inherits that restriction

[dalestubblefield]

Summary

NowAssistSkillConfig validates name against /^[a-zA-Z0-9 ]+$/ and rejects hyphens, underscores, and punctuation. The generated sys_one_extend_capability record then copies the skill name verbatim, so the restriction propagates to the capability record's name.

I would like to understand whether the letters/numbers/spaces rule reflects a platform constraint or is an SDK-side guard, and whether hyphens could be allowed.

Environment: @servicenow/sdk 4.8.1, Australia Patch 2 Hotfix 2.

Repro

NowAssistSkillConfig(
    {
        $id: Now.ID['skill_example'],
        name: 'My Skill some-hyphenated-id',
        state: 'published',
        // inputs, securityControls omitted
    },
    { providers: [ /* ... */ ] }
)

npm run build:

[now-sdk] ERROR: src/fluent/skills/example.now.ts:15:5 - error TS210: Skill name
'My Skill some-hyphenated-id' contains invalid character(s): -. Skill names must contain only
letters, numbers, and spaces. Please remove special characters, underscores, and punctuation.

Replacing the hyphens with spaces builds clean.

Where it comes from

In @servicenow/sdk-api/dist/external-plugins/nask.js:

• validateName() enforces const regex = /^[a-zA-Z0-9 ]+$/, and is called for the skill name, prompt names, and attribute names.
• The capability record is created with name: $.from("name"), so sys_one_extend_capability.name is the skill name unchanged.
• SKILL_NAME_MAX_LENGTH is 40.

Why it matters

The capability name is the only stable, human-readable handle a scoped app has for resolving a skill at runtime, for example via GlideRecord('sys_one_extend_capability') on name. Resolving by name is attractive because it keeps sys_ids out of source and out of per-instance configuration.

That makes the naming rule more consequential than a display-name style preference:

• Hyphens are the common convention for machine-readable identifiers, and any scheme that derives a capability name from such an identifier is blocked.
• Workarounds require encoding the identifier (for instance, substituting spaces for hyphens) and decoding it on lookup. That encoding becomes a hidden invariant which is easy to break later.
• The restriction is not documented in the skills guide, and now-sdk explain nowassist-skills-guide does not mention it. It surfaces only at build time.
• The diagnostic explains the rule for the skill name, but does not mention that the capability record inherits that name, which is where the downstream constraint actually bites.

Questions

1. Is /^[a-zA-Z0-9 ]+$/ enforced by the platform on sys_one_extend_capability.name and sn_nowassist_skill_config, or is it an SDK-side guard that could be relaxed to permit - and _?
2. If it is a platform rule, could it be documented in the skills guide, and could the diagnostic note that the capability record inherits the skill name?
3. Is there a supported way to give a skill a stable machine-readable key decoupled from its display name? A separate internalName on the capability would address this cleanly.

Happy to supply a minimal reproduction repo if useful.