メニュー
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".
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Complete PrestaShop module development workflow using modern architecture and best practices. Use when: creating new PrestaShop modules, updating legacy modules to modern code, implementing hooks and actions, setting up module configuration pages, adding front office features, handling database operations, implementing security measures, managing translations, creating cart rules and vouchers, building Symfony console commands, or modernizing existing PrestaShop modules from legacy patterns to current standards.
Create the form page actions in the admin controller: create (add) and edit, plus any entity-specific actions. Uses FormBuilder/FormHandler pattern — never builds commands directly. Trigger: "create form actions for {Domain}", "create add/edit for {Domain}".
Create the repository in the Adapter layer. This is the ONLY class that touches the database — all handlers delegate to it. Covers multistore patterns with ShopConstraint when the entity requires it. Trigger: "create repository for {Domain}".
Create the form data flow layer: DataProvider (loads entity data for edit form), DataHandler (dispatches commands on create/update), error handling, and service registration. This bridges the form layer with the CQRS layer. Read Component/Forms/CONTEXT.md for conventions. Trigger: "create form data handling for {Domain}".
Create a multi-tab form layout using PrestaShop's NavigationTabType. This is a specific pattern for complex forms with many fields organized by tabs — NOT the default form layout. Most forms do not need tabs. Trigger: "create tab layout for {Domain} form", "add tabs to {Domain} form".
Create the Symfony form type for an 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. Trigger: "create form type for {Domain}".
| 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: form type + data handling + controller actions + form routes + form template + form JS |
| 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.
