Menu
kflow 工作流根入口，介绍体系全貌并把诉求路由到对应 k-* 子技能。触发：用户只输入 `k-flow`、说"介绍一下 .kflow"、"该用哪个技能"、"不知道用哪个"，或诉求还很开放未收敛。本技能只做路由不做事。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
维护 `.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-flow |
| description | kflow 工作流根入口，介绍体系全貌并把诉求路由到对应 k-* 子技能。触发：用户只输入 `k-flow`、说"介绍一下 .kflow"、"该用哪个技能"、"不知道用哪个"，或诉求还很开放未收敛。本技能只做路由不做事。 |
开始任何判断或动作前，先检查 .kflow/attention.md 是否存在；缺失则视为骨架不完整，提示先补齐或运行 k-onboard。本技能只路由，默认不读 attention 全文。
k-flow 是 kflow 工作流家族的统一入口。用户开口大概率不会指名某个 k-xxx——可能只说"我想加个权限校验"、"这个地方有 bug"、"介绍下 .kflow"，甚至只发一个 k-flow。本技能负责接住开放式输入，弄清意图，路由到对的子技能。
两件事，仅此两件：
k-*，并简单说明为什么本技能不做事：不写 spec / 不读写 .kflow/ 下内容产物 / 不替子技能跑流程。产出只有"建议触发哪个子技能"。
回应前每次都做（几个 tool 调用就够）：
Glob .kflow/ 看顶层目录.kflow/attention.md 存在即可；Glob 一下 features/ issues/ roadmap/ 看进行中的工作（拿目录名就够，不逐份读）k-onboardsystem-overview.md 只在用户明确要"详细介绍 / 体系全貌 / 深入解释"时读取；普通路由和简短介绍用本文件的速读图即可，避免每次入口调用都加载完整总览。
扫完才回应。让用户感觉你心里有数。
kflow 把开发活动建模成 7 个实体 + 3 个流程，所有产物聚在 .kflow/：
.kflow/
├── requirements/ 需求实体（"为什么要有这个能力"，只记现状）
├── architecture/ 架构实体（"系统现在长什么样"，只记现状）
├── roadmap/ 规划层（"接下来怎么做这块大需求 + 模块切 + 接口定"）
├── features/ 新增能力 spec 聚合根（design / impl / accept）
├── issues/ 修 bug spec 聚合根（report / analyze / fix）
├── refactors/ 重构 spec 聚合根（beta）
├── audits/ 审计实体（主动扫描发现清单，不定修）
└── compound/ 知识沉淀（learning / trick / decision / explore）
三条流程：
k-feat-design → k-feat-impl → k-feat-accept（想法模糊先 k-brainstorm 分诊）k-issue-report → k-issue-analyze → k-issue-fixk-refactor / k-refactor-ff横切：流程跑完发现"值得记下来" → k-learn / k-trick / k-decide / k-explore 沉淀到 compound/。
核心理念：编排的是软件本身的生命周期（需求、架构、特性、bug、决策），不是 Agent。人在环——程序员对整体把控负责，AI 是高效执行体。
项目已 onboard 的话更详细总览看
.kflow/reference/system-overview.md。
匹配用户的话到表里某行，告诉用户："你这个诉求建议走 k-xxx，因为 {一句话理由}"。
| 用户说什么 / 想做什么 | 路由到 |
|---|---|
仓库还没有 .kflow/ | 先 k-onboard——所有其他 k-* 都依赖这个目录 |
| 想法还模糊 / "有想法没想清楚" / "先聊聊" / "不知道是不是新功能" / "grill me" | k-brainstorm（分诊后路由到 design / feature-brainstorm 落盘 / roadmap；需要时进入逐支澄清的深挖追问模式） |
| 新功能 / "加个 X" / "实现 XX" | k-feat（路由 design / ff / impl / accept） |
| BUG / 异常 / 报错 / "这里不对" / "文档错了" | k-issue（路由 report / analyze / fix） |
| 代码优化 / 重构 / 重写（行为不变） | k-refactor / k-refactor-ff |
| 摸代码 / "X 是怎么实现的" / 提问调研 | k-explore |
| 审查系统 / 扫描 bug / 审计代码 / "有哪些问题" / "哪里可以优化" | k-audit（主动扫描发现，只列清单不定修） |
| 补 / 更新需求文档 | k-req |
| 补 / 更新 / 检查架构文档 / "刷新架构 doc" / "做架构体检" | k-arch |
| 大需求拆解 / "我想要一个 X 系统" / 排期规划 / 模块拆分 + 接口契约 | k-roadmap |
| 技术选型 / 长期约束 / 编码规约 | k-decide |
| 踩坑回顾 / 经验总结 / "值得记下来" | k-learn |
| 可复用编程模式 / 库用法 / "以后做 X 就该这样" | k-trick |
| 一两行的项目注意事项 / 编译特殊设置 / 命令陷阱 / "记到 attention.md" | k-note |
| 开发者指南 / 用户指南 | k-guide |
| 库 API 参考 | k-libdoc |
| 用户在 feature / issue 流程中间问"下一步" | 路由到对应入口（k-feat / k-issue），让该入口判断当前阶段 |
判不出来 / 太抽象："听起来像 {猜测}，但你描述里 {缺什么}。是 {选项 A} 还是 {选项 B}？" 让用户选不要硬猜。
任何 k-* 流程但 .kflow/ 不存在 → 说明这一点建议先 k-onboard。不要直接路由到 k-feat / k-issue——它们的 SKILL.md 都假设 .kflow/ 已存在。
"我想要一个权限系统 / 通知中心 / SSO 接入"这类一眼看出做不完一个 feature 的诉求 → 不路由到 k-feat，路由到 k-brainstorm（大概率判 case 3 → k-roadmap）或直接 k-roadmap。理由：直接起 feature 会变成巨型 design 塞不下。
先问这是 bug 修复（X 现在表现错了）还是 需求变更（X 现在表现没错，但策略变了）：
k-issuek-req 改需求 doc + 之后 k-feat 跑实现扫描看到 features/ 或 issues/ 下已有相关目录 → 提一句"看到 features/2026-04-22-xxx/ 已经存在，是接着做这个吗？" 让用户确认续作还是开新的。
判别口诀：
k-learnk-trickk-decidek-explorek-note（写到 .kflow/attention.md）判不出问用户："这个你想记成 {踩坑回顾 / 复用处方 / 长期规约 / 调研存档 / 常驻提示} 哪一种？"
按这个顺序讲，不一次倒出全部：
收住，别把所有子技能细节讲一遍。用户问到具体的再展开。
本技能没有"落盘"。退出条件一条：
k-* 子技能（或确认用户只是来了解，没要做事）输出形如：
你这个诉求建议走
k-xxx——{一句话理由}。 触发后它会 {简述会发生什么：会先扫已有 spec / 会让你先描述 / 会进入分诊 / ...}。 现在切到k-xxx吗？
.kflow/ 下的内容产物——这些是子技能的事.kflow/reference/system-overview.md 才是权威完整版k-onboard——仓库没接入就先 onboard