Centralize reusable FileMaker workspace guidance

skills/filemaker-naming/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: filemaker-naming
+description: Name or review FileMaker fields, variables, parameters, results, scripts, layouts, and related objects without weakening an established legacy convention. Use for new or changed FileMaker names, especially Boolean fields and variables.
+---
+
+# FileMaker Naming
+
+## Priority
+
+1. Preserve the consuming project's confirmed naming standard and existing legacy pattern.
+2. For a project that opts into an organization-specific standard, read that standard before proposing a name.
+3. Use these client-neutral defaults only where neither of the above decides the name.
+
+Do not rename existing objects solely to apply these defaults.
+
+## Boolean names
+
+Name a Boolean as a positive yes/no question:
+
+- `is...` for identity or current state, for example `isActive`
+- `has...` for possession or inclusion, for example `hasVendorAccess`
+- `can...` for permission or capability, for example `canOpen`
+- `should...` for intent or a business-rule decision, for example `shouldRetry`
+
+Avoid vague words such as `flag`, `status`, `check`, or `done`. Avoid negative names such as `isNotActive` or `hasNoAccess`; name the positive state and negate it in the logic where needed. Retain established FileMaker table-occurrence or scope prefixes.
+
+## Review before proposing a new name
+
+1. Search the current DDR and project sources for nearby names and scope prefixes.
+2. Keep an established family of fields or variables consistent.
+3. State the exact proposed name and why it fits the local convention.
+4. If evidence conflicts or the business meaning is unclear, ask a concise question instead of guessing.