/platform-docs-get

name: platform-docs-get
description: "Official Salesforce documentation retrieval skill. Use when you need authoritative Salesforce docs from developer.salesforce.com, help.salesforce.com, architect.salesforce.com, admin.salesforce.com, or lightningdesignsystem.com, especially when pages are JS-heavy, shell-rendered, or hard to extract with naive fetching. Use to ground answers in official Salesforce sources instead of third-party blogs or summaries. TRIGGER when: user asks for official Salesforce documentation, Apex or API reference, LWC docs, Agentforce docs, setup or help articles, or any doc from a Salesforce-owned domain. DO NOT TRIGGER when: user is asking for a code change, deployment task, or anything not requiring documentation retrieval — use the appropriate sf-* skill instead."
metadata:
  version: "1.2"
  cliTools:
    - tool: ["python3"]
      semver: ">=3.10.0"

platform-docs-get

Use this skill to retrieve and ground answers in **official Salesforce documentation on the public web**.

This skill provides a **reliable online retrieval playbook** for Salesforce docs that are hard to fetch, especially `help.salesforce.com`, JS-heavy `developer.salesforce.com`, Lightning Design System docs on `lightningdesignsystem.com`, and other official Salesforce-owned doc pages such as `architect.salesforce.com` and `admin.salesforce.com`.

Optional extraction scripts are available in `scripts/` — see the Reference File Index below.

Scope

| | | |---|---| | **In scope** | Official Salesforce doc retrieval: Apex, API, LWC, metadata, Agentforce, setup articles, SLDS, architect/admin guidance | | **Out of scope** | Third-party blogs, PDF fallback, local corpus indexing, benchmark workflows, generating code or metadata |

Required Inputs

Before fetching, identify:

• The exact concept, identifier, class, method, or feature name being requested
• The likely doc family (developer docs, help articles, design system, architect/admin)

No additional setup is required to use the retrieval playbook in this skill. The optional extraction scripts require `playwright` — see `scripts/requirements.txt`.

Official Sources Only

Prefer Salesforce-owned documentation sources:

• `developer.salesforce.com`
• `help.salesforce.com`
• `architect.salesforce.com`
• `admin.salesforce.com`
• `lightningdesignsystem.com`
• other official Salesforce documentation pages when Salesforce uses them as the source of truth

Avoid third-party blogs, videos, or summary articles unless the user explicitly asks for them.

Do **not** fall back to PDFs.

Retrieval Workflow

1. Classify the request first

Before fetching anything, identify the likely doc family.

| Family | Typical Source | Use For | |---|---|---| | Developer docs | `developer.salesforce.com/docs/...` | Apex, APIs, LWC, metadata, Agentforce developer docs | | Help docs | `help.salesforce.com/...` | setup, admin, product configuration | | Architect/Admin docs | `architect.salesforce.com/...`, `admin.salesforce.com/...` | best practices, patterns, well-architected guidance, admin enablement | | Design system docs | `lightningdesignsystem.com/...` | SLDS, Cosmos, design tokens, component and styling guidance | | Legacy atlas docs | `developer.salesforce.com/docs/atlas.en-us.*` | older official guide and reference docs |

2. Identify the exact concept

Extract the real target before you search:

• exact API/class/method name
• exact feature name
• exact product phrase
• exact setup concept

Examples:

• `Lightning Message Service`
• `Wire Service`
• `System.StubProvider`
• `Agentforce Actions`
• `Messaging for In-App and Web allowed domains`

3. Prefer targeted official retrieval

Do **not** broad-crawl Salesforce docs.

Instead: 1. identify the most likely official guide root or article 2. if search is needed, restrict it to official Salesforce domains only 3. fetch that official page 4. check whether the **exact concept actually appears on the page** 5. if not, inspect and follow the most relevant **1–3 official child links** 6. stop once you have grounded evidence

4. Do not stop at broad landing pages

A guide landing page is **not enough** unless it clearly contains the exact requested concept.

This is especially important for:

• LWC docs
• Agentforce docs
• broad platform guide homepages
• help landing pages that link to the real article

5. For `developer.salesforce.com`

Use this playbook:

• start with the most likely official guide root
• if the page is JS-heavy, prefer browser-rendered extraction
• check whether the exact concept appears on the page
• if the concept is missing, inspect official child links and follow the best matching 1–3 links
• prefer exact concept pages over broad guide roots
• legacy atlas pages are valid if they are the real official reference for the concept

6. For `help.salesforce.com`

Help pages often fail with naive fetching.

Use this playbook:

• prefer exact `articleView?id=...` URLs when available
• use browser-rendered extraction when plain fetch returns shell content
• treat outputs like `Loading`, `Sorry to interrupt`, `CSS Error`, or mostly chrome/navigation text as **failed extraction**, not evidence
• look for the **real article body**, not just header, nav, or footer text
• reject shell pages and soft-404 pages such as:
• "We looked high and low but couldn't find that page"
• generic empty help shells
• if starting from a nearby guide or hub page, follow linked Help articles until you reach the real article body
• if extraction still fails after targeted retries, return the best official Help URLs you found and explicitly say that article-body extraction was unsuccessful

Acceptance Rules

A page is good enough to answer from only when at least one of these is true:

• the exact identifier appears on the page
• the exact concept phrase appears on the page
• multiple query-specific phrases appear in the correct official context

A page is **not** good enough when:

• it is