Naming
Personal coding profile kit for reusable defaults and setup
npx -y skills add iplaylf2/coding-profile --skill namingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when the user asks to generate, choose, revise, or review a name, label, identifier, or term; design or refine a naming system; or make a substantive naming decision within a broader task. Do not use when naming is merely incidental or the task only applies an exact name already fixed by an explicit requirement or governing contract.
SKILL.md
4.8 KB, as published. Nobody here has run it
Naming
Naming Boundary
This skill produces a complete naming decision: an exact name, a keep/change judgment, or a naming-system rule, together with the semantic contrast and constraints needed to use it. Treat artifact grammar, placement context, and compatibility requirements as inputs when relevant. Applying the chosen name across surrounding artifacts is outside the naming result.
Naming Goal Questions
- What naming result did the user request, and what entity, concept, state, capability, or vocabulary family is being named?
- Who will encounter the name, on what surface, and what must they be able to distinguish or do with it?
- What stable responsibility or meaning must the name communicate, and what unsupported promise must it avoid?
- What exposure, durability, search, speech, or tooling use determines how much context the name must carry itself?
- Which surrounding namespace, heading, path, type, sentence, or sibling group already supplies context that the name need not repeat?
- Which missing details can be inferred from the workspace, domain language, contrast set, or stated goal, and which would materially change the audience, semantic emphasis, compatibility, or result enough to require clarification?
Evidence Questions
- What must the entity denote or distinguish, and which source best establishes that meaning for this audience?
- Which nearby names form the relevant contrast set, level of abstraction, and naming axis?
- Which local vocabulary and grammar are current and audience-appropriate, and what evidence would justify departing from them?
- Which supplied words are exact requirements or authoritative terms, and which are candidates, preferences, rejections, or semantic examples?
- Which explicit user constraints, public or persisted contracts, and tooling rules bind the result?
- When inputs conflict, which are binding requirements, which are evidence, what tradeoff must be exposed, and which choices remain open?
Candidate Questions
- Which distinct semantic frames are plausible, and what candidate best represents each without producing superficial variants?
- Which candidate foregrounds the semantic distinction the audience needs first?
- Is its scope faithful to the entity, or is it too broad, narrow, abstract, implementation-bound, or aspirational?
- Does it remain at the same level of abstraction and on the same naming axis as its siblings?
- Does each word add meaning, contrast, standalone clarity, search value, or format compliance that surrounding context cannot provide?
- Does it use locally natural vocabulary and the form required by its human- or machine-facing surface?
- Would an abbreviation, acronym, coined term, modifier, or longer standalone form be understood by this audience and local system?
- Does a complex or heavily qualified candidate name a stable concept, or compensate for an overloaded term, transient implementation, or unclear domain model?
- Will likely siblings, states, or extensions fit without collisions, awkward exceptions, or a change in naming axis?
- Which candidate remains valid and semantically intact after syntax, casing, uniqueness, reserved-word, or length constraints are applied?
Naming Decision Questions
- Which candidate best balances intended meaning, useful contrast, audience comprehension, local convention, discoverability, and compatibility?
- For a review, what evidence supports keeping or changing the current name, and would a replacement materially improve meaning, audience fit, local coherence, discoverability, or future use?
- For a rename, does the naming benefit justify the reference, persistence, compatibility, alias, documentation, and migration work it entails?
- For a naming system, what semantic axis does each name part own, when may it be omitted, and how will composition, collisions, and future additions work?
- Which exact format, collision, reference, contract, or representative-case checks can validate the decision?
Result
Lead with the exact recommended name, keep/change judgment, or naming-system rule.
- What decisive semantic contrast, audience need, convention, or constraint explains the result?
- Is there a genuinely distinct alternative worth reporting, and if so, what different semantic tradeoff does it represent?
- When the result involves a rename or naming-system change, what migration or compatibility work follows?
- What was actually validated, and which unavailable evidence still affects confidence?