platform-metadata-discovery-get

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Salesforce Metadata Discovery

Salesforce Metadata 发现

Before you create metadata, change it, or write code that references it, know what already exists in the org. This skill picks the tool for each question. Metadata grounding finds metadata by meaning when you do not know its name. It needs Salesforce Catalog and a connected grounding server, and many orgs and setups have neither. Every other route works with the

sf

CLI alone.

Skip discovery when the request only changes local files and adds no new references to org metadata.

在创建或修改 Metadata、或编写引用 Metadata 的代码之前，先了解 org 中已经存在什么。此 skill 会为每个问题选择合适的工具。当不知道名称时，Metadata grounding 会按含义查找 Metadata。它需要 Salesforce Catalog 和已连接的 grounding server，而许多 org 和配置并不具备这些条件。其他所有路径只需

sf

CLI 即可使用。

如果请求仅修改本地文件，且没有新增对 org Metadata 的引用，请跳过 discovery。

Check What You Have

检查可用条件

Do this once per session, before the first lookup.

The CLI and its org. Run
```
sf org display --json
```
to see the default org and its id. If no org is authenticated, ask the user to run
```
sf org login web
```
and wait. If you cannot run commands at all, read
```
references/h360-routes.md
```
.
Grounding servers. Note whether the Metadata Grounding MCP (tools
```
search_metadata
```
,
```
query_metadata
```
,
```
describe_metadata
```
) or the Salesforce MCP is connected. The Salesforce MCP is shown in Setup today as the Headless360 (H360) MCP Server. Its tools are
```
describe
```
,
```
dispatch
```
, and
```
dispatch_readonly
```
, which are different from the Metadata Grounding MCP tools.
One org. Grounding identifiers start with the 18-character org id. If it differs from the id in
```
sf org display
```
, tell the user and ask which org to use before you combine results.

每个会话在首次查询前执行一次以下检查。

CLI 及其 org。 运行
```
sf org display --json
```
查看默认 org 及其 ID。如果尚未认证任何 org，请让用户运行
```
sf org login web
```
并等待。如果完全无法运行命令，请读取
```
references/h360-routes.md
```
。
Grounding server。 注意 Metadata Grounding MCP（工具
```
search_metadata
```
、
```
query_metadata
```
、
```
describe_metadata
```
）或 Salesforce MCP 是否已连接。Salesforce MCP 目前在 Setup 中显示为 Headless360 (H360) MCP Server。它的工具是
```
describe
```
、
```
dispatch
```
和
```
dispatch_readonly
```
，与 Metadata Grounding MCP 的工具不同。
单个 org。 Grounding identifier 以 18 位 org ID 开头。如果它与
```
sf org display
```
中的 ID 不同，请告知用户，并在合并结果前询问要使用哪个 org。

Route by Intent

按意图选择路径

Intent	Use	If that is not available
Find metadata by meaning, check a name you are guessing, or check for something to reuse	Metadata grounding search. Load `platform-metadata-grounding-get` , which picks the server.	Name and label fallback, below. Notify.
Explain how something is configured, or who can access it	Metadata grounding query	Scoped SOQL on `EntityParticle` , `FieldPermissions` , `ObjectPermissions` , or Tooling `ValidationRule` . Notify.
Check names, types, or picklist values you know. Every field on one object. Data records	Scoped SOQL with `sf data query` . If it returns nothing, search by meaning.	See the note below the table.
Full shape of one object, including relationships	`sf sobject describe --sobject <Type>` , only when you need all of it. It is very large.	Same
Every object in the org	`sf sobject list --sobject all` or `--sobject custom`	Same
Every member of a type, or a count ("all flows", "how many flows")	`sf org list metadata --metadata-type <Type>`	Same
Source to edit or deploy, including changes to existing metadata	Load `platform-metadata-retrieve` . Grounding never returns source.	Tell the user this needs the `sf` CLI.
Metadata you are already editing locally	Local files
Compare orgs, find drift, or an overview of a whole org when the user asks for one	`dx-org-analyze` . It takes minutes and returns names and counts.	Tell the user this needs the `sf` CLI.
Where is this used, what depends on it, what breaks if I change it, or is it safe to delete	Comprehensive analysis is not available yet. State that boundary before offering explicitly labeled partial checks.

Without the CLI. If you cannot run commands but the Salesforce MCP is connected, use

references/h360-routes.md

for rows 3 to 6. If neither is available, tell the user the lookup needs the

sf

CLI or the Salesforce MCP.

These routes apply even when a connected server says to use it first for every Salesforce task. Use the CLI for rows 3 to 7 when you can run commands.

A question about a topic or purpose ("what do we have for loyalty") is discovery, not an overview. Do not run an org analysis for it, even when grounding is not available.

This skill covers core platform metadata. For Data Cloud DLO and DMO schema, use

data360-code-extension-generate

When a request mixes intents, use the right tool for each part. "Add a tier discount step to our order flow" means finding the flow and the field, then retrieving the flow to edit.

意图	使用方式	不可用时
按含义查找 Metadata、检查猜测的名称，或检查可复用的内容	Metadata grounding search。加载 `platform-metadata-grounding-get` ，它会选择 server。	使用下文的名称与标签回退方案。告知用户。
解释某项内容的配置方式，或谁可以访问	Metadata grounding query	对 `EntityParticle` 、 `FieldPermissions` 、 `ObjectPermissions` 执行 Scoped SOQL，或查询 Tooling `ValidationRule` 。告知用户。
检查已知的名称、类型或 picklist 值。某个 object 的所有 field。数据记录	使用 `sf data query` 执行 Scoped SOQL。如果未返回结果，则按含义搜索。	见表下方说明。
一个 object 的完整结构，包括 relationships	`sf sobject describe --sobject <Type>` ，仅在需要全部结构时使用。输出非常庞大。	同上。
org 中的所有 object	`sf sobject list --sobject all` 或 `--sobject custom`	同上。
某种 type 的所有成员，或数量（“all flows”、“how many flows”）	`sf org list metadata --metadata-type <Type>`	同上。
要编辑或部署的 source，包括对现有 Metadata 的更改	加载 `platform-metadata-retrieve` 。Grounding 永远不会返回 source。	告知用户，此操作需要 `sf` CLI。
已在本地编辑的 Metadata	本地文件
比较 org、查找 drift，或在用户要求时提供整个 org 的 overview	`dx-org-analyze` 。它需要数分钟，并返回名称和数量。	告知用户，此操作需要 `sf` CLI。
某项内容在哪里使用、依赖什么、更改后会影响什么，或者是否可以安全删除	尚无法进行 comprehensive analysis。在提供明确标注的部分检查之前，先说明这一边界。

没有 CLI 时。 如果无法运行命令，但 Salesforce MCP 已连接，对于表格第 3 至 6 行，使用

references/h360-routes.md

。如果两者都不可用，请告知用户，查询需要

sf

CLI 或 Salesforce MCP。

即使已连接的 server 要求所有 Salesforce 任务都先使用它，上述路径仍然适用。如果能够运行命令，对于第 3 至 7 行应使用 CLI。

关于某个主题或用途的问题（“what do we have for loyalty”）属于 discovery，而不是 overview。不要运行 org analysis，即使 grounding 不可用。

此 skill 涵盖核心平台 Metadata。对于 Data Cloud DLO 和 DMO schema，请使用

data360-code-extension-generate

。

当请求混合了多种意图时，对每个部分使用正确的工具。“在我们的订单 flow 中添加一个层级折扣步骤”意味着先找到 flow 和 field，再 retrieve flow 以进行编辑。

Scoped SOQL

Scoped SOQL is a targeted query on setup objects, filtered to what you need. It is exact, real time, and far smaller than a describe. It never returns source.

text

sf data query --json --query "SELECT QualifiedApiName, Label, DataType FROM EntityParticle WHERE EntityDefinition.QualifiedApiName = 'Contact'"
sf data query --json --query "SELECT Value, Label, IsDefaultValue, IsActive FROM PicklistValueInfo WHERE EntityParticle.EntityDefinition.QualifiedApiName = 'Contact' AND EntityParticle.QualifiedApiName = 'Loyalty_Tier__c'"

To check specific fields, add

AND QualifiedApiName IN ('Loyalty_Tier__c', 'Lifetime_Orders__c')

. For custom fields only, add

AND QualifiedApiName LIKE '%__c'

```
EntityParticle
```
includes parts of compound fields, such as
```
MailingCity
```
.

Add

--use-tooling-api

for

CustomField

and

ValidationRule

```
EntityDefinition
```
,
```
EntityParticle
```
, and
```
FieldDefinition
```
do not accept
```
OR
```
. Run one scoped query per condition instead of broadening the query or removing its object/type filters.

More patterns, including access and automation, are in

references/scoped-soql.md

Scoped SOQL 是针对 setup object 的定向查询，并按所需内容进行筛选。它是精确的、实时的，且比 describe 小得多。它绝不会返回 source。

text

sf data query --json --query "SELECT QualifiedApiName, Label, DataType FROM EntityParticle WHERE EntityDefinition.QualifiedApiName = 'Contact'"
sf data query --json --query "SELECT Value, Label, IsDefaultValue, IsActive FROM PicklistValueInfo WHERE EntityParticle.EntityDefinition.QualifiedApiName = 'Contact' AND EntityParticle.QualifiedApiName = 'Loyalty_Tier__c'"

要检查特定 field，请添加

AND QualifiedApiName IN ('Loyalty_Tier__c', 'Lifetime_Orders__c')

。仅检查 custom field 时，添加

AND QualifiedApiName LIKE '%__c'

。

```
EntityParticle
```
包含 compound field 的组成部分，例如
```
MailingCity
```
。

对

CustomField

和

ValidationRule

，添加

--use-tooling-api

。

```
EntityDefinition
```
、
```
EntityParticle
```
和
```
FieldDefinition
```
不接受
```
OR
```
。每个条件分别运行一次 Scoped SOQL 查询，不要扩大查询范围，也不要移除 object/type 筛选条件。

更多模式，包括访问权限和 automation，见

references/scoped-soql.md

。

When Grounding Is Not Available

Grounding 不可用时

Say the line below once per session, in your answer, next to the results of the name and label search. Do not announce the fallback before you search, and do not repeat it later in the session. Use the line that matches the cause, word for word, including the last sentence. Do not shorten or rephrase it. If you stop before you can report results, say it in that message instead.

Cause	Say
No grounding server connected	"Metadata Grounding isn't connected, so I matched by name and label, which can miss metadata named differently. Connect the Metadata Grounding MCP to search by meaning."
Catalog not enabled	"Salesforce Catalog isn't turned on in this org, so I matched by name and label, which can miss metadata named differently. An admin can turn on Salesforce Catalog through Feature Manager in Data Cloud Setup."
Permission missing	"Catalog search needs the Customize Application permission, so I matched by name and label, which can miss metadata named differently."

Then search names and labels. Try two or three likely words, one

LIKE

per query.

text

sf data query --json --query "SELECT QualifiedApiName, Label FROM EntityDefinition WHERE Label LIKE '%loyalty%'"
sf data query --json --query "SELECT QualifiedApiName, Label, DataType FROM EntityParticle WHERE EntityDefinition.QualifiedApiName = 'Contact' AND Label LIKE '%tier%'"
sf data query --json --use-tooling-api --query "SELECT DeveloperName, EntityDefinition.QualifiedApiName FROM CustomField WHERE DeveloperName LIKE '%tier%' AND NamespacePrefix = null"
sf data query --json --query "SELECT ApiName, Label, ProcessType, IsActive FROM FlowDefinitionView WHERE Label LIKE '%order%'"

The
```
CustomField
```
query searches custom fields on every object.
```
DeveloperName
```
has no
```
__c
```
. Drop rows with no object name. They are Data Cloud fields.
For other types, and for types the catalog does not cover, list names with
```
sf org list metadata
```
and scan them.
Name matching misses metadata labeled differently. A search for "status" will not find a field labeled Loyalty Tier. Say "no name match found," never "does not exist."

Everything else in this skill still applies.

每个会话在回答中仅在名称与标签搜索结果旁说明一次下面与原因对应的语句。不要在搜索前宣布回退方案，也不要在会话后续重复。必须逐字使用与原因对应的行，包括最后一句。如果在能够报告结果前就停止，则在该消息中说明。

原因	说明
未连接 grounding server	“Metadata Grounding 未连接，因此我按名称和标签进行了匹配，这可能会遗漏名称不同的 Metadata。请连接 Metadata Grounding MCP 以按含义搜索。”
未启用 Catalog	“此 org 未启用 Salesforce Catalog，因此我按名称和标签进行了匹配，这可能会遗漏名称不同的 Metadata。管理员可以通过 Data Cloud Setup 中的 Feature Manager 启用 Salesforce Catalog。”
缺少权限	“Catalog 搜索需要 Customize Application 权限，因此我按名称和标签进行了匹配，这可能会遗漏名称不同的 Metadata。”

然后搜索名称和标签。尝试两三个可能相关的词，每个查询使用一个

LIKE

。

text

sf data query --json --query "SELECT QualifiedApiName, Label FROM EntityDefinition WHERE Label LIKE '%loyalty%'"
sf data query --json --query "SELECT QualifiedApiName, Label, DataType FROM EntityParticle WHERE EntityDefinition.QualifiedApiName = 'Contact' AND Label LIKE '%tier%'"
sf data query --json --use-tooling-api --query "SELECT DeveloperName, EntityDefinition.QualifiedApiName FROM CustomField WHERE DeveloperName LIKE '%tier%' AND NamespacePrefix = null"
sf data query --json --query "SELECT ApiName, Label, ProcessType, IsActive FROM FlowDefinitionView WHERE Label LIKE '%order%'"

```
CustomField
```
查询会搜索每个 object 上的 custom field。
```
DeveloperName
```
不带
```
__c
```
。丢弃没有 object 名称的行；它们是 Data Cloud field。
对于其他 type，以及 Catalog 未涵盖的 type，使用
```
sf org list metadata
```
列出名称并逐一检查。
按名称匹配会遗漏标签不同的 Metadata。搜索“status”不会找到标签为 Loyalty Tier 的 field。应说“未找到名称匹配项”，绝不要说“不存在”。

此 skill 的其他所有规则仍然适用。

Reuse Before You Create

创建前先检查复用情况

Before you create an object, field, picklist, permission set, page, app, or flow:

Search by business meaning for existing metadata that stores the same data or does the same job. For a field, first search
```
SObject
```
for the exact object API name, then pass that result's returned
```
identifier
```
as
```
parentIdentifier
```
to the
```
SObjectField
```
search. Never pass the raw object API name as
```
parentIdentifier
```
. A proposed API name or label is only an exact collision check and does not prove that equivalent metadata is absent. Similar words alone are not enough to declare a match.
If you find matches: show up to 3, best first, with API name, label, description, and type. Do not accept or reject an ambiguous match from its name alone. Offer to reuse, extend, or create new in one consolidated reuse checkpoint covering every type you plan to create, then wait. Do not combine this checkpoint with values or other generation-specific questions.
After the user decides: preserve the decision for the request and do not ask again unless the scope changes or new conflicting evidence appears. For reuse, stop creation and inspect configuration only if needed. For extension, inspect the existing component before asking for changes. For new metadata, collect the required configuration and continue with the generation guidance.
If nothing matches: say so in one line and continue.
If the user gave an exact API name: check it with scoped SOQL and say if it already exists.
If the user asked for new metadata or said not to reuse: mention close matches in one line at most and continue.

Treat namespaced items, such as

force__

permission sets or managed package components, as references, not things to edit. Say so when a match is managed.

在创建 object、field、picklist、permission set、page、app 或 flow 前：

按业务含义搜索用于存储相同数据或完成相同工作的现有 Metadata。对于 field，先搜索
```
SObject
```
以获取确切的 object API name，然后将该结果返回的
```
identifier
```
作为
```
parentIdentifier
```
传给
```
SObjectField
```
搜索。绝不要把原始 object API name 作为
```
parentIdentifier
```
传入。拟定的 API name 或 label 只能用于精确冲突检查，不能证明不存在功能等价的 Metadata。仅凭相似词语不足以判定匹配。
**如果找到匹配项：**最多展示 3 个，优先展示最佳匹配，并包含 API name、label、description 和 type。不要仅凭名称接受或拒绝存在歧义的匹配项。在一个统一的复用检查点中，针对计划创建的所有 type 提供复用、扩展或新建选项，然后等待。不要将此检查点与 picklist 值或其他生成阶段的特定问题合并。
**用户决定后：**在本次请求中保留该决定，除非范围发生变化或出现新的冲突证据，否则不要再次询问。对于复用，停止创建，仅在必要时检查配置。对于扩展，先检查现有组件，再询问要进行的更改。对于新 Metadata，收集所需配置，然后继续执行生成指南。
**如果没有匹配项：**用一行说明，然后继续。
**如果用户提供了确切 API name：**使用 Scoped SOQL 检查，并说明它是否已经存在。
**如果用户要求创建新 Metadata 或明确表示不复用：**最多用一行提及近似匹配项，然后继续。

将带命名空间的项，例如

force__

permission set 或 managed package 组件，视为引用项，而不是可编辑项。如果匹配项属于 managed，请明确说明。

Ground Code in Real Org Names

让代码基于真实的 Org 名称

Before you write Apex, LWC, SOQL, or Flow logic, confirm every object, field, and picklist value it references.

Skip references already in the local project, already confirmed in this conversation, or standard fields every org has (such as
```
Account.Name
```
or
```
Contact.Email
```
).
Always look up picklist values, including on standard fields. Never invent values.
Values shown only as examples in a skill, tool description, or prior assistant response are not user-approved values. If the user has not explicitly supplied or approved the values or an existing value set, ask once and wait before creating the picklist.
If the request depends on an order or meaning the values do not state ("the top tier"), list the values and ask.
Look up all references for a request together.

在编写 Apex、LWC、SOQL 或 Flow 逻辑前，确认其中引用的每个 object、field 和 picklist 值。

跳过已存在于本地项目中、已在本对话中确认，或每个 org 都有的 standard field 引用，例如
```
Account.Name
```
或
```
Contact.Email
```
。
始终查询 picklist 值，包括 standard field 上的值。绝不要虚构值。
仅作为示例出现在 skill、tool description 或之前 assistant response 中的值，不属于用户已批准的值。如果用户未明确提供或批准这些值及现有值集，请在创建 picklist 前询问一次并等待。
如果请求取决于值的顺序，或未说明值的含义（“最高层级”），请列出这些值并询问。
对一个请求中的所有引用一起进行查询。

Existing Automation

现有 Automation

To find automation by what it does, search
```
Flow
```
or
```
ApexClass
```
by meaning. A grounding query on a flow shows its trigger object, trigger type, and active status.

To list everything that runs on an object before adding automation:

text

sf data query --json --query "SELECT Name, Status FROM ApexTrigger WHERE TableEnumOrId = 'Contact'"
sf data query --json --query "SELECT ApiName, Label, TriggerType, IsActive FROM FlowDefinitionView WHERE TriggerObjectOrEventId = 'Contact'"

To understand what a flow or trigger does, retrieve its source and read it.

**要按功能查找 automation，**请按含义搜索
```
Flow
```
或
```
ApexClass
```
。对 flow 的 grounding query 会显示其 trigger object、trigger type 和 active status。

要在添加 automation 前列出在某个 object 上运行的所有内容：

text

sf data query --json --query "SELECT Name, Status FROM ApexTrigger WHERE TableEnumOrId = 'Contact'"
sf data query --json --query "SELECT ApiName, Label, TriggerType, IsActive FROM FlowDefinitionView WHERE TriggerObjectOrEventId = 'Contact'"

**要了解某个 flow 或 trigger 的作用，**请 retrieve 其 source 并阅读。

What You Can Explain

可以说明的内容

Question	Answer with
What exists that does X	Grounding search
How a field, object, or validation rule is configured	Grounding query, or `EntityParticle` and Tooling `ValidationRule`
Who can read or edit a field or object	Grounding on `FieldPermissions` , or SOQL on `FieldPermissions` and `ObjectPermissions` for a complete list. These records prove configured access, not actual use; a permission container's name does not prove an integration or dependency is active.
Sharing rules, roles, groups, and which package a component came from	Grounding
What a flow is	Grounding gives the header only (type, trigger, active). For its steps, retrieve the source.
What an Apex class does	Grounding gives signatures only. Retrieve the source.
Why a save failed	A partial answer. Check validation rules on the object, then retrieve the automation that runs on it.
Page layouts, reports, custom metadata types, custom settings	Not in the catalog. Use `sf org list metadata` and retrieve.
Where something is used, what depends on it, what breaks if it changes, or whether it is safe to delete	Comprehensive analysis is not available yet. Say so before any checks. You may offer narrow checks, but label each one as partial and never present their union as complete or conclude that the change is safe.

问题	使用以下方式回答
哪些内容能够完成 X	Grounding search
field、object 或 validation rule 如何配置	Grounding query，或 `EntityParticle` 和 Tooling `ValidationRule`
谁可以读取或编辑某个 field 或 object	对 `FieldPermissions` 使用 Grounding，或对 `FieldPermissions` 和 `ObjectPermissions` 执行 SOQL，以获取完整列表。这些记录只能证明已配置的访问权限，不能证明实际使用情况；permission container 的名称不能证明某个 integration 或 dependency 处于活动状态。
Sharing rules、roles、groups，以及某个组件来自哪个 package	Grounding
flow 是什么	Grounding 仅提供 header（type、trigger、active）。要查看步骤，请 retrieve source。
Apex class 的作用	Grounding 仅提供 signature。请 retrieve source。
为什么 save 失败	只能给出部分答案。检查 object 上的 validation rules，然后 retrieve 在其上运行的 automation。
Page layouts、reports、custom metadata types、custom settings	不在 Catalog 中。使用 `sf org list metadata` 并 retrieve。
某项内容在哪里使用、依赖什么、更改后会影响什么，或者是否可以安全删除	尚无法进行 comprehensive analysis。执行任何检查前先说明这一点。可以提供范围有限的检查，但必须将每项检查标记为部分检查，绝不能将它们的并集视为完整结果，也不能据此得出该内容可以安全更改或删除的结论。

Working With Skills

与 Skill 配合使用

This skill decides what already exists. Build skills decide how to create it. Run discovery before any skill writes files.
If a loaded skill has its own equivalent semantic reuse check, use it instead of the matching step here. Do not run both. An exact-name or exact-label collision check is not equivalent and does not replace semantic reuse discovery.
Two exceptions, even when a skill says otherwise: always look up picklist values, and check names, types, or picklist values you know with scoped SOQL instead of a full object describe.
If a skill's discovery step fails or its tool is not available, use the routes in this skill and tell the user once.

此 skill 负责判断哪些内容已经存在；Build skill 负责决定如何创建。任何 skill 写入文件之前都要运行 discovery。

如果已加载的 skill 有等效的 semantic reuse check，则使用它代替此处的匹配步骤。不要同时运行两者。exact-name 或 exact-label collision check 并不等价，也不能替代 semantic reuse discovery。
即使 skill 另有说明，仍有两个例外：始终查询 picklist 值；使用 Scoped SOQL 检查已知的名称、类型或 picklist 值，而不是执行完整的 object describe。
如果 skill 的 discovery 步骤失败或其工具不可用，请使用此 skill 中的路径，并告知用户一次。

Freshness and Local Files

时效性与本地文件

Reuse discovery results for the rest of the conversation unless that item has changed.
The catalog can take several minutes to reflect deploys and other org changes. For anything changed in this session, trust the local source and deploy results, and confirm with SOQL, which is real time. If the user reports a change SOQL does not show, ask them to confirm the name and org before you write code that uses it.
When the metadata you need is not in the local project, retrieve it before editing, and tell the user you did.
If you learn the org version differs from local in ways you did not make, for example from a retrieve or a deploy conflict, show the difference and ask before you overwrite either one.
When scanning local source for references, read the package directories from
```
sfdx-project.json
```
and search those directories. Exclude response exports, logs, generated output, caches, and agent configuration unless the user explicitly asks to inspect them.
Searching local files finds exact text only. Do not use it to find org metadata by meaning.

在后续对话中复用 discovery 结果，除非该项已经发生变化。
Catalog 可能需要几分钟才能反映 deploy 和其他 org 更改。对于本会话中已更改的任何内容，信任本地 source 和 deploy 结果，并使用实时的 SOQL 确认。如果用户报告了某项更改，但 SOQL 未显示，请在编写使用它的代码前，请用户确认名称和 org。
当所需 Metadata 不在本地项目中时，请在编辑前 retrieve，并告知用户已执行此操作。
如果发现 org version 与本地 version 存在并非由你造成的差异，例如 retrieve 或 deploy conflict，请显示差异，并在覆盖任一方之前询问。
扫描本地 source 查找引用时，从
```
sfdx-project.json
```
读取 package directories，并搜索这些目录。除非用户明确要求检查，否则排除 response exports、logs、generated output、caches 和 agent configuration。
搜索本地文件只能找到精确文本。不要使用本地文件搜索按含义查找 org Metadata。

Never

绝不

Write or deploy files built from grounding query output. It returns properties, not source.
Treat grounding results as a complete list. They are ranked and capped.
Say metadata does not exist because a search or a name match found nothing.
Combine results from two different orgs.
Present partial dependency or reference checks as a complete impact analysis, or conclude from them that metadata is safe to change or delete.
Treat illustrative values from examples, skills, or tool descriptions as user-approved metadata.

不要根据 grounding query 输出编写或部署文件。它返回的是属性，而不是 source。
不要将 grounding 结果视为完整列表。结果经过排序且数量有限。
不要因为搜索或名称匹配未找到结果，就断言 Metadata 不存在。
不要合并来自两个不同 org 的结果。
不要将部分的 dependency 或 reference 检查视为完整的 impact analysis，也不要根据这些检查得出 Metadata 可以安全修改或删除的结论。
不要把示例、skill 或 tool description 中仅作为说明性内容展示的值视为用户已批准的 Metadata。