chore(agent): migrate to skills-based instruction system and extend roadmap

.claude/commands/symfony/bug-fix.md

@@ -0,0 +1,31 @@
+Fix a Signalist bug using a small, repeatable regression-first workflow.
+
+Bug report or scope: `$ARGUMENTS`
+
+Execution order:
+1. Reproduce the bug from the user report, failing test, logs, or current behavior.
+2. Find the narrowest code path that explains the failure.
+3. Identify the root cause before changing code.
+4. Implement the smallest fix that resolves the bug cleanly.
+5. Add or update a regression test in the same session.
+6. Run the relevant repository quality gates before reporting completion.
+
+Default expectations unless the repo clearly differs:
+- Prefer the smallest understandable fix over broad refactoring.
+- Keep the fix easy for a human reviewer to understand.
+- If API Platform, React Query, or another existing project feature already provides the correct behavior directly, use it instead of adding extra layers.
+- If performance and readability conflict and there is no measured bottleneck, choose readability.
+
+Checklist:
+1. State expected behavior versus actual behavior.
+2. Point to the concrete failing path: endpoint, state processor, handler, repository, message handler, hook, component, or adapter.
+3. Reuse local patterns instead of introducing a new structure during a bug fix.
+4. Add one regression test for the reproduced scenario.
+5. Add extra coverage only for closely related edge cases.
+6. Verify with the commands exposed by `Makefile` and the frontend package scripts when relevant.
+
+Avoid:
+- mixing unrelated cleanup into the fix
+- speculative refactors during an urgent bug fix
+- skipping the regression test unless the repo truly cannot express one
+- introducing extra indirection for a local issue

.claude/commands/symfony/hotfix.md

@@ -0,0 +1,20 @@
+Prepare and implement an urgent Signalist hotfix with the smallest safe change set.
+
+Production issue or urgent scope: `$ARGUMENTS`
+
+Workflow:
+1. Confirm the issue is truly urgent and production-facing.
+2. Reproduce or localize the failure quickly from logs, alerts, or the current diff.
+3. Identify the narrowest safe fix with the smallest blast radius.
+4. Prefer a dedicated `hotfix/...` branch if the current branch is shared or protected.
+5. Implement the minimal change only. No opportunistic refactor.
+6. Add the smallest regression coverage the repo can express.
+7. Run the narrowest relevant verification, then the broader checks required by the touched area.
+8. Prepare a Conventional Commit message and deployment notes.
+9. Ask for confirmation before any `git commit` or `git push`.
+
+Rules:
+- Speed matters, but correctness still beats panic.
+- If the real fix is large, prefer a safe containment change plus a follow-up task.
+- Keep the diff extremely narrow and easy to review.
+- Surface any skipped verification explicitly.

.claude/commands/symfony/improve-instructions.md

@@ -0,0 +1,42 @@
+Review the repository guidance and propose improvements to instruction files without editing them silently.
+
+Scope or context: `$ARGUMENTS`
+
+Target files:
+- `AGENTS.md`
+- `CLAUDE.md`
+- `.claude/rules/*.md`
+- `.claude/patterns.md`
+- `.claude/commands/symfony/*.md`
+- `.claude/skills/*/SKILL.md`
+
+Workflow:
+1. Inspect the current repository shape, quality gates, and recent workflow expectations.
+2. Look for instruction drift:
+   - repeated corrections in recent work
+   - `Makefile`, `composer.json`, `frontend/package.json`, or repo structure changes
+   - architecture or testing conventions no longer reflected in instructions
+   - duplicated or conflicting guidance
+3. Classify each candidate update:
+   - policy
+   - workflow
+   - pattern
+   - project fact
+   - temporary note
+4. Keep only durable, reusable updates. Ignore one-off preferences.
+5. Produce a proposed patch and rationale.
+6. Ask for confirmation before editing any instruction file.
+
+Rules:
+- Never edit instruction files silently.
+- `AGENTS.md` remains the canonical source of repository-specific rules.
+- `CLAUDE.md` must stay a thin pointer.
+- Update `.claude` files only when the improvement is reusable and not just project noise.
+- If commands and skills overlap, keep them aligned with the same underlying rules and patterns.
+
+Output format:
+- `Detected drift`
+- `Proposed updates`
+- `Why each update is useful`
+- `Patch preview`
+- `Confirmation request`

.claude/commands/symfony/new-feature.md

@@ -0,0 +1,44 @@
+Implement a new Signalist feature by mirroring the local repository patterns.
+
+User request: `$ARGUMENTS`
+
+Execution order:
+1. Run the equivalent of `/symfony:scan-project` if context is incomplete.
+2. Find one nearby example in the same backend or frontend area and mirror its structure.
+3. Implement the smallest coherent slice that satisfies the request.
+4. Write tests in the same session.
+5. Run the repository quality gates before reporting completion.
+
+Default expectations unless the repo clearly differs:
+- Follow SOLID principles pragmatically.
+- Prefer clean architecture and hexagonal boundaries when the surrounding code already uses them.
+- If API Platform already provides a direct, readable solution for the requested backend behavior, use the API Platform feature instead of adding extra layers.
+- If the existing frontend pattern already solves the behavior cleanly, reuse it instead of introducing a new client abstraction.
+- Keep API Platform resources, processors, controllers, hooks, and components thin.
+- Keep business logic in handlers, use-cases, domain services, or message handlers.
+- Keep repositories and infrastructure adapters focused on persistence or integration concerns.
+- Keep async boundaries explicit for RSS, AI, email, and sync work.
+- Prefer simple, readable code over clever or highly optimized code.
+- If performance and readability conflict and there is no measured bottleneck, choose readability.
+- Keep the result easy for a human reviewer to follow.
+
+Checklist:
+1. Confirm the target flow: API Platform native, handler-based write flow, async message flow, frontend flow, or a combination.
+2. Reuse existing naming and file placement conventions.
+3. Keep `declare(strict_types=1);` and modern PHP syntax where relevant.
+4. Add or update validation at the input boundary.
+5. Keep exceptions, HTTP error mapping, and frontend error behavior aligned with the existing project.
+6. Add the right tests:
+   - backend unit tests for behavior and orchestration
+   - integration tests when persistence or adapter behavior changes
+   - Behat tests when endpoint behavior changes
+   - frontend tests when UI behavior changes
+7. Verify with the commands exposed by `Makefile` and `frontend/package.json`.
+
+Avoid:
+- business logic in controllers, state processors, or large components
+- new dependencies without explicit approval
+- schema changes without explicit approval
+- adding hexagonal or CQRS indirection when API Platform or the existing frontend stack can solve the case directly and cleanly
+- premature optimization or indirection that hurts readability
+- project reshaping when the request only needs a local change

.claude/commands/symfony/prepare-commit.md

@@ -0,0 +1,37 @@
+Prepare a commit for the current changes using Conventional Commits and repo-aware verification notes.
+
+Scope or context: `$ARGUMENTS`
+
+Workflow:
+1. Inspect `git status`, the current branch, and the current diff.
+2. Stage the intended files with `git add`.
+3. Run the repository quality checks relevant to the current change, using the real project gates from `Makefile` and `frontend/package.json`.
+4. Review the change for correctness, architecture, validation, regressions, and test completeness.
+5. Review the change with a security lens: auth/authz, input validation, secrets, external calls, privacy, and data exposure.
+6. If the current branch is `main`, `master`, `develop`, or another protected/shared branch, create a dedicated branch before committing.
+7. Build a Conventional Commit message that matches the actual change scope.
+8. Prepare PR-ready notes that explain:
+   - what changed
+   - why it changed
+   - how it was implemented
+   - what was verified
+   - remaining risks or follow-up points
+9. Prepare a verification checklist based on the real project gates from `Makefile` and the frontend scripts.
+10. If the user explicitly asks to commit, ask for confirmation before running `git commit`.
+11. If the user explicitly asks to push, ask for confirmation before running `git push`.
+
+Rules:
+- Never commit or push silently.
+- Treat `git commit` and `git push` as confirmation-required actions even when the user previously asked for preparation work.
+- Stage only the files that belong to the intended change.
+- Prefer a short, accurate Conventional Commit title over a clever one.
+- Do not invent verification steps that do not exist in the repository.
+- If quality, review, or security checks reveal blockers, surface them before proposing the final commit.
+
+Output format:
+- `Pre-commit checks`
+- `Suggested branch`
+- `Suggested commit title`
+- `Suggested commit body`
+- `PR notes`
+- `Verification checklist`

.claude/commands/symfony/review-change.md

@@ -0,0 +1,29 @@
+Perform a structured code review for a Signalist change.
+
+Review scope: `$ARGUMENTS`
+
+If the scope is omitted, inspect the current git diff.
+
+Review checklist:
+1. Confirm the change respects the repository architecture and `AGENTS.md`.
+2. Check that API Platform resources, state processors, controllers, hooks, and components remain orchestration-focused.
+3. Check that business rules stay in handlers, domain services, or message handlers.
+4. Check validation at the backend input boundary and safe handling in the frontend.
+5. Check persistence, AI, RSS, and external integration code for leaked business logic or unsafe coupling.
+6. Check error handling and user-visible behavior consistency.
+7. Check test completeness for backend, API, and frontend behavior.
+8. Check that the change can pass the repo quality gates.
+
+Prioritize findings:
+- correctness bugs
+- security regressions
+- architectural regressions
+- missing validation or tests
+- maintainability issues
+
+Response format:
+- findings first, ordered by severity
+- then open questions or assumptions
+- then a short summary only if useful
+
+Do not focus on style nits already covered by formatters, ESLint, or static analysis unless they expose real risk.