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
```
using-mobile-native-capabilities
```
.
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.

bash

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.

reviewing-lwc-mobile-offline

NPX Install

Tags

SKILL.md Content

Reviewing LWC Mobile Offline

When to Use

Prerequisites

Knowledge Base

Workflow

Step 1 — Scope the review

Step 2 — Read the grounding and per-reviewer references

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

Step 4 — Inline GraphQL in
`@wire`
(JS)

Step 5 — Komaci ESLint pass (JS)

Step 6 — Produce the report

Step 7 — Apply fixes

Verification Checklist

Troubleshooting

reviewing-lwc-mobile-offline

NPX Install

Tags

SKILL.md Content

Reviewing LWC Mobile Offline

When to Use

Prerequisites

Knowledge Base

Workflow

Step 1 — Scope the review

Step 2 — Read the grounding and per-reviewer references

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

Step 4 — Inline GraphQL in @wire (JS)

Step 5 — Komaci ESLint pass (JS)

Step 6 — Produce the report

Step 7 — Apply fixes

Verification Checklist

Troubleshooting

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

Step 4 — Inline GraphQL in
`@wire`
(JS)