[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C48YMJVFHM7DVGG1WWW5RJ":3,"skill-same:01M6C48YMJVFHM7DVGG1WWW5RJ":82},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":25,"publishedAt":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":54,"repositoryHtmlUrl":55,"repositoryHomepageUrl":6,"ownerHtmlUrl":56,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M6C48YMJVFHM7DVGG1WWW5RJ","webapp-testing",null,"Playwright end-to-end testing guidance for web apps, with practical patterns and setup steps. Use when creating or improving browser-based E2E coverage, test stability, and CI execution. DO NOT USE FOR: React component tests (use ui-testing), canvas game interaction (use browser-canvas-testing), TDD workflow (use test-driven-development), debugging failures (use systematic-debugging), or randomized property tests (use property-based-testing).","Grimblaz\u002Fagent-orchestra","Grimblaz","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F74755849?v=4","01M6C430M9XZDHGHPWQVTQ3KMA","01M6C430RJY3MMX0QAZ3X8DR3Y",3,"MIT","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fwebapp-testing\u002FSKILL.md",[17,22],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发",[26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"webapp testing","webapp","testing","development","use","coverage","game","e2e","execution","ci","browser","canvas","debugging","component","react","web","test","playwright","workflow","tdd","2026-11-10 10:12:30",false,"---\nname: webapp-testing\ndescription: \"Playwright end-to-end testing guidance for web apps, with practical patterns and setup steps. Use when creating or improving browser-based E2E coverage, test stability, and CI execution. DO NOT USE FOR: React component tests (use ui-testing), canvas game interaction (use browser-canvas-testing), TDD workflow (use test-driven-development), debugging failures (use systematic-debugging), or randomized property tests (use property-based-testing).\"\n---\n\n# Web App Testing Skill\n\n## Overview\n\nThis skill provides practical Playwright E2E guidance for reliable web app testing across local and CI environments.\n\n> **[CUSTOMIZE]** Replace sample URLs, auth flows, selectors, and command snippets with your project-specific values.\n\n\u003Cintake>\n\n## What do you need help with?\n\nChoose one intent:\n\n1. **patterns** - Test design, selectors, waits, and reliability techniques\n2. **setup** - Playwright installation, config, environments, and CI basics\n3. **quickstart** - Minimal path to run first E2E test\n\nWhat do you want to do? _(patterns\u002Fsetup\u002Fquickstart)_\n\n\u003C\u002Fintake>\n\n\u003Crouting>\n\n## Response Routing\n\n| Response   | File                                  | Purpose                                                         |\n| ---------- | ------------------------------------- | --------------------------------------------------------------- |\n| patterns   | `patterns.md`                         | Test-writing patterns, anti-flake practices, and debugging flow |\n| setup      | `playwright-setup.md`                 | Setup steps, config model, environment strategy, and CI notes   |\n| quickstart | `playwright-setup.md` → `patterns.md` | Stand up tooling first, then apply stable test patterns         |\n\n\u003C\u002Frouting>\n\n## Quick Principles\n\n- Prefer user-visible assertions over implementation details\n- Use robust locators (`getByRole`, `getByLabel`, `getByTestId`) before CSS\u002FXPath\n- Keep tests isolated and data-independent\n- Minimize fixed sleeps; rely on Playwright auto-wait and explicit expect conditions\n- Stabilize E2E by controlling auth, test data, and network behavior\n\n## References\n\n- `patterns.md` - Practical E2E patterns and pitfalls\n- `playwright-setup.md` - Setup and environment configuration\n\n## Gotchas\n\n| Trigger                                                              | Gotcha                                                           | Fix                                                                                                               |\n| -------------------------------------------------------------------- | ---------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |\n| Using `div > ul > li:nth-child(3) > button` as a locator             | Breaks on any DOM restructure, even visually invisible ones      | Use `getByRole` > `getByLabel` > `getByTestId` > CSS (last resort)                                                |\n| `await page.waitForTimeout(3000)` to wait for readiness              | Adds hard delay to every run; flakes on slow CI                  | Replace with `await expect(locator).toBeVisible()` using Playwright auto-wait                                     |\n| Asserting immediately after an action without waiting for the result | Race condition; flakes on slow renders                           | Use Playwright's built-in auto-wait: `await expect(locator).toHaveText(...)`                                      |\n| Test B passes only when test A runs first                            | Order-dependent suite fails on parallel CI runs                  | Each test creates and owns its own data; tear down on completion                                                  |\n| Running full login UI flow for most tests                            | Login is not re-tested; you're paying time cost repeatedly       | Use `storageState` for authenticated tests; reserve full login UI for a small smoke subset                        |\n| One test scenario covers three different features                    | A failure in one feature fails the entire test; hard to diagnose | One scenario per test; group by feature or user journey                                                           |\n| Retrying a flaky test and moving on when it passes                   | Root cause unknown; intermittent issue will recur                | Repro with retries disabled; capture `--trace on` artifacts; investigate selector stability and async assumptions |\n","# Web App Testing Skill\n\n## Overview\n\nThis skill provides practical Playwright E2E guidance for reliable web app testing across local and CI environments.\n\n> **[CUSTOMIZE]** Replace sample URLs, auth flows, selectors, and command snippets with your project-specific values.\n\n\u003Cintake>\n\n## What do you need help with?\n\nChoose one intent:\n\n1. **patterns** - Test design, selectors, waits, and reliability techniques\n2. **setup** - Playwright installation, config, environments, and CI basics\n3. **quickstart** - Minimal path to run first E2E test\n\nWhat do you want to do? _(patterns\u002Fsetup\u002Fquickstart)_\n\n\u003C\u002Fintake>\n\n\u003Crouting>\n\n## Response Routing\n\n| Response   | File                                  | Purpose                                                         |\n| ---------- | ------------------------------------- | --------------------------------------------------------------- |\n| patterns   | `patterns.md`                         | Test-writing patterns, anti-flake practices, and debugging flow |\n| setup      | `playwright-setup.md`                 | Setup steps, config model, environment strategy, and CI notes   |\n| quickstart | `playwright-setup.md` → `patterns.md` | Stand up tooling first, then apply stable test patterns         |\n\n\u003C\u002Frouting>\n\n## Quick Principles\n\n- Prefer user-visible assertions over implementation details\n- Use robust locators (`getByRole`, `getByLabel`, `getByTestId`) before CSS\u002FXPath\n- Keep tests isolated and data-independent\n- Minimize fixed sleeps; rely on Playwright auto-wait and explicit expect conditions\n- Stabilize E2E by controlling auth, test data, and network behavior\n\n## References\n\n- `patterns.md` - Practical E2E patterns and pitfalls\n- `playwright-setup.md` - Setup and environment configuration\n\n## Gotchas\n\n| Trigger                                                              | Gotcha                                                           | Fix                                                                                                               |\n| -------------------------------------------------------------------- | ---------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |\n| Using `div > ul > li:nth-child(3) > button` as a locator             | Breaks on any DOM restructure, even visually invisible ones      | Use `getByRole` > `getByLabel` > `getByTestId` > CSS (last resort)                                                |\n| `await page.waitForTimeout(3000)` to wait for readiness              | Adds hard delay to every run; flakes on slow CI                  | Replace with `await expect(locator).toBeVisible()` using Playwright auto-wait                                     |\n| Asserting immediately after an action without waiting for the result | Race condition; flakes on slow renders                           | Use Playwright's built-in auto-wait: `await expect(locator).toHaveText(...)`                                      |\n| Test B passes only when test A runs first                            | Order-dependent suite fails on parallel CI runs                  | Each test creates and owns its own data; tear down on completion                                                  |\n| Running full login UI flow for most tests                            | Login is not re-tested; you're paying time cost repeatedly       | Use `storageState` for authenticated tests; reserve full login UI for a small smoke subset                        |\n| One test scenario covers three different features                    | A failure in one feature fails the entire test; hard to diagnose | One scenario per test; group by feature or user journey                                                           |\n| Retrying a flaky test and moving on when it passes                   | Root cause unknown; intermittent issue will recur                | Repro with retries disabled; capture `--trace on` artifacts; investigate selector stability and async assumptions |\n",{"name":5,"description":7},"main","d5486aacc32c9ca1b07173cfd530f8fe75c29e58","skills\u002Fwebapp-testing",0,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra","https:\u002F\u002Fgithub.com\u002FGrimblaz","2026-08-16 01:12:46",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add Grimblaz\u002Fagent-orchestra --skill webapp-testing",{"tool":64,"command":65},"bunx","bunx skills add Grimblaz\u002Fagent-orchestra --skill webapp-testing",{"tool":67,"command":68},"pnpm","pnpm dlx skills add Grimblaz\u002Fagent-orchestra --skill webapp-testing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fwebapp-testing\u002FSKILL.md",true,[72,78],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"patterns.md","REFERENCE","参考文档",2527,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fwebapp-testing\u002Fpatterns.md",{"path":79,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":80,"sourceHtmlUrl":81},"playwright-setup.md",2583,"https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fwebapp-testing\u002Fplaywright-setup.md",[83,108,124,152,173,192],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":46},"01M6C48TNNP2KCSQXV8YK7SK49","verification-before-completion","Evidence-based verification checklist before marking work complete. Use before PRs, releases, marking tickets done, or any \"I'm finished\" declaration; also when naming a baseline commit for a differential suite claim, when designing a mutation campaign or red-run evidence, when making an absence claim, a universal claim, or a one-time demonstration offered as a standing guarantee, when attributing a measurement or claiming a sweep or verification loop is complete, and when stating what a check or a CI suite will do about a change. DO NOT USE FOR: post-merge cleanup or archival (use post-pr-review) or processing GitHub review comments (use code-review-intake).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fverification-before-completion\u002FSKILL.md",[],[90,91,92,93,94,95,96,97,98,99,100,101,35,102,103,104,105,30,106,107],"verification","verification before completion","review","change","commit","merge","pr","cleanup","run","code","code-review","intake","loop","verification loop","work","check","evidence","campaign",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":114,"publishedAt":46},"01M6C48QZWNTP7JGKD32QZAKKX","validation-methodology","Reusable validation and review methodology for staged validation, failure triage, and prosecution-depth setup. Use when running validation ladders, triaging failures, or executing adversarial review passes. DO NOT USE FOR: CE Gate orchestration, specialist dispatch ownership, or step execution flow (keep those in Code-Conductor).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fvalidation-methodology\u002FSKILL.md",[],[115,116,117,92,118,119,120,121,99,122,34,30,123],"validation","methodology","validation methodology","triage","orchestration","setup","adversarial review","flow","dispatch",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":138,"publishedAt":46},"01M6C48MCAHG5Z79BJ369CRYRZ","upstream-onboarding","Shared opening-phase protocol for upstream agents (Experience-Owner, Solution-Designer, Issue-Planner) and Code-Conductor when invoked on an existing GitHub issue. Renders a scaled context brief and runs a standards check on inherited work at each phase boundary. Use when a user-invocable agent receives a request referencing an existing GitHub issue and must load solution-authoring and upstream-onboarding at the opening phase. DO NOT USE FOR: subagent dispatches (which already operate within an assessed session context); post-merge review (use post-pr-review); research or non-tree subagents.","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fupstream-onboarding\u002FSKILL.md",[130,133],{"categoryNo":131,"categoryName":132,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":134,"categoryName":135,"taxonomyType":136,"taxonomyTypeDesc":137},"01JBSEEDCAT000000000000038","人力资源","PROFESSION","适用职业",[139,140,92,141,142,95,143,96,99,144,145,146,147,148,149,104,105,150,151,30],"onboarding","upstream onboarding","github","research","standards check","protocol","brief","boundary","designer","subagent","planner","user","session",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":166,"publishedAt":46},"01M6C48GPVE120TGPMD1CS365H","ui-testing","Resilient React component testing strategies focusing on user behavior. Use when writing or reviewing component-level React tests, fixing flaky component tests, or establishing React testing patterns. DO NOT USE FOR: Playwright E2E tests (use webapp-testing), canvas game interaction (use browser-canvas-testing), TDD workflow (use test-driven-development), debugging failures (use systematic-debugging), UI component design (use frontend-design), or randomized property tests (use property-based-testing).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fui-testing\u002FSKILL.md",[158,159,160,163],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":161,"categoryName":162,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":164,"categoryName":165,"taxonomyType":136,"taxonomyTypeDesc":137},"01JBSEEDCAT000000000000032","设计师",[28,167,168,169,170,171,37,44,43,42,40,39,38,29,36,172,33,32,30,27],"ui","ui testing","frontend","design","writing","testing patterns",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":181,"publishedAt":46},"01M6C48DRJ9XBDR2FW0W37DY53","ui-iteration","Reusable screenshot-driven UI polish workflow for iterative visual refinement. Use when improving layout, hierarchy, spacing, feedback, or Tailwind-based presentation through repeated review-and-adjust passes. DO NOT USE FOR: functional bug fixing, accessibility-only audits, or major redesign strategy work (use Code-Smith or frontend-design).","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Fui-iteration\u002FSKILL.md",[179,180],{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":164,"categoryName":165,"taxonomyType":136,"taxonomyTypeDesc":137},[167,182,169,170,92,44,183,99,184,185,186,187,188,104,189,190,30,191],"ui iteration","accessibility","screenshot","Tailwind","polish","ui polish","feedback","redesign","strategy","only",{"skillNo":193,"name":194,"nameZh":6,"description":195,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":196,"categories":197,"keywords":198,"publishedAt":46},"01M6C48B7PAY03MSRVKNZVYFT4","tracking-format","Tracking-file frontmatter and coordination format guidance. Use when creating or reviewing local tracking files and related handoff conventions. DO NOT USE FOR: session-memory plan authoring rules outside the documented references here.","https:\u002F\u002Fgithub.com\u002FGrimblaz\u002Fagent-orchestra\u002Fblob\u002Fmain\u002Fskills\u002Ftracking-format\u002FSKILL.md",[],[199,200,201,202,203,204,205,206,207,151,30,208],"format","tracking","tracking format","handoff","memory","file","plan","coordination","Rules","plan authoring"]