Skip to content
Development
Skill

/mobile-platform-native-capabilities-integrate

Build a Salesforce LWC that uses native mobile device capabilities — barcode scanner, biometrics, location, NFC, calendar, contacts, document scanner, geofencing, AR space capture, app review, and payments. Use this skill when the user asks for an LWC that scans a barcode,

From plugin
sf-skills
803161 skills6 agents10 commands3 MCP
Install
$ npx -y skills add forcedotcom/sf-skills --skill mobile-platform-native-capabilities-integrate --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/mobile-platform-native-capabilities-integrate

Context preview

The summary Claude sees to decide when to auto-load this skill.

Build a Salesforce LWC that uses native mobile device capabilities — barcode scanner, biometrics, location, NFC, calendar, contacts, document scanner, geofencing, AR space capture, app review, and payments. Use this skill when the user asks for an LWC that scans a barcode,

SKILL.md

mobile-platform-native-capabilities-integrate.SKILL.md
name: mobile-platform-native-capabilities-integrate
description: "Build a Salesforce LWC that uses native mobile device capabilities — barcode scanner, biometrics, location, NFC, calendar, contacts, document scanner, geofencing, AR space capture, app review, and payments. Use this skill when the user asks for an LWC that scans a barcode, captures a photo of a document, reads location or geofences, prompts for biometrics, reads/writes the device calendar or contacts, taps NFC, takes a payment, prompts for an app review, or scans an AR space. Also triggers on \"lightning/mobileCapabilities\", \"mobile capability\", \"Nimbus\", \"device capability\". Do not use for mobile offline / Komaci priming reviews (use `mobile-platform-offline-validate`) or for picking generic Lightning base components (use `design-systems-slds-apply`)."
metadata:
  relatedSkills:
    - "design-systems-slds-apply"
    - "mobile-platform-offline-validate"
  version: "1.0"

Using Mobile Native Capabilities

The `lightning/mobileCapabilities` module exposes a set of factory functions that return service objects for native device features (barcode scanning, biometrics, location, etc.). Each service extends a common [BaseCapability](references/base-capability.md) with an `isAvailable()` method, so an LWC can degrade gracefully on surfaces where the capability is not present (desktop, mobile web).

This skill routes an agent through (1) picking the right capability, (2) loading the authoritative type definitions, and (3) wiring the service into an LWC with the correct availability gating, error handling, and deprecation-aware API choice.

When to Use This Skill

  • User asks for an LWC that uses a device capability listed in the index

below.

  • User mentions `lightning/mobileCapabilities`, "mobile capability", or

"Nimbus" by name.

  • User wants to know which mobile native APIs are available, or which one

fits their feature.

Do NOT use this skill for:

  • Mobile-offline review of an LWC (lwc:if, inline GraphQL, Komaci-priming

violations) — use `mobile-platform-offline-validate`.

  • Choosing or styling generic Lightning Base Components / SLDS blueprints —

use `design-systems-slds-apply`.

Prerequisites

  • Knowledge that the LWC will run inside a supported mobile container

(Salesforce Mobile App, Field Service Mobile App). These capabilities are unavailable on desktop and mobile web; gate every call behind `isAvailable()`.

  • Familiarity with the `lightning/mobileCapabilities` module declaration

(see [mobile-capabilities](references/mobile-capabilities.md)).

Capability Index

| Capability | Reference | One-line use | | --- | --- | --- | | App Review | [App Review](references/app-review.md) | Prompt the user for a native in-app review. | | AR Space Capture | [AR Space Capture](references/ar-space-capture.md) | Capture a 3D scan of a physical space using AR. | | Barcode Scanner | [Barcode Scanner](references/barcode-scanner.md) | Read QR / UPC / EAN / Code-128 / etc. from the camera. | | Biometrics | [Biometrics](references/biometrics.md) | Authenticate via Face ID / fingerprint. | | Calendar | [Calendar](references/calendar.md) | Read or create events on the device calendar. | | Contacts | [Contacts](references/contacts.md) | Read or create entries in the device address book. | | Document Scanner | [Document Scanner](references/document-scanner.md) | Scan paper documents using the camera with edge detection. | | Geofencing | [Geofencing](references/geofencing.md) | Trigger logic when the device crosses a geographic boundary. | | Location | [Location](references/location.md) | Read GPS coordinates and watch for updates. | | NFC | [NFC](references/nfc.md) | Read or write NFC tags. | | Payments | [Payments](references/payments.md) | Take an Apple Pay / Google Pay payment. |

Workflow

Step 1 — Identify the capability

Map the user's feature ask to one row of the capability index. If the ask spans multiple capabilities (e.g. "scan a barcode and store it on a contact"), plan for **each** capability separately — there is one factory function per capability.

Step 2 — Load the shared and capability-specific references

Read these two shared references **once** per session — they apply to every capability and are not duplicated in the per-capability files:

  • [BaseCapability](references/base-capability.md) — the common interface

with `isAvailable()` that every service extends.

  • [mobile-capabilities](references/mobile-capabilities.md) — the

`lightning/mobileCapabilities` module declaration showing every re-exported service.

Then open the capability's reference file from the table above. Each per-capability reference contains the service-specific TypeScript API (factory function, service interface, options types, result types, error types) and assumes the two shared references above are already in context.

Do not infer the API from memory — read it. The services evolve and some methods are explicitly `@deprecated` in favor of newer alternatives.

Step 3 — Wire the service into the LWC

For each capability:

1. Import the factory from `lightning/mobileCapabilities`:

   import { getBarcodeScanner } from 'lightning/mobileCapabilities';

2. Get an instance: `const scanner = getBarcodeScanner();` 3. Gate the call behind `isAvailable()`:

   if (!scanner.isAvailable()) {
     // graceful fallback or user message
     return;
   }

4. Call the **non-deprecated** entry point. Several services keep older methods marked `@deprecated` alongside the recommended one — always prefer the recommended method in the reference. 5. Wrap the promise in `try/catch` and handle the typed failure codes the service exposes (e.g. `BarcodeScannerFailureCode`, `LocationServiceFailureCode`). User-cancelled vs. permission-denied vs. service-unavailable are distinct UX states.

Step 4 — Surface failure modes to the user

Each service defines its own failure-code en

Read more
Ships withsf-skills

This repository provides a curated collection of Salesforce agent skills for building applications.

Get the whole plugin

Other skills on sf-skills.