Claude Code Recipes for Magento 2: Copy-Paste Cookbook
12 recipes I cook every week
Real Magento tasks. Each recipe gives you the working code AND the Claude prompt to regenerate it for your own module.
Paste this into Claude Code in your module root. Replace `Panth\\Demo` with your own vendor/module.
Keep going
- Learning paths Backend, Hyvä, DevOps, architect: pick the path that matches your role.
- Magento playground Safe sandbox recipes for plugins, observers, GraphQL, and UI components.
- Module anatomy Every Magento 2 module file, mapped and explained.
- Glossary 80+ Magento and Claude Code terms, defined without jargon.
- Prompt engineering Write prompts that produce Marketplace-pass Magento code.
- Anti-patterns Twelve ways AI-paired Magento work goes wrong, and the fixes.
- CLI sandbox Run Claude Code on Magento safely with Docker, hooks, and allowlists.
- Slash-commands Production slash-commands for Magento 2 workflows.
- 30-day roadmap Day-by-day plan to ship a Magento module with Claude Code.
- Code reviewer agent A drop-in Claude sub-agent that reviews Magento PRs for shippability.
Common questions
What does a "recipe" actually contain?
Each recipe is four blocks: (1) Goal, one sentence, e.g. "Add a vendor_sku attribute to the product entity"; (2) Prompt, the literal text you paste into Claude Code; (3) Files touched, the expected diff surface (e.g. etc/db_schema.xml, Setup/Patch/Data/, etc/extension_attributes.xml); (4) Verify, the exact CLI command(s) that prove it shipped (bin/magento setup:upgrade, then a SQL query or a REST call). If you can't write the verify step, the recipe isn't ready, you don't actually know what success looks like.
Walk me through the "scaffold a Service Contract" recipe.
Goal: turn a Resource Model into a Magento-style service contract. Prompt: "Generate Api/, Api/Data/, Api/Data/, plus the Model/ implementation, all wired in etc/di.xml with preference for the interface. Use the existing ResourceModel/ and ResourceModel/, do not change them." Files: 5. Verify: bin/magento setup:di:compile + vendor/bin/phpstan analyse Api Model + a quick REST GET /V1/ call after adding a webapi.xml route. Time: 10 minutes start to first green test.
How do I get Claude to write a useful MFTF test, not a brittle one?
Anchor on data and test fixtures, not on UI selectors. Prompt template: "Write an MFTF test that creates a SimpleProductFixture, adds it to the cart as a guest, places the order, and asserts the order is in Sales/Order grid by SKU. Use Magento_Catalog's built-in data entity and the storefront action groups; do not write new page.xml selectors." Then: vendor/bin/mftf run StoryName. The trick is forcing it to reuse Magento's published action groups (StorefrontAddSimpleProductToCartActionGroup, etc.), tests built on those survive Magento upgrades; tests built on raw CSS selectors break on the next patch release.
Hyvä component recipe, block, view-model, or both?
Both, always. Hyvä enforces the ViewModelInterface pattern hard: blocks are dumb (just getViewModel()), view-models hold the logic. Recipe prompt: "Generate Block/ extending Magento\Framework\View\Element\Template, a ViewModel/ implementing ArgumentInterface, the view/frontend/layout/ wiring the view-model as a argument, and the view/frontend/templates/ using Tailwind classes only, no Luma, no inline style." Verify: bin/magento cache:flush, load the page, view source, confirm zero data-mage-init attributes (that would be a Luma leak).
Recipe for adding a GraphQL mutation that hits an existing service contract?
Goal: expose VendorRepositoryInterface::save as a createVendor(input: VendorInput!): Vendor mutation. Files: etc/schema.graphqls (input type, payload type, mutation), Model/Resolver/CreateVendor.php (implements ResolverInterface, calls the repository, maps VendorInterface to the GraphQL output array). Auth: add @doc on the mutation and gate via the resolver checking $context->getExtensionAttributes()->getIsCustomer() for storefront-only. Verify: bin/magento cache:clean config graphql_query_resolver_cache, then run the mutation in a GraphQL IDE with a customer token. The resolver should be < 30 lines, if it's longer, business logic leaked out of the repository.
Send a brief. Get a written quote in 24 hours.
Two paragraphs is enough: scope, price and timeline come back in writing.