Copy-paste recipes that turn one prompt into shippable Magento code.
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/<Patch>.php, 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.
Was this helpful?
Walk me through the "scaffold a Service Contract" recipe.
Goal: turn a Resource Model into a Magento-style service contract. Prompt: "Generate Api/<Entity>RepositoryInterface.php, Api/Data/<Entity>Interface.php, Api/Data/<Entity>SearchResultsInterface.php, plus the Model/<Entity>Repository.php implementation, all wired in etc/di.xml with preference for the interface. Use the existing ResourceModel/<Entity> and ResourceModel/<Entity>/Collection, do not change them." Files: 5. Verify: bin/magento setup:di:compile + vendor/bin/phpstan analyse Api Model + a quick REST GET /V1/<entity>/{id} call after adding a webapi.xml route. Time: 10 minutes start to first green test.
Was this helpful?
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.
Was this helpful?
Hyva component recipe — block, view-model, or both?
Both, always. Hyva enforces the ViewModelInterface pattern hard: blocks are dumb (just getViewModel()), view-models hold the logic. Recipe prompt: "Generate Block/<Name>.php extending Magento\Framework\View\Element\Template, a ViewModel/<Name>.php implementing ArgumentInterface, the view/frontend/layout/<handle>.xml wiring the view-model as a argument, and the view/frontend/templates/<name>.phtml 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).
Was this helpful?
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.
Was this helpful?
Request a quote
I'll reply within 2-4 hours business with a written quote and timeline.
