Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add commands/forcedotcom/sf-skills/plugin-installgit clone --depth 1 https://github.com/forcedotcom/sf-skillsWrote 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.svg" alt="Measured on agentmods" 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 | $0.00018 | $0.01160 |
| Opus 5 | $0.00009 | $0.00580 |
| Sonnet 5 | $0.00004 | $0.00232 |
| Haiku 4.5 | $0.00002 | $0.00116 |
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 today.
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 its marketplace source is exactly ./plugins/builder/<name>, 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.
Elicit that acceptance with an ordinary conversational question and wait for the user's own typed reply -- never through AskUserQuestion or another structured tool-call confirmation. Only a literal UserPromptSubmit message (the user's own words) advances the session's decision workflow to selected; a tool's structured answer never passes through that hook, no matter how affirmative it reads. 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 was proposed this session; the runtime resolves that sole candidate for you. When several were proposed (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. The same missing-selection refusal happens if acceptance arrived through AskUserQuestion (the hook never saw it); recover the same way -- have the user restate it, or name the plugin, in a plain message -- then run the command.
If the accepted entry has any other source shape -- including an external URL/object source -- 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.
On success, relay the command's complete activation handoff verbatim. Then stop the turn: do not continue the original plugin-dependent request, invoke a skill from the new plugin, or claim the plugin is active. The user's next action is the exact host command /reload-plugins; do not try to execute or imitate that slash command through Bash. The handoff is task-aware: when installation interrupted a concrete task it explicitly tells the user to say continue after reload to resume that task; a recommendation-only install instead asks for a new concrete task. After the user runs /reload-plugins, follow that handoff without making them restate an interrupted task, but first use Claude Code's refreshed plugin/skill inventory to verify that the named plugin or its namespaced components are present. If the host does not expose a refreshed inventory, say activation could not be verified and ask the user to start a fresh session; never turn an on-disk install or enabledPlugins setting into a claim of live activation. A SessionStart hook payload does not identify /reload-plugins or enumerate the active plugin set, so do not invent either signal.
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.
- today First seen · 22 lines · 18 tokens per session scan A 8b301412c334
plugin-install is a command published in the GitHub repository forcedotcom/sf-skills (961 stars, last pushed yesterday), licensed Apache-2.0. It adds 18 tokens to every session and 1,160 once invoked, about $0.0001 per session on Opus 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
project-recap
Generate a visual project recap for context switching.
standup
Show a daily standup summary with completed, in-progress, and blocked tasks across all active epics.
m-task-planner
Target: $ARGUMENTS (Default: requirement document(s) discovered in the project).
triage
Triage ServiceNow incidents — list open incidents, assess priority, investigate a specific INC, or analyze trends.
session-log
Create or append a session log entry.
my-tasks
Track, prioritize, and execute tasks with goal alignment and due date awareness. Claude doesn't just remind you — it helps get work done.