From magento2-commerce
Applies PHP design patterns including Repository, Factory, Strategy, Decorator, Observer, Singleton, Builder, Proxy, Composite, and DI. For PHP apps and Magento.
npx claudepluginhub orcaqubits/agentic-commerce-skills-plugins --plugin magento2-commerceThis skill is limited to using the following tools:
**Fetch live docs**: Web-search `php design patterns examples` for current community patterns and best practices. For Magento-specific patterns, web-search `site:developer.adobe.com commerce php development components`.
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
Fetch live docs: Web-search php design patterns examples for current community patterns and best practices. For Magento-specific patterns, web-search site:developer.adobe.com commerce php development components.
Creates objects without exposing instantiation logic. In Magento, auto-generated Factory classes (SomeModelFactory) create non-injectable objects via $factory->create().
When to use: When you need new instances (entities, models) rather than shared singletons. When the caller shouldn't know the concrete class.
Constructs complex objects step by step. Magento's SearchCriteriaBuilder, FilterBuilder, SortOrderBuilder follow this pattern.
When to use: When object construction requires many optional parameters or multi-step assembly.
Single instance shared across the application. Magento's Object Manager shares instances by default. Explicit singleton is generally an anti-pattern — prefer DI container sharing.
When to use: Rarely — let the DI container manage instance sharing.
Delays instantiation of resource-intensive dependencies. Magento auto-generates Proxy classes (SomeClass\Proxy) that create the real object only when a method is called.
When to use: When a class injects a heavy dependency it doesn't always use.
Wraps an object to add behavior without modifying the original. Used in Magento composite components and cache decorators.
When to use: When you need to add behavior to an object dynamically without subclassing.
Treats individual objects and compositions uniformly. Magento's UI component tree and layout container system follow this pattern.
When to use: When you have tree-structured data or components.
Defines a family of algorithms, encapsulates each one, makes them interchangeable. Magento shipping carriers and payment methods are strategy implementations.
When to use: When you have multiple algorithms for the same task and want runtime selection.
Defines a one-to-many dependency. When one object changes state, all dependents are notified. Magento's event/observer system is a direct implementation.
When to use: When changes in one object should trigger actions in others without tight coupling.
Mediates between domain and data mapping layers. Magento's repository interfaces (ProductRepositoryInterface) centralize all data access through a clean API.
When to use: Always — for any data access beyond simple reads. It's the standard Magento pattern.
Encapsulates a request as an object. Magento's Payment Gateway Command pattern uses this — authorize, capture, refund are separate command objects.
When to use: When you need to parameterize, queue, or log requests.
Objects receive their dependencies through constructors rather than creating them. Magento's DI container (Object Manager + di.xml) is the foundation of the entire framework.
When to use: Always — it's the core pattern. Inject interfaces, not concrete classes.
Defines an application's boundary with a layer of services that encapsulates business logic. Magento's Service Contracts (interfaces in Api/) form this layer.
When to use: Always — expose module functionality through service interfaces.
Simple objects that carry data between processes. Magento's Data Interfaces (Api/Data/) are DTOs — they have getters/setters but no business logic.
When to use: When passing data across architectural boundaries (API, service layer).
new (use factories or DI)Fetch current framework documentation for exact interface signatures and implementation patterns before applying.