Dev Auto

Dev Auto

指路,不替用户跑。dev-auto 是 dev-skills 工具链的入口推荐器 —— 接需求 / 接「下一步该做什么」的问题,只输出建议,绝不调起其他 skill,绝不写代码,绝不产出 artifact。

它服务的是「我有个需求,该怎么走完整流程」「UI 工作要不要先沉淀设计上下文」「我跑完 X 了,该跑什么」「X skill 给我返回 BLOCK / REJECT,我该回哪一步」这几类场景。

在 SDD 视角下,dev-auto 只做阶段导航:读取 .design-context.md 和 .claude/artifacts/{designs,plans,fixes}/ 的存在性 / status,推荐下一步。它不生成 spec,不更新 plan,不替用户选择 artifact slug,也不自动启动其他 skill。

Trigger routing

Use this skill only when the user explicitly wants end-to-end guided workflow through the dev-skills toolchain.

Trigger phrases include:

• 用 dev-auto
• 帮我串起来
• 从需求到 commit
• 完整跑
• end to end
• 走完整流程
• 下一步该做什么
• what's next

Do not trigger this skill when the user asks for a specific skill directly, such as 帮我设计, 修个 bug, or commit review; route those to the corresponding skill.

Optional arguments:

• [slug]: specify which feature or bug when multiple items are in flight
• --status [slug]: detect only the current phase
• --next [slug]: output only the next command
• --recover [slug]: recover after a failed or blocked skill result

Step 0 — Load baseline

执行前先加载 references/dev-baseline.md。不假设、最小代码、外科手术式改动、可验证成功标准 全程生效。

baseline 与本 skill 的关联:

• 不假设 —— 路径(feature / bug / hotfix)和复杂度模糊时,列选项让用户选,不替用户拍板。
• 最小代码 —— dev-auto 自己也是最小流程:不深读 artifacts、不维护 state file、不产出 doc。每次调用都从仓库现状现扫现答。

Step 1 — 选模式

按 $ARGUMENTS(所有模式都可选 [slug] 后缀,例 dev-auto --status user-export):

slug 处理:

• 若 $ARGUMENTS 显式给了 slug → 用它
• 若没给 + 仓库只有 1 个 in-flight 项目(designs/plans/fixes 加起来只有 1 个文件)→ 默认用那一个
• 若没给 + 多个 in-flight → 回问:「我看到这些 in-flight: [...],你这次指哪个 slug?」
• 若没给 + 0 个 in-flight(Phase 0,新需求)→ 走默认模式 Step 2 起,Step 3 propose slug 让用户确认(见下)

Step 2 — 分类请求(默认模式)

读用户原话,判断两个维度:

路径(path)

unclear 时列选项问用户(不假设):

你的需求路径不确定,请选一种:
  (a) 新功能 / 增强(走 dev-grill-docs → 可选 dev-plan → dev-tdd → dev-verify → dev-code-review)
  (b) 修 bug(走 dev-fix → dev-verify → dev-code-review)
  (c) Hotfix 紧急(跳过 spec/plan,仍过 dev-tdd → dev-verify → dev-code-review)
  (d) 其他:你说

复杂度(complexity)

复杂度直接决定推荐模式参数(见 Step 4)。模糊时默认 moderate,但在输出里说明假设让用户纠正。

设计上下文(design context)

如果原始请求明显是 UI / landing page / 产品界面 / 品牌视觉 / 组件体验类工作,检查项目根目录是否已有 .design-context.md:

dev-design-context 是一次性前置步骤,不是每个 feature 都必须跑。

Step 3 — 扫描现状(只读 artifacts 存在性 + frontmatter status)

扫以下目录(都在用户当前 cwd 下,不在 dev-skills 仓库下):

ls -la .claude/artifacts/designs/   # dev-grill-docs / dev-spec 产物
ls -la .claude/artifacts/plans/     # dev-plan 产物
ls -la .claude/artifacts/fixes/     # dev-fix 产物
test -f .design-context.md && echo "design context: present"

文件名匹配 + Slug 确认

Slug 命名空间约定:

• designs/<slug>.md 和 plans/<slug>.md 同名 = 同一个 feature(spec → plan 链路)
• fixes/<slug>.md 是独立工作单元(每个 bug 一个 slug),不与 feature slug 共享命名空间

命名空间冲突检测:扫描时如果同一 slug 同时出现在 designs/ 和 fixes/ 两处(例如 designs/auth-refresh.md + fixes/auth-refresh.md 共存)→ 报错并要求用户改名:

检测到 slug 命名空间冲突:
  - .claude/artifacts/designs/<slug>.md (feature 路径)
  - .claude/artifacts/fixes/<slug>.md   (bug 路径)

这两条记录会让 phase 推断混乱(同时是 Phase 1 和 Phase 3)。
请改其中一个的名字让它们分开,例如:
  fixes/<slug>.md → fixes/<slug>-bug.md

改完再来跑 dev-auto。

绝不擅自合并或假设语义(它们可能是同一工作单元的两面,也可能是凑巧重名)。让用户拍板。

Slug 推断 + 确认流程:

绝不自动选 slug 跳过确认 —— slug 直接决定后续 artifact 文件路径,选错会导致 in-flight 项目混淆。

Terminal status 解析(只读 terminal 信号)

读匹配到的 artifact 文件第一行 frontmatter / quote block 里的 Status 字段,只识别以下对 dev-auto 有意义的 terminal status:

spec artifact 的 DRAFT / ALIGNED / IMPLEMENTED lifecycle status 不影响 phase 推断 —— spec 只看「文件是否存在」,生命周期 status 留给用户手动管理。

绝不深读其他内容(不解析 AC / 不读 hypothesis 表 / 不读 plan body)。读了就违反「最小代码」。

推断当前 phase(简化:存在性 + terminal 信号)

没找到任何 artifact                 → Phase 0 (尚未开始)
designs/<slug>.md 存在 + 非 STUCK   → Phase 1 (spec 已存在,可进 plan / dev-tdd)
designs/<slug>.md 存在 + STUCK      → Phase 1-blocked (spec 卡住,需外部信息,见 --recover)
plans/<slug>.md 存在 + APPROVED     → Phase 2 (plan 已通过,待 dev-tdd)
plans/<slug>.md 存在 + BELOW...     → Phase 2-blocked (plan 未达共识,见 --recover)
fixes/<slug>.md 存在 + FIXED        → Phase 3 (修复完,待 dev-verify / dev-code-review)
fixes/<slug>.md 存在 + 其他 status   → Phase X-blocked (见 --recover)

无法明确推断时(例如 fixes/.md 存在但 status 字段缺失),直接告诉用户「我看到 X 但不确定状态,请说一下你刚跑完什么 / 现在卡在哪」。

Clean-tree worktree checkpoint(仅当下一步会进入写代码)

如果推荐链的下一步或后续步骤包含「写代码 / 修代码」,在输出建议前先检查:

git status --short
git branch --show-current

判定:

推荐格式:

编码前检查
  当前 git tree 干净,且下一步会修改代码/多文件。
  建议先创建 worktree:
  $ git worktree add -b codex/<short-slug> ../<repo>-<short-slug>

worktree 命名遵守 CLAUDE.md.template 的规范:codex/<short-slug> 分支 + 兄弟目录 <repo>-<short-slug>。

Step 4 — 输出推荐(默认模式)

严格按下列三段输出,不要加寒暄、不要输出多余分析:

━━━ Dev Auto ━━━
路径   : feature | bug | hotfix
复杂度 : simple | moderate | complex
Slug   : <feature-slug>(自动推断,你可以纠正)

完整推荐链
  1. <skill> <模式参数>          (一句话该步做什么)
  2. <skill> <模式参数>          (按路径列出,没有就省略)
  3. <skill> <模式参数>          (按路径列出,没有就省略)
  ...

当前位置
  Phase <N>:<一句话当前状态>
  已完成 artifacts:<文件路径列表>

下一步
  $ <精确命令,可复制粘贴>
  为什么:<一句话 rationale,不超过两行>

编码前检查
  <仅当下一步会写代码且 clean tree checkpoint 命中时输出;否则整段省略>

推荐链对照表

下面是默认推荐,用户可以偏离(但偏离时 dev-auto 应在下一次 --status 时容忍):

关键规则:

• complex feature 强烈建议 dev-plan --deliberate(自带 pre-mortem + expanded test plan)
• UI / landing page / 产品界面类 feature 且没有 .design-context.md 时,在 feature 链路前追加 dev-design-context。
• complex bug 强烈建议 dev-fix --deep(强制 3-5 hypothesis + 反向追溯 + instrument)
• feature / hotfix / refactor 等直接编码路径默认推荐 dev-tdd;bug 路径由 dev-fix 内置 failing test + red→green→red 验证,不要再追加第二套 dev-tdd。
• 任何完成声明前默认推荐 dev-verify,避免把局部测试通过包装成完整 ready。
• dev-finish 只在验证和 review 后用于 merge / PR / keep / discard,不是 coding step。
• hotfix 只允许 simple,如果用户标 hotfix 但实际是 moderate/complex,警告并建议升级路径(具体话术见下)

Hotfix 升级警告(用户标 hotfix 但实际不是 simple)

输出严格按以下话术,不要软化:

你标了 hotfix,但 symptoms 含 [具体信号:跨服务 / 鉴权 / 数据迁移 / ...],
实际是 [moderate/complex]。

Hotfix 路径会跳过 dev-grill-docs / dev-plan,但不能跳过 dev-tdd / dev-verify / dev-code-review。否则**很可能让 dev-code-review 抓出 P0 阻塞**
(常见 P0:闭环失败 / 边界没考虑 / 跨模块未对齐),反而比走完整路径更慢。

建议改走:
  → [feature/bug] [moderate/complex] 路径(完整 spec + plan + tdd + verify + review)
  → 完整推荐链:[列具体 skill 序列]

如果你坚持 hotfix(承担 review 阶段被 BLOCK 的风险),回复「继续 hotfix」。
否则我按 [推荐路径] 重新输出推荐。

Step 5 — --status 模式

只输出当前位置,不推荐:

━━━ Status ━━━
Slug:<feature-slug>
Phase <N>:<一句话>
已完成:<artifacts 列表>
未完成:<剩余 phase 列表>

Step 6 — --next 模式

只一条命令,极简:

$ <skill> <args>
(<一句话 rationale>)

适合用户已经在流程里,只想问「就告诉我下一句敲什么」。

Step 7 — --recover 模式

输入:用户报告某 skill 输出是 BLOCK / REVISE / REJECT / NEEDS_DESIGN_CHANGE / verify 失败 / 别的失败信号。

Step 7.0 — 输入清晰度检查(必做)

如果用户输入不含明确 skill 名 + 失败信号,不要硬猜,先回问:

要给你恢复建议,我需要两条信息:
  1. 你刚跑了哪个 skill?(dev-grill-docs / dev-spec / dev-plan / dev-tdd / dev-fix / dev-verify / dev-code-review / dev-commit-writer / dev-finish)
  2. 它的输出关键信号是什么?(贴 Verdict / Status / 错误摘要那一行就行)

例如:「dev-code-review 给我 Verdict = ⚠ FIX P1,有 2 处 console.log 残留」
或:「dev-fix 跑了 deep,3 假设全 fail,Status: BELOW_CONFIDENCE_THRESHOLD」

得到具体信息后再进 Step 7.1 决策表。

Step 7.1 — 决策表

按以下决策表推荐恢复路径:

输出形式:

━━━ Recover ━━━
失败 skill : <skill>
失败信号   : <一句话>

推荐恢复:
  → 回到 phase <N>(<skill> <args>)
  原因   :<一句话>
  操作建议:<具体下一步,可复制粘贴的命令>

如果上述方式无效:<次选恢复路径>

绝不输出「再试一次相同操作」 —— 失败有原因,要么修要么换路径,不许重复。

Hard rules

• 不要 调起其他 skill。dev-auto 永远是建议器,用户自己跑。
• 不要 写代码。
• 不要 产出 artifact 文件(没有 .claude/artifacts/workflows/ 这种东西)。
• 不要 深读 artifact 内容 —— 只读存在性 + frontmatter status 字段。读 AC / hypothesis / plan body 就违反「最小代码」。
• 不要 替用户决定模糊 path / complexity —— 列选项问。
• 不要 维护跨调用的 state —— 每次调用都从仓库现状重新扫,推断当前 phase。
• 不要 在 --next / --status 模式里输出多余信息 —— 这两个模式追求极简。
• 不要 在 --recover 模式建议「再试一次」—— 必须是修复 / 换路径 / 升模式 / 转 skill,不许重复同操作。
• 不要 把 hotfix 路径用在 complex 改动上 —— 警告并建议升级到 feature/bug 路径。
• 不要 假装能看到代码改动 —— dev-auto 不读源码,只看 artifacts。代码状态由用户告知。

与其他 skill 的关系

• 入口侧:dev-auto 是所有路径的可选入口。用户可以直接跑某个 skill,也可以先跑 dev-auto 拿推荐再决定。
• 不调用:dev-auto 推荐 dev-grill-docs 时,用户自己执行 dev-grill-docs,不是 dev-auto 调起。
• 下游回流:用户跑完某 skill 后,可以再来 dev-auto 问下一步,也可以自己看流程图直接进。
• 触发竞争:dev-auto 的 description 严格限制只在用户显式要求 workflow / 串起来 / 完整跑时触发,避免和 dev-grill-docs / dev-fix 等具体 skill 抢触发。

Multi-Agent Note

dev-auto is main-agent-first. It remains a workflow recommender, not an orchestrator.

When the host runtime supports multi-agent execution, dev-auto may recommend a next phase that is suitable for delegation, but it must not spawn sub-agents, invoke other skills, or perform delegated work itself. The main agent applies ../../docs/multi-agent-policy.md when deciding whether to delegate.

Source: hashgraph-online/awesome-codex-plugins → plugins/Jason-chen-coder/dev-skills/skills/dev-auto/SKILL.md