internal(cursor): Update rules for documentation

Author: ntucker

.cursor/rules/packages-documentation.mdc

@@ -1,12 +1,10 @@
 ---
-description: Documentation requirements when making breaking changes or adding features to public library interfaces in packages
-globs: 'packages/**/*.ts', 'packages/**/*.tsx', 'packages/**/*.js', 'packages/**/*.jsx'
+description: Guidelines for writing and formatting documentation for public library interfaces in packages
 alwaysApply: false
 ---
+# Package Documentation Writing Guidelines
 
-# Package Documentation Requirements
-
-When making changes to public library interfaces in `/packages`, you **must** update the corresponding documentation in `/docs`.
+This guide covers how to write and format documentation for public library interfaces. For information on **when** documentation updates are required, see `.cursorrules`.
 
 ## Documentation Structure
 
@@ -21,37 +19,6 @@ Each package documentation has subdirectories:
 - `concepts/` - Conceptual documentation
 - `getting-started/` - Getting started guides
 
-## When to Update Documentation
-
-### Breaking Changes
-
-**Breaking changes** include:
-- Removing public APIs (classes, functions, methods, hooks, composables)
-- Changing function/method signatures (parameter types, return types, required vs optional)
-- Changing class/interface properties (removing, renaming, changing types)
-- Changing default behavior that affects existing code
-- Deprecating APIs (should be documented with migration path)
-
-**Required actions:**
-1. Update the relevant API documentation file in `docs/{package}/api/`
-2. Add migration notes or deprecation warnings
-3. Update any guides or examples that use the changed API
-4. Update TypeScript types/examples in documentation
-
-### New Features
-
-**New features** include:
-- Adding new public APIs (classes, functions, methods, hooks, composables)
-- Adding new options/parameters to existing APIs
-- Adding new configuration options
-- New capabilities or behaviors
-
-**Required actions:**
-1. Create or update the relevant API documentation file in `docs/{package}/api/`
-2. Add usage examples
-3. Update relevant guides if the feature affects common workflows
-4. Add to getting-started guides if it's a major feature
-
 ## Documentation File Naming
 
 API documentation files should match the exported name:

.cursorrules

@@ -37,6 +37,21 @@ Yarn monorepo for normalized reactive state management.
 7. **Prefer smaller React components** that do one thing
 8. **Use fixtures/interceptors for testing** instead of mocking
 
+## Documentation Updates
+
+**Update docs when changing public APIs** (anything exported from package entry points like `index.ts`).
+
+**Always update docs for:**
+- Breaking changes (removing/changing signatures, properties, or behavior; deprecations)
+- New public APIs (classes, functions, methods, hooks, composables)
+- New options/parameters on existing APIs
+
+**No docs needed for:**
+- Internal/private APIs (prefixed with `_`, not exported, or marked `@internal`)
+- Implementation-only changes
+
+Update docs **in the same commit/PR** as code changes. For writing guidelines, see `.cursor/rules/packages-documentation.mdc`.
+
 ## Common Mistakes to Avoid
 
 - Don't forget `fromJS()` or default property assignments for Entity fields