codestable

---

安装

Codex plugin marketplace：

codex plugin marketplace add liuzhengdongfortest/CodeStable
codex plugin add codestable@codestable

Claude plugin marketplace：

/plugin marketplace add liuzhengdongfortest/CodeStable
/plugin install codestable@codestable

skills CLI：

npx skills@latest add liuzhengdongfortest/CodeStable

如果你的 skills CLI 没有通过 marketplace catalog 发现插件实体，可用深扫兜底：

npx skills@latest add liuzhengdongfortest/CodeStable --full-depth

CodeStable 插件只打包 plugins/codestable/skills/ 下的 cs / cs-* skills；仓库根目录不再保留独立 skill 目录。

升级

发布新版本后，先看 CHANGELOG.md 确认版本变化，再按你的安装入口刷新。

Codex plugin marketplace：

codex plugin marketplace upgrade codestable
codex plugin add codestable@codestable

Codex 当前 CLI 没有单独的 plugin update 子命令；marketplace upgrade 会刷新 Git marketplace snapshot，plugin add 从刷新后的 snapshot 安装当前版本。

Claude plugin marketplace：

/plugin marketplace update
/plugin update codestable@codestable

Claude 更新后需要重启 Claude Code 才会应用新版插件。

skills CLI：

npx skills@latest update

如果旧安装器没有记录来源，重新执行上面的 npx skills@latest add liuzhengdongfortest/CodeStable 安装命令即可。

只需要一键，开始工作：

/cs-onboard

之后日常使用时，不知道该用哪个技能就喊根入口：

/cs

cs 会读你的诉求，告诉你这次该走哪个 cs-xxx。

---

缘起

我在开发一套新的 Harness Agent（MA），一开始当然是 VibeCoding——我只写设计和需求，代码由 AI 来改。这样支撑了大部分特性的开发。直到有一天 Codex 反复解决不了一个我认为比较简单的问题，并且反复在同一个地方犯错。我就知道项目需要一套工作流来维持它继续进行了。

我调研了 OpenSpec、SuperPowers、Oh-My-OpenAgent 这一类工具，没一个用着顺手：

• OpenSpec 太简单，没有复利工程，生成的 Spec 抽象到人类没法读
• SuperPowers 没有流程约束，不知道该用哪个
• Oh-My-OpenAgent 太重，且哲学上认为"人介入 = 失败"

CodeStable 的目标是解决严肃工程的软件实现和编码问题，不是造一个新名词、追求热点。

---

与其他框架的核心区别：编排的目标是谁

我看了一圈现在主流的 AI 编码框架——Superpowers、CCW、Oh-My-OpenAgent 等等——它们其实都在做同一件事：

如何把 Agent 编排得更好。 让它们组队、协作、头脑风暴、跑流水线、自动接力。围绕的实体始终是 Agent。

CodeStable 走的是另一个方向：

编排的不是 Agent，而是软件本身的生命周期。 围绕的实体是构成软件的要素——每一个需求、每一个架构决定、每一个特性、每一个 bug、每一条历史里留下来的约束。

	Agent 编排派	CodeStable
核心实体	Agent / Role / Team	Requirement / Architecture / Feature / Issue / Decision
主线问题	Agent 之间怎么分工、传递、协调？	软件的需求、约束、决策怎么被记下来、被检索、被复用？
状态存在哪	Agent 的 session / 消息总线 / 队列	项目里的 .codestable/ 文件树（人和 AI 都能读）
解决的痛点	单 Agent 能力不够，需要协同放大	软件复杂度膨胀撑破上下文、隐知识丢失、需求漂移
对人的定位	人少介入越好，理想是全自动	人在环 —— 程序员对整体把控负责，AI 是高效的执行体

这两个方向没有谁对谁错。

如果你的任务是"用 AI 跑一个端到端的自动化产线"、"让多个 Agent 互相讨论方案"，Agent 编排派会更顺手。

如果你的任务是"维护一个会跨年迭代的严肃软件"、"让今天写下的需求和决策三个月后还能被准确召回"——那 CodeStable 这套以软件要素为中心的建模会更合适。

我做 CodeStable 是因为我相信：软件工程的混乱本质上不是 Agent 不够强，而是要素没被组织好。Agent 再强，也写不了一个把需求、架构、历史决策全丢失的项目。

---

设计：实体 + 流程

CodeStable 顺着软件编码的真实流程来设计，把开发活动建模成一组实体和流程。

实体

实体	英文	干什么
需求	requirements	原始用户故事 + 领域术语（CONTEXT.md）+ 架构决策（ADR）。最终的逃生通道——代码烂成一坨屎时，可以摒弃所有代码、让 AI 重新生成
路线图	roadmap	"我想要一个权限校验系统"——直接塞 feature AI 接不住，先拆成路线图分步推进；cs-roadmap-review 做独立规划审查，cs-roadmap-impl-goal 把大需求一路推到 /goal 指令
目标	goals	限定起点和终点，写起点报告后让 AI 自主迭代实现/验证，完成前用 subagent 做功能验收
特性	feature	实际落地的工程执行过程，人与 AI 共同协作，对 design / 实现 / 验收负责；每个阶段之间有显式的 Gate 卡口（design-review / code-review / qa）
问题	issue	开发完成后的 BUG 单子，AI 和人一同解决
重构	refactor	代码腐化时的整理过程（beta）
知识	compound	复利工程的知识库，沉淀踩过的坑、好做法、调研结论（cs-keep）；碎片化项目约定写入 attention.md（cs-note）

流程

流程	关键技能链	说明
特性引入	cs-feat → cs-feat-design → cs-feat-design-review (Gate) → cs-feat-impl → cs-code-review (Gate) → cs-feat-qa (Gate) → cs-feat-accept	想清楚 → 方案独立审查 → 逐步编码 → 代码审查 → QA → 验收闭环
大需求端到端	cs-roadmap → cs-roadmap-review (Gate) → 用户确认 → cs-roadmap-impl-goal → /goal 指令	大需求拆成路线图 → 独立规划审查 → 逐个 feature 自动推进至验收
目标达成	cs-goal	限定起点/终点 → grill 写起点报告 → 自主实现/验证/迭代 → subagent 功能验收
问题修改	cs-issue-report → cs-issue-analyze → cs-issue-fix → cs-code-review (Gate)	跟 AI 说哪里有问题 → 分析根因 → 定点修复 → 合并前独立评审
代码重构	cs-refactor (beta) → cs-code-review (Gate)	软件架构腐化不是一蹴而就的。AI 辅助重构，但终归是人在重构——还在迭代中，欢迎赐教