// Step-by-step orchestrator for migrating a PrestaShop Legacy admin page to Symfony/CQRS. Covers the full lifecycle from audit to GA. Trigger: "migrate the Xxx admin page", "create CQRS for Xxx", "add a Symfony form for Xxx", "migrate AdminXxxController".
Pair the core PR with a ps_apiresources fork branch for coordinated review, or revert that pairing to upstream dev-dev once both PRs are merged. Edits composer.json (repository URL + dev-<branch> pin) and refreshes composer.lock. Trigger: "pair core with ps_apiresources branch", "link ps_apiresources fork branch", "use my ps_apiresources fork in the core PR", "revert ps_apiresources to dev-dev", "unlink the ps_apiresources fork".
Configure modules/ps_apiresources as a development-ready git checkout (symlink to existing local clone or fresh clone with upstream + fork remotes), then provision the local test DB. Trigger: "set up ps_apiresources for development", "develop on the API module", "fix the API integration tests", "work on ps_apiresources locally".
Create the Symfony form type for a CRUD (identifiable) entity's add/edit form. Covers standard field types, translatable fields, money fields, file uploads, and choice providers. For multi-tab layout with NavigationTabType, see create-form-tab-layout. For settings/configuration forms, see create-settings-form. Trigger: "create CRUD form type for {Domain}".
Create a PrestaShop settings form (options block writing to ps_configuration): DataConfiguration + FormDataProvider + FormType + 4 YAML service entries (base Handler reused, never subclassed). For CRUD entity forms, use create-crud-form-type instead. Trigger: "create settings form for {Page}", "add options block for {Page}", "migrate fields_options for {Page}".
Generates a CONTEXT.md file for a PrestaShop shared component inside the `.ai/Component/` folder. Trigger this skill when the user asks to "generate a context for [Component]", "document the [X] component", "fill in the CONTEXT.md for [Component]", or when working inside `.ai/Component/` directories. Components live under `src/Core/{Name}/` and/or `src/Adapter/{Name}/` — they are shared infrastructure, not business domains. Examples: Grid, Form, Hook, CQRS, Translation, Router.
Create form page actions in the admin controller. Covers both patterns: CRUD (create/edit via FormBuilder + FormHandler pair) and settings (index + save via the base FormHandler). Never builds commands directly. Trigger: "create form actions for {Domain}", "create add/edit for {Domain}", "create settings save action for {Page}".
| name | legacy-to-symfony-migration |
| description | Step-by-step orchestrator for migrating a PrestaShop Legacy admin page to Symfony/CQRS. Covers the full lifecycle from audit to GA. Trigger: "migrate the Xxx admin page", "create CQRS for Xxx", "add a Symfony form for Xxx", "migrate AdminXxxController". |
Read @.ai/Component/Migration/CONTEXT.md for conventions, reference pages, dependency graph, and conditional activation matrix.
This skill is an orchestrator: each step file explains why the step exists, when to enter it, what gates it, and which standalone skills to invoke. The procedural detail lives in the standalone skills themselves and in the relevant Component CONTEXT.md.
Trigger when asked to:
When the parent agent supports sub-agents (Claude Code does; other tools currently do not), step-00 audits are particularly suited to delegation: each audit reads a large legacy file and emits a structured artifact, so the parent can offload the read cost without losing context. The migration manifest synthesises both audits and acts as the shared context surface for every later step. Skills tagged subagent: recommended or subagent: optional in their frontmatter are candidates; tools without a sub-agent primitive simply run them in-line — behaviour is identical from the user's standpoint.
| # | File | Title | Deliverable |
|---|---|---|---|
| 0 | step-00-audit.md | Audit | Field map, action list, milestone decision |
| 1 | step-01-feature-flag.md | Feature Flag | feature_flag.xml entry (beta/state=0) — set up early so handlers can carry conditional code |
| 2 | step-02-domain-layer.md | Domain Layer | Commands, Queries, ValueObjects, Exceptions, Handler interfaces |
| 3 | step-03-adapter-layer.md | Adapter Layer | Repository, Handlers, DI registration |
| 4 | step-04-behat-tests.md | Behat Tests | Integration test coverage for CQRS — gate before UI work |
| 5 | step-05-listing-page.md | Listing page (vertical slice) | Working listing page: grid + controller actions + listing routes + index template + listing JS |
| 6 | step-06-form-page.md | Form page (vertical slice) | Working add/edit page (CRUD) and/or options block (settings) — branches on form type per block. See the step file for the settings vs CRUD skill chain. |
| 7 | step-07-playwright-tests.md | Playwright Tests | UI test campaigns per feature area |
| 8 | step-08-general-availability.md | General Availability | Promote flag to stable; optional upgrade SQL handoff |
| 9 | step-09-removal.md | Removal | Track legacy controller removal in next major |
Listing-first is the conventional default — it unblocks bulk operations earlier and is usually simpler than the form. Form-first is valid when listing is already migrated or out of scope. Whichever runs first creates the controller class and routing file; the other extends them.