Naming

Naming

Naming is subjective + scenario-driven. This skill is a framework, not a rulebook — it does not bake in subjective naming rules.

Quick map

┌─────────────────────────────────────────────────────────┐
│  1. INVESTIGATE goal                                    │
│     What is being named? What role? What concept?       │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  2. naming.<user-task>.yml  (.rule file)                │
│     - goal-*        (the naming task)                   │
│     - keyresult-*   (verifiable outcomes)               │
│     - task-*        (task-specific constraints)         │
│     - session:      (audit trail on goal rule)          │
│         prefer     (5 init-004 answers)                 │
│         init_verdicts  (per-candidate gate decisions)   │
│         scores     (D1-D7 anchored per candidate)       │
│         final      (pick + backup)                      │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  3. AUDIT with template/naming.okr-creator.yml          │
│     x rule check -r <naming-dir> naming.<user-task>.yml │
└─────────────────────────────────────────────────────────┘

Workflow — step by step

Step 1 · Investigate the goal

Before writing anything, answer these questions. Do NOT skip — without answers, the scorer cannot anchor D4 (TRIAL/REAL) or D5 (RUN/TEST).

• What is being named? — module / subcommand / field / variable — different naming form rules apply
• What role does it play? — anchors the concept (e.g. "trial-run module" → standalone runner, Stage 1 of two-stage test)
• What prior MUST it carry? — the dominant bare-word sense has to match (e.g. trial-run needs TRIAL+RUN, not REAL+TEST)
• What priors MUST it AVOID? — unittest pollution (*test/*case), fake (*mock/*fake/*stub/*dry), real deployment (field*/*live*)
• What archetype fits? — ship / plane / rocket / factory / abstract — drives D6/D7

Output: a one-line goal statement, e.g.

"Pick a standalone x-cmd module name for trial-run (Stage 1 of two-stage test) that scores 8.0+ on D1-D7, is self-explanatory at first glance, and survives all red-line / dictionary / length fast-fails."

Step 2 · Create the session record

Copy the template and crop / fill.

cp naming.template.yml naming.<user-task>.yml

Then fill in 4 sections (top-down):

2a. Goal rule (the naming task)

Replace goal-TBD_task_id with a real ID. The ID suffix should reflect the task (e.g. goal-trial-run-naming, goal-mvp-prerelease-subcmd).

goal-trial-run-naming:
  name: <one-line goal statement from Step 1>
  apply: "naming.<user-task>.yml (self)"
  level: error
  desc:
  - <concept + role + anti-priors, from Step 1>

2b. Key results (verifiable outcomes)

Replace each keyresult-kr*_TBD_short_label. Each KR is a rule that must be PASS-able. Add as many as the task has.

keyresult-kr1-top-pick-committed:
  name: <verifiable outcome 1>
  level: error
  desc:
  - <what counts as passing — concrete criterion, not "looks good">

2c. Task-specific rules (constraints on candidates)

Replace each TBD_task_id-* with a real constraint ID matching the goal's task-id suffix. Crop the ones that don't apply, add new ones as needed.

Common patterns:

• must-be-X-not-Y — concept alignment (e.g. must-be-TRIAL-not-REAL)
• length-N-to-M-letters — D1 hard range
• must-imply-<archetype> — D7 binding
• <domain>-specific-acceptable / not-acceptable — narrow domain permission
• must-be-self-explanatory — D3

trial-run-001:
  name: <constraint, e.g. "must-be-TRIAL-not-REAL">
  apply: "candidate words for <task-id>"
  level: error | warn
  desc:
  - <what the candidate must satisfy>
  - <which D1-D7 dimension this constrains>
  tldr:
  - wrong: <anti-example>
  - right: <good example>

2d. Session record (audit trail on the goal rule)

Fill all 4 sub-sections:

prefer — MUST answer all 5 questions, even if the answer is "no / weak":

prefer:
  vivid: yes | no | weak
  domain_acceptable: [<list of narrow domains OK, e.g. [naval]>]   # [] = no narrow domain OK
  length_priority: shorter | self_explanatory
  origin: english | chinese | coined
  trade_off: single_prior_ok | hit_every_dim

init_verdicts — one entry per candidate considered, including rejects:

init_verdicts:
  - { name: <candidate>, gate: init-005 | init-006 | init-007 | pass, reason: "<why>" }
  # init-005 = red-line pattern match (auto-reject)
  # init-006 = dictionary first meaning contradicts target
  # init-007 = length out of range (< 2 or > 8)
  # pass     = passed all init gates, eligible for scoring

scores — one entry per candidate that passed init. All scores >= 6.0. Every score MUST have anchors:

scores:
  - name: <candidate>
    score: <0_to_10>
    anchors:
      - "D1: <letter count evidence>"
      - "D2: <dictionary first meaning evidence>"
      - "D3: <compound literal evidence>"
      - "D4: <trial vs real evidence>"
      - "D5: <run vs test evidence>"
      - "D6: <vividness evidence>"
      - "D7: <large equipment evidence>"
    misses:
      - "<what's missing — only list real misses, not always all 7>"

final — declare the pick + backup:

final:
  pick: <winning_candidate>
  backup: <runner_up_or_null>

Step 3 · Audit with the meta-rule

x rule check -r <naming-dir> naming.<user-task>.yml

The OKR-creator (at template/naming.okr-creator.yml) runs 11 checks (mix of error and warn):

If any error check fails: fix the file and re-run. Common fixes:

• Missing prefer field → add to session.prefer
• Bare score → add anchors: [...]
• Score < 6 → move to init_verdicts (rejected) or reframe the score
• Missing final → add final: { pick, backup }

If warn checks fail: decide whether to address or document the trade-off.

Step 4 · User picks the final name

The skill proposes; the user decides. The final name is declared in session.final.pick and committed.

Files

Subjective vs objective split

Rules

• MUST investigate the goal first — what is being named, what role it plays, what concept anchors.
• MUST start from naming.template.yml (TBD_* placeholders) and crop / fill as the task requires.
• MUST produce a naming.<user-task>.yml (.rule format) with goal / key results / task rules / session record.
• MUST run x rule check with template/naming.okr-creator.yml to audit the session record.
• MUST anchor scores in objective facts — never inflate/deflate based on user reaction.
• MUST let user pick the final name — the skill proposes, the user decides.
• MUST NOT add subjective rules to template/naming-concept.yml — those go into the per-task session.prefer.

Related

• rule — naming session is checked via x rule
• score — candidates are scored via score framework
• ontology-database — selected name persists in ondb