release-enablement

name

release-enablement

description

Author and maintain Revenue Cloud (Agentforce Revenue Management) Hands-On Enablement Exercises per release. Use when updating exercises for a new release (260, 262, …), authoring the journey map index document, indexing release-note features per functional area, or implementing the auto-gen pipeline that produces distribution artifacts. Catalog target lives at docs/enablement/{version}/. Per-release source PDFs and feature indexes live at docs/salesforce/{version}/.

Release Enablement

Authoring system for the Revenue Cloud Hands-On Enablement catalog.

This skill is the cross-workstation memory for enablement authoring. The journey map and exercise files in docs/enablement/ are the deliverables; this skill documents the workflow, sources, and conventions that produce them — so any agent on any workstation can pick up the work mid-cycle.

Two-Tier Model: Master + Per-Release Extracts

The catalog has two complementary artifact types, both authored in this repo:

1. Master exercises (docs/enablement/master/{NN}-{area}.md) — the living, workshop-format source of truth. Each exercise progressively walks through a functional area using foundational + new content together, anchored to the Infinitech / Global Media workshop scenario (qb-scenario-reference.md). These are the documents in-person enablement sessions and workshops use. Sections in master exercises carry version-aware frontmatter (introduced, available, enhanced_in) so the auto-gen can derive release-specific cuts.

2. Per-release extracts (docs/enablement/{version}/) — filtered views of the master set, scoped to net-new and enhanced features for a specific release (e.g., 260, 262). Used when the audience already knows prior-cycle content and only wants the delta. Intended steady state: generated by the render task from per-section master frontmatter (introduced / available / enhanced_in), not authored independently. Current reality (until the render task ships): extracts are authored and edited manually as scaffolding, using the master files as content source. When the render task lands, the manual extracts get replaced by render output — until then, edits to an extract file are legitimate (and should be mirrored back to the master if the content also belongs there).

The master is the source of truth. Per-release extracts are mechanical derivatives. When in doubt about where to make a change, edit the master.

Quick Rules

1. Markdown is the source. Distribution artifacts (PDF, Word) render from .md source files. Master files live in docs/enablement/master/; per-release extracts in docs/enablement/{version}/.
2. The QB Scenario Reference is the foundation. Every master exercise anchors walkthroughs to the canonical Infinitech (US, Technology) + Global Media (Canada, Media) customer accounts and the QB catalog (docs/enablement/master/qb-scenario-reference.md).
3. Past releases (248, 252, 254, 256, 258) are read-only historical artifacts. Never edit. They serve as carry-forward references only.
4. Generate 260 and forward. 262 is the current development cycle. 260 is the prior GA reference.
5. Master file naming: {NN}-{area-kebab}.md (e.g., 01-product-catalog-management.md, 02-salesforce-pricing.md). The numeric prefix preserves the workshop sequence. Per-release naming: {version}-{area-kebab}-hands-on.md.
6. Customer accounts come from scratch_data. Infinitech is the primary customer (full BillingAccount setup). Global Media is the secondary (Canada-based, multi-account demos). Robot Resellers (in qb-prm) is the partner channel. Never invent customer names.
7. Reference QuantumBit data. Look up products/SKUs/bundles/CML models in datasets/sfdmu/qb/ and datasets/constraints/qb/ when authoring step-by-step instructions. The QB Scenario Reference summarizes what's available.
8. Per-section version metadata is the auto-gen contract. When a master section is added, mark it with introduced: <version>, available: "<version>+", and (if applicable) enhanced_in: [<later-versions>].
9. Overview boxes in the journey map link to Salesforce Help. We author Hands-On Exercises only.

DO NOT

1. DO NOT edit docs/enablement/{248,252,254,256,258}/ — frozen historical artifacts.
2. DO NOT edit per-release extracts (docs/enablement/260/...) and silently diverge from master.
   • Intended steady state (once render task ships): master is the only editable source — extracts are regenerated, never hand-edited.
   • Current reality (until then): if a fix is faster to apply directly to the extract (typo, version-header sync, frontmatter normalization), edit the extract and mirror the same change back to the corresponding master file in the same PR. The “Authoring workflow → Step 5 (Carry-back to master)” section enforces this.
   • In either era, never let an extract drift from master without explicit, recorded justification.
3. DO NOT commit confidential internal decks (Solution Overview is marked CONFIDENTIAL - Internal Only) without confirming distribution rights. They live in docs/salesforce/{version}/ for internal authoring use; they should not be linked from public-facing exercise PDFs.
4. DO NOT invent feature details. If the source material doesn't have configuration steps for a feature, mark [NEEDS REVIEW] and ask — don't fill gaps with plausible-sounding guesses.
5. DO NOT invent customer or product names in walkthroughs. All data references must come from QuantumBit (datasets/sfdmu/qb/) and scratch_data (customer accounts).

Source Inventory (per release)

Each release has up to four primary sources. Drop them into docs/salesforce/{version}/ as you receive them.

Source	What it gives you	Format
Master Help compendium	Full Help docs for the release as one PDF — definitive but huge (often 1,000+ pages). Use for detailed configuration steps.	revenue-cloud-{release-name}-{date}.pdf
Internal Solution Overview deck	Per-feature Customer Need / Solution / Use Case / Impact — most digestible primary source for authoring. Marked CONFIDENTIAL.	solution-overview-{release-name}.pdf
Public release notes	The "what's new" summary with feature names + one-paragraph descriptions. Live web (SPA — needs Chrome MCP) or PDF if available.	release-notes-{area}.md (curated) and/or salesforce-release-notes-{release-name}-{date}.pdf
Org access / screenshots	For verifying configuration steps work, capturing visuals, sanity-checking what users actually see.	(live)

Capturing release notes from Salesforce Help:

The Help portal is a Lightning Web Components SPA — WebFetch does not work because the initial response redirects without rendering article body. Use Chrome MCP (mcp__Claude_in_Chrome__*):

1. Navigate to the release-notes URL (pattern: https://help.salesforce.com/s/articleView?id=release-notes.rn_{area}.htm&release={version}&type=5).
2. Wait 2–3 seconds for SPA render.
3. Use javascript_tool with a recursive shadow-DOM walker to extract content. The article body is inside multiple shadow roots; standard document.querySelector returns nothing.
4. Save extracted content as Markdown to docs/salesforce/{version}/release-notes-{area}.md.

Recursive shadow walker template:

function findAllInShadow(root, predicate, results = []) {
  if (!root) return results;
  const all = root.querySelectorAll ? root.querySelectorAll('*') : [];
  all.forEach(el => {
    if (predicate(el)) results.push(el);
    if (el.shadowRoot) findAllInShadow(el.shadowRoot, predicate, results);
  });
  return results;
}
const h1s = findAllInShadow(document, el => el.tagName === 'H1' && el.innerText.includes('{HEADING}'));
h1s[0].parentElement.innerText;

Workflow

The two-tier model has two distinct workflows: maintaining the master, and producing per-release extracts. They share inputs but produce different artifacts.

Workflow A — Master exercise authoring/maintenance

0. Read docs/enablement/master/qb-scenario-reference.md to ground new content
   in the canonical QB scenario (Infinitech / Global Media / QB-COMPLETE / QB-QRack-750).
1. For each area's master file (docs/enablement/master/{NN}-{area}.md):
   a. Identify what content needs adding/updating — could be foundational
      (introduced in any prior release), new (introduced in current release),
      or refactored (better structure / better walkthrough / scenario-thread fix).
   b. Author/update the section with appropriate version-aware frontmatter:
      introduced: <version>
      available: "<version>+"
      enhanced_in: [<later-versions>]   (optional)
      scenario_step: <ordered narrative position>   (optional)
   c. Anchor walkthroughs to the workshop scenario — Infinitech as customer,
      QB-COMPLETE / QB-QRack-750 as bundles, etc.
2. Mark each master file status: outline → draft → review → final.
3. Update docs/enablement/coverage-matrix.md when new sections are added or
   existing sections change status.

Workflow B — Per-release extract generation

0. Drop release-specific source PDFs into docs/salesforce/{version}/
   (Solution Overview decks, master Help PDF, captured release notes).
1. Update docs/salesforce/{version}/feature-index.md with per-area features
   extracted from sources.
2. For each new feature in the release, ensure the corresponding section
   exists in the master (Workflow A). The master is the source.
3. Run the render task to generate docs/enablement/{version}/{version}-{area}-hands-on.md
   files as filtered extracts of the master:
   - Sections where `available` includes {version}: emit
   - Sections where `enhanced_in` includes {version}: emit with "Enhanced in {version}" callout
   - Sections introduced after {version}: skip
   - Sections introduced before {version} where `available` doesn't include {version}: skip
4. Render distribution artifacts (PDF/Word via Pandoc) for the per-release set.
5. Update the journey map: docs/enablement/{version}/{version}-journey-map.md.
6. Promote {version} from WIP to released — update README.md release pointer.

Until the render task is built, per-release extracts are maintained manually as the existing 260 drafts demonstrate. The two-tier conventions (frontmatter, scenario threading, naming) apply during manual authoring so the eventual auto-gen can take over without restructuring.

Authoring Conventions

Filename pattern

docs/enablement/{version}/{version}-{area-kebab}-hands-on.md
docs/enablement/{version}/{version}-journey-map.md

Example for 260:

docs/enablement/260/260-salesforce-pricing-hands-on.md
docs/enablement/260/260-product-catalog-management-hands-on.md
docs/enablement/260/260-journey-map.md

Frontmatter schema

The auto-gen reads frontmatter to populate the cover page, headers, footers, and TOC. Required fields:

---
release_version: 262            # int — RCA package version (current cycle; 260 = Spring '26 = prior GA)
release_name: "Summer '26"      # str — seasonal name
api_version: 67.0               # float — Salesforce API version
area: "Salesforce Pricing"      # str — must match journey map label
document_version: 0.3           # str — semver-ish, increment within a release cycle
status: draft                   # outline | draft | review | final
last_updated: 2026-05-06        # ISO date
authors: [Brian Galdino]
data_shape: qb                  # qb | mfg | q3 — which dataset this exercise assumes
prerequisites: [...]            # list of strings
sources: [...]                  # list of strings — file paths or URLs that informed this doc
---

Section structure (after frontmatter)

# Revenue Cloud — {{ area }}                    <-- H1
**Enablement Exercises** · Version {{ document_version }}, {{ release_name }}

(branding/data-shape callouts)

## Status of this document
## Carry-forward inventory (from prior releases)
## Release Overview
## Feature N: {{ name }}                        <-- H2 per feature
   ### Business Objective                       <-- H3
   ### Use Cases                                <-- H3
   ### Design Time Configuration                <-- H3
   ### Configuration and Runtime Video          <-- H3
## QuantumBit data reference
## Open questions for author
## Footer

The auto-gen uses the H2 + H3 structure literally. Section headers must match this list verbatim — additions are fine (e.g., feature-specific subheadings under H3) but the four standard parts per feature should be present.

Per-release feature indexes

Release	Status	Feature Index
260 (Spring '26)	Prior GA reference	docs/salesforce/260/feature-index.md
262 (Summer '26)	Current — in development	docs/salesforce/262/feature-index.md

The feature index for each release is the authoring input. It contains a per-area table of new features with: name, tier (GA/Beta/Pilot), one-paragraph description, source page references, demo URL placeholders. Authoring an exercise means working through that area's row in the feature index and turning each row into a Feature N section in the area's .md file.

Auto-Gen (planned)

The eventual goal is to invoke a single command and have all distribution artifacts produced for a release. Architecture sketch:

1. Render task in tasks/rlm_render_enablement.py (CCI custom task) reads frontmatter and source .md, calls Pandoc.
2. Per-area templates in docs/enablement/_template/ define the cover page, header/footer, copyright, branding (per-release release_name swap).
3. Cross-release diff task identifies which areas changed since the prior release (frontmatter last_updated + content hash) so an incremental render only re-emits what changed.
4. Journey map is generated last, after all area files are at status: final.

Build the render task once 260 is signed off and the Markdown structure is stable. Until then, manual Pandoc:

pandoc docs/enablement/260/260-salesforce-pricing-hands-on.md \
  -o "260 - Salesforce Pricing - Hands-On.pdf" \
  --pdf-engine=xelatex --toc --toc-depth=2

Cross-Workstation Handoff

This skill plus the contents of docs/enablement/, docs/salesforce/, and datasets/sfdmu/qb/ are everything an agent needs to pick up the work mid-cycle on any workstation. Workflow:

1. New session on any workstation: agent reads AGENTS.md → finds this skill in the index → reads this SKILL.md → reads the relevant per-release feature index.
2. Agent inspects current state: docs/enablement/coverage-matrix.md and the status: field in each area file's frontmatter.
3. Agent picks up next pending area or continues whatever was in progress.

The project already establishes a two-workstation pattern (personal + Salesforce). This skill extends that pattern to enablement work.

Sub-Files

File	Contains
authoring-patterns.md	Conventions for handling edge cases (upgrade guidance, known issues, sub-features, cross-area features, carry-forward markers, recordings placeholders, QB walkthrough handling, frontmatter, scenario threading, version-aware section metadata, license-scope split). Read this before authoring any exercise file.
resume-enablement-work.md	Cross-workstation handoff. Read when starting a fresh conversation in this repo without prior thread context. Provides the 4-step re-orientation, common follow-up task pointers, tool grants checklist, and a standard restart prompt template.

Required Authoring Inputs (read these before authoring)

File	Why
docs/enablement/master/qb-scenario-reference.md	Canonical reference for what's in QB orgs by default — bundles (QB-COMPLETE / QB-QRack-750), CML constraint models (QuantumBitComplete + Server2 with Type/Port semantics), pricing-feature wiring (Bundle / Attribute / Volume), customer accounts (Infinitech / Global Media via scratch_data), partner channel (Robot Resellers via qb-prm), 4 Legal Entities, 9 selling models, 9 usage products, multi-currency setup. The workshop scenario lives here.
authoring-patterns.md	Conventions for edge cases.

Related Skills

• revenue-cloud-data-model — for object/field references in exercise step-by-step instructions
• sfdmu-data-plans — for understanding what QuantumBit catalog records exist when authoring walkthroughs
• doc-consistency — pre-merge checks when exercises are updated

Change Log

• 2026-05-06 — Skill created during 260 Salesforce Pricing pilot. Captured workflow, source inventory pattern, frontmatter schema, Chrome MCP shadow-walk for Help portal extraction.
• 2026-05-06 — Restructured for Two-Tier Model after 260 catalog completion (10 area drafts done). Master exercises become source of truth at docs/enablement/master/; per-release extracts are filtered views. Added QB Scenario Reference as a required authoring input. Customer accounts canonicalized to scratch_data (Infinitech + Global Media). Pricing-feature mapping (Bundle/Attribute/Volume) onto QB-COMPLETE and constraint-engine semantics (Port/Type) for QB-QRack-750 documented in QB Scenario Reference.