feat(skills): six new ms-* skills

ms-archify (evidence-based architectural mapping), ms-sdlc,
ms-proactive-agent, ms-goal, ms-grill-me, ms-frontend-design.

skills/ms-frontend-design/references/verification.md

@@ -0,0 +1,70 @@
+# Verification and completion
+
+## Evidence appropriate to the task (MUST)
+
+For each relevant requirement record its ID or clear name, result, evidence,
+and unresolved limitation. Use the existing project report or a concise
+handoff; a small repair does not need a separate audit document.
+
+- **pass:** observed behavior satisfies the requirement; identify the check.
+- **fail:** observed behavior violates it; identify the problem.
+- **not applicable:** the applicability condition is absent; explain why.
+- **not verified:** needed access, facts, or test capability are missing.
+
+An explicit scope exclusion is recorded as excluded with its consequence;
+it does not turn an applicable requirement into an inapplicable one. Do not
+average failed functional/accessibility checks into a passing aesthetic score.
+
+## Review sequence
+
+1. **Structure and content:** check hierarchy, truthful copy, semantic tokens,
+   route inventory, real link destinations, and relevant component states.
+2. **Rendered behavior:** inspect representative narrow and wide viewports,
+   around layout transitions, with long/empty content, image/font failure,
+   zoom, reduced motion, and supported themes/languages as relevant.
+3. **Interactions:** exercise the main task, keyboard path, submission states,
+   recovery, and repeated actions. Use a mock or authorized test destination
+   for messaging, purchases, and other external effects.
+4. **Site completeness:** for site-level work, verify the inventory in
+   [site completeness](site-completeness.md), including direct unknown routes,
+   Contact, privacy, consent behavior, footer links, and year rollover.
+5. **Project checks:** run relevant existing build, lint, accessibility, and
+   behavior checks. Add tests when they verify consequential behavior such as
+   consent gating or submission recovery; avoid tests that merely match copy.
+6. **Critique and recheck:** correct observed problems and rerun affected
+   checks. Stop when the scoped acceptance conditions are met; do not add
+   repeated redesign rounds just to seek novelty.
+
+Screenshots support visual claims. DOM inspection supports structural claims.
+Keyboard traces support interaction claims. Network/storage checks support
+consent claims. Mock responses do not prove a production delivery integration.
+State those limits instead of treating one kind of evidence as another.
+
+## Completion gate
+
+For implemented work, do not declare the site or feature fully complete while
+an applicable requirement is failed or not verified. Deliver the usable work
+and name remaining limitations precisely. Do not block independent work just
+because one integration or business fact is missing. Publication is governed
+by the user's authorization and project workflow, not this skill.
+
+For reviews or design-only work, completion means the requested assessment or
+design is delivered with findings and limitations; it does not mean the
+underlying product has passed implementation checks.
+
+## Scenario checks for maintaining this skill
+
+Use contrasting scenarios when substantially revising the instructions.
+These describe expected decisions, not a requirement to build all scenarios
+for each frontend task. Distinguish a reasoning walkthrough from an executed
+evaluation with a rendered artifact.
+
+| Scenario | Expected behavior |
+| --- | --- |
+| New public studio site, supplied business facts, no optional tracking | Distinctive direction; working About, Contact, privacy, footer, dynamic year, and 404. Inspect actual data use; no unnecessary consent banner. |
+| Public site with consent-required analytics and a third-party video embed | Inventory both integrations; gate them before consent, permit selective choice, persist rejection, and stop future activity after withdrawal. |
+| Dense internal operations dashboard | Reuse product conventions, preserve frequent controls, include relevant failure/focus/empty states, and adapt genuine two-dimensional data appropriately. Public marketing pages need a scope reason. |
+| Fix one form field in an established app | Preserve the design system; fix semantics, labeling, and related error/layout behavior. Do not launch a site-wide redesign. |
+| New public site with unknown operator/contact/retention facts | Ask for required facts; build independent structure; identify draft policy/contact work. Do not invent facts or claim publication readiness. |
+| Static site with multiple copyright placements | Use a shared year source with a rollover/update strategy; exercise year boundary and cache behavior. Leave policy effective dates intact. |
+| No browser or network-inspection capability | Perform useful implementation/static checks and explicitly mark visual, interaction, or consent checks not verified. |