[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BY7DTT65562SZZ74DVVAK0":3,"skill-same:01M6BY7DTT65562SZZ74DVVAK0":133},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":50,"repositoryHtmlUrl":51,"repositoryHomepageUrl":6,"ownerHtmlUrl":52,"ownerBlogUrl":53,"ownerDescription":54,"updatedAt":55,"install":56,"resources":68},"01M6BY7DTT65562SZZ74DVVAK0","shopware-ats",null,"Work effectively in the Shopware Acceptance Test Suite repository: inspect or modify Playwright specs, merged fixtures, page objects, tasks, service helpers, shared types, and locale-backed assertions. Use when you need to debug a failing ATS test, add or refactor Shopware end-to-end coverage, trace how exported fixtures are wired together, or choose the right file to update in `tests\u002F`, `src\u002Ffixtures\u002F`, `src\u002Fpage-objects\u002F`, `src\u002Ftasks\u002F`, `src\u002Fservices\u002F`, or `src\u002Ftypes\u002F`.","shopware\u002Facceptance-test-suite","shopware","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F612628?v=4","01M6BY7A3ZCJ7Z009TPK94GXVP","Shopware","01M6BY7A7WNR741EKSDFHYGVRG",30,"MIT","https:\u002F\u002Fgithub.com\u002Fshopware\u002Facceptance-test-suite\u002Fblob\u002Ftrunk\u002F.codex\u002Fskills\u002Fshopware-ats\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39],"shopware ats","playwright","test","debug","tasks","update","acceptance","file","repository","services","refactor","how","src","page","trace","choose","2026-11-10 10:12:30",false,"---\nname: shopware-ats\ndescription: \"Work effectively in the Shopware Acceptance Test Suite repository: inspect or modify Playwright specs, merged fixtures, page objects, tasks, service helpers, shared types, and locale-backed assertions. Use when you need to debug a failing ATS test, add or refactor Shopware end-to-end coverage, trace how exported fixtures are wired together, or choose the right file to update in `tests\u002F`, `src\u002Ffixtures\u002F`, `src\u002Fpage-objects\u002F`, `src\u002Ftasks\u002F`, `src\u002Fservices\u002F`, or `src\u002Ftypes\u002F`.\"\nmetadata:\n    internal: true\n---\n\n# Shopware ATS\n\nUse this skill to make precise ATS changes without over-abstracting. Keep this file directive; use `references\u002Frepo-map.md` for detailed layout and examples.\n\nThis skill is for work inside this repository. Projects that consume the package should use the `acceptance-test-suite` skill from `skills\u002F` instead.\n\n## Start Here\n\n- Open `package.json`, `playwright.config.ts`, and `src\u002Findex.ts`.\n- Then open `references\u002Frepo-map.md` for merge points and edit targets.\n\n## Choose The Right Layer\n\nPick the narrowest owner of the behavior:\n\n- `tests\u002F`: spec flow, assertions, and coverage composition.\n- `src\u002Fpage-objects\u002F`: selectors, URLs, and page-level affordances. See Page Object Locators below.\n- `src\u002Ftasks\u002F`: reusable multi-step business actions.\n- `src\u002Ffixtures\u002F`: context wiring, actors, lifecycle, and API\u002Fpage contexts.\n- `src\u002Fservices\u002FTestDataService.ts`: API-backed test data creation, setup, cleanup, and cleanup ordering (`highPriorityEntities`) for new work.\n- `src\u002Fservices\u002F`: cross-cutting helpers and integrations.\n- `src\u002Ftypes\u002F`: shared fixture, page-object, task, and Shopware domain contracts.\n- `src\u002Flocales\u002F`: translation-backed assertion keys.\n\nTreat `src\u002Fdata-fixtures\u002F` as a legacy compatibility surface. Do not introduce new data-fixtures when `TestDataService` can own the behavior; only touch legacy fixtures to keep existing public APIs working.\n\nIf you add a reusable primitive, export it through the appropriate merge file or `src\u002Findex.ts` so it stays reachable from the public API.\n\n## Page Object Locators\n\n- Initialize reusable locators as constructor-initialized `readonly` fields; keep methods only for parameterized locators.\n- Avoid descendant CSS selector strings like `.foo .bar`. If CSS is unavoidable, target one stable element or scope through a named parent locator instead of encoding the hierarchy into one selector string.\n\n## When To Keep It Simple\n\nPrefer a direct spec edit (no new abstraction) when all are true:\n\n1. The behavior is used by one spec or one assertion path.\n2. The interaction is short and readable inline.\n3. Reuse is unlikely across other scenarios.\n\nOnly introduce or extend page objects, tasks, fixtures, services, or shared types when the same behavior is repeated, unstable, or clearly part of shared domain language.\n\n## Keep Surfaces Separate\n\nKeep each browser-driven scenario on one UI surface. Do not bounce between Administration and Storefront in the same task or spec just because both fixtures are available.\n\nIn practice, that means one browser actor per scenario: `ShopAdmin` for Administration coverage or `ShopCustomer` for Storefront coverage. Neutral setup fixtures such as `TestDataService`, `AdminApiContext`, `StoreApiContext`, `DefaultSalesChannel`, or mail helpers can support either side because they do not switch the browser surface.\n\nIf a storefront scenario needs admin-side prerequisites, create them through `TestDataService`, `AdminApiContext`, or setup fixtures and then stay in Storefront. If an admin scenario needs storefront-side state, prepare it through `TestDataService`, `StoreApiContext`, or separate setup coverage instead of switching the browser surface mid-flow.\n\nIf a requested behavior truly spans both surfaces, split it into setup plus validation or into separate specs. Do not model browser flows that go Administration -> Storefront -> Administration, or the reverse.\n\n## Prefer Deterministic Setup\n\nFollow ATS and Playwright isolation rules so tests stay parallel-safe and resilient on unknown shop states:\n\n- Prefer `TestDataService` for common entity setup and cleanup.\n- Extend `TestDataService` when the same creation logic, relation setup, or cleanup behavior would otherwise be duplicated across tests.\n- Use `AdminApiContext` or `StoreApiContext` for setup and verification when the UI is not the behavior under test.\n- Prefer fixture-provided contexts such as `DefaultSalesChannel` over mutating shared shop state.\n- Create all data a scenario needs explicitly. Do not rely on existing categories, rules, flows, users, customers, or other ambient shop state.\n- Do not assume default locale or currency values like `en_GB` or `EUR`; set up or fetch what the scenario needs.\n- When possible, navigate directly to detail pages with entity IDs. If you must go through a listing, search with a unique name so the scenario targets one known entity.\n\n## Validate Network Responses\n\nCheck `page.waitForResponse(...)` responses for `response.ok()`, not just URL\u002Fmethod\u002Fpayload match.\n\n- In-predicate (`... && response.ok()`, see `helpers\u002FUploadMedia.ts`) for search-as-you-type \u002F debounced flows.\n- Assert-after (`expect(response.ok()).toBeTruthy()` on the awaited response, see `tasks\u002Fshop-admin\u002FProduct\u002FBulkEditProducts.ts`, `SaveProduct.ts`) for single-shot calls.\n\n## Cross-Repo Sync\n\nIf a change is needed in `acceptance-test-suite` and must be consumed immediately in a platform repository, use this workflow instead of improvising package wiring:\n\n1. In the `acceptance-test-suite` project root, run `npm run build`.\n2. Open the generated `dist\u002F` folder and copy the three `index*` files from that build output.\n3. In the platform project root, open `tests\u002Facceptance\u002Fnode_modules\u002F@shopware-ag\u002Facceptance-test-suite\u002Fdist\u002F`.\n4. Replace the three `index*` files there with the files copied from `acceptance-test-suite\u002Fdist\u002F`.\n5. Continue with the platform-side execution or verification after those files are replaced.\n\nUse this as the default local cross-repo sync path for ATS changes. Do not assume that installing from a sibling checkout, mixing transient npm installs, or wiring multiple Playwright runtimes together will behave the same way.\n\n## Implementation Workflow\n\n1. Reproduce with the smallest affected spec\u002Ftest block.\n2. Search for existing nouns, flows, and `TestDataService` helpers with `rg` before creating new helpers.\n3. Trace from spec -> actor\u002Ftask -> page object -> fixture\u002Fservice\u002Ftype and fix the owning layer.\n4. Keep established patterns (`mergeTests`, `test.extend`, locale-aware assertions, and the actor model where it improves readability). The actor pattern is optional; plain Playwright is still valid when it is clearer. For Storefront flows, prefer `ShopCustomer.fillsIn()` and `ShopCustomer.presses()` where existing tasks already use that keyboard-first pattern; do not generalize that rule to Administration flows.\n5. Keep version or SaaS branching explicit when tied to `InstanceMeta`.\n6. Re-export new reusable surfaces via the right merge file or `src\u002Findex.ts`.\n7. Keep page objects structural: constructor-initialize fixed `readonly` locators, use methods only for parameterized locators, and move multi-step behavior into tasks, services, or helper classes. When the behavior is a reusable browser-driven business action, prefer a task over a local spec helper function. For locators, prefer semantic single-target queries over chained CSS descendants; do not introduce selectors like `.parent .child` when a direct accessible locator or a scoped named parent locator would be clearer and less brittle.\n8. Keep `ShopAdmin.expects(...)` or `ShopCustomer.expects(...)` in the spec or the owning task, but keep the verification intent obvious from the spec. A reader should be able to tell what behavior the scenario proves without digging through helper layers.\n9. When a fix must be verified in a consuming repo, sync the built ATS `dist\u002Findex*` files into the consumer's `tests\u002Facceptance\u002Fnode_modules\u002F@shopware-ag\u002Facceptance-test-suite\u002Fdist\u002F` folder before retrying the spec.\n\n## Keep Specs High-Signal\n\nWhen writing or refactoring ATS specs:\n\n- Assert only what materially proves the behavior. Avoid duplicate visibility\u002Fcount\u002Ftext checks that restate the same fact with more noise.\n- Favor a few high-signal assertions over exhaustive UI restatement. The goal is confidence in behavior, not a transcript of the page.\n- Keep the verified outcome legible at spec level. Even when an owning task contains `ShopAdmin.expects(...)` or `ShopCustomer.expects(...)`, the spec should still make the proven behavior obvious from its setup, action, and named verification step.\n\n### Don't\n\n- Do not hide most `expect(...)` calls inside helpers, tasks, or page objects. Those layers should usually return locators, values, or perform actions; only extract an `expect...` helper when the assertion is a shared domain primitive.\n- Do not wrap `ShopAdmin.expects(...)` or `ShopCustomer.expects(...)` inside generic helper methods. Keep actor-scoped expectations in the spec or the owning task, and make the verification intent clear from the spec so the reader can see what is being proven.\n- Do not introduce ad hoc local helper functions for repeated browser-driven flows when the same interaction belongs in a reusable task. If the behavior is a shared business action, model it as a task instead of a spec-local helper.\n- Do not repeat explicit timeouts when Playwright's configured defaults already express the intended wait. Add a custom timeout only when one wait is genuinely exceptional and the reason is clear from the scenario.\n- Do not split tiny actions or single assertions into separate `test.step(...)` blocks.\n- Do not combine `ShopAdmin` and `ShopCustomer` UI actions in one browser-driven task or spec. If both surfaces are involved, use API or fixture setup for prerequisites and keep the UI flow on one side.\n- Do not assume a list, table, or API helper returns only one item. Use unique names or IDs so the scenario identifies the exact entity it created.\n- Do not request unused fixtures. If the spec does not read from a fixture, remove it or refactor the setup.\n- Do not depend on implicit configuration or pre-existing shop data.\n- Do not change global settings unless the scenario explicitly owns that scope; prefer sales-channel-specific setup and isolated test data.\n- Do not stack duplicate visibility, count, and text assertions that restate the same fact with more noise.\n- Do not turn a spec into a transcript of the page. Keep assertions focused on the few signals that materially prove the behavior.\n\n## Validate\n\nRun the narrowest useful checks first:\n\n- `npx playwright test tests\u002F\u003Cspec>.spec.ts --project=chromium`\n- `npm run lint`\n- `npm run typecheck`\n- `npm run build`\n\nFor environment defaults and boot behavior, rely on `playwright.config.ts` and the reference file instead of hardcoding assumptions.\n\n## Grow This Skill From Review Feedback\n\nWhen a review — human or agent — traces a mistake back to a gap in this skill rather than a one-off code error, propose a concrete addition:\n\n- Only if the pattern already recurs across multiple files here and would not have surfaced from a minute of `rg` before writing the code — otherwise it is a one-off, not a skill gap.\n- Rule plus real precedent file(s) only (see Validate Network Responses above for the format), no narrative justification.\n- Mark an expiry condition when the rule is tied to a transitional state (an in-progress migration, a pattern being phased out), the same way `\u002F\u002FTODO: After 6.8.0.0 release...` comments already mark code for cleanup.\n- If rules like this start crowding the file, consolidate into a `references\u002F` file and leave a pointer here instead (see how Start Here delegates to `references\u002Frepo-map.md`).\n- Get the user's or reviewer's sign-off on wording and placement before committing it here.\n","# Shopware ATS\n\nUse this skill to make precise ATS changes without over-abstracting. Keep this file directive; use `references\u002Frepo-map.md` for detailed layout and examples.\n\nThis skill is for work inside this repository. Projects that consume the package should use the `acceptance-test-suite` skill from `skills\u002F` instead.\n\n## Start Here\n\n- Open `package.json`, `playwright.config.ts`, and `src\u002Findex.ts`.\n- Then open `references\u002Frepo-map.md` for merge points and edit targets.\n\n## Choose The Right Layer\n\nPick the narrowest owner of the behavior:\n\n- `tests\u002F`: spec flow, assertions, and coverage composition.\n- `src\u002Fpage-objects\u002F`: selectors, URLs, and page-level affordances. See Page Object Locators below.\n- `src\u002Ftasks\u002F`: reusable multi-step business actions.\n- `src\u002Ffixtures\u002F`: context wiring, actors, lifecycle, and API\u002Fpage contexts.\n- `src\u002Fservices\u002FTestDataService.ts`: API-backed test data creation, setup, cleanup, and cleanup ordering (`highPriorityEntities`) for new work.\n- `src\u002Fservices\u002F`: cross-cutting helpers and integrations.\n- `src\u002Ftypes\u002F`: shared fixture, page-object, task, and Shopware domain contracts.\n- `src\u002Flocales\u002F`: translation-backed assertion keys.\n\nTreat `src\u002Fdata-fixtures\u002F` as a legacy compatibility surface. Do not introduce new data-fixtures when `TestDataService` can own the behavior; only touch legacy fixtures to keep existing public APIs working.\n\nIf you add a reusable primitive, export it through the appropriate merge file or `src\u002Findex.ts` so it stays reachable from the public API.\n\n## Page Object Locators\n\n- Initialize reusable locators as constructor-initialized `readonly` fields; keep methods only for parameterized locators.\n- Avoid descendant CSS selector strings like `.foo .bar`. If CSS is unavoidable, target one stable element or scope through a named parent locator instead of encoding the hierarchy into one selector string.\n\n## When To Keep It Simple\n\nPrefer a direct spec edit (no new abstraction) when all are true:\n\n1. The behavior is used by one spec or one assertion path.\n2. The interaction is short and readable inline.\n3. Reuse is unlikely across other scenarios.\n\nOnly introduce or extend page objects, tasks, fixtures, services, or shared types when the same behavior is repeated, unstable, or clearly part of shared domain language.\n\n## Keep Surfaces Separate\n\nKeep each browser-driven scenario on one UI surface. Do not bounce between Administration and Storefront in the same task or spec just because both fixtures are available.\n\nIn practice, that means one browser actor per scenario: `ShopAdmin` for Administration coverage or `ShopCustomer` for Storefront coverage. Neutral setup fixtures such as `TestDataService`, `AdminApiContext`, `StoreApiContext`, `DefaultSalesChannel`, or mail helpers can support either side because they do not switch the browser surface.\n\nIf a storefront scenario needs admin-side prerequisites, create them through `TestDataService`, `AdminApiContext`, or setup fixtures and then stay in Storefront. If an admin scenario needs storefront-side state, prepare it through `TestDataService`, `StoreApiContext`, or separate setup coverage instead of switching the browser surface mid-flow.\n\nIf a requested behavior truly spans both surfaces, split it into setup plus validation or into separate specs. Do not model browser flows that go Administration -> Storefront -> Administration, or the reverse.\n\n## Prefer Deterministic Setup\n\nFollow ATS and Playwright isolation rules so tests stay parallel-safe and resilient on unknown shop states:\n\n- Prefer `TestDataService` for common entity setup and cleanup.\n- Extend `TestDataService` when the same creation logic, relation setup, or cleanup behavior would otherwise be duplicated across tests.\n- Use `AdminApiContext` or `StoreApiContext` for setup and verification when the UI is not the behavior under test.\n- Prefer fixture-provided contexts such as `DefaultSalesChannel` over mutating shared shop state.\n- Create all data a scenario needs explicitly. Do not rely on existing categories, rules, flows, users, customers, or other ambient shop state.\n- Do not assume default locale or currency values like `en_GB` or `EUR`; set up or fetch what the scenario needs.\n- When possible, navigate directly to detail pages with entity IDs. If you must go through a listing, search with a unique name so the scenario targets one known entity.\n\n## Validate Network Responses\n\nCheck `page.waitForResponse(...)` responses for `response.ok()`, not just URL\u002Fmethod\u002Fpayload match.\n\n- In-predicate (`... && response.ok()`, see `helpers\u002FUploadMedia.ts`) for search-as-you-type \u002F debounced flows.\n- Assert-after (`expect(response.ok()).toBeTruthy()` on the awaited response, see `tasks\u002Fshop-admin\u002FProduct\u002FBulkEditProducts.ts`, `SaveProduct.ts`) for single-shot calls.\n\n## Cross-Repo Sync\n\nIf a change is needed in `acceptance-test-suite` and must be consumed immediately in a platform repository, use this workflow instead of improvising package wiring:\n\n1. In the `acceptance-test-suite` project root, run `npm run build`.\n2. Open the generated `dist\u002F` folder and copy the three `index*` files from that build output.\n3. In the platform project root, open `tests\u002Facceptance\u002Fnode_modules\u002F@shopware-ag\u002Facceptance-test-suite\u002Fdist\u002F`.\n4. Replace the three `index*` files there with the files copied from `acceptance-test-suite\u002Fdist\u002F`.\n5. Continue with the platform-side execution or verification after those files are replaced.\n\nUse this as the default local cross-repo sync path for ATS changes. Do not assume that installing from a sibling checkout, mixing transient npm installs, or wiring multiple Playwright runtimes together will behave the same way.\n\n## Implementation Workflow\n\n1. Reproduce with the smallest affected spec\u002Ftest block.\n2. Search for existing nouns, flows, and `TestDataService` helpers with `rg` before creating new helpers.\n3. Trace from spec -> actor\u002Ftask -> page object -> fixture\u002Fservice\u002Ftype and fix the owning layer.\n4. Keep established patterns (`mergeTests`, `test.extend`, locale-aware assertions, and the actor model where it improves readability). The actor pattern is optional; plain Playwright is still valid when it is clearer. For Storefront flows, prefer `ShopCustomer.fillsIn()` and `ShopCustomer.presses()` where existing tasks already use that keyboard-first pattern; do not generalize that rule to Administration flows.\n5. Keep version or SaaS branching explicit when tied to `InstanceMeta`.\n6. Re-export new reusable surfaces via the right merge file or `src\u002Findex.ts`.\n7. Keep page objects structural: constructor-initialize fixed `readonly` locators, use methods only for parameterized locators, and move multi-step behavior into tasks, services, or helper classes. When the behavior is a reusable browser-driven business action, prefer a task over a local spec helper function. For locators, prefer semantic single-target queries over chained CSS descendants; do not introduce selectors like `.parent .child` when a direct accessible locator or a scoped named parent locator would be clearer and less brittle.\n8. Keep `ShopAdmin.expects(...)` or `ShopCustomer.expects(...)` in the spec or the owning task, but keep the verification intent obvious from the spec. A reader should be able to tell what behavior the scenario proves without digging through helper layers.\n9. When a fix must be verified in a consuming repo, sync the built ATS `dist\u002Findex*` files into the consumer's `tests\u002Facceptance\u002Fnode_modules\u002F@shopware-ag\u002Facceptance-test-suite\u002Fdist\u002F` folder before retrying the spec.\n\n## Keep Specs High-Signal\n\nWhen writing or refactoring ATS specs:\n\n- Assert only what materially proves the behavior. Avoid duplicate visibility\u002Fcount\u002Ftext checks that restate the same fact with more noise.\n- Favor a few high-signal assertions over exhaustive UI restatement. The goal is confidence in behavior, not a transcript of the page.\n- Keep the verified outcome legible at spec level. Even when an owning task contains `ShopAdmin.expects(...)` or `ShopCustomer.expects(...)`, the spec should still make the proven behavior obvious from its setup, action, and named verification step.\n\n### Don't\n\n- Do not hide most `expect(...)` calls inside helpers, tasks, or page objects. Those layers should usually return locators, values, or perform actions; only extract an `expect...` helper when the assertion is a shared domain primitive.\n- Do not wrap `ShopAdmin.expects(...)` or `ShopCustomer.expects(...)` inside generic helper methods. Keep actor-scoped expectations in the spec or the owning task, and make the verification intent clear from the spec so the reader can see what is being proven.\n- Do not introduce ad hoc local helper functions for repeated browser-driven flows when the same interaction belongs in a reusable task. If the behavior is a shared business action, model it as a task instead of a spec-local helper.\n- Do not repeat explicit timeouts when Playwright's configured defaults already express the intended wait. Add a custom timeout only when one wait is genuinely exceptional and the reason is clear from the scenario.\n- Do not split tiny actions or single assertions into separate `test.step(...)` blocks.\n- Do not combine `ShopAdmin` and `ShopCustomer` UI actions in one browser-driven task or spec. If both surfaces are involved, use API or fixture setup for prerequisites and keep the UI flow on one side.\n- Do not assume a list, table, or API helper returns only one item. Use unique names or IDs so the scenario identifies the exact entity it created.\n- Do not request unused fixtures. If the spec does not read from a fixture, remove it or refactor the setup.\n- Do not depend on implicit configuration or pre-existing shop data.\n- Do not change global settings unless the scenario explicitly owns that scope; prefer sales-channel-specific setup and isolated test data.\n- Do not stack duplicate visibility, count, and text assertions that restate the same fact with more noise.\n- Do not turn a spec into a transcript of the page. Keep assertions focused on the few signals that materially prove the behavior.\n\n## Validate\n\nRun the narrowest useful checks first:\n\n- `npx playwright test tests\u002F\u003Cspec>.spec.ts --project=chromium`\n- `npm run lint`\n- `npm run typecheck`\n- `npm run build`\n\nFor environment defaults and boot behavior, rely on `playwright.config.ts` and the reference file instead of hardcoding assumptions.\n\n## Grow This Skill From Review Feedback\n\nWhen a review — human or agent — traces a mistake back to a gap in this skill rather than a one-off code error, propose a concrete addition:\n\n- Only if the pattern already recurs across multiple files here and would not have surfaced from a minute of `rg` before writing the code — otherwise it is a one-off, not a skill gap.\n- Rule plus real precedent file(s) only (see Validate Network Responses above for the format), no narrative justification.\n- Mark an expiry condition when the rule is tied to a transitional state (an in-progress migration, a pattern being phased out), the same way `\u002F\u002FTODO: After 6.8.0.0 release...` comments already mark code for cleanup.\n- If rules like this start crowding the file, consolidate into a `references\u002F` file and leave a pointer here instead (see how Start Here delegates to `references\u002Frepo-map.md`).\n- Get the user's or reviewer's sign-off on wording and placement before committing it here.\n",{"name":5,"metadata":45,"description":7},{"internal":46},true,"trunk","00723d5461c49d1e9302f90666993d4207f3a0a9",".codex\u002Fskills\u002Fshopware-ats",9,"https:\u002F\u002Fgithub.com\u002Fshopware\u002Facceptance-test-suite","https:\u002F\u002Fgithub.com\u002Fshopware","https:\u002F\u002Fwww.shopware.com","Shopware 6 is an open commerce platform based on Symfony Framework and Vue and supported by a worldwide community and more than 2.500 community extensions","2026-11-12 18:53:38",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":46},[58,61,64],{"tool":59,"command":60},"npx","npx skills add shopware\u002Facceptance-test-suite --skill shopware-ats",{"tool":62,"command":63},"bunx","bunx skills add shopware\u002Facceptance-test-suite --skill shopware-ats",{"tool":65,"command":66},"pnpm","pnpm dlx skills add shopware\u002Facceptance-test-suite --skill shopware-ats","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fshopware\u002Facceptance-test-suite\u002Fblob\u002Ftrunk\u002F.codex\u002Fskills\u002Fshopware-ats\u002FSKILL.md",[69,75,79,83,87,91,95,99,103,109,113,117,121,125,129],{"path":70,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":73,"sourceHtmlUrl":74},"agents\u002Fopenai.yaml","REFERENCE","参考文档",216,"https:\u002F\u002Fgithub.com\u002Fshopware\u002Facceptance-test-suite\u002Fblob\u002Ftrunk\u002F.codex\u002Fskills\u002Fshopware-ats\u002Fagents\u002Fopenai.yaml",{"path":76,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":77,"sourceHtmlUrl":78},"references\u002Fcost-tracking.md",1384,"https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fconfigs\u002Fskills\u002Fbanana\u002Freferences\u002Fcost-tracking.md",{"path":80,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Fgemini-models.md",9642,"https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fconfigs\u002Fskills\u002Fbanana\u002Freferences\u002Fgemini-models.md",{"path":84,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":85,"sourceHtmlUrl":86},"references\u002Fmcp-tools.md",5759,"https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fconfigs\u002Fskills\u002Fbanana\u002Freferences\u002Fmcp-tools.md",{"path":88,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":89,"sourceHtmlUrl":90},"references\u002Fpost-processing.md",5205,"https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fconfigs\u002Fskills\u002Fbanana\u002Freferences\u002Fpost-processing.md",{"path":92,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":93,"sourceHtmlUrl":94},"references\u002Fpresets.md",2250,"https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fconfigs\u002Fskills\u002Fbanana\u002Freferences\u002Fpresets.md",{"path":96,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":97,"sourceHtmlUrl":98},"references\u002Fprompt-engineering.md",24498,"https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fconfigs\u002Fskills\u002Fbanana\u002Freferences\u002Fprompt-engineering.md",{"path":100,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":101,"sourceHtmlUrl":102},"references\u002Frepo-map.md",7958,"https:\u002F\u002Fgithub.com\u002Fshopware\u002Facceptance-test-suite\u002Fblob\u002Ftrunk\u002F.codex\u002Fskills\u002Fshopware-ats\u002Freferences\u002Frepo-map.md",{"path":104,"resourceType":105,"resourceTypeDesc":106,"sizeBytes":107,"sourceHtmlUrl":108},"scripts\u002Fbatch.py","SCRIPT","脚本",3155,"https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fconfigs\u002Fskills\u002Fbanana\u002Fscripts\u002Fbatch.py",{"path":110,"resourceType":105,"resourceTypeDesc":106,"sizeBytes":111,"sourceHtmlUrl":112},"scripts\u002Fcost_tracker.py",6400,"https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fconfigs\u002Fskills\u002Fbanana\u002Fscripts\u002Fcost_tracker.py",{"path":114,"resourceType":105,"resourceTypeDesc":106,"sizeBytes":115,"sourceHtmlUrl":116},"scripts\u002Fedit.py",5583,"https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fconfigs\u002Fskills\u002Fbanana\u002Fscripts\u002Fedit.py",{"path":118,"resourceType":105,"resourceTypeDesc":106,"sizeBytes":119,"sourceHtmlUrl":120},"scripts\u002Fgenerate.py",6572,"https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fconfigs\u002Fskills\u002Fbanana\u002Fscripts\u002Fgenerate.py",{"path":122,"resourceType":105,"resourceTypeDesc":106,"sizeBytes":123,"sourceHtmlUrl":124},"scripts\u002Fpresets.py",5066,"https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fconfigs\u002Fskills\u002Fbanana\u002Fscripts\u002Fpresets.py",{"path":126,"resourceType":105,"resourceTypeDesc":106,"sizeBytes":127,"sourceHtmlUrl":128},"scripts\u002Fsetup_mcp.py",4627,"https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fconfigs\u002Fskills\u002Fbanana\u002Fscripts\u002Fsetup_mcp.py",{"path":130,"resourceType":105,"resourceTypeDesc":106,"sizeBytes":131,"sourceHtmlUrl":132},"scripts\u002Fvalidate_setup.py",3641,"https:\u002F\u002Fgithub.com\u002Fshenxingy\u002FClade\u002Fblob\u002Fmain\u002Fconfigs\u002Fskills\u002Fbanana\u002Fscripts\u002Fvalidate_setup.py",[134,153],{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":141,"publishedAt":40},"01M6BY7GYC5STYS0CANRNCXEYV","acceptance-test-suite","Write and run Playwright acceptance and accessibility tests in a Shopware project that consumes the Shopware Acceptance Test Suite (@shopware-ag\u002Facceptance-test-suite) as an npm package. Use when setting up the test workspace, writing or debugging specs, creating test data, working with actors and tasks, or checking accessibility with the bundled axe integration, including when the request just mentions ATS or acceptance tests. Not for contributing to the shopware\u002Facceptance-test-suite repository itself.","https:\u002F\u002Fgithub.com\u002Fshopware\u002Facceptance-test-suite\u002Fblob\u002Ftrunk\u002Fskills\u002Facceptance-test-suite\u002FSKILL.md",[140],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[26,142,30,28,143,144,145,146,147,148,149,32,150,151,152,25],"acceptance test suite","debugging","writing","package","npm","data","accessibility","integration","workspace","run","contributing",{"skillNo":154,"name":5,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":157,"publishedAt":40},"01M6BY7CHT7479PM7R3E74BTE1","https:\u002F\u002Fgithub.com\u002Fshopware\u002Facceptance-test-suite\u002Fblob\u002Ftrunk\u002F.claude\u002Fskills\u002Fshopware-ats\u002FSKILL.md",[],[24]]