naming-is-hard

Applies naming and wording doctrine to code symbols, branches, commits, PRs, and UI copy.

4|Updated Jun 9, 2026
One-click install
npx skills add https://github.com/laicluse/agent-fieldkit --skill naming-is-hard-laicluse
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: naming-is-hard
Source: https://github.com/laicluse/agent-fieldkit/tree/main/.agents/plugins/generated/house-rules/skills/naming-is-hard
Command: npx skills add https://github.com/laicluse/agent-fieldkit --skill naming-is-hard-laicluse

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Naming decisions drift when agents follow generic training-corpus defaults, producing inconsistent vocabulary across code, docs, branches, commits, and UI copy. This Skill provides a canonical naming and wording doctrine so one concept keeps one name across every artifact. ## Core Features & Use Cases - Naming Precedence Workflow: Searches existing project vocabulary (AGENTS.md, CLAUDE.md, rg, git log) before inventing new terms, applying a clear precedence from user wording down to corpus defaults. - Cross-Artifact Doctrine: Covers code identifiers, branch and worktree names, commit subjects, PR titles and bodies, changelog entries, backlog and epic titles, and UI copy. - Mixed Dutch/English Rules: Keeps code names in English, preserves established technical terms in Dutch prose, and avoids literal translation of metaphor verbs. - Use Case: Before renaming a class, writing a commit subject, or titling a PR, consult the doctrine to pick a searchable, domain-accurate name free of agent or tooling signatures. ## Quick Start Ask the agent to review or propose a name for a class, branch, commit subject, or PR title using the naming doctrine before finalizing it.

Frequently Asked Questions about naming-is-hard

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I choose a good name for a code symbol or class?▼

Search the repository first with rg and git log to find the established term for the concept, then prefer domain nouns over generic role words like Manager or Helper. Name the thing by what it means in the system, not by which file or refactor produced it.

How should I write commit subjects and PR titles?▼

Write commit subjects in imperative English, around 50 characters and never over 72, describing the resulting capability rather than the file operation. PR titles and bodies should lead with context and intent, without agent templates, footers, or rendered diffs.

Should code names be in Dutch or English?▼

Code and code-adjacent names are always English, including variables, classes, files, branches, and commit subjects. Dutch prose may code-switch but keeps established technical terms like framework, library, and protocol names in English.

What naming conventions apply to branches and worktrees?▼

Use lower-case hyphenated phrases that a future maintainer would search for, describing the domain or feature. Branch names must not contain agent, vendor, or tool names, and should stay readable if slashes flatten to dashes in worktree directories.

When should I read the detailed naming doctrine reference?▼

Read references/naming-doctrine.md for nontrivial naming choices, renames, cross-language wording decisions, branch or project names, commit and PR text, user-facing messages, or any category not covered by the quick rules in SKILL.md.