菜单
Naming-convention lens consulted BEFORE writing code — camelCase in code, snake_case at the DB boundary, and one consistent name per concept across layers. Appended to impl-conventions.txt by the stack-conventions pack. Also usable standalone.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/CaioWF/keel --skill naming-conventions命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Use when designing the structure of a feature or module (in the plan phase, or when refactoring) to apply language-agnostic engineering principles — Clean Architecture, SOLID, testing strategy, and tactical DDD. Container of guides; each concept is a companion.
Use when implementation is complete, gates pass, and you need to decide how to integrate the work — presents structured options (merge, PR, keep, discard) and handles the chosen workflow, including worktree cleanup. Closes the SDD cycle after review-and-simplify.
Use when PAUSING/ending a session (writes the current state to docs/STATE.md to resume later) or when RESUMING (reads docs/STATE.md and the active spec, recomposes context, and proposes the next step). Maintains continuity across human and agent sessions.
基于 SOC 职业分类
正在显示 SKILL.md
| name | naming-conventions |
| description | Naming-convention lens consulted BEFORE writing code — camelCase in code, snake_case at the DB boundary, and one consistent name per concept across layers. Appended to impl-conventions.txt by the stack-conventions pack. Also usable standalone. |
When: consulted by plan-writer (to record naming decisions in Technical Decisions) and by implement-feature (to apply them while coding), in projects where the stack-conventions pack is installed. Not a review lens — this shapes code as it is written, not after.
Scope: names the code introduces — identifiers, DB columns/tables, API fields, files. Advisory knowledge, makes no edits.
camelCase for variables/functions/properties, PascalCase for types/classes/components, SCREAMING_SNAKE for module-level constants. One name per concept — do not rename a thing as it crosses functions (userId stays userId, not uid then user_id then id).snake_case for tables and columns (created_at, user_id). Tables plural (users), columns singular. The mapping camelCase (code) ↔ snake_case (DB) is EXPLICIT — declared once in the ORM/mapper (Prisma @map/@@map, or the query layer), never scattered per-query. A plan that adds a table must state this mapping.camelCase JSON is the common default for TS stacks; do not mix camelCase and snake_case in the same payload. The wire shape is a contract, independent of the DB casing.is/has/can (isActive, hasAccess). Avoid negated names (isNotDisabled).kebab-case.ts vs PascalCase.tsx) — consistency with siblings beats any absolute rule.plan-writer: when the plan adds a table, column, or API field, record the code↔DB↔wire names and the mapping site in Technical Decisions. Ambiguity here becomes a clarify question, not a coin-flip at implement time.implement-feature: before naming a new identifier, match how the surrounding code already names the same concept. New name only when no sibling exists.Whitelist over blacklist for any allowed-value naming (source/role/type checks): name the allowed set, not the banned one — see the constitution's authorization rule.