mobile-platform-offline-validate

SKILL.md

Reviewing LWC Mobile Offline

Run a structured offline-priming compliance pass over a Lightning Web
Component, producing a report of issues found and code-level fixes to bring
the component into compliance with Komaci's static analysis requirements
for the Salesforce Mobile App Plus and Field Service Mobile App.

When to Use

The user asks for a "mobile offline review", "Komaci check", or "offline
priming audit" on a specific LWC.

Preparing a component to ship in Salesforce Mobile App Plus or Field
Service Mobile App offline mode.

Investigating priming failures reported by the offline analyzer.

Do NOT use this skill for:

Building an LWC that uses native mobile capabilities (barcode scanner,
biometrics, location, etc.) — use mobile-platform-native-capabilities-integrate.

Generic LWC code review — use the appropriate domain skill
(reviewing-lws-security, reviewing-lwc-rtl, accessibility-code-review).

Prerequisites

Component path (LWC bundle under modules/…).

Access to the component's JS/TS and HTML templates.

Local Node + npm; ability to run npx eslint with the
@salesforce/eslint-plugin-lwc-graph-analyzer plugin.

Knowledge Base

Mobile Offline Grounding explains the three
violation categories and why each blocks offline priming. Read it before
judging. The per-reviewer references below are the source of truth for the
rules and remediations:

Inline GraphQL wire configuration: Inline GraphQL Reviewer

lwc:if conditional rendering compatibility: lwc:if Reviewer

Komaci ESLint static analysis: Komaci ESLint Reviewer

Workflow

Step 1 — Scope the review

Identify the component bundle: .html, .js/.ts. CSS and meta files are
not in scope for offline priming. If the bundle has multiple HTML
templates, all are reviewed.

Step 2 — Read the grounding and per-reviewer references

Read Mobile Offline Grounding and the three
per-reviewer references end-to-end before judging. Cite the specific
reviewer when emitting each finding so the report is auditable.

Step 3 — lwc:if / lwc:elseif / lwc:else (HTML)

Walk every .html file in the bundle and apply the rules in
lwc:if Reviewer. For each occurrence of
lwc:if={…}, lwc:elseif={…}, or lwc:else, emit a finding with the
exact if:true / if:false rewrite — including the nesting required to
preserve lwc:elseif and lwc:else semantics.

Step 4 — Inline GraphQL in @wire (JS)

Walk every .js/.ts file in the bundle and apply the rules in
Inline GraphQL Reviewer. For each @wire
that references a gql template literal directly (or via a top-level
constant), emit a finding that names a concrete getter and shows the
rewritten @wire configuration.

Step 5 — Komaci ESLint pass (JS)

Run the Komaci ESLint analyzer over the bundle's JS file using the
bundled script. It applies the
@salesforce/eslint-plugin-lwc-graph-analyzer recommended ruleset with
the bundleAnalyzer processor enabled.

scripts/run-komaci.sh path/to/component.js

The script requires @salesforce/eslint-plugin-lwc-graph-analyzer to
be resolvable from the working directory, and the component's sibling
HTML templates must live next to the JS file (the plugin's
bundleAnalyzer processor uses them to resolve the offline data
graph). Output is ESLint --format json on stdout.

For each messages[*] entry in the output, group by ruleId and look
up the per-rule remediation in
Komaci ESLint Reviewer. Emit a finding
per (rule, line) pair with the exact remediation text from the
reference; do not invent new advice. See the reference for the manual
npx eslint ... invocation if the script is unavailable in the runtime
environment.

Step 6 — Produce the report

Emit a report in this shape:

## Mobile Offline (Komaci priming)
- <reviewer> — <file>:<startLine>:<startColumn>-<endLine>:<endColumn> — <type>
  Description: <verbatim from the reviewer reference>
  Intent analysis: <verbatim from the reviewer reference>
  Suggested action: <verbatim from the reviewer reference>
  Code: |
    <source snippet from startLine through endLine, optional but
     recommended when the violation spans multiple lines>
  Applied: yes/no

## Summary
- <n> issues found; <m> fixed; <k> deferred (with reason)

For Komaci ESLint findings, take startLine/startColumn/endLine/
endColumn from the ESLint message's line/column/endLine/endColumn.
For Inline GraphQL and lwc:if findings, supply the line/column range you
observed in the source. If endLine/endColumn are not available for a
finding, fall back to <file>:<startLine> and omit the trailing range.

Cite the reviewer (Inline GraphQL / lwc:if / Komaci ESLint rule id) on every
finding.

Step 7 — Apply fixes

Apply the remediations directly when the user asked for fixes. If a
remediation conflicts with the component's behavior outside offline (e.g.
the developer relies on lwc:elseif for readability and the user is not
yet shipping to mobile offline), surface the conflict in the deferred list
rather than silently rewriting.

Verification Checklist

 Every lwc:if / lwc:elseif / lwc:else flagged or absent.

 Every @wire referencing gql checked; inline queries extracted to
a getter.

 Komaci ESLint analyzer was actually run; findings cite real rule
ids, not invented ones.

 Each finding cites the originating reviewer or rule id.

 No remediation outside the three categories above (other concerns
belong to other skills).

Troubleshooting

npx eslint cannot find the plugin — install
@salesforce/eslint-plugin-lwc-graph-analyzer in the workspace, or use a
pinned local install path. The plugin is the canonical source of Komaci
rules.

bundleAnalyzer related errors — the recommended config drives the
bundle processor; do not strip it. The processor expects sibling HTML
files to be discoverable. If running on a stripped-down JS file, supply
the matching HTML in the temp directory.

No findings for a component you expect to fail — confirm the
recommended ruleset is applied (not just bundleAnalyzer with empty
rules). Some rules require the HTML to be present alongside the JS.

Findings duplicate lwc:if from the dedicated reviewer — the Komaci
plugin does not check templates; the lwc:if check is HTML-only and
comes from Step 3. Findings from Step 5 are JS-only.