Menü
把可复用的编程模式 / 库用法 / 技术技巧整理成处方性参考库，三种类型 pattern / library / technique。触发：用户说"记录一个技巧"、"这个用法值得记"、"tricks"、"记录库用法"，或 design / analyze 阶段发现值得沉淀的技巧时推送。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | k-trick |
| description | 把可复用的编程模式 / 库用法 / 技术技巧整理成处方性参考库，三种类型 pattern / library / technique。触发：用户说"记录一个技巧"、"这个用法值得记"、"tricks"、"记录库用法"，或 design / analyze 阶段发现值得沉淀的技巧时推送。 |
开始任何判断或动作前，先读取 .kflow/attention.md；缺失则视为骨架不完整，提示先补齐或运行 k-onboard。
k-trick 是面向问题的处方性参考库，回答：要做 X，经过验证的正确做法是什么？ 不需要触发事件，任何时候发现值得沉淀的模式或用法都可以直接写。
典型内容：某个设计模式在这个项目的标准写法 / 某个库的核心 API 用法 + 已知坑 / 某类操作的命令配方。
共享路径与命名约定看
.kflow/reference/shared-paths.md。产物写入.kflow/compound/，命名YYYY-MM-DD-trick-{slug}.md，frontmatter 带doc_type: trick。
frontmatter 的 type 字段：
| 类型 | 适用情境 | 示例 |
|---|---|---|
pattern | 设计模式 / 架构模式 / 编程惯用法 | "用 Repository 模式隔离数据访问层"、"用 Builder 构造复杂配置" |
library | 某个库 / 框架的用法 / 配置方式 / 常见坑 | "Prisma 事务的正确写法"、"Pinia store 的 action 错误处理" |
technique | 具体操作技巧 / 工具用法 / 命令配方 | "用 jq 从 JSON 提取嵌套字段"、"git bisect 定位引入 bug 的提交" |
查询用途：查"代码该怎么组织"→ pattern；"库 / 框架某 API 怎么用"→ library；"这类操作怎么做"→ technique。分不清选最接近的，type 不影响搜索可用性。
frontmatter / 正文模板 / 长示例见同目录 reference.md。流程约束：
type 只允许 pattern / library / technique最多两个问题：
typetopic用户描述已清楚就跳过直接进 Phase 1.5。
按 shared-archive.md 查重规则：
--query 查一遍 topic，命中相近时把候选列给用户更新流程：读旧文档 → 和用户对齐改哪几节 → 跳过 Phase 2 完整代码调查（被改的节涉及的代码要重读确认未失效）→ 起草 diff 给用户 review → 写回 + updated: YYYY-MM-DD。
技巧通过代码体现——用户不贴代码不等于不需要看代码。AI 必须主动调查代码仓。
为什么必做：没看代码就写出的"技巧"会停留在抽象层面，下次有人按这条找代码会找不到对应的真实例子，反而失去信心。
library 类找 import 和调用处；pattern 类找结构性代码（接口定义 / 类继承 / 组合）；technique 类找操作步骤对应的脚本或配置补充：用户附带文件 → 仍要搜一遍代码仓确认有没有其他使用点；搜索结果为空 → 可继续但必须在文档注明；找到的代码和用户描述矛盾 → 主动跟用户确认。
结合 Phase 2 找到的代码提问——不问用户已经能在代码看到的东西：
用户说"没什么"或"跳过"就跳过，宁缺节也不用空话填充。
AI 一次性起草完整文档（YAML frontmatter + 正文）。示例代码优先用 Phase 2 找到的真实项目代码（可精简），别凭空编写。展示给用户。
compound/YYYY-MM-DD-trick-{slug}.md，frontmatter 带 doc_type: trickupdated: 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=trick --filter type=library --filter framework~={库名}
# 按技术栈浏览
python .kflow/tools/search-yaml.py --dir .kflow/compound --filter doc_type=trick --filter language=typescript --filter status=active
# 归档后查重叠
python .kflow/tools/search-yaml.py --dir .kflow/compound --filter doc_type=trick --query "{关键词}" --json
归档类共享规则见
shared-archive.md。本技能特有：
doc_type: trick维护 `.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"、"按分析修"、"动手改代码"。只动方案声明的文件，不顺手优化。