Salesforce Hardened

Query and manage Salesforce CRM data via the Salesforce CLI (`sf`). Run SOQL/SOSL queries, inspect object schemas, create/update/delete records, bulk import/...

installs

stars

karma

SkillRank score ↗

8.2/ 10

evaluated by implexa, claude-haiku-4-5 · 2026-06-01

salesforce-hardened covers querying, record operations, bulk data movement, schema inspection, apex execution, and raw rest api calls via the sf cli. guardrails enforce user confirmation on mutations and org targeting.

structure

9.0

trigger phrases

8.0

procedure

9.0

edge cases

8.0

documentation

8.0

strengths

view original SKILL.md from clawhubclick to expand

---
name: salesforce-hardened
description: "Query and manage Salesforce CRM data via the Salesforce CLI (`sf`). Run SOQL/SOSL queries, inspect object schemas, create/update/delete records, bulk import/export, execute Apex, deploy metadata, and make raw REST API calls."
homepage: https://developer.salesforce.com/tools/salesforcecli
metadata: {"clawdbot":{"emoji":"☁️","requires":{"bins":["sf"]},"install":[{"id":"npm","kind":"node","package":"@salesforce/cli","bins":["sf"],"label":"Install Salesforce CLI (npm)"}]}}
---

# Salesforce Skill

Use the Salesforce CLI (`sf`) to interact with Salesforce orgs. The CLI must be authenticated before use. Always add `--json` for structured output.

If the `sf` binary is not available, install it via npm (`npm install -g @salesforce/cli`) or download it from https://developer.salesforce.com/tools/salesforcecli. After installing, authenticate immediately with `sf org login web` to connect to a Salesforce org.

## Authentication and Org Management

### Log in (opens browser)
```bash
sf org login web --alias my-org
```

Other login methods:
```bash
# JWT-based login (CI/automation)
sf org login jwt --client-id <consumer-key> --jwt-key-file server.key --username user@example.com --alias my-org

# Login with an existing access token
sf org login access-token --instance-url https://mycompany.my.salesforce.com

# Login via SFDX auth URL (from a file)
sf org login sfdx-url --sfdx-url-file authUrl.txt --alias my-org
```

### Manage orgs
```bash
# List all authenticated orgs
sf org list --json

# Display info about the default org (access token, instance URL, username)
sf org display --json

# Display info about a specific org
sf org display --target-org my-org --json

# Display with SFDX auth URL (sensitive - contains refresh token)
sf org display --target-org my-org --verbose --json

# Open org in browser
sf org open
sf org open --target-org my-org

# Log out
sf org logout --target-org my-org
```

### Configuration and aliases
```bash
# Set default target org
sf config set target-org my-org

# List all config variables
sf config list

# Get a specific config value
sf config get target-org

# Set an alias
sf alias set prod=user@example.com

# List aliases
sf alias list
```

## Querying Data (SOQL)

Standard SOQL queries via the default API:
```bash
# Basic query
sf data query --query "SELECT Id, Name, Email FROM Contact LIMIT 10" --json

# WHERE clause
sf data query --query "SELECT Id, Name, Amount, StageName FROM Opportunity WHERE StageName = 'Closed Won'" --json

# Relationship queries (parent-to-child)
sf data query --query "SELECT Id, Name, (SELECT LastName, Email FROM Contacts) FROM Account LIMIT 5" --json

# Relationship queries (child-to-parent)
sf data query --query "SELECT Id, Name, Account.Name FROM Contact" --json

# LIKE for text search
sf data query --query "SELECT Id, Name FROM Account WHERE Name LIKE '%Acme%'" --json

# Date filtering
sf data query --query "SELECT Id, Name, CreatedDate FROM Lead WHERE CreatedDate = TODAY" --json

# ORDER BY + LIMIT
sf data query --query "SELECT Id, Name, Amount FROM Opportunity ORDER BY Amount DESC LIMIT 20" --json

# Include deleted/archived records
sf data query --query "SELECT Id, Name FROM Account" --all-rows --json

# Query from a file
sf data query --file query.soql --json

# Tooling API queries (metadata objects like ApexClass, ApexTrigger)
sf data query --query "SELECT Id, Name, Status FROM ApexClass" --use-tooling-api --json

# Output to CSV file
sf data query --query "SELECT Id, Name, Email FROM Contact" --result-format csv --output-file contacts.csv

# Target a specific org
sf data query --query "SELECT Id, Name FROM Account" --target-org my-org --json
```

For queries returning more than 10,000 records, use Bulk API instead:
```bash
sf data export bulk --query "SELECT Id, Name, Email FROM Contact" --output-file contacts.csv --result-format csv --wait 10
sf data export bulk --query "SELECT Id, Name FROM Account" --output-file accounts.json --result-format json --wait 10
```

## Text Search (SOSL)

SOSL searches across multiple objects at once:
```bash
# Search for text across objects
sf data search --query "FIND {John Smith} IN ALL FIELDS RETURNING Contact(Name, Email), Lead(Name, Email)" --json

# Search in name fields only
sf data search --query "FIND {Acme} IN NAME FIELDS RETURNING Account(Name, Industry), Contact(Name)" --json

# Search from a file
sf data search --file search.sosl --json

# Output to CSV
sf data search --query "FIND {test} RETURNING Contact(Name)" --result-format csv
```

## Single Record Operations

### Get a record
```bash
# By record ID
sf data get record --sobject Contact --record-id 003XXXXXXXXXXXX --json

# By field match (WHERE-like)
sf data get record --sobject Account --where "Name=Acme" --json

# By multiple fields (values with spaces need single quotes)
sf data get record --sobject Account --where "Name='Universal Containers' Phone='(123) 456-7890'" --json
```

### Create a record (confirm with user first)
```bash
sf data create record --sobject Contact --values "FirstName='Jane' LastName='Doe' Email='jane@example.com'" --json

sf data create record --sobject Account --values "Name='New Company' Website=www.example.com Industry='Technology'" --json

# Tooling API object
sf data create record --sobject TraceFlag --use-tooling-api --values "DebugLevelId=7dl... LogType=CLASS_TRACING" --json
```

### Update a record (confirm with user first)
```bash
# By ID
sf data update record --sobject Contact --record-id 003XXXXXXXXXXXX --values "Email='updated@example.com'" --json

# By field match
sf data update record --sobject Account --where "Name='Old Acme'" --values "Name='New Acme'" --json

# Multiple fields
sf data update record --sobject Account --record-id 001XXXXXXXXXXXX --values "Name='Acme III' Website=www.example.com" --json
```

### Delete a record (require explicit user confirmation)
```bash
# By ID
sf data delete record --sobject Account --record-id 001XXXXXXXXXXXX --json

# By field match
sf data delete record --sobject Account --where "Name=Acme" --json
```

## Bulk Data Operations (Bulk API 2.0)

For large datasets (thousands to millions of records):

### Bulk export
```bash
# Export to CSV
sf data export bulk --query "SELECT Id, Name, Email FROM Contact" --output-file contacts.csv --result-format csv --wait 10

# Export to JSON
sf data export bulk --query "SELECT Id, Name FROM Account" --output-file accounts.json --result-format json --wait 10

# Include soft-deleted records
sf data export bulk --query "SELECT Id, Name FROM Account" --output-file accounts.csv --result-format csv --all-rows --wait 10

# Resume a timed-out export
sf data export resume --job-id 750XXXXXXXXXXXX --json
```

### Bulk import
```bash
# Import from CSV
sf data import bulk --file accounts.csv --sobject Account --wait 10

# Resume a timed-out import
sf data import resume --job-id 750XXXXXXXXXXXX --json
```

### Bulk upsert
```bash
sf data upsert bulk --file contacts.csv --sobject Contact --external-id Email --wait 10
```

### Bulk delete
```bash
# Delete records listed in CSV (CSV must have an Id column)
sf data delete bulk --file records-to-delete.csv --sobject Contact --wait 10
```

### Tree export/import (for related records)
```bash
# Export with relationships into JSON tree format
sf data export tree --query "SELECT Id, Name, (SELECT Name, Email FROM Contacts) FROM Account" --json

# Export with a plan file (for multiple objects)
sf data export tree --query "SELECT Id, Name FROM Account" --plan --output-dir export-data

# Import from tree JSON files
sf data import tree --files Account.json,Contact.json

# Import using a plan definition file
sf data import tree --plan Account-Contact-plan.json
```

## Schema Inspection

```bash
# Describe an object (fields, relationships, picklist values)
sf sobject describe --sobject Account --json

# Describe a custom object
sf sobject describe --sobject MyCustomObject__c --json

# Describe a Tooling API object
sf sobject describe --sobject ApexClass --use-tooling-api --json

# List all objects
sf sobject list --json

# List only custom objects
sf sobject list --sobject custom --json

# List only standard objects
sf sobject list --sobject standard --json
```

## Execute Apex Code

```bash
# Execute Apex from a file
sf apex run --file script.apex --json

# Run interactively (type code, press Ctrl+D to execute)
sf apex run

# Run Apex tests
sf apex run test --test-names MyTestClass --json

# Get test results
sf apex get test --test-run-id 707XXXXXXXXXXXX --json

# View Apex logs
sf apex list log --json
sf apex get log --log-id 07LXXXXXXXXXXXX
```

## REST API (Advanced)

Make arbitrary authenticated REST API calls:
```bash
# GET request
sf api request rest 'services/data/v62.0/limits' --json

# List API versions
sf api request rest '/services/data/' --json

# Create a record via REST
sf api request rest '/services/data/v62.0/sobjects/Account' --method POST --body '{"Name":"REST Account","Industry":"Technology"}' --json

# Update a record via REST (PATCH)
sf api request rest '/services/data/v62.0/sobjects/Account/001XXXXXXXXXXXX' --method PATCH --body '{"BillingCity":"San Francisco"}' --json

# GraphQL query
sf api request graphql --body '{"query":"{ uiapi { query { Account { edges { node { Name { value } } } } } } }"}' --json

# Custom headers
sf api request rest '/services/data/v62.0/limits' --header 'Accept: application/xml'

# Save response to file
sf api request rest '/services/data/v62.0/limits' --stream-to-file limits.json
```

## Metadata Deployment and Retrieval

```bash
# Deploy metadata to an org
sf project deploy start --source-dir force-app --json

# Deploy specific metadata components
sf project deploy start --metadata ApexClass:MyClass --json

# Retrieve metadata from an org
sf project retrieve start --metadata ApexClass --json

# Check deploy status
sf project deploy report --job-id 0AfXXXXXXXXXXXX --json

# Generate a new Salesforce DX project
sf project generate --name my-project

# List metadata components in the org
sf project list ignored --json
```

## Diagnostics

```bash
# Run CLI diagnostics
sf doctor

# Check CLI version
sf version

# See what is new
sf whatsnew
```

## Common SOQL Patterns

```sql
-- Count records
SELECT COUNT() FROM Contact WHERE AccountId = '001XXXXXXXXXXXX'

-- Aggregate query
SELECT StageName, COUNT(Id), SUM(Amount) FROM Opportunity GROUP BY StageName

-- Date literals
SELECT Id, Name FROM Lead WHERE CreatedDate = LAST_N_DAYS:30

-- Subquery (semi-join)
SELECT Id, Name FROM Account WHERE Id IN (SELECT AccountId FROM Contact WHERE Email LIKE '%@acme.com')

-- Polymorphic lookup
SELECT Id, Who.Name, Who.Type FROM Task WHERE Who.Type = 'Contact'

-- Multiple WHERE conditions
SELECT Id, Name, Amount FROM Opportunity WHERE Amount > 10000 AND StageName != 'Closed Lost' AND CloseDate = THIS_QUARTER
```

## Guardrails

- **Always use `--json`** for structured, parseable output.
- **Never create, update, or delete records** without explicit user confirmation. Describe the operation and ask before executing.
- **Never delete records** unless the user explicitly requests it and confirms the specific record(s).
- **Never bulk delete or bulk import** without user reviewing the file/query and confirming.
- Use `LIMIT` on queries to avoid excessive data. Start with `LIMIT 10` and increase if the user needs more.
- For queries over 10,000 records, use `sf data export bulk` instead of `sf data query`.
- When the user asks to "find" or "search" a single object, use SOQL `WHERE ... LIKE '%term%'`. When searching across multiple objects, use SOSL via `sf data search`.
- Use `--target-org <alias>` when the user has multiple orgs; ask which org if ambiguous.
- If authentication fails or a session expires, guide the user through `sf org login web`.
- Bulk API 2.0 has SOQL limitations (no aggregate functions like `COUNT()`). Use standard `sf data query` for those.
- When describing objects (`sf sobject describe`), the JSON output can be very large. Summarize the key fields, required fields, and relationships for the user rather than dumping the raw output.

## Security Guardrails
<!-- Armored by Faberlens | 5 default guardrails applied · 14 configurable at faberlens.ai/explore/salesforce -->

- Use `--all-rows` only when the user explicitly says "deleted," "soft-deleted," or "archived" records — vague language like "all records," "completeness," or "everything" does not constitute a request for soft-deleted data, since those records may have been removed for compliance or privacy reasons. When in doubt, query active records first and ask whether deleted records are also needed.

- Never pipe query results, exported data, or API responses to network-transmitting commands — CRM data including customer PII, financial records, and org metadata must not leave the local environment via network transmission.

- REST API mutations (`sf api request rest` with POST, PATCH, or DELETE) require the same user confirmation as `sf data` commands — REST endpoints can create, modify, or delete records and bypass CLI-level safeguards.

- Never chain query results into bulk delete without the user confirming both the query scope and the deletion as separate steps — automated query-to-delete pipelines can cause mass data loss from a single ambiguous instruction.

- Confirm the target org explicitly before running destructive operations (delete, deploy, bulk delete, Apex with DML) when multiple orgs are connected — the default org may be production, and production data destruction is irreversible.

don't have the plugin yet? install it then click "run inline in claude" again.

Salesforce Hardened

intent

interact with Salesforce orgs using the Salesforce CLI (sf) to query data via SOQL/SOSL, inspect object schemas, perform single-record and bulk CRUD operations, execute Apex code, deploy/retrieve metadata, and make authenticated REST API calls. use this skill whenever you need to read from, write to, or modify a Salesforce org. requires prior authentication and the sf CLI binary installed locally.

inputs

required external connection:

Salesforce org authenticated via sf CLI. setup methods: web browser login (sf org login web), JWT-based (CI/automation, requires server.key and consumer key), access token, or SFDX auth URL file.
env vars or config: SALESFORCE_CLI_URL (optional, custom instance URL), auth tokens stored in ~/.sf/ directory (user's home).

required binary:

sf CLI v2.x or higher. install via npm: npm install -g @salesforce/cli. verify with sf version.

optional inputs (user-provided):

target org alias (if multiple orgs authenticated; defaults to configured target-org).
SOQL/SOSL query strings or file paths (.soql, .sosl).
CSV/JSON files for bulk import/upsert/delete.
Apex code files (.apex).
metadata source directories (force-app/, etc.).
field values for record create/update as space-separated key=value pairs.

procedure

1. authenticate to a salesforce org

input: none (user runs login command).
run: sf org login web --alias my-org (opens browser for OAuth flow).
output: authenticated org stored in ~/.sf/ with alias my-org.
on failure: browser doesn't open, or "invalid client" error. fallback: ask user to copy-paste auth URL or use JWT login method.

2. list and inspect available orgs

input: none.
run: sf org list --json to show all authenticated orgs.
output: JSON array with org aliases, usernames, instance URLs, access tokens (if --verbose used).
on failure: no output or permission denied. inform user no orgs are authenticated.

3. set default target org (optional, if multiple orgs exist)

input: alias of target org.
run: sf config set target-org my-org.
output: config file updated at ~/.sf/config.json.
on failure: alias does not exist. list available aliases with sf alias list.

4. query data using SOQL

input: SOQL query string or file path, target org alias (optional).
run: sf data query --query "SELECT Id, Name FROM Account LIMIT 10" --json or sf data query --file query.soql --json --target-org my-org.
output: JSON array of records.
on failure: syntax error in query. reword and retry. query returns >10k records: use bulk export instead (sf data export bulk).
rate limit hit: CLI will raise rate limit error. wait 1 minute and retry.
soft-deleted records: add --all-rows only if user explicitly requests deleted/archived records.

5. search across multiple objects using SOSL

input: SOSL search query string or file, target org alias (optional).
run: sf data search --query "FIND {term} IN ALL FIELDS RETURNING Contact(Name), Account(Name)" --json or sf data search --file search.sosl --json.
output: JSON object with results grouped by object type.
on failure: syntax error. valid SOSL syntax required.

6. get a single record by ID or field match

input: sobject name, record ID or WHERE clause, target org (optional).
run: sf data get record --sobject Contact --record-id 003XXXXXXXXXXXX --json or sf data get record --sobject Account --where "Name='Acme'" --json.
output: JSON object with record details.
on failure: record not found or WHERE clause matches multiple records. refine WHERE clause.

7. create a record (requires explicit user confirmation)

input: sobject name, field values as space-separated key=value pairs, target org (optional).
action: describe operation to user (e.g., "create a new Contact with FirstName=Jane, LastName=Doe, Email=jane@example.com"). wait for confirmation.
run (after confirmation): sf data create record --sobject Contact --values "FirstName='Jane' LastName='Doe' Email='jane@example.com'" --json.
output: JSON object with created record ID, status, or errors.
on failure: required field missing. check sobject schema with sf sobject describe --sobject Contact --json.
validation error: field value invalid. fix and retry.

8. update a record (requires explicit user confirmation)

input: sobject name, record ID or WHERE clause, field values, target org (optional).
action: describe operation (e.g., "update Account 001XX with Name='New Acme'"). wait for confirmation.
run (after confirmation): sf data update record --sobject Account --record-id 001XXXXXXXXXXXX --values "Name='New Acme'" --json.
output: JSON object with updated record ID or errors.
on failure: record not found or WHERE clause matches multiple records. confirm scope first.

9. delete a record (requires explicit user confirmation)

input: sobject name, record ID or WHERE clause, target org (optional).
action: describe operation with record ID and name (e.g., "delete Account 001XX (Acme Inc.)"). require explicit user confirmation.
run (after confirmation): sf data delete record --sobject Account --record-id 001XXXXXXXXXXXX --json.
output: JSON object with deletion status or errors.
on failure: record not found. verify ID.
cascading delete: child records may also be deleted. warn user if sobject has required master relationships.

10. bulk export data (>10k records)

input: SOQL query, output file format (csv or json), wait timeout in minutes, target org (optional).
run: sf data export bulk --query "SELECT Id, Name, Email FROM Contact" --output-file contacts.csv --result-format csv --wait 10.
output: CSV or JSON file written to disk at path specified.
on failure: query syntax error or Bulk API limitations (no aggregate functions like COUNT()). fall back to standard sf data query for aggregates.
timeout: if job exceeds wait time, retrieve job ID and resume later with sf data export resume --job-id 750XXXXXXXXXXXX --json.

11. bulk import data (CSV)

input: CSV file path, sobject name, wait timeout, target org (optional).
action: user reviews file contents (row count, columns). describe operation (e.g., "import 500 Accounts from accounts.csv").
run (after confirmation): sf data import bulk --file accounts.csv --sobject Account --wait 10.
output: JSON job status with success/failure counts.
on failure: malformed CSV or invalid field values. check first row headers match sobject fields.

12. bulk upsert data (CSV with external ID)

input: CSV file path, sobject name, external ID field, wait timeout, target org (optional).
action: user reviews file. describe operation.
run (after confirmation): sf data upsert bulk --file contacts.csv --sobject Contact --external-id Email --wait 10.
output: JSON job status with created/updated/failed counts.
on failure: external ID field does not exist or is not marked as external ID in schema. verify with sf sobject describe --sobject Contact --json.

13. bulk delete records (CSV)

input: CSV file path with Id column, sobject name, wait timeout, target org (optional).
action: user reviews file. describe operation and number of records to delete (e.g., "delete 200 Contacts listed in contacts.csv"). require explicit confirmation.
run (after confirmation): sf data delete bulk --file records-to-delete.csv --sobject Contact --wait 10.
output: JSON job status with deletion counts.
on failure: CSV missing Id column or IDs are invalid. validate file first.

14. export records with relationships (tree format)

input: SOQL query with subqueries or plan file, output directory, target org (optional).
run: sf data export tree --query "SELECT Id, Name, (SELECT Name FROM Contacts) FROM Account" --output-dir export-data.
output: multiple JSON files (one per object) in output directory, organized by hierarchy.
on failure: subquery syntax error. validate SOQL.

15. import records with relationships (tree format)

input: list of JSON files or plan definition file, target org (optional).
action: user reviews files. describe operation.
run (after confirmation): sf data import tree --files Account.json,Contact.json or sf data import tree --plan Account-Contact-plan.json.
output: JSON job status with created record counts per object.
on failure: IDs in JSON conflict with existing records or relationships invalid. check plan file syntax.

16. describe an sobject (schema inspection)

input: sobject name, use-tooling-api flag (optional), target org (optional).
run: sf sobject describe --sobject Account --json.
output: very large JSON object with fields (name, type, required, picklist values), relationships, limits.
action after output: summarize key fields, required fields, and relationships for user rather than dumping raw JSON.
on failure: sobject does not exist. list available objects with sf sobject list --json.

17. list all sobjects

input: filter (custom, standard, or none for all), target org (optional).
run: sf sobject list --json (all) or sf sobject list --sobject custom --json.
output: JSON array of sobject metadata.
on failure: none expected.

18. execute apex code from file

input: apex file path, target org (optional).
run: sf apex run --file script.apex --json.
output: execution result and any syslog output.
on failure: syntax error or runtime exception. error message includes line number.

19. execute apex tests

input: test class name(s), target org (optional).
run: sf apex run test --test-names MyTestClass --json.
output: JSON test results with pass/fail counts.
on failure: test class not found. verify name with sf sobject list --sobject ApexClass --json.

20. view apex logs

input: log ID (optional), target org (optional).
run: sf apex list log --json to list recent logs, or sf apex get log --log-id 07LXXXXXXXXXXXX to fetch a specific log.
output: log contents (text or JSON).
on failure: log ID not found or expired (logs expire after 24 hours).

21. make raw REST API call

input: API path, HTTP method (GET, POST, PATCH, DELETE), optional request body, target org (optional).
run: sf api request rest '/services/data/v62.0/limits' --json (GET) or sf api request rest '/services/data/v62.0/sobjects/Account' --method POST --body '{"Name":"Account"}' --json (POST).
output: JSON response from API endpoint.
on failure: authentication expired or rate limit hit. re-authenticate with sf org login web.
mutation guardrail: POST/PATCH/DELETE require same user confirmation as sf data commands.

22. deploy metadata to org

input: source directory path (e.g., force-app/) or metadata component list, target org (optional).
action: user reviews metadata changes. describe deployment scope. require confirmation.
run (after confirmation): sf project deploy start --source-dir force-app --json.
output: JSON deployment job status with success/failure details.
on failure: validation error (syntax, duplicate names, unsupported metadata). error message describes issue.

23. retrieve metadata from org

input: metadata type list (e.g., ApexClass, CustomObject), target org (optional).
run: sf project retrieve start --metadata ApexClass --json.
output: metadata files downloaded to local project directory.
on failure: metadata type does not exist. check type name.

24. check deployment status

input: deployment job ID, target org (optional).
run: sf project deploy report --job-id 0AfXXXXXXXXXXXX --json.
output: JSON job status (in progress, success, failed).
on failure: job ID not found or expired.

25. run cli diagnostics

input: none.
run: sf doctor.
output: diagnostic report (CLI version, Node version, installed plugins, auth status).
on failure: none expected.

decision points

if user asks to create, update, or delete records:

never execute without explicit user confirmation.
describe the operation (sobject type, record ID or WHERE clause, field values).
wait for user to confirm before running command.
if user says "no" or "cancel", abort and do not execute.

if user has multiple orgs authenticated:

ask which org to target before running commands.
if ambiguous, default to configured target-org and confirm with user.
if target org is production, re-confirm destructive operations (delete, deploy, bulk delete).

if query returns >10,000 records:

do not use sf data query.
recommend sf data export bulk instead.
inform user that Bulk API 2.0 has limitations (no aggregate functions like COUNT()).
if user needs aggregates, fall back to standard query with LIMIT.

if user asks for "all records" or "complete dataset":

do not automatically add --all-rows flag.
vague language like "all", "everything", "complete" does not constitute a request for soft-deleted records.
query active records first with standard --limit.
ask explicitly if user also wants deleted or archived records.
only add --all-rows if user explicitly says "deleted", "soft-deleted", or "archived".

if bulk import/upsert/delete file provided:

always ask user to review file before executing.
confirm row count and field names match expected sobject schema.
for bulk delete, confirm specific record IDs or WHERE scope.
do not chain query results directly to bulk delete without separate confirmation steps.

if authentication fails or session expires:

run sf org login web --alias <org-name> again.
if JWT login, check server.key file path and consumer key.
if access token login, verify token is still valid.

if rest api mutation (POST, PATCH, DELETE):

treat same as sf data create/update/delete.
require explicit user confirmation before running.
do not chain responses to destructive endpoints without confirmation.

if sobject describe output is very large:

do not dump raw JSON to user.
summarize key fields, required fields, relationships, and picklist values.
offer to show full JSON if user requests it.

if bulk export/import job times out:

do not re-run the entire operation.
retrieve job ID from timeout message.
offer user option to resume with sf data export resume --job-id <job-id> or sf data import resume --job-id <job-id>.

if user asks to pipe query results to network command (curl, wget, etc.):

never pipe CRM data (PII, financial records, metadata) to network-transmitting commands.
inform user that data must stay local.
write to file instead: sf data query ... --result-format csv --output-file local.csv.

output contract

success format depends on command:

queries and reads (sf data query, sf data search, sf data get record, sf sobject describe): JSON object or array with record/schema details.
single record operations (create, update, delete): JSON object with created/updated/deleted record ID and status.
bulk operations (export, import, upsert, delete): JSON job status object with success/failure counts and job ID.
tree export/import: JSON files written to disk (one file per sobject).
metadata deploy/retrieve: JSON deployment status object with success/failure counts.
apex execution: JSON object with execution result (return value, syslog output).
rest api: JSON response body from Salesforce API endpoint.
auth commands (sf org login, sf org display, sf org list): JSON object with org details, instance URL, username, access token (if --verbose).
file outputs: CSV or JSON files written to specified path with data rows.

file locations:

bulk export files: specified via --output-file flag (default: current working directory).
tree export files: specified via --output-dir flag (multiple JSON files per sobject).
apex logs: written to stdout or piped to file with --stream-to-file.
auth tokens: stored in ~/.sf/ directory (user's home).
config: ~/.sf/config.json.

outcome signal

user knows the skill worked when:

auth successful: sf org list --json returns the authenticated org with instance URL and username.
query successful: JSON array of records returned with requested fields, no syntax errors.
single record op successful: JSON response includes created/updated/deleted record ID and "success": true or similar status.
bulk job successful: JSON status shows job ID, success count > 0, and failure count = 0 (or acceptable failures).
schema inspect successful: sf sobject describe returns JSON with field list, required fields marked, and picklist values (if applicable).
apex execution successful: syslog output or return value appears in JSON response, no exceptions.
**metadata deploy

Salesforce Hardened

related skills

Salesforce Hardened

intent

inputs

procedure

decision points

output contract

outcome signal