Salesforce Learning Research
Use this skill to establish what can responsibly be taught about a Salesforce topic before writing the lesson. It separates evidence acquisition from explanation so the final learning brief cannot turn stale release guidance, org assumptions, or community opinion into timeless platform fact.
This is an end-user research workflow. It does not replace the repository's build-time content-researcher agent, upstream intake, source manifest, or skill-authoring validation.
Research Packet Contract
| Section |
Required content |
| Research question |
Learner's question, role/level, desired outcome, and explicit boundaries |
| Context identity |
Cloud/product, release/API version, org/package context, and observed date when relevant |
| Terminology |
Official names, aliases, renamed products, deprecated terms, and disambiguation |
| Source inventory |
Source ID, title, owner, tier, publication/update date, retrieval date, scope, and URL/reference |
| Claim ledger |
Atomic claim, state, evidence IDs, applicability, confidence, and teaching implication |
| Contradictions |
Conflicting statements, winner under source hierarchy, and unresolved conditions |
| Freshness |
Current, preview/beta, retired, historical, or unknown status for release-sensitive content |
| Gaps |
Questions the sources do not support and evidence still needed |
| Brief handoff |
Ordered concepts, examples safe to teach, caveats, and knowledge-check targets |
Do not copy large passages into the packet. Record concise original summaries and stable citations.
Bound the Learning Question
Capture:
- learner role and current experience;
- what they should be able to explain or do afterward;
- whether the topic is conceptual, procedural, architectural, diagnostic, or release-specific;
- relevant Salesforce cloud, product, edition, license, API version, package, or org context;
- exclusions and neighboring concepts that should route to another brief;
- supplied sources that must remain the sole basis, when the user requests source-bounded work.
A broad prompt such as "teach me Flow" needs a narrower outcome before research. A bounded prompt such as "explain before-save versus after-save record-triggered Flow to an admin who knows formulas" has a researchable evidence surface.
Source Hierarchy
Apply standards/source-hierarchy.md. Use the source best suited to the claim rather than treating every Salesforce-owned page as interchangeable.
| Claim type |
Preferred evidence |
| Current behavior, limits, API, metadata, security contract |
Salesforce product/developer documentation and current release notes |
| Architecture patterns and tradeoffs |
Salesforce Architects guidance, then official developer guidance |
| Guided learning sequence |
Trailhead or official learning content, verified against product docs for exact behavior |
| Current tooling command or option |
Official CLI/tool documentation for the installed major version |
| Feature availability or lifecycle |
Current release notes and official product availability documentation |
| Org-specific state |
Read-only evidence from the explicitly identified org or user-provided snapshot |
| Practitioner nuance absent from official sources |
Named expert source, explicitly lower confidence, corroborated per repository policy |
Rules:
- A lower-tier source never overrides a higher-tier source on platform behavior.
- Current release notes override older product documentation when behavior changed.
- Documentation proves platform capability, not target-org entitlement or activation.
- Search snippets are discovery aids, not final evidence; open the source before recording the claim.
- AI-generated summaries, including this repository's own skills, are navigation aids unless their underlying sources are inspected.
- When the user says to use only attached material, do not silently fill gaps from the web or general knowledge.
Atomic Claim Ledger
Each row should make one testable statement.
| Field |
Meaning |
claim_id |
Stable identifier such as C-01 |
claim |
One factual or recommendation statement in original wording |
state |
verified-fact, official-recommendation, inference, assumption, unknown, or unsupported |
evidence_ids |
One or more source or org evidence identifiers |
applicability |
Product, edition, release/API version, environment, persona, or file type |
freshness |
current, preview, beta, retired, historical, or unknown |
confidence |
HIGH, MEDIUM, or LOW with a short reason |
teaching_implication |
What the final brief may say, must qualify, or must omit |
Never combine a verified platform behavior and an inferred best practice in one row. Split them so the final brief can label each correctly.
Freshness and Lifecycle
For every release-sensitive claim, record:
- publication or last-updated date when visible;
- retrieval date;
- Salesforce release or API version;
- feature status such as GA, beta, developer preview, retired, or announced;
- enforcement or rollout date when the official source states one;
- whether the target org can be assumed to have received the release.
Use absolute dates in the packet. Do not write "recently", "now", or "next release" without anchoring the date and release.
A repository skill may summarize an older behavior accurately for its stated version. Do not label it wrong solely because it is historical; label its applicability and keep it out of a current brief unless history is relevant.
Contradiction Resolution
- Confirm that the sources discuss the same product, release, API, license, and context.
- Prefer the higher source tier; within Tier 1, prefer the more current and more specific source.
- Check whether one source is preview/beta while the other describes GA behavior.
- Separate a product guarantee from an implementation recommendation.
- Record the losing statement and why it does not control; do not silently discard it.
- When authoritative sources still conflict, mark the claim
unknown, explain the conflict, and prevent the final brief from asserting either side as settled.
Recommended Workflow
- Bound the learning question by defining the learner outcome, mapping ambiguous/renamed terminology, and recording product, release, API, org, and source boundaries.
- Plan and retrieve evidence by claim type—behavior, limit, procedure, architecture, lifecycle, or org state—and search the strongest authorized sources first.
- Build the evidence packet with source inventory, observed dates, stable references, atomic claims, applicability, freshness, and confidence. Use original synthesis rather than copied upstream expression.
- Resolve contradictions and gaps using repository policy. Preserve unsupported, stale, inaccessible, or conflicting claims instead of silently choosing a convenient answer.
- Design the teaching handoff with concept order, safe examples, caveats, checks for understanding, and the claim IDs that must remain cited.
- Validate and hand off the packet with the bundled checker, then pass it to
admin/salesforce-learning-brief for learner-facing synthesis.
Quality Gates
Output and Validation
Create the packet from templates/salesforce-learning-research-template.md, then run:
python3 skills/architect/salesforce-learning-research/scripts/check_salesforce_learning_research.py --input path/to/research-packet.md
A passing packet is evidence-ready, not automatically correct. Review source relevance and claim interpretation before teaching.
Related Skills and Boundaries
admin/salesforce-learning-brief — turn the verified packet into a learner-facing explanation and practice sequence.- Repository
content-researcher agent — research and author canonical SfSkills content; it has provenance, licensing, and repository-specific responsibilities this skill does not perform.
architect/salesforce-decision-analysis — compare viable options; use learning research only to supply evidence for concepts the decision depends on.- Domain skills — supply bounded practitioner guidance after their sources and release applicability are verified.
See the bundled references for example packets, contradiction cases, and common research failures.
1---2name: salesforce-learning-research3description: Research a Salesforce topic for a learner using a citation-first, release-aware evidence workflow: bound the question, prioritize official sources, build a claim ledger, resolve contradictions, and produce a research packet for teaching. Trigger keywords: research Salesforce topic, find official Salesforce docs, prepare learning sources, verify Salesforce concept, release-aware research. Repository package authoring and upstream intake remain outside this package. NOT for the final learner-facing explanation — use admin/salesforce-learning-brief.4---56# Salesforce Learning Research78Use this skill to establish what can responsibly be taught about a Salesforce topic **before** writing the lesson. It separates evidence acquisition from explanation so the final learning brief cannot turn stale release guidance, org assumptions, or community opinion into timeless platform fact.910This is an end-user research workflow. It does not replace the repository's build-time `content-researcher` agent, upstream intake, source manifest, or skill-authoring validation.1112---1314## Research Packet Contract1516| Section | Required content |17|---|---|18| Research question | Learner's question, role/level, desired outcome, and explicit boundaries |19| Context identity | Cloud/product, release/API version, org/package context, and observed date when relevant |20| Terminology | Official names, aliases, renamed products, deprecated terms, and disambiguation |21| Source inventory | Source ID, title, owner, tier, publication/update date, retrieval date, scope, and URL/reference |22| Claim ledger | Atomic claim, state, evidence IDs, applicability, confidence, and teaching implication |23| Contradictions | Conflicting statements, winner under source hierarchy, and unresolved conditions |24| Freshness | Current, preview/beta, retired, historical, or unknown status for release-sensitive content |25| Gaps | Questions the sources do not support and evidence still needed |26| Brief handoff | Ordered concepts, examples safe to teach, caveats, and knowledge-check targets |2728Do not copy large passages into the packet. Record concise original summaries and stable citations.2930---3132## Bound the Learning Question3334Capture:3536- learner role and current experience;37- what they should be able to explain or do afterward;38- whether the topic is conceptual, procedural, architectural, diagnostic, or release-specific;39- relevant Salesforce cloud, product, edition, license, API version, package, or org context;40- exclusions and neighboring concepts that should route to another brief;41- supplied sources that must remain the sole basis, when the user requests source-bounded work.4243A broad prompt such as "teach me Flow" needs a narrower outcome before research. A bounded prompt such as "explain before-save versus after-save record-triggered Flow to an admin who knows formulas" has a researchable evidence surface.4445---4647## Source Hierarchy4849Apply `standards/source-hierarchy.md`. Use the source best suited to the claim rather than treating every Salesforce-owned page as interchangeable.5051| Claim type | Preferred evidence |52|---|---|53| Current behavior, limits, API, metadata, security contract | Salesforce product/developer documentation and current release notes |54| Architecture patterns and tradeoffs | Salesforce Architects guidance, then official developer guidance |55| Guided learning sequence | Trailhead or official learning content, verified against product docs for exact behavior |56| Current tooling command or option | Official CLI/tool documentation for the installed major version |57| Feature availability or lifecycle | Current release notes and official product availability documentation |58| Org-specific state | Read-only evidence from the explicitly identified org or user-provided snapshot |59| Practitioner nuance absent from official sources | Named expert source, explicitly lower confidence, corroborated per repository policy |6061Rules:62631. A lower-tier source never overrides a higher-tier source on platform behavior.642. Current release notes override older product documentation when behavior changed.653. Documentation proves platform capability, not target-org entitlement or activation.664. Search snippets are discovery aids, not final evidence; open the source before recording the claim.675. AI-generated summaries, including this repository's own skills, are navigation aids unless their underlying sources are inspected.686. When the user says to use only attached material, do not silently fill gaps from the web or general knowledge.6970---7172## Atomic Claim Ledger7374Each row should make one testable statement.7576| Field | Meaning |77|---|---|78| `claim_id` | Stable identifier such as `C-01` |79| `claim` | One factual or recommendation statement in original wording |80| `state` | `verified-fact`, `official-recommendation`, `inference`, `assumption`, `unknown`, or `unsupported` |81| `evidence_ids` | One or more source or org evidence identifiers |82| `applicability` | Product, edition, release/API version, environment, persona, or file type |83| `freshness` | `current`, `preview`, `beta`, `retired`, `historical`, or `unknown` |84| `confidence` | `HIGH`, `MEDIUM`, or `LOW` with a short reason |85| `teaching_implication` | What the final brief may say, must qualify, or must omit |8687Never combine a verified platform behavior and an inferred best practice in one row. Split them so the final brief can label each correctly.8889---9091## Freshness and Lifecycle9293For every release-sensitive claim, record:9495- publication or last-updated date when visible;96- retrieval date;97- Salesforce release or API version;98- feature status such as GA, beta, developer preview, retired, or announced;99- enforcement or rollout date when the official source states one;100- whether the target org can be assumed to have received the release.101102Use absolute dates in the packet. Do not write "recently", "now", or "next release" without anchoring the date and release.103104A repository skill may summarize an older behavior accurately for its stated version. Do not label it wrong solely because it is historical; label its applicability and keep it out of a current brief unless history is relevant.105106---107108## Contradiction Resolution1091101. Confirm that the sources discuss the same product, release, API, license, and context.1112. Prefer the higher source tier; within Tier 1, prefer the more current and more specific source.1123. Check whether one source is preview/beta while the other describes GA behavior.1134. Separate a product guarantee from an implementation recommendation.1145. Record the losing statement and why it does not control; do not silently discard it.1156. When authoritative sources still conflict, mark the claim `unknown`, explain the conflict, and prevent the final brief from asserting either side as settled.116117---118119## Recommended Workflow1201211. **Bound the learning question** by defining the learner outcome, mapping ambiguous/renamed terminology, and recording product, release, API, org, and source boundaries.1222. **Plan and retrieve evidence** by claim type—behavior, limit, procedure, architecture, lifecycle, or org state—and search the strongest authorized sources first.1233. **Build the evidence packet** with source inventory, observed dates, stable references, atomic claims, applicability, freshness, and confidence. Use original synthesis rather than copied upstream expression.1244. **Resolve contradictions and gaps** using repository policy. Preserve unsupported, stale, inaccessible, or conflicting claims instead of silently choosing a convenient answer.1255. **Design the teaching handoff** with concept order, safe examples, caveats, checks for understanding, and the claim IDs that must remain cited.1266. **Validate and hand off** the packet with the bundled checker, then pass it to `admin/salesforce-learning-brief` for learner-facing synthesis.127128---129130## Quality Gates131132- [ ] Learner role, level, outcome, and scope are explicit133- [ ] Product/cloud and release/API context are pinned where material134- [ ] Terminology and product renames are resolved135- [ ] Every source has owner, tier, date/retrieval date, scope, and reference136- [ ] Every material statement is an atomic claim with a state137- [ ] Release-sensitive claims carry freshness and applicability138- [ ] Recommendations are not labeled as platform guarantees139- [ ] Org-specific claims use identified org evidence or remain unknown140- [ ] Contradictions and unsupported claims are preserved, not hidden141- [ ] Search snippets and AI summaries are not the sole evidence142- [ ] The handoff tells the learning brief what it may teach and what it must qualify143144---145146## Output and Validation147148Create the packet from `templates/salesforce-learning-research-template.md`, then run:149150```bash151python3 skills/architect/salesforce-learning-research/scripts/check_salesforce_learning_research.py --input path/to/research-packet.md152```153154A passing packet is evidence-ready, not automatically correct. Review source relevance and claim interpretation before teaching.155156---157158## Related Skills and Boundaries159160- `admin/salesforce-learning-brief` — turn the verified packet into a learner-facing explanation and practice sequence.161- Repository `content-researcher` agent — research and author canonical SfSkills content; it has provenance, licensing, and repository-specific responsibilities this skill does not perform.162- `architect/salesforce-decision-analysis` — compare viable options; use learning research only to supply evidence for concepts the decision depends on.163- Domain skills — supply bounded practitioner guidance after their sources and release applicability are verified.164165See the bundled references for example packets, contradiction cases, and common research failures.
PranavNagrecha