GitHub Issue 沉淀

把 GitHub Issue 中的观点沉淀到站内文档的流程。

流程

1. 用 gh issue list 或 gh issue view <number> --comments --json number,title,author,body,comments,url 读取待处理 issue。
2. 先确认内容来源。正文为空时，要检查 issue comments；若评论中有自动抓取的原文、链接、发布时间、作者、正文，应优先使用评论里的完整内容，不只根据标题猜测。
3. 判断观点应归属到哪个内容区域：
   • 健康幸福 → docs/01-health/
   • 事业有成、能力、职业、AI、安全、软件工程 → docs/02-capability/
   • 财务自由 → docs/03-wealth/
   • 人生丰富、体验、探索世界 → docs/04-experience/
   • 全局人生框架 → docs/overview.mdx
4. 先判断是否能拿准处理方式。若内容核心、归属位置、修改文件和处理边界都明确，可以直接融合处理；若归属不确定、需要新建文章、可能影响多个栏目、原文信息不足或边界难判断，先给出处理计划并等待用户确认。
5. 需要确认时，计划至少说明：内容核心、归属位置、准备修改的文件、新建或融入现有文档的理由、不会处理的边界。
6. 先过滤不适合沉淀的 issue：功能实现、部署方案、站点架构任务、带日期标题的特殊记录、只有一句想法且缺少展开材料的 issue，不按文章沉淀流程处理。此类 issue 保持 open，除非用户明确要求继续处理为功能或方案。
7. 对原始观点进行探讨和完善：补足逻辑链条，去掉口号化、重复或过于临时的表达。
8. 将内容融入对应文档的合适位置，优先调整上下文和段落结构，避免孤立追加。
9. 沉淀内容不要过分简洁。不能只提炼成几条摘要，要尽量把有价值的因果链、适用条件、反例、实践步骤、风险边界和与现有文章的关系写完整。
10. 若 issue 对应的是完整教程、系统方法、独立概念或现有文档无法承载的主题，可以新建文章。新建文章必须遵循网站开发规范：确认真实 icon、设置稳定英文 slug、添加 description，并在对应入口页补链接。新建文章默认属于需要确认的情形，除非用户已经明确要求新建。
11. 处理完成后，在 issue 中留言说明沉淀位置和改动内容，再关闭 issue。
12. 提交时在 commit 信息末尾附上 issue 编号，例如：优化财富框架 (#42)。

边界

• 默认只处理用户本人创建的 issue。若 issue 由其他人创建，应先向用户确认是否需要处理。
• 不要简单把 issue 原文追加到文档中。要先理解其核心观点、适用边界和与现有内容的关系，再整理成更清晰、连贯、可沉淀的表达。
• 用户已授权：能拿准的 issue 可以直接融合处理，不需要每个都先问；拿不准时必须先问，不要硬猜。
• 已经判断为需要用户确认的 issue，在用户确认前不要修改文档、留言或关闭 issue。
• 如果公开搜索找不到原文，但 issue comments 已包含抓取内容，可以直接使用 comments 中的内容；如果正文和评论都缺失，只能按标题处理时，要在计划里说明信息不足。
• 本流程默认处理“可沉淀为文章内容”的 issue。非文章型 issue（功能开发、站点架构、部署配置、数据管道、每日/年度特殊记录、单句灵感）不要为了关闭 issue 强行写入文章或 SKILL；需要实现时应转入对应开发任务流程，信息不足时保持 open。