Add Claude project skill

Author: mtoensing

.claude/skills/simpletoc-wordpress-standards/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: simpletoc-wordpress-standards
+description: Use when working on the SimpleTOC WordPress plugin, especially for Gutenberg block changes, PHP render logic, settings-page work, styling changes, or editor sidebar options. Apply when implementation quality must stay close to WordPress core patterns: prefer standards, official APIs, block metadata, Settings API, sanitized output, and maintainable SCSS over hacks, CSS tricks, or ad-hoc workarounds.
+---
+
+# SimpleTOC WordPress Standards
+
+Follow these rules for all changes in this plugin.
+
+## Core Rules
+
+- Stay close to WordPress core and Gutenberg standards.
+- Prefer existing Gutenberg elements, WordPress functions, official APIs, block metadata, block-editor components, and the WordPress Settings API.
+- Write as little custom code as possible. Less is more.
+- Avoid hacks, CSS tricks, hidden coupling, and one-off workarounds.
+- Avoid inline styles unless a user-selected value must be output dynamically and there is no cleaner standard path.
+- Keep layout and reusable presentation rules in SCSS/CSS, not in PHP strings.
+- Sanitize all dynamic PHP output with the appropriate WordPress escaping helpers.
+
+## Documentation Workflow
+
+- Update `readme.txt` only when changing plugin documentation.
+- Do not edit `README.md` by hand. It is generated automatically from `readme.txt` by the GitHub Actions workflow.
+- Keep `readme.txt` valid for WordPress.org first; the generated Markdown README is secondary.
+
+## Block Workflow
+
+- Treat `src/block.json` as the source of truth for block attributes and asset registration.
+- Treat `src/edit.js` as editor configuration only.
+- Remember that SimpleTOC is a dynamic block: frontend markup is rendered in `plugin.php`, not `save.js`.
+- When adding a new editor option, wire it through block attributes first, then implement the frontend effect in the PHP render path or registered frontend styles.
+- Rebuild generated files after source changes so `build/` stays in sync.
+
+## Styling Workflow
+
+- Prefer wrapper classes and registered block stylesheets over hard-coded CSS in PHP.
+- Reuse Gutenberg conventions such as palette-driven colors, `has-background`, and block wrapper attributes when they fit.
+- For optional styling features, expose explicit settings instead of baking in fixed presets unless the requirement is truly global.
+- For global styling behavior, add the option to the SimpleTOC settings page and store it via the existing options flow.
+
+## Settings Workflow
+
+- Add global options in `simpletoc-admin-settings.php`.
+- Register options with `register_setting()`, render them with `add_settings_field()`, and keep labels/help text concise.
+- Respect existing filter overrides when the settings page already follows that pattern.
+- If a global option forces behavior, keep block-level UI simple and make the server-side precedence explicit.
+
+## Project Preferences
+
+- Prefer maintainable, standard-compliant solutions over fast shortcuts.
+- If a request appears to require a workaround, stop and look for the clean WordPress-native approach first.
+- If a compromise is unavoidable, state the tradeoff explicitly before implementing it.

.distignore

@@ -1,6 +1,7 @@
 /.wordpress-org
 /.git
 /.github
+/.claude
 /node_modules
 /src
 package.json