@codeam/shared 2.61.74 → 2.61.76

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/dist/index.mjs CHANGED
@@ -2043,11 +2043,110 @@ var specDrivenDevelopmentSkill = {
2043
2043
  }
2044
2044
  };
2045
2045
 
2046
+ // src/skills/code-naming.ts
2047
+ var CODE_NAMING_BODY = `Use this skill when NAMING or RENAMING code \u2014 variables, functions, classes,
2048
+ interfaces, types, files, modules, components, hooks, constants \u2014 while writing
2049
+ new code, refactoring, or reviewing a diff. A name should reveal intent and
2050
+ domain meaning so a reader understands the code without translating it in their
2051
+ head, and so it needs fewer comments.
2052
+
2053
+ ## The five core rules (name the concept, not the implementation)
2054
+
2055
+ 1. **Don't abbreviate, and don't use single letters for meaningful values.**
2056
+ \`usr\`/\`cfg\`/\`authReq\` \u2192 \`user\`/\`config\`/\`authRequest\`; \`u\`/\`p\` \u2192 \`user\`/\`project\`.
2057
+ Abbreviations rely on context the next reader may not have. Allowed: standard
2058
+ acronyms the domain already uses (API, URL, HTTP, ID, UUID, CLI, SDK, PR, OAuth),
2059
+ loop indices \`i\`/\`j\`, coordinates \`x\`/\`y\`, and generic type params \`T\`/\`K\`/\`V\`.
2060
+
2061
+ 2. **Don't put the data TYPE in a variable name.** \`userList\` \u2192 \`users\`,
2062
+ \`nameString\` \u2192 \`displayName\`, \`isActiveBool\` \u2192 \`isActive\`, \`invoiceMap\` \u2192
2063
+ \`invoicesById\`. The type system and editor already show the type; the name
2064
+ should carry the meaning.
2065
+
2066
+ 3. **Include the UNIT when a number has one** (unless the type makes it
2067
+ unmistakable). \`timeout\` \u2192 \`timeoutMs\`, \`delay\` \u2192 \`retryDelaySeconds\`,
2068
+ \`size\` \u2192 \`fileSizeBytes\`, \`price\` \u2192 \`priceUsd\`. Especially time, distance,
2069
+ money, bytes, rates, percentages, token/rate limits.
2070
+
2071
+ 4. **Don't put the type CONSTRUCT in a type's name.** \`UserClass\` \u2192 \`User\`,
2072
+ \`PaymentInterface\`/\`IPayment\` \u2192 \`Payment\` (or a role like \`PaymentGateway\`),
2073
+ \`ConfigType\` \u2192 \`Config\`, \`StatusEnum\` \u2192 \`Status\`. Name the concept, not
2074
+ "what kind of programming thing it is."
2075
+
2076
+ 5. **Refactor when you're reaching for \`Utils\`/\`Helpers\`/\`Common\`.** A generic
2077
+ bucket usually hides a missing concept. Group by domain instead:
2078
+ \`utils/parseCookie\` \u2192 a \`cookies/\` module or a \`CookieStore\`/\`CookieJar\` class;
2079
+ \`utils/formatDate\` \u2192 \`dates/\` or a \`DateRangeFormatter\`. Same for vague
2080
+ \`Base\`/\`Abstract\`/\`Manager\`/\`Helper\` class names \u2014 prefer the role
2081
+ (\`Repository\`, \`BillingService\`, \`UserProvisioner\`) unless the project
2082
+ convention explicitly requires \`Base\`/\`Abstract\`.
2083
+
2084
+ ## Shape rules
2085
+
2086
+ - **Functions are verbs / verb phrases:** \`createInvoice()\`, \`sendPasswordResetEmail()\`,
2087
+ \`findRepositoryById()\`. Booleans read like a question in an \`if\`:
2088
+ \`isActive\`, \`hasAccess\`, \`canDeploy\`, \`shouldRetry\` (prefix \`is/has/can/should/needs\`).
2089
+ - **Classes / interfaces / types are nouns or roles:** \`Invoice\`, \`PaymentGateway\`,
2090
+ \`AgentSession\` \u2014 not \`InvoiceData\`, \`SubscriptionThing\`, \`AgentSessionType\`.
2091
+ - **Collections are plural, or \`\u2026ById\`/\`\u2026ByX\` when indexed:** \`users\`,
2092
+ \`activeSessions\`, \`invoicesByCustomerId\`.
2093
+ - **Don't encode a temporary implementation in a name that may change:**
2094
+ \`postgresUserRepository\` \u2192 \`userRepository\`, \`redisCache\` \u2192 \`cache\` \u2014 unless the
2095
+ implementation IS the meaningful distinction. Name the role, not today's backend.
2096
+ - **Follow the project's existing conventions** (casing, file naming, \`useX\`
2097
+ hooks, \`handleX\` handlers). Match the surrounding code; don't introduce a new
2098
+ style without a strong reason.
2099
+
2100
+ ## Words to distrust (infer the real role, then name it)
2101
+
2102
+ \`data\`, \`info\`, \`item\`, \`obj\`, \`temp\`, \`result\`, \`value\`, \`thing\`, \`stuff\`,
2103
+ \`manager\`, \`helper\`, \`utils\`, \`common\`, \`base\`, \`abstract\`, \`processor\`,
2104
+ \`handler\`, \`payload\`. They're acceptable only when the surrounding context makes
2105
+ them precise (e.g. \`config\` inside one \`DatabaseConnection\`); vague when passed
2106
+ across many layers.
2107
+
2108
+ ## Guardrails \u2014 this is a review/refactor guide, NOT a mass-rename mandate
2109
+
2110
+ - Names that are already clear and idiomatic are DONE \u2014 leave them.
2111
+ - Before renaming: read how the identifier is used and infer the real domain
2112
+ concept. Prefer the **smallest** clear rename.
2113
+ - Do NOT do large unrelated renames, and do NOT rename purely for personal
2114
+ preference. Stay inside the change you were asked to make.
2115
+ - Preserve public API / exported names unless the task explicitly allows a break;
2116
+ when you do rename, update every reference, tests, and docs in the same change.
2117
+ - No clever names, jokes, or metaphors in production code; don't make names
2118
+ needlessly long either.
2119
+
2120
+ When reviewing, raise a naming issue only when a clearer name would materially
2121
+ help a reader \u2014 one suggestion per finding: \`current \u2192 suggested \u2014 why\`.`;
2122
+ var CODE_NAMING_INSTRUCTION = `When naming or renaming code, name the domain concept, not the implementation:
2123
+ no abbreviations or single-letter names for meaningful values (standard acronyms
2124
+ like API/URL/ID/OAuth are fine); don't put the data type in a variable name
2125
+ (userList \u2192 users); include the unit when a number has one (timeout \u2192 timeoutMs);
2126
+ don't put the type construct in a type's name (IPayment \u2192 Payment); and refactor
2127
+ generic Utils/Helper/Manager/Base buckets into a domain module or a role-named
2128
+ class. Functions are verbs (createInvoice), booleans read like questions
2129
+ (isActive/hasAccess), classes/types are nouns/roles, collections are plural or
2130
+ \u2026ById. This is a review/refactor guide, not a mandate to mass-rename: leave
2131
+ already-clear names alone, prefer the smallest clear rename, don't rename
2132
+ unrelated code, and preserve public/exported names unless the task allows a break.`;
2133
+ var codeNamingSkill = {
2134
+ id: "code-naming",
2135
+ name: "Code Naming",
2136
+ description: `Naming review & refactor: name the domain concept, not the implementation \u2014 no abbreviations, no type-in-name, units when they matter, no Utils/Manager/Base buckets; rename minimally, never mass-rename.`,
2137
+ source: "curated",
2138
+ delivery: {
2139
+ skillFile: { body: CODE_NAMING_BODY },
2140
+ instruction: { body: CODE_NAMING_INSTRUCTION }
2141
+ }
2142
+ };
2143
+
2046
2144
  // src/skills/registry.ts
2047
2145
  var SKILL_REGISTRY = {
2048
2146
  "code-review": codeReviewSkill,
2049
2147
  "resolve-conflicts": resolveConflictsSkill,
2050
- "spec-driven-development": specDrivenDevelopmentSkill
2148
+ "spec-driven-development": specDrivenDevelopmentSkill,
2149
+ "code-naming": codeNamingSkill
2051
2150
  };
2052
2151
  function isSkillId(id) {
2053
2152
  return Object.prototype.hasOwnProperty.call(SKILL_REGISTRY, id);