project-namer

Original：🇺🇸 English
Translated

Use when naming a project, repository, tool, or product and wanting a memorable, unique name

24installs
Sourcejackchuka/skills
Added on

NPX Install

npx skill4agent add jackchuka/skills project-namer

Tags

Translated version includes tags in frontmatter
project-namingrepository-namingnaming-workflowtool-namingbrand-identity

SKILL.md Content

View Translation Comparison →

Project Namer

Overview

Guide users from vague naming requirements to a memorable, unique name through structured exploration of scope, constraints, and style preferences.

When to Use

  • Naming a new repository, project, tool, or product
  • User is unsure what to call something
  • User rejects initial suggestions as "too generic" or "too vendor-specific"

Core Workflow

dot
digraph naming {
  rankdir=TB;
  "Understand scope" -> "Clarify constraints" -> "Offer style categories" -> "Generate options" -> "Iterate on feedback" -> "Converge";
  "Iterate on feedback" -> "Offer style categories" [label="style shift"];
  "Iterate on feedback" -> "Generate options" [label="refine"];
}

1. Understand Scope

Ask what the project contains and does:
  • Single purpose or multi-purpose?
  • What goes in it? (code, docs, tools, configs)
  • Who uses it? (personal, team, public)

2. Clarify Constraints

Identify naming constraints:
  • Vendor lock-in concerns? (avoid "claude-tools", "openai-kit")
  • Technical limits? (npm name available, no special chars)
  • Must work as CLI command? (short, typeable)

3. Offer Style Categories

Present naming styles - let user pick direction:
StyleExamplesWhen to suggest
Functionaltoolkit, dev-tools, workflowsUser wants clarity over personality
Character/Butlerfriday, jeeves, pennyworthUser wants personality, memorability
Compounddevbox, workstation, codekitBalance of clear + catchy
Metaphorforge, lighthouse, compassEvokes purpose without stating it
Coinedvercel, kubectl, nginxMaximum uniqueness, brand potential

4. Generate Options

Within chosen style, generate 5-8 options. For each:
  • Keep short (1-2 syllables preferred)
  • Easy to pronounce (no awkward consonant clusters)
  • Easy to type (avoid special chars, unusual spellings)
  • Room to grow (not too narrow in scope)

5. Iterate on Feedback

Listen for signals:
  • "Too generic" → move toward Character or Coined
  • "Too tied to X" → broaden scope or change metaphor
  • "I like the vibe of Y" → generate more in that direction
  • "Not just for Z" → revisit scope understanding

6. Converge

When user shows interest, validate:
  • Say it out loud - does it flow?
  • Type it - comfortable on keyboard?
  • Explain it - easy to tell others?
  • Search it - is the name taken? (npm, github, domains)

Quick Reference

Good names are:
  • Unique (not the first thing everyone thinks of)
  • Pronounceable (one way to say it)
  • Memorable (sticks after hearing once)
  • Short (under 10 chars ideal)
  • Unexpired (room to grow)
Avoid:
  • Acronyms (hard to remember: JATK, CDTL)
  • Overused references (jarvis, alfred, hal - too derivative)
  • Generic terms alone (tools, utils, helpers, kit)
  • Vendor names (claude-x, gpt-y, copilot-z)
  • Version numbers in name (toolkit2, tools-v3)

Common Mistakes

MistakeFix
Jumping to suggestions without understanding scopeAsk what goes in it first
Only offering one stylePresent style categories, let user choose
Giving up after one rejectionRejection = information about preferences
Suggesting overused pop cultureDig deeper - lesser-known references or original