pstack benny 自动化包详解基于 Slack 问题报告的自动分诊与复现修复双流水线【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/pluginsbenny 是 pstack 插件内附的一个「休眠式」Cursor 自动化包它为同一个 Slack 问题报告频道提供两条协同工作的自动化一条负责对每条新报告做分诊triage并只回一条带判定标记的线程回复另一条负责等待可信分诊标记后通过控制适配器在真实 UI 上复现确认的 bug并在满足严格门槛时提交一个有界bounded的草稿 Pull Request。读完本文你能完整理解 benny 的目录结构与文件职责、六步安装流程、两个自动化各自的运行规则与安全边界以及如何适配configuration.example.yaml、feature map、routing map 与 control adapter 契约这四项用户侧配置。1. benny 是什么两条协同的 Cursor Automation根据 READMEbenny 提供两个用于 Slack 问题报告的 Cursor 自动化Triage 自动化benny-triage对每条新报告做一次分诊产出唯一的线程内判定回复Reproduce fix 自动化benny-reproduce复现已确认的 bug并可能准备一个小型草稿修复。README 特别强调了一点该目录中的文件是「dormant setup and automation sources休眠的安装与自动化源文件」不会以 slash skill 的形式出现。也就是说benny 不是一个注册在 slash 命令列表里的插件技能集合而是一套被 Cursor Automation 在运行时直接按仓库相对路径读取的操作文件。这一点在 setup-benny/SKILL.md 中得到了源码级印证pstack 的插件 manifest 只暴露 pstack 正常的 skill 根目录benny 的三个SKILL.md文件setup、triage、reproduce全部带disable-model-invocation: true前置元数据禁止被模型自主调用——它们只能由对应的 Cursor Automation 提示词显式指示「读取并遵循」这个文件路径。两个自动化的完整意图触发器、行为、工具、边界在 FOR_AGENTS.md 中以「what i want to automate」的形式给出它是人类进入设置流程时让 Cursor 指向的入口文件。核心设计约束包括触发方式一致两条自动化都由源 Slack 频道中的「新顶级报告new top-level report」触发并保持原始线程坐标不变。标记契约marker contracttriage 用[benny:bug]、[benny:performance]、[benny:other]三种标记之一收尾reproduce 只接受「来自配置的分诊身份、且位于本源线程下」的标记只推进bug与performance。这个标记机制「替代了私有 bot 身份和自由文本判定匹配」reproduce SKILL 原文This marker replaces private bot identities and free-form verdict matching。硬边界两条自动化都永远不在源频道发 root 消息只允许在源线程内回复。Fail closed失败即停当频道坐标、tracker 访问、控制适配器或 feature map 缺失或不确定时两个自动化都必须 fail closed而不是继续执行并声称完成。2. 安装流程六步设置与合并规则README 的「set it up」章节给出了六步安装流程这里完整继承并结合 FOR_AGENTS.md 和 setup-benny/SKILL.md 的合并规则展开说明。2.1 六步安装概览让 Cursor 指向FOR_AGENTS.md并指定目标仓库让安装流程把整个目录合并到目标仓库的.cursor/automations/benny/且必须保留目标端独有文件、对冲突做审查合并而不是覆盖本地编辑让安装流程在目标仓库的.cursor/settings.json中启用 pstack作为共享依赖来源{ plugins: { pstack: { enabled: true } } }把用户自有的配置保留在复制包之外例如.cursor/benny/并适配configuration.example.yaml与feature-map.example.md在启用任何一条自动化之前提交.cursor/settings.json、.cursor/automations/benny/以及所有不含密钥的配置在各自编辑器中审阅每一条新自动化草稿或直接更新已有自动化然后发送一条无害的测试报告验证所有源频道的帖子都留在原线程内。2.2 包合并merge的具体规则setup-benny/SKILL.md 的第 1 步把 README 第 2 条展开为可执行的分步规则目标目录不存在时先创建每个源文件按相同相对路径复制到目标保留目标端独有文件——安装或刷新过程中永不删除无关文件用户自有的配置、feature map、routing map 一律放在目标目录之外永不覆盖当某个源管理路径下的已有文件内容不一致时检查 diff 并在不丢弃本地编辑的前提下合并所有权归属模糊时停止并询问校验目标端包含FOR_AGENTS.md、setup 文件、两个操作文件及其 references、全部 templates。对.cursor/settings.json的修改也有明确约束保留所有无关的顶层配置和其他插件条目若plugins.pstack已存在只改其enabled值文件使用 JSONC 时保留注释与合法 JSONC 语法编辑后校验文件。2.3 共享依赖的验证启用 pstack 的目的不是给 benny「装功能」而是让它能依赖 pstack 的技能与原则技能。从 setup-benny/SKILL.md 的清单看需要在项目作用域project scope下解析的共享技能包括how、why、tdd、unslop以及五个 principle 技能principle-separate-before-serializing-shared-state、principle-minimize-reader-load、principle-guard-the-context-window、principle-sequence-verifiable-units、principle-fix-root-causes、principle-prove-it-works。这些技能对应 pstack 插件skills/目录下的同名技能如 principle-prove-it-works。验证方式有严格前提必须用一个以目标仓库为根的新 agent确认这些技能从项目作用域解析出来——当前会话或用户级安装中加载的技能不算数。若项目级插件不可用或任一共享依赖无法解析应停止并解释失败原因且不要把.cursor/automations/benny/skills/加进插件 manifest、也不要期待它们出现在 slash skill 列表里。这一步通过后线上自动化提示词就可以用稳定的仓库相对路径读取已提交的操作文件不允许嵌入插件缓存路径或把文件内容复制进提示词——这正是 README 第 5 步「先提交、后启用」的原因。3. 包内目录结构与文件职责整个包只有四类文件职责划分清晰文件职责FOR_AGENTS.md人类意图源intent source两个自动化的触发/行为/工具/结果/边界加上完整的配置占位清单设置流程的入口skills/setup-benny/SKILL.md安装流程的操作手册合并规则、配置适配、能力检查、/automate使用边界、线程安全测试skills/triage-issue-reports/SKILL.mdtriage 自动化的运行时操作文件10 步流程skills/reproduce-and-fix-issues/SKILL.mdreproduce 自动化的运行时操作文件15 步流程templates/configuration.example.yaml用户配置的完整示例需复制到包外填写templates/triage-automation-prompt.md、templates/reproduce-automation-prompt.md两条自动化线上提示词的意图模板含{{占位符}}references/ 下的四个文件feature map 模板、control-adapter 契约、verify-existing-fix 模式、routing map 示例两个 references 目录中的文件与操作文件是「被引用」关系triage SKILL 引用routing.example.mdreproduce SKILL 引用control-adapter.md、feature-map.example.md与verify-existing-fix.md。4. Triage 自动化一次运行产出唯一判定triage-issue-reports/SKILL.md 是整个包中流程最完整的一份操作文件。其定位是对一条 Slack 报告做分类并在源线程内发布一条有用的判定只有对清晰的新 bug 才创建 tracker 工单绝不在这里复现或修复。4.1 硬性安全规则该文件开列的 hard safety rules 是理解 benny 安全模型的关键源频道与 root 线程坐标不可变immutable永不发源频道 root 消息永不向其他频道发帖、广播、发 DM 或另开替代线程在任何 tracker 写入之前、以及在判定发布之前都要对源父消息做 preflight父消息缺失、被删、不可访问或状态不确定时直接停止且不做任何写入只发一条实质性判定不播报进度协调者coordinator是唯一的 Slack 发帖者委派出去的 worker 必须是只读的、只返回发现且不得接收 Slack 凭证或写操作——每个子提示词都必须显式禁止SendSlackMessage、PostToSlack、chat.postMessage等一切 Slack 写动作若 worker 隔离无法保证这些限制就改由协调者自己做永不创建无法链接回源线程的工单宁可不出单也不要猜测或重复出单对源坐标应用 pstack 的principle-separate-before-serializing-shared-state对最终判定应用principle-minimize-reader-load与unslop技能。4.2 冻结源坐标第 1 步要求在列工作清单或委派之前冻结坐标从触发器读source_channel_id并与配置比对SOURCE_THREAD_TS优先取trigger.thread_ts否则取trigger.ts且必须非空随后把SOURCE_CHANNEL_ID与SOURCE_THREAD_TS存为不可变值读取线程验证 root 坐标完全一致并抓取稳定的源 permalink。之后所有源端读取和发布都必须使用这两个存储值「永不」替换为回复时间戳或 operations 线程时间戳。这一规则与两个提示词模板triage-automation-prompt.md 与 reproduce-automation-prompt.md中的触发器 JSON 字段一一对应{ source_channel_id: {{SLACK_CHANNEL_ID}}, message_ts: {{SLACK_MESSAGE_TS}}, thread_ts: {{SLACK_THREAD_TS_OR_EMPTY}} }4.3 读全报告 → 溯源 → 分类读全报告先读 root 与全部当前回复收集报告者措辞、产品版本/构建/环境/平台、期望行为、实际行为、频率与触发方式、错误文本或栈签名、已有 issue/commit/PR 链接、以及「是否已有人明确在修」的陈述检查每个相关附件截图按可用分辨率读、视频看关键状态转换、日志/trace 找具体签名附件读不了就在判定里如实说明绝不臆测其内容。先溯源再路由用 pstack 的how技能沿「报告动作 → 观察结果」的路径做有界的源码与历史走查报告像回归或涉及防御性代码时用why。这一遍不要求完整根因只要求「强到足以避免把可见症状路由给错误的负责人」。仓库不可读时不猜代码归属继续保守分类并声明溯源不可用。分类五个互斥类别——Bug违反预期行为含错误输出、状态损坏、崩溃、挂起、静默无操作、回归、Performance可度量的慢、内存、电量、卡顿等资源问题按 bug 处理但保留测量与 profile、Feature request、Question/feedback、Reroute。bug 与 feature 的界线不清时不出单判定中可提一个聚焦问题并用other标记。4.4 路由、去重与出单门槛路由读routing.map_path指向的可选路由图匹配依据是「已确认的产品区域、代码路径或错误签名」仅凭可见症状不够无路由匹配时说明负责人不清、不猜不交叉发帖cross-post而是在源线程里告诉报告者该把问题带去哪里。负责人 ping 默认关闭且必须同时满足四条才允许路由图明确点名、配置允许该 ping 类型、属于需要负责人输入的功能请求或有强证据的疑似回归作者、且对象不是宽泛的 on-call 组。去重先检查该源 permalink 是否已关联到某 tracker 工单或某次分诊回复是则不发帖不出单。对 bug/performance 报告用精确错误签名、产品区域、触发方式、症状、版本或时间窗、疑似回归提交、源 permalink 组合搜索。结果四选一确信重复更新已有工单加 permalink 与一句复发说明不重开/不改标签/不重分配、可能相关在判定里作为不确定项链接不创建、弱相似、无匹配。长期关闭的工单是回归线索而非自动的在网重复项。出单门槛只有同时满足七条才创建工单——分类为 bug/performance、行为明确损坏、仍在网或未知已修复、去重未发现确信或可信的在网匹配、源父消息与 permalink 通过 preflight、tracker 目标字段已解析、适配器具备「判定发布失败时可补偿」的能力。新工单必须自包含朴素标题指明区域与症状不含猜测的根因、报告者引语、期望/实际行为、版本与环境或unknown、触发与频率、源线程 permalink、带假设标注的溯源发现、内联截图或代表帧、其余产物链接、配置好的 intake 状态与标签。4.5 判定发布与标记契约发布前再跑一次新的源父消息 preflight然后以channelSOURCE_CHANNEL_ID、thread_tsSOURCE_THREAD_TS精确发布一条回复且「从未」允许在没有非空thread_ts时调用源频道发帖动作。判定要短先说结果、链接已有或新建的 tracker 工单、必要时提一句重路由或缺失事实、至多一个允许的 owner ping、以恰好一行标记结尾。标记契约如下只允许使用配置的标记字符串[benny:bug] [benny:bug] trackerhttps://tracker.example/issue/123 [benny:performance] [benny:performance] trackerhttps://tracker.example/issue/123 [benny:other]发布后必须回读同一源线程验证判定确实出现在SOURCE_THREAD_TS下若不出现永不在 root 重试。若本次运行创建了 tracker 工单但判定没发出去就用适配器的补偿动作把该工单取消/关闭/删除并验证补偿结果补偿无法验证时只在自动化运行输出里报告失败。最后是一个跟进窗口follow-up window只回答直接问给 triage 身份的问题、在安全时对 tracker 工单做具体更正、同一运行内不发第二个标记、不参与人类协调与闲聊、被要求停止就停止窗口最多延长一次新报告应开启新运行。5. Reproduce fix 自动化标记等待、双次复现与有界修复reproduce-and-fix-issues/SKILL.md 是包中最长的操作文件15 步。它的定位是等待源线程中的可信分诊标记通过目标应用的真实 UI 复现精确症状若已有修复则验证之只在确认复现后尝试一次有界修复。配置、必需动作、控制适配器或完成的 feature map 任一缺失即 fail closed。5.1 标记等待与所有权门槛第 2 步「等待分诊契约」在配置的判定预算内监听源线程并保持静默。只接受同时满足三条的判定——作者匹配slack.triage_identity_user_id、是SOURCE_THREAD_TS下的回复、恰好包含一个配置的标记。只对bug或performance推进并抓取可选 tracker URL遇到other、无判定、不可信作者、冲突标记或超时全部静默停止。第 3 步「所有权与修复产物门槛」要求开工前重读线程有人明确认领修复声称在修、给出具体实现计划、或要求某个 agent 实现/打补丁/开 PR时停止。注意反例清单bot 汇总证据、工具查日志或工单、有人让 bot 做诊断/解释/检查/复现、bot 发布根因假设但未承诺实现——这些都不算修复所有权。判据是「被要求的动作」而非 bot 的存在。若存在一个开放 PR 或已合并 commit 可能修复该报告则切换到 verify-existing-fix.md 描述的验证模式没有 commit/PR 的口头声明不构成修复产物。有人认领但没产出时停止不与人类竞跑。5.2 控制适配器七能力第 5 步要求读取 control-adapter.md 与control.feature_map_path指向的完成版 feature map然后调用control.skill_name命名的技能并强制要求全部七项能力按配置拉起目标应用与测试环境导航已映射功能并演练其文档化状态用真实 UI 驱动点击、键入、按键、滚动、拖拽、缩放、导航只读检查状态不改变它截屏开始/停止屏幕录制清理进程、会话、profile 与临时数据。适配器缺失或任一能力缺失时把 operations 状态标为 blocked 并停止——「不假装截图、单元测试、状态变更或读源码就是 UI 复现」。control-adapter 契约本身对适配器行为有细化约束适配器必须先报告能力与可驱动/被阻塞的 feature map 部分基线构建与打补丁构建必须使用相同环境输入重试要有界密钥不得出现在日志与产物中录制必须覆盖到「可判别症状的最终状态」而非只有 setup 或 loading 屏清理不得删除用户工作。契约还定义了「环境翻译environment translation」在宣布环境阻塞前先用平台无关的名词重述缺陷看相同行为能否在可用环境中安全测试例如「某个命名浏览器」可以指任何外部浏览器只有测试的是同一底层行为时才用翻译尝试并标注为 translated evidence不得称之为精确复现。启用前还要跑一次九步的无害适配器自检拉起 → 确认稳定标记 → 加载一个完成的 feature map 段落 → 按用户路径导航 → 演练一个可丢弃状态 → 检查状态 → 截屏 → 短录制 → 清理九步全过且不涉及任何源频道发帖才可启用复现工作。5.3 复现的「两次规则」与证据评审第 7 步复现的判定标准值得逐条记住先命名正确的最终状态再命名损坏的最终状态走到两者分叉点观察到损坏状态重置足够的状态使第二次尝试相互独立重复同一路径并再次观察到相同损坏状态然后在可能时交叉核对一个真实状态值。预期中的对话框、loading 态或 setup 步骤不算 bug。复现预算内复现不出来就给出干净的Could not reproduce环境缺能力就报Blocked并说明缺什么。第 8 步要求成功复现后录制完整症状路径、截损坏最终状态、保存精确步骤与观察的短笔记、产物放进配置的临时 artifact 目录然后让只读媒体评审回答一个问题——「证据是否可见地展示了可判别的损坏状态」答案是否定或不确定复现即未确认。5.4 验证已有修复verify 模式verify-existing-fix.md 把「已有产物」的验证压缩成一句话现有产物拥有这个修复你只验证不编辑、不写竞争补丁、不开替代 PR。具体要求产物必须具体一个代码改动针对该症状的开放 PR、一个已合并 PR、或代码与意图匹配的已合并 commit线程声明、tracker 状态、分支名、根因假设都不算。多个产物时选源线程或 tracker 链接的那个否则选与受影响代码最接近的并说明理由。用独立 worktree 或干净 checkout 保护工作树记录基线修订、打补丁修订、PR/commit URL、两次运行共享的构建与环境输入。基线测量开放 PR 用其 base 分支已合并修复用修复前一个可构建且代表旧行为的修订。通过控制适配器跑真实 UI 路径两次观察到可判别症状基线上两次都复现不出来就没有基线不得声称修复有效。打补丁构建相同环境与数据构建运行 PR 或修复 commit同一路径两次确认损坏态消失且期望态出现采集 after 录制、截图与同一状态检查。「不要停在编译或测试上——after 结果必须来自运行中的打补丁应用。」三种结果Confirmed基线两次复现、打补丁构建两次消除 → 状态标 verified链接产物发一条简短源线程回复不开 PR、Insufficient fix两个构建都出现症状 → 标「复现但未修复」链接产物说明未解决不开竞争 PR、Inconclusive基线不复现/打补丁应用跑不动/证据未展示可判别状态 → 不声称成功说明哪一半没测出来。5.5 有界修复与草稿 PR第 11 步列出尝试修复的七重门槛普通确认复现、媒体评审确认了损坏最终态、无既有修复产物、拒绝窗口期内无人认领、运行时证据指认根因、预期改动落在配置的修复预算与仓库范围内、控制适配器能跑基线与打补丁两个构建。任一不满足就停在复现报告。通过门槛后协调者拥有所有 Slack 帖子、最终 diff 审查、commit 与 PR只读 worker 可追代码与历史、提议测试、画爆炸半径、审 diff、审媒体但不编辑、不做外部写、不发状态、不拥有修复只有当工具隔离能证明该 worker 环境中排除了 Slack 凭证与全部 Slack 写动作时才可委派一个紧范围的代码编辑且提示词仍必须携带显式 Slack 写禁令不确定时就留在协调者手里。实现要求用运行时证据确认机制、编辑前排除竞争假设、以最小合理改动修根因有廉价本地测试目标时调用 pstack 的tdd技能、先写失败测试再修路径昂贵/不明确/集成重时说明为何跳过 TDD不夹带无关清理改动超出预算即停。第 13 步「证明修复」保留原始基线证据在打补丁构建上跑同一真实 UI 路径两次、展示损坏态消失与期望态就位、采集 after 录制与截图、交叉核对基线用的同一真实状态值——「编译、单元测试、代码审查或看似合理的 diff 都不是 after 证据」。随后跑聚焦测试并对爆炸半径做 smoke覆盖相邻状态、输入、权限、平台与失败路径仍有回归就停、不开 PR。第 14 步只在 before-and-after 证据齐备后开draftPR审查最终 diff 中无关改动与密钥、跑仓库要求的检查、在允许时做小而有顺序的 commit、链接配置好的 tracker 工单、使用配置的公开 URL 形式默认https://github.com/{owner}/{repo}/pull/{number}、包含复现步骤/根因/测试结果/before-after 证据/爆炸半径检查并用unslop技能过一遍 PR 文本与 Slack 更新。这个工作流永不 merge 或 deployPR 创建失败时不声称成功把 commit/分支状态留在运行输出里并标Fix did not land。6. 配置参考configuration.example.yaml 逐段说明configuration.example.yaml是唯一完整的配置示例schema_version: 1需要复制到包外如.cursor/benny/configuration.yaml填写不要编辑包内示例——包刷新可能更新源管理文件但永不触碰用户副本。各段含义如下automations两条自动化的命名triage_name: benny-triage、reproduce_name: benny-reproduce与 setup 流程中交给/automate的名称一致。slacksource_channel_id必需、operations_channel_id可选状态频道、triage_identity_user_id判定可信身份、四个动作占位读、线程发帖、文件下载、operations 编辑、prefer_cursor_actions: true优先使用已配置的 Cursor Slack 动作、optional_bot_token_env: BENNY_SLACK_BOT_TOKEN可选 bot token 只用于补一个窄缺口如编辑那一条 operations 状态消息或下载附件且必须存在密钥管理器或环境变量中而不是写进 YAML、allow_source_root_posts: false与allow_worker_slack_writes: false两个硬开关。repository仓库 URL、默认分支、pull_request_action能开 draft PR 的动作、pull_request_url_format、draft_only: true。tracker类型示例为linear、adapter_skill_name、team/project/labelsbug、performance、intake、needs_repro 四类标签占位、intake 状态、source_link_title以及require_compensation_action: true——要求适配器具备「本次运行创建的工单在 Slack 交接失败时可被取消/关闭/删除」的补偿能力对应 triage 第 9 步的补偿规则。tracker 是适配器而非指定厂商Linear 只是示例GitHub Issues 或其他 tracker 实现同一契约即可。routingmap_path示例指向.cursor/benny/routing.md、owner_pings_default: false以及两个 ping 授权开关默认全关。controlskill_name控制适配器技能名、feature_map_path、测试环境、artifact_directory: /tmp/benny-artifacts、artifact_retention_hours: 24。verdict_markers三个标记字符串与tracker_attribute: tracker构成 4.5 节的标记契约的可配置部分。status_emojiseen / reproducing / reproduced / could_not_reproduce / blocked / fixing / fix_failed / pull_request_opened 八个状态表情字符串示例值 ✅ ⚪ ⛔ ️ ❌ 用于 operations 频道的状态更新。budgetspoll_seconds: 45轮询间隔、verdict_wait_minutes: 45判定等待、triage_follow_up_minutes: 10、triage_total_minutes: 30、repro_minutes: 60、rejection_window_minutes: 10拒绝窗口、fix_minutes: 90修复预算、operations_follow_up_minutes: 45。这些数字同时是「fail closed 之前愿意花多少时间」的量化边界。modelstriage / reproduce / code / media_review 四个角色各配一个模型 slug。setup 流程明确要求只使用用户在 Cursor 模型选择器或支持列表中能看到可用的 slug不猜、不沿用私有默认。FOR_AGENTS.md 的「my configuration」一节还列出了示例 YAML 之外的意图级配置项可选 operations 频道、分诊身份、control skill、feature map提交在包外的同仓库路径或「待意译的行为」、状态表情字符串、各类预算、以及可选 bot token 能力none、file download或editable operations status三档。7. 三份用户侧参考文件feature map、routing map、control adapterbenny 把「如何理解你的产品」的知识全部外置成三份用户自有文件均要求复制到.cursor/automations/benny/之外7.1 Feature mapfeature-map.example.md给出逐功能模板每个功能一段包含「用户如何到达」点击路径与快捷键、「控制适配器如何驱动它」适配器动作与可见结果 重置方式、「稳定选择器」role/可访问名/ARIA 关系/语义化 data 属性严禁生成类名、StyleX 类、动态 hash、子索引、脆弱 DOM 位置、「要演练的状态」default/hover/focus-visible/active/disabled、loading/empty/error、selected/open/expanded 及功能特有变体、「前置条件与 setup」认证、fixture 数据、权限、flags、服务可用性、「证据与交叉检查」截图/视频/只读状态核对各自的要求、「Gotchas」已知死胡同与安全的环境翻译。示例文件附了一个虚构任务应用的四个功能Sign in、Item list and detail、Item editor、Settings作为填写范本并以完整性检查清单收尾。关键原则map 保持在用户视角内部实现与当前代码路径运行时再发现不冻结在 map 里。7.2 Routing maprouting.example.md是一份 YAML 数据文件routes列表每条含name、matchproduct_areas / code_paths / error_signatures 三类匹配、destinationslack_channel 与 tracker_team、owners与allow_feature_owner_ping外加fallback目的地默认为空除非某个团队接受所有未匹配报告与ping_policydefault 为 offallow 仅「已配置的功能负责人」与「已确认的回归作者」deny「宽泛 on-call 组」与「未经验证的负责人」。规则强调triage 技能把它当数据处理一条路由需要报告或溯源的证据支撑仅靠关键词匹配不够重路由只是告诉报告者该去哪里自动化永不交叉发帖。7.3 Control adapter如 5.2 节所述control-adapter.md 定义的是契约而非实现bring up / drive UI / drive mapped features and states / inspect state / screenshot / recording / cleanup 七个能力各自的输入、返回与禁止事项例如 drive UI 不允许设置内部状态、调用隐藏方法、直写存储或注入 DOM 来制造症状inspect 必须是只读会改变状态的查询属于 drive UI。8. 启用前验证线程安全七项检查与创建边界setup 流程的最后一步第 8 步是线程安全测试全部基于测试频道或无害测试报告triage 存下 root 的thread_ts且只以回复形式发布恰好一条判定判定恰好包含一个配置的标记repro 只接受来自配置分诊身份的标记repro 保持同一套不可变源坐标没有源频道 root 消息出现被委派的 worker 无法使用任何 Slack 写动作坐标缺失、父消息被删或 preflight 失败时无帖子、无 tracker 工单产生。七项全过才允许放开正常流量。测试前还要确认三件事.cursor/settings.json、.cursor/automations/benny/、以及所有被引用的无密钥配置文件都已提交在自动化 checkout 所用分支上两条线上提示词都指向各自精确的已提交操作文件任一检查失败即停止并告知用户自动化还不能启用。创建路径本身也有一条硬边界setup 流程的「Creation boundary」永不调用直接的自动化后端服务或后端自动化工具、永不使用携带草稿字段的浏览器 URL、永不构建或打开 Cursor protocol 深链——新自动化的唯一完成路径是内置automate技能审阅后的 Automations editor 交接。首次创建时/automate对 triage 用一次、对 repro 用一次且第一条的草稿审阅、批准、就绪检查与 editor 交接全部完成后才允许开始第二条。对已有自动化则完全相反内置automate只能创建、不能检查或更新已有自动化所以 setup 流程改为给出一份精简的字段检查清单让用户在各自编辑器中直接更新——不创建替代项、不产生重复。9. 设计要点小结把散落在各文件中的规则汇总benny 的架构可以归纳为五条不变量坐标不可变SOURCE_CHANNEL_ID与SOURCE_THREAD_TS在两条自动化中都是冻结值一切源端读写只走这对坐标preflight 不通过即零写入单一发帖者协调者独占 Slack 写权限子 agent 只读、无凭证、提示词携带显式写禁令隔离不可证明时工作收回协调者证据先于动作两次真实 UI 复现 媒体评审确认才谈修复基线与打补丁构建的 before-and-after 都来自运行中的应用编译与测试不构成 after 证据已有产物强制切换验证模式不与人类或既有 PR 竞跑fail closed 贯穿始终配置、tracker、控制适配器、feature map 任一缺失或不确定都表现为「不出声、不写入」并如实报告缺什么产物只到 draft只开草稿 PR永不 merge、永不 deploy用户自有配置在包外包刷新永不覆盖操作文件走已提交的仓库相对路径提示词不复制内容、不用缓存路径。对于想在自有 Slack 问题频道部署类似流水线的团队benny 包提供了一个可直接复制的起点FOR_AGENTS.md表达意图、两个操作 SKILL 承载运行时行为、templates 提供配置骨架、references 外置产品知识——四条路径FOR_AGENTS.md、triage-issue-reports/SKILL.md、reproduce-and-fix-issues/SKILL.md、configuration.example.yaml即覆盖了从安装到启用的完整知识面。【免费下载链接】pluginsCursor plugin specification and official plugins项目地址: https://gitcode.com/GitHub_Trending/plugins125/plugins创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考