project-namer

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

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:

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)