Importance: Medium. Status: Pending (built and QA'd, not yet installed).

Goal for this session: review the salesforce-developer skill against Sam's actual Litify org and optimize it.

What was done

Reviewed salesforce-developer in context with the live skill library and found it was a generic third-party skill (MIT, github.com/Jeffallan) with three real defects, then rebuilt it.

Defects found and fixed:

  1. Broken references. Its Reference Guide table told agents to load five references/*.md files (apex-development, lightning-web-components, soql-sosl, integration-patterns, deployment-devops). None existed; the folder held only SKILL.md. Folded the useful content inline and removed the dead pointers, so nothing can break on load.
  2. Phantom router target. litify-operator-core routes all Apex/LWC/field/object/deploy work to litify-metadata-builder, which does not exist anywhere in the library. The real skill covering that scope (salesforce-developer) was wired into nothing. Repointed the router to salesforce-developer (one-line change).
  3. Trigger collision and vanilla-advice risk. Its description triggered on the same bare words as operator-core (Salesforce, Apex, SOQL, triggers) and handed back generic advice with none of the live-org-first or respect-Litify-package-boundaries discipline the sibling skills enforce. Rewrote the description to position it as the build layer under operator-core.

Also fixed staleness: LWC apiVersion 59.0 to 63.0 (with a note to pin to the org's current version), removed an unneeded @track, and reframed "90% coverage" as an internal bar versus Salesforce's 75% platform floor. Added a Litify package-boundary section (litify_pm__ namespace, do not edit or clone managed members) and stopped hardcoding repo paths (inherits canonical paths from operator-core per Sam's skills-hygiene rule).

Name preserved as salesforce-developer (version 1.1.0 to 2.0.0) so nothing referencing it by name breaks for other agents.

Delivered as inline links: the installable .skill, the readable SKILL.md, the patched operator-core, a README with install + rollback, and the original for rollback. Rollback snapshots also kept in the session workspace.

Why the session ended

Work is complete and QA'd. Held at the install boundary because installing a skill and editing the base router are changes to shared infrastructure other agents depend on, so Sam's go is appropriate before they go live. This is web Claude.ai, so there is no mount to Sam's Mac or the sail-skills repo from this session.

Recommended next actions (Sam's call, all low-risk with rollback)

  1. Install the optimized skill (drag the .skill into Settings > Skills, or commit skills/salesforce-developer/SKILL.md to samaguiar1982-cpu/sail-skills on main).
  2. Apply the 1-line operator-core router fix (use litify-metadata-builder to use salesforce-developer). This is what actually closes the phantom-route gap; installing the skill alone does not.
  3. Optional: decide whether litify-metadata-builder was ever meant to exist as a separate skill, or whether salesforce-developer is the intended home for that scope (this session assumes the latter).

Handoff for the next agent

Everything needed is in the session outputs (the .skill, readable SKILL.md, patched operator-core, README, and original rollback). If Sam approved install via GitHub, prefer the reliable commit path (github-direct-commit on the Mac, or direct GitHub REST) over Pipedream's github-create-or-update-file-contents, which rewrites large files through an intermediate model. If the router fix is applied, confirm by re-reading operator-core line ~76 and checking it reads use salesforce-developer. No live org writes were made; this was skill-library work only. If asked to verify the skill against the real org, load litify-operator-core first, then litify-live-recon for current API names before trusting any object/field reference.

Self-audit note for future improvement