Menü
把已拍板的技术选型、架构决定、长期约束、编码规约记成永久性决策文档（tech-stack / architecture / constraint / convention 四种）。触发：用户说"记录决定"、"归档技术选型"、"ADR"、"记录这条约束"、"把规约写下来"，或 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-decide |
| description | 把已拍板的技术选型、架构决定、长期约束、编码规约记成永久性决策文档（tech-stack / architecture / constraint / convention 四种）。触发：用户说"记录决定"、"归档技术选型"、"ADR"、"记录这条约束"、"把规约写下来"，或 design / analyze 后做出重要选择。只归档已拍板的，讨论中的不归档。 |
开始任何判断或动作前，先读取 .kflow/attention.md；缺失则视为骨架不完整，提示先补齐或运行 k-onboard。
项目里"有意做出的选择"——技术选型 / 架构决定 / 长期约束 / 编码规约——特别容易丢失。它不会触发报错、没人会注意到它消失，但消失代价很具体：
本工作流让每一条重要的"已经决定了"都有完整存档：是什么、为什么、考虑过什么替代方案、后果是什么。
共享路径与命名约定看
.kflow/reference/shared-paths.md。产物写入.kflow/compound/，命名YYYY-MM-DD-decision-{slug}.md，frontmatter 带doc_type: decision。
每条归属四类之一（frontmatter 的 category 字段标注）：
| 类型 | 适用情境 | 示例 |
|---|---|---|
tech-stack | 技术 / 库 / 框架的选型 | "用 Vite 而非 Webpack"、"状态管理用 Pinia" |
architecture | 系统结构、模块划分、数据流方向 | "前后端完全分离"、"事件总线只在顶层使用" |
constraint | 硬约束——某些事情不允许做 | "不引入 jQuery"、"所有 API 调用必须通过统一的 http 模块" |
convention | 软规约——某些事情统一这样做 | "组件命名用 PascalCase"、"副作用集中在 composables/" |
查询时各有用途：查"用什么工具"→ tech-stack；"系统怎么组织"→ architecture；"这里为什么不能改"→ constraint；"统一做法是什么"→ convention。
frontmatter / 正文模板 / 示例见同目录 reference.md。本技能流程约束：
category 只允许 tech-stack / architecture / constraint / conventionstatus 只允许 active / superseded / deprecated用一个问题确认关键信息不要给用户大表格：
category按 shared-archive.md 查重规则执行：
update vs supersede：结论变了 → supersede；结论没变只补充 → update。拿不准问用户。
用户可随时说"没什么"跳过：
AI 根据对话起草完整文档（YAML frontmatter + 所有正文节）。一次性展示给用户 review，别逐节展示逐节问——拿到完整版才能判断节之间逻辑是否自洽。
.kflow/compound/YYYY-MM-DD-decision-{slug}.md，frontmatter 顶部带 doc_type: decisionupdated: YYYY-MM-DDshared-archive.md supersede 规则处理；旧文档 status: superseded + superseded-by写完检查两项有则提示用户（不自作主张改文件）：
architecture/ARCHITECTURE.md 的"关键架构决定"节是否应引用——architecture 或 tech-stack 通常应该.kflow/attention.md 是否应追加一句启动必读摘要——constraint 或 convention 通常应该完整语法见
.kflow/reference/tools.md。
# 列出所有当前有效的决策
python .kflow/tools/search-yaml.py --dir .kflow/compound --filter doc_type=decision --filter status=active
# 按类型 + 状态组合
python .kflow/tools/search-yaml.py --dir .kflow/compound --filter doc_type=decision --filter category=constraint --filter status=active
# 归档后查重叠
python .kflow/tools/search-yaml.py --dir .kflow/compound --filter doc_type=decision --query "{关键词}" --json
归档类工作流共享守护规则（只增不删 / 宁缺毋滥 / 不替用户写 / 可发现性 / 归档后查重叠）见
shared-archive.md。本技能特有：
superseded-by + 正文顶部 **[已取代]** 见 {新文档 slug}k-notedoc_type: decision维护 `.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"、"按分析修"、"动手改代码"。只动方案声明的文件，不顺手优化。