@codeam/shared 2.61.75 → 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.d.mts +1 -1
- package/dist/index.d.ts +1 -1
- package/dist/index.js +100 -1
- package/dist/index.js.map +1 -1
- package/dist/index.mjs +100 -1
- package/dist/index.mjs.map +1 -1
- package/package.json +1 -1
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);
|