claude.md: defer release notes style to global config

The full WooCommerce-style format spec now lives in
~/.claude/CLAUDE.md so it applies to every plugin and theme,
not just Jetonomy. Plugin-level CLAUDE.md keeps a short pointer
plus the reference-implementation note.

Author: vapvarun

CLAUDE.md

@@ -52,40 +52,9 @@ Two further rules apply to every release:
 - **readme.txt is customer-facing**, not developer notes. Lead with what's new and what's fixed, in plain English. Internal commits/refactors stay in git history and PR descriptions.
 - **Release zip is verified by the build, not by hand.** `bin/build-release.sh` runs `grunt build` (Step 0), asserts every CSS/JS source has a `.min` pair (Step 5b), and rejects any top-level dev cruft (Step 5c). Manual extract-and-eyeball is the wrong model.
 
-## Release Notes Style (readme.txt + GitHub releases)
+## Release Notes Style
 
-Every changelog entry and GitHub release body must follow the WooCommerce-style action-prefix format. The same rules apply to both surfaces (readme.txt changelog AND GitHub release body):
-
-### Format
-
-```
-= 1.4.2 - May 2026 =
-
-One-line summary of the release in plain English. No marketing fluff.
-
-* New      - Description of the new feature.
-* New      - Description of another new feature.
-* Improve  - Description of the improvement.
-* Fix      - Description of the fix.
-* Security - Description of the security fix.
-* Dev      - Developer-facing change (REST endpoint, hook, helper, CI).
-* Compat   - Compatibility / lockstep note.
-```
-
-### Rules
-
-1. **One bullet per change with an action prefix.** Action labels: `New`, `Improve`, `Fix`, `Security`, `Dev`, `Compat`. Pad to 8 characters before ` - ` so columns line up. No feature-themed subheadings (`**Public or private community**`, `**For people who run a space**`) - the action label IS the section.
-2. **No emoji anywhere.** Not in summary, not in bullets, not in headings. Trophies, ballot boxes, party poppers all out. Section labels do the work.
-3. **No em-dashes (`-`) anywhere.** Use a regular hyphen `-`. Em-dash reads as AI-generated and has been flagged multiple times by the team. Sweep before tagging.
-4. **Short summary paragraph (optional).** One line of plain English under the version heading explains what the release is about. Skip it if the bullets speak for themselves (small fix releases).
-5. **Release title is `Plugin X.Y.Z - one-line summary`.** No em-dash. Examples: `Jetonomy 1.4.2 - Show & Tell, Ideas roadmap, multisite, scale` / `Jetonomy Pro 1.4.2 - Webhooks back online, multisite Pro install`.
-6. **Lockstep cross-link.** Free release body links to Pro release tag; Pro release body links to free release tag. Both halves of a customer's install are findable from either page.
-7. **Order within a version.** Group by action label in this order: New, Improve, Fix, Security, Dev, Compat. Keeps the most customer-relevant bullets at the top.
-8. **One sentence per bullet.** If a change needs two sentences, the first is the headline, the second is the detail. No marketing copy, no internal references (ticket IDs, branch names, commit SHAs in the bullet text).
-
-### Why this style
-
-WooCommerce, EDD, GravityForms, ACF, and most major WP plugins use this format. It is the closest thing to a standard for WordPress.org readme.txt. Scannable, easy to translate, easy to share, easy to diff between versions. The rule lives here so we do not repeat the same cleanup on the next release.
+See **`~/.claude/CLAUDE.md` -> "Release Notes Style (ALL plugins & themes)"** for the canonical format spec. Same WooCommerce-style action-prefix rules apply to this plugin's `readme.txt` and GitHub release body. This plugin is the reference implementation — open `readme.txt` for the exact pattern.
 
 ## Quick Reference
 - **Type**: WordPress Plugin (forum, Q&A, ideas, social feed)