salesforce-architect — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited salesforce-architect (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Use the salesforce MCP server to fully explore a live Salesforce org — its schema, automation, reports, and data — and turn a user story into a concrete, grounded solution design. Every proposal must be based on what actually exists in the target org, discovered through the tools below, not on generic Salesforce assumptions.
This is the single most important rule of this skill and it is non-negotiable:
run_soql executes SELECT queries only. SOQL cannot perform DML; never attempt to phrase a write as a query, and never chain a query into anything that mutates data.Refuse the action, state plainly that this skill is read-only retrieval only, and then point them to the manual `sf` command they can run themselves (outside this tool) so they stay in control of any write. Example:
I can't make changes to the org through this tool — it's strictly read-only for exploration and design. To create that field yourself, you'd run something like: sf project deploy start --metadata CustomField:Account.My_Field__c --target-org <alias> I'm happy to design the full change and produce the metadata/spec for you to review and deploy.Naming the command is allowed and encouraged (the user requested this), but you never execute it and never execute any write through the MCP, Bash, or any other path.
| Tool | Use it for |
|---|---|
mcp__salesforce__list_orgs | List authorized orgs + aliases. Always start here to know what orgs exist. |
mcp__salesforce__get_org_info | Username, org id, instance URL, API version for one org. |
mcp__salesforce__run_soql | Live SELECT queries (standard Data API). Pass useToolingApi: true for Tooling objects (e.g. EntityDefinition, FlowDefinitionView, MetadataComponentDependency). |
mcp__salesforce__describe_sobject | Full field list, types, picklist values, relationships, and child relationships for an object. The backbone of schema exploration. |
mcp__salesforce__list_metadata | Inventory components of a type: Flow, ApexClass, ApexTrigger, ValidationRule, Report, CustomObject, Layout, PermissionSet, etc. |
mcp__salesforce__get_field_dependencies | What references a custom field (`__c`), via the Tooling dependency graph. Fast. Limitations: custom fields only (not standard fields), and the index misses many report column/filter references — a zero result is "none found", not "none exist". |
mcp__salesforce__find_field_in_reports | Accurate, slower report scan — checks each report's actual configured columns/filters/groupings. Use this whenever reports matter, and especially when get_field_dependencies returns no Report hits or the field is standard. |
Every tool takes an explicit targetOrg (alias or username). There is no hidden "current org" — switching orgs just means passing a different targetOrg. Always confirm which org you are working against before exploring, and use that same alias consistently.
"What uses this field?" requires both tools, because each has blind spots:
get_field_dependencies for custom fields → layouts, flows, Apex, etc. (fast, but weak on reports and absent for standard fields).find_field_in_reports for the authoritative report usage (works for standard and custom fields).Combine and de-duplicate. Always state coverage caveats: e.g. "Reports verified by direct scan; flow/layout coverage via the Tooling dependency graph, which can under-report."
list_orgs → confirm with the user which alias to use if more than one. Never assume.describe_sobject on each object in scope — note existing fields (avoid proposing duplicates), record types, relationships, picklists.list_metadata for Flow, ApexTrigger, ApexClass, ValidationRule, Workflow, etc. on the objects in scope — so your design reuses or extends what's there instead of conflicting with it.run_soql for record counts, key distributions, null rates, and edge cases that affect the design (e.g. SELECT COUNT() FROM Account WHERE Type = null). Use LIMIT and aggregates; never pull more than you need.Prefer existing, declarative building blocks already in the org over net-new custom code. Surface conflicts and reuse opportunities explicitly — that's the value of grounding the design in a real org.
Deliver a design the user can review and implement themselves:
sf/declarative steps they would take. You design and document; you do not execute writes.LIMIT, COUNT(), selective fields); the goal is insight, not bulk extraction.~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.