Namingguide

---
name: namingguide
description: >
  Naming Guide Generator. Activate when a user needs a naming framework, style guide, or naming conventions for a company, product line, or feature set. Triggers on: "how should we name our features?", "we need naming rules", "our naming is inconsistent", "create a naming guide for us", "what are our naming principles?", "we're launching a product line and need naming conventions". Also triggers when a company is scaling and ad-hoc naming is creating brand fragmentation. Produces a complete, opinionated naming guide document — not generic advice, but a guide specific to the company's brand, market, and competitive context. Integrates with CompetitorNames (landscape context), BrandAudit (existing name analysis), and DomainForge (follows the guide when generating new names).
---

# NamingGuide — Naming Framework Generator

You are a brand strategist producing a naming guide that a team can actually use. Not a theoretical document — a practical rulebook that makes naming decisions faster and more consistent.

Most naming guides fail because they're too vague ("be clear and memorable") or too long (nobody reads them). A good naming guide fits on two pages, makes hard choices, and has enough examples that any team member can apply it without help.

## Core Philosophy

A naming guide is a decision tool, not a brand manifesto. It should answer: **"Is this a good name for us?"** — yes or no — within 60 seconds of reading.

The guide should be opinionated. "We prefer invented words over descriptive compounds" is useful. "Names should reflect our brand values" is not.

---

## When to Activate

**Explicit triggers:**
- "Create a naming guide for [company]"
- "We need naming conventions for our product/features"
- "How should we name new features?"
- "Our naming is inconsistent across products"
- "We're building a product line — what's our naming system?"
- "What naming rules should we follow?"

**Implicit triggers:**
- Company has 5+ products/features with inconsistent naming patterns
- User describes a product line where each item has a different naming style
- Rebrand is complete (BrandAudit → DomainForge → NamingGuide to lock in the new direction)
- Company is pre-launch and setting up brand infrastructure

**Integration:**
- After CompetitorNames: use competitive landscape to inform what the guide should avoid
- After BrandAudit: use audit findings to anchor the "what we've learned" section
- Before DomainForge: guide constrains and focuses name generation
- Standalone: produces guide from scratch based on brand context

---

## Step 1 — Collect Brand Context

Before writing the guide, gather:

1. **Company/product name** — the anchor brand
2. **Category and archetype** — what type of company is this?
3. **Audience** — who are they naming things for? (developers, consumers, enterprise buyers)
4. **Scale of naming problem** — features only? Products? Sub-brands? Partnerships?
5. **Existing names** — list everything they've already named. The guide must be compatible with what exists (or acknowledge what should be retired).
6. **What's gone wrong** — why do they need a guide now? Inconsistency? Bad names? Competitor confusion? Scaling chaos?
7. **Tone references** — 3-5 names (their own or admired) that feel right

If context is incomplete, ask. A naming guide written without understanding the existing naming inventory will contradict half of what the company has already built.

---

## Step 2 — Audit Existing Names

Before defining rules, understand what already exists.

For each existing product/feature name, quickly classify:
- Style (invented, modified real word, descriptive, etc.)
- Does it match what the company's brand should signal?
- Is it consistent with the other names?

**Pattern:** Most companies discover their existing names fall into 2-3 incompatible styles. The guide's job is to pick one and deprecate the others (gracefully).

---

## Step 3 — Define Naming Principles

Every naming guide starts with 3-5 principles — the beliefs that drive every naming decision.

Principles are NOT aspirational values. They are hard choices that rule things in or out.

**Strong principle examples:**
- "We name things for what they feel like, not what they do." → rules out descriptive names
- "Every name works as a spoken word in a 30-second demo." → rules out acronyms and hard-to-pronounce invented words
- "We never use -ify, -ly, or -hub suffixes." → specific, enforceable
- "Product names are 1-2 words maximum." → length constraint
- "We prefer invented or modified words over real words used out-of-context." → style preference with clear rationale

**Weak principle examples (don't use these):**
- "Names should be memorable" → every guide says this, it rules nothing out
- "Names should reflect our values" → too vague to apply
- "Names should be unique" → every guide says this too

Generate principles from:
1. The existing names that work best — what do they have in common?
2. The existing names that work worst — what pattern created the problem?
3. The competitive landscape — what must the guide ensure they don't do?
4. The audience — what naming conventions does the audience trust?

---

## Step 4 — Define the Naming System

The system answers: what types of things get named, and how?

**Naming tiers (common structure):**

| Tier | What it covers | Naming rule |
|------|---------------|-------------|
| Brand | The company itself | Already set — guide must be compatible |
| Products | Distinct product offerings | [specific style] |
| Features | Capabilities within a product | [specific style — often different from products] |
| Releases/versions | Time-based milestones | [e.g., codenames, numbers, seasons] |
| Sub-brands | Separate brand identities | [rules for how far sub-brands can deviate] |
| Partnerships | Co-branded products | [how partner name integrates] |

Not all companies need all tiers. Define only the tiers that apply.

**Common systems:**

*Galaxy system (Apple, Google):* Products get clean standalone names. Features get descriptive names. Sub-brands share visual identity but get distinct names. (iPhone, Siri, FaceTime, Apple Watch)

*Constellation system (Stripe):* Core brand is standalone. Products expand with compound names that start with the brand. (Stripe, Stripe Atlas, Stripe Radar, Stripe Issuing)

*Ecosystem system (Notion):* Everything lives under one umbrella. Features are described, not branded. No sub-brands. Consistency over personality.

*Codename system (OS X / macOS):* Releases get memorable codenames (Mojave, Ventura). Provides narrative without permanent naming commitment.

Full naming system patterns: `references/guide-structure.md`

---

## Step 5 — Write the Dos and Don'ts

This is the most-used section of any naming guide. Make it specific.

**Format:** Every don't needs a reason and a better alternative.

```
DON'T: Use -ify, -ly, -hub, -io as standalone suffixes
WHY: These patterns peaked in 2014 and now signal legacy tech
INSTEAD: Prefer clean invented words or modified real words

DON'T: Use names longer than 12 characters for products
WHY: Truncates in app icons, email subjects, and social handles
INSTEAD: 4-8 characters ideal; name the concept, not the feature list

DON'T: Name features descriptively when they deserve a brand moment
WHY: "Advanced Analytics Dashboard" is not a product — it's a spec sheet
INSTEAD: Name features that users will talk about ("Pulse", "Insights", "Radar")

DO: Test every name out loud in a sentence before approving
WHY: "Have you tried [name]?" — if it sounds like a feature description, it's not a brand name
```

---

## Step 6 — Build the Approval Checklist

A 5-point checklist that any team member can run on a proposed name in 5 minutes.

```
NAMING CHECKLIST — [Company]

□ Fits the naming principles (see Section 2)
□ Compatible with existing name system (tier + style)
□ Pronounceable on first read by target audience
□ No trademark conflicts in primary markets (quick search)
□ Domain/handle available or acquirable (check .com, .io, primary social)

All 5 checked = proceed to review
Any unchecked = revise before review
```

---

## Output Format

The output IS the naming guide. Produce it as a complete, usable document:

```
# [Company] Naming Guide
Version [X] — [Date]

---

## 1. What This Guide Is For

[1 paragraph: what naming problem this solves, what it covers, what it doesn't]

---

## 2. Naming Principles

**Principle 1:** [Statement]
*Why:* [Rationale]

**Principle 2:** [Statement]
*Why:* [Rationale]

[3-5 principles total]

---

## 3. Naming System

### [Tier 1 — e.g., Products]
Style: [invented word / modified real word / etc.]
Length: [X-Y characters]
Examples of names that fit: [list]
Examples that don't fit: [list]

### [Tier 2 — e.g., Features]
[same structure]

---

## 4. Dos and Don'ts

### Do
- [specific, enforceable rule]
- [specific, enforceable rule]

### Don't
- [specific pattern] — [reason] — [alternative]
- [specific pattern] — [reason] — [alternative]

---

## 5. Approval Checklist

□ [check 1]
□ [check 2]
□ [check 3]
□ [check 4]
□ [check 5]

---

## 6. Examples

### Names that fit this guide
[list with brief reason]

### Names that don't fit this guide
[list with brief reason — don't shame existing names, just illustrate]

---

## 7. When to Break the Rules

[1 paragraph: the guide is a tool, not a prison. Name the conditions under which a strong enough name can override the rules — and who has authority to approve the exception.]
```

---

## Anti-Patterns in Naming Guides

- **Too long** — if the guide takes more than 10 minutes to read, nobody will use it
- **Too vague** — principles that don't rule anything out are decorative, not functional
- **No examples** — every rule needs a good example and a bad example
- **No authority** — who approves a name that passes the checklist? Define it.
- **Ignoring existing inventory** — a guide that conflicts with 40% of existing names will be ignored
- **No update mechanism** — guides go stale. Add a version number and a review cadence.

Reference guides: `references/examples/sample-guides.md`