Claude Code Slash-Commands for Magento 2 Workflows
Ready-to-paste slash-commands & hooks
Drop these into .claude/commands/ or .claude/settings.json and you have got the same workflow I use across every Magento project.
Each card is a real .md file. Click the body to expand, then copy. Or grab the whole library as one shell script.
Hooks live in .claude/settings.json under the hooks key. Merge each block into your existing matchers, do not duplicate event names.
Hooks run shell commands on your machine. Read each command before pasting: never trust a hook config you have not skimmed.
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.
- Recipes cookbook Copy-paste recipes that turn one prompt into shippable Magento code.
- 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.
- 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
Where do slash-commands live, and do they sync across machines?
Two scopes. Project: .claude/commands/, commits with your repo, syncs to teammates via git. User: ~/.claude/commands/, only on your laptop. The file is plain Markdown with optional YAML frontmatter for argument hints. Project commands win on name collisions. Rule of thumb: anything Magento-specific (/scaffold-feature, /add-graphql) goes in the project; anything personal (/explain-this, /summarise) goes in user. Don't put secrets in either, commands are plain text and end up in the prompt.
What does a good /scaffold-feature command look like for Magento?
Three sections. (1) Args: feature name, e.g. VendorRegistry. (2) Steps: explicit list, "Generate etc/module.xml, registration.php, etc/di.xml with the preference, the Api interface, the Repository, the Model, the ResourceModel, the Collection, an etc/db_schema.xml for the table, and a Setup/Patch/Data/Install stub." (3) Verify: "Run php -l on each PHP file, run bin/magento setup:upgrade, confirm the table exists." The verify step is what makes the command idempotent, without it you'll re-scaffold on top of an existing module and overwrite work.
I want a /write-mftf command, what should it know about my repo?
Three things, baked into the command body. (1) Where MFTF tests live in your repo, usually app/code/, but custom themes vary. (2) The command to run a single test: vendor/bin/mftf run . (3) The convention to extend Magento's built-in action groups, never write raw selectors. Sample body: "Generate an MFTF test for page.xml selectors. Output the test file, then run it." Time to first green test: 5 minutes.
Is there a built-in security-review slash-command worth installing?
Yes, the security-review skill ships with Claude Code (run /security-review). For Magento it covers the obvious: SQL string-concatenation, echo without escaping in phtml, missing CSRF tokens on form actions, ACL gaps in admin controllers, raw user input passed to bin/magento shell calls, hardcoded API keys. It will not catch the Magento-specific gotchas: missing _isAllowed(), observers running inside the order DB transaction, ObjectManager in non-setup code. For those, copy .claude/agents/code-reviewer.md from the module generator output, it knows the EQP checklist.
How do I auto-generate release notes from conventional commits?
Slash-command body: "Read git log v$(git describe --tags --abbrev=0)..HEAD --format=%s. Group by Conventional Commit type (feat, fix, perf, refactor, docs, chore). For each feat and fix, write a one-line user-facing description, not the commit subject, the impact. Output as Markdown with a ## Breaking changes section first if any commit body contains BREAKING CHANGE:." Combine with semantic-release for auto-tagging. Two minutes per release versus thirty manual.
Send a brief. Get a written quote in 24 hours.
Two paragraphs is enough: scope, price and timeline come back in writing.