cs-feat-impl
cs-feat-impl
启动必读
开始任何判断或动作前,先读取 .codestable/attention.md;缺失则视为骨架不完整,提示先补齐或运行 cs-onboard,不要回退到外部 AI 入口文件。
到这一步用户已经在方案上签过字了,你的活是把方案变成代码。容易出问题的不是写代码本身,而是实现路上发现方案没覆盖到的情况时怎么办——硬冲下去就把方案当摆设了。下面整套规则就是为了让"停下来"成为默认动作。
共享路径与命名约定看
.codestable/reference/shared-conventions.md第 0 节。
写代码时的三条姿态
具体规则是这三条姿态的落点,理解姿态比记规则重要。
1. 默认写最少的代码
只写当前步骤明确要的东西。不顺手加"以后可能要"的可配置项、抽象层、参数开关、防御性兜底。判据:写完一段觉得"是不是还得加点 X",先问 X 是不是当前用户能感知到的——不是就别加。整体写完一看 200 行其实 50 行能讲清楚 → 重写。多出来的代码不是中性的,是后人维护的负担。
More from liuzhengdongfortest/codestable
cs-feat-design
feature 流程阶段 1——为新功能起草 {slug}-design.md 作为后续实现和验收的唯一输入,拍板后抽出 checklist。触发:用户说"开始设计方案"、"写 design doc"、"准备实现 XX",前提是已知道做什么、为谁、怎么算成功。
670cs-brainstorm
想法还模糊时的讨论入口,做分诊后路由到 feature-design / feature-brainstorm / roadmap。AI 是思考伙伴不是记录员。触发:用户说"有个想法还没想清楚"、"先 brainstorm 一下"、"聊一聊这块"、"方向还在摇摆"。不处理 bug 和重构。
669cs-feat-accept
feature 流程阶段 3——验收闭环:对照 design 核实现 + 回写 architecture / requirement / roadmap,最后产出 {slug}-acceptance.md。触发:用户说"功能写完了验收一下"、"做最后检查"、"准备 merge"、"出验收报告"。前置依赖 cs-feat-impl 完成。
669cs-onboard
把新仓库或有零散文档的仓库接入 CodeStable 体系,两条路径自动判断:空仓库从零搭骨架,已有文档走审计 + 迁移映射。触发:用户说"在这个项目里用 CodeStable"、"搭 CodeStable 结构"、"初始化 CodeStable"、"迁移到 CodeStable"。
667cs-feat
新功能开发的子流程入口,把"加个 X 能力"从想法走到验收闭环。触发:用户说"做新功能"、"加个 X"、"实现 XX"。只做路由,根据已有产物决定走 brainstorm / design / fastforward / implement / acceptance。不处理 bug。
666cs-explore
对仓库做定向代码探索并把"提问→读代码→得结论"沉淀为可检索证据,三种类型 question / module-overview / spike。触发:用户说"先 explore 一下"、"这个仓库里 X 怎么实现"、"快速熟悉这个模块"、"把探索结果存档"。
665