mobile-platform-offline-validate

Name: mobile-platform-offline-validate
Author: forcedotcom

744stars272forks

How to install mobile-platform-offline-validate?

forcedotcom/sf-skills/mobile-platform-offline-validate

$npx -y skills add forcedotcom/sf-skills --skill mobile-platform-offline-validate

Installs into the current project.

Summary

Review a Lightning Web Component for mobile offline compatibility — the Komaci offline static analyzer that pre-primes the data graph for Salesforce Mobile App Plus and Field Service Mobile App. Produces a finding list with code-level fixes covering inline GraphQL queries in

Files · 1

View on GitHub

SKILL.md

1	# Reviewing LWC Mobile Offline
2
3	Run a structured offline-priming compliance pass over a Lightning Web
4	Component, producing a report of issues found and code-level fixes to bring
5	the component into compliance with Komaci's static analysis requirements
6	for the Salesforce Mobile App Plus and Field Service Mobile App.
7
8	## When to Use
9
10	- The user asks for a "mobile offline review", "Komaci check", or "offline
11	priming audit" on a specific LWC.
12	- Preparing a component to ship in Salesforce Mobile App Plus or Field
13	Service Mobile App offline mode.
14	- Investigating priming failures reported by the offline analyzer.
15
16	Do NOT use this skill for:
17
18	- Building an LWC that uses native mobile capabilities (barcode scanner,
19	biometrics, location, etc.) — use `mobile-platform-native-capabilities-integrate`.
20	- Generic LWC code review — use the appropriate domain skill
21	(`reviewing-lws-security`, `reviewing-lwc-rtl`, `accessibility-code-review`).
22
23	## Prerequisites
24
25	- Component path (LWC bundle under `modules/…`).
26	- Access to the component's JS/TS and HTML templates.
27	- Local Node + npm; ability to run `npx eslint` with the
28	`@salesforce/eslint-plugin-lwc-graph-analyzer` plugin.
29
30	## Knowledge Base
31
32	[Mobile Offline Grounding](references/grounding.md) explains the three
33	violation categories and why each blocks offline priming. Read it before
34	judging. The per-reviewer references below are the source of truth for the
35	rules and remediations:
36
37	- Inline GraphQL wire configuration: [Inline GraphQL Reviewer](references/inline-graphql.md)
38	- `lwc:if` conditional rendering compatibility: [lwc:if Reviewer](references/lwc-if.md)
39	- Komaci ESLint static analysis: [Komaci ESLint Reviewer](references/komaci-eslint.md)
40
41	## Workflow
42
43	### Step 1 — Scope the review
44
45	Identify the component bundle: `.html`, `.js`/`.ts`. CSS and meta files are
46	not in scope for offline priming. If the bundle has multiple HTML
47	templates, all are reviewed.
48
49	### Step 2 — Read the grounding and per-reviewer references
50
51	Read [Mobile Offline Grounding](references/grounding.md) and the three
52	per-reviewer references end-to-end before judging. Cite the specific
53	reviewer when emitting each finding so the report is auditable.
54
55	### Step 3 — `lwc:if` / `lwc:elseif` / `lwc:else` (HTML)
56
57	Walk every `.html` file in the bundle and apply the rules in
58	[lwc:if Reviewer](references/lwc-if.md). For each occurrence of
59	`lwc:if={…}`, `lwc:elseif={…}`, or `lwc:else`, emit a finding with the
60	exact `if:true` / `if:false` rewrite — including the nesting required to
61	preserve `lwc:elseif` and `lwc:else` semantics.
62
63	### Step 4 — Inline GraphQL in `@wire` (JS)
64
65	Walk every `.js`/`.ts` file in the bundle and apply the rules in
66	[Inline GraphQL Reviewer](references/inline-graphql.md). For each `@wire`
67	that references a `gql` template literal directly (or via a top-level
68	constant), emit a finding that names a concrete getter and shows the
69	rewritten `@wire` configuration.
70
71	### Step 5 — Komaci ESLint pass (JS)
72
73	Run the Komaci ESLint analyzer over the bundle's JS file using the
74	bundled script. It applies the
75	`@salesforce/eslint-plugin-lwc-graph-analyzer` recommended ruleset with
76	the `bundleAnalyzer` processor enabled.
77
78	```bash
79	scripts/run-komaci.sh path/to/component.js
80	```
81
82	The script requires `@salesforce/eslint-plugin-lwc-graph-analyzer` to
83	be resolvable from the working directory, and the component's sibling
84	HTML templates must live next to the JS file (the plugin's
85	`bundleAnalyzer` processor uses them to resolve the offline data
86	graph). Output is ESLint `--format json` on stdout.
87
88	For each `messages[*]` entry in the output, group by `ruleId` and look
89	up the per-rule remediation in
90	[Komaci ESLint Reviewer](references/komaci-eslint.md). Emit a finding
91	per (rule, line) pair with the exact remediation text from the
92	reference; do not invent new advice. See the reference for the manual
93	`npx eslint ...` invocation if the script is unavailable in the runtime
94	environment.
95
96	### Step 6 — Produce the report
97
98	Emit a re

People who liked this also viewed

6 picks

Type

mobile-platform-offline-validate

744stars272forks

View on GitHub

How to install mobile-platform-offline-validate?

forcedotcom/sf-skills/mobile-platform-offline-validate

$npx -y skills add forcedotcom/sf-skills --skill mobile-platform-offline-validate

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Reviewing LWC Mobile Offline
2
3	Run a structured offline-priming compliance pass over a Lightning Web
4	Component, producing a report of issues found and code-level fixes to bring
5	the component into compliance with Komaci's static analysis requirements
6	for the Salesforce Mobile App Plus and Field Service Mobile App.
7
8	## When to Use
9
10	- The user asks for a "mobile offline review", "Komaci check", or "offline
11	priming audit" on a specific LWC.
12	- Preparing a component to ship in Salesforce Mobile App Plus or Field
13	Service Mobile App offline mode.
14	- Investigating priming failures reported by the offline analyzer.
15
16	Do NOT use this skill for:
17
18	- Building an LWC that uses native mobile capabilities (barcode scanner,
19	biometrics, location, etc.) — use `mobile-platform-native-capabilities-integrate`.
20	- Generic LWC code review — use the appropriate domain skill
21	(`reviewing-lws-security`, `reviewing-lwc-rtl`, `accessibility-code-review`).
22
23	## Prerequisites
24
25	- Component path (LWC bundle under `modules/…`).
26	- Access to the component's JS/TS and HTML templates.
27	- Local Node + npm; ability to run `npx eslint` with the
28	`@salesforce/eslint-plugin-lwc-graph-analyzer` plugin.
29
30	## Knowledge Base
31
32	[Mobile Offline Grounding](references/grounding.md) explains the three
33	violation categories and why each blocks offline priming. Read it before
34	judging. The per-reviewer references below are the source of truth for the
35	rules and remediations:
36
37	- Inline GraphQL wire configuration: [Inline GraphQL Reviewer](references/inline-graphql.md)
38	- `lwc:if` conditional rendering compatibility: [lwc:if Reviewer](references/lwc-if.md)
39	- Komaci ESLint static analysis: [Komaci ESLint Reviewer](references/komaci-eslint.md)
40
41	## Workflow
42
43	### Step 1 — Scope the review
44
45	Identify the component bundle: `.html`, `.js`/`.ts`. CSS and meta files are
46	not in scope for offline priming. If the bundle has multiple HTML
47	templates, all are reviewed.
48
49	### Step 2 — Read the grounding and per-reviewer references
50
51	Read [Mobile Offline Grounding](references/grounding.md) and the three
52	per-reviewer references end-to-end before judging. Cite the specific
53	reviewer when emitting each finding so the report is auditable.
54
55	### Step 3 — `lwc:if` / `lwc:elseif` / `lwc:else` (HTML)
56
57	Walk every `.html` file in the bundle and apply the rules in
58	[lwc:if Reviewer](references/lwc-if.md). For each occurrence of
59	`lwc:if={…}`, `lwc:elseif={…}`, or `lwc:else`, emit a finding with the
60	exact `if:true` / `if:false` rewrite — including the nesting required to
61	preserve `lwc:elseif` and `lwc:else` semantics.
62
63	### Step 4 — Inline GraphQL in `@wire` (JS)
64
65	Walk every `.js`/`.ts` file in the bundle and apply the rules in
66	[Inline GraphQL Reviewer](references/inline-graphql.md). For each `@wire`
67	that references a `gql` template literal directly (or via a top-level
68	constant), emit a finding that names a concrete getter and shows the
69	rewritten `@wire` configuration.
70
71	### Step 5 — Komaci ESLint pass (JS)
72
73	Run the Komaci ESLint analyzer over the bundle's JS file using the
74	bundled script. It applies the
75	`@salesforce/eslint-plugin-lwc-graph-analyzer` recommended ruleset with
76	the `bundleAnalyzer` processor enabled.
77
78	```bash
79	scripts/run-komaci.sh path/to/component.js
80	```
81
82	The script requires `@salesforce/eslint-plugin-lwc-graph-analyzer` to
83	be resolvable from the working directory, and the component's sibling
84	HTML templates must live next to the JS file (the plugin's
85	`bundleAnalyzer` processor uses them to resolve the offline data
86	graph). Output is ESLint `--format json` on stdout.
87
88	For each `messages[*]` entry in the output, group by `ruleId` and look
89	up the per-rule remediation in
90	[Komaci ESLint Reviewer](references/komaci-eslint.md). Emit a finding
91	per (rule, line) pair with the exact remediation text from the
92	reference; do not invent new advice. See the reference for the manual
93	`npx eslint ...` invocation if the script is unavailable in the runtime
94	environment.
95
96	### Step 6 — Produce the report
97
98	Emit a re

People who liked this also viewed

6 picks

Type