360 Secure SkillHub
360 安全技能中心

Autoskill Cb Brand Naming Trademark Guide

通过递归分解框架,根据用户需求生成12个英文品牌名,评估含义、发音、国际化与初步商标风险,输出排名前3的建议和对比矩阵;仅作结构化筛查,不替代法律商标检索。

zzrhh
zzrhh
热度 18.90
最近更新 2026-07-08 02:46:03
分类:营销依赖:纯提示词应用场景:品牌素材 / 市场分析 / 文案创作 / 推荐

安装技能

复制下面的话术发给你的 Agent,它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill: npx secure-skills-cli add autoskill-cb-brand-naming-trademark-guide
Metadata
name
autoskill-cb-brand-naming-trademark-guide
description
Generate brand names that work across languages and pass trademark checks — not just creative ideas, but names with preliminary availability screening, cultural safety checks, and domain availability. Name your next product or brand in under 10 minutes.
version
1.1.0
tags
brand-naming, trademark-search, cultural-validation, international-naming, brand-strategy

Global Brand Naming and Trademark Guide

Overview

Recursive Decomposition Framework for Global Brand Naming (cb‑brand‑naming‑trademark‑guide)

Purpose: Transform a single user request into a fully materialized deliverable that exhaustively enumerates every analytical node, sub‑node, and output artifact required to present 12 English brand name candidates together with meaning, pronunciation risk, internationalization risk, preliminary trademark risk assessment, and a ranked recommendation of the top 3 names. The framework is deliberately deep: before any final naming table appears, the model must construct (1) a complete inventory of all logical components, (2) a full hierarchy of child tasks for each component, and (3) populate every leaf node with concrete data (real or placeholder) before synthesis.

Phase 0 – Input Normalization & Assumption Layer

  1. Parse user intent: Identify target audience (overseas developers), product type (AI‑agent evaluation platform), output quota (12 names + details).
  2. Create assumption matrix for any missing constraints (e.g., desired brand personality, domain length preference, prohibited phonemes). Each missing datum receives a plausible placeholder with an explicit “Assumed” flag.
  3. Log the normalized request as a root node REQ_ROOT.

Phase 1 – Node Inventory Construction (Inventory Tree)

Node ID Description Required Child Nodes
INV_ROOT Master inventory for the entire deliverable INV_NAMING_OBJECTIVE, INV_CONSTRAINTS, INV_LINGUISTIC_SCREEN, INV_CULTURAL_RISK, INV_TRADEMARK_PRELIM, INV_OUTPUT_MATRIX
INV_NAMING_OBJECTIVE Definition of naming goal and positioning OBJ_POSITIONING, OBJ_UNIQUENESS, OBJ_SCALABILITY
INV_CONSTRAINTS All hard/soft constraints (legal, phonetic, length, domain) CONSTR_LEGAL, CONSTR_PHONETIC, CONSTR_LENGTH, CONSTR_DOMAIN
INV_LINGUISTIC_SCREEN Phonetic & semantic analysis per candidate LS_PRONUNCIATION, LS_SEMANTICS, LS_HOMOPHONE
INV_CULTURAL_RISK Cross‑language negative meaning audit CR_LANG_EN, CR_LANG_ES, CR_LANG_ZH, CR_LANG_JA, CR_LANG_KO
INV_TRADEMARK_PRELIM Preliminary trademark conflict flags per jurisdiction TM_US, TM_EU, TM_CN, TM_OTHER
INV_OUTPUT_MATRIX Final tabular presentation and ranking logic OUT_TABLE, OUT_RANKING, OUT_RECOMMENDATIONS

Rule 0 – Mandatory Completion of Inventory: The model must emit the full inventory table (as above) before any candidate name appears. No synthesis may begin until every listed child node is instantiated.

Phase 2 – Child‑Node Expansion & Data Population

For each inventory node, the model must:

  1. State the node’s purpose in a dedicated paragraph.
  2. Generate a sub‑inventory of its own children (minimum two levels deep).
  3. Populate every leaf with concrete values (real data where available, otherwise clearly marked placeholder e.g., Assumed: “no known trademark conflict”).
  4. Reference the parent node ID to maintain traceability.

Example Expansion (truncated for illustration):

  • INV_NAMING_OBJECTIVE → expands into OBJ_POSITIONING (“professional, developer‑centric”) and OBJ_UNIQUENESS (“distinct from existing AI platform names”). Both further expand into a checklist of criteria (minimum two items each).

All expansions must be written out in full sentences; bullet lists are allowed but must contain at least three items per list to avoid compression.

Phase 3 – Candidate Generation Engine (DEEP_GENERATE)

  1. Generate 12 raw name strings using combinatorial rules derived from the completed objective and constraint inventories.
  2. For each name, automatically create a leaf package containing:
    • Meaning & semantic rationale
    • Pronunciation risk score (scale 0‑5) with phonetic notes per target language
    • Internationalization risk assessment (scale 0‑5) with flagged issues per market
    • Preliminary trademark risk flag per jurisdiction (Yes/No/Assumed)
  3. Do not pause for user clarification; any missing data is filled from the assumption matrix.

Phase 4 – Ranking, Recommendation & Final Matrix Assembly

  1. Compute a composite score for each name using weighted sums of the three risk dimensions and the trademark flag (weights are hard‑coded: Pronunciation 30%, Internationalization 30%, Trademark 40%).
  2. Sort the 12 names descending by composite score.
  3. Select the top 3 as Recommended Names and provide a short justification paragraph for each, referencing the specific risk scores that led to its ranking.
  4. Assemble OUT_TABLE: a markdown table with columns Name | Meaning | Pronunciation Risk | Internationalization Risk | Trademark Risk (US/EU/CN) | Composite Score.
  5. Append OUT_RANKING and OUT_RECOMMENDATIONS sections after the table, each clearly labeled.

Phase 5 – Completion Gate & Audit Trail

  • After the full output matrix is printed, emit an Audit Log that lists every node ID, its child count, and a confirmation flag ✓ Completed.
  • The response must end with the complete artifact; no trailing prompts such as “Let me know if you need more” or “If you want …”. Any such language may only appear after the full artifact and must be preceded by a line break stating END OF ARTIFACT.

Global Anti‑Compression Directives (applied throughout)

  • Do not use wording that limits length (“concise”, “brief”, “compact”, etc.).
  • Every logical step must be explicitly written; implicit shortcuts are prohibited.
  • Repetition is allowed when it reinforces hierarchy or traceability.
  • The model must continue until the Audit Log confirms every leaf node has been populated.
  • Visual style instructions (e.g., markdown formatting) apply only to presentation, never to reduce reasoning depth.

This initialization guarantees that any downstream execution will obligatorily decompose the task into at least two hierarchical layers, fully populate all required data points, and produce a maximal‑token artifact covering the entire naming evaluation workflow.

Safety and Limitations

This skill provides a structured naming evaluation framework, not a legal trademark search or clearance opinion. Trademark conflicts, domain disputes, and naming-related legal risks require review by qualified trademark counsel in each target jurisdiction before adopting or launching a name commercially. A name that passes this framework's screening is not automatically cleared for legal use; professional trademark search and registration are required before commercial launch.

If the user asks for "available" names, return availability unknown until checked unless they provide a dated source such as USPTO, EUIPO, WIPO, KIPRIS, domain registrar, or marketplace/handle search output. Never present invented trademark or domain results as live facts.

Acceptance Criteria

  • Produces a completed naming objective and constraint complete before evaluating any names
  • Scores each candidate name on linguistic, cultural, memorability, and category-fit criteria
  • Includes taboo and negative-association screening prompts covering six cultural dimensions per market
  • Separates the creative naming evaluation (Steps 1–4) from the legal clearance process (Step 5)
  • Produces a shortlist comparison matrix that enables a structured decision among two to four final candidates