[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DNENECDN4W0V2HV2BNP352":3,"skill-same:01M6DNENECDN4W0V2HV2BNP352":78},{"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":31,"publishedAt":52,"linkOnly":53,"markdownContent":54,"markdownBody":55,"frontMatter":56,"refName":57,"commitSha":58,"skillDirectory":59,"forksCount":60,"repositoryHtmlUrl":61,"repositoryHomepageUrl":6,"ownerHtmlUrl":62,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":63,"install":64,"resources":77},"01M6DNENECDN4W0V2HV2BNP352","aac-frontend-ui-engineering",null,"Engineers the implementation of user interfaces: component design, props contracts, state management, accessibility, and performance. Use when building or modifying any UI component, when designing a new component interface, when reviewing frontend code, or when fixing UI performance or accessibility issues. Pairs with aac-ux (which designs the user experience) and aac-create-ux-design (which produces the design spec) by handling the code that brings the design to life.","msayedshokry\u002FAgileAgentCanvasExt","msayedshokry","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F35009459?v=4","01M6DN5RZZ297CGWTNJ6ERZQ8W","Mohamed Sayed","01M6DN5S4XS7SVCSXZRW2XR0XF",3,"MIT","https:\u002F\u002Fgithub.com\u002Fmsayedshokry\u002FAgileAgentCanvasExt\u002Fblob\u002Fmain\u002Fresources\u002F_aac\u002Fskills\u002Faac-frontend-ui-engineering\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51],"aac frontend ui engineering","frontend ui engineering","engineering","ui","frontend","issues","life","ux-design","ui component","use","ux","state","code","state management","create","component","accessibility","performance","spec","design","2026-11-10 10:12:30",false,"---\nname: aac-frontend-ui-engineering\ndescription: 'Engineers the implementation of user interfaces: component design, props contracts, state management, accessibility, and performance. Use when building or modifying any UI component, when designing a new component interface, when reviewing frontend code, or when fixing UI performance or accessibility issues. Pairs with aac-ux (which designs the user experience) and aac-create-ux-design (which produces the design spec) by handling the code that brings the design to life.'\n---\n\n# Frontend UI Engineering\n\nThe code that brings the design to life. A `Button` is not just a styled `\u003Cbutton>` — it is a contract (props), a state machine (pressed \u002F focused \u002F disabled \u002F loading), an accessibility surface (keyboard, screen reader, focus management), and a performance budget (re-renders, bundle size, paint time). This skill is the discipline of building components that meet the contract on all four axes at once.\n\n## Overview\n\nFrontend engineering is the layer where the *design* (from `aac-ux`), the *spec* (from `aac-create-ux-design`), and the *runtime* (the framework, the bundler, the browser) all meet. The work is to make the implementation match the design while honoring the runtime's constraints. The skill is the discipline of *all four axes at once*, not one axis at a time and then the others.\n\n## When to Use\n\n- Building or modifying a UI component\n- Designing a new component's props interface\n- Reviewing frontend code for correctness, accessibility, or performance\n- Diagnosing a UI performance issue (slow render, janky scroll, paint flicker)\n- Fixing an accessibility issue (focus trap, missing label, color contrast)\n- A UI library or framework is being adopted or migrated\n- The frontend is being added to a project that did not have one\n\n**When NOT to use:**\n\n- The work is design-only (mockups, wireframes) — use `aac-ux`\n- The work is the design spec only — use `aac-create-ux-design`\n- The work is a content or copy change, not a code change\n- The component is a one-off in a single page, not a reusable surface\n\n## The Four Axes\n\nEvery UI component has four surfaces. Missing any one of them produces a component that *looks* right but fails on a different dimension.\n\n### 1. Contract (the props)\n\nThe props are the *interface* the component presents to the rest of the codebase. The contract should be:\n\n- **Small** — fewer props, each load-bearing. A component with 20 props is doing 20 things; a component with 3 is doing 3.\n- **Typed** — every prop has a type. `string` is rarely right; the union of the actual values is.\n- **Required vs optional** — defaults should not hide required values. If a prop must be set, it is required.\n- **Composable** — `children` and `className` (or the framework equivalent) pass through. The component does not own layout.\n\n### 2. State (the lifecycle)\n\nA component has states even when it has no `useState`. The states are: *unmounted* (no DOM), *mounted* (initial render), *interactive* (responding to user), *loading* (waiting for async), *disabled* (user cannot interact), *error* (something failed), *unmounted* (cleanup). Each state has a visual, an a11y label, and a behaviour:\n\n- **Loading** — show a spinner or skeleton, mark the component `aria-busy=\"true\"`, do not block the rest of the page.\n- **Disabled** — visually distinct, marked `aria-disabled=\"true\"`, *not* removed from the tab order. (A disabled button is still in the tab order; a hidden one is not.)\n- **Error** — the error is announced (`role=\"alert\"` or live region), the input that caused the error gets focus, the message is in plain language, not a stack trace.\n\nThe state transitions are explicit. The component does not silently get into a state the design did not name.\n\n### 3. Accessibility (the surface)\n\nThe component is accessible by default, not as a follow-up. The a11y checks are in the implementation, not the QA pass:\n\n- **Keyboard** — every interactive element is reachable via Tab, every action is triggerable via Enter or Space, the focus order matches the visual order.\n- **Screen reader** — every interactive element has an accessible name, every state change is announced, every error is announced.\n- **Focus management** — when a modal opens, focus moves into it; when it closes, focus returns to the trigger. When content is added dynamically, focus is managed or the change is announced.\n- **Contrast** — text and interactive elements meet WCAG AA (4.5:1 for text, 3:1 for UI). The component's colors come from the design tokens, which are validated once at the token level, not per-component.\n- **Motion** — `prefers-reduced-motion` is respected. Animations that are not decorative have a non-motion fallback.\n\n### 4. Performance (the budget)\n\nA component is fast, then it is correct, then it is feature-complete. The performance budget is set before the implementation:\n\n- **Initial render** — under X ms on the target hardware\n- **Re-render** — under Y ms, no full-tree re-renders for a single state change\n- **Bundle size** — under Z KB gzipped for the component alone, under W KB for the full page that contains it\n- **Paint** — the component's first paint under T ms, no layout shift after the first paint\n\nThe budget is met by:\n- Memoizing where it matters (props that are referentially stable, components that re-render on parent state)\n- Lazy-loading below-the-fold components\n- Code-splitting the route or the modal\n- Using the framework's optimization primitives (`useMemo`, `React.memo`, `track`, signals) — not fighting the framework\n\n## The Process\n\n### 1. Read the design and the spec\n\nBefore writing code, read the design (from `aac-ux`) and the spec (from `aac-create-ux-design`). The component is implementing a design that was decided. The spec is the contract the component must meet.\n\n### 2. Pick the smallest primitive that fits\n\nMost components are not new components. A \"feature card\" is a composition of `Card`, `Heading`, `Text`, and `Button`. Before writing a new component, look for an existing one that does 80% of the work. The 20% that is new is the new component.\n\n### 3. Write the contract first\n\nBefore implementation, write the props interface. The interface is the test surface — every behaviour the component promises is reachable through the props. If a behaviour is not in the props, the component does not do it.\n\n### 4. Implement the states\n\nImplement the states in order: mounted, interactive, loading, disabled, error. Each state has a visual, an a11y label, and a behaviour. The states are tested individually, not just as the \"happy path.\"\n\n### 5. Wire the accessibility\n\nRun the keyboard test: can I reach every interactive element with Tab? Can I trigger every action with Enter\u002FSpace? Run the screen reader test: does every element have a name, every state change announce? Run the focus test: when the modal opens, where does focus go? When it closes, does it return?\n\n### 6. Measure the performance\n\nRun the perf budget. If the initial render is over budget, find the cause (large bundle, expensive computation, blocking I\u002FO). Do not ship a component that misses the budget on the target hardware. The user pays the cost of every missed budget.\n\n### 7. Review the four axes\n\nBefore merging, walk the four axes:\n\n- Contract: small, typed, composable?\n- State: every state explicit, every transition tested?\n- Accessibility: keyboard, screen reader, focus, contrast, motion?\n- Performance: budget met on the target hardware?\n\nAny unchecked axis is a merge blocker.\n\n## Common Rationalizations\n\n| Rationalization | Reality |\n|---|---|\n| \"It's just a button\" | Buttons have 5+ states, an a11y contract, and a focus story. \"Just\" is doing a lot of work. |\n| \"We'll add accessibility later\" | Retrofitting a11y is more expensive than building it in. The skip is a debt, not a saving. |\n| \"The design system handles it\" | The design system handles the visual layer. The component handles the contract, the state, the runtime. The design system is the input, not the output. |\n| \"Performance can be optimized later\" | Performance budgets are easier to meet during implementation. The cost of fixing perf after a component is in production is much higher. |\n| \"We don't need to memoize, React is fast\" | React is fast until it is not. Memoize where the measurement says it matters, not where you guess. |\n| \"It's not visible without JS\" | Progressive enhancement is a real discipline. The choice to require JS is a choice, not a default. |\n| \"The user can just refresh\" | A user who refreshes is a user who has lost state. The fix for a render bug is a render fix, not a refresh instruction. |\n| \"Animation makes it feel faster\" | Animation makes the user *feel* the wait less. It does not make the wait shorter. Use animation to clarify, not to hide. |\n| \"We'll add the disabled state if we need it\" | Disabled is a state, not a feature. It is needed by every interactive component. Build it. |\n\n## Red Flags\n\n- The component has more than 12 props\n- A required prop has a default value (the prop is optional, name it that way)\n- The disabled state is \"the button is grey\" with no `aria-disabled`\n- The error state is a `console.error` with no user-facing message\n- The component re-renders on every parent state change\n- The bundle size of the page that contains the component is over 250 KB gzipped\n- The keyboard test fails: Tab does not reach a control, or Enter does not trigger an action\n- The screen reader test fails: a button has no accessible name, or a state change is silent\n- The component is built without reading the design spec\n- The component is built by writing CSS first, props second\n- The component's \"loading\" state is the entire page freezing for 3 seconds\n\n## Verification\n\nBefore a UI component is merged:\n\n- [ ] Props interface is small, typed, and composable; `children` passes through\n- [ ] Required props are required; optional props have explicit defaults\n- [ ] Every state (mounted, interactive, loading, disabled, error) is implemented and tested\n- [ ] Keyboard test: every interactive element is reachable and triggerable\n- [ ] Screen reader test: every element has an accessible name, every state change is announced\n- [ ] Focus management: modals trap focus, content changes move focus correctly\n- [ ] Contrast meets WCAG AA on all states (use the design tokens, not raw colors)\n- [ ] `prefers-reduced-motion` is respected\n- [ ] Performance budget is met on the target hardware (initial render, re-render, bundle, paint)\n- [ ] No `console.error` or warning in the browser console\n- [ ] Component is built from the design spec, not in parallel to it\n","# Frontend UI Engineering\n\nThe code that brings the design to life. A `Button` is not just a styled `\u003Cbutton>` — it is a contract (props), a state machine (pressed \u002F focused \u002F disabled \u002F loading), an accessibility surface (keyboard, screen reader, focus management), and a performance budget (re-renders, bundle size, paint time). This skill is the discipline of building components that meet the contract on all four axes at once.\n\n## Overview\n\nFrontend engineering is the layer where the *design* (from `aac-ux`), the *spec* (from `aac-create-ux-design`), and the *runtime* (the framework, the bundler, the browser) all meet. The work is to make the implementation match the design while honoring the runtime's constraints. The skill is the discipline of *all four axes at once*, not one axis at a time and then the others.\n\n## When to Use\n\n- Building or modifying a UI component\n- Designing a new component's props interface\n- Reviewing frontend code for correctness, accessibility, or performance\n- Diagnosing a UI performance issue (slow render, janky scroll, paint flicker)\n- Fixing an accessibility issue (focus trap, missing label, color contrast)\n- A UI library or framework is being adopted or migrated\n- The frontend is being added to a project that did not have one\n\n**When NOT to use:**\n\n- The work is design-only (mockups, wireframes) — use `aac-ux`\n- The work is the design spec only — use `aac-create-ux-design`\n- The work is a content or copy change, not a code change\n- The component is a one-off in a single page, not a reusable surface\n\n## The Four Axes\n\nEvery UI component has four surfaces. Missing any one of them produces a component that *looks* right but fails on a different dimension.\n\n### 1. Contract (the props)\n\nThe props are the *interface* the component presents to the rest of the codebase. The contract should be:\n\n- **Small** — fewer props, each load-bearing. A component with 20 props is doing 20 things; a component with 3 is doing 3.\n- **Typed** — every prop has a type. `string` is rarely right; the union of the actual values is.\n- **Required vs optional** — defaults should not hide required values. If a prop must be set, it is required.\n- **Composable** — `children` and `className` (or the framework equivalent) pass through. The component does not own layout.\n\n### 2. State (the lifecycle)\n\nA component has states even when it has no `useState`. The states are: *unmounted* (no DOM), *mounted* (initial render), *interactive* (responding to user), *loading* (waiting for async), *disabled* (user cannot interact), *error* (something failed), *unmounted* (cleanup). Each state has a visual, an a11y label, and a behaviour:\n\n- **Loading** — show a spinner or skeleton, mark the component `aria-busy=\"true\"`, do not block the rest of the page.\n- **Disabled** — visually distinct, marked `aria-disabled=\"true\"`, *not* removed from the tab order. (A disabled button is still in the tab order; a hidden one is not.)\n- **Error** — the error is announced (`role=\"alert\"` or live region), the input that caused the error gets focus, the message is in plain language, not a stack trace.\n\nThe state transitions are explicit. The component does not silently get into a state the design did not name.\n\n### 3. Accessibility (the surface)\n\nThe component is accessible by default, not as a follow-up. The a11y checks are in the implementation, not the QA pass:\n\n- **Keyboard** — every interactive element is reachable via Tab, every action is triggerable via Enter or Space, the focus order matches the visual order.\n- **Screen reader** — every interactive element has an accessible name, every state change is announced, every error is announced.\n- **Focus management** — when a modal opens, focus moves into it; when it closes, focus returns to the trigger. When content is added dynamically, focus is managed or the change is announced.\n- **Contrast** — text and interactive elements meet WCAG AA (4.5:1 for text, 3:1 for UI). The component's colors come from the design tokens, which are validated once at the token level, not per-component.\n- **Motion** — `prefers-reduced-motion` is respected. Animations that are not decorative have a non-motion fallback.\n\n### 4. Performance (the budget)\n\nA component is fast, then it is correct, then it is feature-complete. The performance budget is set before the implementation:\n\n- **Initial render** — under X ms on the target hardware\n- **Re-render** — under Y ms, no full-tree re-renders for a single state change\n- **Bundle size** — under Z KB gzipped for the component alone, under W KB for the full page that contains it\n- **Paint** — the component's first paint under T ms, no layout shift after the first paint\n\nThe budget is met by:\n- Memoizing where it matters (props that are referentially stable, components that re-render on parent state)\n- Lazy-loading below-the-fold components\n- Code-splitting the route or the modal\n- Using the framework's optimization primitives (`useMemo`, `React.memo`, `track`, signals) — not fighting the framework\n\n## The Process\n\n### 1. Read the design and the spec\n\nBefore writing code, read the design (from `aac-ux`) and the spec (from `aac-create-ux-design`). The component is implementing a design that was decided. The spec is the contract the component must meet.\n\n### 2. Pick the smallest primitive that fits\n\nMost components are not new components. A \"feature card\" is a composition of `Card`, `Heading`, `Text`, and `Button`. Before writing a new component, look for an existing one that does 80% of the work. The 20% that is new is the new component.\n\n### 3. Write the contract first\n\nBefore implementation, write the props interface. The interface is the test surface — every behaviour the component promises is reachable through the props. If a behaviour is not in the props, the component does not do it.\n\n### 4. Implement the states\n\nImplement the states in order: mounted, interactive, loading, disabled, error. Each state has a visual, an a11y label, and a behaviour. The states are tested individually, not just as the \"happy path.\"\n\n### 5. Wire the accessibility\n\nRun the keyboard test: can I reach every interactive element with Tab? Can I trigger every action with Enter\u002FSpace? Run the screen reader test: does every element have a name, every state change announce? Run the focus test: when the modal opens, where does focus go? When it closes, does it return?\n\n### 6. Measure the performance\n\nRun the perf budget. If the initial render is over budget, find the cause (large bundle, expensive computation, blocking I\u002FO). Do not ship a component that misses the budget on the target hardware. The user pays the cost of every missed budget.\n\n### 7. Review the four axes\n\nBefore merging, walk the four axes:\n\n- Contract: small, typed, composable?\n- State: every state explicit, every transition tested?\n- Accessibility: keyboard, screen reader, focus, contrast, motion?\n- Performance: budget met on the target hardware?\n\nAny unchecked axis is a merge blocker.\n\n## Common Rationalizations\n\n| Rationalization | Reality |\n|---|---|\n| \"It's just a button\" | Buttons have 5+ states, an a11y contract, and a focus story. \"Just\" is doing a lot of work. |\n| \"We'll add accessibility later\" | Retrofitting a11y is more expensive than building it in. The skip is a debt, not a saving. |\n| \"The design system handles it\" | The design system handles the visual layer. The component handles the contract, the state, the runtime. The design system is the input, not the output. |\n| \"Performance can be optimized later\" | Performance budgets are easier to meet during implementation. The cost of fixing perf after a component is in production is much higher. |\n| \"We don't need to memoize, React is fast\" | React is fast until it is not. Memoize where the measurement says it matters, not where you guess. |\n| \"It's not visible without JS\" | Progressive enhancement is a real discipline. The choice to require JS is a choice, not a default. |\n| \"The user can just refresh\" | A user who refreshes is a user who has lost state. The fix for a render bug is a render fix, not a refresh instruction. |\n| \"Animation makes it feel faster\" | Animation makes the user *feel* the wait less. It does not make the wait shorter. Use animation to clarify, not to hide. |\n| \"We'll add the disabled state if we need it\" | Disabled is a state, not a feature. It is needed by every interactive component. Build it. |\n\n## Red Flags\n\n- The component has more than 12 props\n- A required prop has a default value (the prop is optional, name it that way)\n- The disabled state is \"the button is grey\" with no `aria-disabled`\n- The error state is a `console.error` with no user-facing message\n- The component re-renders on every parent state change\n- The bundle size of the page that contains the component is over 250 KB gzipped\n- The keyboard test fails: Tab does not reach a control, or Enter does not trigger an action\n- The screen reader test fails: a button has no accessible name, or a state change is silent\n- The component is built without reading the design spec\n- The component is built by writing CSS first, props second\n- The component's \"loading\" state is the entire page freezing for 3 seconds\n\n## Verification\n\nBefore a UI component is merged:\n\n- [ ] Props interface is small, typed, and composable; `children` passes through\n- [ ] Required props are required; optional props have explicit defaults\n- [ ] Every state (mounted, interactive, loading, disabled, error) is implemented and tested\n- [ ] Keyboard test: every interactive element is reachable and triggerable\n- [ ] Screen reader test: every element has an accessible name, every state change is announced\n- [ ] Focus management: modals trap focus, content changes move focus correctly\n- [ ] Contrast meets WCAG AA on all states (use the design tokens, not raw colors)\n- [ ] `prefers-reduced-motion` is respected\n- [ ] Performance budget is met on the target hardware (initial render, re-render, bundle, paint)\n- [ ] No `console.error` or warning in the browser console\n- [ ] Component is built from the design spec, not in parallel to it\n",{"name":5,"description":7},"main","473351382920a74eb8f353f979a06f6f05bb5f59","resources\u002F_aac\u002Fskills\u002Faac-frontend-ui-engineering",0,"https:\u002F\u002Fgithub.com\u002Fmsayedshokry\u002FAgileAgentCanvasExt","https:\u002F\u002Fgithub.com\u002Fmsayedshokry","2026-08-29 02:00:07",{"source":8,"skillName":5,"commands":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add msayedshokry\u002FAgileAgentCanvasExt --skill aac-frontend-ui-engineering",{"tool":70,"command":71},"bunx","bunx skills add msayedshokry\u002FAgileAgentCanvasExt --skill aac-frontend-ui-engineering",{"tool":73,"command":74},"pnpm","pnpm dlx skills add msayedshokry\u002FAgileAgentCanvasExt --skill aac-frontend-ui-engineering","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmsayedshokry\u002FAgileAgentCanvasExt\u002Fblob\u002Fmain\u002Fresources\u002F_aac\u002Fskills\u002Faac-frontend-ui-engineering\u002FSKILL.md",true,[],[79,104,122,135,153,168],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":91,"publishedAt":52},"01M6DNRTHE3M1XG3KDJTEF6BG6","bmad-teach-me-testing","Teach testing progressively through structured sessions. Use when user says \"lets learn testing\" or \"I want to study test practices\"","https:\u002F\u002Fgithub.com\u002Fmsayedshokry\u002FAgileAgentCanvasExt\u002Fblob\u002Fmain\u002Fresources\u002F_aac\u002Ftea\u002Fworkflows\u002Ftestarch\u002Fbmad-teach-me-testing\u002FSKILL.md",[85,88],{"categoryNo":86,"categoryName":87,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":89,"categoryName":90,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000039","教师与教育",[92,93,94,95,96,97,98,99,100,101,41,102,103],"bmad","me","bmad teach me testing","teach me","teach","testing","test","sessions","learn","user","study","structured",{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":111,"publishedAt":52},"01M6DNRG27V77JEGMPMJVRY0Q5","aac-testarch-trace","Generate traceability matrix and quality gate decision. Use when the user says \"lets create traceability matrix\" or \"I want to analyze test coverage\"","https:\u002F\u002Fgithub.com\u002Fmsayedshokry\u002FAgileAgentCanvasExt\u002Fblob\u002Fmain\u002Fresources\u002F_aac\u002Ftea\u002Fworkflows\u002Ftestarch\u002Faac-testarch-trace\u002FSKILL.md",[110],{"categoryNo":86,"categoryName":87,"taxonomyType":21,"taxonomyTypeDesc":22},[112,113,98,114,46,115,116,117,118,101,119,41,120,121],"aac testarch trace","trace","quality gate","generate","analyze","quality","decision","coverage","test coverage","gate",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":129,"publishedAt":52},"01M6DNR70G1S0DGDSHRWT1S1DD","aac-testarch-test-review","Review test quality using best practices validation. Use when user says \"lets review tests\" or \"I want to evaluate test quality\"","https:\u002F\u002Fgithub.com\u002Fmsayedshokry\u002FAgileAgentCanvasExt\u002Fblob\u002Fmain\u002Fresources\u002F_aac\u002Ftea\u002Fworkflows\u002Ftestarch\u002Faac-testarch-test-review\u002FSKILL.md",[128],{"categoryNo":86,"categoryName":87,"taxonomyType":21,"taxonomyTypeDesc":22},[130,131,98,132,133,117,101,41,134],"review","aac testarch test review","best practices","validation","tests",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":144,"publishedAt":52},"01M6DNQXV8F40EE78ZMWGWRPJM","aac-testarch-test-design","Create system-level or epic-level test plans. Use when the user says \"lets design test plan\" or \"I want to create test strategy\"","https:\u002F\u002Fgithub.com\u002Fmsayedshokry\u002FAgileAgentCanvasExt\u002Fblob\u002Fmain\u002Fresources\u002F_aac\u002Ftea\u002Fworkflows\u002Ftestarch\u002Faac-testarch-test-design\u002FSKILL.md",[141,142,143],{"categoryNo":86,"categoryName":87,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},[145,146,98,51,101,46,147,148,149,150,41,151,152],"aac testarch test design","test design","test plan","plan","system","strategy","test strategy","plans",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":159,"publishedAt":52},"01M6DNQNG0T7Q5DKV3C03RY35D","aac-testarch-nfr","Audit NFR evidence for performance, security, reliability, and scalability. Use when implementation evidence exists and the user says \"audit NFR evidence\", \"audit NFRs\", or \"evaluate non-functional requirements\"","https:\u002F\u002Fgithub.com\u002Fmsayedshokry\u002FAgileAgentCanvasExt\u002Fblob\u002Fmain\u002Fresources\u002F_aac\u002Ftea\u002Fworkflows\u002Ftestarch\u002Faac-testarch-nfr\u002FSKILL.md",[],[160,161,162,163,164,165,101,166,49,41,167],"aac testarch nfr","reliability","evidence","implementation","scalability","requirements","audit","security",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":175,"publishedAt":52},"01M6DNQDPTGB49D8AAJV4GN2H8","aac-testarch-framework","Initialize test framework with Playwright or Cypress. Use when the user says \"lets setup test framework\" or \"I want to initialize testing framework\"","https:\u002F\u002Fgithub.com\u002Fmsayedshokry\u002FAgileAgentCanvasExt\u002Fblob\u002Fmain\u002Fresources\u002F_aac\u002Ftea\u002Fworkflows\u002Ftestarch\u002Faac-testarch-framework\u002FSKILL.md",[174],{"categoryNo":86,"categoryName":87,"taxonomyType":21,"taxonomyTypeDesc":22},[176,177,178,101,41,179,180,181,98,182,97,183],"aac testarch framework","framework","initialize","testing framework","setup","test framework","playwright","cypress"]