菜单
Phase 8 of 1st-gen to 2nd-gen component migration. Use to run final checks, verify lint/tests/build/Storybook, update the workstream status table, and open a PR.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Phase 6 of 1st-gen to 2nd-gen component migration. Use to write unit tests, accessibility tests, and Storybook play functions for a migrated component.
Author dedicated Storybook visual regression stories for 2nd-gen components. Use when adding or reviewing `.vrt.ts` files, Chromatic VRT coverage, forced-colors coverage, pseudo-state snapshots, global stylesheet coverage, or custom-property VRT coverage.
Phase 3 of 1st-gen to 2nd-gen component migration. Use to move properties, methods, and types from 1st-gen to 2nd-gen while maintaining a clear public API.
Create accessibility migration analysis docs for 2nd-gen component migration. Use when on the "analyze accessibility" step for one or more components.
Phase 5 of 1st-gen to 2nd-gen component migration. Use to migrate CSS to the 2nd-gen structure, apply Spectrum 2 tokens, and ensure stylelint passes.
Upgrade Spectrum 1 (sp-* elements, @spectrum-web-components/*) to Spectrum 2 (swc-* elements, @adobe/spectrum-wc). Use when developers need to migrate from Spectrum 1 to Spectrum 2 web components, or when they mention @spectrum-web-components, sp-* elements, or Spectrum 1.
| name | migration-review |
| description | Phase 8 of 1st-gen to 2nd-gen component migration. Use to run final checks, verify lint/tests/build/Storybook, update the workstream status table, and open a PR. |
Phase 8 of the 1st-gen → 2nd-gen component migration. The goal is final checks — lint, tests, build, and Storybook — then updating the workstream status table and opening a PR.
You are a gatekeeper, not a rubber stamp. A passing build and green tests are the minimum expectations. Read the diff as if you are a reviewer who did not write this code. Look for missing edge cases, inconsistent conventions, and anything the automated checks cannot catch. Use the style guides in CONTRIBUTOR-DOCS/02_style-guide when enforcing code styles.
Read the migration plan at CONTRIBUTOR-DOCS/03_project-planning/03_components/[component]/migration-plan.md when available before final review. Verify that the implemented API, behavior, breaking changes, docs, and tests still match the plan, and treat undocumented drift as a review issue. If the plan is missing, stale, or intentionally incomplete, review against the best available source material and call out the missing plan as a risk. See also migration-plan-contract.
Follow Phase 8: Review in the washing machine workflow doc — it covers what to do, what to check, common problems, and the quality gate for this phase.
In addition to the workflow doc and migration-plan-contract, explicitly verify that:
