/discovery

description: Discover installed and available Salesforce capabilities, drill into a domain or skill, or explicitly add one catalog-authorized project skill.
allowed-tools:
  - Bash

Interpret the optional natural-language arguments as exactly one supported mode. If none were supplied, use `overview`. The journey lifecycle is **Connect → Project → Build → Test → Deploy → Observe**; setup/readiness is a prerequisite, not a journey stage.

• `overview`
• `domain <domain>`
• `skill <name>`
• `index`
• `journey`
• `journey inspect`
• `journey reset [--stage <Connect|Project|Build|Test|Deploy|Observe>] [--scope all|current-org|other-org|unattributed] [--json]`
• `where`
• natural-language `where am I?`
• `add <name>`
• `features [--target-org <alias>] [--refresh] [--json]`
• `internal-preview overview|skill <name>|index [--json]` (unsupported internal checkouts only)
• `internal-preview install <name> [--json]` (explicit guarded project copy)
• `internal-preview install-plan <name> --json` (legacy nonexecuting plan)

For `overview`, `domain`, `skill`, and `index`, validate the domain/name as a single kebab-case token and run the corresponding fixed `${CLAUDE_PLUGIN_ROOT}/scripts/sf-context discovery ...` command. A trailing `--json` is allowed only for these read modes. These default modes use the checked public-channel catalog: the exact public release snapshot plus physically bundled foundation skills. They never scan the internal authoring tree or advertise internal names.

Map `journey`, `where`, or the natural-language question `where am I?` to exactly `${CLAUDE_PLUGIN_ROOT}/scripts/sf-context discovery journey`, with a trailing `--json` only when explicitly requested. Map the explicit `journey inspect` request to exactly `${CLAUDE_PLUGIN_ROOT}/scripts/sf-context discovery journey inspect`, again allowing only an explicitly requested trailing `--json`. Inspect is read-only and reports the bounded sanitized durable-history schema, accepted/rejected/truncated counts, and evidence grouped by stage; it does not replace the separately derived live target, project, source, or test facts. Missing or corrupt history is an honest result, not a reason to reconstruct or expose its raw content.

For `journey reset`, accept only the fixed `--stage`, `--scope`, and optional `--json` values listed above. Reset is a two-turn confirmation flow. First run the command **without** `--confirm`; this mandatory dry run names the sanitized project, exact filters, selected accepted-record count, rejected/truncated status, live-fact relight warning, and nonce. If canonical parsing reports any rejected record or truncation, reset is blocked: selected is zero, no nonce is emitted, and you must not ask for or attempt confirmation. Otherwise show those facts to the user and ask for explicit confirmation that names that project, those filters, and that selected count. Never infer confirmation from the reset request itself or from general approval elsewhere. Only after the user explicitly says yes to that exact dry run may you rerun the identical fixed command with `--confirm <exact nonce>` appended. Never invent, shorten, transform, reuse, or expose anything other than the emitted nonce; if history changes or confirmation is not exact, dry-run again. Do not claim that resetting Connect, Project, or Build erases live facts: those stages have no durable records and re-derive. The runtime creates the contained byte-exact backup and performs the atomic replacement; never manipulate history or backups directly.

Do not pass the alias or question through as an argument. Never place arbitrary user text in a shell command or interpolate it into the fixed command. The signpost rail it prints is a pinned deterministic visual and is the one exception to the presentation freedom below. Answer in two parts, in this order: reproduce the rail in your reply first, inside a fenced block and unmodified — preserve its glyphs and stage labels exactly as emitted rather than redrawing, reordering, or re-glyphing it, and never assume the command's own output is visible to the user — and **then add your own** short read of what that stage means for the work in this project, the concrete next step, and what stays unknown. The rail is the grounding both of you can rely on being identical every session; your read is the relevance it cannot carry. Never replace the rail with a summary of itself and never restate it line by line. Exception: if this turn's context says the plugin already displayed the rail to the user (in color), skip reproducing it and do not re-run the command — give only your read.

Map the natural-language questions `what can I do here?`, `what can this do`, and `what are my options` to the `overview` mode (the capability catalog) — never to `discovery journey`/`where`. These ask what the catalog offers, not where the user sits in the six-stage journey; only the explicit `where am I?`, `where`, and `journey` phrasings request the signpost rail. Do not conflate a "what can I do" question with "where am I?": answer the former with `overview` and never substitute the rail for it. The plugin paints the overview for you when it fires (see below) — you run the `overview` command yourself only in the fallback case described there.

The `overview` block is a pinned, first-party curated capability surface — every line of it (the title, the release/counts line, the offline declared-availability lines, the no-org lead when present, the two labelled groups whose rows pair a friendly domain label and count with one authored example or tagline, and the closing suggestions) is authored copy, not mined from any skill's description, so it is the second exception to the presentation freedom below. It is a Tier-1 surface, like the SessionStart banner: when it fires the plugin paints the block directly onto the user's screen, and this turn's context will say it was displayed. When it has been displayed, do **not** reproduce, redraw, or re-