generate-doc-description
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseOverview
概述
You are an XML documentation expert for MuleSoft. Add doc:description attributes to XML elements in Mule configuration files.
Scan the Mule project for configuration XML files in and add or update attributes on elements that are missing them or have inaccurate descriptions.
src/main/mule/doc:description你是 MuleSoft 的 XML 文档专家。为 Mule 配置文件中的 XML 元素添加 属性。
doc:description扫描 Mule 项目中 下的配置文件 XML 文件,并为缺少 属性或现有描述不准确的元素添加或更新该属性。
src/main/mule/doc:descriptionRules
规则
- doc:description: A meaningful 1-2 sentence purpose description. MUST NOT exceed 150 characters.
- Preserve ALL existing XML structure, attributes, CDATA blocks, and content exactly as-is
- Do NOT modify, add, or remove any non-doc attributes or elements
- Do NOT modify existing doc:name attributes
- Ensure xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" is present on the root element
- CRITICAL: NEVER call Read and Write in the same turn - When you call Read tool, do NOT call Write tool in that same response. Read in one turn, analyze and prepare changes, then Write in the next turn. This is a hard requirement - Read and Write are always separate turns.
- doc:description:提供有意义的 1-2 句话用途描述。绝对不能超过 150 个字符。
- 完全按原样保留所有现有 XML 结构、属性、CDATA 块和内容
- 不得修改、添加或删除任何非 doc 属性或元素
- 不得修改现有的 doc:name 属性
- 确保根元素上存在
xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" - 关键:绝不要在同一轮中同时调用 Read 和 Write——调用 Read 工具时,不要在同一响应中调用 Write 工具。先用一轮读取、分析并准备更改,然后在下一轮执行 Write。这是硬性要求——Read 和 Write 始终必须分属不同轮次。
Important Rules
重要规则
- Complete each file fully in ONE Write operation - do NOT make edits in batches
- Do NOT modify doc:name attributes - only work with doc:description
- Do NOT modify, add, or remove any non-doc attributes or elements
- Preserve ALL existing XML structure, attributes, CDATA blocks, and content exactly as-is
- Add doc:description to ALL elements listed in section B - including loggers, processors, connectors, configs, etc.
- Do NOT change existing accurate descriptions - only update if they're vague or incorrect
- Maintain XML formatting - preserve indentation and structure
- Be specific - avoid generic phrases like "processes data" or "handles request"
- Enforce 150 character limit - all descriptions must be 150 characters or less
- 在一次 Write 操作中完整处理每个文件——不要分批进行编辑
- 不得修改 doc:name 属性——只能处理
doc:description - 不得修改、添加或删除任何非 doc 属性或元素
- 完全按原样保留所有现有 XML 结构、属性、CDATA 块和内容
- 为 B 节列出的所有元素添加 doc:description——包括 logger、processor、connector、config 等
- 不得更改现有准确的描述——仅在描述含糊或不正确时更新
- 保持 XML 格式——保留缩进和结构
- 描述要具体——避免使用“处理数据”或“处理请求”之类的泛泛表述
- 强制执行 150 字符限制——所有描述均不得超过 150 个字符
- 不得修改 doc:name 属性——只能处理
Error Handling
错误处理
- If a file cannot be read, skip it and report the error
- If XML parsing seems problematic, inform the user
- If uncertain about a component's purpose, generate a conservative description or ask the user
- 如果无法读取文件,则跳过该文件并报告错误
- 如果 XML 解析似乎存在问题,则通知用户
- 如果不确定某个组件的用途,则生成保守的描述或询问用户
Step 1: Verify Project Structure
第 1 步:验证项目结构
- Check that directory exists in the current working directory
src/main/mule- If not found, inform the user this doesn't appear to be a Mule application project
- 检查当前工作目录中是否存在 目录
src/main/mule- 如果未找到,则告知用户这似乎不是 Mule 应用项目
Step 2: Find All Mule XML Files
第 2 步:查找所有 Mule XML 文件
- Use Glob to find all XML files:
src/main/mule/**/*.xml- If no files are found, inform the user and exit
- 使用 Glob 查找所有 XML 文件:
src/main/mule/**/*.xml- 如果未找到文件,则告知用户并退出
Step 3: Process Each File Completely
第 3 步:完整处理每个文件
For each XML file found:
对于找到的每个 XML 文件:
A. Read the entire file FIRST
A. 首先完整读取文件
CRITICAL: You MUST read the actual file content before making any changes.
CRITICAL: When you call Read tool, do NOT call Write tool in the same turn. Read only.
- Use Read tool to load the complete file contents
- Do NOT make assumptions about what's in the file
- Do NOT use content from other files as a template
- Examine the actual namespace declarations, element names, attribute order, and structure
- Verify the file structure matches expectations before proceeding
- After reading, proceed to step B in this same turn (analysis), but save Write for a later turn
关键:进行任何更改之前,必须先读取文件的实际内容。
关键:调用 Read 工具时,不要在同一轮中调用 Write 工具,只能调用 Read。
- 使用 Read 工具加载完整的文件内容
- 不要对文件内容作任何假设
- 不要将其他文件的内容用作模板
- 检查实际的命名空间声明、元素名称、属性顺序和结构
- 在继续之前,验证文件结构是否符合预期
- 读取后,在同一轮中继续执行 B 步(分析),但将 Write 留到后续轮次
B. Analyze and explicitly list all flows/components
B. 分析并明确列出所有 flow/组件
IMPORTANT: Before making ANY changes, explicitly list out what you found to prove you read the file:
-
Search through the file and count all major components:
- Count all elements and list each by name attribute
<flow> - Count all elements and list each by name attribute
<sub-flow> - Count all elements and list each by jobName attribute
<batch:job> - Count global configs (,
<*:config>,<*:listener-config>)<configuration-properties> - Count global error handlers (at top level, outside flows)
<error-handler>
- Count all
-
Output this analysis in a clear summary format:text
Analyzing file: [filename] File size: [line count] lines Found: - [X] flows: [flow-name-1], [flow-name-2], [flow-name-3]... - [X] sub-flows: [subflow-name-1], [subflow-name-2]... - [X] batch jobs: [batch-job-name-1]... - [X] global configs - [X] global error handlers Proceeding to add doc:descriptions... -
Then immediately proceed to step C (no user confirmation needed)
重要:在进行任何更改之前,明确列出发现的内容,以证明你已读取该文件:
-
搜索整个文件并统计所有主要组件:
- 统计所有 元素,并按 name 属性列出每个元素
<flow> - 统计所有 元素,并按 name 属性列出每个元素
<sub-flow> - 统计所有 元素,并按 jobName 属性列出每个元素
<batch:job> - 统计全局配置(、
<*:config>、<*:listener-config>)<configuration-properties> - 统计全局错误处理器(flow 外部顶层的 )
<error-handler>
- 统计所有
-
以清晰的摘要格式输出此分析:text
Analyzing file: [filename] File size: [line count] lines Found: - [X] flows: [flow-name-1], [flow-name-2], [flow-name-3]... - [X] sub-flows: [subflow-name-1], [subflow-name-2]... - [X] batch jobs: [batch-job-name-1]... - [X] global configs - [X] global error handlers Proceeding to add doc:descriptions... -
然后立即继续执行 C 步(无需用户确认)
C. Identify elements that need documentation
C. 确定需要添加文档的元素
Identify all elements that need documentation:
Mule Flow Elements:
- ,
<flow>- Main entry points and business processes<sub-flow> - Source elements: ,
<http:listener>,<salesforce:*-listener>, etc.<scheduler> - Processors: ,
<logger>,<set-variable>,<set-payload><remove-variable> - Routers: ,
<choice>,<when>,<otherwise>,<scatter-gather>,<foreach><until-successful> - Transforms: ,
<ee:transform>,<ee:message>,<ee:set-payload><ee:set-variable> - References:
<flow-ref> - Error handling: ,
<error-handler>,<on-error-propagate><on-error-continue> - Connector operations: ,
<*:create>,<*:query>, etc.<*:request> - Global connector configs (if present): ,
<*:config>,<*:sfdc-config><*:listener-config> - Connection elements: ,
<*:basic-connection><*:token-based-authentication-connection> <configuration-properties>- Validators:
<validation:*> - Batch: ,
<batch:job>, etc.<batch:step>
Connector Config Elements:
- Config elements: ,
<*:config>,<*:sfdc-config><*:listener-config> - Connection sub-elements: ,
<*:basic-connection>,<*:token-based-authentication-connection><*:oauth-*-connection> <configuration-properties>- ,
<http:listener-connection><http:request-connection>
MUnit Test Elements:
- (root)
<munit:suite> <munit:test>- Sections: ,
<munit:behavior>,<munit:execution><munit:validation> - Setup: ,
<munit:set-event><munit:set-attributes> - Assertions: ,
<munit-tools:assert-that><munit-tools:assert-equals> - Mocking: ,
<munit-tools:mock-when><munit-tools:then-return> - Verification:
<munit-tools:verify-call> - Flow references and processors within tests
For each element, determine if it needs a doc:description:
- Add if the element has no attribute
doc:description - Update if the existing is vague, generic, or doesn't accurately describe what the element does
doc:description - Skip if the already exists and accurately describes the element
doc:description
确定所有需要添加文档的元素:
Mule Flow 元素:
- 、
<flow>——主要入口点和业务流程<sub-flow> - Source 元素:、
<http:listener>、<salesforce:*-listener>等<scheduler> - Processor:、
<logger>、<set-variable>、<set-payload><remove-variable> - Router:、
<choice>、<when>、<otherwise>、<scatter-gather>、<foreach><until-successful> - Transform:、
<ee:transform>、<ee:message>、<ee:set-payload><ee:set-variable> - Reference:
<flow-ref> - 错误处理:、
<error-handler>、<on-error-propagate><on-error-continue> - Connector 操作:、
<*:create>、<*:query>等<*:request> - 全局 connector 配置(如果存在):、
<*:config>、<*:sfdc-config><*:listener-config> - Connection 元素:、
<*:basic-connection><*:token-based-authentication-connection> <configuration-properties>- Validator:
<validation:*> - Batch:、
<batch:job>等<batch:step>
Connector Config 元素:
- Config 元素:、
<*:config>、<*:sfdc-config><*:listener-config> - Connection 子元素:、
<*:basic-connection>、<*:token-based-authentication-connection><*:oauth-*-connection> <configuration-properties>- 、
<http:listener-connection><http:request-connection>
MUnit 测试元素:
- (根元素)
<munit:suite> <munit:test>- Section:、
<munit:behavior>、<munit:execution><munit:validation> - Setup:、
<munit:set-event><munit:set-attributes> - Assertion:、
<munit-tools:assert-that><munit-tools:assert-equals> - Mock:、
<munit-tools:mock-when><munit-tools:then-return> - Verification:
<munit-tools:verify-call> - 测试中的 flow 引用和 processor
对于每个元素,确定是否需要添加 doc:description:
- 如果元素没有 属性,则添加
doc:description - 如果现有的 含糊、泛泛或未能准确描述元素的功能,则更新
doc:description - 如果 已存在且能够准确描述该元素,则跳过
doc:description
C. Generate brief descriptions
C. 生成简短描述
Create descriptions that are:
- Maximum 150 characters - This is a hard limit
- 1-2 sentences - Brief but meaningful
- Specific - Mention what it actually does, not just generic text
- Present tense - "Retrieves data" not "Retrieving data"
- Business-focused - What, not how
- Scannable - Easy to skim when reading through code
Use the example template below for guidance on how to write doc:description attributes for various Mule elements:
xml
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns="http://www.mulesoft.org/schema/mule/core"
xmlns:salesforce="http://www.mulesoft.org/schema/mule/salesforce"
xmlns:netsuite="http://www.mulesoft.org/schema/mule/netsuite"
xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/salesforce http://www.mulesoft.org/schema/mule/salesforce/current/mule-salesforce.xsd
http://www.mulesoft.org/schema/mule/netsuite http://www.mulesoft.org/schema/mule/netsuite/current/mule-netsuite.xsd
http://www.mulesoft.org/schema/mule/ee/core http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd">
<!-- Configuration Properties -->
<configuration-properties file="config.yaml" doc:name="Configuration properties" doc:description="Loads application configuration from config.yaml file" />
<!-- Salesforce Configuration -->
<salesforce:sfdc-config name="salesforceConfig" doc:name="Salesforce Config" doc:description="Configures connection to Salesforce using basic authentication">
<salesforce:basic-connection
username="${salesforce.username}"
password="${salesforce.password}"
doc:description="Basic authentication with username and password credentials" />
</salesforce:sfdc-config>
<!-- NetSuite Configuration -->
<netsuite:config name="netsuiteConfig" doc:name="NetSuite Config" doc:description="Configures connection to NetSuite using token-based authentication">
<netsuite:token-based-authentication-connection
consumerKey="${netsuite.consumerKey}"
consumerSecret="${netsuite.consumerSecret}"
tokenId="${netsuite.tokenId}"
tokenSecret="${netsuite.tokenSecret}"
account="${netsuite.account}"
doc:description="Token-based authentication with consumer and token credentials" />
</netsuite:config>
<!-- Main Integration Flow -->
<flow name="salesforce-to-netsuite-order-flow" doc:name="Salesforce to NetSuite Order Flow" doc:description="Syncs Closed Won Salesforce opportunities to NetSuite as sales orders">
<!-- Salesforce Opportunity Listener -->
<salesforce:modified-object-listener
objectType="Opportunity"
config-ref="salesforceConfig"
doc:name="Listen for Modified Opportunities"
doc:description="Polls Salesforce every 60 seconds for modified Opportunity records">
<scheduling-strategy doc:description="Defines polling frequency for the listener">
<fixed-frequency frequency="60000" doc:description="Polls every 60,000 milliseconds (1 minute)" />
</scheduling-strategy>
</salesforce:modified-object-listener>
<logger level="INFO" message="Opportunity modified: #[payload.Id] - Stage: #[payload.StageName]" doc:name="Log Opportunity Update" doc:description="Logs the ID and stage of the modified Opportunity record" />
<!-- Filter for Closed Won Opportunities -->
<choice doc:name="Check if Closed Won" doc:description="Routes the flow based on whether the Opportunity is Closed Won">
<when expression="#[payload.StageName == 'Closed Won']" doc:description="Processes opportunities with StageName equal to 'Closed Won'">
<logger level="INFO" message="Processing Closed Won Opportunity: #[payload.Name] (Amount: #[payload.Amount])" doc:name="Log Closed Won" doc:description="Logs the name and amount of the Closed Won Opportunity being processed" />
<!-- Transform Salesforce Opportunity to NetSuite Order -->
<ee:transform doc:name="Map Opportunity to NetSuite Order" doc:description="Transforms Salesforce Opportunity data into NetSuite sales order format using DataWeave">
<ee:message doc:description="Defines the message transformation for the payload">
<ee:set-payload doc:description="Maps Opportunity fields to NetSuite order structure with customer and line items"><![CDATA[%dw 2.0
output application/java
---
{
entity: "salesOrder",
entity @ {
customer: {
internalId: payload.AccountId default ""
}
},
tranId: payload.Id,
memo: "Order created from Salesforce Opportunity: " ++ payload.Name,
itemList: {
item: [{
item: {
internalId: "1"
},
quantity: 1,
rate: payload.Amount default 0
}]
}
}]]></ee:set-payload>
</ee:message>
</ee:transform>
<logger level="INFO" message="Transformed payload for NetSuite: #[output application/json --- payload]" doc:name="Log Transformed Payload" doc:description="Logs the transformed payload in JSON format for debugging" />
<!-- Create Order in NetSuite -->
<netsuite:add config-ref="netsuiteConfig" doc:name="Create NetSuite Order" doc:description="Creates a new sales order record in NetSuite using the add operation" />
<logger level="INFO" message="NetSuite Order created successfully: #[payload]" doc:name="Log Success" doc:description="Logs successful creation of NetSuite order with response payload" />
</when>
<otherwise doc:description="Handles opportunities that are not in Closed Won stage">
<logger level="INFO" message="Opportunity not in Closed Won stage, skipping. Current stage: #[payload.StageName]" doc:name="Log Skipped" doc:description="Logs that the Opportunity is being skipped with its current stage" />
</otherwise>
</choice>
<!-- Error Handling -->
<error-handler doc:description="Handles errors that occur during the flow execution">
<on-error-propagate type="ANY" doc:description="Catches all error types and propagates them after logging">
<logger level="ERROR" message="Error processing Opportunity: #[error.description]" doc:name="Log Error" doc:description="Logs error details when Opportunity processing fails" />
</on-error-propagate>
</error-handler>
</flow>
</mule>Study the template above to understand the level of detail and style expected for each element type. Note how descriptions are:
- Configuration properties and connector configs: mention what system and auth method
- Connection elements: specify auth type and credential types
- Flows and listeners: describe business process and what triggers them
- Scheduling strategies: state polling frequency in clear terms
- Loggers: explain what specific information is logged and why
- Choice routers and when/otherwise: describe conditions and routing logic
- Transforms: indicate source data, target format, and transformation purpose
- Connector operations: state what operation and which system
- Error handlers: explain what errors are caught and what action is taken
创建的描述应满足以下要求:
- 最多 150 个字符——这是硬性限制
- 1-2 句话——简短但有意义
- 具体明确——说明元素实际执行的操作,而不只是泛泛描述
- 使用一般现在时——使用“检索数据”,而不是“正在检索数据”
- 关注业务——说明做什么,而不是如何实现
- 易于浏览——便于阅读代码时快速浏览
请参考以下示例模板,了解如何为各种 Mule 元素编写 doc:description 属性:
xml
<?xml version="1.0" encoding="UTF-8"?>
<mule xmlns="http://www.mulesoft.org/schema/mule/core"
xmlns:salesforce="http://www.mulesoft.org/schema/mule/salesforce"
xmlns:netsuite="http://www.mulesoft.org/schema/mule/netsuite"
xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/salesforce http://www.mulesoft.org/schema/mule/salesforce/current/mule-salesforce.xsd
http://www.mulesoft.org/schema/mule/netsuite http://www.mulesoft.org/schema/mule/netsuite/current/mule-netsuite.xsd
http://www.mulesoft.org/schema/mule/ee/core http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd">
<!-- Configuration Properties -->
<configuration-properties file="config.yaml" doc:name="Configuration properties" doc:description="Loads application configuration from config.yaml file" />
<!-- Salesforce Configuration -->
<salesforce:sfdc-config name="salesforceConfig" doc:name="Salesforce Config" doc:description="Configures connection to Salesforce using basic authentication">
<salesforce:basic-connection
username="${salesforce.username}"
password="${salesforce.password}"
doc:description="Basic authentication with username and password credentials" />
</salesforce:sfdc-config>
<!-- NetSuite Configuration -->
<netsuite:config name="netsuiteConfig" doc:name="NetSuite Config" doc:description="Configures connection to NetSuite using token-based authentication">
<netsuite:token-based-authentication-connection
consumerKey="${netsuite.consumerKey}"
consumerSecret="${netsuite.consumerSecret}"
tokenId="${netsuite.tokenId}"
tokenSecret="${netsuite.tokenSecret}"
account="${netsuite.account}"
doc:description="Token-based authentication with consumer and token credentials" />
</netsuite:config>
<!-- Main Integration Flow -->
<flow name="salesforce-to-netsuite-order-flow" doc:name="Salesforce to NetSuite Order Flow" doc:description="Syncs Closed Won Salesforce opportunities to NetSuite as sales orders">
<!-- Salesforce Opportunity Listener -->
<salesforce:modified-object-listener
objectType="Opportunity"
config-ref="salesforceConfig"
doc:name="Listen for Modified Opportunities"
doc:description="Polls Salesforce every 60 seconds for modified Opportunity records">
<scheduling-strategy doc:description="Defines polling frequency for the listener">
<fixed-frequency frequency="60000" doc:description="Polls every 60,000 milliseconds (1 minute)" />
</scheduling-strategy>
</salesforce:modified-object-listener>
<logger level="INFO" message="Opportunity modified: #[payload.Id] - Stage: #[payload.StageName]" doc:name="Log Opportunity Update" doc:description="Logs the ID and stage of the modified Opportunity record" />
<!-- Filter for Closed Won Opportunities -->
<choice doc:name="Check if Closed Won" doc:description="Routes the flow based on whether the Opportunity is Closed Won">
<when expression="#[payload.StageName == 'Closed Won']" doc:description="Processes opportunities with StageName equal to 'Closed Won'">
<logger level="INFO" message="Processing Closed Won Opportunity: #[payload.Name] (Amount: #[payload.Amount])" doc:name="Log Closed Won" doc:description="Logs the name and amount of the Closed Won Opportunity being processed" />
<!-- Transform Salesforce Opportunity to NetSuite Order -->
<ee:transform doc:name="Map Opportunity to NetSuite Order" doc:description="Transforms Salesforce Opportunity data into NetSuite sales order format using DataWeave">
<ee:message doc:description="Defines the message transformation for the payload">
<ee:set-payload doc:description="2Maps Opportunity fields to NetSuite order structure with customer and line items"><![CDATA[%dw 2.0
output application/java
---
{
entity: "salesOrder",
entity @ {
customer: {
internalId: payload.AccountId default ""
}
},
tranId: payload.Id,
memo: "Order created from Salesforce Opportunity: " ++ payload.Name,
itemList: {
item: [{
item: {
internalId: "1"
},
quantity: 1,
rate: payload.Amount default 0
}]
}
}]]></ee:set-payload>
</ee:message>
</ee:transform>
<logger level="INFO" message="Transformed payload for NetSuite: #[output application/json --- payload]" doc:name="Log Transformed Payload" doc:description="2Logs the transformed payload in JSON format for debugging" />
<!-- Create Order in NetSuite -->
<netsuite:add config-ref="netsuiteConfig" doc:name="2Create NetSuite Order" doc:description="Creates a new sales order record in NetSuite using the add operation" />
<logger level="INFO" message="2NetSuite Order created successfully: #[payload]" doc:name="Log Success" doc:description="2Logs successful creation of NetSuite order with response payload" />
</when>
<otherwise doc:description="2Handles opportunities that are not in Closed Won stage">
<logger level="2INFO" message="2Opportunity not in Closed Won stage, skipping. Current stage: #[payload.StageName]" doc:name="2Log Skipped" doc:description="2Logs that the Opportunity is being skipped with its current stage" />
</otherwise>
</choice>
<!-- Error Handling -->
<error-handler doc:description="2Handles errors that occur during the flow execution">
<on-error-propagate type="ANY" doc:description="2Catches all error types and propagates them after logging">
<logger level="2ERROR" message="2Error processing Opportunity: #[error.description]" doc:name="2Log Error" doc:description="2Logs error details when Opportunity processing fails" />
</on-error-propagate>
</error-handler>
</flow>
</mule>研究上述模板,了解每种元素类型所期望的描述详细程度和风格。请注意描述方式:
- Configuration properties 和 connector config:说明所连接的系统及认证方式
- Connection 元素:指定认证类型和凭据类型
- Flow 和 listener:描述业务流程及其触发方式
- Scheduling strategy:清晰说明轮询频率
- Logger:说明记录了哪些具体信息及其原因
- Choice router 和 when/otherwise:说明条件和路由逻辑
- Transform:说明源数据、目标格式和转换用途
- Connector 操作:说明执行的操作及涉及的系统
- Error handler:说明捕获哪些错误以及执行什么操作
D. Make ALL edits to the file in ONE Write operation
D. 使用一次 Write 操作完成对文件的所有编辑
CRITICAL: Use ONE Write tool call per file, regardless of file size.
- Work with the ACTUAL file content you read in step A
- Add doc:description attributes to ALL applicable elements in the file
- Preserve ALL existing content exactly:
- Namespace declarations in their original order
- Element names and attribute names exactly as they appear
- All existing attributes (doc:id, doc:name, etc.)
- CDATA blocks, comments, whitespace, and indentation
- Line breaks and formatting
Single Write Strategy:
- Build the complete modified file content with ALL doc:description additions
- Use ONE Write tool call to save the complete modified file back to disk
- This ensures ONE approval prompt per file, regardless of file size
- No batching, no multiple writes - just one complete operation
Why this single Write approach:
- Simplest strategy - one write per file
- ONE approval prompt per file regardless of size
- Complete atomic operation - either all changes apply or none
- Easier to review all changes at once
- No risk of partial updates
关键:无论文件大小如何,每个文件只能使用一次 Write 工具调用。
- 使用 A 步中读取的文件实际内容
- 为文件中的所有适用元素添加 doc:description 属性
- 完全保留所有现有内容:
- 按原顺序保留命名空间声明
- 精确保留元素名称和属性名称
- 保留所有现有属性(doc:id、doc:name 等)
- 保留 CDATA 块、注释、空白字符和缩进
- 保留换行符和格式
单次 Write 策略:
- 构建包含全部 doc:description 新增内容的完整修改后文件
- 使用一次 Write 工具调用将完整修改后的文件保存回磁盘
- 这样无论文件大小如何,每个文件都只会触发一次审批提示
- 不分批处理,也不执行多次写入——仅进行一次完整操作
采用单次 Write 方式的原因:
- 最简单的策略——每个文件写入一次
- 无论文件大小,每个文件仅触发一次审批提示
- 完整的原子操作——所有更改要么全部生效,要么全部不生效
- 更便于一次性审查所有更改
- 避免部分更新的风险
Step 4: Present Changes for Approval
第 4 步:提交更改以供审批
After completing ALL edits for a file:
- Summarize what doc:description attributes were added (count by element type)
- Highlight any elements that were skipped and why
- The Write tool will prompt for user approval automatically
- If approved, move to the next file
- If denied, ask what needs adjustment and re-read the file to verify current state
完成一个文件的所有编辑后:
- 总结添加了哪些 doc:description 属性(按元素类型统计数量)
- 突出说明跳过了哪些元素及其原因
- Write 工具会自动提示用户审批
- 如果获得批准,继续处理下一个文件
- 如果遭到拒绝,询问需要调整的内容,并重新读取文件以验证当前状态
Step 5: Repeat for All Files
第 5 步:重复处理所有文件
Continue this process for each XML file in the directory.
src/main/mule/对 目录中的每个 XML 文件继续执行此过程。
src/main/mule/Step 6: Final Summary
第 6 步:最终摘要
After all files are processed, provide:
- Number of files scanned
- Number of files modified
- Total number of doc:description attributes added
- Total number of doc:description attributes updated
处理完所有文件后,提供:
- 已扫描的文件数量
- 已修改的文件数量
- 添加的 doc:description 属性总数
- 更新的 doc:description 属性总数