[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7EVCB4Y2T112WJMFPE4Q58S":3,"skill-same:01M7EVCB4Y2T112WJMFPE4Q58S":47},{"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":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":25,"commitSha":26,"skillDirectory":27,"forksCount":28,"repositoryHtmlUrl":29,"repositoryHomepageUrl":6,"ownerHtmlUrl":30,"ownerBlogUrl":31,"ownerDescription":6,"updatedAt":32,"install":33,"resources":46},"01M7EVCB4Y2T112WJMFPE4Q58S","playwright-pro",null,"Browser automation with Playwright — reliable selectors, waits, and test patterns — use for E2E testing and scripted browsing.","TanNhatCMS\u002Fjarvis","TanNhatCMS","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F113796420?v=4","01M753MV17KG5CD3152G3WQEQY","KietNT","01M7EKEDYVYQ6PWVJJMZ911VMX",0,"MIT","https:\u002F\u002Fgithub.com\u002FTanNhatCMS\u002Fjarvis\u002Fblob\u002Fmain\u002Fskills\u002Fams-playwright-pro\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: playwright-pro\ndescription: Browser automation with Playwright — reliable selectors, waits, and test patterns — use for E2E testing and scripted browsing.\ncategory: web-data\n---\n\n## Overview\n\nPlaywright automates Chromium, Firefox, and WebKit with a modern async API,\nbuilt-in waiting, and first-class test runner integration. Its killer\nfeature is auto-waiting: actions wait for elements to be actionable, which\neliminates most flakiness that plagues browser automation. This skill covers\nwriting Playwright automation that's fast and reliable.\n\n## When to use\n\n- Writing end-to-end tests for web applications\n- Automating browser workflows (form filling, data extraction from JS sites)\n- Testing across Chromium, Firefox, and WebKit\n- Debugging flaky browser tests\n- Generating PDFs\u002Fscreenshots or mocking network responses\n\n## Core concepts\n\n**Auto-waiting beats sleep.** Playwright actions (click, fill, select)\nautomatically wait for the element to be attached, visible, stable, and\nreceiving events. Never use fixed `sleep()` — use explicit waits\n(`waitForSelector`, `expect(...).toBeVisible()`) tied to actual conditions.\nFlaky tests are almost always missing waits in disguise.\n\n**Locators over selectors.** Prefer user-facing locators —\n`getByRole('button', { name: 'Submit' })`, `getByLabel`, `getByText` — over\nCSS\u002FXPath. They mirror how users find elements, survive most refactors, and\nenforce accessibility (if you can't find it by role, screen readers can't\neither). Reserve CSS for layout-specific cases.\n\n**Isolated contexts.** Each test gets a fresh browser context (cookies,\nstorage, sessions isolated) — fast and parallelizable, unlike fresh browser\ninstances. Share authenticated state via storage-state files: log in once,\nsave state, reuse across tests — cutting minutes off suites.\n\n**Network control.** Route interception mocks APIs (`page.route` → fulfill\nwith fixtures) for deterministic tests independent of backends; request\ninspection asserts what the app actually sent. Use mocking for speed and\nstability, but keep a subset of tests hitting real backends to catch\nintegration drift.\n\n**Trace viewer for debugging.** On failure, capture traces (screenshots,\nDOM snapshots, network, console per action) — the trace viewer replays\nexactly what happened. Configure tracing to retain-on-failure; debugging\nfrom a trace beats re-running and hoping.\n\n## Practical workflow\n\n1. **Structure tests by user journey** (not by page object ceremony):\n   arrange → act → assert, with test data seeded via API (faster than UI\n   setup) where possible.\n2. **Write with locators:** roles, labels, and text first; add `data-\n   testid` attributes for elements with no good user-facing handle.\n3. **Handle the async reality:** await every action, assert with\n   auto-retrying `expect` (not manual polling), and wait for network idle\n   or specific responses after actions that trigger requests.\n4. **Isolate and parallelize:** fresh context per test, storage-state for\n   auth, workers for parallelism — keep suites under minutes, not hours.\n5. **Debug with traces:** reproduce locally with `--headed --debug`,\n   inspect the trace timeline for the exact failing action and app state.\n6. **Keep the suite healthy:** quarantine genuinely flaky tests with an\n   owner and deadline (never normalize red), and delete tests that assert\n   nothing meaningful.\n\n## Common pitfalls\n\n- **Fixed sleeps** — `waitForTimeout(3000)` is slow when unnecessary and\n  flaky when insufficient; wait on conditions instead.\n- **Testing implementation details** — asserting on CSS classes or internal\n  state instead of user-visible outcomes; refactors break the suite.\n- **Shared state between tests** — order-dependent tests that pass alone\n  and fail together; isolate via fresh contexts.\n- **Over-mocking** — a suite that mocks everything tests the mocks;\n  balance with real-integration coverage.\n- **Ignoring the other browsers** — Chromium-only testing misses\n  Firefox\u002FWebKit quirks; run the matrix in CI at least for critical paths.\n- **Screenshots as assertions** — pixel comparisons are brittle across\n  environments; assert structure and key visuals, not exact pixels\n  (except dedicated visual-regression setups with controlled baselines).\n","## Overview\n\nPlaywright automates Chromium, Firefox, and WebKit with a modern async API,\nbuilt-in waiting, and first-class test runner integration. Its killer\nfeature is auto-waiting: actions wait for elements to be actionable, which\neliminates most flakiness that plagues browser automation. This skill covers\nwriting Playwright automation that's fast and reliable.\n\n## When to use\n\n- Writing end-to-end tests for web applications\n- Automating browser workflows (form filling, data extraction from JS sites)\n- Testing across Chromium, Firefox, and WebKit\n- Debugging flaky browser tests\n- Generating PDFs\u002Fscreenshots or mocking network responses\n\n## Core concepts\n\n**Auto-waiting beats sleep.** Playwright actions (click, fill, select)\nautomatically wait for the element to be attached, visible, stable, and\nreceiving events. Never use fixed `sleep()` — use explicit waits\n(`waitForSelector`, `expect(...).toBeVisible()`) tied to actual conditions.\nFlaky tests are almost always missing waits in disguise.\n\n**Locators over selectors.** Prefer user-facing locators —\n`getByRole('button', { name: 'Submit' })`, `getByLabel`, `getByText` — over\nCSS\u002FXPath. They mirror how users find elements, survive most refactors, and\nenforce accessibility (if you can't find it by role, screen readers can't\neither). Reserve CSS for layout-specific cases.\n\n**Isolated contexts.** Each test gets a fresh browser context (cookies,\nstorage, sessions isolated) — fast and parallelizable, unlike fresh browser\ninstances. Share authenticated state via storage-state files: log in once,\nsave state, reuse across tests — cutting minutes off suites.\n\n**Network control.** Route interception mocks APIs (`page.route` → fulfill\nwith fixtures) for deterministic tests independent of backends; request\ninspection asserts what the app actually sent. Use mocking for speed and\nstability, but keep a subset of tests hitting real backends to catch\nintegration drift.\n\n**Trace viewer for debugging.** On failure, capture traces (screenshots,\nDOM snapshots, network, console per action) — the trace viewer replays\nexactly what happened. Configure tracing to retain-on-failure; debugging\nfrom a trace beats re-running and hoping.\n\n## Practical workflow\n\n1. **Structure tests by user journey** (not by page object ceremony):\n   arrange → act → assert, with test data seeded via API (faster than UI\n   setup) where possible.\n2. **Write with locators:** roles, labels, and text first; add `data-\n   testid` attributes for elements with no good user-facing handle.\n3. **Handle the async reality:** await every action, assert with\n   auto-retrying `expect` (not manual polling), and wait for network idle\n   or specific responses after actions that trigger requests.\n4. **Isolate and parallelize:** fresh context per test, storage-state for\n   auth, workers for parallelism — keep suites under minutes, not hours.\n5. **Debug with traces:** reproduce locally with `--headed --debug`,\n   inspect the trace timeline for the exact failing action and app state.\n6. **Keep the suite healthy:** quarantine genuinely flaky tests with an\n   owner and deadline (never normalize red), and delete tests that assert\n   nothing meaningful.\n\n## Common pitfalls\n\n- **Fixed sleeps** — `waitForTimeout(3000)` is slow when unnecessary and\n  flaky when insufficient; wait on conditions instead.\n- **Testing implementation details** — asserting on CSS classes or internal\n  state instead of user-visible outcomes; refactors break the suite.\n- **Shared state between tests** — order-dependent tests that pass alone\n  and fail together; isolate via fresh contexts.\n- **Over-mocking** — a suite that mocks everything tests the mocks;\n  balance with real-integration coverage.\n- **Ignoring the other browsers** — Chromium-only testing misses\n  Firefox\u002FWebKit quirks; run the matrix in CI at least for critical paths.\n- **Screenshots as assertions** — pixel comparisons are brittle across\n  environments; assert structure and key visuals, not exact pixels\n  (except dedicated visual-regression setups with controlled baselines).\n",{"name":5,"category":24,"description":7},"web-data","main","af388a77c2fe5e0b4fd879cca4300a0ffa9a6579","skills\u002Fams-playwright-pro",1,"https:\u002F\u002Fgithub.com\u002FTanNhatCMS\u002Fjarvis","https:\u002F\u002Fgithub.com\u002FTanNhatCMS","https:\u002F\u002Fmrkiet.name.vn","2026-11-07 14:23:08",{"source":8,"skillName":5,"commands":34,"prompt":44,"zipAvailable":45},[35,38,41],{"tool":36,"command":37},"npx","npx skills add TanNhatCMS\u002Fjarvis --skill playwright-pro",{"tool":39,"command":40},"bunx","bunx skills add TanNhatCMS\u002Fjarvis --skill playwright-pro",{"tool":42,"command":43},"pnpm","pnpm dlx skills add TanNhatCMS\u002Fjarvis --skill playwright-pro","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FTanNhatCMS\u002Fjarvis\u002Fblob\u002Fmain\u002Fskills\u002Fams-playwright-pro\u002FSKILL.md",true,[],[48,55,63,70,77,84],{"skillNo":49,"name":50,"nameZh":6,"description":51,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":52,"categories":53,"keywords":54,"publishedAt":19},"01M7EWYJR0J8DARY7E59Z6Y9MV","web-scrape","Turn web pages into LLM-ready markdown via the Firecrawl API (renders JS, anti-bot handling). Use when browser_open\u002Ffetch fails on JS-heavy pages, or when you need clean markdown\u002Fstructured extraction from a site. Requires FIRECRAWL_API_KEY.","https:\u002F\u002Fgithub.com\u002FTanNhatCMS\u002Fjarvis\u002Fblob\u002Fmain\u002Fskills\u002Fweb-scrape\u002FSKILL.md",[],[],{"skillNo":56,"name":57,"nameZh":6,"description":58,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":59,"sourceHtmlUrl":60,"categories":61,"keywords":62,"publishedAt":19},"01M7EWYBN5P6F2AJG3FR24T9BP","design-taste-frontend","tasteskill v2, the anti-slop frontend skill. Art direction for websites, distilled from a study of 247 curated gallery sites (One Page Love, Awwwards Sites of the Day). Deals researched directions (idea, composition, type, palette, photographs, section blueprints) from a library, enforces a strict no-slop house style with a real-browser inspector, and runs a look-and-fix loop on screenshots. Use this whenever you build, design, redesign, restyle, polish or review a landing page, marketing site, portfolio, product page, one-pager, hero or any public-facing web page, in any stack (HTML\u002FCSS, React, Next.js, Vue, Svelte, Astro, Tailwind) — also when the user says a page looks generic, templated, \"AI-made\", sloppy, or asks to make it look designed, premium, award-level or less like every other site. Not for dashboards or app screens.","https:\u002F\u002Fgithub.com\u002FTanNhatCMS\u002Fjarvis\u002Fblob\u002Fmain\u002Fskills\u002Ftaste-design\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FTanNhatCMS\u002Fjarvis\u002Fblob\u002Fmain\u002Fskills\u002Ftaste-design\u002FSKILL.md",[],[],{"skillNo":64,"name":65,"nameZh":6,"description":66,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":67,"categories":68,"keywords":69,"publishedAt":19},"01M7EWY8FQFNQ2GB7NZZWGSSDX","test-driven-development","Use when implementing any feature or bugfix, before writing implementation code","https:\u002F\u002Fgithub.com\u002FTanNhatCMS\u002Fjarvis\u002Fblob\u002Fmain\u002Fskills\u002Fsuperpowers-tdd\u002FSKILL.md",[],[],{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":19},"01M7EWY5SHBFRH1HDHVWM9K7TV","systematic-debugging","Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes","https:\u002F\u002Fgithub.com\u002FTanNhatCMS\u002Fjarvis\u002Fblob\u002Fmain\u002Fskills\u002Fsuperpowers-debugging\u002FSKILL.md",[],[],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":83,"publishedAt":19},"01M7EWY3NM0Z0JAKS7HDZ24K66","requesting-code-review","Use when completing tasks, implementing major features, or before merging to verify work meets requirements","https:\u002F\u002Fgithub.com\u002FTanNhatCMS\u002Fjarvis\u002Fblob\u002Fmain\u002Fskills\u002Fsuperpowers-code-review\u002FSKILL.md",[],[],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":19},"01M7EWY0WRMWX4M9ZFY0WKC593","brainstorming","You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or planning anything new, in software or out of it (a talk, a business, a renovation).","https:\u002F\u002Fgithub.com\u002FTanNhatCMS\u002Fjarvis\u002Fblob\u002Fmain\u002Fskills\u002Fsuperpowers-brainstorming\u002FSKILL.md",[],[]]