Spryker Documentation

Marketplace order invoice documents feature overview

Tue, 27 Oct 2026 10:49:25 +0000

{% include pbc/all/order-management-system/order-invoice-liability.md %} The *Marketplace order invoice documents* feature extends the [Order invoice documents](/docs/pbc/all/order-management-system/latest/base-shop/order-management-feature-overview/order-invoice-documents-overview.html) feature for marketplace shops. A marketplace order contains items of one or several merchants and, optionally, items the marketplace operator sells. Instead of one invoice for the whole order, the feature creates one invoice per merchant plus one invoice for the items without a merchant. Each invoice shows only the items, expenses, and totals of its merchant, together with the merchant's requisites, and merchants open their invoices in the Merchant Portal. The feature is provided by the `MerchantSalesInvoice` module. The `SalesInvoice` module stays unaware of merchants: `MerchantSalesInvoice` plugs into it through the plugin interfaces of the `SalesInvoiceExtension` module and stores the merchant of an invoice in the new `merchant_reference` column of the `spy_sales_order_invoice` table. Shops without `MerchantSalesInvoice` keep one invoice per order. ## How it works 1. A merchant ships items in the Merchant Portal. The merchant state machine runs the `ship` event, which moves the items of the marketplace order into the `shipped by merchant` state of the marketplace state machine. 2. Entering `shipped by merchant` triggers the `invoice-generate` event with the `MerchantInvoice/Generate` OMS command (`GenerateMerchantOrderInvoicesCommandPlugin`). The command groups the items of the event by merchant reference and asks `SalesInvoice` to generate one invoice per group. Items without a merchant reference form the operator's group. The `deliver` event of the subprocess then moves the items from `invoice generated` to `delivered`, and the `MarketplaceReturn` subprocess accepts `start-return` from `invoice generated` as well as from `shipped by merchant` and `delivered`. 3. `MerchantReferenceOrderInvoiceBeforeSavePlugin` stores the merchant reference of the group in the invoice. `MerchantOrderInvoiceExistenceCheckStrategyPlugin` makes sure that an order gets at most one invoice per merchant: a unique key on the order and the merchant reference backs the check. 4. When the invoice is rendered, in the email, on the Storefront, in the Back Office, or in the Merchant Portal, `MerchantOrderInvoiceRenderOrderExpanderPlugin` replaces the order in the template with a copy that contains only the items and expenses of the invoice's merchant and the totals of the [merchant order](/docs/pbc/all/order-management-system/latest/marketplace/marketplace-order-management-feature-overview/merchant-order-overview.html). It also adds the merchant to the invoice, so the template prints the merchant's name, registration number, and address. For the operator's invoice, the copy keeps the items and expenses without a merchant and recalculates the totals. 5. `MerchantOrderInvoicesExpanderPlugin` adds the merchant to every loaded invoice, so the Back Office **Documents** block shows a **Merchant** column, and the Storefront row shows the merchant through the `SoldByMerchantWidget`. ### Invoice per merchant order The invoice of a merchant is created on the merchant's first `shipped by merchant` transition and is rendered from the whole merchant order. If the merchant ships the items of one order in several shipments, the later shipments do not create another invoice: the invoice created with the first shipment already lists all items of the merchant in that order. This mirrors the base shop, where the whole order is invoiced at once. Items canceled after the invoice was created are not reflected; credit notes are not supported. The `MerchantInvoice/Generate` command also runs the manual `invoice-generate` event of the demo `DummyPayment01` process, so a Back Office user who triggers it on a marketplace order with the regular invoice payment method gets the same set of invoices: one per merchant plus one for the operator's items. ## Merchant Portal The order details page of the Merchant Portal shows a **Documents** card with the invoices issued for the merchant's part of the order: the reference, the issue date, and a **PDF** link. The link opens the invoice page in a new tab, in the Merchant Portal layout, with a **Save as PDF** button and the document in a frame. The page answers with a 404 page unless the merchant order belongs to the merchant of the logged in merchant user and the invoice belongs to that merchant order's merchant. Merchant users receive access to the page through the `merchant-sales-invoice` ACL bundle, which `MerchantSalesInvoiceMerchantAclRuleExpanderPlugin` adds to every merchant. Because the invoice is generated inside the Merchant Portal request that ships the items, `MerchantSalesInvoiceMerchantAclEntityRuleExpanderPlugin` grants merchant users the ACL entity rule to create, read, and update the invoices of their orders, and `MerchantSalesInvoiceAclEntityConfigurationExpanderPlugin` registers the invoice as a child of the order and allows the sequence number entity, so that the invoice reference can be generated. For details, see [View merchant order invoice documents in the Merchant Portal](/docs/pbc/all/order-management-system/latest/marketplace/view-merchant-order-invoice-documents.html). ## Back Office The **Documents** block of the order page lists every invoice of the order with its reference, date, merchant, and the **PDF** link. `MerchantOrderInvoiceSalesListBlockRendererPlugin` of `MerchantSalesInvoice` renders the block with the **Merchant** column and replaces the block plugin of `SalesInvoice`. The operator's invoice shows an empty **Merchant** cell. For details, see [View order invoice documents](/docs/pbc/all/order-management-system/latest/base-shop/manage-in-the-back-office/orders/view-order-invoice-documents.html). ## Storefront The **Documents** section of the order details page lists every invoice of the order. Each row shows the reference, the issue date, the merchant through the `SoldByMerchantWidget` of the `MerchantWidget` module, and the **PDF** link. Access follows the rules of the order details page; see [Order invoice documents feature overview](/docs/pbc/all/order-management-system/latest/base-shop/order-management-feature-overview/order-invoice-documents-overview.html#storefront). ## The document Each invoice renders the invoice template of your project. The template receives the narrowed order and the invoice with the merchant, so it can print the merchant's requisites next to the operator's header; the demo template prints the merchant's name, registration number, and the address from the merchant profile. For the template and the extension points, see [Customize the order invoice document](/docs/pbc/all/order-management-system/latest/base-shop/customize-the-order-invoice-document.html). ## Current constraints - One invoice per merchant order, created with the merchant's first shipment, plus one invoice for the items without a merchant. Shipments and partial deliveries do not get separate invoices. - Invoice references stay in one sequence for all merchants, for example `Invoice-12`, `Invoice-13`. - Every invoice is sent as its own invoice email, so the customer gets one email per merchant and one for the items without a merchant. The BCC recipients configured in `SalesInvoiceConfig::getOrderInvoiceBcc()` receive each email too; merchants receive no email. - Credit notes and delivery notes are not supported. - The unique key on the order and the merchant reference does not cover the operator's invoice, whose merchant reference is `NULL`, which matches the base shop behavior for all invoices.

Install the Order Management feature

Tue, 27 Oct 2026 10:49:25 +0000

{% include pbc/all/install-features/latest/install-the-order-management-feature.md %}

Install the Marketplace Order Invoice Documents feature

Tue, 27 Oct 2026 10:49:25 +0000

{% include pbc/all/install-features/latest/marketplace/install-the-marketplace-order-invoice-documents-feature.md %}

Install the Purchasing Control feature

Tue, 27 Oct 2026 08:19:49 +0000

This document describes how to install the [Purchasing Control feature](/docs/pbc/all/cart-and-checkout/latest/base-shop/feature-overviews/purchasing-control-feature-overview.html). ## Install feature core Follow the steps below to install the Purchasing Control feature core. ### Prerequisites To start feature integration, review and install the necessary features: | NAME | VERSION | INSTALLATION GUIDE | | --- | --- | --- | | Spryker Core | {{page.release_tag}} | [Install the Spryker Core feature](/docs/pbc/all/miscellaneous/latest/install-and-upgrade/install-features/install-the-spryker-core-feature.html) | | Company Account | {{page.release_tag}} | [Install the Company Account feature](/docs/pbc/all/customer-relationship-management/latest/base-shop/install-and-upgrade/install-features/install-the-company-account-feature.html) | | Checkout | {{page.release_tag}} | [Install the Checkout feature](/docs/pbc/all/cart-and-checkout/latest/base-shop/install-and-upgrade/install-features/install-the-checkout-feature.html) | | Approval Process | {{page.release_tag}} | [Install the Approval Process feature](/docs/pbc/all/cart-and-checkout/latest/base-shop/install-and-upgrade/install-features/install-the-approval-process-feature.html) | | Quotation Process | {{page.release_tag}} | [Install the Quotation Process feature](/docs/pbc/all/request-for-quote/latest/install-and-upgrade/install-features/install-the-quotation-process-feature.html) | {% info_block infoBox "Quotation Process" %} The Quotation Process feature is required only if you want buyers and agents to assign cost centers and budgets to quote requests. The `spryker/quote-request` and `spryker/quote-request-agent` modules are installed as dependencies of `spryker-feature/purchasing-control` in either case, but the Storefront quote request pages are only available with the Quotation Process feature installed. If you do not need this part of the feature, skip [Integrate cost centers with quote requests](#integrate-cost-centers-with-quote-requests). {% endinfo_block %} ### 1) Install the required modules ```bash composer require spryker-feature/purchasing-control:"^2.0.0" spryker/sales:"^11.83.0" spryker/sales-extension:"^1.15.0" spryker-shop/checkout-page:"^3.40.0" spryker-shop/company-page:"^2.36.0" spryker-shop/customer-page:"^2.77.0" spryker-shop/shop-ui:"^1.108.0" --update-with-dependencies --ignore-platform-req=ext-grpc ``` ### 2) Set up database schema and transfer objects Apply database changes and generate entity and transfer changes: ```bash console propel:install console transfer:generate ``` {% info_block warningBox "Verification" %} Make sure the following changes have been applied in the database: | DATABASE ENTITY | TYPE | EVENT | | --- | --- | --- | | spy_cost_center | table | created | | spy_cost_center_to_company_business_unit | table | created | | spy_budget | table | created | | spy_budget_consumption | table | created | | spy_quote.fk_cost_center | column | created | | spy_quote.fk_budget | column | created | | spy_sales_order.fk_cost_center | column | created | | spy_sales_order.fk_budget | column | created | Make sure the following changes have been applied in transfer objects: | TRANSFER | TYPE | EVENT | PATH | | --- | --- | --- | --- | | CostCenter | class | created | src/Generated/Shared/Transfer/CostCenterTransfer.php | | CostCenterCollection | class | created | src/Generated/Shared/Transfer/CostCenterCollectionTransfer.php | | CostCenterCriteria | class | created | src/Generated/Shared/Transfer/CostCenterCriteriaTransfer.php | | CostCenterConditions | class | created | src/Generated/Shared/Transfer/CostCenterConditionsTransfer.php | | CostCenterCollectionRequest | class | created | src/Generated/Shared/Transfer/CostCenterCollectionRequestTransfer.php | | CostCenterCollectionResponse | class | created | src/Generated/Shared/Transfer/CostCenterCollectionResponseTransfer.php | | CostCenterResponse | class | created | src/Generated/Shared/Transfer/CostCenterResponseTransfer.php | | CostCenterQuoteUpdateRequest | class | created | src/Generated/Shared/Transfer/CostCenterQuoteUpdateRequestTransfer.php | | CostCenterQuoteUpdateResponse | class | created | src/Generated/Shared/Transfer/CostCenterQuoteUpdateResponseTransfer.php | | Budget | class | created | src/Generated/Shared/Transfer/BudgetTransfer.php | | BudgetCollection | class | created | src/Generated/Shared/Transfer/BudgetCollectionTransfer.php | | BudgetCriteria | class | created | src/Generated/Shared/Transfer/BudgetCriteriaTransfer.php | | BudgetConditions | class | created | src/Generated/Shared/Transfer/BudgetConditionsTransfer.php | | BudgetCollectionRequest | class | created | src/Generated/Shared/Transfer/BudgetCollectionRequestTransfer.php | | BudgetCollectionResponse | class | created | src/Generated/Shared/Transfer/BudgetCollectionResponseTransfer.php | | BudgetResponse | class | created | src/Generated/Shared/Transfer/BudgetResponseTransfer.php | | BudgetConsumption | class | created | src/Generated/Shared/Transfer/BudgetConsumptionTransfer.php | | BudgetConsumptionCollection | class | created | src/Generated/Shared/Transfer/BudgetConsumptionCollectionTransfer.php | | BudgetConsumptionCriteria | class | created | src/Generated/Shared/Transfer/BudgetConsumptionCriteriaTransfer.php | | BudgetConsumptionConditions | class | created | src/Generated/Shared/Transfer/BudgetConsumptionConditionsTransfer.php | | Quote.idCostCenter | property | created | src/Generated/Shared/Transfer/QuoteTransfer.php | | Quote.idBudget | property | created | src/Generated/Shared/Transfer/QuoteTransfer.php | | Quote.costCenter | property | created | src/Generated/Shared/Transfer/QuoteTransfer.php | | Quote.budget | property | created | src/Generated/Shared/Transfer/QuoteTransfer.php | | Order.fkCostCenter | property | created | src/Generated/Shared/Transfer/OrderTransfer.php | | Order.fkBudget | property | created | src/Generated/Shared/Transfer/OrderTransfer.php | | Order.costCenter | property | created | src/Generated/Shared/Transfer/OrderTransfer.php | | Order.budget | property | created | src/Generated/Shared/Transfer/OrderTransfer.php | | OrderTableCriteria.costCenterIds | property | created | src/Generated/Shared/Transfer/OrderTableCriteriaTransfer.php | | OrderTableCriteria.budgetIds | property | created | src/Generated/Shared/Transfer/OrderTableCriteriaTransfer.php | {% endinfo_block %} ### 3) Set up data import Register the following data import plugins: | PLUGIN | SPECIFICATION | PREREQUISITES | NAMESPACE | | --- | --- | --- | --- | | CostCenterDataImportPlugin | Imports cost centers from `cost_center.csv`. Creates or updates cost centers by key, name, description, and active status. | None | SprykerFeature\Zed\PurchasingControl\Communication\Plugin\DataImport | | BudgetDataImportPlugin | Imports budgets from `budget.csv`. Resolves the cost center by key and creates or updates budgets by cost center and name. | None | SprykerFeature\Zed\PurchasingControl\Communication\Plugin\DataImport | | CostCenterToCompanyBusinessUnitDataImportPlugin | Imports cost center to company business unit relations from `cost_center_company_business_unit.csv`. Skips already existing relations. | None | SprykerFeature\Zed\PurchasingControl\Communication\Plugin\DataImport | **src/Pyz/Zed/DataImport/DataImportDependencyProvider.php** ```php */ protected function getDataImporterPlugins(): array { return [ // ... new CostCenterDataImportPlugin(), #PurchasingControlFeature new BudgetDataImportPlugin(), #PurchasingControlFeature new CostCenterToCompanyBusinessUnitDataImportPlugin(), #PurchasingControlFeature ]; } } ``` Create the CSV import files: **data/import/common/common/cost_center.csv** ```csv key,name,description,is_active cc-marketing,Marketing,Marketing and communications expenses,1 cc-it,IT & Operations,IT infrastructure and software licenses,1 ``` **data/import/common/common/budget.csv** ```csv cost_center_key,name,amount,currency_iso_code,starts_at,ends_at,enforcement_rule,is_active cc-marketing,Marketing Q2 2026,50000,EUR,2026-04-01,2026-06-30,warn,1 cc-it,IT Software Licenses 2026,100000,EUR,2026-01-01,2026-12-31,block,1 cc-it,IT Hardware Approvals 2026,200000,EUR,2026-01-01,2026-12-31,require_approval,1 ``` **data/import/common/common/cost_center_company_business_unit.csv** ```csv cost_center_key,business_unit_key cc-marketing,spryker_systems_berlin cc-it,spryker_systems_berlin ``` Import the data: ```bash console data:import purchasing-control-cost-center console data:import purchasing-control-budget console data:import purchasing-control-cost-center-to-company-business-unit ``` {% info_block warningBox "Verification" %} In the Back Office, under **Customers > Cost Centers**, make sure the imported cost centers and budgets are displayed. Make sure the cost centers are assigned to the expected business units. {% endinfo_block %} ### 4) Set up behavior Enable the following behaviors by registering the plugins. #### Set up Zed plugins | PLUGIN | SPECIFICATION | PREREQUISITES | NAMESPACE | | --- | --- | --- | --- | | ManageCostCentersPermissionPlugin | Grants permission to create, update, and manage cost centers. Assign this permission to company roles that should have access to Purchasing Control management pages. | None | SprykerFeature\Shared\PurchasingControl\Plugin\Permission | | BudgetCheckoutPreConditionPlugin | Validates the cart grand total against the remaining budget before checkout proceeds. Blocks checkout or triggers the approval flow depending on the budget enforcement rule. | None | SprykerFeature\Zed\PurchasingControl\Communication\Plugin\Checkout | | CostCenterOrderSaverPlugin | Saves the selected cost center and budget references to the sales order during checkout. | None | SprykerFeature\Zed\PurchasingControl\Communication\Plugin\Checkout | | ConsumeBudgetCheckoutPostSavePlugin | Records budget consumption immediately after the order is saved so the remaining budget balance is accurate for concurrent buyers. Does nothing when no budget is selected on the quote. | None | SprykerFeature\Zed\PurchasingControl\Communication\Plugin\Checkout | | CostCenterQuoteExpanderPlugin | Expands the quote with the default cost center assigned to the buyer's business unit when no cost center is already set. | None | SprykerFeature\Zed\PurchasingControl\Communication\Plugin\Quote | | CostCenterQuoteFieldsAllowedForSavingProviderPlugin | Adds `idCostCenter` and `idBudget` to the list of quote fields persisted to the database. | None | SprykerFeature\Zed\PurchasingControl\Communication\Plugin\Quote | | RestoreBudgetOnCancelOmsCommandPlugin | Restores the budget balance by deducting the amount of the canceled order items. Also deducts the shipment group total if all items in the group are canceled. | None | SprykerFeature\Zed\PurchasingControl\Communication\Plugin\Oms | | RestoreBudgetOnRefundOmsCommandPlugin | Restores the budget balance by deducting the refundable amount of the refunded order items. When refund with shipment is enabled, also deducts the shipment group expense refundable amount if all items in the group are refunded. | None | SprykerFeature\Zed\PurchasingControl\Communication\Plugin\Oms | | PurchasingControlAclEntityConfigurationExpanderPlugin | Grants global read, update, and delete access to `SpyBudgetConsumption` in the Merchant Portal ACL configuration. This lets the budget restore OMS commands adjust budget consumption when a merchant user triggers them. Required only for marketplace projects with the Merchant Portal. | None | SprykerFeature\Zed\PurchasingControl\Communication\Plugin\AclMerchantPortal | | CostCenterOrderExpanderPlugin | Expands `OrderTransfer` with the assigned cost center and company name, and with the assigned budget when present. Does nothing when no cost center is assigned to the order. | None | SprykerFeature\Zed\PurchasingControl\Communication\Plugin\Sales | | CostCenterSearchOrderExpanderPlugin | Expands each `OrderTransfer` in a list with `CostCenterTransfer` and `BudgetTransfer` when assigned. Used for order search results. | None | SprykerFeature\Zed\PurchasingControl\Communication\Plugin\Sales | | CostCenterOrderSearchQueryExpanderPlugin | Expands `QueryJoinCollectionTransfer` with `WHERE` conditions for `fk_cost_center` and `fk_budget` when filter fields of type `costCenter` or `budget` are present. | None | SprykerFeature\Zed\PurchasingControl\Communication\Plugin\Sales | | CostCenterOrdersTableQueryExpanderPlugin | Adds a `LEFT JOIN` from `spy_sales_order.fk_cost_center` to `spy_cost_center.id_cost_center` and exposes `cost_center_name` as a virtual column on the Back Office orders table query. | None | SprykerFeature\Zed\PurchasingControl\Communication\Plugin\Sales | | CostCenterOrdersTableHeaderExpanderPlugin | Inserts a **Cost Center** column before the **Actions** column in the Back Office orders table. | None | SprykerFeature\Zed\PurchasingControl\Communication\Plugin\Sales | | CostCenterOrdersTableFilterFormExpanderPlugin | Adds cost center and budget multi-select filter fields to the Back Office orders table filter form. Budget choices are loaded via AJAX filtered by the selected cost centers. | None | SprykerFeature\Zed\PurchasingControl\Communication\Plugin\Sales | | CostCenterOrdersTableCriteriaFilterExpanderPlugin | Filters the Back Office orders table by `costCenterIds` and `budgetIds` when present on `OrderTableCriteriaTransfer`. | None | SprykerFeature\Zed\PurchasingControl\Communication\Plugin\Sales | | CostCenterSalesTablePlugin | Normalizes the `cost_center_name` column to `-` for orders that have no cost center assigned. | None | SprykerFeature\Zed\PurchasingControl\Communication\Plugin\Sales | #### Set up permissions **src/Pyz/Zed/Permission/PermissionDependencyProvider.php** ```php */ protected function getPermissionPlugins(): array { return [ // ... new ManageCostCentersPermissionPlugin(), #PurchasingControlFeature ]; } } ``` **src/Pyz/Client/Permission/PermissionDependencyProvider.php** ```php */ protected function getPermissionPlugins(): array { return [ // ... new ManageCostCentersPermissionPlugin(), #PurchasingControlFeature ]; } } ``` Sync the permission plugins to the database: ```bash console sync:data permission ``` {% info_block warningBox "Verification" %} In the Back Office, under **Customers > Company Roles**, assign the **ManageCostCentersPermissionPlugin** permission to a company role. Make sure company users with that role can access the cost center management pages on the Storefront. {% endinfo_block %} {% info_block infoBox "Require Approval enforcement rule" %} If you configure budgets with the **Require Approval** enforcement rule, the following [Approval Process](/docs/pbc/all/cart-and-checkout/latest/base-shop/install-and-upgrade/install-features/install-the-approval-process-feature.html) permissions must be registered and assigned to company roles for the approval workflow to function: | PERMISSION | REQUIRES | | --- | --- | | Buy up to grand total (`PlaceOrderPermissionPlugin`) | Send cart for approval | | Send cart for approval (`RequestQuoteApprovalPermissionPlugin`) | Buy up to grand total | | Approve up to grand total (`ApproveQuotePermissionPlugin`) | None | For plugin registration details, see [Install the Approval Process feature](/docs/pbc/all/cart-and-checkout/latest/base-shop/install-and-upgrade/install-features/install-the-approval-process-feature.html). {% endinfo_block %} #### Set up Checkout plugins **src/Pyz/Zed/Checkout/CheckoutDependencyProvider.php** ```php */ protected function getCheckoutPreConditions(Container $container): array { return [ // ... new BudgetCheckoutPreConditionPlugin(), #PurchasingControlFeature ]; } /** * @param \Spryker\Zed\Kernel\Container $container * * @return list<\Spryker\Zed\Checkout\Dependency\Plugin\CheckoutSaveOrderInterface|\Spryker\Zed\CheckoutExtension\Dependency\Plugin\CheckoutDoSaveOrderInterface> */ protected function getCheckoutOrderSavers(Container $container): array { return [ // ... new CostCenterOrderSaverPlugin(), #PurchasingControlFeature ]; } /** * @param \Spryker\Zed\Kernel\Container $container * * @return list<\Spryker\Zed\CheckoutExtension\Dependency\Plugin\CheckoutPostSaveInterface> */ protected function getCheckoutPostHooks(Container $container): array { return [ // ... new ConsumeBudgetCheckoutPostSavePlugin(), #PurchasingControlFeature ]; } } ``` {% info_block warningBox "Verification" %} When a buyer places an order with a budget selected, verify the following: - Checkout is blocked when the order exceeds a budget with the **Block** enforcement rule. - An approval request is triggered when the order exceeds a budget with the **Require Approval** rule. - A warning is displayed when the order exceeds a budget with the **Warn** rule. - A `spy_budget_consumption` record is created after the order is successfully placed. - The cost center and budget IDs are saved on the `spy_sales_order` record. {% endinfo_block %} #### Set up Quote plugins **src/Pyz/Zed/Quote/QuoteDependencyProvider.php** ```php */ protected function getQuoteExpanderPlugins(): array { return [ // ... new CostCenterQuoteExpanderPlugin(), #PurchasingControlFeature ]; } /** * @return array<\Spryker\Zed\QuoteExtension\Dependency\Plugin\QuoteFieldsAllowedForSavingProviderPluginInterface> */ protected function getQuoteFieldsAllowedForSavingProviderPlugins(): array { return [ // ... new CostCenterQuoteFieldsAllowedForSavingProviderPlugin(), #PurchasingControlFeature ]; } } ``` {% info_block warningBox "Verification" %} When a buyer with an assigned business unit opens a cart, make sure the quote is automatically expanded with the default cost center of their business unit. Make sure `idCostCenter` and `idBudget` are persisted to the `spy_quote` table when the quote is saved. {% endinfo_block %} #### Set up Sales plugins **src/Pyz/Zed/Sales/SalesDependencyProvider.php** ```php */ protected function getOrderHydrationPlugins(): array { return [ // ... new CostCenterOrderExpanderPlugin(), #PurchasingControlFeature ]; } /** * @return array<\Spryker\Zed\SalesExtension\Dependency\Plugin\SearchOrderExpanderPluginInterface> */ protected function getSearchOrderExpanderPlugins(): array { return [ // ... new CostCenterSearchOrderExpanderPlugin(), #PurchasingControlFeature ]; } /** * @return array<\Spryker\Zed\SalesExtension\Dependency\Plugin\SearchOrderQueryExpanderPluginInterface> */ protected function getOrderSearchQueryExpanderPlugins(): array { return [ // ... new CostCenterOrderSearchQueryExpanderPlugin(), #PurchasingControlFeature ]; } /** * @return array<\Spryker\Zed\SalesExtension\Dependency\Plugin\OrdersTableQueryExpanderPluginInterface> */ protected function getOrdersTableQueryExpanderPlugins(): array { return [ // ... new CostCenterOrdersTableQueryExpanderPlugin(), #PurchasingControlFeature ]; } /** * @return array<\Spryker\Zed\SalesExtension\Dependency\Plugin\OrdersTableHeaderExpanderPluginInterface> */ protected function getOrdersTableHeaderExpanderPlugins(): array { return [ // ... new CostCenterOrdersTableHeaderExpanderPlugin(), #PurchasingControlFeature ]; } /** * @return array<\Spryker\Zed\SalesExtension\Dependency\Plugin\OrdersTableFilterFormExpanderPluginInterface> */ protected function getOrdersTableFilterFormExpanderPlugins(): array { return [ // ... new CostCenterOrdersTableFilterFormExpanderPlugin(), #PurchasingControlFeature ]; } /** * @return array<\Spryker\Zed\SalesExtension\Dependency\Plugin\OrdersTableCriteriaFilterExpanderPluginInterface> */ protected function getOrdersTableCriteriaFilterExpanderPlugins(): array { return [ // ... new CostCenterOrdersTableCriteriaFilterExpanderPlugin(), #PurchasingControlFeature ]; } /** * @return array<\Spryker\Zed\SalesExtension\Dependency\Plugin\SalesTablePluginInterface> */ protected function getSalesTablePlugins(): array { return [ // ... new CostCenterSalesTablePlugin(), #PurchasingControlFeature ]; } } ``` {% info_block warningBox "Verification" %} - In the Back Office, open **Sales > Orders**. Make sure the **Cost Center** column is displayed in the orders table. - Make sure the orders table filter form includes cost center and budget multi-select fields. - Open an individual order. Make sure the cost center and budget names are displayed on the order detail page. - In the storefront, open **My Account > Orders**. Make sure the cost center and budget data appear on completed orders. {% endinfo_block %} #### Set up Recurring Orders plugins {% info_block infoBox "Recurring Orders feature" %} This step is only required if your project uses the [Recurring Orders feature](/docs/pbc/all/order-experience-management/latest/base-shop/feature-overviews/recurring-orders-feature-overview.html). The plugins belong to the Purchasing Control module but register in the `OrderExperienceManagement` dependency providers. {% endinfo_block %} | PLUGIN | SPECIFICATION | PREREQUISITES | NAMESPACE | | --- | --- | --- | --- | | BudgetApprovalRuleRecurringOrderCheckoutValidatorPlugin | Blocks checkout when a quote being set up as a recurring order carries a budget with the `require_approval` enforcement rule. Applies regardless of the quote grand total and the remaining budget amount. Passes when no budget is selected or the budget uses another enforcement rule. | Recurring Orders feature | SprykerFeature\Zed\PurchasingControl\Communication\Plugin\OrderExperienceManagement | | CostCenterRecurringOrderApproveFormExpanderPlugin | Adds cost center and budget dropdowns to the recurring order review approve form and validates the selected pair server-side. | Recurring Orders feature | SprykerFeature\Yves\PurchasingControl\Plugin\OrderExperienceManagement | | CostCenterRecurringScheduleEditFormExpanderPlugin | Adds cost center and budget dropdowns to the recurring schedule edit form and validates the selected pair server-side. | Recurring Orders feature | SprykerFeature\Yves\PurchasingControl\Plugin\OrderExperienceManagement | **src/Pyz/Zed/OrderExperienceManagement/OrderExperienceManagementDependencyProvider.php** ```php */ protected function getRecurringOrderCheckoutValidatorPlugins(): array { return [ new BudgetApprovalRuleRecurringOrderCheckoutValidatorPlugin(), #PurchasingControlFeature ]; } } ``` For the two Yves form expander plugins and the budget enforcement rules that can be selected on the recurring order forms, see [Install the Recurring Orders feature](/docs/pbc/all/order-experience-management/latest/base-shop/install-and-upgrade/install-features/install-the-recurring-orders-feature.html). {% info_block warningBox "Verification" %} Set a budget's enforcement rule to **Require approval**, assign it to a cart, and set up that cart as a recurring order at checkout. Make sure checkout is blocked with a message stating that the selected budget requires approval and cannot be used for a recurring order. {% endinfo_block %} ### 5) Configure Back Office navigation Add the Purchasing Control section to the Back Office navigation: **config/Zed/navigation.xml** ```xml ... ... Cost Centers Cost Centers purchasing-control cost-center index ``` Rebuild the navigation cache: ```bash console navigation:build-cache ``` {% info_block warningBox "Verification" %} In the Back Office, under **Customers**, make sure the **Cost Centers** menu item is displayed and links to the cost center list page. {% endinfo_block %} ### 6) Configure the OMS process Register the OMS command plugins and configure the OMS process XML. #### Register OMS command plugins **src/Pyz/Zed/Oms/OmsDependencyProvider.php** ```php extend(self::COMMAND_PLUGINS, function (CommandCollectionInterface $commandCollection) { // ... $commandCollection->add(new RestoreBudgetOnCancelOmsCommandPlugin(), 'CostCenter/RestoreBudgetOnCancel'); #PurchasingControlFeature $commandCollection->add(new RestoreBudgetOnRefundOmsCommandPlugin(), 'CostCenter/RestoreBudgetOnRefund'); #PurchasingControlFeature return $commandCollection; }); return $container; } } ``` #### Configure the OMS process XML Add the `CostCenter/RestoreBudgetOnCancel` and `CostCenter/RestoreBudgetOnRefund` commands to the relevant events in your OMS process XML. The following example uses `DummyPayment01`: **config/Zed/oms/DummyPayment01.xml** ```xml ... ... ``` #### Grant Merchant Portal access to budget consumption In a marketplace, merchant users can cancel and refund order items from the Merchant Portal. The Merchant Portal applies ACL entity rules to every database query, so without explicit access, the `CostCenter/RestoreBudgetOnCancel` and `CostCenter/RestoreBudgetOnRefund` commands cannot update `spy_budget_consumption` and the budget is not restored. If your project does not use the Merchant Portal, skip this step. **src/Pyz/Zed/AclMerchantPortal/AclMerchantPortalDependencyProvider.php** ```php */ protected function getAclEntityConfigurationExpanderPlugins(): array { return [ // ... new PurchasingControlAclEntityConfigurationExpanderPlugin(), #PurchasingControlFeature ]; } } ``` #### Configure budget restoration behavior By default, shipment costs are not included when restoring the budget on refund. To include shipment costs, override `isRefundWithShipmentEnabled()` in your project config: **src/Pyz/Zed/PurchasingControl/PurchasingControlConfig.php** ```php */ protected function getGlobalWidgets(): array { return [ // ... CostCenterMenuItemWidget::class, #PurchasingControlFeature PurchasingControlSummaryWidget::class, #PurchasingControlFeature CostCenterSelectorWidget::class, #PurchasingControlFeature CostCenterDetailWidget::class, #PurchasingControlFeature CostCenterOrderDetailWidget::class, #PurchasingControlFeature CostCenterBudgetFilterWidget::class, #PurchasingControlFeature ]; } } ``` {% info_block infoBox "Where CostCenterDetailWidget is rendered" %} Unlike the other widgets in this table, no Purchasing Control template calls `CostCenterDetailWidget`. It renders only where another template calls it explicitly. In the demo shop, its single caller is the recurring order detail sidebar of the [Recurring Orders feature](/docs/pbc/all/order-experience-management/latest/base-shop/feature-overviews/recurring-orders-feature-overview.html). To display the assigned cost center and budget elsewhere—on the cart page or a quote detail page, for example—call the widget from that template: ```twig {% raw %}{% widget 'CostCenterDetailWidget' args [data.quote] only %}{% endwidget %}{% endraw %} ``` Pass a second argument to add a budget usage summary—the total, used, and remaining amounts, plus a used-percentage bar—below the cost center and budget names: ```twig {% raw %}{% widget 'CostCenterDetailWidget' args [data.quote, true] only %}{% endwidget %}{% endraw %} ``` The summary is rendered by the `recurring-order-budget-summary` molecule the module ships. It is omitted when the argument is `false` or not passed, and also when the quote carries no budget or no currency. {% endinfo_block %} {% info_block warningBox "Verification" %} - Make sure all six widgets are available in Twig templates. - On the storefront company dashboard, make sure the **Purchasing Control** summary widget displays cost center and budget data. - On the checkout summary page, make sure the cost center and budget selector is displayed. - On the order detail page, make sure the assigned cost center and budget names are displayed. - On the order history page, make sure the cost center and budget filter controls are displayed. - Call `CostCenterDetailWidget` from a template with a quote that has a cost center assigned, and make sure the cost center and budget names are displayed. Deactivate that cost center and make sure the names are no longer displayed. {% endinfo_block %} ### 3) Extend the ShopUi select component Extend the ShopUi `select` atom to render HTML attributes for the cost center and budget selectors: **src/Pyz/Yves/ShopUi/Theme/default/components/atoms/select/select.twig** ```twig {% raw %}{% block attributes %} {%- for attrname, attrvalue in attr | default({}) -%} {%- if attrvalue is same as(true) -%} {{ attrname }}="{{ attrname }}" {%- elseif attrvalue is not same as(false) -%} {{ attrname }}="{{ attrvalue }}" {%- endif -%} {%- endfor -%} {% endblock %}{% endraw %} ``` {% info_block warningBox "Verification" %} Make sure the cost center and budget dropdowns correctly disable unavailable options. Select a cost center and make sure the budget dropdown offers only the budgets of that cost center, and that budgets of other cost centers are both hidden and disabled. {% endinfo_block %} ### 4) Extend the checkout summary template Add the `CostCenterSelectorWidget` to the checkout summary page, placing it directly above the `QuoteApprovalWidget` call: **src/SprykerShop/CheckoutPage/src/SprykerShop/Yves/CheckoutPage/Theme/default/views/summary/summary.twig** ```twig

{% raw %}{% widget 'CostCenterSelectorWidget' args [data.cart] only %}{% endwidget %}{% endraw %} {% raw %}{% widget 'QuoteApprovalWidget' args [data.cart] only %}{% endwidget %}{% endraw %}

``` {% info_block warningBox "Verification" %} On the checkout summary page, make sure the cost center and budget selector is displayed above the approval widget. {% endinfo_block %} ### 5) Set up routes Register the following route provider plugins: | PLUGIN | SPECIFICATION | PREREQUISITES | NAMESPACE | | --- | --- | --- | --- | | CostCenterRouteProviderPlugin | Adds storefront routes for cost center list, create, update, and quote update actions. Also adds the POST-only routes that update the cost center and budget of a quote request in the customer and agent contexts. | None | SprykerFeature\Yves\PurchasingControl\Plugin\Router | | BudgetRouteProviderPlugin | Adds storefront routes for budget list, create, and update actions. | None | SprykerFeature\Yves\PurchasingControl\Plugin\Router | **src/Pyz/Yves/Router/RouterDependencyProvider.php** ```php */ protected function getRouteProvider(): array { return [ // ... new CostCenterRouteProviderPlugin(), #PurchasingControlFeature new BudgetRouteProviderPlugin(), #PurchasingControlFeature ]; } } ``` {% info_block warningBox "Verification" %} - Make sure the cost center list, create, and update pages are accessible under `/company/cost-center`. - Make sure submitting the cost center selector form in the cart updates the quote with the selected cost center and budget. - Make sure the budget list, create, and update pages are accessible. {% endinfo_block %} ### 6) Extend the order search form Register the following plugins to add cost center and budget filter fields to the storefront order history search form: | PLUGIN | SPECIFICATION | PREREQUISITES | NAMESPACE | | --- | --- | --- | --- | | CostCenterOrderSearchFormExpanderPlugin | Adds cost center and budget filter dropdowns to the order history search form. Only adds fields when the current customer is a company user. | None | SprykerFeature\Yves\PurchasingControl\Plugin\CustomerPage | | CostCenterOrderSearchFormHandlerPlugin | Maps selected cost center and budget IDs from the filter form to `FilterFieldTransfer` entries on `OrderListTransfer`. | None | SprykerFeature\Yves\PurchasingControl\Plugin\CustomerPage | **src/Pyz/Yves/CustomerPage/CustomerPageDependencyProvider.php** ```php */ protected function getOrderSearchFormExpanderPlugins(): array { return [ // ... new CostCenterOrderSearchFormExpanderPlugin(), #PurchasingControlFeature ]; } /** * @return array<\SprykerShop\Yves\CustomerPageExtension\Dependency\Plugin\OrderSearchFormHandlerPluginInterface> */ protected function getOrderSearchFormHandlerPlugins(): array { return [ // ... new CostCenterOrderSearchFormHandlerPlugin(), #PurchasingControlFeature ]; } } ``` {% info_block warningBox "Verification" %} On the storefront **My Account > Orders** page, make sure company users see cost center and budget filter dropdowns. Make sure filtering by cost center or budget returns the expected orders. {% endinfo_block %} ## Integrate cost centers with quote requests Follow the steps below to let buyers and agents assign a cost center and a budget to a quote request. Skip this section if you do not use quote requests. {% info_block infoBox "Prerequisites" %} This part of the feature requires the [Quotation Process](/docs/pbc/all/request-for-quote/latest/install-and-upgrade/install-features/install-the-quotation-process-feature.html) feature. {% endinfo_block %} ### 1) Install the required modules ```bash composer require spryker-shop/quote-request-page:"^3.8.0" spryker-shop/quote-request-agent-page:"^3.7.0" --update-with-dependencies ``` {% info_block warningBox "Verification" %} Make sure the following modules are installed at the specified versions or higher: | MODULE | EXPECTED VERSION | | --- | --- | | QuoteRequestPage | 3.8.0 | | QuoteRequestAgentPage | 3.7.0 | {% endinfo_block %} ### 2) Allow the cost center and budget quote fields for saving Add `ID_COST_CENTER` and `ID_BUDGET` to the quote fields that are persisted with a quote request version. Without this configuration, both fields are stripped when the quote request version is saved: the update appears to succeed, but the selection is lost. **src/Pyz/Zed/QuoteRequest/QuoteRequestConfig.php** ```php */ public function getQuoteFieldsAllowedForSaving(): array { return array_merge(parent::getQuoteFieldsAllowedForSaving(), [ // ... QuoteTransfer::ID_COST_CENTER, #PurchasingControlFeature QuoteTransfer::ID_BUDGET, #PurchasingControlFeature ]); } } ``` {% info_block warningBox "Verification" %} Assign a cost center and a budget to a quote request, then reload the quote request details page. Make sure the selection is still displayed. In the database, make sure `spy_quote_request_version.quote` contains the `idCostCenter` and `idBudget` values. {% endinfo_block %} ### 3) Set up widgets Register the following global widgets: | WIDGET | DESCRIPTION | NAMESPACE | | --- | --- | --- | | QuoteRequestCostCenterSelectorWidget | Renders the cost center and budget selection UI on the quote request details and quote request edit pages. Takes a `QuoteRequestTransfer` and an optional form action route name. When the route name is omitted, the form posts to `company/cost-center/update-quote-request`. | SprykerFeature\Yves\PurchasingControl\Widget | | QuoteRequestAgentCostCenterSelectorWidget | Renders the same selection UI on the agent quote request details and agent quote request edit pages. Takes the same two arguments. When the route name is omitted, the form posts to `agent/quote-request/cost-center/update`. | SprykerFeature\Yves\PurchasingControl\Widget | **src/Pyz/Yves/ShopApplication/ShopApplicationDependencyProvider.php** ```php */ protected function getGlobalWidgets(): array { return [ // ... QuoteRequestCostCenterSelectorWidget::class, #PurchasingControlFeature QuoteRequestAgentCostCenterSelectorWidget::class, #PurchasingControlFeature ]; } } ``` Both widgets are rendered from a `costCenter` block in the `quote-request-details.twig` and `quote-request-edit.twig` templates of the `QuoteRequestPage` and `QuoteRequestAgentPage` modules. In a project that uses these templates as they are shipped, no template changes are required. To change or remove the placement, override the `costCenter` block. {% info_block warningBox "Template overrides" %} If your project overrides any of the four templates, the widget is not rendered on the affected pages, because your override replaces the module template that contains the `costCenter` block. Re-base your overrides against the new module templates, or add the `costCenter` block to them. {% endinfo_block %} The second argument controls where the form returns to after saving. The details pages omit it, so the widget falls back to the details route. The edit pages pass it explicitly: the `QuoteRequestPage` edit template passes `company/cost-center/update-quote-request-from-edit`, and the `QuoteRequestAgentPage` edit template passes `agent/quote-request/cost-center/update-from-edit`. Pass a route name of your own only if you also register a route that returns to your page. {% info_block infoBox "Info" %} The widgets suppress themselves when there is nothing to show. An editable quote request renders the selection form only if at least one cost center is available to the owner's business unit. A quote request that is not editable displays the assigned cost center and budget as read-only. {% endinfo_block %} {% info_block warningBox "Verification" %} - On the Storefront, open a quote request in an editable status and make sure the cost center and budget selection is displayed on both the details page and the edit page. - Select a cost center and a budget, then submit the form. Make sure a success message is displayed and the page returns to the details page or the edit page, depending on where you started. - Open a quote request that is not editable and make sure the assigned cost center and budget are displayed as read-only, without a submit button. - As an agent, open a customer's quote request and make sure the cost center dropdown lists the cost centers of the customer's business unit, not your own. {% endinfo_block %} ### 4) Review the quote request routes The `CostCenterRouteProviderPlugin` that you registered in [Set up routes](#5-set-up-routes) adds the following routes. All of them accept `POST` requests only, and each one determines its own return page, so the redirect target cannot be supplied by the request. | ROUTE NAME | PATH | RETURNS TO | | --- | --- | --- | | `company/cost-center/update-quote-request` | `/company/cost-center/update-quote-request/{quoteRequestReference}` | Quote request details page | | `company/cost-center/update-quote-request-from-edit` | `/company/cost-center/update-quote-request-from-edit/{quoteRequestReference}` | Quote request edit page | | `agent/quote-request/cost-center/update` | `/agent/quote-request/cost-center/update/{quoteRequestReference}` | Agent quote request details page | | `agent/quote-request/cost-center/update-from-edit` | `/agent/quote-request/cost-center/update-from-edit/{quoteRequestReference}` | Agent quote request edit page | The two `-from-edit` routes are reached only when a widget receives a form action route name as its second argument. For details, see [Set up widgets](#3-set-up-widgets). The two agent routes are deliberately placed under `/agent/` so that they are covered by the agent firewall. {% info_block warningBox "Verification" %} - Make sure a `GET` request to any of the four paths is rejected. - Make sure a buyer cannot update the cost center of a quote request that belongs to another company user: the request must return `404`, the same response as for a quote request reference that does not exist. - Make sure an anonymous request to either agent path is rejected by the agent firewall. {% endinfo_block %}

Install the Workflows feature

Mon, 26 Oct 2026 15:30:43 +0000

This document describes how to install the Workflows feature. ## Prerequisites Install the required modules: | MODULE | VERSION | |--------|---------| | spryker/workflow | ^0.4.0 | | spryker/state-machine | ^2.26.0 | | spryker/data-import | ^1.27.1 | | spryker/gui | ^5.11.0 | | spryker/kernel | ^3.84.0 | | spryker/user | ^3.17.0 | ## Install feature core ### 1) Install the required modules Install the Workflow module and update its dependencies to the required versions: ```bash composer require spryker/workflow:"^0.4.0" --update-with-dependencies ``` {% info_block warningBox "Verification" %} Make sure the following modules are available in `vendor/spryker/`: | MODULE | |--------| | spryker/workflow | | spryker/state-machine | | spryker/data-import | | spryker/gui | | spryker/user | {% endinfo_block %} ### 2) Set up the database schema and transfer objects Apply the database changes and generate the transfer objects: ```bash docker/sdk cli console propel:install docker/sdk cli console transfer:generate ``` {% info_block warningBox "Verification" %} Make sure that the following tables exist in the database: | DATABASE ENTITY | TYPE | EVENT | |-----------------|------|-------| | spy_state_machine_process | table | created | | spy_state_machine_process_definition | table | created | | spy_state_machine_process_definition_instance | table | created | | spy_state_machine_process_definition_trigger | table | created | {% endinfo_block %} ### 3) Configure navigation The Workflow Back Office menu entry is added under **Administration**. Add the following node to `config/Zed/navigation.xml`: ```xml Workflows Workflows workflow process index ``` Rebuild the navigation cache: ```bash docker/sdk cli console navigation:build-cache docker/sdk cli console cache:empty-all ``` {% info_block warningBox "Verification" %} In the Back Office, go to **Administration > Workflows** and make sure the page opens. {% endinfo_block %} ### 4) Build the Back Office assets and translations The workflow builder and the action confirmation modal are part of the Back Office frontend assets, and the Workflow and Gui modules ship Back Office translations. Build the assets and generate the translation cache: ```bash docker/sdk cli console frontend:zed:build docker/sdk cli console translator:generate-cache ``` {% info_block warningBox "Verification" %} In the Back Office, go to **Administration > Workflows** and click **Create Workflow**. Make sure the visual builder is displayed and the page labels are translated. {% endinfo_block %} ### 5) Create a workflow in the Back Office Once the feature is installed, a Back Office user can author a workflow through the UI. The **Subject type** and **Triggers** fields list only the subject types and events provided by registered trigger plugins, so register at least one trigger plugin first. For details, see [Register command, condition, and trigger plugins](#register-command-condition-and-trigger-plugins). 1. Go to **Administration > Workflows** and click **Create Workflow**. 2. Enter a **Name** and, optionally, a **Description**. 3. Select a **Subject type**, then select one or more **Triggers** of that subject type. Triggers apply to all versions of the workflow. 4. In **Version 1**, draw the states and transitions in the visual builder and mark the initial state. To check the definition before saving, click **Validate**. 5. Click **Create workflow**. The workflow and its first version are created inactive. 6. Activate the version and the workflow. Each activation asks for confirmation. The workflow is now live: whenever a selected trigger event fires for a subject of the configured type, a new instance starts on the active version. To change the description or triggers later, open the workflow and click **Edit description and triggers**. To change the definition, click **New version**, then **Save as new version**. {% info_block infoBox "Provisioning instead of manual authoring" %} To ship a ready-made workflow with your project instead of creating it by hand, use the data import in the following steps. The two approaches are interchangeable — both produce the same process, versions, and triggers. {% endinfo_block %} ### 6) Register command, condition, and trigger plugins Register your project's commands, conditions, and start triggers by extending the core `WorkflowDependencyProvider`. **src/Pyz/Zed/Workflow/WorkflowDependencyProvider.php** ```php */ protected function getCommandPlugins(): array { return [ // new MyCommandPlugin(), ]; } /** * @return array<\Spryker\Zed\Workflow\Dependency\Plugin\WorkflowConditionPluginInterface> */ protected function getConditionPlugins(): array { return [ // new MyConditionPlugin(), ]; } /** * @return array<\Spryker\Zed\Workflow\Dependency\Plugin\StateMachineProcessTriggerPluginInterface> */ protected function getTriggerPlugins(): array { return [ // new MyProcessTriggerPlugin(), ]; } } ``` For the plugin interfaces and how the engine resolves them, see [Extending a workflow](/docs/pbc/all/back-office/latest/base-shop/workflows-feature-overview.html#extending-a-workflow). A trigger plugin only makes an event selectable in the Back Office. To start an instance when the event fires, your project also needs an event listener. For a complete example, see [Add a subject type to the Workflows feature](/docs/dg/dev/integrate-and-configure/add-a-subject-type-to-the-workflows-feature.html). ### 7) Register the data importer Register the Workflow data import plugin so workflows can be provisioned from CSV. **src/Pyz/Zed/DataImport/DataImportDependencyProvider.php** ```php use Spryker\Zed\Workflow\Communication\Plugin\DataImport\WorkflowDataImportPlugin; /** * @return array<\Spryker\Zed\DataImport\Dependency\Plugin\DataImportPluginInterface> */ protected function getDataImporterPlugins(): array { return [ new WorkflowDataImportPlugin(), ]; } ``` ### 8) Provide the import data The import uses two files: a definition XML file that describes the state machine (its states, transitions, and events, in the same `state-machine-01` format used by the OMS), and a CSV that provisions the workflow and points at that XML file. Storing the definition in its own file keeps the CSV readable and lets you edit the state machine like any other XML process. The `definition` column in the CSV holds the path to the XML file, relative to the project root. **data/import/common/common/workflow/company_onboarding.xml** ```xml {% raw %} {% endraw %} ``` **data/import/common/common/workflow.csv** ```csv name,subject_type,description,initial_state,version,definition,trigger_events,is_active CompanyOnboarding,Company,B2B company onboarding demo workflow,created,1,data/import/common/common/workflow/company_onboarding.xml,"Entity.spy_company.create,Entity.spy_company.update",1 ``` | COLUMN | REQUIRED | DESCRIPTION | |--------|----------|-------------| | name | yes | Workflow (process) name. | | subject_type | yes | The subject the workflow applies to, for example `Company`. | | description | no | Human-readable description. | | initial_state | yes | The state a new instance starts in. | | version | yes | Version number. The importer upserts on `(name, version)`, so re-imports do not create duplicates. | | definition | yes | Path to the definition XML file, relative to the project root — for example `data/import/common/common/workflow/company_onboarding.xml`. | | trigger_events | no | The Publish & Synchronize event names custom type of triggers that start an instance, for example `Entity.spy_company.create`. To list several events, separate them with commas and wrap the whole cell in double quotes so the commas are not read as CSV column separators: `"Entity.spy_company.create,Entity.spy_company.update"`. | | is_active | no | `1` activates this version and its process. | Run the importer directly to verify: ```bash docker/sdk cli console data:import workflow ``` ### 9) Add the importer to the install recipe Register the workflow importer in the data import configuration so it runs during deployment. Add it to the region import config that the install recipes invoke through `data:import`. Add the following entry to the import config of **every region and environment you deploy** — the local files (`data/import/local/full_.yml`) and the production files (`data/import/production/full_.yml`). Adding it to only one file provisions the workflow only for that region and environment. **data/import/local/full_EU.yml** (and the other `full_.yml` files, local and production) ```yaml - data_entity: workflow source: data/import/common/common/workflow.csv ``` Place the entry after the modules whose subjects the workflow attaches to (for example `company`), so those subjects exist before the workflow is provisioned. The install recipes already call `data:import` with the region import config, so no recipe change is required beyond this entry. {% info_block warningBox "Verification" %} Run the install recipe and make sure the workflow with its versions appears under **Administration > Workflows**. {% endinfo_block %} ### 10) Schedule the condition and timeout jobs Condition and timeout transitions have no event, so they must be advanced by two console commands: `workflow:check-condition` and `workflow:check-timeout`. These commands are **not** scheduled out of the box — register them as recurring jobs the same way the OMS and state machine checks are scheduled. Add the following jobs to `config/Zed/cronjobs/jenkins.php`: ```php $jobs[] = [ 'name' => 'workflow-check-conditions', 'command' => '$PHP_BIN vendor/bin/console workflow:check-condition', 'schedule' => '* * * * *', 'enable' => true, 'stores' => $allStores, ]; $jobs[] = [ 'name' => 'workflow-check-timeouts', 'command' => '$PHP_BIN vendor/bin/console workflow:check-timeout', 'schedule' => '* * * * *', 'enable' => true, 'stores' => $allStores, ]; ``` {% info_block warningBox "Verification" %} Start an instance, then run `docker/sdk cli console workflow:check-condition` and confirm the instance advances in `spy_state_machine_process_definition_instance`. {% endinfo_block %} ## Remove the demo workflow The [B2B Demo Marketplace](/docs/about/all/spryker-marketplace/marketplace-b2b-suite.html) ships with the Workflows feature installed and with a demo `ExampleWorkflow` module. The module provides the `CompanyOnboarding` workflow and example triggers for the `Company`, `Merchant`, `MerchantRelationship`, and `MerchantProduct` subject types. If your project does not need the demo workflow or the example triggers, remove them as follows. The Workflows feature itself stays installed. 1. Delete the `src/Pyz/Zed/ExampleWorkflow/` directory. 2. In `src/Pyz/Zed/Workflow/WorkflowDependencyProvider.php`, remove the `ExampleWorkflow` plugins from `getCommandPlugins()`, `getConditionPlugins()`, and `getTriggerPlugins()`. Add your own plugins instead. 3. In `src/Pyz/Zed/Event/EventDependencyProvider.php`, remove the `StateMachineCompanyEventSubscriber`, `StateMachineMerchantEventSubscriberPlugin`, `StateMachineMerchantRelationshipEventSubscriberPlugin`, and `StateMachineMerchantProductEventSubscriberPlugin` subscribers. 4. Remove the demo workflow data: the `workflow.csv` files and the `workflow/company_onboarding.xml` definitions in `data/import/common/common/`, `data/import/b2b_common/common/`, and `data/import/b2b_robot/common/`. To provision your own workflows, replace them with your files as described in [Provide the import data](#provide-the-import-data). 5. If you do not provision workflows through data import, remove the `workflow` entry from the `data/import/local/*.yml` and `data/import/production/*.yml` import configurations. 6. In `phpmd.xml`, remove the exclusion for `ExampleWorkflow`. The Propel `event` behavior on `spy_merchant_relationship` can stay: it only publishes entity events and does not depend on the demo module. {% info_block warningBox "Verification" %} Run the install recipe and make sure the following applies: - **Administration > Workflows** does not list the `CompanyOnboarding` workflow. - On the **Create workflow** page, **Subject type** lists only the subject types of your own trigger plugins. {% endinfo_block %}

Add a subject type to the Workflows feature

Mon, 26 Oct 2026 15:30:43 +0000

A workflow runs for one subject type, such as Company or Merchant. Subject types come from your project code: the Subject type field on the Create workflow page lists a subject type only after your project registers at least one trigger plugin for it.

This document describes how to add a subject type and start a workflow instance whenever an application event fires for it.

The steps use the MerchantRelationship subject type as an example. The same pattern applies to any entity in your project.

Prerequisites

Install the Workflows feature. For details, see Install the Workflows feature.

How a subject type is wired

Three pieces of project code connect an application event to a workflow:

PIECE	PURPOSE
Trigger plugin	Makes the subject type and its event selectable in the Back Office.
Event listener	Receives the application event and asks the Workflows feature to start an instance.
Event subscriber	Registers the listener for the event in the event dispatcher.

When the event fires, WorkflowFacade::startStateMachineInstance() finds every active workflow that has this event as a trigger and starts an instance on its active version. If an instance already exists for the same subject, no new instance is started.

1) Define the event and subject type

Keep the event name and the subject type in one place, so the trigger plugin and the listener use the same values.

src/Pyz/Zed/ExampleWorkflow/ExampleWorkflowConfig.php

<?php

namespace Pyz\Zed\ExampleWorkflow;

use Spryker\Zed\Kernel\AbstractBundleConfig;

class ExampleWorkflowConfig extends AbstractBundleConfig
{
    /**
     * Requires the Propel event behavior on spy_merchant_relationship.
     */
    public const EVENT_MERCHANT_RELATIONSHIP_CREATE = 'Entity.spy_merchant_relationship.create';

    public const SUBJECT_TYPE_MERCHANT_RELATIONSHIP = 'MerchantRelationship';
}

2) Enable entity events for the table

Entity.* events are published only for tables that have the Propel event behavior. If your event is an entity event and the table does not publish it yet, add the behavior in the project schema. Skip this step for events that a module already publishes, such as Merchant.created.

src/Pyz/Zed/MerchantRelationship/Persistence/Propel/Schema/spy_merchant_relationship.schema.xml

<table name="spy_merchant_relationship">
    <behavior name="event">
        <parameter name="spy_merchant_relationship_all" column="*"/>
    </behavior>
</table>

Apply the schema change:

docker/sdk cli console propel:install

3) Add the trigger plugin

The trigger plugin binds the event to the subject type. Its name and description are shown in the Triggers field on the Create workflow page.

src/Pyz/Zed/ExampleWorkflow/Communication/Plugin/StateMachine/MerchantRelationshipCreateStateMachineProcessTriggerPlugin.php

<?php

namespace Pyz\Zed\ExampleWorkflow\Communication\Plugin\StateMachine;

use Pyz\Zed\ExampleWorkflow\ExampleWorkflowConfig;
use Spryker\Zed\Kernel\Communication\AbstractPlugin;
use Spryker\Zed\Workflow\Dependency\Plugin\StateMachineProcessTriggerPluginInterface;

class MerchantRelationshipCreateStateMachineProcessTriggerPlugin extends AbstractPlugin implements StateMachineProcessTriggerPluginInterface
{
    public function getEventName(): string
    {
        return ExampleWorkflowConfig::EVENT_MERCHANT_RELATIONSHIP_CREATE;
    }

    public function getName(): string
    {
        return 'Merchant relationship created';
    }

    public function getSubjectType(): string
    {
        return ExampleWorkflowConfig::SUBJECT_TYPE_MERCHANT_RELATIONSHIP;
    }

    public function getDescription(): string
    {
        return 'Fired when a new merchant relationship is created.';
    }
}

src/Pyz/Zed/Workflow/WorkflowDependencyProvider.php

<?php

namespace Pyz\Zed\Workflow;

use Pyz\Zed\ExampleWorkflow\Communication\Plugin\StateMachine\MerchantRelationshipCreateStateMachineProcessTriggerPlugin;
use Spryker\Zed\Workflow\WorkflowDependencyProvider as SprykerWorkflowDependencyProvider;

class WorkflowDependencyProvider extends SprykerWorkflowDependencyProvider
{
    /**
     * @return array<\Spryker\Zed\Workflow\Dependency\Plugin\StateMachineProcessTriggerPluginInterface>
     */
    protected function getTriggerPlugins(): array
    {
        return [
            new MerchantRelationshipCreateStateMachineProcessTriggerPlugin(),
        ];
    }
}

4) Add the event listener

The listener receives the event and starts the workflow instance. The subject identifier is the ID of the created entity.

The listener needs WorkflowFacadeInterface. Provide the facade in the module’s dependency provider:

src/Pyz/Zed/ExampleWorkflow/ExampleWorkflowDependencyProvider.php

<?php

namespace Pyz\Zed\ExampleWorkflow;

use Spryker\Zed\Kernel\AbstractBundleDependencyProvider;
use Spryker\Zed\Kernel\Container;

class ExampleWorkflowDependencyProvider extends AbstractBundleDependencyProvider
{
    public const FACADE_WORKFLOW = 'FACADE_WORKFLOW';

    public function provideCommunicationLayerDependencies(Container $container): Container
    {
        $container = parent::provideCommunicationLayerDependencies($container);

        $container->set(static::FACADE_WORKFLOW, static function (Container $container) {
            return $container->getLocator()->workflow()->facade();
        });

        return $container;
    }
}

Expose it through the module’s communication factory:

src/Pyz/Zed/ExampleWorkflow/Communication/ExampleWorkflowCommunicationFactory.php

<?php

namespace Pyz\Zed\ExampleWorkflow\Communication;

use Pyz\Zed\ExampleWorkflow\ExampleWorkflowDependencyProvider;
use Spryker\Zed\Kernel\Communication\AbstractCommunicationFactory;
use Spryker\Zed\Workflow\Business\WorkflowFacadeInterface;

class ExampleWorkflowCommunicationFactory extends AbstractCommunicationFactory
{
    public function getWorkflowFacade(): WorkflowFacadeInterface
    {
        return $this->getProvidedDependency(ExampleWorkflowDependencyProvider::FACADE_WORKFLOW);
    }
}

Add the listener:

src/Pyz/Zed/ExampleWorkflow/Communication/Plugin/Event/Listener/StateMachineMerchantRelationshipEventListenerPlugin.php

<?php

namespace Pyz\Zed\ExampleWorkflow\Communication\Plugin\Event\Listener;

use Generated\Shared\Transfer\EventEntityTransfer;
use Generated\Shared\Transfer\StateMachineEventTriggerRequestTransfer;
use Pyz\Zed\ExampleWorkflow\ExampleWorkflowConfig;
use Spryker\Shared\Kernel\Transfer\TransferInterface;
use Spryker\Zed\Event\Dependency\Plugin\EventHandlerInterface;
use Spryker\Zed\Kernel\Communication\AbstractPlugin;

/**
 * @method \Pyz\Zed\ExampleWorkflow\Communication\ExampleWorkflowCommunicationFactory getFactory()
 */
class StateMachineMerchantRelationshipEventListenerPlugin extends AbstractPlugin implements EventHandlerInterface
{
    /**
     * @param string $eventName
     */
    public function handle(TransferInterface $transfer, $eventName): void
    {
        if (!$transfer instanceof EventEntityTransfer || $transfer->getId() === null) {
            return;
        }

        $this->getFactory()->getWorkflowFacade()->startStateMachineInstance(
            (new StateMachineEventTriggerRequestTransfer())
                ->setEventName(ExampleWorkflowConfig::EVENT_MERCHANT_RELATIONSHIP_CREATE)
                ->setSubjectType(ExampleWorkflowConfig::SUBJECT_TYPE_MERCHANT_RELATIONSHIP)
                ->setIdentifier((int)$transfer->getId()),
        );
    }
}

Register the listener as queued, so starting the workflow does not slow down the request that created the entity. Queued listeners run when the event queue is processed.

src/Pyz/Zed/ExampleWorkflow/Communication/Plugin/Event/Subscriber/StateMachineMerchantRelationshipEventSubscriberPlugin.php

<?php

namespace Pyz\Zed\ExampleWorkflow\Communication\Plugin\Event\Subscriber;

use Pyz\Zed\ExampleWorkflow\Communication\Plugin\Event\Listener\StateMachineMerchantRelationshipEventListenerPlugin;
use Pyz\Zed\ExampleWorkflow\ExampleWorkflowConfig;
use Spryker\Zed\Event\Dependency\EventCollectionInterface;
use Spryker\Zed\Event\Dependency\Plugin\EventSubscriberInterface;
use Spryker\Zed\Kernel\Communication\AbstractPlugin;

class StateMachineMerchantRelationshipEventSubscriberPlugin extends AbstractPlugin implements EventSubscriberInterface
{
    public function getSubscribedEvents(EventCollectionInterface $eventCollection)
    {
        $eventCollection->addListenerQueued(
            ExampleWorkflowConfig::EVENT_MERCHANT_RELATIONSHIP_CREATE,
            new StateMachineMerchantRelationshipEventListenerPlugin(),
        );

        return $eventCollection;
    }
}

src/Pyz/Zed/Event/EventDependencyProvider.php

<?php

namespace Pyz\Zed\Event;

use Pyz\Zed\ExampleWorkflow\Communication\Plugin\Event\Subscriber\StateMachineMerchantRelationshipEventSubscriberPlugin;
use Spryker\Zed\Event\EventDependencyProvider as SprykerEventDependencyProvider;

class EventDependencyProvider extends SprykerEventDependencyProvider
{
    public function getEventSubscriberCollection()
    {
        $eventSubscriberCollection = parent::getEventSubscriberCollection();

        $eventSubscriberCollection->add(new StateMachineMerchantRelationshipEventSubscriberPlugin());

        return $eventSubscriberCollection;
    }
}

Verification

In the Back Office, go to Administration > Workflows and click Create Workflow.
In Subject type, make sure MerchantRelationship is available. Select it and make sure Merchant relationship created is available in Triggers.
Create the workflow, then activate it and its version.
Create a merchant relationship and process the event queue.
Open the workflow’s active version and make sure a new instance for the merchant relationship appears in Workflow activity.

AI Dev SDK

Mon, 26 Oct 2026 09:25:38 +0000

Warning

Before you use AI-related tools, consult your legal department.

Overview

When you use AI tools to write code, they rely on general patterns, which leads to mistakes and requires you to repeatedly explain your project structure.

The AI Dev SDK makes your AI assistant Spryker-aware. It ships:

Skills and agents — packaged workflows for Spryker work: project setup, demo preparation, feature customization, bugfixing, upgrades, testing, and code review. See Workflows, Skills, and Agents.
Rules and a project context file — Spryker’s coding conventions, loaded when you work on the files they apply to, and your project’s specifics, loaded into every session.
An MCP server (MCP — Model Context Protocol, a standard that lets AI tools query external systems) — live access to your running application: transfer objects, module interfaces, order management system (OMS) state machines, and read-only database queries. See AI Dev MCP Server.

The SDK is delivered by the spryker-sdk/ai-dev module and, for Claude Code and GitHub Copilot CLI, by the spryker-ai-dev-sdk plugin. To set either of them up, see Installation.

How it works

The skills, agents, and rules are files installed into your AI tool’s directories — through the plugin (for Claude Code and GitHub Copilot CLI) or the ai-dev:setup console command (for other assistants). The assistant loads the context file into every session and each rule when you work on a file that the rule applies to. When you describe a task, it picks the matching skill and follows a tested Spryker workflow instead of improvising.

The MCP server covers what static files cannot: facts about your running application. It runs as a console command inside your project’s Docker container; when the assistant needs a transfer structure, an OMS transition, or a data check, it queries the server and works with your actual project state instead of assumptions.

The result: the generated code fits your project from the start, and you spend less time correcting mistakes and explaining Spryker concepts.

Key capabilities

Ready-made workflows

Six orchestrated workflows drive multi-step work end to end, and the profiler workflow turns the WebProfiler into hard numbers. They are all documented under Workflows, Skills, and Agents:

Project Starter Wizard — turn a fresh demoshop clone into your project
Demo Preparation Wizard — prepare a customer demo from the briefing to a handover report
Customization Workflow — build a feature from a product requirement document to a committed branch
Bugfix Workflow — drive a bug to a validated, QA-accepted fix
Upgrade Workflow — upgrade a customized project to a newer Spryker release
Profiler Workflow — read the Spryker WebProfiler as hard performance numbers
Architecture Workflow — turn project discovery into a filled architecture/ folder of arc42 sections and C4 diagrams

Spryker-aware code review

The spryker-code-reviewer agent checks changes against Spryker’s coding standards and layer architecture before they reach a pull request.

Faster Spryker-specific answers

AI can search Spryker documentation instead of requiring you to explain basic concepts or guessing how features work.

Smarter code generation

AI can look up your actual transfer objects, module dependencies, and interface methods so that the generated code matches your project structure instead of relying on assumptions.

OMS debugging made easy

AI can analyze your OMS flows to find possible next states, transitions, conditions, and timeouts for any order or state. This capability is especially helpful when you work with complex OMS schemas. You no longer need to manually follow arrows in large diagrams.

Working with complex data imports

AI can analyze, modify, and transform multi-column CSV files correctly. This task normally requires significant manual effort.

Database queries

AI can execute read-only database queries to inspect data when debugging issues.

Extensible for your project

You can extend the MCP server with custom plugins to add new tools — see Extension points. The shipped skills are plain Markdown files, so you can also use them as a template for your team’s own workflows.

Workflows, Skills, and Agents

Mon, 26 Oct 2026 09:25:38 +0000

Overview

The AI Dev SDK ships seven ready-made workflows, more than 30 skills, and six agents that codify common Spryker practice — from turning a demoshop clone into a customer project and preparing a customer demo, to building features, fixing bugs, and upgrading releases. Instead of teaching your AI assistant Spryker’s conventions prompt by prompt, you install workflows that already know them.

The skills and agents reach your project in two ways:

Via the ai-dev:setup console command — copies the skills and agents into your project’s AI-tool directories (.claude/skills/ + .claude/agents/, .windsurf/skills/ + .windsurf/agents/, and so on)
for every AI tool listed under Generated files per AI tool. Codex CLI has no agents directory, so agents are skipped for that tool.
Via the spryker-ai-dev-sdk plugin — for Claude Code and GitHub Copilot CLI users, the plugin installs the same skills and agents through the spryker-plugins-official marketplace, no console command required. Both coding agents install the same plugin. See Installation.

Both delivery paths read from the same source files — the plugin just packages them for marketplace installation.

What is the difference between a skill and an agent?

Skills load into the active chat on demand. Use them when you want the assistant to follow a specific workflow (write a product requirement document, refresh caches, run QA).
Agents are isolated sub-conversations the assistant delegates to. Use them when you want focused, single-purpose work done in its own context window (verify a behavior, diagnose a failure).

You do not need to remember the names — the assistant picks the right skill or agent from your prompt. The tables below explain what each one does so you know what to expect.

Available workflows and wizards

Seven shipped workflows cover the work most projects need on day one, so you get value before you write anything of your own. Each has its own page, listed under this one in the sidebar:

Workflow	Skill	What it does
Project Starter Wizard	`project-starter-wizard`	Turns a fresh demoshop clone into your project
Demo Preparation Wizard	`demo-prep-wizard`	Prepares a customer demo from the briefing to a handover report for the presenter
Customization Workflow	`spryker-customization`	Builds a feature from a product requirement document to a committed branch
Bugfix Workflow	`spryker-bugfix`	Drives a bug to a validated, QA-accepted fix
Upgrade Workflow	`spryker-upgrade`	Upgrades a customized project to a newer Spryker release
Profiler Workflow	`spryker-profiler`	Reads the Spryker WebProfiler as hard performance numbers
Architecture Workflow	`architecture-prep`	Turns project discovery into a filled `architecture/` folder

All but the Profiler Workflow are orchestrators: they own a full workflow and delegate each stage to the specialist skills and agents listed below. Alongside them, product-requirement-document turns a feature idea into a research-grounded spec, so you can go from idea to specification to implementation without leaving your assistant.

Composable by design

Each skill covers one stage of work and nothing more — research a feature, seed test data, run static validation, drive the running app, capture screenshots. Nothing is bundled into a single monolithic assistant, so you compose the stages into whatever long-running workflow your team actually runs.

This is how the orchestrator skills themselves are built. spryker-bugfix does not reimplement testing or validation — it calls codecept-functional, static-validation, code-review, and spryker-qa-coverage in sequence, and delegates isolated work to the agents. Your own workflows compose the same building blocks the same way.

Adapt the shipped workflows to your process. The six orchestrators are a baseline, not a prescription. Every team runs a different process — different review gates, different definition of done, different tracker. Because the stages are separate, you can reorder them, skip the ones you do not need, or drop your own stage in between. Ask for the workflow you want in your own words and the assistant assembles it from the installed skills.

Use the shipped skills as a template for your own. Every skill is plain Markdown with frontmatter, and every one ships a README documenting its flow, design decisions, and limits — linked in the Reference column of the tables below. Read the skill closest to what you need, then write your own the same way: your team’s release checklist, your onboarding walkthrough, your project-specific conventions. The result is AI-assisted development shaped by how your team works rather than by a fixed set of commands.

How to invoke

In most cases you do not need to call a skill or agent by name. Describe what you want — “build this feature”, “verify the new fee shows on the cart”, “write a product requirement document for…” — and the assistant matches your wording to the right skill or agent from the set installed in your project.

If you want to invoke one explicitly:

Plugin (Claude Code and GitHub Copilot CLI) — every skill is also available as a slash command, shown in the Command column below. Type the command (for example /spryker-ai-dev-sdk:spryker-customization) and the skill loads into the current chat.
Other AI tools — invocation follows the tool’s own convention for skills and agents. In Cursor, Windsurf, GitHub Copilot in an IDE, OpenCode, and Codex CLI, the skills and agents land in the tool-specific directories (.cursor/, .windsurf/, etc.) and are picked up automatically by your assistant. Generated files per AI tool lists the output paths per tool.
Agents (subagents) are not invoked by the user directly — they are spawned by the assistant or by a parent skill when the work calls for an isolated context. You can suggest one by name in your prompt (“use the spryker-verifier to…”), but the assistant decides when to spawn. On a plugin install, the agent name carries the plugin prefix: spryker-ai-dev-sdk:spryker-verifier in Claude Code, spryker-ai-dev-sdk/spryker-verifier in GitHub Copilot.

Skills

Skills are delivered through ai-dev:setup (all supported AI tools) or the plugin (Claude Code and GitHub Copilot CLI).

Every skill ships a README in its own directory in the plugin repository, covering its full flow, design decisions, and known limits. The Reference column links to it — use it when the summary here is not enough.

Orchestrator skills

These skills own a full workflow and delegate each stage to the specialist skills and agents below. Each has its own page.

Skill	Command	Purpose	Benefits	Reference
`project-starter-wizard`	`/spryker-ai-dev-sdk:project-starter-wizard`	Turn a fresh clone of a demoshop into the customer’s project	One developer interview up front, then nine orchestrated steps to a verified running shop; a resumable state file survives interruptions	README
`demo-prep-wizard`	`/spryker-ai-dev-sdk:demo-prep-wizard`	Prepare a customer demo on a demoshop clone: intake, requirements, design reference, harvest, build, check, and handover report	The preparer confirms the scope once and answers all questions in one sitting; every demo point is checked in the browser; the handover report has one row per requirement of the brief, with its status	README
`spryker-customization`	`/spryker-ai-dev-sdk:spryker-customization`	Walk a product requirement document or set of acceptance criteria through to a committed branch	One workflow drives the full build; quality bar (PoC or MVP) chosen up-front; never auto-commits	README
`spryker-bugfix`	`/spryker-ai-dev-sdk:spryker-bugfix`	Drive a bug from an optional tracker ticket or a plain description through to a committed, validated, QA-accepted fix	Orchestrates reproduce, root cause, minimal fix, functional test, static validation, review, QA, and final verification; a shared attempt budget loops back on any failed gate; Autonomous mode adds a pushed draft PR with a remote CI watch loop	README
`architecture-prep`	`/spryker-architecture:architecture-prep`	Turn project discovery into a filled `architecture/` folder of arc42 sections and C4 diagrams	Progressive questionnaire that asks only what the project’s shape requires; mines documents you already have before asking; writes what the answers support and names the rest as owned gaps	README
`spryker-upgrade`	`/spryker-ai-dev-sdk:spryker-upgrade`	Upgrade the project’s modules and features to a newer Spryker release	Checks first whether the customizations are covered by tests at all, resolves the constraint blockers that stop a release-group bump, then detects the silent damage a heavily customized project would otherwise ship; also updates the Docker SDK, the deploy files, and the developer tools, applies security and performance fixes, finds the release steps, and writes a report of the upgrade	README

Project setup skills

The project-starter-wizard runs these as its steps, and each also works standalone on an existing project.

Skill	Command	Purpose	Benefits	Reference
`project-ci-generator`	`/spryker-ai-dev-sdk:project-ci-generator`	Transform an inherited product-style CI setup into a single, lean project CI pipeline	Reads the CI that actually exists rather than applying a template; proposes a keep/drop plan for approval before deleting anything; ports the same jobs to GitLab or Bitbucket	README
`configure-codebase`	`/spryker-ai-dev-sdk:configure-codebase`	Register a custom namespace instead of `Pyz` and wire autoload, frontend build, and Codeception to resolve it	One pass covers every place the namespace must be declared, so the project builds, lints, and tests under its own name	README
`brand-project`	`/spryker-ai-dev-sdk:brand-project`	Apply or change the project’s brand identity — name, development domain, Docker namespace, palette, and logo	Repeatable any time, not only at project start; works pre- or post-boot	README
`configure-services`	`/spryker-ai-dev-sdk:configure-services`	Change what infrastructure the project runs on, or build a new environment deploy file	Surgical edits to the keys it owns; neighboring deploy-file blocks stay untouched	README
`define-stores`	`/spryker-ai-dev-sdk:define-stores`	Create or redefine a DMS project’s stores and region before the first boot	Clears the hardcoded store and locale literals that otherwise abort the boot	README
`project-data`	`/spryker-ai-dev-sdk:project-data`	Populate, reshape, reduce, clean up, or remove the project’s import data	One skill for every `data/import` change — adapt the demo shop to your stores, generate a catalog from images, or start with no demo data at all	README
`spryker-import-tools`	`/spryker-ai-dev-sdk:spryker-import-tools`	Read, filter, edit, and validate data import CSV files and manifests	Reliable where shell tools corrupt multi-line quoted fields; the `validate.php gate` command runs all data checks in one call and catches boot-aborting data in seconds	README
`boot-and-verify`	`/spryker-ai-dev-sdk:boot-and-verify`	Take a transformed project from “files written” to “verified running”	Per-store verification of storefront, Back Office, search, and queues; an independent verifier agent gives the verdict	README
`curate-golive-data`	`/spryker-ai-dev-sdk:curate-golive-data`	Make the data the project keeps production-safe before go-live	Resolves the go-live warnings the data and boot steps surface — placeholder tax rates, Spryker CDN imagery, demo accounts	README
`translate-content`	`/spryker-ai-dev-sdk:translate-content`	Translate storefront content into a project locale	Strictly per-locale and opt-in; covers glossary as well as catalog, CMS, navigation, and labels	README

Demo preparation skills

The demo-prep-wizard runs these as its phases, and each also works standalone.

Skill	Command	Purpose	Benefits	Reference
`demo-intake`	`/spryker-ai-dev-sdk:demo-intake`	Turn a customer briefing — a `.docx`, `.pdf` or `.txt` brief, a demo script, a reference URL, or a verbal brief — into structured input	Read-only on the source; states what is known, names where the data is, and marks every unanswered question	README
`harvest-source-materials`	`/spryker-ai-dev-sdk:harvest-source-materials`	Collect product data, product images, editorial images, and brand assets from the customer’s public site or a supplied export	Collects only what the demo needs, into a folder beside the project; records every limit of the collection	README
`match-reference-design`	`/spryker-ai-dev-sdk:match-reference-design`	Make the storefront look like a reference site — homepage composition, navigation, and CMS blocks	One change per cycle, each with a screenshot before and after; every step is reversible	README
`demo-run-sheet`	`/spryker-ai-dev-sdk:demo-run-sheet`	Write the demo handover report: environment, demo accounts, products, categories, demo points, what to watch out for, and how each part is built	Every link, login, price, and facet is read from the running shop and tested; HTML that keeps its format when pasted into a document, or Markdown	README

Development skills

Skill	Command	Purpose	Benefits	Reference
`ai-dev-setup`	`/spryker-ai-dev-sdk:ai-dev-setup`	Generate rules, an agents/context file, and skills for the project and the chosen AI tool	One command sets up consistent AI tooling for the whole team; detects the coding agent (Claude Code, GitHub Copilot CLI, VS Code) and writes the files it reads; also refreshes the rules and context file from the latest upstream content, or installs only the rules without Docker and Composer	README
`code-review`	`/spryker-ai-dev-sdk:code-review`	Review staged or PR changes against Spryker coding standards	Catches Spryker-specific issues before they reach a pull request	README
`propel-schema`	`/spryker-ai-dev-sdk:propel-schema`	Create and modify Propel ORM schema files	Follows Spryker schema conventions automatically	README
`data-import`	`/spryker-ai-dev-sdk:data-import`	Create and modify data import CSV files and importers	Generates importers that fit Spryker’s data-import path	README
`static-validation`	`/spryker-ai-dev-sdk:static-validation`	Run static analysis over only the code that changed against a base branch — PHP and frontend	Validates the diff rather than the whole project; groups PHP by changed file or by whole changed module	README
`payment-template`	`/spryker-ai-dev-sdk:payment-template`	Scaffold payment method integration	Follows Spryker payment module patterns end-to-end	README
`yves-atomic-frontend`	`/spryker-ai-dev-sdk:yves-atomic-frontend`	Create and override atomic design components for the Yves storefront — Twig, SCSS, and TypeScript	Components match the project’s atomic conventions; catches project-specific pitfalls such as an `index.ts` that replaces the core entry or a same-name component that silently shadows a core one	README
`backoffice-frontend`	`/spryker-ai-dev-sdk:backoffice-frontend`	Build or override Back Office pages — Zed Twig templates, navigation and ACL, and Back Office JavaScript and SCSS	Overrides extend core blocks instead of copying them; covers the cache warm-ups a new template, menu entry, or action needs before it shows up	README
`product-requirement-document`	`/spryker-ai-dev-sdk:product-requirement-document`	Turn a feature idea into a research-grounded product requirement document before any code is written	Spec-before-code; assigns a real Spryker actor to every story; cuts ambiguity before implementation	README
`spryker-refresher`	`/spryker-ai-dev-sdk:spryker-refresher`	Run the right post-change console and composer commands after edits	Owns the file-to-command mapping (codegen, caches, frontend builds, class-resolver); no missed cache rebuilds	README
`spryker-docs-research`	`/spryker-ai-dev-sdk:spryker-docs-research`	Look up the right answer in official Spryker documentation	Grounds AI work in documented behavior rather than the model’s memory; falls back gracefully when MCP tools are unavailable	README
`spryker-runtime`	`/spryker-ai-dev-sdk:spryker-runtime`	Drive the running Spryker application — Yves, Back Office, Merchant Portal, console, HTTP	Real authenticated sessions; read-only DB, Redis, and queue inspection; reusable building block for higher-level skills and agents	README
`ai-runtime-debugging`	`/spryker-ai-dev-sdk:ai-runtime-debugging`	Inspect Spryker runtime state safely from an AI session	`[AI-DEBUG]` tagged-log pattern plus optional XDebug step-debug; built-in cleanup of debug instrumentation before commit	README

Testing and performance skills

Skill	Command	Purpose	Benefits	Reference
`codecept-functional`	`/spryker-ai-dev-sdk:codecept-functional`	Generate Codeception functional tests	Tests follow Spryker test patterns out of the box	README
`cypress-tests`	`/spryker-ai-dev-sdk:cypress-tests`	Create, run, review, and validate Cypress end-to-end tests	Day-to-day E2E work against your project’s own suite — storefront, Back Office, Merchant Portal, and Glue API	README
`cypress-migration`	`/spryker-ai-dev-sdk:cypress-migration`	Replace Spryker’s demoshop test suites with a project-owned Cypress baseline	One-time migration; vendors in a proven reference implementation, wires up CI, and generates the companion `cypress-tests` skill for the project	README
`spryker-qa-coverage`	`/spryker-ai-dev-sdk:spryker-qa-coverage`	Turn acceptance criteria into a four-bucket test plan executed against the live app	Coverage goes beyond literal acceptance criteria — happy, negative, authorization, and corner cases; reports pass/fail with real evidence	README
`spryker-profiler`	`/spryker-ai-dev-sdk:spryker-profiler`	Read and configure the Spryker WebProfiler — every metric it recorded about a request	Real measurements instead of guesses; finds N+1 duplicates, Redis and search call counts, and the heaviest request; also fixes a profiler that shows no data	README

Agents

Agents are delivered through ai-dev:setup (every supported AI tool with an agents directory) or the plugin (Claude Code and GitHub Copilot CLI).

Each agent does one narrowly defined job in its own context and reports back — the “never” boundaries in the table are what make the results trustworthy.

Agent	Purpose	Benefits
`spryker-code-reviewer`	Review code against Spryker’s coding standards and architectural rules	Deeper, Spryker-aware review than a generic linter; catches layer-architecture and module-convention issues
`spryker-feature-expert`	Answer “how does feature X work in this project / in Spryker”	Pushes back when the user’s framing reinvents an existing primitive; surfaces canonical patterns first; never edits code
`spryker-verifier`	Verify that a specific behavior holds in the running Spryker environment	Returns PASS / FAIL / BLOCKED per acceptance criterion with raw evidence; never lies green; never tries to fix
`spryker-issue-diagnoser`	Investigate why something failed and return a root cause	Reads logs, DB state, queue, search, browser console — returns a suggested direction; never attempts the fix itself
`spryker-data-seeder`	Create small additive test data through Spryker’s existing import path	Safe and incremental — CSV + `data:import` only; never edits code, never writes directly to the database
`spryker-screenshot-collector`	Capture screenshots and GIFs of pages and flows for demos and documentation	Pure capture — never asserts whether something works, never investigates failures, never edits

Upgrade Workflow

Mon, 26 Oct 2026 09:25:38 +0000

Availability

The spryker-upgrade skill is available from spryker-sdk/ai-dev version 0.6.4, which ships version 0.4.0 of the spryker-ai-dev-sdk plugin. Plugin version 0.7.0 adds the tooling alignment and the performance fixes. Plugin version 0.8.0 adds the security fixes, the release steps check, and the handover report, and supports GitHub Copilot.

To update the plugin, run /plugin in Claude Code and update spryker-ai-dev-sdk from the spryker-plugins-official marketplace. In GitHub Copilot, run copilot plugin update spryker-ai-dev-sdk@spryker-plugins-official. For installation instructions, see Installation.

What the skill does

spryker-upgrade upgrades your project’s modules and features to a newer Spryker release. It is built for projects with heavy src/Pyz customization, where the dangerous part of an upgrade is not the code that stops compiling but the code that keeps running while doing nothing.

The skill combines an orchestrated workflow with a set of deterministic detector scripts. Each script is a standalone CLI that runs on host PHP using reflection or static parsing only, with no Spryker bootstrap — so they also work in CI.

Invoke it with “upgrade the project”, “update to the latest release”, or any request to bump spryker-feature/* or spryker/* packages.

For the full flow, the design decisions, and the known limits, see the spryker-upgrade README in the plugin repository.

Why silent damage is the real problem

Everything a Spryker project overrides fails quietly when core moves. A dead override still loads, a replaced plugin stack still boots, and a stale template still renders. Nothing errors — the customization simply stops taking effect.

The workflow therefore starts with a different question than “which modules changed”. It asks which of your customizations would notice if they stopped working, and whether the upgrade can be verified at all.

The phases

Preflight and baselines — boots the project before the upgrade and records snapshots of overrides, shadowed frontend files, constants, the Back Office pages, and the storage and search tables. It also records the existing test, PHPStan, and code style results, so that existing damage is not attributed to the upgrade. check-baselines.php blocks the next phase until all baselines exist.
Coverage check — measures your override surface against the tests that cover it, and offers to write characterization tests for the gaps. These must be written before the upgrade; written afterwards they pin the upgraded behavior and can no longer detect that it changed.
Target selection — reads the installed state from composer.lock, and reads the security release notes that Spryker published after the starting release.
Tooling, Docker SDK, and deploy files — updates the Docker SDK, the deploy files, and the developer tools (PHPStan, the evaluator, the code sniffer, Codeception) to the versions of the reference demo shop of the target release, each as its own commit.
Constraint resolution — relaxes patch-locked constraints, then resolves conflicts iteratively. Conflicts arrive in waves, each root bump revealing the next transitive layer.
Composer update — runs a full update in the container, then applies the security fixes. See Security fixes.
Detection — after Composer completes, runs the detectors that find the silent damage.
Resolution — merges shadowed files, rewires replaced plugin stacks, fixes broken configuration references, and requires a migration guide for every major module bump.
Boot and verify — boots the upgraded project, compares the storage and search tables with the baseline, regenerates the artifacts, and runs the full test suite in the booted environment.
New features — lists the new packages and the new capabilities of existing modules. You decide for each one: integrate now, defer, or never.
Performance fixes — checks the project against Spryker’s performance guidelines. See Performance fixes.
Page checks — checks the pages of the upgraded project in the browser.
Release steps — finds the commands that staging and production must run after the normal deployment. See Release steps.
Reports — writes a report for the developer and a handover report for the development team. See Reports.

The upgrade comes as two pull requests: the tests pull request first, then the upgrade pull request, which starts from it. Without new tests, there is only the upgrade pull request.

What the detectors find

Detector	Damage it catches
`check-test-coverage.php`	Customizations with no test over them, ranked by risk, with the test type that would catch each gap
`check-vendor-class-replacement.php`	Project files that declare a vendor namespace and replace a core class outright, so the vendor implementation never loads
`check-constraint-style.php`	Patch-locked or exactly pinned constraints that make a feature bump unresolvable
`check-typed-members.php`	Untyped overrides of constants and properties that core has since typed — a fatal on class load that aborts the console itself
`check-dead-overrides.php`	Project methods overriding a vendor method that the new version deleted, so the project logic stops being called
`twig-shadow-map.php`	Shadowed Twig, SCSS, and TypeScript files whose vendor counterparts changed upstream
`merge-shadowed-files.php`	Runs a three-way merge for every shadowed file and sorts the outcomes into clean, identical, conflicted, and removed
`check-plugin-usage.php`	Vendor plugins that are missing or deprecated after the upgrade, and project plugins implementing a removed interface
`check-config-constants.php`	Configuration referencing a vendor constants interface or constant that no longer exists, which breaks bootstrap of every application
`list-major-bumps.php`	Every major module bump, with a documentation search URL, changelog URL, and compare URL per package
`check-baselines.php`	Missing baselines before the upgrade starts, so every later comparison has something to compare with
`check-added-comments.php`	Explanatory comments and suppressions (`@phpstan-ignore`, `eslint-disable`, and others) added since the upgrade began
`check-platform-alignment.php`	A lock file resolved on a host that does not match the project’s image, and would not install there
`check-tooling-alignment.php`	Developer tools, the Docker SDK version, and the deploy files that do not match the reference demo shop of the target release
`check-constant-overrides.php`	Project constants that override a vendor constant whose value changed in the new version
`check-legacy-css-classes.php`	Legacy CSS classes that the vendor code still renders or selects
`storage-search-counts.php`	Storage and search tables that lost rows after the same import, compared before and after the upgrade
`backoffice-smoke.php`	Back Office navigation pages and table data endpoints that no longer answer — a vendor-to-vendor conflict can break many pages that the upgrade did not touch
`check-performance.php`	Performance guideline pages without a recorded fix or a reason, and fixes without a size, a status, or the developer’s decision
`resolve-constraints.php`	Runs Composer, parses root conflicts, raises the constraints the tree demands, and repeats
`unpin-feature-driven-modules.php`	Breaks a cohort deadlock, where a group of modules sharing a dependency must move together

The detectors keep their snapshots and reports in .spryker-upgrade/state/ inside the project, created self-gitignoring on first use.

Order matters

The dependency between the detectors is real. The skill runs them in the correct order — coverage and replacement checks first, then baselines and constraint preflight, then resolution, then post-Composer detection. Running them out of order wastes time on phantom findings.

Security fixes

The skill reads the security release notes that Spryker published after the starting release — for example, Security release notes 202610.0. For each issue, it checks the installed module version in composer.lock:

The module is below its fixed version — the skill raises the module’s constraint to the fixed version and updates it, as its own commit. When that does not resolve, the skill gives the developer the output of composer why-not.
The fix needs extra steps — a module update alone does not always fix an issue. The skill applies the code and configuration steps as their own commit. Steps for the environments go into the release steps.
The project overrides a file that the fix changed — the skill does not change the override, because that can change the shop’s behavior. The report lists the issue as not fixed, with the recommended fix for that file.

When the release notes cannot be read, the reports say that the security fixes are not checked.

Performance fixes

The skill reads Spryker’s performance guidelines as published on the day of the upgrade. For each guideline page, it records the fixes that apply to the project, or the reason why none applies. Each fix gets a size:

S — a configuration value or a flag. The skill applies it without asking.
M — a package update or a change in a few files.
L — a refactoring, a schema change, or a change in many files.

For the M and L fixes, you decide once for each fix: apply now, defer, or skip. A fix that changes the shop’s visible behavior is not applied; the report lists it as a recommendation. The skill applies one fix at a time, as its own commit, and reverts it when the checks fail. The deferred fixes go into the report’s performance backlog.

Release steps

Through the whole upgrade, the skill writes each release action into a log: a migration, an environment variable, a one-time command, a new job, or an action that a guide names — a migration guide, the integration guide of a new feature, a performance fix, or a security release note.

Then it checks the log locally. It deploys the upgrade branch onto a copy of the production state with only the normal deployment commands, and compares the result with a fresh installation of the upgrade branch. The database, Redis, and the search engine are compared. Each difference that a command fixes becomes a release step. Before the check, the skill asks which branch production runs, which commands the deployment runs, and whether it may reset the local data.

Reports

The skill writes two reports in .spryker-upgrade/state/:

The developer report — for the person who ran the upgrade: what is verified, what has not failed yet, the tests that were already red before the upgrade, the replaced deprecated plugins, and the performance fixes.
The handover report — for the development team that reviews, releases, and owns the result. The skill asks once for the format: Markdown, or HTML to paste into Confluence. It contains:
- An executive summary: the goal, what was done, the changes in behavior, the security fixes, and what happens next.
- Technical details: the pull requests, the upgrade per area, the behavior changes from replaced deprecated plugins, the database migrations, and the security fixes.
- Action items for the development team: the review, the local environment, the release steps for staging and production, and what was not done in this upgrade.
- The existing issues found during the upgrade, the performance guideline check, and the new Spryker features that the project can adopt.

Run the detectors in CI

Two detectors are cheap enough to gate every pull request, and both catch damage that is otherwise invisible until runtime:

php $UP/check-typed-members.php     # fatals on class load
php $UP/check-plugin-usage.php      # missing plugins

Neither needs a snapshot, a database, or a search backend — only an installed vendor/ directory. Failing the build on exit code 1 turns “the Back Office returns 500 after deploy” into a red pipeline.

For dependency-bumping pull requests, also wrap the change in a snapshot and verify pair for check-dead-overrides.php and twig-shadow-map.php, because those compare against pre-upgrade state and cannot work from a single point in time.

You can also gate check-test-coverage.php in CI, but gate it on a ratchet rather than on zero: fail when a pull request increases the number of untested overrides. New customization then arrives with a test, instead of the project needing a coverage project before anyone can merge.

Known limits

No detector covers Propel schema merges, glossary keys, ACL and navigation for new Back Office routes, or pure behavioral change. Those remain process gates and tests, and the skill marks them as such.

Published migration guides are also sometimes stale or absent, so the skill treats the tag diff, not the guide, as the source of truth.

Requirements

A Spryker project with Composer installed, and host PHP available to run the detector scripts
A running Docker environment of the project (docker/sdk)
An AI tool with the SDK’s skills loaded — either through the plugin in Claude Code or GitHub Copilot CLI, or via ai-dev:setup for another supported tool. See Installation.

Rules

Mon, 26 Oct 2026 09:25:38 +0000

The AI Dev SDK installs a set of Spryker-specific coding rules into your project. These rules guide the AI to follow Spryker conventions automatically, without requiring you to explain them in every prompt.

How the rules reach your project

When a session starts — in a Spryker project without the rules, the plugin offers once to install them. If you accept, the coding agent installs them. The offer does not show in CI, outside a Spryker project, or when the project has a .ai-dev/no-rules-sync file.
With the ai-dev-setup skill — the full setup installs the rules together with the project context file and the MCP server. Ask for “only the rules” to install only the rules; this flow needs no Docker environment and no Composer.
With the ai-dev:setup console command — for assistants without the plugin. See Set up with another assistant.

The rules go to the folder that your coding agent reads:

Coding agent	Rules folder	Scope by file path
Claude Code	`.claude/rules/<rule>.md`	`paths`
GitHub Copilot	`.github/instructions/<rule>.instructions.md`	`applyTo`

A refresh never overwrites a rule file that you changed. Commit the rule files, so that the whole team works with the same rules.

Rule files

Rule file	What it enforces
`business-models.md`	Business model structure and responsibilities
`client-zed-communication.md`	Client–Zed gateway communication patterns
`controller.md`	Controller conventions and responsibilities, including translatable flash messages
`dependency-provider.md`	Dependency provider wiring and plugin stacks
`enforce-constants-for-control-flow.md`	Use of constants instead of magic strings in control flow
`expander-pattern.md`	Expander pattern for extending transfer objects
`factory-pattern.md`	Factory class structure and dependency injection
`form-data-loading-performance.md`	Performant data loading in Zed forms
`layer-communication.md`	Cross-layer call rules (Presentation → Communication → Business → Persistence)
`mapper-pattern.md`	Mapper pattern for transfer-to-transfer and entity-to-transfer mappings
`merchant-portal-angular.md`	Merchant Portal Angular components: reuse of installed `@spryker/` UI components, project-side extension of core, and validation with the `mp:` scripts
`module-config.md`	Module configuration class conventions
`naming-conventions.md`	Class, method, and variable naming standards
`owasp.md`	OWASP security guidelines applied to Spryker code
`performance.md`	Performance best practices (query optimization, caching)
`persistence.md`	Persistence layer conventions (repositories, entity managers)
`php-code-style.md`	PHP code style rules (PSR compliance, formatting)
`plugins.md`	Plugin and plugin interface implementation patterns
`table.md`	Back Office table and query container conventions
`transfer-object.md`	Transfer object usage and immutability rules
`upgradability.md`	Backward compatibility and upgradability guidelines
`yves-frontend.md`	Yves storefront Twig, SCSS, and TypeScript: project-level overrides of core components, BEM and JavaScript hook conventions, and validation with the project’s npm lint scripts
`zed-backoffice-frontend.md`	Back Office Twig, JavaScript, SCSS, and navigation: overrides that extend core blocks, Bootstrap 5 markup, no new jQuery, translated text, safe escaping, and server-side ACL

Every rule is scoped by file path: the coding agent loads a rule only when you work on a file that the rule applies to.

Spryker Documentation

Marketplace order invoice documents feature overview

Install the Order Management feature

Install the Marketplace Order Invoice Documents feature

Install the Purchasing Control feature

Install the Workflows feature

Add a subject type to the Workflows feature

Prerequisites

How a subject type is wired

1) Define the event and subject type

2) Enable entity events for the table

3) Add the trigger plugin

4) Add the event listener

5) Subscribe the listener to the event

AI Dev SDK

Overview

How it works

Key capabilities

Ready-made workflows

Spryker-aware code review

Faster Spryker-specific answers

Smarter code generation

OMS debugging made easy

Working with complex data imports

Database queries

Extensible for your project

Workflows, Skills, and Agents

Overview

Available workflows and wizards

Composable by design

How to invoke

Skills

Orchestrator skills

Project setup skills

Demo preparation skills

Development skills

Testing and performance skills

Agents

Upgrade Workflow

Availability

What the skill does

Why silent damage is the real problem

The phases

What the detectors find

Security fixes

Performance fixes

Release steps

Reports

Run the detectors in CI

Known limits

Requirements

Rules

How the rules reach your project

Rule files