docs(agents): remove commit message guidelines from AGENTS.md

- Drop duplicate Conventional Commits section in favor of the commit skill

Author: lemmon

AGENTS.md

@@ -41,24 +41,3 @@ Dev tooling: symfony/var-dumper, symfony/error-handler, ergebnis/composer-normal
 ## Coding Style & Formatting
 
 PSR-12 for PHP. Mago for lint/format (`composer lint`, `composer format`). Prettier (`.prettierrc`) for YAML, JSON, Markdown. Add PHPDoc where behavior is non-obvious. Stick to ASCII punctuation in code and docs (e.g. `--` not em dash) so diffs stay predictable. Emojis sparingly.
-
-## Commit Message Guidelines
-
-- Commit messages must follow Conventional Commits
-- Write messages so they make sense for commit-by-commit development: each commit describes the actual state change from the previous shipped state. Do not mention intermediate or throwaway steps (e.g. classes created and removed in the same session). Describe what the commit delivers, not the path taken to get there
-- Subject format: `<type>(<scope>): <summary>`; use `<type>: <summary>` when scope is omitted
-- Allowed `type` values: `feat`, `fix`, `refactor`, `perf`, `docs`, `test`, `build`, `ci`, `chore`, `revert`
-- `scope` is optional but recommended when it narrows the area (e.g. `StringValidator`, `FieldValidator`, `AssociativeValidator`)
-- Write summary lines in imperative mood, keep them concise (around 72 characters recommended, not strict), and omit trailing periods
-- Keep each commit focused on one concern; include related tests or validation updates in the same commit when applicable
-- Prefer bullet lists in commit bodies for concrete changes, with one logical change per bullet
-- Commit body bullets should start with a capitalized imperative verb and omit trailing periods
-- Never artificially break lines anywhere in a commit message; tools wrap naturally
-- Avoid unnecessary noise in commit bodies; include only explicit, intentional, non-obvious updates
-- Do not call out secondary artifact changes (for example lockfile refreshes) unless they carry non-obvious impact
-- Add a short prose paragraph only when extra context is needed (rationale, tradeoffs, migration notes, risks, or non-obvious impact)
-- Separate subject, body, and footers with blank lines
-- Use optional footers in `Key: Value` format; preferred keys: `Refs`, `Closes`, `Fixes`, `PR`, `BREAKING CHANGE`
-- Breaking changes must include a `BREAKING CHANGE:` footer
-- Release notes belong in CHANGELOG, not commit body. Tag format: annotated `vX.Y.Z - <headline>`; details in CHANGELOG/releases
-- Quick templates: `fix(scope): <imperative summary>` and `feat(scope): <imperative summary>`