用途：在审查或维护 llm-wiki 仓库、对照当前 LLM/AI 工程概念、或需要从 wiki 架构与内容差距中生成 GitHub issue 时使用。触发条件包括：被要求审查、刷新或维护 llm-wiki 仓库；要求建立保持 AI/LLM 概念新鲜的每周节奏；询问应开启哪些 GitHub issue；或会话产生需持久化收尾、交接的维护产物。核心原则是把 llm-wiki 视为开发杠杆系统而非被动知识库。
每周工作流分五步：一、仓库架构盘点，检查信息架构（领域、概念页、源码映射、图/清单生成、校验脚本、文档报告），识别过期页面、孤立节点、弱交叉链接、缺失来源引用、未与代码开发用例绑定的概念。二、外部概念新鲜度扫描，关注 agents、tool use、RAG、context engineering、evals、model-routing、推理/服务、结构化输出、安全、数据治理和代码智能体工作流，以候选增量而非原始研究堆砌记录。三、代码开发实用性映射，对每个候选差距追问能改进哪个仓库决策、代码模式、评估、文档契约或自动化流水线。四、创建 issue 组合，去重并检查现有 issue 与计划状态后开启，按类别聚类：新鲜度流水线、图/索引质量、来源与引用治理、领域页面、代码集成指南、评估/就绪记分卡；实现受工作区 issue 流程约束（计划→对抗性审查→用户批准→TDD 实现）。五、验证与收尾，运行仓库现有的图清单、schema、文档、法律/公共安全门禁测试与校验器；无法完成收尾时，用仓库跟踪的交接文件保存验证证据、脏文件、issue 状态与下一检查点。
良好的 issue 应包含：与代码开发杠杆相关的清晰问题陈述、当前证据路径、范围边界、带验证命令或报告产物的验收标准、公私数据分类、对现有架构契约与图 schema、引用模型、来源摄入工作流的依赖。
陷阱：不要创建泛泛的“加主题 X”式平铺待办；外部趋势需有来源出处和更新日期；不要因任务偏文档而绕过 issue 计划门禁；不要只生成报告就关闭 issue，须核对提交文件、推送状态、标签评论与测试；不要在提交/推送/关闭前丢失部分收尾状态，应先写交接。参考资料为 references/issue-closeout-handoff-pattern.md，描述验证通过但实现文件仍需最终提交与关闭 issue 时的重启交接模式。