Project Namer

Overview

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

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

• Single purpose or multi-purpose?
• What goes in it? (code, docs, tools, configs)
• Who uses it? (personal, team, public)

2. Clarify 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

4. Generate Options

• 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

• "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

• 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

• 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)

• 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