Update to fstack

{
  "description": "Apply when naming variables, functions, types, files, or endpoints. Enforces the 6-month amnesia test, language conventions, intent-based naming, and cross-boundary consistency.",
  "included_files": [],
  "name": "principle-clear-naming",
  "skill_md_contents": "---\nname: principle-clear-naming\ndescription: Apply when naming variables, functions, types, files, or endpoints. Enforces the 6-month amnesia test, language conventions, intent-based naming, and cross-boundary consistency.\nuser-invocable: false\ndisable-model-invocation: true\n---\n\n# Clear Naming Discipline\n\n> \"There are only two hard things in Computer Science: cache invalidation and naming things.\" — Phil Karlton\n\nCode is read far more often than it is written. A bad name forces every future reader to inspect the underlying implementation just to understand what a function or variable holds. A good name makes the surrounding code self-evident.\n\n---\n\n## 1. The 6-Month Amnesia Test\n\nWhenever you name a variable, function, class, file, or endpoint, ask:\n\n> **\"If I wake up with amnesia in 6 months and read this line, will I immediately know what it is and what it does? Will a new teammate guess its exact purpose on their first day?\"**\n\nIf the answer is *\"Only if they read the function body\"*, the name has failed. Rename it.\n\n---\n\n## 2. Intent Over Mechanism\n\nName by **what problem it solves and what data it represents**, not the mechanical data structure or plumbing:\n\n| Mechanical / Bad | Intent-Driven / Good | Rationale |\n|---|---|---|\n| `dataArray` | `activeSubscriptions` | Names the domain entity, not the memory structure. |\n| `dictMap` | `cachedUserPermissions` | Reveals what the lookup is for. |\n| `processStuff()` | `syncStripeInvoices()` | States the exact business operation. |\n| `tempFlag` | `hasVerifiedEmail` | Self-documenting state. |\n\n---\n\n## 3. Language & Ecosystem Conventions\n\nAlways adhere to the idiom of the host language unless an explicit codebase convention overrides it:\n\n- **TypeScript / JavaScript**:\n  - `camelCase` for variables, properties, and functions (`getUserSession`, `isOrgAdmin`).\n  - `PascalCase` for classes, types, interfaces, and React components (`PaymentProcessor`, `UserProfileCard`).\n  - `UPPER_SNAKE_CASE` for immutable module-level constants (`MAX_RETRY_ATTEMPTS`).\n- **Python**:\n  - `snake_case` for functions, methods, and variables (`calculate_tax`, `user_id`).\n  - `PascalCase` for classes (`DatabaseConnection`).\n- **Go / Rust**: Follow standard idiomatic casing (`userID`, `fetch_record`).\n\n---\n\n## 4. Consistency Across Boundaries\n\nPick one verb per action in a subsystem and stick to it religiously. Do not mix semantic synonyms across files:\n- If you use `get...` for database lookups, do not switch randomly to `fetch...`, `retrieve...`, or `query...`.\n- If you use `delete...`, do not switch between `remove...`, `drop...`, and `destroy...` for the same entity type.\n\n---\n\n## 5. Booleans as Clear Predicates\n\nBooleans must sound like yes/no questions:\n- **Good**: `isEnabled`, `hasAccess`, `shouldRetry`, `canEdit`, `isPendingApproval`.\n- **Bad**: `status` (ambiguous), `access` (noun), `check` (sounds like a function).\n\n---\n\n## 6. Ban Cryptic Abbreviations\n\nUnless an abbreviation is universally recognized in the domain (`id`, `url`, `req`, `res`, `ctx`, `err`), spell it out:\n- Bad: `usrMgrSvc`, `calcDiscTot()`, `custAddrStr`.\n- Good: `userManager`, `calculateDiscountTotal()`, `customerAddress`.\n"
}