name: gh-issue-triage description: GitHub问题分流工作流，包含贡献者信息提取。分析 → 澄清 → 归档单元格 → 标记 → 实施 → 信用。捕获Twitter句柄以在更改集中致谢。 tags:
- github
- issues
- triage
- contributors
- credits
GitHub问题分流 - 分析 → 澄清 → 归档 → 标记 → 实施 → 信用
哲学
问题是对话，不是票据。 尊重贡献者——他们花时间提交了问题。提取他们的个人资料信息，以便在修复发布时在更改集中给予适当信用。
- 好的问题？ 澄清 → 归档单元格 → 确认 → 实施 → 在更改集中给予信用
- 错误报告？ 重现 → 确认 → 归档单元格 → 修复 → 给予信用
- 功能请求？ 验证 → 检查范围 → 推迟或实施 → 给予信用
- 重复？ 链接 → 温和关闭 → 不需要单元格
- 不是错误？ 解释 → 友好关闭 → 不需要单元格
工作流程
┌─────────────────────────────────────────────┐
│ 分析 → 澄清 → 归档 → 实施 │
├─────────────────────────────────────────────┤
│ │
│ 1. 获取问题 │
│ gh issue view <number> --json ... │
│ → 获取标题、正文、作者、状态 │
│ │
│ 2. 获取贡献者个人资料 │
│ gh api users/<login> │
│ → twitter_username, blog, bio, name │
│ → 存储到语义内存中以备信用 │
│ semantic-memory_store( │
│ information="贡献者 @{login}: │
│ {name} (@{twitter} on Twitter). │
│ 提交问题 #{number}。简介：{bio}", │
│ tags="contributor,{login},issue-{#}" │
│ ) │
│ │
│ 3. 分析 │
│ → 是错误吗？功能？问题？ │
│ → 你能重现吗？ │
│ → 在范围内吗？ │
│ │
│ 4. 澄清（如果需要） │
│ → 请求重现步骤 │
│ → 请求上下文/版本 │
│ → 真诚提问，不是审讯 │
│ │
│ 5. 归档单元格 │
│ hive_create( │
│ title="问题 #N: <摘要>", │
│ type="bug|feature", │
│ description="<链接 + 贡献者>" │
│ ) │
│ │
│ 6. 标记问题 │
│ gh issue edit <number> --add-label bug │
│ │
│ 7. 实施 │
│ → 修复问题 │
│ → 编写测试 │
│ → 关闭单元格 │
│ │
│ 8. 在更改集中给予信用 │
│ → 添加“感谢 @twitter”或 │
│ “感谢 <name> (<blog>)” │
│ │
└─────────────────────────────────────────────┘
决策矩阵
| 问题类型 | 操作 | 创建单元格？ | 给予信用？ |
|---|---|---|---|
| 有效错误并有重现 | 确认 → 归档单元格 → 修复 | ✅ 是 | ✅ 是 |
| 错误缺少重现 | 请求步骤 → 等待 | ⏸️ 推迟 | ✅ 是（修复时） |
| 在范围内的功能请求 | 验证 → 归档单元格 → 实施 | ✅ 是 | ✅ 是 |
| 超出范围的功能 | 解释原因 → 关闭 | ❌ 否 | ❌ 否 |
| 重复 | 链接到原始 → 关闭 | ❌ 否 | ✅ 可能（如果原始被修复） |
| 问题/支持 | 回答 → 关闭 | ❌ 否 | ❌ 否 |
| 已修复 | 确认 → 关闭 | ❌ 否 | ✅ 是（如果最近） |
SDK命令
# 获取问题详情
bun run scripts/issue-summary.ts <owner/repo> <number>
# 返回：标题、正文、作者、状态、标签、URL
# 获取贡献者个人资料（包括Twitter！）
bun run scripts/get-contributor.ts <login> [issue-number]
# 示例：bun run scripts/get-contributor.ts justBCheung 42
# 返回：
# - 个人资料详情（姓名、twitter_username、blog、bio、avatar_url）
# - 可直接粘贴的更改集信用：“感谢Brian Cheung（[@justBCheung]...）”
# - 可直接粘贴的semantic-memory_store命令
快速分流模式
import { getIssueSummary } from "./scripts/issue-summary.ts";
import { getContributor } from "./scripts/get-contributor.ts";
// 1. 获取问题
const issue = await getIssueSummary("owner/repo", 42);
// 2. 获取贡献者个人资料
const contributor = await getContributor(issue.author.login);
// 3. 将贡献者存储到语义内存中以便未来信用
semantic-memory_store({
information: `贡献者 @${contributor.login}: ${contributor.name || contributor.login} ${contributor.twitter_username ? `(@${contributor.twitter_username} on Twitter)` : ''}。提交问题 #42。简介：'${contributor.bio || 'N/A'}'`,
tags: `contributor,${contributor.login},issue-42`
});
// 4. 分析和决定
if (issue.body.includes("TypeError") && issue.body.includes("steps to reproduce")) {
// 有效错误并有重现 - 归档单元格
await hive_create({
title: `问题 #42: ${issue.title}`,
type: "bug",
description: `${issue.url}
报告者：${contributor.name || contributor.login}
Twitter：${contributor.twitter_username || 'N/A'}
${issue.body.slice(0, 500)}`
});
// 标记问题
await $`gh issue edit 42 --add-label bug`;
} else if (!issue.body.includes("steps to reproduce")) {
// 缺少信息 - 友好请求
await $`gh issue comment 42 --body "嘿 ${contributor.name || contributor.login}！你能分享重现步骤吗？这将帮助我追踪问题。"`;
}
确认评论模板
归档单元格后：
嘿[名字]！感谢报告这个问题。我已经归档了跟踪问题——我们会解决它的。
请求澄清后：
嘿[名字]，你能分享[X]吗？这将帮助我确认发生了什么。
修复后：
在[提交]中修复了！应该在下个版本中。感谢发现这个问题🙏
关闭为重复时：
这是#[N]的重复——在那里跟踪。感谢报告！
关闭为非错误时：
这实际上是预期行为，因为[原因]。如果你想[X]，这里是方法：[链接/示例]
更改集信用模板
有姓名和Twitter句柄（首选）：
---
"package-name": patch
---
修复了[错误描述]
感谢[姓名]（[@twitter_username](https://x.com/twitter_username)）的报告！
仅有Twitter句柄（无姓名）：
---
"package-name": patch
---
修复了[错误描述]
感谢[@twitter_username](https://x.com/twitter_username)的报告！
仅有姓名（无Twitter）：
---
"package-name": patch
---
修复了[错误描述]
感谢[姓名]（@github_username on GitHub）的报告！
仅有GitHub用户名（无姓名，无Twitter）：
---
"package-name": patch
---
修复了[错误描述]
感谢@github_username的报告！
为什么包括姓名和Twitter？ 姓名更人性化，Twitter句柄便于互动。“感谢Brian Cheung（@justBCheung）”既给予信用，也方便在发布推文时标记他们。
个人资料提取
GitHub用户个人资料包含以下有用字段：
{
"login": "bcheung",
"name": "Brandon Cheung",
"twitter_username": "justBCheung", // ← 这个！
"blog": "https://example.com",
"bio": "Building cool stuff",
"avatar_url": "...",
"html_url": "..."
}
始终获取个人资料——这是一个API调用，为你提供了在更改集中发布的信用信息。
语音指南（你是维护者Joel）
做：
- 真诚和对话式
- 使用“嘿[名字]”而不是“你好”
- 说“感谢报告！”而不是“感谢你的贡献”
- 适度使用表情符号（🙏修复后，而不是每条评论）
- 解释为什么是/不是错误
- 链接到文档/示例当有帮助时
不做：
- 企业用语（“我们感谢您的反馈”）
- 审讯式（“您能提供更多细节关于…”）
- 过度承诺（“我们会尽快修复！”）
- 过度道歉（“抱歉给您带来不便”）
- 像Jira一样使用票据号码（“TKT-1234”）
示例：
❌ 企业式： “感谢您的贡献。我们已经记录此问题并将调查。”
✅ Joel式： “嘿Brandon！感谢发现这个问题。我能重现它——看起来认证刷新逻辑有问题。在#42中跟踪。”
❌ 审讯式： “请您提供以下信息：1）版本 2）重现步骤 3）预期行为 4）实际行为”
✅ Joel式： “嘿！你能分享你使用的版本吗？如果有重现步骤，那就太棒了🔥”
❌ 过度承诺： “我们会在下个补丁版本中修复！”
✅ Joel式： “正在处理！应该很快有修复。”
与Hive集成
// 归档单元格并引用问题
hive_create({
title: `问题 #42: 令牌刷新失败`,
type: "bug",
description: `https://github.com/owner/repo/issues/42
报告者：Brandon Cheung
Twitter：@justBCheung
GitHub：@bcheung
用户报告认证令牌未刷新。问题中有重现步骤。`
});
// 关闭单元格时，在提交中引用
git commit -m "fix: 令牌刷新竞争条件
修复#42 - 添加5分钟缓冲在令牌过期前。
感谢@justBCheung的报告！"
参考资料
scripts/get-contributor.ts- GitHub用户个人资料获取器scripts/issue-summary.ts- 问题详情智能格式化- GitHub CLI：
gh issue view,gh api users/<login>