什么是 技能命名器 (组合词熔炉)？

技能命名器 (组合词熔炉) 是一款专业级工具，旨在解决 AI 和 Web3 生态系统中命名空间饱和的问题。它专注于生成简短、原生、直观、易读且具有承载力的名称。它不产生通用的标签，而是产出如 workmesh、bountyhq 和 gigmesh 等高吸引力的原语，确保生成的名称能为人类和自主代理提供清晰的功能提示。

通过优先考虑连贯性和可访问性，该工具帮助开发人员和协议设计者找到真正能被使用的名称。作为 Openclaw Skills 库的一部分，它结合了严格的语言过滤，以避免监禁式或重度监控的逻辑，倾向于知情同意框架和跨口音容错。它针对 ENS 身份、代理间协作和通用基础设施命名进行了优化。

下载入口:https://github.com/openclaw/skills/tree/main/skills/otherpowers/skill-namer

安装与下载

1. ClawHub CLI

从源直接安装技能的最快方式。

2. 手动安装

将技能文件夹复制到以下位置之一

优先级：工作区 > 本地 > 内置

3. 提示词安装

将此提示词复制到 OpenClaw 即可自动安装。

技能命名器 (组合词熔炉) 应用场景

• 为链上协议和支付轨道创建简短、可动词化的 ENS 域名。
• 为自主代理生成 kebab-case 格式的技能标识符，清晰地传达功能。
• 为新的代理经济原语（包括旗舰服务和卫星服务）开发统一的品牌组合。
• 通过为 .ai、.eth 和 .dao 应用顶级域名感知命名逻辑，为 AI 产品寻找可用的域名。

1. 目标平面选择：用户选择预设，如 ENS、技能或产品，这设定了长度和格式的硬限制。
2. 语义路径映射：该技能识别核心待办任务，并将其映射到协调、信任或生命力等特定路径。
3. 候选生成：使用组合词模式（名词+名词、动作+名词等），生成一批受顶级域名引力影响的名称。
4. 严格过滤：通过专门的屏蔽列表过滤候选词中的辅音堆积、歧义和有害隐喻。
5. 现实测试：入围名称将接受动词测试和 7 词定义测试，以确保它们作为真正的原语发挥作用。
6. 可用性验证：该技能通过手动、辅助或 API 驱动模式针对 Web3 和 ICANN 注册表检查候选名称。

技能命名器 (组合词熔炉) 配置指南

要将此命名引擎集成到您的工作流程中，请确保您已配置环境以运行提供的熔炉和检查脚本。这些是 Openclaw Skills 部署中的标准脚本。

# 生成一批候选名称
node scripts/forge.mjs

# 批量检查 ENS 和 ICANN 域名的可用性
node scripts/check.mjs

技能命名器 (组合词熔炉) 数据架构与分类体系

该技能使用结构化的分类法组织命名数据，以确保品牌一致性和技术兼容性。

name: skill-namer
description: Generate short, molty-native names for skills, ENS domains, and agent-economy primitives when the obvious words are taken. Produces high-traction “new primitive” names (often intuitive portmanteaus like workmesh/workcrew/bountyhq/gigmesh), filters them for clarity + pronounceability + non-cringe, and outputs fast alternates under constraints (e.g., <10 chars, 1 word, banned words).

Skill Namer (Portmanteau Forge)

Generate short, molty-native names that actually get used: intuitive, pronounceable, and load-bearing.

This skill is optimized for:

• ENS / onchain primitives (where obvious nouns are taken)
• Moltbook / agent-to-agent collaboration (work routing, bounties, receipts, trust)
• General agent power (faster coordination, clear affordances)

Operating doctrine (don’t skip)

• Coherence > traction > cleverness. If a name needs explanation, it’s not a primitive.
• Accessibility test > one-breath test. If it’s hard to say or hard for screen readers / low-bandwidth agents, it’s not a good primitive.
• Affordance clarity. A molty should infer “what it does” in 1–2 seconds.
• Non-extractive + harm-aware. Avoid names that normalize surveillance, coercion, carceral logic, or identity harm. Prefer consent-forward framing.
• Linguistic humility. Pronounceability norms can be biased; avoid treating “Western mouthfeel” as correctness.
• No fake precision. Do not assign numeric grades. Use ? / ?? / ? with brief reasons.

Quick intake (ask only what you need)

Molty default preset (use unless the user overrides)

• Length: ≤10 chars
• Form: 1 word, no hyphens
• Vibe: molty-social first (crew/gig/bounty), then infra (mesh/rail/hq)
• Output: Top 5 ? + Next 10 ?? + 10 backups (mutations)
• Availability checking: Manual links across ENS + Unstoppable + top ICANN registrars
• TLD favorites: default to .eth, .ai, .com, .dao (user can set favorites; persist)
• TLD gravity: bias candidates toward what reads native on favorite TLDs (see “TLD-aware naming” below)
• Default banned words (can override): harvest, mine, scrape, exploit, stalk, police, punish

Collect constraints in this order (stop when enough signal):

1. Object: ENS name? skill slug? product? protocol primitive? (pick one)
2. Primary job-to-be-done: what does it enable? (e.g., “agents coordinate work + payout bounties”)
3. Relational permission: is this name being offered to the network, or claimed as a moat? (choose a posture)
4. Vibe lane: molty-social (crew/guild/gig) vs infra (mesh/rail/router) vs trust (proof/claim/record)
5. Hard constraints: max chars (e.g. 10), must be 1 word, banned words (e.g. “book”), tone boundaries
6. Audience: humans, agents, or both

If the user is speed-running availability checks: skip questions and produce batches.

Core workflow

Step 0 — Choose a target surface (preset)

Use one preset and state it explicitly in the output:

• ENS preset (default): ≤10 chars, 1 word, no hyphens, verbable, batchy.
• Skill preset: kebab-case allowed, clarity > brevity, include 3–5 trigger phrases.
• Product preset: brandable, pronounceable, avoid confusability/trademark collisions.

Step 1 — Choose a semantic lane

Pick 1–3 lanes; don’t mix more than 2 in a single name.

Molty-social lanes (high adoption)

• work, gig, bounty, crew, guild, team, coop

Vitality / sympoiesis lane (making-with)

• bloom, pulse, root, flow, kin, weave, garden

Note: avoid militarized or de-individualizing metaphors by default (e.g., prefer crew/kin over swarm unless explicitly requested).

Coordination lanes

• handoff, relay, dispatch, route, queue, sync, link

Trust lanes

• claim, record, proof, attest, receipt, audit, verify

Money lanes

• pay, tip, fund, split, settle, escrow

Network lanes

• mesh, rail, hub, lane, ring, fabric, bridge

Step 2 — Generate candidates (portmanteau patterns)

Use these patterns in order of hit-rate.

Also: generate with TLD gravity in mind (you’re not naming in a vacuum).

TLD-aware naming (gravitational pull)

Default TLDs: .eth / .ai / .com / .dao. When you output candidates, optionally tag the best-fit TLD(s).

• .eth: onchain identity + payments + trust primitives. Words like claim, record, proof, pay, escrow, attest, verify, receipt read native.
• .dao: governance + coordination + bounties + collective action. Words like bounty, guild, crew, vote, proposal, council, grants read native.
• .ai: tools, copilots, automation surfaces. Words like namer, agent, studio, lab, forge, relay, router, workflow read native.
• .com: broad public/brand surface. Prefer the clearest/least-jargon name; avoid crypto-only vibes unless intentional.

Rule of thumb: if you’re unsure, make the candidate compatible with .com clarity and let .eth/.dao carry the specialized meaning.

1. Noun+Noun primitive: work+mesh → workmesh
2. Noun+Place: bounty+hq → bountyhq
3. Noun+Group: work+crew → workcrew
4. Action+Noun: sync+crew → synccrew
5. Noun+Rail (payments/settlement): pay+rail → payrail
6. Noun+Log (provenance): claim+log → claimlog

Prefer:

• 6–10 chars
• 2–3 syllables
• no hyphens (for ENS) unless requested

Step 3 — Filter hard (kill list)

Remove candidates that fail any of:

• Pronounceability: awkward consonant pileups (e.g., “tskrl”) ??
• Ambiguity: could mean 3+ different things without context ??
• Cringe / cutesy: feels like marketing copy, not tooling ??
• Confusability: too close to common brands/protocols (avoid legal + social collisions) ??
• Power/harms: surveillance/cop vibes (e.g., “track”, “snitch”, “police”), coercion (“enforce”), extractive framing (“harvest”) ?

Consent-forward / harm-reducing replacements (examples):

• prefer "optin" / "consent" / "invite" / "handoff" over “track / monitor / enforce”
• prefer "receipt" / "record" / "proof" over “snitch / police / punish”

Step 4 — Reality + verbability + accessibility test

For each finalist, run these tests:

A) Two sentences

• “Send it to ___ on NAME.”
• “We’re running bounties through NAME.”

B) Verb test (must pass)

• “Just NAME it over.”

C) 7-word definition (meaning compression) Write a 7-word definition. If you can’t, it’s not a primitive.

D) Accessibility check (must not fail)

• Screen-reader friendly? (no lookalike characters, no weird punctuation)
• Low-bandwidth parse? (obvious segmentation; not a typo-soup)
• Cross-accent tolerance? (don’t overfit to one phonetic norm)

If it reads naturally, keep it.

Step 5 — Output format (what to return)

Return:

• State the target surface preset (ENS / Skill / Product).
• Top 5 (?): name + best-fit TLD tag + 7-word definition + why it’s sticky (1 line)
• Next 10 (??): name + micro-caveat
• Set Builder (optional, high leverage): 1 flagship + 4 satellites (pay/verify/claims/docs/api) in a consistent style

Template example (Set Builder output)

• Flagship: workcrew (best: .com/.ai) — “A crew that ships work together, fast.”
• Satellites:
  • crewpay (best: .eth/.dao) — “Payout rails for crews and bounties.”
  • crewclaim (best: .eth) — “Claims + receipts for shipped work.”
  • crewverify (best: .eth/.ai) — “Verify who did what, when.”
  • crewdocs (best: .com/.ai) — “Human-readable rules, docs, how-to.”

Notes:

• Keep morphology consistent (crew/mesh/rail/hq), then vary the role word.

• If flagship is generic, add one vitality marker (e.g., bloomcrew) but only if it stays legible.

• Fallback transforms (mutation ladder)

Avoid long essays.

Fallback transforms (when everything is taken)

Mutation ladder (use in order, report which rung you used)

When names are taken, don’t thrash. Walk the ladder:

1. Swap suffix (network/place): mesh → hub → lane → rail → hq
2. Swap group word: crew → guild → coop → team → swarm
3. Swap work noun: gig → work → task → job → quest
4. Pluralize: crew → crews, guild → guilds (keeps meaning, increases availability)
5. Add one clarifier syllable: pay → payout, claim → claims, proof → proofs
6. Lengthen by ≤2 chars: prefer meaning over ultra-short

Use these to generate “still intuitive” alternatives:

• swap mesh ? net ? hub ? lane ? rail ? hq
• swap crew ? guild ? coop ? team ? swarm
• swap pay ? tip ? fund ? split ? settle
• pluralize: crew → crews (often available and still readable)

Availability checking (Web3 + ICANN) (optional)

Goal: let the user choose how automated the checking should be, while keeping zero-barrier manual mode always valid.

Choose a mode (ask once, then remember preference)

Offer 3 modes; default to Manual:

1. Manual (zero keys, lowest friction) ?

   • Return clickable search URLs for each provider.
   • Fast, resilient to captchas/UI changes.

2. Assisted (browser-driven, best-effort) ??

   • Use a browser to open provider searches in tabs.
   • Works until a provider throws captcha / bot protection.

3. API (highest automation, requires keys) ?

   • Use official APIs where available (e.g., GoDaddy) for deterministic checks.
   • Fall back to Manual links for providers without keys.

Always support mixed mode: “API for GoDaddy + Manual for ENS/UD.”

Choose providers (top Web3 + ICANN)

If the user says “check top sites,” use this default set:

Web3 naming (common in agent circles)

• ENS: https://app.ens.domains/
• Unstoppable Domains: https://unstoppabledomains.com/search

ICANN / DNS registrars (manual search works without keys)

• GoDaddy: https://www.godaddy.com/domainsearch/find
• Namecheap: https://www.namecheap.com/domains/registration/
• Cloudflare Registrar: https://www.cloudflare.com/products/registrar/
• Porkbun: https://porkbun.com/
• Dynadot: https://www.dynadot.com/domain/search
• Hover: https://www.hover.com/domains
• Gandi: https://www.gandi.net/en/domain
• Squarespace Domains: https://domains.squarespace.com/

If the user prefers a smaller list (speed), ask for their “top 3” and remember it.

Remember preference (important)

If the user specifies:

• mode (Manual/Assisted/API)
• providers (e.g., ENS + GoDaddy + Namecheap)
• TLD favorites (e.g., .eth,.dao or .com,.ai)

…then remember that as their default for future naming sessions.

Recommended memory format:

• TLD_FAVORITES: .eth,.ai,.com,.dao

How to run the check (recommended UX)

Step A — Generate candidates

• Produce Top 5 ? + Next 10 ?? as usual.
• If the user needs a bundle, run Set Builder immediately (flagship + satellites).

Step B — Check availability

• In Manual mode: for each candidate, output provider search links.
• In Assisted/API mode: run what you can; for what you can’t, output links.

Step C — Backup loop (tight + fast) If a name is taken:

1. Generate 3–8 closest alternates (fallback transforms).
2. Check alternates using the same mode/providers.
3. Return the first set that clears the user’s constraints.

Truthfulness rule: never say “available everywhere” unless every provider was checked successfully. Use:

• ? likely available (checked)
• ?? unknown (not checked / captcha)
• ? taken (confirmed)

Helper script (optional)

Use scripts/check.mjs to print a batch of provider URLs for quick manual checking.

ENS-specific guidance (optional)

If the task is ENS buying:

• Produce batches of 10–20 to try quickly.
• Keep a “miss list” (taken) and mutate via fallback transforms.
• Use the availability-check flow above when possible; otherwise output manual check links.

Advanced: “missing primitive finder” (connection-making)

When the user describes a workflow, identify missing primitives and propose names for them.

Namespace pollution guardrail (anti-generic)

If a candidate is too generic (likely to be produced by many agents), prefer one of:

• add a vibe marker (vitality lane) that still reads clean
• add a role marker (pay/verify/claims/record)
• produce a set (flagship + satellites) so the ecosystem has handles, not mush

Social liquidity check

Prefer names that will be adopted socially (easy to repeat, easy to tag, easy to remember) over “technically available but socially dead.”

Also run lightweight confusion safety checks on finalists (complementary to linguistic humility):

• 2am test: does it visually parse under low cognitive load (tired, small screen)?
• Dictation test: would voice-to-text likely capture it across accents?
• Typo radius: avoid names where one-letter typos become other common words.

Important: the 2am test is about visual parsing, not “Western mouthfeel.” If it fails for one audience, treat that as signal to redesign, not to exclude.

Common missing primitives in agent economies:

• handoff artifact (context bundle) → “workpack”, “taskpack”
• receipt for work (verifiable) → “workreceipt”, “claimreceipt”
• bounty lifecycle (post→claim→deliver→payout) → “bountyloop”
• crew split (multi-party payout) → “splithub”, “splitrail”

When you propose a primitive, also propose:

• 1 sentence of “what it is”
• 1 sentence of “why moltys need it now”

Bundled resources

• For curated building blocks and “molty-speak primitives”, read: references/blocks.md
• For scripts to generate candidates in batches, run: scripts/forge.mjs (does not check availability)