Chat on WhatsApp
  • Sign In
  • Create an Account
Toggle Nav
My Cart
Account
Back to /claude
Claude code cluster

Claude Code Slash-Commands for Magento 2 Workflows

Slash-commands turn repeated prompts into one-keystroke workflows. Twenty Magento-aware commands you can drop into .claude/commands/ today — scaffold features, write MFTF tests, generate release notes, gate security review.

Claude Code library

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.

More in the cluster

Keep going

FAQ

Common questions

Where do slash-commands live, and do they sync across machines?

Two scopes. Project: .claude/commands/<name>.md — commits with your repo, syncs to teammates via git. User: ~/.claude/commands/<name>.md — 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<Feature>Seed.php 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/<Vendor>/<Module>/Test/Mftf/Test/<StoryName>Test.xml, but custom themes vary. (2) The command to run a single test: vendor/bin/mftf run <StoryName>. (3) The convention to extend Magento's built-in action groups, never write raw selectors. Sample body: "Generate an MFTF test for <arg>. Use only Magento_*, Hyva_*, or our existing action groups; do not introduce new 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.