k-learn
把踩过的坑或好做法沉淀成可检索的 learning 文档,两条轨道 pitfall(坑)/ knowledge(默认做法)。触发:用户说"沉淀知识"、"learning"、"把这次经验记下来",或 acceptance / fix 收尾时推送。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
把踩过的坑或好做法沉淀成可检索的 learning 文档,两条轨道 pitfall(坑)/ knowledge(默认做法)。触发:用户说"沉淀知识"、"learning"、"把这次经验记下来",或 acceptance / fix 收尾时推送。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
维护 `.kflow/architecture/` 这份只记现状的系统地图,三种模式 update / check / backfill。触发:用户说"刷新 architecture"、"做架构检查"、"补这个模块的架构文档"、"方案和代码对得上吗",或 feature 阶段需要先做架构动作。不写未来规划(走 k-roadmap)。
feature 流程阶段 3——验收闭环:对照 design 核实现 + 回写 architecture / requirement / roadmap,最后产出 {slug}-acceptance.md。触发:用户说"功能写完了验收一下"、"做最后检查"、"准备 merge"、"出验收报告"。前置依赖 k-feat-impl 完成。
feature 流程阶段 1——为新功能起草 {slug}-design.md 作为后续实现和验收的唯一输入,拍板后抽出 checklist。触发:用户说"开始设计方案"、"写 design doc"、"准备实现 XX",前提是已知道做什么、为谁、怎么算成功。
feature 流程阶段 2——按 {slug}-checklist.yaml 里 design 切好的 paradigm 维度 steps 推进,每步具体改哪个文件由 implement 自决,写完用统一格式汇报。触发:用户说"方案确认了开始实现"、"按方案写代码"、"开工"。前提是 design 已 approved 且有 checklist。遇到方案外情况要回方案谈不要硬冲。
issue 流程阶段 2——读 report + 读代码定位根因、评估风险,给用户 2-3 个修复方案让 TA 拍板。这一步不改代码。触发:用户说"分析这个 bug"、"找根因"、"定位问题",且已有 {slug}-report.md。
issue 流程阶段 3——按已确认根因和方案定点修复、验证、写 {slug}-fix-note.md 落档。两个入口:标准路径从 analyze 来,快速通道从 report 直接来。触发:用户说"开始修 bug"、"按分析修"、"动手改代码"。只动方案声明的文件,不顺手优化。
| name | k-learn |
| description | 把踩过的坑或好做法沉淀成可检索的 learning 文档,两条轨道 pitfall(坑)/ knowledge(默认做法)。触发:用户说"沉淀知识"、"learning"、"把这次经验记下来",或 acceptance / fix 收尾时推送。 |
开始任何判断或动作前,先读取 .kflow/attention.md;缺失则视为骨架不完整,提示先补齐或运行 k-onboard。
每次做 feature 或修 issue 都会留下 spec 文件。但 spec 记录的是"做了什么"和"怎么做的",不会记录"踩了什么坑"和"发现了什么更好的做法"。没有沉淀的团队总在重复解决同一个问题。
两条轨道:
两者都写入 .kflow/compound/(共享目录见 shared-frontmatter.md"归档类文档")。本技能产出 frontmatter 带 doc_type: learning,命名 YYYY-MM-DD-learning-{slug}.md。
| 情境 | 说明 |
|---|---|
| 完成 feature 工作流 | k-feat-accept 主动问"要记录这次的学习点吗?" |
| 完成 issue 工作流 | k-issue-fix 主动问"要把这个坑记录下来吗?" |
| 用户主动 | "记录一下"、"沉淀知识"、"learning"等 |
| 解决了一次性难题 | 不在 feature / issue 内但花了大量时间才解决的工程问题 |
主动推荐一句话即可,用户说"不用了"立刻跳过——重复推可能让用户觉得 AI 在加戏。
坑点:调试过的 bug / 绕过的配置陷阱 / 环境问题 / 集成失败……一切"本来应该好但没好"的经历。
知识:发现的最佳实践 / 工作流改进 / 架构洞见 / 可复用设计模式……一切"以后应该默认这样做"的学习。
frontmatter / 正文模板 / 完整示例见同目录 reference.md。
从对话上下文提取:
来源不明确问用户一个问题澄清不要猜。
按 shared-archive.md 查重规则:
--filter tags~= 或 --query 查一遍,命中相近旧文档时把候选列给用户更新路径:读旧文档 → 和用户对齐要改哪几节(常见是补新踩的坑、补当时"没找到原因"的根因)→ 起草 diff → 写回原文件 + updated: YYYY-MM-DD,不新建。
坑点轨道问:
知识轨道问:
用户对某问题说"没什么"或"跳过"就跳过——宁可少一节也不用空话填充。
AI 一次性起草完整文档(YAML frontmatter + 所有正文节)。一次性展示给用户。
compound/YYYY-MM-DD-learning-{slug}.md(日期取归档当天),frontmatter 带 doc_type: learningupdated: YYYY-MM-DDshared-archive.md supersede 规则处理写完若发现一两行"每次 kflow 技能启动都该知道"的项目硬约束,提示用户用 k-note 追加到 .kflow/attention.md。不要自作主张改 attention,也不要写外部 AI 入口。
完整语法见
.kflow/reference/tools.md。
# 按轨道筛选坑点
python .kflow/tools/search-yaml.py --dir .kflow/compound --filter doc_type=learning --filter track=pitfall --filter severity=high
# 按组件查相关学习点
python .kflow/tools/search-yaml.py --dir .kflow/compound --filter doc_type=learning --filter component~={组件名}
# 归档后查重叠
python .kflow/tools/search-yaml.py --dir .kflow/compound --filter doc_type=learning --filter tags~={主要 tag} --json
归档类共享规则见
shared-archive.md。本技能特有:
features/ 或 issues/;spec 也不放进 compound/doc_type: learning