k-flow

星标10

分支1

更新时间2026年7月3日 15:24

kflow 工作流根入口，介绍体系全貌并把诉求路由到对应 k-* 子技能。触发：用户只输入 `k-flow`、说"介绍一下 .kflow"、"该用哪个技能"、"不知道用哪个"，或诉求还很开放未收敛。本技能只做路由不做事。

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

来源

kunbo928

kunbo928/kflow

打开 GitHub 仓库查看创作者相关仓库

下载

相关职业SOC

基于 SOC 职业分类

软件开发工程师计算机与数学类职业·SOC 15-1252

SKILL.md

readonly

同仓库更多 Skills

同仓库

k-arch

kunbo928/kflow

维护 `.kflow/architecture/` 这份只记现状的系统地图，三种模式 update / check / backfill。触发：用户说"刷新 architecture"、"做架构检查"、"补这个模块的架构文档"、"方案和代码对得上吗"，或 feature 阶段需要先做架构动作。不写未来规划（走 k-roadmap）。

2026-07-0410

k-feat-accept

kunbo928/kflow

feature 流程阶段 3——验收闭环：对照 design 核实现 + 回写 architecture / requirement / roadmap，最后产出 {slug}-acceptance.md。触发：用户说"功能写完了验收一下"、"做最后检查"、"准备 merge"、"出验收报告"。前置依赖 k-feat-impl 完成。

2026-07-0410

k-feat-design

kunbo928/kflow

feature 流程阶段 1——为新功能起草 {slug}-design.md 作为后续实现和验收的唯一输入，拍板后抽出 checklist。触发：用户说"开始设计方案"、"写 design doc"、"准备实现 XX"，前提是已知道做什么、为谁、怎么算成功。

2026-07-0410

k-feat-impl

kunbo928/kflow

feature 流程阶段 2——按 {slug}-checklist.yaml 里 design 切好的 paradigm 维度 steps 推进，每步具体改哪个文件由 implement 自决，写完用统一格式汇报。触发：用户说"方案确认了开始实现"、"按方案写代码"、"开工"。前提是 design 已 approved 且有 checklist。遇到方案外情况要回方案谈不要硬冲。

2026-07-0410

k-issue-analyze

kunbo928/kflow

issue 流程阶段 2——读 report + 读代码定位根因、评估风险，给用户 2-3 个修复方案让 TA 拍板。这一步不改代码。触发：用户说"分析这个 bug"、"找根因"、"定位问题"，且已有 {slug}-report.md。

2026-07-0410

k-issue-fix

kunbo928/kflow

issue 流程阶段 3——按已确认根因和方案定点修复、验证、写 {slug}-fix-note.md 落档。两个入口：标准路径从 analyze 来，快速通道从 report 直接来。触发：用户说"开始修 bug"、"按分析修"、"动手改代码"。只动方案声明的文件，不顺手优化。

2026-07-0410

name	k-flow
description	kflow 工作流根入口，介绍体系全貌并把诉求路由到对应 k-* 子技能。触发：用户只输入 `k-flow`、说"介绍一下 .kflow"、"该用哪个技能"、"不知道用哪个"，或诉求还很开放未收敛。本技能只做路由不做事。

k-flow

启动必读

开始任何判断或动作前，先检查 .kflow/attention.md 是否存在；缺失则视为骨架不完整，提示先补齐或运行 k-onboard。本技能只路由，默认不读 attention 全文。

k-flow 是 kflow 工作流家族的统一入口。用户开口大概率不会指名某个 k-xxx——可能只说"我想加个权限校验"、"这个地方有 bug"、"介绍下 .kflow"，甚至只发一个 k-flow。本技能负责接住开放式输入，弄清意图，路由到对的子技能。

两件事，仅此两件：

用户带具体诉求 → 匹配场景路由表，告诉用户该触发哪个 k-*，并简单说明为什么
用户想了解体系 / 说不清想做什么 → 给精简体系速读 + 让用户挑或描述更具体的诉求

本技能不做事：不写 spec / 不读写 .kflow/ 下内容产物 / 不替子技能跑流程。产出只有"建议触发哪个子技能"。

收到调用先做的扫描

回应前每次都做（几个 tool 调用就够）：

看仓库有没有接入 kflow——Glob .kflow/ 看顶层目录
存在——确认 .kflow/attention.md 存在即可；Glob 一下 features/ issues/ roadmap/ 看进行中的工作（拿目录名就够，不逐份读）
不存在——后面提示用户先走 k-onboard
看用户原话——开放式还是带具体诉求？带诉求匹配路由表，没诉求给体系介绍

system-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 分诊）
修 bug：k-issue-report → k-issue-analyze → k-issue-fix
重构（beta）：k-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/ 已存在。

大需求被误当成 feature

"我想要一个权限系统 / 通知中心 / SSO 接入"这类一眼看出做不完一个 feature 的诉求 → 不路由到 k-feat，路由到 k-brainstorm（大概率判 case 3 → k-roadmap）或直接 k-roadmap。理由：直接起 feature 会变成巨型 design 塞不下。

"改一下 X" 但 X 是已有功能

先问这是 bug 修复（X 现在表现错了）还是 需求变更（X 现在表现没错，但策略变了）：

bug → k-issue
需求变更 → k-req 改需求 doc + 之后 k-feat 跑实现

进行中的工作

扫描看到 features/ 或 issues/ 下已有相关目录 → 提一句"看到 features/2026-04-22-xxx/ 已经存在，是接着做这个吗？" 让用户确认续作还是开新的。

沉淀类技能的细分

判别口诀：

回顾"做 X 时踩了 Y" → k-learn
处方"以后做 X 就这样做" → k-trick
规定"全项目今后都按 X 来" → k-decide
调查"X 现在是什么样" → k-explore
一两行常驻提示"kflow 技能每次启动都得知道 X" → k-note（写到 .kflow/attention.md）

判不出问用户："这个你想记成 {踩坑回顾 / 复用处方 / 长期规约 / 调研存档 / 常驻提示} 哪一种？"

介绍模式（用户只说想了解 / 不知道做什么）

按这个顺序讲，不一次倒出全部：

一句话：kflow 是面向严肃工程的 AI 编码工作流，编排软件生命周期而不是 Agent
6 实体 + 3 流程的速读图
问用户"你现在最想从哪儿开始？"，给三个引子：
- "我有个新功能想做" → k-feat
- "代码里有个 bug" → k-issue
- "项目还没接入 kflow" → k-onboard

收住，别把所有子技能细节讲一遍。用户问到具体的再展开。

退出

本技能没有"落盘"。退出条件一条：

已告诉用户下一步触发哪个具体的 k-* 子技能（或确认用户只是来了解，没要做事）

输出形如：

你这个诉求建议走 k-xxx——{一句话理由}。触发后它会 {简述会发生什么：会先扫已有 spec / 会让你先描述 / 会进入分诊 / ...}。现在切到 k-xxx 吗？

不做的事

不读写 .kflow/ 下的内容产物——这些是子技能的事
不替子技能做决策——不在本技能做 brainstorm 分诊，不判 k-arch 走哪个模式
不一次推荐多个技能——每次只指一条路；两个独立诉求分两轮
不重复体系总览细节——.kflow/reference/system-overview.md 才是权威完整版
不绕过 k-onboard——仓库没接入就先 onboard