kflow
面向严肃工程的 AI 编码工作流。编排软件生命周期，人在环。
安装
在目标项目根目录执行（skills CLI）：
npx skills add kunbo928/kflow
交互提示选择 Agent 时选 Claude Code。非交互一步到位：
npx skills add kunbo928/kflow -a claude-code --skill '*' -y
装完后新开 Claude Code 会话：
/k-onboard # 首次：生成 .kflow/ 骨架
/k-flow # 日常：路由到正确的子技能
Cursor / Codex
npx skills add kunbo928/kflow -a cursor --skill '*' -y
npx skills add kunbo928/kflow -a codex --skill '*' -y
技能在 .agents/skills/。无 / 斜杠——对话里说 「k-onboard」 / 「k-flow」，或 @k-flow。
更多选项
npx skills add kunbo928/kflow --list # 查看技能列表
npx skills add kunbo928/kflow -g # 全局安装（跨项目可用）
npx skills add . # 本地开发 kflow 源码时
技能总览
25 个技能按软件活动分组，覆盖完整开发闭环。
| 分组 | 技能 | 用途 |
|---|
| 根入口 | k-flow | 统一入口，介绍体系 + 路由到对应子技能 |
| 接入 | k-onboard | 生成 .kflow/ 骨架，释放参考文档 |
| 长效档案 | k-req k-arch | 需求文档 / 架构文档（只记现状） |
| 路线图 | k-roadmap | 大需求的事前规划：模块拆分 → 接口契约 → 子 feature 清单 |
| 讨论 | k-brainstorm | 模糊想法的分诊入口，路由到 design / roadmap / 直接开写 |
| 特性流程 | k-feat → k-feat-design → k-feat-impl → k-feat-accept
k-feat-ff（轻量通道，跳过 design） | 想清楚 → 设计 → 编码 → 验收 |
| 问题流程 | k-issue → k-issue-report → k-issue-analyze → k-issue-fix | 报告 → 分析根因 → 定点修复 |
| 重构流程 | k-refactor k-refactor-ff | 重构主流程 / 轻量通道（beta） |
| 审计 | k-audit | 代码质量审计 |
| 知识沉淀 | k-learn k-trick k-decide | 踩坑记录 / 可复用技巧 / 技术决策 |
| 探索 & 文档 | k-explore k-guide k-libdoc | 定向代码探索 / 开发者指南 / 库参考 |
| 常驻提示 | k-note | 会话级常驻上下文 |
工作流示意
kflow 不是线性流水线，而是分层 + 事件驱动：
══════════════════════════════════════════════════════════════
根入口 · k-flow （任何时候都可调用）
──────────────────────────────────────────────────────────────
介绍体系 / 把开放式诉求路由到对应子技能
══════════════════════════════════════════════════════════════
│
┌───────────────┬───────┴───────┬───────────────┐
▼ ▼ ▼ ▼
══════════════════ ════════════════ ════════════════ ═══════
第 1 层 第 2 层 第 3 层 横切层
长效档案 规划 执行流程 知识沉淀
──────────────────────────────────────────────────────────────
k-req 需求文档 k-roadmap k-feat-* 特性 k-learn
k-arch 架构文档 路线图拆解 k-issue-* 问题 k-trick
（大需求才进） k-refactor 重构 k-decide
k-audit 审计 k-explore
──────────────────────────────────────────────────────────────
│
k-brainstorm（讨论入口 · 可选）
模糊想法分诊后路由到上面各层
══════════════════════════════════════════════════════════════
怎么读：
- 纵向分层，不是严格时序——长效档案持续刷新，规划层只在大需求时进入
- 第 3 层是事件入口：新需求走 feature 流，bug 走 issue 流，腐化走 refactor 流
- 横切层是复利飞轮：任何流程跑完觉得"值得记下来"就触发沉淀，产物被下一次同类工作读到
6 个实体 · 3 个流程
kflow 把软件活动建模成 6 个实体，走 3 条流程。实体回答"项目里有什么"，流程回答"怎么推动它演进"：
- 实体：需求（为什么要有）· 架构（用什么结构实现）· 路线图（接下来怎么走）· 特性（新增能力）· 问题（修复缺陷）· 知识（复利沉淀）
- 流程：特性引入（design → impl → accept）· 问题修改（report → analyze → fix）· 代码重构（scan → design → apply）
运行时结构：.kflow/ 目录
/k-onboard 在项目根生成 .kflow/，所有产物聚合于此：
.kflow/
├── requirements/ # 需求文档
├── architecture/ # 架构文档（总入口 + 子系统）
├── roadmap/ # 路线图（主文档 + items.yaml + 草稿）
├── features/ # 特性流程（design / checklist / acceptance）
├── issues/ # 问题流程（report / analysis / fix-note）
├── refactors/ # 重构流程（beta）
├── compound/ # 知识沉淀（learning / trick / decision / explore）
├── skills/ tools/ reference/ # onboard 释放，跨平台 AI 读取
要点：
requirements/ architecture/ 是长效档案（只记现状），roadmap/ 是规划层，刻意分开features/ issues/ refactors/ 用 YYYY-MM-DD-{slug}/ 一个目录装齐所有相关产物compound/ 是唯一的知识沉淀目录，按 doc_type 区分而非分目录——好搜reference/ 是跨 skill 共享口径，改 k-onboard/reference/ 模板，新项目 onboard 自动带上新版
设计哲学
缘起
日常用 AI 编码工具时发现一个共同问题：没有流程约束，面对复杂工程不知道该用哪个技能、什么时候用。调研了同类工具：
- OpenSpec — 太简单，无复利工程，生成的 Spec 人类没法读
- SuperPowers — 没有流程约束，不知道该用哪个
- Oh-My-OpenAgent — 太重，且哲学上认为「人介入 = 失败」
kflow 的目标是解决严肃工程的软件实现和编码问题，不是造新名词、追热点。
核心区别：编排的目标是谁
主流 AI 编码框架（Superpowers、CCW、Oh-My-OpenAgent 等）在做同一件事：
如何把 Agent 编排得更好。 组队、协作、流水线、自动接力。围绕的实体始终是 Agent。
kflow 走另一个方向：
编排的不是 Agent，而是软件本身的生命周期。 围绕的实体是构成软件的要素——需求、架构决定、特性、bug、历史约束。
