【免费下载链接】OpenShellOpenShell is the safe, private runtime for autonomous AI agents.项目地址https://gitcode.com/gh_mirrors/op/OpenShell点击查看免费下载导读本文讲解 OpenShell 仓库内置的贡献者技能triage-issue位于 .agents/skills/triage-issue/SKILL.md它是一套面向 Agent 的社区 Issue 评估与分流工作流负责把用户提交的 issue 转化为“事实充分、等待人工处置”的state:validated状态同时严格把路线图roadmap排期、接受与否等决策留给维护者。读完本文你将掌握该技能的调用方式、七个核心步骤、十一类分类标准、state:*状态机与agent:*委托标签的完整语义并了解它与create-spike、build-from-issue等下游技能如何串联成端到端管道。背景OpenShell 的 agent-first 协作模型OpenShell 是一个为自主 AI Agent 提供安全、私有运行时的开源项目。其贡献流程同样贯彻“agent-first”理念Agent 负责调查、验证、规划与实现人类负责产品决策与路线图。CONTRIBUTING.md 开篇即声明“OpenShell is built agent-first”并围绕这一理念把贡献工作拆分为“技术评估、产品处置、路线图排期、代理委托”四个互不混淆的层次。在 AGENTS.md 中项目把技能划分为两套skills/面向用户的公共、可安装技能如 openshell-cli、debug-inference、debug-openshell-cluster必须在源码检出之外也能工作以已安装 CLI 帮助与已发布文档为准。.agents/skills/面向贡献者与维护者的内部工作流triage-issue即属于此集合由仓库感知的 Agent 运行时原生加载。triage-issue 的定位只建立事实不做产品决策triage-issue的核心使命非常明确为人类决策者建立“OpenShell 是否应该处理该 issue、以及它属于路线图的哪个位置”所需的事实。技能文档反复强调三件事它不做不授权工作、不排期、不产出实现计划那是build-from-issue的职责不决定技术上有效的工作是否该投入不把“技术有效性”当作“产品接受”。换言之分流triage是评估层assessment layer它只回答“报告是否真实、证据是否充分、影响有多大”然后停下等待人类给出是/否与排期结论。前置条件运行该技能前需要确认ghCLI 已认证gh auth status当前位于带有 GitHub remote 的 git 仓库中工作流标签state:validated、state:accepted、state:needs-info必须已存在。若缺失应向操作者报告不得隐式创建。关键约束处置与路线图排期只能由人完成技能文档专门设置了“Critical: Disposition and Roadmap Placement Are Human-Only”一节。执行分流时Agent 必须遵守以下红线不得决定 OpenShell 是否应在其他有效工作上投入不得应用或移除state:accepted不得把 issue 加入路线图项目、不得应用或移除roadmap标签也不得推荐具体路线图条目不得应用agent:plan-requested或agent:implementation-requested不得把技术有效性等同于产品接受。OpenShell没有priority:*优先级标签。排期完全来自 issue 与 OpenShell 路线图条目的关联而这种关联是维护者的专属决策。CONTRIBUTING.md 的“Issue Lifecycle, Roadmap, and Agent Work”一节用一张决策表总结了分工决策问题记录方式评估Assessment报告技术上是否有效、证据是否足以行动state:*处置DispositionOpenShell 是否应推进这项工作state:accepted、路线图放置或以 not planned 关闭排期Sequencing已接受的工作相对其他工作的位置关联 OpenShell Roadmap 项目归属Ownership由人实现、用户直接指示 Agent还是维护者排队给无人值守 Agent直接指示或可选的agent:*工作流state:validated表示“事实评估已完成、等待人类处置”不等于项目已接受该工作。维护者用state:accepted或路线图放置来发出接受信号路线图放置额外携带排期信息但不指派所有者。状态机与 agent 委托标签CONTRIBUTING.md 定义了四个生命周期状态状态含义通常的下一步state:triage-needed尚未评估。无仓库写权限的用户提交的新 issue 自动获得此标签调查报告并记录结果state:needs-info评估需要特定证据或复现细节报告者或其他贡献者补充所请求的信息state:validated事实评估已完成维护者接受、拒绝或要求更多证据state:accepted维护者决定 OpenShell 应推进该 issue人类可实现或维护者委托给 Agentstate:stale只是非活跃标记不是生命周期决策已接受、待人工处置的 issue 豁免于 stale 处理而state:needs-info若无新证据则可能变 stale。agent:*标签用于维护者把工作排队给持续运行的无人值守 AgentAgent 工作流标签由谁应用含义agent:plan-requested维护者请 Agent 产出实现计划agent:plan-readyAgent计划已就绪等待人类评审agent:implementation-requested维护者计划已批准Agent 可实现agent:in-progressAgent已授权的实现正在进行agent:pr-openedAgent实现产出了拉取请求标准的委托链路是state:accepted或路线图放置→agent:plan-requested→agent:plan-ready→agent:implementation-requested→agent:in-progress→agent:pr-opened。规划授权不等于实现授权agent:plan-requested只授权取走规划agent:implementation-requested才确认人类已评审计划并授权实现。Agent 永远不得应用这两个请求标签。一个重要的例外用户直接指示 Agent 处理某个具体 issue 时该指示本身即授权所请求的阶段即使 issue 缺少预期的生命周期或工作流标签。此时 Agent 应警告缺失的标签然后继续工作但不得擅自修改这些标签。评论标记区分 Agent 与人类评论该技能发布的所有评论必须以以下标记行开头 ** triage-agent**该标记用于把分流评论与人类评论以及其他技能如️ build-from-issue-agent、 security-review-agent等区分开也用于 Step 2 的“是否已分流”检测。调用模式该技能支持两种调用模式。单 issue 模式triage issue 250 triage issue #250给定 issue 编号直接进入 Step 1 开始评估。批量模式triage issues批量模式在处理前必须经过确认门禁防止对公共仓库造成意外的大规模评论。Step 1预览。查询所有匹配的 issue 并显示摘要gh issue list --label state:triage-needed --state open --json number,title --jq .[] | #\(.number) \(.title)把结果呈现给用户最多展示 10 条超出显示 “and N more”并提示“这将在每个 issue 上发布分流评论”。Step 2确认。使用AskUserQuestion向用户索要明确确认选项为 “Proceed with all N issues”、“Let me pick specific issues”并允许自定义输入。未获确认不得继续。Step 3处理。仅在确认后对每个 issue 运行完整的七步工作流最后报告每一条 issue 及其分类的摘要。七步分流工作流Step 1获取 Issue去掉 issue 编号前导的#然后获取完整内容gh issue view id --json title,body,state,labels,author,comments若该 issue 已关闭直接报告并停止。Step 2检查是否已分流在 issue 评论中搜索分流标记 ** triage-agent**若找到标记且其后没有携带新信息或新问题的人类评论报告“该 issue 已被分流”并停止。若找到标记但有更新的、包含额外信息的人类评论进入 Step 3基于新上下文重新评估。若人类已拒绝该 issue、应用了state:accepted或已将其放入路线图不得撤销或重新解释该决策。若未找到标记进入 Step 3。Step 3检查报告完整性检查是否包含实质性的 User Story、Problem Statement、Impact / Why This Matters 与 Acceptance Criteria。Impact 应解释当前行为的后果以及现有 workaround 为何不足。Bug 报告还需复现步骤与相关环境功能请求需检查 Proposed Design 与 Alternatives Considered。报告者提供的诊断与 Agent 输出是可选项不得作为准入门禁。若所需章节缺失关键信息归类为needs-information只请求缺失的确切信息移除state:triage-needed并添加state:needs-info。若公共 issue 可能披露安全漏洞不得复述或展开敏感细节归类为security-report引导操作者阅读 SECURITY.md。使用类问题与支持请求转介到文档化的支持渠道。明确的重复、错误仓库报告与客观上的预期行为无需完整技术调查即可处理。报告需要技术验证时进入 Step 4。Step 4核对报告版本与已知修复在深入诊断前先判断报告是否可能已被较新版本修复从 issue 正文、环境章节、日志与评论中提取报告的 OpenShell 版本若未提供记录为缺失上下文并继续。在可用时核对当前发布信息与已知修复gh release list --limit 10gh release view tag关联 issue、已合并 PR、发布说明、本地 git 标签/历史以及开放与关闭状态的潜在重复若网络访问或发布元数据不可用在分流评论中说明该限制而不是猜测。若 issue 针对旧版本、而较新版本或已合并 PR 看起来解决了相同行为若报告者已在修复/当前版本上复现继续 Step 5。若报告者尚未在修复/当前版本上测试在采用fixed-in-release前必须找到具体的修复变更若因果联系不确定请请求重测而不是宣告已修复。Step 5诊断与验证通过 Task 工具调用principal-engineer-reviewer子代理评估报告向其提供完整 issue 标题与正文以怀疑视角评估的指令包含 10 个问题用户故事确立了怎样的人物画像与期望能力问题陈述是否与当前产品行为一致Impact 是否解释了后果、当前 workaround 及其为何不足验收标准是否具体、可观察、与用户故事一致描述的工作流能否从给定信息复现或以其他方式验证当前产品是否支持所请求的结果哪个组件拥有该行为该报告最适合归类为 bug、功能请求、支持请求还是其他类别若是功能请求提议的设计在技术上是否自洽且可行不要决定项目是否应接受它是否存在开放或已关闭的重复 issue仍有怎样的不确定性哪些确切证据可以消除它基于子代理的分析还要直接尝试验证报告Bug 报告检查相关代码路径寻找所述失败模式功能请求对照现有架构评估可行性网关部署或基础设施问题参考 skills/debug-openshell-cluster/SKILL.md 中的已知失败模式推理与 provider 拓扑问题参考 skills/debug-inference/SKILL.mdCLI/使用问题参考 skills/openshell-cli/SKILL.md 中的工作流并用openshell --help确认已安装语法。最后为人类决策记录影响信号受影响用户与范围、回归状态、workaround 可用性、严重性证据、证据质量。不要把这些事实转换为路线图或排期建议。Step 6分类根据调查结果把 issue 归入以下十一类之一分类含义Agent 动作validated-bug证据确认真实缺陷添加相关 area/topic 标签把 triage/needs-info 状态替换为state:validated保持 openvalidated-feature提议在技术上自洽且可行添加相关 area/topic 标签把 triage/needs-info 状态替换为state:validated保持 openneeds-investigation报告可信但需要更深层的 spike可用时添加spike把 triage/needs-info 状态替换为state:validated保持 open等待人类决定是否投入 spikeneeds-information关键的复现或环境证据缺失把state:triage-needed替换为state:needs-info请求确切缺失的证据cannot-reproduce忠实尝试未复现但报告可能仍然有效把state:triage-needed替换为state:needs-info记录尝试过程并请求可区分的证据fixed-in-release某个已发布的具体变更修复了所述行为解释修复与版本仅在因果联系清晰时关闭否则请求重测duplicate另一个开放或已关闭的 issue 是规范报告链接规范 issue 并关闭expected-behavior代码与文档确立了该行为是有意为之解释行为并关闭support-request报告请求的是使用帮助而非跟踪工作提供支持渠道并关闭wrong-repository另一个仓库拥有受影响的组件链接正确的跟踪仓库并关闭security-report报告可能包含漏洞避免进一步公开分析引导操作者阅读SECURITY.md以安全处理两个明确的禁止项不得用validated-feature暗示路线图接受不得用expected-behavior拒绝技术上有效的功能请求。Step 7发布分流评论发布带有分流标记的结构化评论 ** triage-agent** ## Triage Assessment **Classification:** validated-bug | validated-feature | needs-investigation ### Summary What was established and confidence in the evidence. ### Investigation Reproduction results, code/release evidence, affected components, and duplicates. ### Impact Signals - **Affected users/scope:** facts or unknown - **Regression:** yes/no/unknown - **Workaround:** available/unavailable/unknown - **Evidence quality:** high/medium/low with reason ### Human Decision Required Decide whether OpenShell should address this issue. If yes, apply state:accepted, associate it with a roadmap item, or do both, and decide whether the work remains human-owned. Either action records acceptance; roadmap placement additionally records sequencing. To queue investigation or planning for an unattended agent, also apply agent:plan-requested. You can instead directly ask an agent to use create-spike or build-from-issue on this issue; the agent will warn about missing expected workflow labels and continue without changing them. If no, close it as not planned and record the rationale.对其他结果如needs-information、fixed-in-release、duplicate等把影响与决策部分替换为确切的信息请求、客观的解决方案或安全转介指引。分流期间的状态规则在state:triage-needed、state:needs-info、state:validated中恰好保持一个入站/分流状态每次评估完成后移除state:triage-needed分流期间永不应用state:accepted、任何agent:*标签或roadmap标签永不关闭已通过验证的 issue。与其他技能的关系端到端管道triage-issue是社区贡献管道的第一环。技能文档给出了完整的关系图Community issue filed | [GitHub Action: instant gate check] | triage-issue | state:validated | human decline OR state:accepted / roadmap placement | create-spike (if deeper investigation is approved) | human queues planning with agent:plan-requested OR directly requests planning | build-from-issue (creates implementation plan) | human queues implementation with agent:implementation-requested OR directly requests implementation | implementation各技能的分工是triage-issue建立技术有效性与影响证据人类决定是否接受有效工作以及它落在路线图的什么位置create-spike见 .agents/skills/create-spike/SKILL.md只有在投入调查获得批准后深化调查把模糊问题映射为结构化、可构建的 issue并在证据充分时标记state:validated、否则标记state:needs-info——它同样永不添加state:accepted、agent:*或roadmap标签build-from-issue可在特定 issue 上被直接调用无人值守 Agent 用agent:plan-requested取走规划、用agent:implementation-requested取走实现。AGENTS.md 还列出了项目内的其他工作流链与分流管道形成对照内部开发链为create-spike→ 人工处置 →build-from-issue安全链为review-security-issue→fix-security-issue通用构建 Agent 不得处理topic:security的 issue安全 issue 按 SECURITY.md 走私有流程策略迭代链为openshell-cli→generate-sandbox-policy。从源码结构看该工作流的可执行性从仓库结构可以确认triage-issue引用的全部支撑材料在仓库中真实存在并保持同步状态机与决策分工的权威定义位于 CONTRIBUTING.md 的 “Issue Lifecycle, Roadmap, and Agent Work” 章节其中“谁执行哪项动作”的对照表与技能文档的红线完全一致AGENTS.md 作为注入给 Agent 的指令表面把triage-issue明确列为 “Community inflow” 管道的起点并规定“issue triage 只确立技术有效性与影响证据Agent 永不决定接受、应用state:accepted、把 issue 放上路线图或应用agent:*请求标签”技能引用的三个公共诊断技能——openshell-cli、debug-inference、debug-openshell-cluster——均位于skills/目录供 Step 5 按问题类型CLI、推理/provider 拓扑、网关部署分流参考下游的create-spike技能与本技能共用同一套状态语义与标签红线保证管道各环对state:*与agent:*的理解一致。这套设计把“谁调查、谁验证、谁接受、谁排期、谁实现”彻底解耦分流 Agent 是事实调查者维护者是人类决策者agent:*标签与直接用户指令是委托通道。任何一环都不能越权替代另一环。小结为什么这套分流机制值得借鉴triage-issue的价值在于用机制而不是信任来约束 Agent评论标记保证可审计、批量模式用确认门禁保护公共仓库、state:*状态机让所有贡献者对 issue 所处阶段一目了然、agent:*标签为无人值守 Agent 提供安全的队列拾取语义而“技术有效 ≠ 产品接受”的红线保证了机器判断永远无法替人类拍板路线图。对 OpenShell 社区而言这意味着每个新 issue 都能以一致、可追溯、证据充分的方式进入评估流程对构建类似 agent-first 协作流程的团队而言这套“评估层/处置层/排期层/委托层”分离的模型本身就是一份可复制的设计范本。赞分享【免费下载链接】OpenShellOpenShell is the safe, private runtime for autonomous AI agents.项目地址https://gitcode.com/gh_mirrors/op/OpenShell点击查看免费下载相关推荐Phoenix Issue Triage 技能实战七阶段开源 Issue 分流工作流全解析Phoenix Issue Triage 技能实战七阶段开源 Issue 分流工作流全解析 开源仓库的 Issue 积压是每个活跃项目都要面对的难题——类型不可观测性AI 评测LLMOpsAI 应用人工智能Kubernetes Issue Triage 实战指南社区 Issue 分流流程、优先级体系与工具链Kubernetes Issue Triage 实战指南社区 Issue 分流流程、优先级体系与工具链 本文基于 Kubernetes 社区仓库的官方文档 c开源治理文档研发协作sentry-javascript 仓库的 AI Issue 分流Triage实战指南triage-issue Skill 工作流与安全机制全解析sentry javascript 仓库的 AI Issue 分流Triage实战指南triage issue Skill 工作流与安全机制全解析 导读可观测性上一篇离线转字幕还能顺手翻译video-subtitle-master 本地视频字幕实战指南下一篇Noto 字体避坑指南一套免费开源字体900 语言告别豆腐块创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
