Importance: High (skill-store drift). Status: Pending (install + reconcile decision).

Follow-up to the earlier 2026-05-31 salesforce-developer session. Sam approved: always-allow on committing reviewed skill fixes to sail-skills; apply the phantom-router fix; do the path-drift improvement; and enhance the skill further using Knowledge Base entries plus independent Litify research.

What was done

Enhanced salesforce-developer from v2.0.0 to v2.1.0 using two evidence sources:

v2.1.0 adds: a cited one-paragraph org overview; a concrete object/field reference using actual members (litify_pm__OpposingParty__c managed lookup, litify_pm__Matter_State__c restricted picklist, custom fields Client_ZIP__c and Sync_to_Eve_Legal__c, related Police_Report__c); an investigate-before-change section codifying house discipline (check org-level population counts before trusting a field's name; check code usage before repurposing, e.g. RingCentral reads Primary_Party_Contact__c; verify with live FieldDefinition/layout describes; reversible deploys); FLS/role awareness with real Litify permission set names; and a Litify-flavored SOQL example. QA clean (no banned words, no em dashes, 209 lines). Delivered as an installable .skill plus readable source, the operator-core 1-line router patch, a README, and the original for rollback.

Resolved the open metadata-builder question with evidence: the only trace of litify-metadata-builder anywhere is the phantom router line. It was never built. salesforce-developer is the correct home for that scope.

Major finding: skill-store drift (the reason nothing was committed)

The sail-skills GitHub repo and the Cowork mount have drifted badly. Repo holds 17 skills; the mount holds 88; only 3 overlap (firm-briefing, notion-knowledge-base, sa-template-reference). salesforce-developer and the entire litify-* family (11 skills, including litify-operator-core) exist ONLY in the mount, not in the repo. The 14 repo-only skills (banana-router, monthly-content-refresh, monthly-dedupe, sa-landing-page-layouts, sa-web-layout, seo-competitive-execution, skill-smoke-test, web-ai-concierge, cloudflare-worker-deploy, cowork-disk-cleanup, github-contents-api-push, github-direct-commit, marketing-competitive-context, capacity-watchdog) are not in the mount.

Because of this, the always-allow commit was deliberately not executed: adding salesforce-developer to a repo that lacks its parent skill would orphan it and would not touch the copy that actually runs, and the operator-core router fix cannot be applied in the repo since operator-core is not there. The mount is read-only from the web session. So the live path is install-via-package or apply on the Mac where the mount is writable, and the repo/mount split needs a separate reconciliation decision.

This suggests memory note about skill-sync routing all edits through sail-skills at skills/<name>/SKILL.md may be stale or only ever covered a subset. Worth confirming whether the litify/operational families live in a different repo or only in the mount.

Why the session ended

Enhancement complete and QA'd. Held at install/commit because the drift finding means the safe action is Sam's call on where these skills are canonical before syncing.

Recommended next actions (Sam's call)

  1. Install v2.1.0 via the .skill (and apply the operator-core router patch) on the writable mount/Mac.
  2. Decide canonical store for the litify/operational families, then reconcile repo and mount so future commits have a real target. Until then, the always-allow commit permission has no valid target for these specific skills.
  3. Optional: run the approved library-wide phantom-router scan and the litify-family hardcoded-path pass once the canonical store is settled, so they are not done twice.

Handoff for the next agent

Everything is in the session outputs (.skill, readable v2.1.0, operator-core patch, README, original rollback). Do not commit these skills to sail-skills until the canonical-store question is resolved; the repo currently lacks the litify family. github-direct-commit on the Mac is the reliable lane once a target exists. Firecrawl keys are in API Keys & App Secrets if deeper Litify scraping is wanted; built-in web fetch was sufficient this pass. No live org writes were made.