migration-review

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.

Migration review (Phase 8)

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.

Mindset

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.

When to use this skill

• All previous phases are complete
• The user asks to "review [component]", "finalize [component]", or "open a PR for [component]"
• The user refers to "Phase 8" of the 2nd-gen component migration workstream

When NOT to use

• Phase 7 is not complete — documentation and stories should be finalized before review
• You are resolving a lint, test, or build failure that belongs to an earlier phase (e.g. stylelint errors → Phase 5, failing unit or a11y tests → Phase 6)

How to invoke

• "Review [component] migration"
• "PR review for [component]"
• "Phase 8 for [component] migration"

---

Workflow

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:

• Implemented API and behavior match the approved migration plan
• Breaking changes in code are documented in the plan and reflected in docs
• Any drift from the plan is either corrected or clearly called out for review
• Unresolved open questions were not silently decided in code without alignment
• Any new or newly-consumed shared core resource (controller, mixin, utility, directive) is reflected in 16_2nd-gen-shared-resources.md — this is the last gate before merge, so treat it as blocking, not advisory