Menú
把"短到不值得起一份文件、但 AI 每次启动 kflow 技能都必须知道"的项目碎片知识追加到 `.kflow/attention.md` 的固定分节里——比如编译特殊 flag、运行前要先起的服务、路径陷阱、命令别名、环境变量约定。触发：用户说"记一笔"、"加到 attention.md"、"项目要 X 才能编译"、"以后每次都得 Y"，或刚踩到一个一句话能讲清的项目特殊设置。
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional 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-note |
| description | 把"短到不值得起一份文件、但 AI 每次启动 kflow 技能都必须知道"的项目碎片知识追加到 `.kflow/attention.md` 的固定分节里——比如编译特殊 flag、运行前要先起的服务、路径陷阱、命令别名、环境变量约定。触发：用户说"记一笔"、"加到 attention.md"、"项目要 X 才能编译"、"以后每次都得 Y"，或刚踩到一个一句话能讲清的项目特殊设置。 |
开始任何判断或动作前，先检查 .kflow/attention.md：存在就读取；缺 .kflow/ 就提示先运行 k-onboard；只有 attention.md 缺失时，本技能可以先创建固定分节骨架再写入。
k-learn / k-trick / k-decide 产出独立 markdown 文件，通过检索被读到；.kflow/attention.md 是执行类 kflow 技能启动时的短提醒清单。这两类信息归宿不同——本技能专管后者：只把"短、稳、每次动手前都要知道"的提醒追加到 attention 文件里。
不替代沉淀类技能，是补一个之前缺的入口。
判据：长度 + 频次 + 稳定度——三条都过才走 k-note。
| 项 | 进 k-note | 走别处 |
|---|---|---|
| 长度 | 一行能讲清，可附一个文档链接 | 超过两行 / 需要展开背景 → k-learn / k-trick / k-decide |
| 频次 | 几乎每次会话都用得上 | 只在某类具体任务相关 → k-trick |
| 稳定度 | 项目长期生效的硬约束 | 临时绕过 / 短期 workaround → 写到 issue spec 或 feature spec |
| 拍板状态 | 已既成事实（不需要决策记录） | 需要记选型理由 / 拒方案 → k-decide |
✅ 典型该进：
pnpm run gen 生成 schema"compound/2026-xx-xx-trick-prisma-schema.md"docker compose up redis"npm install"bun test，不是 npm test"OPENAI_KEY 走 1Password，别从 .env.example 复制"❌ 典型不该进（会让 attention.md 膨胀）：
判不准就反问用户一句："这条以后是不是每次会话都要让 AI 知道？"答"不一定" → 不是 k-note。
目标文件固定为 .kflow/attention.md。
.kflow/ 不存在 → 本仓库还没接入 kflow，先提示用户运行 k-onboard.kflow/attention.md 不存在 → 视为骨架缺失，先创建最小骨架再写入attention.md 是项目注意事项的短索引，不是详细说明书。跨平台 AI 通过 AGENTS.md（k-onboard 生成）发现它；路由类技能只检查存在，执行类技能读取全文。
为了防止文件膨胀成另一个胖文件，分节写死一组（不在列表里的不开新节）：
## 项目碎片知识
<!-- k-note managed: 用 k-note 维护，新条目按下面分节追加 -->
### 编译与构建
### 运行与本地起服务
### 测试
### 命令与脚本陷阱
### 路径与目录约定
### 环境变量与凭证
### 其他
规则：
<!-- k-note managed --> 是本技能的识别锚——找不到就在文件末尾插入整块结构按上面"判据"表对一遍。任一项不过 → 引导到对应别的技能，本轮结束。
检查 .kflow/attention.md。缺 .kflow/ 就停止并提示先 k-onboard；只缺 attention.md 就创建本技能的固定分节骨架。
.kflow/attention.md，找 <!-- k-note managed --> 锚定位每条格式：
- {一句话事实 + 必要时一句话原因}
例：
- 编译前要先 `pnpm run gen`，否则 schema 类型对不上
- 别用 `npm install`，项目锁文件是 yarn berry 的
- src/legacy/ 是 2023 前的老代码，改之前先和 @ldz 确认
写完用户 review 一句确认就退出。不主动连写多条——一次一条，避免顺手把没拍板的也塞进去。
写入前后都检查有效项目数（- 开头的条目）：
不要替用户决定迁哪条，但要明确拒绝把 attention.md 继续当知识库堆。
不要每次都问。只在两个明确信号触发时推一句：
k-note 一下？以后 AI 每次都能看到。"k-note 记一笔，下次会话直接知道。"用户说"不用了"立刻跳过，不重复推。
AGENTS.md / CLAUDE.md——k-note 只写 attention.md，入口文件由 k-onboard 统一管理