尧图网站建设 
Deno Issue Triage 技能实战从分类、复现到打标签的完整 Issue 分诊工作流【免费下载链接】denoA modern runtime for JavaScript and TypeScript.项目地址: https://gitcode.com/GitHub_Trending/de/denoDeno 仓库在.claude/skills/目录下维护了一套面向 AI Agent 的技能Skill文件其中 issue-triage/SKILL.md 定义了一套标准化的 GitHub Issue 分诊流程读取 issue、判断类型、校验信息完整性、在隔离环境中复现 bug、按规则打标签、发布结构化的分诊评论。读完本文你将掌握这套六步工作流的每一步操作细节、ghCLI 命令用法、Docker 复现方案以及标签体系如何与 Deno 仓库的目录结构一一对应。技能定义frontmatter 与工具白名单SKILL.md是一个带 YAML frontmatter 的 Markdown 文件其头部元数据声明了技能的名称、触发条件、参数提示和工具白名单name: issue-triage description: Triage a Deno GitHub issue — reproduce bugs, classify, label, and comment with findings. Use when asked to triage an issue or when an issue number/URL is provided for triage. argument-hint: issue-number-or-url allowed-tools: Bash(gh *) Bash(deno *) Bash(git *) Bash(mktemp *) Bash(rm *) Bash(cat *) Read Write Glob Grep Agent几个设计要点值得注意触发条件当用户要求 triage 某个 issue或提供了 issue 编号/URL 时Agent 应加载该技能把参数作为$ARGUMENTS贯穿整个流程正文第一行即声明Triage issue $ARGUMENTS on the denoland/deno repository。工具白名单allowed-tools字段把 Agent 的权限收敛到gh、deno、git、mktemp、rm、cat等最小命令集合以及文件读写类工具。这是一种最小权限模式——分诊只需读 issue、跑复现代码、改标签和评论不需要构建仓库或执行任意命令。内联命令标记正文中用!围栏包裹的命令如gh issue view表示技能被调用时应自动执行的命令与普通说明性代码块区分开。同一目录下还有若干姊妹技能各自承担不同的分诊/审查场景review-pr/SKILL.mdPR 审查、node-compat/SKILL.mdNode 兼容性问题、fmt/SKILL.md、lint-all/SKILL.md、lint-js/SKILL.md。issue-triage 是其中唯一面向入站 issue的技能与 review-pr 面向入站 PR形成互补。Step 1读取 Issue流程的第一步是通过ghCLI 拉取 issue 的完整元数据gh issue view $ARGUMENTS --repo denoland/deno --json number,title,body,author,labels,state,comments,createdAt,url这条命令以 JSON 形式返回 issue 的编号、标题、正文、作者、已有标签、状态、评论、创建时间和 URL。其中body是后续所有判断分类、提取复现代码、检查信息完整性的输入来源labels用于识别 issue 是否还挂着needs triage/triage required 这类待分诊标记Step 5 会移除它们。Step 2五分类判断技能把每个 issue 归入以下五类之一Bug report—— 行为不符合预期Feature request / suggestion—— 新能力或增强请求Question—— 使用问题不是 bugDuplicate—— 已有同类报告。查找方式是用关键词搜索全部状态的 issuegh issue list --search keywords --state all--state all同时覆盖 open 和 closed避免重复报告只与已关闭 issue 重复却被漏判的情况Invalid—— 无法处理、不属于 Deno 的问题、或信息不足。这里有一个重要的**快速路径fast-path**设计如果 issue 明显属于 question、duplicate 或 invalid跳过复现环节直接跳到 Step 5 打标签。这与仓库的 CI 设计哲学一致——doc/ci.md 描述的pre-build门禁同样是先用廉价判断决定下游任务是否执行避免为不需要构建的 PR 跑完整流水线。分诊中的先分类再复现就是 issue 层面的 docs-only 快速路径。Step 3校验信息完整性一个合格的 bug report 必须同时包含四项信息Deno 版本deno --version的输出操作系统复现步骤或最小复现代码预期行为 vs 实际行为。任一项缺失时技能给出的处理是打上needs info标签并评论请求作者补充缺失细节。明确禁止在没有清晰复现用例时尝试复现——这与 CLAUDE.md 中遇到构建/测试失败先看具体输出再排查的排障风格一脉相承先确认证据再做推断。版本号在 Deno 中是一等公民构建时通过编译期环境变量DENO_VERSION、DENO_CANARY、DENO_RC注入版本信息并缓存到denover段中供deno --version读取见 cli/lib/version.rs 与 cli/lib/version.txt当前仓库记录的版本号为 2.9.6。因此 issue 中的版本号能精确定位到一次构建是版本对比复现策略的前提。Step 4复现 Bug只有携带清晰复现用例的 bug report 才进入这一步。隔离环境优先 Docker技能要求在 Docker 容器内运行复现代码以保证隔离仅在 Docker 不可用时退回到本地临时目录# Run repro with latest canary docker run --rm -v $REPRO_DIR:/repro -w /repro denoland/deno:canary deno run repro.ts # Run repro with a specific version (e.g., 2.1.4) docker run --rm -v $REPRO_DIR:/repro -w /repro denoland/deno:2.1.4 deno run repro.ts要点docker run --rm保证容器用完即删复现文件通过-v挂载进容器的/repro工作目录。本地回退方案则用mktemp -d建临时目录REPRO_DIR$(mktemp -d) deno run $REPRO_DIR/repro.ts双版本对比策略复现时尽量跑两个版本issue 中报告的版本若指定——确认 bug 确实存在最新 canary——检查是否已被修复。两个版本分别对应不同的 Docker 镜像 tag如denoland/deno:2.1.4、denoland/deno:canary。如果指定版本能复现而 canary 上不复现应记录可能已修复并进一步检查 git log 中寻找相关修复提交。复现执行与清理从 issue 正文中提取复现代码写入本地临时目录用 issue 中描述的deno子命令和 flag 在容器或本地中运行同时捕获 stdout 和 stderr再与 issue 描述的预期行为对比如果复现涉及特定 npm 包、deno.json配置或多文件工程按描述完整重建该环境完成后清理rm -rf $REPRO_DIR。记录复现结论技能要求最终记录三个问题bug 在报告的版本上是否复现bug 在 canary 上是否复现有无额外观察不同的报错信息、部分修复、关联 issue 等这套报告版本 × canary的二维结论矩阵正是后面 Step 5/Step 6 打regression标签和撰写评论模板的直接输入。Step 5打标签技能强调标签要从简——通常一个 area 标签就够不要过度打标。标签分三层类型标签最多一个Label使用场景bug已确认的 bug——凡是验证过的 bug report 必加feat已被接受的新特性suggestion尚未接受的功能请求question使用问题duplicate与另一个 issue 重复invalid无法处理panicDeno panic / 崩溃regression以前可用现在坏掉bug与suggestion的边界是是否已被接受尚未决策的功能请求只能先标suggestion而不是feat。regression的判定依据正是 Step 4 的双版本对比——旧版本可用、新版本坏掉才配得上这个标签。区域标签选一个最匹配的LabelAreanode compat通用 Node.js 兼容性node API特定node:*模块 APIext/node,ext/fs,ext/net,ext/http,ext/fetch,ext/web,ext/crypto,ext/console,ext/url,ext/websocket,ext/kv具体扩展cliCLI 行为、flag、子命令lsp语言服务器runtimeRuntime cratepermissions权限系统compiledeno compiletestingdeno test与覆盖率task runnerdeno taskinstalldeno install/deno addtscTypeScript 编译器typesTypeScript 类型问题configdeno.json配置node resolutionNode/npm 模块解析publishdeno publishlintdeno lintwasmWebAssembly这些标签并非凭空命名而是与仓库目录结构高度对齐这让区域标签实际上承担了分诊路由的职责ext/*系列标签对应 ext/ 下的同名扩展 crate如 ext/fetch/、ext/net/、ext/kv/、ext/web/、ext/crypto/、ext/console/、ext/url/、ext/websocket/Node 兼容性问题落在 ext/node/含 ext/node/polyfills/ 下的内置模块 polyfillcli对应 cli/ crateflag 解析在 cli/args/flags.rs每个子命令在 cli/tools/ 下一个模块如 cli/tools/compile.rs、cli/tools/test/、cli/tools/lint/、cli/tools/publish/、cli/tools/pm/ 对应deno install/deno add的包管理工具链lsp对应 cli/lsp/runtime对应 runtime/deno_runtimecratepermissions对应 runtime/permissions.rs 及 runtime/permissions/ 目录下的权限系统config的解析实现位于 libs/config/ crate。这个映射与 doc/codebase-map.md 的目录导览一致ext/下每个子目录就是一个扩展Rust crate 加带数字前缀的 JS 文件如 ext/fs/30_fs.js所以拿到一个带区域标签的 issue基本就能直接定位到应读的源码目录。优先级标签仅在明显必要时添加Label使用场景high priority影响严重、阻塞用户、安全问题quick fix显然简单的修复添加与清理标签gh issue edit $ARGUMENTS --repo denoland/deno --add-label bug并移除待分诊标记若存在gh issue edit $ARGUMENTS --repo denoland/deno --remove-label needs triage --remove-label triage required 移除needs triage/triage required 是分诊完成的标志性动作——与 CI 中pre-build决定任务去留类似分诊结论决定 issue 的后续流向带bug的 issue 进入开发流程带duplicate/question/invalid的进入关闭流程。Step 6发布分诊评论评论按 issue 类型使用固定模板保证信息结构一致、可快速扫读确认的 bugConfirmed on [version]. [Brief description of what you observed.] [If tested on canary: Also reproduces on canary. or Does not reproduce on canary — may already be fixed.]需要补充信息Thanks for reporting. Could you provide [missing info]? This will help us investigate.重复 issueThis looks like a duplicate of #XXXX. Closing in favor of that issue.使用问题This is a usage question rather than a bug. [Brief answer or pointer to docs.] Closing this — feel free to ask on https://discord.gg/deno if you have more questions.发布与关闭命令gh issue comment $ARGUMENTS --repo denoland/deno --body comment textgh issue close $ARGUMENTS --repo denoland/deno --reason not planned注意关闭的适用范围只有 duplicate、question、invalid 三类可以关闭bug report 一律不关——即使暂无人处理needs info的 bug 也只评论不关闭等待作者补充。Rules安全边界与行为守则技能末尾的 Rules 一节划定了自动化分诊的安全边界也是整套流程可信度的来源任何修改 GitHub 的操作发评论、改标签前必须与用户确认——Agent 拥有gh权限但不应越权执行不关闭 bug report只关闭重复、问题类和无效 issue标签保持最小化一个类型标签 一个区域标签通常足够对报告者保持善意感谢报告者尤其是首次贡献者无法复现就如实说明不猜测原因——不确定的结论比没有结论更有危害复现所需权限或资源不可用时记录该限制并跳过复现未经调查不得驳回任何 issue。小结issue-triage/SKILL.md 展示了一种可复制的Agent 技能写法用 frontmatter 声明触发条件与最小工具集用编号步骤固定工作流顺序用快速路径避免无谓工作question/duplicate 跳过复现用模板化输出保证结论一致用显式 Rules 划定自动化行为的边界。配合 Deno 仓库自身的分层结构cli/、runtime/、ext/、libs/区域标签实际上把每个 issue 路由到了正确的源码目录让分诊从行政动作变成了有技术含义的分诊。同一目录下的 review-pr/SKILL.md 则把同样的方法论应用到了 PR 审查侧门禁检查、逐文件审查、结构化 review两者共同构成 Deno 仓库面向 AI Agent 的贡献者工作流。【免费下载链接】denoA modern runtime for JavaScript and TypeScript.项目地址: https://gitcode.com/GitHub_Trending/de/deno创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Deno Issue Triage 技能实战：从分类、复现到打标签的完整 Issue 分诊工作流
Deno Issue Triage 技能实战从分类、复现到打标签的完整 Issue 分诊工作流【免费下载链接】denoA modern runtime for JavaScript and TypeScript.项目地址: https://gitcode.com/GitHub_Trending/de/denoDeno 仓库在.claude/skills/目录下维护了一套面向 AI Agent 的技能Skill文件其中 issue-triage/SKILL.md 定义了一套标准化的 GitHub Issue 分诊流程读取 issue、判断类型、校验信息完整性、在隔离环境中复现 bug、按规则打标签、发布结构化的分诊评论。读完本文你将掌握这套六步工作流的每一步操作细节、ghCLI 命令用法、Docker 复现方案以及标签体系如何与 Deno 仓库的目录结构一一对应。技能定义frontmatter 与工具白名单SKILL.md是一个带 YAML frontmatter 的 Markdown 文件其头部元数据声明了技能的名称、触发条件、参数提示和工具白名单name: issue-triage description: Triage a Deno GitHub issue — reproduce bugs, classify, label, and comment with findings. Use when asked to triage an issue or when an issue number/URL is provided for triage. argument-hint: issue-number-or-url allowed-tools: Bash(gh *) Bash(deno *) Bash(git *) Bash(mktemp *) Bash(rm *) Bash(cat *) Read Write Glob Grep Agent几个设计要点值得注意触发条件当用户要求 triage 某个 issue或提供了 issue 编号/URL 时Agent 应加载该技能把参数作为$ARGUMENTS贯穿整个流程正文第一行即声明Triage issue $ARGUMENTS on the denoland/deno repository。工具白名单allowed-tools字段把 Agent 的权限收敛到gh、deno、git、mktemp、rm、cat等最小命令集合以及文件读写类工具。这是一种最小权限模式——分诊只需读 issue、跑复现代码、改标签和评论不需要构建仓库或执行任意命令。内联命令标记正文中用!围栏包裹的命令如gh issue view表示技能被调用时应自动执行的命令与普通说明性代码块区分开。同一目录下还有若干姊妹技能各自承担不同的分诊/审查场景review-pr/SKILL.mdPR 审查、node-compat/SKILL.mdNode 兼容性问题、fmt/SKILL.md、lint-all/SKILL.md、lint-js/SKILL.md。issue-triage 是其中唯一面向入站 issue的技能与 review-pr 面向入站 PR形成互补。Step 1读取 Issue流程的第一步是通过ghCLI 拉取 issue 的完整元数据gh issue view $ARGUMENTS --repo denoland/deno --json number,title,body,author,labels,state,comments,createdAt,url这条命令以 JSON 形式返回 issue 的编号、标题、正文、作者、已有标签、状态、评论、创建时间和 URL。其中body是后续所有判断分类、提取复现代码、检查信息完整性的输入来源labels用于识别 issue 是否还挂着needs triage/triage required 这类待分诊标记Step 5 会移除它们。Step 2五分类判断技能把每个 issue 归入以下五类之一Bug report—— 行为不符合预期Feature request / suggestion—— 新能力或增强请求Question—— 使用问题不是 bugDuplicate—— 已有同类报告。查找方式是用关键词搜索全部状态的 issuegh issue list --search keywords --state all--state all同时覆盖 open 和 closed避免重复报告只与已关闭 issue 重复却被漏判的情况Invalid—— 无法处理、不属于 Deno 的问题、或信息不足。这里有一个重要的**快速路径fast-path**设计如果 issue 明显属于 question、duplicate 或 invalid跳过复现环节直接跳到 Step 5 打标签。这与仓库的 CI 设计哲学一致——doc/ci.md 描述的pre-build门禁同样是先用廉价判断决定下游任务是否执行避免为不需要构建的 PR 跑完整流水线。分诊中的先分类再复现就是 issue 层面的 docs-only 快速路径。Step 3校验信息完整性一个合格的 bug report 必须同时包含四项信息Deno 版本deno --version的输出操作系统复现步骤或最小复现代码预期行为 vs 实际行为。任一项缺失时技能给出的处理是打上needs info标签并评论请求作者补充缺失细节。明确禁止在没有清晰复现用例时尝试复现——这与 CLAUDE.md 中遇到构建/测试失败先看具体输出再排查的排障风格一脉相承先确认证据再做推断。版本号在 Deno 中是一等公民构建时通过编译期环境变量DENO_VERSION、DENO_CANARY、DENO_RC注入版本信息并缓存到denover段中供deno --version读取见 cli/lib/version.rs 与 cli/lib/version.txt当前仓库记录的版本号为 2.9.6。因此 issue 中的版本号能精确定位到一次构建是版本对比复现策略的前提。Step 4复现 Bug只有携带清晰复现用例的 bug report 才进入这一步。隔离环境优先 Docker技能要求在 Docker 容器内运行复现代码以保证隔离仅在 Docker 不可用时退回到本地临时目录# Run repro with latest canary docker run --rm -v $REPRO_DIR:/repro -w /repro denoland/deno:canary deno run repro.ts # Run repro with a specific version (e.g., 2.1.4) docker run --rm -v $REPRO_DIR:/repro -w /repro denoland/deno:2.1.4 deno run repro.ts要点docker run --rm保证容器用完即删复现文件通过-v挂载进容器的/repro工作目录。本地回退方案则用mktemp -d建临时目录REPRO_DIR$(mktemp -d) deno run $REPRO_DIR/repro.ts双版本对比策略复现时尽量跑两个版本issue 中报告的版本若指定——确认 bug 确实存在最新 canary——检查是否已被修复。两个版本分别对应不同的 Docker 镜像 tag如denoland/deno:2.1.4、denoland/deno:canary。如果指定版本能复现而 canary 上不复现应记录可能已修复并进一步检查 git log 中寻找相关修复提交。复现执行与清理从 issue 正文中提取复现代码写入本地临时目录用 issue 中描述的deno子命令和 flag 在容器或本地中运行同时捕获 stdout 和 stderr再与 issue 描述的预期行为对比如果复现涉及特定 npm 包、deno.json配置或多文件工程按描述完整重建该环境完成后清理rm -rf $REPRO_DIR。记录复现结论技能要求最终记录三个问题bug 在报告的版本上是否复现bug 在 canary 上是否复现有无额外观察不同的报错信息、部分修复、关联 issue 等这套报告版本 × canary的二维结论矩阵正是后面 Step 5/Step 6 打regression标签和撰写评论模板的直接输入。Step 5打标签技能强调标签要从简——通常一个 area 标签就够不要过度打标。标签分三层类型标签最多一个Label使用场景bug已确认的 bug——凡是验证过的 bug report 必加feat已被接受的新特性suggestion尚未接受的功能请求question使用问题duplicate与另一个 issue 重复invalid无法处理panicDeno panic / 崩溃regression以前可用现在坏掉bug与suggestion的边界是是否已被接受尚未决策的功能请求只能先标suggestion而不是feat。regression的判定依据正是 Step 4 的双版本对比——旧版本可用、新版本坏掉才配得上这个标签。区域标签选一个最匹配的LabelAreanode compat通用 Node.js 兼容性node API特定node:*模块 APIext/node,ext/fs,ext/net,ext/http,ext/fetch,ext/web,ext/crypto,ext/console,ext/url,ext/websocket,ext/kv具体扩展cliCLI 行为、flag、子命令lsp语言服务器runtimeRuntime cratepermissions权限系统compiledeno compiletestingdeno test与覆盖率task runnerdeno taskinstalldeno install/deno addtscTypeScript 编译器typesTypeScript 类型问题configdeno.json配置node resolutionNode/npm 模块解析publishdeno publishlintdeno lintwasmWebAssembly这些标签并非凭空命名而是与仓库目录结构高度对齐这让区域标签实际上承担了分诊路由的职责ext/*系列标签对应 ext/ 下的同名扩展 crate如 ext/fetch/、ext/net/、ext/kv/、ext/web/、ext/crypto/、ext/console/、ext/url/、ext/websocket/Node 兼容性问题落在 ext/node/含 ext/node/polyfills/ 下的内置模块 polyfillcli对应 cli/ crateflag 解析在 cli/args/flags.rs每个子命令在 cli/tools/ 下一个模块如 cli/tools/compile.rs、cli/tools/test/、cli/tools/lint/、cli/tools/publish/、cli/tools/pm/ 对应deno install/deno add的包管理工具链lsp对应 cli/lsp/runtime对应 runtime/deno_runtimecratepermissions对应 runtime/permissions.rs 及 runtime/permissions/ 目录下的权限系统config的解析实现位于 libs/config/ crate。这个映射与 doc/codebase-map.md 的目录导览一致ext/下每个子目录就是一个扩展Rust crate 加带数字前缀的 JS 文件如 ext/fs/30_fs.js所以拿到一个带区域标签的 issue基本就能直接定位到应读的源码目录。优先级标签仅在明显必要时添加Label使用场景high priority影响严重、阻塞用户、安全问题quick fix显然简单的修复添加与清理标签gh issue edit $ARGUMENTS --repo denoland/deno --add-label bug并移除待分诊标记若存在gh issue edit $ARGUMENTS --repo denoland/deno --remove-label needs triage --remove-label triage required 移除needs triage/triage required 是分诊完成的标志性动作——与 CI 中pre-build决定任务去留类似分诊结论决定 issue 的后续流向带bug的 issue 进入开发流程带duplicate/question/invalid的进入关闭流程。Step 6发布分诊评论评论按 issue 类型使用固定模板保证信息结构一致、可快速扫读确认的 bugConfirmed on [version]. [Brief description of what you observed.] [If tested on canary: Also reproduces on canary. or Does not reproduce on canary — may already be fixed.]需要补充信息Thanks for reporting. Could you provide [missing info]? This will help us investigate.重复 issueThis looks like a duplicate of #XXXX. Closing in favor of that issue.使用问题This is a usage question rather than a bug. [Brief answer or pointer to docs.] Closing this — feel free to ask on https://discord.gg/deno if you have more questions.发布与关闭命令gh issue comment $ARGUMENTS --repo denoland/deno --body comment textgh issue close $ARGUMENTS --repo denoland/deno --reason not planned注意关闭的适用范围只有 duplicate、question、invalid 三类可以关闭bug report 一律不关——即使暂无人处理needs info的 bug 也只评论不关闭等待作者补充。Rules安全边界与行为守则技能末尾的 Rules 一节划定了自动化分诊的安全边界也是整套流程可信度的来源任何修改 GitHub 的操作发评论、改标签前必须与用户确认——Agent 拥有gh权限但不应越权执行不关闭 bug report只关闭重复、问题类和无效 issue标签保持最小化一个类型标签 一个区域标签通常足够对报告者保持善意感谢报告者尤其是首次贡献者无法复现就如实说明不猜测原因——不确定的结论比没有结论更有危害复现所需权限或资源不可用时记录该限制并跳过复现未经调查不得驳回任何 issue。小结issue-triage/SKILL.md 展示了一种可复制的Agent 技能写法用 frontmatter 声明触发条件与最小工具集用编号步骤固定工作流顺序用快速路径避免无谓工作question/duplicate 跳过复现用模板化输出保证结论一致用显式 Rules 划定自动化行为的边界。配合 Deno 仓库自身的分层结构cli/、runtime/、ext/、libs/区域标签实际上把每个 issue 路由到了正确的源码目录让分诊从行政动作变成了有技术含义的分诊。同一目录下的 review-pr/SKILL.md 则把同样的方法论应用到了 PR 审查侧门禁检查、逐文件审查、结构化 review两者共同构成 Deno 仓库面向 AI Agent 的贡献者工作流。【免费下载链接】denoA modern runtime for JavaScript and TypeScript.项目地址: https://gitcode.com/GitHub_Trending/de/deno创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考