forcedotcom/sf-skills is a collection of reusable instructions that help AI coding agents build and work with Salesforce applications and platform features. Developers use it for Agentforce agents, Lightning apps, Flow, Apex, SOQL, Lightning Web Components, and related Salesforce configuration. The catalogue entries are the repository’s skills, plugins, commands, MCP servers, and agents for AI tools that support skills.
Getting it into your agent
This one installs as part of its plugin. Adding the marketplace and installing the plugin brings it with everything else the plugin ships.
/plugin marketplace add forcedotcom/sf-skills/plugin install salesforce-developmentWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/forcedotcom/sf-skills/plugin-install)<a href="https://agentmods.dev/commands/forcedotcom/sf-skills/plugin-install"><img src="https://agentmods.dev/badge/commands/forcedotcom/sf-skills/plugin-install/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/commands/forcedotcom/sf-skills/plugin-install"><img src="https://agentmods.dev/badge/commands/forcedotcom/sf-skills/plugin-install.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00018 | $0.01361 |
| Opus 5.5 | $0.00007 | $0.00544 |
| Sonnet 5.5 | $0.00004 | $0.00272 |
| Haiku 4.5 | $0.00002 | $0.00136 |
Grade A, and why
plugin-install scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 18d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 22 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Accept exactly one plugin name as <name>. This command installs one named, previously surfaced plugin at a time -- never several, and never a plugin the user has not already seen named (via SessionStart, a prompt-time recommendation, overview, plugins <text>, or a bypass-gate warning) in this conversation.
When the user explicitly accepts a plugin recommendation in this session -- and the prompt hook has registered that acceptance and handed you an instruction naming the plugin -- run exactly ${CLAUDE_PLUGIN_ROOT}/scripts/sf-context plugin-install <name> --accept-proposed. The runtime requires that exact plugin to exist in the same-session proposal ledger and be selected in the active workflow. If it is a trusted install target -- the exact local ./plugins/builder/<name> source -- the user's acceptance is the sole confirmation and the guarded runtime installs immediately. Do not add a second prose confirmation or rerun the command.
Prefer to elicit that acceptance with an ordinary conversational question and the user's own typed reply -- that is the primary path, and a literal UserPromptSubmit message (the user's own words) advances the session's decision workflow to selected. A structured AskUserQuestion selection is also honored: when the user picks an option that names exactly one open proposal, a PostToolUse bridge advances the same workflow to selected just as a typed reply would. So if you do ask with AskUserQuestion, make each install option name the plugin (e.g. "Install salesforce-test-drive"); a bare "Yes"/"No" option names no plugin and advances nothing, and you would then need the user's typed confirmation instead. If you are proposing two or more plugins at once, ask about them with separate, sequential questions that each name exactly one plugin rather than a single question with a combined option (e.g. "Install both") -- a combined option or answer (such as "Both plugins") never names a single open proposal, so the bridge deliberately leaves it unresolved instead of guessing which one, or both, the user meant. A bare affirmative such as "yes", "ok", or "install it" advances the workflow -- and earns you the named install instruction -- only when exactly one plugin is open to acceptance; the runtime resolves that sole candidate for you, including a lone proposal that a topic change just cleared from the live workflow, but only on your very next message -- a short-lived, one-shot marker carries it forward for that one message and nothing later. When two or more are open (for example a plugins <text> discovery list that returned more than one), a bare "yes" is ambiguous: the runtime deliberately does not pick one and instead tells you to ask which the user means, so --accept-proposed would refuse with a missing-same-session-selection error. Do not guess or retry --accept-proposed then -- ask the user which single plugin they mean and have them name it (e.g. "install salesforce-test-drive"); a named acceptance always selects itself, no matter how many were proposed, and is also the only way to re-accept a plugin the user previously declined (a bare "yes" never reverses a decline).
If the accepted entry is not a trusted install target -- its source is not that exact ./plugins/builder/<name> path -- the same command installs nothing. It prints the concrete source, a TRUST WARNING, and a content-bound nonce. Relay that output faithfully and ask the user to confirm that exact source. Only after that confirmation run ${CLAUDE_PLUGIN_ROOT}/scripts/sf-context plugin-install <name> --confirm <exact nonce>. Never invent, shorten, transform, reuse, or expose another nonce; a stale or mismatched nonce requires a fresh source preview. A bare self-directed plugin-install <name> call retains this source-preview path for compatibility and does not inherit the trusted accepted-proposal fast path.
A successful install shells out to claude plugin marketplace add when needed for a reachable local-development checkout and then claude plugin install on the user's behalf, with fixed argv and no shell. Failure output contains only exit/timeout metadata, never raw subprocess text. Installation changes Claude Code's on-disk/enabled state; it does not prove that this running session's plugin catalog, skills, hooks, agents, or MCP servers have been rebuilt.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 18d ago Changed 5bcfdee411ae
- 1mo ago Changed 907a396d0af8
- 1mo ago First seen · 22 lines · 18 tokens per session scan A 8b301412c334
plugin-install is a command published in the GitHub repository forcedotcom/sf-skills (1,104 stars, last pushed yesterday), licensed Apache-2.0. It adds 18 tokens to every session and 1,361 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other commands, from other repositories
template
Manage issue templates for streamlined issue creation.
add-note
Add an internal or external note to a ConnectWise PSA ticket.
fest-show
Show festival progression (in-progress tasks, roadmap, and dependency view).
sync-linear
Sync current work with Linear ticket status.
dispatcher
Use when you want the orchestrator to pick the next repo to work on across your whole portfolio — it enumerates candidate repos below the confinement root, resolves free/busy from each repo's session.lock lease, ranks the FREE ones by backlog priority × staleness × readiness, recommends the single most worthwhile one…
workpm
A project-management workflow for coordinating multiple AI workers through five stages. It includes task assignment, shared activity logs, worker replacement, and final checks.