mobile-ai-agents 1.0.32 → 1.0.34

package/README.md

@@ -316,7 +316,7 @@ Not sure where to begin? Pick your situation:
 | `/store-listing` | Conversation → ASO-optimized listing copy |
 | `/feature-slice` | Epic → independently shippable tickets |
 | `/release-prep` | Full release checklist from freeze to store |
-| `/accessibility-audit` | WCAG 2.1 AA + platform accessibility review |
+| `/accessibility-audit` | WCAG 2.1 AA, reskin contrast, and semantic color-token migration review |
 | `/api-versioning` | API deprecation strategy for mobile clients |
 | `/deeplink-debug` | Diagnoses broken deep links across Android and iOS |
 | `/mobile-mcp-qa` | Run AI-assisted QA on iOS/Android devices, simulators, and emulators |

package/docs/wiki.md

@@ -384,6 +384,16 @@ Full guide: [`docs/vscode-copilot-integration.md`](vscode-copilot-integration.md
 
 **Specify the exact platform:** `Android-Compose`, `Android-XML`, `iOS-SwiftUI`, `iOS-UIKit`, `Flutter`, or `React-Native`. The fixes differ significantly between frameworks.
 
+For a reskin or theme migration, run `/accessibility-audit` with the supported themes, theme/token source, affected screens, and resolved foreground/background pairs. It maps by semantic role rather than old hex value, computes WCAG AA contrast for light and dark modes, and reports role collisions where one palette value was incorrectly reused for text, borders, fills, disabled content, or status states. Pair it with `/mobile-app-design` before implementation and `/mobile-mcp-qa` for device screenshots afterward.
+
+```text
+/accessibility-audit
+PLATFORM: React Native
+SUPPORTED_THEMES: light, dark
+Audit the Settings reskin and token migration. Report failed pairs with their ratio,
+required ratio, semantic role, theme/state, and recommended token.
+```
+
 ---
 
 ## 7. How Skills Work

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "mobile-ai-agents",
-  "version": "1.0.32",
+  "version": "1.0.34",
   "description": "AI agents, skills, and Loop Engineering workflows for building, testing, auditing, and releasing mobile apps.",
   "bin": {
     "mobile-ai-agents": "cli/index.js",

package/skills/cross-platform/accessibility-audit.md

@@ -7,7 +7,27 @@
 
 ## Purpose
 
-Reviews any mobile screen for WCAG 2.1 AA compliance and platform accessibility standards. Increasingly required by law (EU Accessibility Act 2025, ADA).
+Reviews mobile UI for WCAG 2.1 AA and platform accessibility requirements. It also verifies app reskins and color-token migrations by semantic role so palette replacements do not create invisible text, controls, or status states.
+
+## When to Use
+
+- Before releasing a new or redesigned mobile screen.
+- After `/mobile-app-design` changes themes, tokens, components, or navigation.
+- When a reskin replaces hardcoded colors or consolidates competing palettes.
+- When `/mobile-mcp-qa` finds unreadable content or a theme-specific regression.
+
+## Inputs
+
+Provide as much of this evidence as is available:
+
+```text
+PLATFORM: Android | iOS | Flutter | React Native
+SUPPORTED_THEMES: light, dark, or named themes
+UI_SOURCE: screen/component and theme/token source files
+COLOR_PAIRS: optional resolved foreground/background pairs by role, theme, and state
+SCREENSHOTS: optional device evidence; never a substitute for computed colors
+RESKIN_PLAN: optional /mobile-app-design screen inventory and token migration plan
+```
 
 ---
 
@@ -59,5 +79,135 @@ React Native:
 - accessibilityHint for non-obvious actions.
 - accessible={false} for decorative elements.
 
-For each issue: element, requirement violated, WCAG criterion, and concrete fix.
+RESKIN AND TOKEN MIGRATION:
+1. Build a usage inventory before changing or approving tokens. Inspect each occurrence as
+   body text, large text, muted/secondary text, icon, border, fill/surface, disabled content,
+   disabled fill, status content, status fill, or fixed-tone content/fill.
+2. Map colors by semantic role, never by old hex value. If one old hex is used for text,
+   borders, and fills, those usages require separate destination tokens. Flag a single
+   replacement token across different roles as ROLE_COLLISION.
+3. Resolve the actual foreground and background after aliases, theme selection, state layers,
+   opacity, and alpha compositing. Do not infer contrast from token names or visual judgment.
+4. Compute WCAG relative luminance and contrast ratio for every supported theme and relevant
+   state. Use (Llighter + 0.05) / (Ldarker + 0.05).
+5. Require at least 4.5:1 for body/normal text and 3:1 for large text, icons, borders,
+   focus indicators, and other meaningful non-text UI. Large text is at least 18pt regular
+   or 14pt bold. Decorative borders and inactive controls do not need 3:1, but enabled
+   control boundaries and state indicators do.
+6. Test these pairs separately in every theme:
+   - body text on each surface it appears on
+   - muted/secondary text on each surface it appears on
+   - icons and meaningful borders against adjacent colors
+   - status chips/badges: content on container and container against its surroundings when
+     the boundary communicates status
+   - disabled content on disabled fill and surrounding surface; disabled state must not rely
+     on low contrast or color alone
+   - error, success, warning, and info content/containers
+   - fixed-tone content on fixed-tone fills, without allowing system theme substitution
+7. Detect invisible-text risks: foreground and background resolving to the same token/value,
+   on-color paired with the wrong container, transparent content composited onto a matching
+   surface, fixed-tone content replaced by a theme-dependent token, or a missing dark token
+   falling back to a light-theme value.
+8. Screenshots may reveal where to inspect, but sampled pixels are not sufficient when text
+   has antialiasing, transparency, imagery, or gradients. Use resolved source/runtime colors
+   for the computed result and mark unavailable pairs UNVERIFIED.
+
+For each accessibility issue include the element, requirement, WCAG criterion, severity,
+evidence, and concrete fix. For color failures, recommend a semantic token, not only a hex.
+
+OUTPUT FORMAT:
+ACCESSIBILITY AUDIT
+===================
+Platform:
+Themes audited:
+Evidence:
+Result: PASS | FAIL | PARTIAL | BLOCKED
+
+Summary:
+- Critical:
+- High:
+- Medium:
+- Low:
+- Unverified:
+
+Role Collision Audit:
+| Old Color/Token | Source Usages | Incorrect Mapping | Required Role Tokens | Result |
+|---|---|---|---|---|
+
+Contrast Results:
+| Element/Pair | Role | Theme/State | Foreground | Background | Ratio | Required | Recommended Token | Result |
+|---|---|---|---|---|---:|---:|---|---|
+
+Other Findings:
+| Severity | Element | Requirement/WCAG | Evidence | Fix |
+|---|---|---|---|---|
+
+Unverified Evidence:
+- Pair or behavior, missing evidence, and exact verification needed.
+
+Decision:
+- PASS only when all in-scope themes and states have computed passing pairs and no blocking
+  semantic, focus, label, target-size, or announcement failures remain.
+- PARTIAL when available checks pass but required evidence is missing.
+- FAIL when any required pair or accessibility behavior fails.
+```
+
+## Example
+
+**Input:**
+
+```text
+PLATFORM: React Native
+SUPPORTED_THEMES: light, dark
+RESKIN_PLAN: Replace legacy #6B7280 usages with the new secondary token.
+UI_SOURCE:
+- Settings helper text used #6B7280.
+- Card borders used #6B7280.
+- Dark theme maps secondary to #334155 on surface #0F172A.
 ```
+
+**Output:**
+
+```text
+ACCESSIBILITY AUDIT
+===================
+Platform: React Native
+Themes audited: light, dark
+Evidence: resolved theme tokens and Settings source
+Result: FAIL
+
+Summary:
+- Critical: 0
+- High: 1
+- Medium: 1
+- Low: 0
+- Unverified: 0
+
+Role Collision Audit:
+| Old Color/Token | Source Usages | Incorrect Mapping | Required Role Tokens | Result |
+|---|---|---|---|---|
+| #6B7280 | helper text, card border | color.secondary | color.onSurfaceVariant, color.outline | ROLE_COLLISION |
+
+Contrast Results:
+| Element/Pair | Role | Theme/State | Foreground | Background | Ratio | Required | Recommended Token | Result |
+|---|---|---|---|---|---:|---:|---|---|
+| Settings helper/surface | muted text | dark/default | #334155 | #0F172A | 1.72:1 | 4.5:1 | color.onSurfaceVariant | FAIL |
+| Settings card edge/surface | meaningful border | dark/default | #334155 | #0F172A | 1.72:1 | 3:1 | color.outline | FAIL |
+
+Other Findings:
+| Severity | Element | Requirement/WCAG | Evidence | Fix |
+|---|---|---|---|---|
+| HIGH | Settings helper | 1.4.3 contrast | Dark token migration makes text nearly invisible | Map text to color.onSurfaceVariant and verify >= 4.5:1 |
+| MEDIUM | Settings card | 1.4.11 non-text contrast | Border no longer communicates grouping | Map border to color.outline and verify >= 3:1 |
+
+Unverified Evidence:
+- None.
+
+Decision:
+- FAIL. Split the legacy value by semantic role, recompute both dark-mode pairs, and rerun
+  `/mobile-mcp-qa` for Settings in light and dark themes.
+```
+
+## Composition
+
+Use `/mobile-app-design` to define the reskin and token plan, this skill to compute accessibility results, and `/mobile-mcp-qa` to capture device evidence in every supported theme.

package/skills/cross-platform/prd-verification.md

@@ -27,6 +27,10 @@ IMPLEMENTATION:
 <changed files, relevant source code, repo tree, or diff>
 EVIDENCE:
 <test output, build output, screenshots, Mobile MCP QA report, logs, accessibility report, security report>
+RESKIN_PLAN:
+<optional /mobile-app-design plan with REDESIGN, RESTYLE, and LEAVE screen inventory rows>
+RESKIN_QA:
+<optional /mobile-mcp-qa Reskin QA report, before/after screenshots, state coverage, and theme evidence>
 KNOWN_LIMITATIONS:
 <optional explicit constraints, skipped checks, unavailable device, unavailable backend>
 ```
@@ -45,11 +49,13 @@ Read these inputs in order:
 1. PRD.md or product requirements
 2. TASKS.md acceptance criteria
 3. DESIGN.md or design plan
-4. DEPENDENCIES.md and ROADMAP.md when provided
-5. MOBILE_MEMORY.md or project context when provided
-6. Relevant source code, diff, and file tree
-7. Test/build output
-8. Screenshots, videos, accessibility reports, security reports, or Mobile MCP QA reports
+4. /mobile-app-design reskin plan and screen inventory when provided
+5. DEPENDENCIES.md and ROADMAP.md when provided
+6. MOBILE_MEMORY.md or project context when provided
+7. Relevant source code, diff, and file tree
+8. Test/build output
+9. Screenshots, videos, accessibility reports, security reports, or Mobile MCP QA reports
+10. /mobile-mcp-qa Reskin QA report when provided
 
 Verification rules:
 
@@ -61,6 +67,10 @@ Verification rules:
 - Separate confirmed gaps from assumptions.
 - Do not expand scope beyond the approved PRD unless it creates release risk.
 - Do not mark release-ready if critical requirements, security blockers, crash risks, or required tests are missing.
+- For mobile reskins, compile/build/test success is not UI proof by itself.
+- For mobile reskins, every required screen inventory row needs screenshot, video, or Mobile MCP evidence.
+- Mark missing required reskin evidence as UNVERIFIED, or PARTIAL only when some states/themes are proven.
+- Reject shallow rethemes: a REDESIGN screen fails when it only inherits token, color, font, spacing, or theme changes.
 
 Check these areas:
 
@@ -81,17 +91,28 @@ Check these areas:
 - Layout, hierarchy, content, states, responsiveness, and accessibility evidence.
 - Screenshot or Mobile MCP evidence when available.
 
-4. TEST AND DEVICE EVIDENCE
+4. MOBILE RESKIN VERIFICATION
+Use this section when RESKIN_PLAN is provided or the scope mentions /mobile-app-design, reskin, redesign, tab reorder, navigation rename, visual refresh, or restyle.
+- Read every screen inventory row and preserve its decision: REDESIGN, RESTYLE, or LEAVE.
+- REDESIGN must show structural change: layout, hierarchy, grouping, density, information architecture, state layout, tab order, or interaction model.
+- RESTYLE must include justification and must not be counted as structurally redesigned.
+- LEAVE must be intentionally out of scope and should not be reported as a missed redesign unless the PRD required it.
+- Compare before/after screenshots or Mobile MCP evidence for each required screen, state, orientation, and light/dark theme listed in the plan.
+- If navigation changed, verify routes, deep links, selected tab state, back behavior, accessibility labels, tests, snapshots, and docs.
+- If tabs or screens were renamed, verify user-facing copy changed consistently in UI, tests, screenshots, and docs.
+- Use per-screen status values: PASS, FAIL, PARTIAL, or UNVERIFIED.
+
+5. TEST AND DEVICE EVIDENCE
 - Unit, integration, UI, golden/snapshot, E2E, and manual QA evidence.
 - Build/install/launch proof.
 - Device, emulator, simulator, or Mobile MCP proof when available.
 
-5. SECURITY AND RELEASE BLOCKERS
+6. SECURITY AND RELEASE BLOCKERS
 - Security audit findings that affect release.
 - Sensitive data, auth, storage, network, permissions, deep links, WebViews, logging, and payment/subscription behavior when relevant.
 - Performance blockers that affect launch readiness.
 
-6. CONTEXT CONTINUITY
+7. CONTEXT CONTINUITY
 - MOBILE_MEMORY.md or project context reflects the current state.
 - Remaining gaps and next action are captured for future sessions.
 
@@ -127,6 +148,10 @@ UI Match:
 | Screen/State | Source | Status | Evidence |
 |---|---|---|---|
 
+Mobile Reskin Verification:
+| Screen/State | Decision | Evidence | Status | Reason |
+|---|---|---|---|---|
+
 Test And Device Evidence:
 | Check | Status | Evidence |
 |---|---|---|
@@ -157,7 +182,7 @@ Test Gaps:
 - <gap or "None">
 
 Release Readiness:
-PASS only if all required PRD items and acceptance criteria are PASS, no critical UI/security/test gaps remain, and unknowns are documented or risk-accepted.
+PASS only if all required PRD items and acceptance criteria are PASS, no critical UI/security/test gaps remain, required reskin evidence is PASS or risk-accepted, and unknowns are documented or risk-accepted.
 
 Next Action:
 1. <single highest priority action>
@@ -299,6 +324,54 @@ Next Action:
 
 ---
 
+## Mobile Reskin Example
+
+Use this guidance when `/mobile-app-design` produced a reskin plan and `/mobile-mcp-qa` produced device evidence.
+
+```text
+RESKIN_PLAN:
+- Home: REDESIGN. Replace feed cards with grouped Today, Progress, and Next Action sections.
+- Profile: RESTYLE. Keep structure, update typography and spacing only.
+- Billing: LEAVE. Out of scope for this release.
+
+RESKIN_QA:
+- Mobile MCP Reskin QA has before/after screenshots for Home light and dark.
+- Profile screenshot exists only for light theme.
+- No Billing screenshot because it is marked LEAVE.
+```
+
+Expected verification behavior:
+
+```text
+Mobile Reskin Verification:
+| Screen/State | Decision | Evidence | Status | Reason |
+|---|---|---|---|---|
+| Home light/dark | REDESIGN | MCP screenshots | PASS | Structure changed |
+| Profile light | RESTYLE | Screenshot | PARTIAL | Dark missing |
+| Billing | LEAVE | Plan row | PASS | Out of scope |
+
+Verification Details:
+### UI-001 — Home redesign is proven
+- Source: /mobile-app-design RESKIN_PLAN.
+- Evidence: /mobile-mcp-qa before/after screenshots show new grouped sections.
+- Status: PASS.
+- Confirmed gap: None.
+- Assumption: None.
+- Required fix: None.
+
+### UI-002 — Profile restyle has incomplete evidence
+- Source: /mobile-app-design RESKIN_PLAN.
+- Evidence: Only light theme screenshot was provided.
+- Status: PARTIAL.
+- Confirmed gap: Dark theme evidence is missing.
+- Assumption: Profile was intentionally restyled, not redesigned.
+- Required fix: Capture Profile dark theme screenshot or risk-accept the gap.
+```
+
+If Home only changed colors, fonts, or tokens, mark it FAIL because a REDESIGN requires structural proof.
+
+---
+
 ## Composition Example
 
 ```text