{"owner":"statamic","repo":"cms","hasSkills":true,"totalSkillsCount":3,"totalTokensCount":3548,"categories":["claude-rule","anthropic-skill","cursor-rule"],"hasMcp":false,"mcpConfig":null,"found":["CLAUDE.md",".claude/skills/changelog/SKILL.md",".cursorrules (typo3cms-extension-cursorrules-prompt-file.mdc)"],"skills":{"CLAUDE.md":"# Statamic CMS - Claude AI Context\n\n## Project Overview\n\nThis is the **Statamic CMS Core Package** - a Laravel-powered, flat-file (by default) CMS designed for building modern, easy-to-manage websites. This repository contains the core Composer package that gets installed into Laravel applications.\n\n## Project Structure\n\n```\n├── src/                  # Core PHP source code (PSR-4: Statamic\\)\n│   ├── CP/               # Control Panel specific functionality  \n│   └── ...               # Many other core modules\n├── resources/\n│   ├── js/               # Vue.js Control Panel frontend\n│   │   ├── bootstrap/\n│   │   │   ├── cms/      # Bootstraps the code necessary for the npm package\n│   │   │   └── ...\n│   │   ├── package/      # The @statamic/cms local npm package to be used by addons\n│   │   ├── tests/        # JS test suite (Vitest)\n│   │   └── ...\n│   ├── css/              # Stylesheets\n│   ├── views/            # Blade templates\n│   └── lang/             # Translations\n├── tests/                # PHPUnit test suite\n├── config/               # Configuration files\n└── routes/               # Route definitions\n```\n\n## Technology Stack\n\n- **Backend**: Laravel 12+ / PHP 8+\n- **Control Panel Frontend**: Vue 3 + TypeScript + Vite\n- **Control Panel CSS**: Tailwind CSS 4\n- **Database**: File-based \"Stache\" out of the box, but eloquent supported through the statamic/eloquent-driver composer package\n\n## Development Commands\n\n### PHP/Backend\n\n```bash\n# Run PHPUnit tests\n./vendor/bin/phpunit\n# OR use the batch file on Windows\nphpunit.bat\n\n# Code style/linting (Laravel Pint)\n./vendor/bin/pint\n\n# Run specific test\n./vendor/bin/phpunit tests/path/to/TestFile.php\n```\n\n## Common Development Tasks\n\n- **Adding new fieldtypes**: Extend `src/Fieldtypes/`\n- **Control Panel features**: Work in `src/CP/` + `resources/js/`\n- **API endpoints**: Check `src/API/` + `routes/api.php`\n- **Entry/content handling**: See `src/Entries/`\n- **Asset management**: See `src/Assets/`\n- **Authentication**: See `src/Auth/`\n\n## Testing\n\n- Full PHPUnit test suite in `tests/`\n- Frontend tests with Vitest\n- Run tests before submitting PRs\n\n## Important Notes\n\n- This is the **core package only** - it requires a Laravel app to run\n- The starter Laravel app is at [statamic/statamic](https://github.com/statamic/statamic)  \n- Documentation site code is at [statamic.dev](https://statamic.dev)\n- Do not commit compiled assets (`resources/dist/*`) - they're auto-generated\n- Follow the contribution guidelines in [CONTRIBUTING.md](CONTRIBUTING.md)\n\n## Build Process\n\nThe project uses Vite for asset compilation with separate configs:\n\n- `vite.config.js` - Main Control Panel assets. e.g. The Vue application.\n- `vite-frontend.config.js` - Frontend-specific assets. e.g. Things like conditional field logic to be used on front-end forms. \n- Control Panel assets are built to `resources/dist/` and `resources/dist-dev/`. The dev version enables Vue devtools.\n\n## NPM Package Notes\n\n- Our Vite bundle contains the Vue app, UI components, all the JS to make the Control Panel work.\n- We provide a `@statamic/cms` node module for addons to use that provides core helpers, ui components, etc.\n- Our Vite bundle assembles everything the node module needs in `resouces/js/bootstrap/cms` and makes it available in the `window.__STATAMIC__` object.\n- The node module is defined in `packages/cms` and resolves everything through the `window` object.\n- Code needs to be in the `window` object to prevent addon bundles from re-including our code, and from needing to recompile our source files.\n\n## UI Components & Storybook\n\n- UI components live in `resources/js/components/ui/` and are available to addons via `@statamic/cms/ui`. They are documented with Storybook at [ui.statamic.dev](https://ui.statamic.dev).\n- Stories live in `resources/js/stories/*.stories.ts`, their docs pages in `resources/js/stories/docs/*.mdx`.\n- `npm run storybook` starts Storybook along with its MCP server at `http://localhost:6006/mcp` (configured in `.mcp.json`).\n  - Use its documentation tools to look up a component's props, stories and usage before using or changing a UI component.\n  - After changing components or stories, run the story tests through the MCP server or with `npx vitest run --project storybook`.\n- Storybook generates component manifests for AI agents from stories, MDX docs and component source. Inspect them at `http://localhost:6006/manifests/components.html`.\n  - Document props with JSDoc comments. They end up in the manifest.\n  - Stories import components from `@statamic/cms/ui`, not `@ui`. Snippets copy the story's imports, and `@ui` doesn't exist for addons. `tsconfig.json` maps `@statamic/cms/ui` to `resources/js/components/ui` so this resolves in Storybook.\n  - Snippets are extracted statically from each story's `render`. Write `template` as a literal without `${}` interpolation, use `setup()` instead of `data`/`methods`, keep everything `setup` references inside it (or imported), and read args as `args.foo` or `v-bind=\"args\"`. A story that breaks these rules has no snippet in the manifest. Only add `parameters.docs.source.code` when the docs should show something different from the template.\n\n## For PR Reviews\n\n- All user-facing strings should be localized.\n  - Short strings (like \"Submit\" or \"Click here\") can use the translation strings as keys. \n  - Longer phrases or sentences should use keys and have their translations stored in an appropriate translation file.\n  - When adding to a translation file, only English strings need to be added. Other languages will be provided by contributors.\n  - Exception messages can stay untranslated in English\n\n## Misc\n\n- Commit messages within a PR do *not* need the PR number prefix. Those are just for the PR merge commit itself.\n\n\n## Links\n\n- [Main Documentation](https://statamic.dev/)\n- [Application Repo](https://github.com/statamic/statamic) \n- [Discussions](https://github.com/statamic/cms/discussions)\n- [Discord](https://statamic.com/discord)\n",".claude/skills/changelog/SKILL.md":"---\nname: changelog\ndescription: Generate a changelog for a release\n---\n\nGenerate a changelog entry for the CHANGELOG.md file by following these steps:\n\n## 1. Get commits since last tag\n\nFirst, fetch tags from origin — they sit off-branch (see note below) so they don't come down with a normal `git pull`/`git fetch` on the branch:\n\n```\ngit fetch origin --tags\n```\n\nThen run the following to get the list of commits:\n\n```\ngit --no-pager log $(git merge-base $(git tag --list 'v*' --sort=-v:refname | head -n1) HEAD)..HEAD --oneline --no-decorate --no-merges\n```\n\nNote: The release workflow tags a separate \"Build assets\" commit that is *not* an ancestor of the branch, so the tag itself never lands on `6.x`. That means `git describe --tags` walks back to a stale tag. Instead, take the newest tag and use its `git merge-base` with `HEAD`, which resolves to the release commit that *is* on the branch.\n\n5.x commits are merged into 6.x as-is (not squashed), so this plain `--no-merges` log already walks both the 6.x mainline and every commit brought in via a 5.x merge, in true chronological order — it only excludes the merge commits themselves (multi-parent, no real change of their own).\n\n## 2. Process each commit\n\nFor each commit:\n- Extract the PR number from the commit message (e.g., `(#13331)`)\n- Remove the commit SHA and `[6.x]`/`[5.x]` prefix from the message\n- Fetch the PR author from GitHub using a sequential loop — do NOT use parallel background jobs (`&`) as they interleave stdout unpredictably. Use: `for pr in <numbers>; do echo -n \"PR $pr: \"; gh pr view $pr --json author --jq '.author.login'; done`\n\n## 3. Skip certain commits\n\nSkip commits that are:\n- Test fixture updates (e.g., \"Update composer test fixtures\")\n- CI/workflow changes (e.g., \"Only run lint workflow...\")\n- Test-only fixes with no user-facing effect (e.g., \"Fix failing Guzzle tests\" — check the PR body; if it says the bug only affected tests, skip it)\n- Internal release/workflow-only PRs (e.g., \"Update Release Workflow\")\n- Commits with no PR number, or whose message is itself a merge bookkeeping commit (e.g., \"Merge 5.x (#NUM)\", \"Merge branch '5.x' into...\")\n\nDo not skip dependency bumps from dependabot.\n\nFor `[5.x]`-prefixed commits, also skip/dedupe:\n- Changes already superseded by a bigger PR in this release. Read the PR bodies — if a larger 6.x PR's description explicitly covers what the smaller 5.x fix addressed (e.g., a big OAuth rework that says it removes email-based matching supersedes a smaller \"Fix OAuth\" email-trust patch), skip the smaller one and note it in the summary (step 10).\n- Changes that no longer apply to 6.x because 6.x already handled it independently (e.g., a 5.x \"Drop support for Laravel 10/11\" PR when 6.x already dropped those versions).\n\nWhen in doubt about whether a `[5.x]`-prefixed commit is user-facing, lean toward including it — security/authorization hardening fixes (auth checks, method-resolution guarding, validation hardening) belong in the changelog even without a lot of detail in the title, matching how they're written up in the 5.x changelog (e.g. \"Harden remote URL validation\", \"Fix token path traversal\").\n\n## 4. Categorize commits\n\n- **What's new**: Commits that add new features (title contains \"Add\" or introduces new functionality). An \"improvement\" is not to be considered new. \n- **What's fixed**: Bug fixes, improvements, translation updates, and other changes\n\n## 5. Format each entry\n\nFormat: `- Description [#NUMBER](https://github.com/statamic/cms/issues/NUMBER) by @username`\n\n## 6. Order entries\n\n- Reverse the list so earliest commits come first (git log shows newest first)\n- Within each category, maintain chronological order — this already interleaves 5.x-origin commits correctly since step 1's log is in true merge order\n- Translation PRs get moved to the bottom of the list\n- Dependabot PRs get moved to the bottom, after translations\n\n## 7. Determine version number\n\n- Look at the previous version in CHANGELOG.md\n- If there are new features → increment minor version (e.g., 6.0.0 → 6.1.0)\n- If only fixes → increment patch version (e.g., 6.0.0 → 6.0.1)\n\n## 8. Format the release\n\n```markdown\n## X.Y.Z (YYYY-MM-DD)\n\n### What's new\n- Entry 1\n- Entry 2\n\n### What's fixed\n- Entry 1\n- Entry 2\n```\n\n- Use today's date\n- Leave 3 empty lines between releases\n- If there are no new features, omit the \"What's new\" section\n\n## 9. Update CHANGELOG.md\n\nInsert the new release entry at the top of the file, after the `# Release Notes` heading.\n\n## 10. Provide a summary to the user\n\nInform the user of anything noteworthy, or any liberties you took. e.g. \"I skipped PR 123 because of reason\" or \"I moved PR 123 to the bottom of the list\"\n\nYou do not need to list *everything*. Only the noteworthy bits. The user will be able to inspect the diff of the changelog to see what you're adding.\n",".cursorrules (typo3cms-extension-cursorrules-prompt-file.mdc)":"---\ndescription: \"Cursor rules for TYPO3 CMS development with extension integration.\"\nglobs: **/*\nalwaysApply: false\n---\nYou are a highly skilled TYPO3 extension developer tasked with creating a new extension. Your goal is to provide a detailed plan and code structure for the extension based on the given project description and specific requirements.\n\n---\n\n### 1. Development Guidelines\n\n- **Use PHP 8.3+ features where appropriate**\n- Follow **TYPO3 Coding Guidelines (CGL)** and **Core Team Best Practices**\n- Use the **Extension Builder** as a starting point where useful, but favor manual organization for better control\n- Apply **PSR-12** coding standards\n- Utilize **strict typing**, union types, readonly properties, and modern attributes\n- Prefer **dependency injection** over static access or global scope\n- Focus on excellent **Developer Experience (DX)**:\n  - Clear type annotations\n  - IDE autocompletion\n  - Precise PHPDoc blocks\n  - Consistent naming conventions\n\n---\n\n### 2. Coding Standards and Conventions\n\n- **File Names**: Use `PascalCase.php` (e.g., `MyService.php`)\n- **Class and Enum Names**: Use `PascalCase` (e.g., `MyUtilityClass`)\n- **Method Names**: Use `camelCase` (e.g., `getUserData`)\n- **Variable and Property Names**: Use `camelCase` (e.g., `userService`)\n- **Constants and Enum Case Names**: Use `SCREAMING_SNAKE_CASE` (e.g., `DEFAULT_LIMIT`)\n- **Namespaces**: Respect PSR-4 autoloading, use `Vendor\\ExtensionName\\SubNamespace`\n\n---\n\n### 3. Extension Structure and File Organization\n\n```plaintext\nmy_extension/\n├── Classes/\n│   ├── Controller/           # Extbase Controllers\n│   ├── Domain/\n│   │   ├── Model/            # Domain Models\n│   │   └── Repository/       # Domain Repositories\n│   ├── Service/              # Business logic classes\n│   ├── EventListener/        # PSR-14 event subscribers\n│   ├── Middleware/           # Custom middlewares (if needed)\n│   └── Utility/              # Utility/helper classes\n├── Configuration/\n│   ├── TCA/                  # Table configuration arrays\n│   ├── Services.yaml         # Service container configuration\n│   └── ext_localconf.php     # Extension registration\n├── Resources/\n│   ├── Private/\n│   │   ├── Templates/        # Fluid templates\n│   │   ├── Partials/\n│   │   └── Layouts/\n│   └── Public/               # JS, CSS, Images\n├── Tests/\n│   ├── Unit/                 # PHPUnit unit tests\n│   └── Functional/           # Functional tests\n├── ext_emconf.php            # Extension metadata\n└── composer.json             # Composer configuration\n```\n\n#### Integration into TYPO3 CMS\n\n- The extension is installed via **Composer** or manually via the **Extension Manager**\n- Services are automatically injected via `Services.yaml` configuration\n- PSR-14 Events, SignalSlots, and TypoScript are registered via `ext_localconf.php`\n- Configuration is handled via TypoScript and YAML\n\n---\n\n### 4. Testing and Documentation\n\n#### ✅ Testing Strategy\n\n- Use **PHPUnit** for both **unit** and **functional** tests\n- Use `typo3/testing-framework` for TYPO3-specific test cases\n- Write tests for:\n  - Domain logic (Models, Repositories)\n  - Services (pure PHP logic)\n  - Controllers (via functional tests)\n- Ensure code coverage and test edge cases\n\n#### 📚 Documentation Structure\n\n- `README.md`\n  - Extension purpose\n  - Installation instructions\n  - Minimal usage example\n- `Docs/`\n  - Setup and configuration guides\n  - Full usage examples (Fluid templates, TypoScript)\n  - API reference (linked with PHPDoc)\n- Code is self-documented with comprehensive **PHPDoc**\n"},"files":{"CLAUDE.md":"# Statamic CMS - Claude AI Context\n\n## Project Overview\n\nThis is the **Statamic CMS Core Package** - a Laravel-powered, flat-file (by default) CMS designed for building modern, easy-to-manage websites. This repository contains the core Composer package that gets installed into Laravel applications.\n\n## Project Structure\n\n```\n├── src/                  # Core PHP source code (PSR-4: Statamic\\)\n│   ├── CP/               # Control Panel specific functionality  \n│   └── ...               # Many other core modules\n├── resources/\n│   ├── js/               # Vue.js Control Panel frontend\n│   │   ├── bootstrap/\n│   │   │   ├── cms/      # Bootstraps the code necessary for the npm package\n│   │   │   └── ...\n│   │   ├── package/      # The @statamic/cms local npm package to be used by addons\n│   │   ├── tests/        # JS test suite (Vitest)\n│   │   └── ...\n│   ├── css/              # Stylesheets\n│   ├── views/            # Blade templates\n│   └── lang/             # Translations\n├── tests/                # PHPUnit test suite\n├── config/               # Configuration files\n└── routes/               # Route definitions\n```\n\n## Technology Stack\n\n- **Backend**: Laravel 12+ / PHP 8+\n- **Control Panel Frontend**: Vue 3 + TypeScript + Vite\n- **Control Panel CSS**: Tailwind CSS 4\n- **Database**: File-based \"Stache\" out of the box, but eloquent supported through the statamic/eloquent-driver composer package\n\n## Development Commands\n\n### PHP/Backend\n\n```bash\n# Run PHPUnit tests\n./vendor/bin/phpunit\n# OR use the batch file on Windows\nphpunit.bat\n\n# Code style/linting (Laravel Pint)\n./vendor/bin/pint\n\n# Run specific test\n./vendor/bin/phpunit tests/path/to/TestFile.php\n```\n\n## Common Development Tasks\n\n- **Adding new fieldtypes**: Extend `src/Fieldtypes/`\n- **Control Panel features**: Work in `src/CP/` + `resources/js/`\n- **API endpoints**: Check `src/API/` + `routes/api.php`\n- **Entry/content handling**: See `src/Entries/`\n- **Asset management**: See `src/Assets/`\n- **Authentication**: See `src/Auth/`\n\n## Testing\n\n- Full PHPUnit test suite in `tests/`\n- Frontend tests with Vitest\n- Run tests before submitting PRs\n\n## Important Notes\n\n- This is the **core package only** - it requires a Laravel app to run\n- The starter Laravel app is at [statamic/statamic](https://github.com/statamic/statamic)  \n- Documentation site code is at [statamic.dev](https://statamic.dev)\n- Do not commit compiled assets (`resources/dist/*`) - they're auto-generated\n- Follow the contribution guidelines in [CONTRIBUTING.md](CONTRIBUTING.md)\n\n## Build Process\n\nThe project uses Vite for asset compilation with separate configs:\n\n- `vite.config.js` - Main Control Panel assets. e.g. The Vue application.\n- `vite-frontend.config.js` - Frontend-specific assets. e.g. Things like conditional field logic to be used on front-end forms. \n- Control Panel assets are built to `resources/dist/` and `resources/dist-dev/`. The dev version enables Vue devtools.\n\n## NPM Package Notes\n\n- Our Vite bundle contains the Vue app, UI components, all the JS to make the Control Panel work.\n- We provide a `@statamic/cms` node module for addons to use that provides core helpers, ui components, etc.\n- Our Vite bundle assembles everything the node module needs in `resouces/js/bootstrap/cms` and makes it available in the `window.__STATAMIC__` object.\n- The node module is defined in `packages/cms` and resolves everything through the `window` object.\n- Code needs to be in the `window` object to prevent addon bundles from re-including our code, and from needing to recompile our source files.\n\n## UI Components & Storybook\n\n- UI components live in `resources/js/components/ui/` and are available to addons via `@statamic/cms/ui`. They are documented with Storybook at [ui.statamic.dev](https://ui.statamic.dev).\n- Stories live in `resources/js/stories/*.stories.ts`, their docs pages in `resources/js/stories/docs/*.mdx`.\n- `npm run storybook` starts Storybook along with its MCP server at `http://localhost:6006/mcp` (configured in `.mcp.json`).\n  - Use its documentation tools to look up a component's props, stories and usage before using or changing a UI component.\n  - After changing components or stories, run the story tests through the MCP server or with `npx vitest run --project storybook`.\n- Storybook generates component manifests for AI agents from stories, MDX docs and component source. Inspect them at `http://localhost:6006/manifests/components.html`.\n  - Document props with JSDoc comments. They end up in the manifest.\n  - Stories import components from `@statamic/cms/ui`, not `@ui`. Snippets copy the story's imports, and `@ui` doesn't exist for addons. `tsconfig.json` maps `@statamic/cms/ui` to `resources/js/components/ui` so this resolves in Storybook.\n  - Snippets are extracted statically from each story's `render`. Write `template` as a literal without `${}` interpolation, use `setup()` instead of `data`/`methods`, keep everything `setup` references inside it (or imported), and read args as `args.foo` or `v-bind=\"args\"`. A story that breaks these rules has no snippet in the manifest. Only add `parameters.docs.source.code` when the docs should show something different from the template.\n\n## For PR Reviews\n\n- All user-facing strings should be localized.\n  - Short strings (like \"Submit\" or \"Click here\") can use the translation strings as keys. \n  - Longer phrases or sentences should use keys and have their translations stored in an appropriate translation file.\n  - When adding to a translation file, only English strings need to be added. Other languages will be provided by contributors.\n  - Exception messages can stay untranslated in English\n\n## Misc\n\n- Commit messages within a PR do *not* need the PR number prefix. Those are just for the PR merge commit itself.\n\n\n## Links\n\n- [Main Documentation](https://statamic.dev/)\n- [Application Repo](https://github.com/statamic/statamic) \n- [Discussions](https://github.com/statamic/cms/discussions)\n- [Discord](https://statamic.com/discord)\n",".claude/skills/changelog/SKILL.md":"---\nname: changelog\ndescription: Generate a changelog for a release\n---\n\nGenerate a changelog entry for the CHANGELOG.md file by following these steps:\n\n## 1. Get commits since last tag\n\nFirst, fetch tags from origin — they sit off-branch (see note below) so they don't come down with a normal `git pull`/`git fetch` on the branch:\n\n```\ngit fetch origin --tags\n```\n\nThen run the following to get the list of commits:\n\n```\ngit --no-pager log $(git merge-base $(git tag --list 'v*' --sort=-v:refname | head -n1) HEAD)..HEAD --oneline --no-decorate --no-merges\n```\n\nNote: The release workflow tags a separate \"Build assets\" commit that is *not* an ancestor of the branch, so the tag itself never lands on `6.x`. That means `git describe --tags` walks back to a stale tag. Instead, take the newest tag and use its `git merge-base` with `HEAD`, which resolves to the release commit that *is* on the branch.\n\n5.x commits are merged into 6.x as-is (not squashed), so this plain `--no-merges` log already walks both the 6.x mainline and every commit brought in via a 5.x merge, in true chronological order — it only excludes the merge commits themselves (multi-parent, no real change of their own).\n\n## 2. Process each commit\n\nFor each commit:\n- Extract the PR number from the commit message (e.g., `(#13331)`)\n- Remove the commit SHA and `[6.x]`/`[5.x]` prefix from the message\n- Fetch the PR author from GitHub using a sequential loop — do NOT use parallel background jobs (`&`) as they interleave stdout unpredictably. Use: `for pr in <numbers>; do echo -n \"PR $pr: \"; gh pr view $pr --json author --jq '.author.login'; done`\n\n## 3. Skip certain commits\n\nSkip commits that are:\n- Test fixture updates (e.g., \"Update composer test fixtures\")\n- CI/workflow changes (e.g., \"Only run lint workflow...\")\n- Test-only fixes with no user-facing effect (e.g., \"Fix failing Guzzle tests\" — check the PR body; if it says the bug only affected tests, skip it)\n- Internal release/workflow-only PRs (e.g., \"Update Release Workflow\")\n- Commits with no PR number, or whose message is itself a merge bookkeeping commit (e.g., \"Merge 5.x (#NUM)\", \"Merge branch '5.x' into...\")\n\nDo not skip dependency bumps from dependabot.\n\nFor `[5.x]`-prefixed commits, also skip/dedupe:\n- Changes already superseded by a bigger PR in this release. Read the PR bodies — if a larger 6.x PR's description explicitly covers what the smaller 5.x fix addressed (e.g., a big OAuth rework that says it removes email-based matching supersedes a smaller \"Fix OAuth\" email-trust patch), skip the smaller one and note it in the summary (step 10).\n- Changes that no longer apply to 6.x because 6.x already handled it independently (e.g., a 5.x \"Drop support for Laravel 10/11\" PR when 6.x already dropped those versions).\n\nWhen in doubt about whether a `[5.x]`-prefixed commit is user-facing, lean toward including it — security/authorization hardening fixes (auth checks, method-resolution guarding, validation hardening) belong in the changelog even without a lot of detail in the title, matching how they're written up in the 5.x changelog (e.g. \"Harden remote URL validation\", \"Fix token path traversal\").\n\n## 4. Categorize commits\n\n- **What's new**: Commits that add new features (title contains \"Add\" or introduces new functionality). An \"improvement\" is not to be considered new. \n- **What's fixed**: Bug fixes, improvements, translation updates, and other changes\n\n## 5. Format each entry\n\nFormat: `- Description [#NUMBER](https://github.com/statamic/cms/issues/NUMBER) by @username`\n\n## 6. Order entries\n\n- Reverse the list so earliest commits come first (git log shows newest first)\n- Within each category, maintain chronological order — this already interleaves 5.x-origin commits correctly since step 1's log is in true merge order\n- Translation PRs get moved to the bottom of the list\n- Dependabot PRs get moved to the bottom, after translations\n\n## 7. Determine version number\n\n- Look at the previous version in CHANGELOG.md\n- If there are new features → increment minor version (e.g., 6.0.0 → 6.1.0)\n- If only fixes → increment patch version (e.g., 6.0.0 → 6.0.1)\n\n## 8. Format the release\n\n```markdown\n## X.Y.Z (YYYY-MM-DD)\n\n### What's new\n- Entry 1\n- Entry 2\n\n### What's fixed\n- Entry 1\n- Entry 2\n```\n\n- Use today's date\n- Leave 3 empty lines between releases\n- If there are no new features, omit the \"What's new\" section\n\n## 9. Update CHANGELOG.md\n\nInsert the new release entry at the top of the file, after the `# Release Notes` heading.\n\n## 10. Provide a summary to the user\n\nInform the user of anything noteworthy, or any liberties you took. e.g. \"I skipped PR 123 because of reason\" or \"I moved PR 123 to the bottom of the list\"\n\nYou do not need to list *everything*. Only the noteworthy bits. The user will be able to inspect the diff of the changelog to see what you're adding.\n",".cursorrules (typo3cms-extension-cursorrules-prompt-file.mdc)":"---\ndescription: \"Cursor rules for TYPO3 CMS development with extension integration.\"\nglobs: **/*\nalwaysApply: false\n---\nYou are a highly skilled TYPO3 extension developer tasked with creating a new extension. Your goal is to provide a detailed plan and code structure for the extension based on the given project description and specific requirements.\n\n---\n\n### 1. Development Guidelines\n\n- **Use PHP 8.3+ features where appropriate**\n- Follow **TYPO3 Coding Guidelines (CGL)** and **Core Team Best Practices**\n- Use the **Extension Builder** as a starting point where useful, but favor manual organization for better control\n- Apply **PSR-12** coding standards\n- Utilize **strict typing**, union types, readonly properties, and modern attributes\n- Prefer **dependency injection** over static access or global scope\n- Focus on excellent **Developer Experience (DX)**:\n  - Clear type annotations\n  - IDE autocompletion\n  - Precise PHPDoc blocks\n  - Consistent naming conventions\n\n---\n\n### 2. Coding Standards and Conventions\n\n- **File Names**: Use `PascalCase.php` (e.g., `MyService.php`)\n- **Class and Enum Names**: Use `PascalCase` (e.g., `MyUtilityClass`)\n- **Method Names**: Use `camelCase` (e.g., `getUserData`)\n- **Variable and Property Names**: Use `camelCase` (e.g., `userService`)\n- **Constants and Enum Case Names**: Use `SCREAMING_SNAKE_CASE` (e.g., `DEFAULT_LIMIT`)\n- **Namespaces**: Respect PSR-4 autoloading, use `Vendor\\ExtensionName\\SubNamespace`\n\n---\n\n### 3. Extension Structure and File Organization\n\n```plaintext\nmy_extension/\n├── Classes/\n│   ├── Controller/           # Extbase Controllers\n│   ├── Domain/\n│   │   ├── Model/            # Domain Models\n│   │   └── Repository/       # Domain Repositories\n│   ├── Service/              # Business logic classes\n│   ├── EventListener/        # PSR-14 event subscribers\n│   ├── Middleware/           # Custom middlewares (if needed)\n│   └── Utility/              # Utility/helper classes\n├── Configuration/\n│   ├── TCA/                  # Table configuration arrays\n│   ├── Services.yaml         # Service container configuration\n│   └── ext_localconf.php     # Extension registration\n├── Resources/\n│   ├── Private/\n│   │   ├── Templates/        # Fluid templates\n│   │   ├── Partials/\n│   │   └── Layouts/\n│   └── Public/               # JS, CSS, Images\n├── Tests/\n│   ├── Unit/                 # PHPUnit unit tests\n│   └── Functional/           # Functional tests\n├── ext_emconf.php            # Extension metadata\n└── composer.json             # Composer configuration\n```\n\n#### Integration into TYPO3 CMS\n\n- The extension is installed via **Composer** or manually via the **Extension Manager**\n- Services are automatically injected via `Services.yaml` configuration\n- PSR-14 Events, SignalSlots, and TypoScript are registered via `ext_localconf.php`\n- Configuration is handled via TypoScript and YAML\n\n---\n\n### 4. Testing and Documentation\n\n#### ✅ Testing Strategy\n\n- Use **PHPUnit** for both **unit** and **functional** tests\n- Use `typo3/testing-framework` for TYPO3-specific test cases\n- Write tests for:\n  - Domain logic (Models, Repositories)\n  - Services (pure PHP logic)\n  - Controllers (via functional tests)\n- Ensure code coverage and test edge cases\n\n#### 📚 Documentation Structure\n\n- `README.md`\n  - Extension purpose\n  - Installation instructions\n  - Minimal usage example\n- `Docs/`\n  - Setup and configuration guides\n  - Full usage examples (Fluid templates, TypoScript)\n  - API reference (linked with PHPDoc)\n- Code is self-documented with comprehensive **PHPDoc**\n"},"items":[{"name":"SKILL.md","path":".claude/skills/changelog/SKILL.md","rawUrl":"https://raw.githubusercontent.com/statamic/cms/HEAD/.claude/skills/changelog/SKILL.md","title":"changelog","category":"anthropic-skill","format":"markdown","content":"---\nname: changelog\ndescription: Generate a changelog for a release\n---\n\nGenerate a changelog entry for the CHANGELOG.md file by following these steps:\n\n## 1. Get commits since last tag\n\nFirst, fetch tags from origin — they sit off-branch (see note below) so they don't come down with a normal `git pull`/`git fetch` on the branch:\n\n```\ngit fetch origin --tags\n```\n\nThen run the following to get the list of commits:\n\n```\ngit --no-pager log $(git merge-base $(git tag --list 'v*' --sort=-v:refname | head -n1) HEAD)..HEAD --oneline --no-decorate --no-merges\n```\n\nNote: The release workflow tags a separate \"Build assets\" commit that is *not* an ancestor of the branch, so the tag itself never lands on `6.x`. That means `git describe --tags` walks back to a stale tag. Instead, take the newest tag and use its `git merge-base` with `HEAD`, which resolves to the release commit that *is* on the branch.\n\n5.x commits are merged into 6.x as-is (not squashed), so this plain `--no-merges` log already walks both the 6.x mainline and every commit brought in via a 5.x merge, in true chronological order — it only excludes the merge commits themselves (multi-parent, no real change of their own).\n\n## 2. Process each commit\n\nFor each commit:\n- Extract the PR number from the commit message (e.g., `(#13331)`)\n- Remove the commit SHA and `[6.x]`/`[5.x]` prefix from the message\n- Fetch the PR author from GitHub using a sequential loop — do NOT use parallel background jobs (`&`) as they interleave stdout unpredictably. Use: `for pr in <numbers>; do echo -n \"PR $pr: \"; gh pr view $pr --json author --jq '.author.login'; done`\n\n## 3. Skip certain commits\n\nSkip commits that are:\n- Test fixture updates (e.g., \"Update composer test fixtures\")\n- CI/workflow changes (e.g., \"Only run lint workflow...\")\n- Test-only fixes with no user-facing effect (e.g., \"Fix failing Guzzle tests\" — check the PR body; if it says the bug only affected tests, skip it)\n- Internal release/workflow-only PRs (e.g., \"Update Release Workflow\")\n- Commits with no PR number, or whose message is itself a merge bookkeeping commit (e.g., \"Merge 5.x (#NUM)\", \"Merge branch '5.x' into...\")\n\nDo not skip dependency bumps from dependabot.\n\nFor `[5.x]`-prefixed commits, also skip/dedupe:\n- Changes already superseded by a bigger PR in this release. Read the PR bodies — if a larger 6.x PR's description explicitly covers what the smaller 5.x fix addressed (e.g., a big OAuth rework that says it removes email-based matching supersedes a smaller \"Fix OAuth\" email-trust patch), skip the smaller one and note it in the summary (step 10).\n- Changes that no longer apply to 6.x because 6.x already handled it independently (e.g., a 5.x \"Drop support for Laravel 10/11\" PR when 6.x already dropped those versions).\n\nWhen in doubt about whether a `[5.x]`-prefixed commit is user-facing, lean toward including it — security/authorization hardening fixes (auth checks, method-resolution guarding, validation hardening) belong in the changelog even without a lot of detail in the title, matching how they're written up in the 5.x changelog (e.g. \"Harden remote URL validation\", \"Fix token path traversal\").\n\n## 4. Categorize commits\n\n- **What's new**: Commits that add new features (title contains \"Add\" or introduces new functionality). An \"improvement\" is not to be considered new. \n- **What's fixed**: Bug fixes, improvements, translation updates, and other changes\n\n## 5. Format each entry\n\nFormat: `- Description [#NUMBER](https://github.com/statamic/cms/issues/NUMBER) by @username`\n\n## 6. Order entries\n\n- Reverse the list so earliest commits come first (git log shows newest first)\n- Within each category, maintain chronological order — this already interleaves 5.x-origin commits correctly since step 1's log is in true merge order\n- Translation PRs get moved to the bottom of the list\n- Dependabot PRs get moved to the bottom, after translations\n\n## 7. Determine version number\n\n- Look at the previous version in CHANGELOG.md\n- If there are new features → increment minor version (e.g., 6.0.0 → 6.1.0)\n- If only fixes → increment patch version (e.g., 6.0.0 → 6.0.1)\n\n## 8. Format the release\n\n```markdown\n## X.Y.Z (YYYY-MM-DD)\n\n### What's new\n- Entry 1\n- Entry 2\n\n### What's fixed\n- Entry 1\n- Entry 2\n```\n\n- Use today's date\n- Leave 3 empty lines between releases\n- If there are no new features, omit the \"What's new\" section\n\n## 9. Update CHANGELOG.md\n\nInsert the new release entry at the top of the file, after the `# Release Notes` heading.\n\n## 10. Provide a summary to the user\n\nInform the user of anything noteworthy, or any liberties you took. e.g. \"I skipped PR 123 because of reason\" or \"I moved PR 123 to the bottom of the list\"\n\nYou do not need to list *everything*. Only the noteworthy bits. The user will be able to inspect the diff of the changelog to see what you're adding.\n","frontmatter":{"name":"changelog","description":"Generate a changelog for a release"},"isInternal":false,"tokens":1252,"sizeBytes":4874},{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/statamic/cms/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"# Statamic CMS - Claude AI Context\n\n## Project Overview\n\nThis is the **Statamic CMS Core Package** - a Laravel-powered, flat-file (by default) CMS designed for building modern, easy-to-manage websites. This repository contains the core Composer package that gets installed into Laravel applications.\n\n## Project Structure\n\n```\n├── src/                  # Core PHP source code (PSR-4: Statamic\\)\n│   ├── CP/               # Control Panel specific functionality  \n│   └── ...               # Many other core modules\n├── resources/\n│   ├── js/               # Vue.js Control Panel frontend\n│   │   ├── bootstrap/\n│   │   │   ├── cms/      # Bootstraps the code necessary for the npm package\n│   │   │   └── ...\n│   │   ├── package/      # The @statamic/cms local npm package to be used by addons\n│   │   ├── tests/        # JS test suite (Vitest)\n│   │   └── ...\n│   ├── css/              # Stylesheets\n│   ├── views/            # Blade templates\n│   └── lang/             # Translations\n├── tests/                # PHPUnit test suite\n├── config/               # Configuration files\n└── routes/               # Route definitions\n```\n\n## Technology Stack\n\n- **Backend**: Laravel 12+ / PHP 8+\n- **Control Panel Frontend**: Vue 3 + TypeScript + Vite\n- **Control Panel CSS**: Tailwind CSS 4\n- **Database**: File-based \"Stache\" out of the box, but eloquent supported through the statamic/eloquent-driver composer package\n\n## Development Commands\n\n### PHP/Backend\n\n```bash\n# Run PHPUnit tests\n./vendor/bin/phpunit\n# OR use the batch file on Windows\nphpunit.bat\n\n# Code style/linting (Laravel Pint)\n./vendor/bin/pint\n\n# Run specific test\n./vendor/bin/phpunit tests/path/to/TestFile.php\n```\n\n## Common Development Tasks\n\n- **Adding new fieldtypes**: Extend `src/Fieldtypes/`\n- **Control Panel features**: Work in `src/CP/` + `resources/js/`\n- **API endpoints**: Check `src/API/` + `routes/api.php`\n- **Entry/content handling**: See `src/Entries/`\n- **Asset management**: See `src/Assets/`\n- **Authentication**: See `src/Auth/`\n\n## Testing\n\n- Full PHPUnit test suite in `tests/`\n- Frontend tests with Vitest\n- Run tests before submitting PRs\n\n## Important Notes\n\n- This is the **core package only** - it requires a Laravel app to run\n- The starter Laravel app is at [statamic/statamic](https://github.com/statamic/statamic)  \n- Documentation site code is at [statamic.dev](https://statamic.dev)\n- Do not commit compiled assets (`resources/dist/*`) - they're auto-generated\n- Follow the contribution guidelines in [CONTRIBUTING.md](CONTRIBUTING.md)\n\n## Build Process\n\nThe project uses Vite for asset compilation with separate configs:\n\n- `vite.config.js` - Main Control Panel assets. e.g. The Vue application.\n- `vite-frontend.config.js` - Frontend-specific assets. e.g. Things like conditional field logic to be used on front-end forms. \n- Control Panel assets are built to `resources/dist/` and `resources/dist-dev/`. The dev version enables Vue devtools.\n\n## NPM Package Notes\n\n- Our Vite bundle contains the Vue app, UI components, all the JS to make the Control Panel work.\n- We provide a `@statamic/cms` node module for addons to use that provides core helpers, ui components, etc.\n- Our Vite bundle assembles everything the node module needs in `resouces/js/bootstrap/cms` and makes it available in the `window.__STATAMIC__` object.\n- The node module is defined in `packages/cms` and resolves everything through the `window` object.\n- Code needs to be in the `window` object to prevent addon bundles from re-including our code, and from needing to recompile our source files.\n\n## UI Components & Storybook\n\n- UI components live in `resources/js/components/ui/` and are available to addons via `@statamic/cms/ui`. They are documented with Storybook at [ui.statamic.dev](https://ui.statamic.dev).\n- Stories live in `resources/js/stories/*.stories.ts`, their docs pages in `resources/js/stories/docs/*.mdx`.\n- `npm run storybook` starts Storybook along with its MCP server at `http://localhost:6006/mcp` (configured in `.mcp.json`).\n  - Use its documentation tools to look up a component's props, stories and usage before using or changing a UI component.\n  - After changing components or stories, run the story tests through the MCP server or with `npx vitest run --project storybook`.\n- Storybook generates component manifests for AI agents from stories, MDX docs and component source. Inspect them at `http://localhost:6006/manifests/components.html`.\n  - Document props with JSDoc comments. They end up in the manifest.\n  - Stories import components from `@statamic/cms/ui`, not `@ui`. Snippets copy the story's imports, and `@ui` doesn't exist for addons. `tsconfig.json` maps `@statamic/cms/ui` to `resources/js/components/ui` so this resolves in Storybook.\n  - Snippets are extracted statically from each story's `render`. Write `template` as a literal without `${}` interpolation, use `setup()` instead of `data`/`methods`, keep everything `setup` references inside it (or imported), and read args as `args.foo` or `v-bind=\"args\"`. A story that breaks these rules has no snippet in the manifest. Only add `parameters.docs.source.code` when the docs should show something different from the template.\n\n## For PR Reviews\n\n- All user-facing strings should be localized.\n  - Short strings (like \"Submit\" or \"Click here\") can use the translation strings as keys. \n  - Longer phrases or sentences should use keys and have their translations stored in an appropriate translation file.\n  - When adding to a translation file, only English strings need to be added. Other languages will be provided by contributors.\n  - Exception messages can stay untranslated in English\n\n## Misc\n\n- Commit messages within a PR do *not* need the PR number prefix. Those are just for the PR merge commit itself.\n\n\n## Links\n\n- [Main Documentation](https://statamic.dev/)\n- [Application Repo](https://github.com/statamic/statamic) \n- [Discussions](https://github.com/statamic/cms/discussions)\n- [Discord](https://statamic.com/discord)\n","isInternal":false,"tokens":1450,"sizeBytes":6147},{"name":".cursorrules","path":".cursorrules (typo3cms-extension-cursorrules-prompt-file.mdc)","rawUrl":"https://raw.githubusercontent.com/PatrickJS/awesome-cursorrules/main/rules/typo3cms-extension-cursorrules-prompt-file.mdc","title":"Awesome Cursorrules: typo3cms extension","category":"cursor-rule","format":"markdown","content":"---\ndescription: \"Cursor rules for TYPO3 CMS development with extension integration.\"\nglobs: **/*\nalwaysApply: false\n---\nYou are a highly skilled TYPO3 extension developer tasked with creating a new extension. Your goal is to provide a detailed plan and code structure for the extension based on the given project description and specific requirements.\n\n---\n\n### 1. Development Guidelines\n\n- **Use PHP 8.3+ features where appropriate**\n- Follow **TYPO3 Coding Guidelines (CGL)** and **Core Team Best Practices**\n- Use the **Extension Builder** as a starting point where useful, but favor manual organization for better control\n- Apply **PSR-12** coding standards\n- Utilize **strict typing**, union types, readonly properties, and modern attributes\n- Prefer **dependency injection** over static access or global scope\n- Focus on excellent **Developer Experience (DX)**:\n  - Clear type annotations\n  - IDE autocompletion\n  - Precise PHPDoc blocks\n  - Consistent naming conventions\n\n---\n\n### 2. Coding Standards and Conventions\n\n- **File Names**: Use `PascalCase.php` (e.g., `MyService.php`)\n- **Class and Enum Names**: Use `PascalCase` (e.g., `MyUtilityClass`)\n- **Method Names**: Use `camelCase` (e.g., `getUserData`)\n- **Variable and Property Names**: Use `camelCase` (e.g., `userService`)\n- **Constants and Enum Case Names**: Use `SCREAMING_SNAKE_CASE` (e.g., `DEFAULT_LIMIT`)\n- **Namespaces**: Respect PSR-4 autoloading, use `Vendor\\ExtensionName\\SubNamespace`\n\n---\n\n### 3. Extension Structure and File Organization\n\n```plaintext\nmy_extension/\n├── Classes/\n│   ├── Controller/           # Extbase Controllers\n│   ├── Domain/\n│   │   ├── Model/            # Domain Models\n│   │   └── Repository/       # Domain Repositories\n│   ├── Service/              # Business logic classes\n│   ├── EventListener/        # PSR-14 event subscribers\n│   ├── Middleware/           # Custom middlewares (if needed)\n│   └── Utility/              # Utility/helper classes\n├── Configuration/\n│   ├── TCA/                  # Table configuration arrays\n│   ├── Services.yaml         # Service container configuration\n│   └── ext_localconf.php     # Extension registration\n├── Resources/\n│   ├── Private/\n│   │   ├── Templates/        # Fluid templates\n│   │   ├── Partials/\n│   │   └── Layouts/\n│   └── Public/               # JS, CSS, Images\n├── Tests/\n│   ├── Unit/                 # PHPUnit unit tests\n│   └── Functional/           # Functional tests\n├── ext_emconf.php            # Extension metadata\n└── composer.json             # Composer configuration\n```\n\n#### Integration into TYPO3 CMS\n\n- The extension is installed via **Composer** or manually via the **Extension Manager**\n- Services are automatically injected via `Services.yaml` configuration\n- PSR-14 Events, SignalSlots, and TypoScript are registered via `ext_localconf.php`\n- Configuration is handled via TypoScript and YAML\n\n---\n\n### 4. Testing and Documentation\n\n#### ✅ Testing Strategy\n\n- Use **PHPUnit** for both **unit** and **functional** tests\n- Use `typo3/testing-framework` for TYPO3-specific test cases\n- Write tests for:\n  - Domain logic (Models, Repositories)\n  - Services (pure PHP logic)\n  - Controllers (via functional tests)\n- Ensure code coverage and test edge cases\n\n#### 📚 Documentation Structure\n\n- `README.md`\n  - Extension purpose\n  - Installation instructions\n  - Minimal usage example\n- `Docs/`\n  - Setup and configuration guides\n  - Full usage examples (Fluid templates, TypoScript)\n  - API reference (linked with PHPDoc)\n- Code is self-documented with comprehensive **PHPDoc**\n","tokens":846,"sizeBytes":3746}],"systemPromptSnippet":"<yakaai_skills repo=\"statamic/cms\">\n<!-- File: .claude/skills/changelog/SKILL.md (Tokens: ~1252 | Category: anthropic-skill) -->\n---\nname: changelog\ndescription: Generate a changelog for a release\n---\n\nGenerate a changelog entry for the CHANGELOG.md file by following these steps:\n\n## 1. Get commits since last tag\n\nFirst, fetch tags from origin — they sit off-branch (see note below) so they don't come down with a normal `git pull`/`git fetch` on the branch:\n\n```\ngit fetch origin --tags\n```\n\nThen run the following to get the list of commits:\n\n```\ngit --no-pager log $(git merge-base $(git tag --list 'v*' --sort=-v:refname | head -n1) HEAD)..HEAD --oneline --no-decorate --no-merges\n```\n\nNote: The release workflow tags a separate \"Build assets\" commit that is *not* an ancestor of the branch, so the tag itself never lands on `6.x`. That means `git describe --tags` walks back to a stale tag. Instead, take the newest tag and use its `git merge-base` with `HEAD`, which resolves to the release commit that *is* on the branch.\n\n5.x commits are merged into 6.x as-is (not squashed), so this plain `--no-merges` log already walks both the 6.x mainline and every commit brought in via a 5.x merge, in true chronological order — it only excludes the merge commits themselves (multi-parent, no real change of their own).\n\n## 2. Process each commit\n\nFor each commit:\n- Extract the PR number from the commit message (e.g., `(#13331)`)\n- Remove the commit SHA and `[6.x]`/`[5.x]` prefix from the message\n- Fetch the PR author from GitHub using a sequential loop — do NOT use parallel background jobs (`&`) as they interleave stdout unpredictably. Use: `for pr in <numbers>; do echo -n \"PR $pr: \"; gh pr view $pr --json author --jq '.author.login'; done`\n\n## 3. Skip certain commits\n\nSkip commits that are:\n- Test fixture updates (e.g., \"Update composer test fixtures\")\n- CI/workflow changes (e.g., \"Only run lint workflow...\")\n- Test-only fixes with no user-facing effect (e.g., \"Fix failing Guzzle tests\" — check the PR body; if it says the bug only affected tests, skip it)\n- Internal release/workflow-only PRs (e.g., \"Update Release Workflow\")\n- Commits with no PR number, or whose message is itself a merge bookkeeping commit (e.g., \"Merge 5.x (#NUM)\", \"Merge branch '5.x' into...\")\n\nDo not skip dependency bumps from dependabot.\n\nFor `[5.x]`-prefixed commits, also skip/dedupe:\n- Changes already superseded by a bigger PR in this release. Read the PR bodies — if a larger 6.x PR's description explicitly covers what the smaller 5.x fix addressed (e.g., a big OAuth rework that says it removes email-based matching supersedes a smaller \"Fix OAuth\" email-trust patch), skip the smaller one and note it in the summary (step 10).\n- Changes that no longer apply to 6.x because 6.x already handled it independently (e.g., a 5.x \"Drop support for Laravel 10/11\" PR when 6.x already dropped those versions).\n\nWhen in doubt about whether a `[5.x]`-prefixed commit is user-facing, lean toward including it — security/authorization hardening fixes (auth checks, method-resolution guarding, validation hardening) belong in the changelog even without a lot of detail in the title, matching how they're written up in the 5.x changelog (e.g. \"Harden remote URL validation\", \"Fix token path traversal\").\n\n## 4. Categorize commits\n\n- **What's new**: Commits that add new features (title contains \"Add\" or introduces new functionality). An \"improvement\" is not to be considered new. \n- **What's fixed**: Bug fixes, improvements, translation updates, and other changes\n\n## 5. Format each entry\n\nFormat: `- Description [#NUMBER](https://github.com/statamic/cms/issues/NUMBER) by @username`\n\n## 6. Order entries\n\n- Reverse the list so earliest commits come first (git log shows newest first)\n- Within each category, maintain chronological order — this already interleaves 5.x-origin commits correctly since step 1's log is in true merge order\n- Translation PRs get moved to the bottom of the list\n- Dependabot PRs get moved to the bottom, after translations\n\n## 7. Determine version number\n\n- Look at the previous version in CHANGELOG.md\n- If there are new features → increment minor version (e.g., 6.0.0 → 6.1.0)\n- If only fixes → increment patch version (e.g., 6.0.0 → 6.0.1)\n\n## 8. Format the release\n\n```markdown\n## X.Y.Z (YYYY-MM-DD)\n\n### What's new\n- Entry 1\n- Entry 2\n\n### What's fixed\n- Entry 1\n- Entry 2\n```\n\n- Use today's date\n- Leave 3 empty lines between releases\n- If there are no new features, omit the \"What's new\" section\n\n## 9. Update CHANGELOG.md\n\nInsert the new release entry at the top of the file, after the `# Release Notes` heading.\n\n## 10. Provide a summary to the user\n\nInform the user of anything noteworthy, or any liberties you took. e.g. \"I skipped PR 123 because of reason\" or \"I moved PR 123 to the bottom of the list\"\n\nYou do not need to list *everything*. Only the noteworthy bits. The user will be able to inspect the diff of the changelog to see what you're adding.\n\n<!-- File: CLAUDE.md (Tokens: ~1450 | Category: claude-rule) -->\n# Statamic CMS - Claude AI Context\n\n## Project Overview\n\nThis is the **Statamic CMS Core Package** - a Laravel-powered, flat-file (by default) CMS designed for building modern, easy-to-manage websites. This repository contains the core Composer package that gets installed into Laravel applications.\n\n## Project Structure\n\n```\n├── src/                  # Core PHP source code (PSR-4: Statamic\\)\n│   ├── CP/               # Control Panel specific functionality  \n│   └── ...               # Many other core modules\n├── resources/\n│   ├── js/               # Vue.js Control Panel frontend\n│   │   ├── bootstrap/\n│   │   │   ├── cms/      # Bootstraps the code necessary for the npm package\n│   │   │   └── ...\n│   │   ├── package/      # The @statamic/cms local npm package to be used by addons\n│   │   ├── tests/        # JS test suite (Vitest)\n│   │   └── ...\n│   ├── css/              # Stylesheets\n│   ├── views/            # Blade templates\n│   └── lang/             # Translations\n├── tests/                # PHPUnit test suite\n├── config/               # Configuration files\n└── routes/               # Route definitions\n```\n\n## Technology Stack\n\n- **Backend**: Laravel 12+ / PHP 8+\n- **Control Panel Frontend**: Vue 3 + TypeScript + Vite\n- **Control Panel CSS**: Tailwind CSS 4\n- **Database**: File-based \"Stache\" out of the box, but eloquent supported through the statamic/eloquent-driver composer package\n\n## Development Commands\n\n### PHP/Backend\n\n```bash\n# Run PHPUnit tests\n./vendor/bin/phpunit\n# OR use the batch file on Windows\nphpunit.bat\n\n# Code style/linting (Laravel Pint)\n./vendor/bin/pint\n\n# Run specific test\n./vendor/bin/phpunit tests/path/to/TestFile.php\n```\n\n## Common Development Tasks\n\n- **Adding new fieldtypes**: Extend `src/Fieldtypes/`\n- **Control Panel features**: Work in `src/CP/` + `resources/js/`\n- **API endpoints**: Check `src/API/` + `routes/api.php`\n- **Entry/content handling**: See `src/Entries/`\n- **Asset management**: See `src/Assets/`\n- **Authentication**: See `src/Auth/`\n\n## Testing\n\n- Full PHPUnit test suite in `tests/`\n- Frontend tests with Vitest\n- Run tests before submitting PRs\n\n## Important Notes\n\n- This is the **core package only** - it requires a Laravel app to run\n- The starter Laravel app is at [statamic/statamic](https://github.com/statamic/statamic)  \n- Documentation site code is at [statamic.dev](https://statamic.dev)\n- Do not commit compiled assets (`resources/dist/*`) - they're auto-generated\n- Follow the contribution guidelines in [CONTRIBUTING.md](CONTRIBUTING.md)\n\n## Build Process\n\nThe project uses Vite for asset compilation with separate configs:\n\n- `vite.config.js` - Main Control Panel assets. e.g. The Vue application.\n- `vite-frontend.config.js` - Frontend-specific assets. e.g. Things like conditional field logic to be used on front-end forms. \n- Control Panel assets are built to `resources/dist/` and `resources/dist-dev/`. The dev version enables Vue devtools.\n\n## NPM Package Notes\n\n- Our Vite bundle contains the Vue app, UI components, all the JS to make the Control Panel work.\n- We provide a `@statamic/cms` node module for addons to use that provides core helpers, ui components, etc.\n- Our Vite bundle assembles everything the node module needs in `resouces/js/bootstrap/cms` and makes it available in the `window.__STATAMIC__` object.\n- The node module is defined in `packages/cms` and resolves everything through the `window` object.\n- Code needs to be in the `window` object to prevent addon bundles from re-including our code, and from needing to recompile our source files.\n\n## UI Components & Storybook\n\n- UI components live in `resources/js/components/ui/` and are available to addons via `@statamic/cms/ui`. They are documented with Storybook at [ui.statamic.dev](https://ui.statamic.dev).\n- Stories live in `resources/js/stories/*.stories.ts`, their docs pages in `resources/js/stories/docs/*.mdx`.\n- `npm run storybook` starts Storybook along with its MCP server at `http://localhost:6006/mcp` (configured in `.mcp.json`).\n  - Use its documentation tools to look up a component's props, stories and usage before using or changing a UI component.\n  - After changing components or stories, run the story tests through the MCP server or with `npx vitest run --project storybook`.\n- Storybook generates component manifests for AI agents from stories, MDX docs and component source. Inspect them at `http://localhost:6006/manifests/components.html`.\n  - Document props with JSDoc comments. They end up in the manifest.\n  - Stories import components from `@statamic/cms/ui`, not `@ui`. Snippets copy the story's imports, and `@ui` doesn't exist for addons. `tsconfig.json` maps `@statamic/cms/ui` to `resources/js/components/ui` so this resolves in Storybook.\n  - Snippets are extracted statically from each story's `render`. Write `template` as a literal without `${}` interpolation, use `setup()` instead of `data`/`methods`, keep everything `setup` references inside it (or imported), and read args as `args.foo` or `v-bind=\"args\"`. A story that breaks these rules has no snippet in the manifest. Only add `parameters.docs.source.code` when the docs should show something different from the template.\n\n## For PR Reviews\n\n- All user-facing strings should be localized.\n  - Short strings (like \"Submit\" or \"Click here\") can use the translation strings as keys. \n  - Longer phrases or sentences should use keys and have their translations stored in an appropriate translation file.\n  - When adding to a translation file, only English strings need to be added. Other languages will be provided by contributors.\n  - Exception messages can stay untranslated in English\n\n## Misc\n\n- Commit messages within a PR do *not* need the PR number prefix. Those are just for the PR merge commit itself.\n\n\n## Links\n\n- [Main Documentation](https://statamic.dev/)\n- [Application Repo](https://github.com/statamic/statamic) \n- [Discussions](https://github.com/statamic/cms/discussions)\n- [Discord](https://statamic.com/discord)\n\n<!-- File: .cursorrules (typo3cms-extension-cursorrules-prompt-file.mdc) (Tokens: ~846 | Category: cursor-rule) -->\n---\ndescription: \"Cursor rules for TYPO3 CMS development with extension integration.\"\nglobs: **/*\nalwaysApply: false\n---\nYou are a highly skilled TYPO3 extension developer tasked with creating a new extension. Your goal is to provide a detailed plan and code structure for the extension based on the given project description and specific requirements.\n\n---\n\n### 1. Development Guidelines\n\n- **Use PHP 8.3+ features where appropriate**\n- Follow **TYPO3 Coding Guidelines (CGL)** and **Core Team Best Practices**\n- Use the **Extension Builder** as a starting point where useful, but favor manual organization for better control\n- Apply **PSR-12** coding standards\n- Utilize **strict typing**, union types, readonly properties, and modern attributes\n- Prefer **dependency injection** over static access or global scope\n- Focus on excellent **Developer Experience (DX)**:\n  - Clear type annotations\n  - IDE autocompletion\n  - Precise PHPDoc blocks\n  - Consistent naming conventions\n\n---\n\n### 2. Coding Standards and Conventions\n\n- **File Names**: Use `PascalCase.php` (e.g., `MyService.php`)\n- **Class and Enum Names**: Use `PascalCase` (e.g., `MyUtilityClass`)\n- **Method Names**: Use `camelCase` (e.g., `getUserData`)\n- **Variable and Property Names**: Use `camelCase` (e.g., `userService`)\n- **Constants and Enum Case Names**: Use `SCREAMING_SNAKE_CASE` (e.g., `DEFAULT_LIMIT`)\n- **Namespaces**: Respect PSR-4 autoloading, use `Vendor\\ExtensionName\\SubNamespace`\n\n---\n\n### 3. Extension Structure and File Organization\n\n```plaintext\nmy_extension/\n├── Classes/\n│   ├── Controller/           # Extbase Controllers\n│   ├── Domain/\n│   │   ├── Model/            # Domain Models\n│   │   └── Repository/       # Domain Repositories\n│   ├── Service/              # Business logic classes\n│   ├── EventListener/        # PSR-14 event subscribers\n│   ├── Middleware/           # Custom middlewares (if needed)\n│   └── Utility/              # Utility/helper classes\n├── Configuration/\n│   ├── TCA/                  # Table configuration arrays\n│   ├── Services.yaml         # Service container configuration\n│   └── ext_localconf.php     # Extension registration\n├── Resources/\n│   ├── Private/\n│   │   ├── Templates/        # Fluid templates\n│   │   ├── Partials/\n│   │   └── Layouts/\n│   └── Public/               # JS, CSS, Images\n├── Tests/\n│   ├── Unit/                 # PHPUnit unit tests\n│   └── Functional/           # Functional tests\n├── ext_emconf.php            # Extension metadata\n└── composer.json             # Composer configuration\n```\n\n#### Integration into TYPO3 CMS\n\n- The extension is installed via **Composer** or manually via the **Extension Manager**\n- Services are automatically injected via `Services.yaml` configuration\n- PSR-14 Events, SignalSlots, and TypoScript are registered via `ext_localconf.php`\n- Configuration is handled via TypoScript and YAML\n\n---\n\n### 4. Testing and Documentation\n\n#### ✅ Testing Strategy\n\n- Use **PHPUnit** for both **unit** and **functional** tests\n- Use `typo3/testing-framework` for TYPO3-specific test cases\n- Write tests for:\n  - Domain logic (Models, Repositories)\n  - Services (pure PHP logic)\n  - Controllers (via functional tests)\n- Ensure code coverage and test edge cases\n\n#### 📚 Documentation Structure\n\n- `README.md`\n  - Extension purpose\n  - Installation instructions\n  - Minimal usage example\n- `Docs/`\n  - Setup and configuration guides\n  - Full usage examples (Fluid templates, TypoScript)\n  - API reference (linked with PHPDoc)\n- Code is self-documented with comprehensive **PHPDoc**\n</yakaai_skills>"}