spryker-ai-dev-sdk

Plugin spryker-ai-dev-sdk from marketplace spryker-plugins-official in spryker-sdk/ai-dev. Commands read from the repo's manifest — 3 days ago.

Skills (37)

• ai-dev-setup

  Sets up the Spryker AI Dev SDK in a Spryker project. Covers three related flows: first-time onboarding (installs the Composer package, wires console commands, registers the MCP server with the coding agent in use, installs the project instructions file and the Spryker coding rules), updating (refres

• ai-runtime-debugging

  Use when an AI agent needs to inspect Spryker runtime state — adding temporary debug logs the agent can read back, or stepping through code with XDebug like a human developer. Covers LoggerTrait, file_put_contents fallback, log file locations for cli vs FPM containers, and driving an XDebug-capable

• backoffice-frontend

  Use when building or overriding Spryker Back Office (Zed) pages in a project — new list/create/edit pages, overrides of core Zed Twig templates, Back Office navigation/ACL, or Back Office JS/SCSS. Triggers: "create a Back Office page", "add an admin screen for X", "override a Zed template", "add BO

• boot-and-verify

  Use to take a transformed Spryker project from 'files written' to 'verified running' — the first boot at project start (the wizard's last mandatory step and commit point), re-applying data changes on an already-booted stack, or standalone per-store verification of storefront, Back Office, search, an

• brand-project

  Use when applying or changing a Spryker project's brand identity — project name, dev domain, and docker namespace at project start (a pre-boot wizard step), or a standalone repeatable rebrand any time: 'change the palette', 'apply a new brand colour', 'set the storefront logo', 'rebrand the shop', '

• code-review

  Use when the user asks to review code in a Spryker project — a diff, a branch, a PR or a list of files ("review my changes", "code review this branch", "check these files before I commit"). Splits the change (by default the diff against master) across spryker-code-reviewer subagents, checks frontend

• codecept-functional

  Use when creating, updating, fixing or running Codeception tests in a Spryker project (src/**/tests/**, tests/**) — unit and functional tests for Facades, Controllers, console commands, plugins and Publish & Synchronize. Applies Spryker conventions: given/when/then names, Arrange/Act/Assert, DataBui

• configure-codebase

  Use when a Spryker project adopts a custom namespace instead of Pyz and the code layer must resolve, build, lint, and test it — namespace registration, composer autoload, frontend build config, codeception wiring. A pre-boot wizard step of project start; skipped entirely when the project keeps Pyz.

• configure-services

  Use when changing what infrastructure a Spryker project runs on — disable optional dev services (mail catcher, swagger, dashboard), or applications in a deploy file — or when building a new environment deploy file (deploy.<project>-<env>.yml). A pre-boot wizard step of project start, and the standal

• curate-golive-data

  Use before go-live to make the data a Spryker project is keeping production-safe — real tax rates instead of placeholders, the customer's own imagery instead of Spryker-CDN URLs, demo accounts/passwords removed or rotated, remaining demo leftovers cleared, integrity re-verified. A late, standalone c

• cypress-migration

  Use when onboarding a Spryker project onto its own Cypress E2E baseline in place of Spryker's demo-shop suites — "migrate off spryker/cypress-tests", "remove the demo-shop cypress/robot suites", "set up project-owned cypress testing", "integrate cypress-boilerplate". One-time migration: removes spry

• cypress-tests

  Use this skill whenever the user wants to create, run, review, or validate Cypress end-to-end tests in this project. Trigger on phrases like "add a cypress test", "write an e2e test", "run the cypress tests", "run e2e tests", "check my cypress test", "review this cypress spec", "does this test pass

• data-import

  Use when creating, updating or fixing a Spryker data import for an entity — the {Module}DataImport module with its config, DataSet, validator and writer steps, business factory, facade and DataImportPlugin, the registration in DataImportDependencyProvider, the data/import/*.yml entry and a sample CS

• define-stores

  Use when a Spryker DMS project's stores or region must be created or redefined pre-boot — a new store set, a region rename, or hardcoded store/locale literals (CodeBucketConfig, default_store, host maps) that block boot. Invoked by the wizard's store step, or standalone on an un-booted clone. Store

• demo-intake

  Use to turn a customer briefing into structured input — a .docx/.pdf/.txt brief, a demo script, a reference URL or a verbal brief. Triggers: "turn this brief into wizard input", "what data do we need from this brief", "classify this briefing", "give me a description of this demo". Phase 1 of `demo-p

• demo-prep-wizard

  Use when a demo is coming and the job is to prepare it end to end — 'we have a demo coming up', 'help me prepare a demo for <customer>', 'prepare the demo', 'here is the briefing for the demo', 'what do we need for this demo'. The demo-side parallel of `project-starter-wizard`: that one turns a demo

• demo-run-sheet

  Use to produce the demo handover report for a deployed demo environment — the document the presenter works from and the team takes over: environment and links, demo accounts, products, categories, one demo point per requirement of the brief with its status, what to watch out for, and how each part i

• harvest-source-materials

  Use to collect the raw material a demo will be built from — product data, product imagery, editorial/campaign imagery, brand assets — out of a customer's public website or a supplied export, into a harvest directory that sits beside the project and never inside it. Triggers: "gather the images", "ha

• match-reference-design

  Use when a Spryker storefront has to look like a reference site — the customer's own site or one the person names. Triggers: "make it look like <url>", "match the reference", "fix the navigation to be like theirs", and look-and-feel feedback on a page being matched to a reference or a demo look ("th

• payment-template

  Use when a developer wants to build, implement, scaffold, or onboard a new PSP (Payment Service Provider) or payment gateway integration in Spryker from scratch — including named providers like Adyen, Mollie, Stripe, Braintree, Klarna, Worldpay, Buckaroo, Payone, Nuvei, or any custom PSP partner. Tr

• product-requirement-document

  Use when creating PRDs for Spryker features, before implementation planning, or when a user requests a spec/requirements document that another AI agent will turn into tasks. This is the START of the Spryker feature-building chain — "I want to build a feature" begins here, then flows to spryker-custo

• project-ci-generator

  Use when turning a repo's inherited product/vendor CI into a single, lean project CI pipeline — "clean up CI for the project", "make a project CI", "recreate one CI file", "remove product-only CI jobs", "clear the CI folder and rebuild", or porting CI to another host (GitLab, Bitbucket). A pre-boot

• project-data

  The one skill for a Spryker project's data/import/** — use whenever demo/import data must be populated, reshaped, reduced, cleaned up, or removed. Triggers: 'adapt the demo shop to my stores and currencies', 'add demo data / generate a catalog of tools/books/dresses from these images', 'create CMS b

• project-starter-wizard

  Use at the very start of a new customer project, on an unmodified (booted or not) clone of a Spryker b2b/b2b-marketplace demoshop — 'turn this demoshop into our project', 'start the project setup', 'run the project starter'. Also the trigger for 'give me the setup questionnaire' / 'here are my fille

• propel-schema

  Use when creating, updating or reviewing Propel schema XML for Spryker modules — new tables and columns, foreign keys, indexes, unique constraints, many-to-many tables and the timestampable, uuid, event and synchronization behaviors. Applies Spryker naming (spy_/pyz_ table prefixes, id_/fk_ columns,

• spryker-bugfix

  End-to-end bug-fixing workflow: from an optional tracker ticket (JIRA, GitHub Issues, or any service) or a plain bug description to a committed, validated, QA-accepted fix on a bugfix branch (autonomous mode adds a pushed Draft PR + CI watch). Orchestrates reproduce → root-cause → fix → functional t

• spryker-customization

  Use whenever the user wants to change how the shop behaves — new or overridden PHP (plugins, expanders, dependency providers, config classes, importers), permissions, checkout/cart/payment logic, new modules — from a PRD or acceptance criteria. Triggers include "build this", "implement this", "here

• spryker-docs-research

  Research and summarize official Spryker public documentation — module behavior, configuration options, API/Glue references, architecture concepts, supported actors, feature/PBC names, and integration/installation guides. Use this whenever a task needs to understand how a Spryker feature, module, or

• spryker-import-tools

  The engine (csv.php + validate.php) that project-data and the wizard drive to manipulate and validate Spryker data-import CSVs and import manifests — for WHAT data to change (add, adapt, reduce, clean up, an ad-hoc CSV edit), use project-data; come here for the mechanics of a command. csv.php: read/

• spryker-profiler

  Read and configure the Spryker/Symfony WebProfiler. Use when someone asks why a page, endpoint or Back Office screen is slow, wants the slowest request, asks how many queries a page runs, suspects an N+1, wants Redis, Elasticsearch, Yves→Zed or external HTTP call counts, or wants before/after eviden

• spryker-qa-coverage

  Hands-on QA of a Spryker feature against the running application: turns a PRD or feature description into a checklist and test cases (happy path, negative, authorization, edge cases), runs them through spryker-runtime (Back Office and storefront in the browser, CLI, HTTP/API, database/Redis/queue ch

• spryker-refresher

  Use this skill whenever code, schema, frontend, or config changes have just been applied and the system needs to be refreshed so the changes take effect. Triggers - "run post-change commands", "refresh after edits", "regenerate transfers", "rebuild the frontend", "clear caches after this change", "w

• spryker-runtime

  Use to actually RUN the Spryker application and observe real behavior, and to perform manual testing / QA against a real authenticated session — log in to Yves storefront, the Back Office, Merchant Portal, drive the UI in Chrome, run `docker/sdk cli console` commands, and call Yves/Glue endpoints ov

• spryker-upgrade

  Upgrade this Spryker project's modules/features to a newer release. First records baselines (tests, PHPStan, code sniffer, evaluator and a crawl of the whole Back Office) and checks whether the project's customisations are covered by tests, offering Facade/Client-level functional tests where they ar

• static-validation

  Run Spryker static analysis over only the code that changed versus a base branch — PHP (phpcbf, phpcs, phpmd/architecture-sniffer, phpstan) and frontend (eslint, stylelint, prettier for js/ts/scss/css/less/html across Yves, Back Office and Merchant Portal) — after implementing or editing code, befor

• translate-content

  Use when actually translating a Spryker project's storefront content into a project locale — glossary and/or catalog/CMS/navigation/labels — the opt-in localization pass that project setup defers: 'localize uk_UA', 'translate the shop content into Polish', 'the storefront is still English in my loca

• yves-atomic-frontend

  Use when creating, extending, or overriding Spryker Yves storefront frontend code in a project — atomic components, templates, views, Widgets — and their Twig, SCSS, and TypeScript. Triggers: "create a new molecule", "override the product item", "extend the cart item component", "create a widget", "

Subagents (6)

• spryker-code-reviewer

  Review code for compliance with Spryker standards

• spryker-data-seeder

  Use whenever the user needs a small amount of Spryker test data to exist before running a verification or demoing a flow. Triggers include "seed X", "create test data for Y", "I need a product with X", "set up a quote request", "make a B2B customer for testing", "prepare data so the AC can run", "cr

• spryker-feature-expert

  Use whenever the user asks about a Spryker feature, module, or capability. Triggers include "tell me about X", "explain X", "how does X work in Spryker", "what is X", "what does X do", "what X types exist", "how is X implemented", "how do I X", "design Y", "how should I build Z in Spryker", "what's

• spryker-issue-diagnoser

  Use whenever something failed and the user wants to know why. Triggers include "why is X failing", "what's wrong with X", "debug this", "diagnose this", "investigate this error", "I'm seeing X error", "find out why", "the import succeeded but data isn't visible", "the form returns 500", "queue is st

• spryker-screenshot-collector

  Use whenever the user wants to capture screenshots, images, or short GIFs of Spryker pages or flows for a demo deck, sales recap, slide, or documentation. Triggers include "screenshot X", "capture X", "take screenshots of X", "record a GIF of Y", "make demo images of Z", "I need pictures of the BO/s

• spryker-verifier

  Use whenever the user wants to verify, check, or test that a specific behaviour holds in a running Spryker environment. Triggers include "verify that X works", "check whether X", "test the feature", "run the ACs", "does X pass", "make sure X works", "confirm that the storefront/BO/API shows X", "ass

Hooks (2)

• SessionStart

  "${CLAUDE_PLUGIN_ROOT}/scripts/sync-rules.sh"

• Stop

  command -v php >/dev/null 2>&1 && exec php "${CLAUDE_PLUGIN_ROOT}/hooks/guard-stop.php" || exit 0

Similar plugins