Official Salesforce documentation retrieval guidance. Use when you need authoritative Salesforce docs from developer.salesforce.com or help.salesforce.com, especially when pages are JS-heavy, shell-rendered, or hard to extract with naive fetching.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Instruções da origem · Visualização somente leitura
name
sf-docs
description
Official Salesforce documentation retrieval guidance. Use when you need authoritative Salesforce docs from developer.salesforce.com or help.salesforce.com, especially when pages are JS-heavy, shell-rendered, or hard to extract with naive fetching.
license
MIT
metadata
{"version":"0.4.0","author":"Jag Valaiyapathy"}
sf-docs
Use this skill to retrieve and ground answers in official Salesforce documentation on the public web.
This skill is intentionally simple:
no local corpus
no indexing
no benchmark workflow
no helper CLI dependency
no PDF fallback
Its job is to provide 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.
An optional wrapper script is available at:
skills/sf-docs/scripts/extract_salesforce_doc.py
It automatically routes help.salesforce.com URLs into the dedicated Help extractor and supports other official documentation pages such as and through a generic browser-rendered path. For bot-sensitive pages, it also supports best-effort optional stealth mode via when is installed.
*.salesforce.com
lightningdesignsystem.com
--stealth
playwright-stealth
The dedicated Help extractor is also available directly at:
skills/sf-docs/scripts/extract_help_salesforce.py
Core Goal
Find the best official Salesforce HTML page online and extract enough real content to answer confidently.
If the evidence is weak, say so clearly instead of forcing a weak answer.
When to Use
Use sf-docs when a user asks for:
official Salesforce documentation
Apex, API, LWC, metadata, Agentforce, setup, or help articles
docs from developer.salesforce.com
docs from help.salesforce.com
pages that look JS-heavy, shell-rendered, or difficult to read with ordinary fetches
Official Sources Only
Prefer Salesforce-owned documentation sources:
developer.salesforce.com
help.salesforce.com
architect.salesforce.com
admin.salesforce.com
lightningdesignsystem.com
other relevant 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.
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:
identify the most likely official guide root or article
if search is needed, restrict it to official Salesforce domains only
fetch that official page
check whether the exact concept actually appears on the page
if not, inspect and follow the most relevant 1–3 official child links
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 only a broad landing page
it is a shell page with little real article text
it is from the wrong product area
it does not contain the requested identifier or concept
it is a third-party explanation when an official page should exist
Rejection Rules
Reject these as final evidence:
broad guide homepages without the exact concept
release notes when a concept/reference page is expected
admin blog posts when developer docs are requested
third-party blogs when official docs are available
shell-rendered pages with no real article body
pages whose titles sound right but whose body does not contain the requested concept
Grounding Requirements
When answering, include:
guide/article title
exact official URL
source type:
developer doc page
atlas reference page
help article page
any caveat if extraction was partial or browser-rendered
If evidence is weak, say so plainly.
Examples
Example: Lightning Message Service
Do not stop at the general LWC guide root.
Find the exact LWC page for Lightning Message Service or follow the most relevant child links from the LWC docs until the exact concept appears.
Example: Wire Service
Do not answer from the LWC homepage unless Wire Service is actually present there.
Follow the relevant child doc page for wire service or wire adapters.
Example: Agentforce Actions
Do not answer from a broad Agentforce landing page or a blog post.
Find the official Agentforce developer page for actions, or follow the best matching child pages from the official Agentforce docs.
Example: Messaging for In-App and Web allowed domains
Prefer official Help articles and browser-rendered extraction.
Reject generic help shells. Follow linked Help articles from nearby official messaging docs if needed.
Example: System.StubProvider
Prefer the official Salesforce reference/developer page where the exact identifier appears.
Do not substitute a broader Apex landing page if the identifier is absent.
Non-Goals
This skill should not:
maintain a local documentation corpus
rely on a local index
use PDF fallback
run benchmark workflows
depend on repo-specific scripts to be useful
Cross-Skill Role
Other sf-* skills should use sf-docs when they need authoritative Salesforce documentation instead of relying on generic search alone.
