AI development workflow skills

从需求到提交,
每步可验证。

dev-skills 为 Claude Code 与 Codex 提供 11 个工程流程 skill 和精简 always-on 团队规则,用轻量 SDD 让设计上下文、需求拷问、spec、plan、实现、验证、评审与收尾都有清晰边界和可复核结果。

codex cli Workflow
$ codex
> 做一个登录页,别直接开写,先帮我收敛一下

收到。我先把需求落成 spec:
- 目标:谁在什么产品场景里登录
- 范围:登录方式、错误态、移动端、无障碍
- 不做:注册、找回密码、SSO,除非你确认

如果复杂度升高,我会再补 plan / ADR。实现、验证和 review 都会回到这份 artifact 对齐。

Skill library

按你现在要做的事,选择对应的 skill。

日常只要回答“现在卡在哪一步”。dev-skills 会把需求、方案、实现、修复、验证和提交收进同一条 SDD 工程流程。

不确定下一步

让 agent 先判断路径

当你只知道目标,但不知道该先写需求、计划还是直接修复时,从这里开始。

  • dev-auto
需求和方案

先把要做什么说清

优先用 dev-grill-docs 对齐需求、边界和验收条件,生成 spec artifact;dev-spec 只作为 spec-only 兼容入口,复杂或高风险改动再补 plan。

  • dev-grill-docs
  • dev-spec spec-only alias
  • dev-plan
  • dev-design-context
实现和修复

写代码前先锁住行为

新功能走 TDD;问题修复从复现和 root cause 开始,避免只修表面症状。

  • dev-tdd
  • dev-fix
完成和提交

先验证,再 review

完成声明必须有证据;提交前检查 diff。只需要 message 时再单独使用 commit writer。

  • dev-verify
  • dev-code-review
  • dev-commit-writer
  • dev-finish

Articles

用文章解释 dev-skills 背后的工程判断。

AI 写代码越快,越要先给它装上刹车 Latest · CSDN 专栏

AI 写代码越快,越要先给它装上刹车

为什么 AI 写完代码后,不能直接 commit Commit review

为什么 AI 写完代码后,不能直接 commit

别被已修复骗了:AI 修 bug 最该追问这一句 Root cause

别被“已修复”骗了:AI 修 bug 最该追问这一句

从需求到 commit:一套更稳的 AI 编程工作流 Workflow

从需求到 commit:一套更稳的 AI 编程工作流

AI 越会写代码,越不能让它直接写到 commit Evidence chain

AI 越会写代码,越不能让它直接写到 commit

AI 编程最危险的瞬间:它还没听懂,就已经开始写了 Requirement intake

AI 编程最危险的瞬间:它还没听懂,就已经开始写了

Install and upgrade

Claude Code 和 Codex 分开安装。

选择你的入口,复制对应命令。升级 skill 不会自动覆盖项目里的短版团队规则模板;详细政策可参考或复制 `docs/team-policy.md`。

Claude Code · Install

/plugin marketplace add https://github.com/Jason-chen-coder/dev-skills
/plugin install dev-skills

首次安装后,如需团队规则,复制 `CLAUDE.md.template` 到项目根 `CLAUDE.md`;详细政策参考 `docs/team-policy.md`。

Main agent

定阶段

理解目标、判断当前卡点,决定该走 spec、plan、实现、修复还是验证。

Spec / Plan

收敛

模糊需求先落 spec;复杂或高风险改动再补 plan / ADR。

Build / Fix

执行

实现或修复时锁住行为,只按当前 artifact 和范围改代码。

Verify / Review

把关

完成前跑验证,提交前检查 diff、风险和夹带改动。

Runtime preview

看关键节点在 Codex CLI 里怎么跑。

只保留高频 workflow 节点。切换 tab 查看代表性输入和输出;开启减少动效时直接显示完整文本。

codex cli
$ codex
> 用 dev-auto 帮我串起来,下一步该做什么?
Dev Auto
━━━ Dev Auto ━━━
路径   : feature
复杂度 : moderate
下一步
  $ dev-grill-docs user-export
为什么:先把模糊需求拆成可验证 spec。

Workflow

纵向流程图,三条分支最后汇合到验证、评审和提交。

Feature path

  1. dev-design-context optionalUI 工作先沉淀设计上下文
  2. dev-grill-docs拷问需求,生成 spec,按需沉淀 CONTEXT / ADR
  3. dev-plan optional复杂 / 高风险改动先出 plan / ADR
  4. dev-tddred -> green -> refactor
  5. dev-verify完成前证据门禁
  6. dev-code-review提交前 5 轴检查
  7. dev-commit-writer optional需要时生成 commit message
  8. git commitREADY 后提交
  9. dev-finish分支 / PR / 收尾决策

Bug path

  1. dev-fix复现、假设、定位 root cause
  2. dev-verify完成前证据门禁
  3. dev-code-review确认无回归和夹带改动
  4. dev-commit-writer optional需要时生成 commit message
  5. git commit记录修复上下文
  6. dev-finish分支 / PR / 收尾决策

Simple hotfix

  1. dev-tdd直接用测试锁住小改动
  2. dev-verify完成前证据门禁
  3. dev-code-review提交前检查风险
  4. git commitREADY 后提交
  5. dev-finish optional需要分支收尾时执行

FAQ

常见问题。

Claude Code 和 Codex 为什么安装方式不一样?

Claude Code 使用 `.claude-plugin/` manifest;Codex 当前兼容方式是复制 `skills/*` 到 `$CODEX_HOME/skills`。

升级会覆盖我的 `CLAUDE.md` 或 `AGENTS.md` 吗?

不会。skill 升级只更新 skill 文件,短版团队规则模板需要人工对比后同步;详细 policy 文档也建议按团队实际情况复制或改写。

`docs/why-dev-baseline.md` 和 `docs/team-policy.md` 分别解决什么?

前者解释四条 baseline 背后的失败模式,防止规则变口号;后者放详细团队治理,避免把 always-on 模板写得过长。

什么时候用 `dev-auto`?

当你不知道下一步跑哪个 skill,或者需要从失败状态恢复时使用。它只建议,不调起其他 skill。

准备 commit 时为什么默认走 `dev-code-review`?

团队策略是 commit 前先 review。`dev-commit-writer` 只用于用户明确表示跳过 review 且只要 message 的场景。