菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Ingest a raw source into the project's OKF knowledge bundle — distill it into concept pages, refresh the index, and log the change. keel's compounding "LLM wiki" loop.
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 executing implementation plans with independent tasks in the current session
Orchestrates the implement-feature, evaluator, fix-runner loop for the active feature until all Criterios de Aceitacao are met and quality gates are green.
Use after the plan is approved to break the active feature's plan into a concrete task checklist, written into specs/<feature>/tasks.md from the tasks template.
Use while implementing a feature that has retries, queues, background jobs, external calls, or any critical path an on-call engineer will need to reason about in production. Invoke when adding a new endpoint, dependency, or async flow, and before considering such a feature done — instrumentation is developed alongside the code, like tests, not bolted on after.
| 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 Decisões Técnicas) 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 Decisões Técnicas. 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.