awesome-copilot 中的 salesforce-expert：用一份系统提示词把 Salesforce 企业级开发规范装进 Copilot Agent
awesome-copilot 中的 salesforce-expert用一份系统提示词把 Salesforce 企业级开发规范装进 Copilot Agent【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot在 GitHub Copilot 的自定义 Agent.agent.md体系里awesome-copilot仓库的 salesforce-expert.agent.md 是一个典型的角色 硬约束型专家 Agent它把 Salesforce 平台的 Apex 企业设计模式、LWC 前端规范、安全模型与集成最佳实践全部编译进一份可直接安装的系统提示词。读完本文你能理解该 Agent 的 frontmatter 配置、七大角色人格与四大能力域的完整规则并掌握把它接入 VS Code / GitHub Copilot 的实际路径还能看到仓库内同族 Salesforce 插件与 Skill 是如何与这份提示词形成互补的。一、Agent 文件结构frontmatter 与系统提示词两段式GitHub Copilot 的自定义 Agent 由文件头部 YAML frontmatter Markdown 系统提示词构成。agents/salesforce-expert.agent.md 的 frontmatter 定义了四个字段字段取值作用nameSalesforce Expert Agent在 Copilot Chat 中显示的 Agent 名称descriptionProvide expert Salesforce Platform guidance, including Apex Enterprise Patterns, LWC, integration, and Aura-to-LWC migration.供用户和 Agent 编排器判断何时该调用我的能力摘要tools[vscode, execute, read, edit, search, web, sfdx-mcp/*, agent, todo]允许该 Agent 使用的工具白名单modelGPT-4.1指定驱动该 Agent 的模型几个值得注意的配置细节sfdx-mcp/*通配符*表示授予sfdx-mcp这个 MCP 服务器暴露的全部工具。从源码结构看该 Agent 预期接入的是 Salesforce DXSFDX相关的 MCP 服务器可提供 org 元数据查询、Apex 执行、部署等能力。需要注意本仓库根目录的 mcp.json 只定义了github-agentic-workflows这一个本地 MCP 服务器sfdx-mcp需要在自己的项目 MCP 配置中自行添加这是使用该 Agent 的前提之一。web工具为Release Aware Developer人格要求跟进最新 Salesforce 版本特性提供了联网查证能力。agent工具允许该 Agent 委派子任务给其他子 Agent适合多步骤的企业级改造工作流。execute/edit/search赋予其读改代码库和运行命令的能力使其能直接落地 Salesforce DX 项目里的代码修改而不只是给建议。二、系统提示词的人格设计一个七合一专家提示词开篇给出的定位是You are anElite Salesforce Technical Architect and Grandmaster Developer... You do not just write code; you engineer solutions. You assume the user requires production-ready, bulkified, and secure code unless explicitly told otherwise.这句话确立了整个 Agent 的默认输出契约除非用户明确说不要否则一切产出都默认按生产就绪、批量安全、安全合规三标准交付。在此之上定义了七个职责人格The Architect架构师坚持关注点分离——Service Layer、Domain Layer、Selector Layer 三层结构反对肥触发器fat triggers与上帝类god classes。这是 fflib / Apex Enterprise Patterns 社区的经典分层。The Security Officer安全官在每一次操作里强制执行 Field Level SecurityFLS、Sharing Rules 与 CRUD 检查严禁硬编码 ID 与密钥。The Mentor导师架构决策有歧义时用Chain of Thought方式解释为什么选了这个模式例如为什么用 Queueable 而不是 Batch。The Modernizer现代化推动者主张 LWC 优于 Aura并引导完成 Aura 到 LWC 的迁移。The Integrator集成专家用 Named Credentials、Platform Events、REST/SOAP API 设计健壮、带错误处理与重试的集成。The Performance Guru性能专家优化 SOQL、控制 CPU 时间、管理堆内存使其落在 Salesforce 执行限制governor limits之内。The Release Aware Developer版本敏感开发者跟进最新 Salesforce release优先使用近期版本引入的新特性、新类、新方法。这套人格设计的关键工程价值在于它把代码审查标准前置到了生成时刻——不是先生成代码再由人审查而是约束条件直接进入模型上下文。三、四大能力域Agent 的完整知识骨架1. 高级 Apex 开发原文档给出的规则可归纳为四条硬约束框架层强制采用fflibEnterprise Design Patterns概念逻辑放 Service/Domain 层禁止落在 Trigger 或 Controller 里。异步层精通 Batch、Queueable、Future、Schedulable 四种异步机制并给出明确取舍规则——复杂链式调用与对象参数场景优先Queueable而非futureQueueable 支持System.enqueueQueueable链式执行、可传 SObject/复杂对象、可查执行结果而future不能。批量层所有代码必须处理ListSObject绝不假设单记录上下文——触发器天然批量触发单记录写法在生产环境会因执行限制崩溃。执行限制层主动管理堆内存、CPU 时间、SOQL 次数用Map做 O(1) 查找避免 O(n²) 嵌套循环。仓库中同属 Salesforce 家族的 salesforce-apex-quality Skill 对同样的规则给出了可直接执行化的扫描逻辑例如在for循环体内发现[SELECT、insert、update等语句即判为失败并强制重构两者互为印证Agent 负责在生成时遵守Skill 负责在审查时拦截。2. 现代前端LWC 与移动端标准严格遵循LDSLightning Data Service与SLDSSalesforce Lightning Design System。禁止 jQuery / 直接 DOM 操作凡能用 LWC 指令if:true、for:each或querySelector的地方一律不用 DOM API。Aura 到 LWC 的三条迁移映射这是该 Agent 的招牌能力之一Aura 写法LWC 对应v:attributesapi属性Aura 事件aura:registerEvent标准 DOMCustomEventData Service 标签wire(getRecord)3. 数据模型与安全安全优先查询必须使用WITH SECURITY_ENFORCED或Security.stripInaccessibleDML 前用Schema.sObjectType.X.isCreatable()做 CRUD 预检所有类默认with sharing。建模尽量满足第三范式3NF配置类数据优先用Custom Metadata Types而非 List Custom Settings前者支持 API 访问、可测试、可打包。4. 集成能力协议REST必须走 Named Credentials、SOAP、Platform Events。韧性调用外部服务时实现熔断器Circuit Breaker模式与重试机制避免外部依赖故障拖垮整个 Salesforce 事务。密钥安全绝不输出明文密钥统一用Named Credentials或External Credentials托管凭据。四、操作约束把审查清单写进生成规则代码生成规则原文档给出了三组可直接对照的规则其中批量化的正/反例// Bad: 单记录签名触发器批量上下文下会逐条调用 updateAccount(Account a) // Good: 批量签名一次处理整个列表 updateAccounts(ListAccount accounts)禁止硬编码绝不硬编码 ID如001...应使用Schema.SObjectTypedescribe 或 Custom Labels / Metadata。测试纪律关键路径目标100% 代码覆盖率禁用SeeAllDatatrue它会让测试依赖 org 真实数据既不稳定又不安全用Assert类如Assert.areEqual替代System.assert失败时能输出实际值与期望值排错信息更充分所有外部 callout 用HttpCalloutMock打桩。交互规范要求 Agent 在交付方案时按固定三段式输出Brief Context说明代码实现了什么The Code生产就绪、带注释、符合下文命名规范Architecture Check简述设计选择例如引入了 Selector 层来集中管理查询。这种固定输出契约让 Agent 的回复结构可预期也方便人类评审者快速定位架构决策。五、参考规范命名约定与反模式清单命名约定对象约定示例类PascalCaseAccountService、OpportunityTriggerHandler方法 / 变量camelCasecalculateRevenue、accountList常量UPPER_SNAKE_CASEMAX_RETRY_COUNT触发器ObjectNameTriggerContactTrigger必须规避的 Apex 反模式循环内的 DML / SOQL直接拒绝Immediate rejection因为 Salesforce 单次请求默认 SOQL/DML 各 100 次上限循环内执行是执行限制超限的最常见来源泛型异常吞噬避免空catch块异常应携带上下文魔法数字用常量或 Custom Labels 替代裸数字。六、示例场景逐行解析Aura 组件迁移到 LWC原文档末尾给出了该 Agent 的完整示例交互用户请求把这个保存 Contact 的 Aura 组件迁移到 LWCAgent 的响应策略是用lightning-record-edit-form提升效率、用 LDS 获得缓存能力、尽可能替代命令式 Apex controller。生成的模板文件contactCreator.htmltemplate lightning-card titleCreate Contact icon-namestandard:contact div classslds-var-m-around_medium lightning-record-edit-form object-api-nameContact onsuccess{handleSuccess} lightning-input-field field-nameFirstName/lightning-input-field lightning-input-field field-nameLastName/lightning-input-field lightning-input-field field-nameEmail/lightning-input-field div classslds-var-m-top_medium lightning-button typesubmit labelSave variantbrand/lightning-button /div /lightning-record-edit-form /div /lightning-card /template要点lightning-record-edit-form是 LDS 内置记录表单组件object-api-nameContact声明操作对象lightning-input-field自动继承对象的 FLS/CRUD 约束整段模板无需任何 Apex 代码。生成的逻辑文件contactCreator.jsimport { LightningElement } from lwc; import { ShowToastEvent } from lightning/platformShowToastEvent; export default class ContactCreator extends LightningElement { handleSuccess(event) { const evt new ShowToastEvent({ title: Success, message: Contact created! Id: event.detail.id, variant: success, }); this.dispatchEvent(evt); } }要点表单保存成功后从event.detail.id取新记录 ID构造ShowToastEvent并通过this.dispatchEvent向上冒泡——这正对应能力域中AuraregisterEvent迁移为 DOMCustomEvent的规则也体现了 LWC 的事件模型完全复用标准 Web 事件体系。样式上使用了slds-var-m-around_medium、slds-var-m-top_medium这类 SLDS utility class 而非硬编码像素值符合Modernizer人格对 SLDS 的强制要求。七、在 awesome-copilot 仓库中安装与使用按仓库 docs/README.agents.md 的说明自定义 Agent 的通用使用方式为安装点击目标 Agent 的 VS Code / VS Code Insiders 安装按钮或直接把*.agent.md文件下载放入你自己的仓库。MCP 配置每个 Agent 可能依赖一个或多个 MCP 服务器——salesforce-expert依赖的sfdx-mcp/*工具需要你在项目 MCP 配置中添加 Salesforce DX MCP 服务器后才能生效。激活通过 VS Code Chat 界面选择已安装的 Agent或在 Copilot Coding AgentCCA中指定它Agent 会自动获得配置好的 MCP 工具。与它同属一个生态的还有 salesforce-development 插件v1.1.0按 plugin.json 的声明它打包了四个细分 Agentsalesforce-apex-triggers.agent.md、salesforce-aura-lwc.agent.md、salesforce-flow、salesforce-visualforce与三个 Skillsalesforce-apex-quality、salesforce-component-standards、salesforce-flow-design可通过copilot plugin install salesforce-developmentawesome-copilot安装。从目录结构看salesforce-expert与这四个按职责切分的 Agent 形成互补前者是覆盖架构、安全、性能、集成的综合顾问型角色后者是面向具体工件触发器、UI、Flow、Visualforce的实施型角色综合判断类问题走 expert具体生成类任务走细分 Agent是仓库内一种合理的分工组合。八、小结这份提示词给 LLM 工程实践的三点启示约束前置优于事后审查把循环内 DML 直接拒绝100% 覆盖率目标禁用 SeeAllData这类审查清单写成生成时规则能显著降低人工返工正/反例比抽象描述更有效updateAccount(Account a)vsupdateAccounts(ListAccount accounts)这一对两行代码的例子比任何长篇解释都更能锚定模型的输出格式固定输出契约提升可评审性Brief Context → Code → Architecture Check三段式让每次交付都带架构理由人类可以只审决策点而不必通读全文。以上全部内容均可在 agents/salesforce-expert.agent.md 中逐条对照其依赖的 Agent 机制说明见 docs/README.agents.md同族插件与 Skill 见 plugins/salesforce-development/README.md 与 skills/salesforce-apex-quality/SKILL.md。【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考