by umacloud
AI 编码项目总监 Agent:驱动你已登录的 Claude Code / Codex / OpenCode,套上 9 阶段可治理的商业级交付流水线。 AI coding project-director agent — a 9-phase governed delivery pipeline over your logged-in Claude Code / Codex / OpenCode.
# Add to your Claude Code skills
git clone https://github.com/umacloud/umadevumadev is an open-source ai agents skill for AI coding assistants such as Claude Code, Codex CLI, and ChatGPT, built by umacloud. AI 编码项目总监 Agent:驱动你已登录的 Claude Code / Codex / OpenCode,套上 9 阶段可治理的商业级交付流水线。 AI coding project-director agent — a 9-phase governed delivery pipeline over your logged-in Claude Code / Codex / OpenCode. It has 52 GitHub stars.
umadev's catalog security scan is still queued. You can run an instant dependency and prompt-injection check now with the "Scan for vulnerabilities" button above.
Clone the repository with "git clone https://github.com/umacloud/umadev" and add it to your Claude Code skills directory (see the Installation section above).
umadev is primarily written in Rust. It is open-source under umacloud on GitHub, so you can review or fork the full source.
Yes. SkillsLLM lists many other AI Agents skills you can browse and compare side by side. Open the AI Agents category from the badge at the top of this page, or use the Related Skills and comparison links further down to weigh umadev against similar tools.
No comments yet. Be the first to share your thoughts!
Unlocks once the catalog security scan passes (runs nightly).
The deep catalog scan for this skill is still queued. Run an instant dependency check now instead.
从一句需求,到 PRD、架构、UI/UX、代码、质量门、交付包——底座写代码,UmaDev 管流程。
UmaDev 是一个本地运行的确定性壳:它给你已经登录的 AI 编码底座(Claude Code / Codex / OpenCode)套上一条治理轨道,把"AI 写代码"约束成一个可检查、可恢复、可审计的交付流程。它不替代这些底座,也不卖模型 API——脑子始终在底座,UmaDev 只管流程、规则和证据。
如果普通 AI 编码工具像一个很强的工程师,那么 UmaDev 更像围着它的一圈流程与审稿岗位——产品经理、架构师、UI/UX 审稿人、技术负责人、QA、交付经理的检查清单,而不是一个能取代工程师的全自动总监。最终判断和代码仍来自底座,UmaDev 负责让这个过程不跑偏、留下证据。
定位与成熟度:UmaDev 仍处于早期、治理优先阶段,最适合在真实项目上验证它的流程与门禁。它把价值押在"轨道"上,而不是声称已经能无人值守地全自动交付。
UmaDev 脱胎于原项目 shangyankeji/super-dev。
早期的 super-dev 更像一个 AI 编码治理工具:它主要关注“AI 生成代码时不能写什么”,例如不要用 emoji 当图标、不要硬编码颜色、不要写不安全代码。
现在的 UmaDev 在这之上扩成了一条完整的治理轨道:
一句话概括这个演进:
super-dev关注“AI 不要写烂代码”;UmaDev关注“AI 如何交付一个完整、可上线、可审计的商业项目”。
很多人第一次用 AI 编码工具时都会遇到类似问题:
UmaDev 的目标就是把这些问题系统化解决。
它会强制 AI 走一条更像真实团队的流程:
flowchart LR
A["一句需求"] --> B["澄清问题"]
B --> C["调研"]
C --> D["PRD / 架构 / UIUX"]
D --> E["执行计划"]
E --> F["前端实现"]
F --> G["预览确认"]
G --> H["后端实现"]
H --> I["质量门"]
I --> J["交付包"]
推荐用 npm 安装预编译二进制:
npm install -g umadev
npm 只是分发壳。真正运行的是 Rust 编译出的 umadev 二进制。
支持的平台:
也可以从源码构建:
git clone https://github.com/umacloud/umadev.git
cd umadev
cargo build --release
./target/release/umadev --version
UmaDev 推荐驱动你已经登录的 CLI:
# 三选一即可
npm install -g @anthropic-ai/claude-code
npm install -g @openai/codex
npm install -g opencode-ai
然后按这些工具自己的方式登录。
UmaDev 不保存你的 Claude / Codex / OpenCode 登录信息。它只是把任务作为非交互命令发给它们。
cd your-project
umadev init
这一步会写入一些项目配置:
umadev.yaml # 声明这是一个 UmaDev 管理的项目
.umadevrc # 项目级配置
.umadev/rules.toml # 治理规则配置
CLAUDE.md # 给 Claude Code 看的项目说明
.gitignore # 忽略 UmaDev 运行产物
knowledge/ # 项目内知识库和设计系统种子
umadev
第一次打开会让你选择:
之后直接输入需求:
做一个面向独立开发者的 SaaS 订阅管理后台,包含登录、订阅计划、账单记录和管理员仪表盘。
UmaDev 会开始组织完整流程。
前端阶段完成后:
/preview
交付阶段完成后:
/deploy
最终交付证据会在:
output/
release/
.umadev/audit/
其中最重要的是:
release/proof-pack-<project>-<time>.zip
release/scorecard-<project>-<time>.html
这两个文件就是给团队、客户或审计方看的交付证明。
假设你在一个空项目里运行:
umadev init
umadev
然后输入:
做一个课程预约小程序,用户可以查看课程、选择时间、预约、取消预约,管理员可以管理课程和预约记录。
UmaDev 会做这些事:
output/<slug>-research.md。整个过程不是“AI 聊完就算完成”,而是会留下真实文件。
整体架构可以理解成四层:
flowchart TB
User["用户<br/>输入需求 / 审核 / 预览 / 部署"] --> UI["UmaDev TUI / CLI<br/>聊天界面 + 命令入口"]
UI --> Director["umadev-agent<br/>流程引擎:阶段、gate、状态、质量门"]
Director --> Spec["umadev-spec<br/>UMADEV_HOST_SPEC_V1"]
Director --> Knowledge["umadev-knowledge<br/>本地知识库检索:BM25 + 向量"]
Director --> Governance["umadev-governance<br/>112 条治理规则 + 审计"]
Director --> Contract["umadev-contract<br/>OpenAPI 契约校验"]
Director --> Runtime["umadev-runtime<br/>统一 Runtime 接口"]
Runtime --> Host["umadev-host<br/>驱动底座 Claude / Codex / OpenCode<br/>实现代码 · 联网调研竞品"]
Runtime --> Offline["离线模板<br/>内部 CI / 无底座兜底"]
Host --> Workspace["项目工作区<br/>源码 / output / release"]
Offline --> Workspace
Governance --> Evidence[".umadev/audit<br/>审计日志"]
Contract --> Quality["quality gate"]
Evidence --> Quality
Quality --> Release["proof pack<br/>scorecard"]
更简单地说:
research.md——不是上来就写代码。这是推荐模式。
| Backend ID | 实际程序 | UmaDev 怎么调用 | 适合谁 |
|---|---|---|---|
claude-code |
claude |
claude --print --output-format text |
已经在用 Claude Code 的用户 |
codex |
codex |
codex exec --sandbox workspace-write |
已经在用 Codex CLI 的用户 |
opencode |
opencode |
opencode run |
已经在用 OpenCode 的用户 |
特点:
UmaDev 不自带模型,也不接第三方 API —— 底座用它自己的模型(你订阅登录的,或你给底座自己配的第三方 / 本地模型)。选底座时 UmaDev 会读出并显示它当前用的模型和思考强度(/status 也能看),但绝不覆盖:运行时默认不传 --model,底座用它自己的;想换就改底座自己的配置,或用 /model <id> 临时覆盖这一会话。
UmaDev 读取的来源:claude 的 ~/.claude/settings.json(model / effortLevel)、codex 的 ~/.codex/config.toml(model / model_reasoning_effort)、opencode 的 opencode.json(model,思考强度内置在模型变体里)。
/offline
离线模式不会调用任何模型,也不会访问网络。它不是一个让你选的产品形态——产品永远是"驱动你登录的底座"。离线模板只是没有底座可用时的确定性兜底,适合:
离线产物只是模板(带 TODO 占位),不代表模型完成了真实开发;真实交付必须走底座。第一次启动的底座选择器也只列这三个底座,不会把离线当成一个选项。
规范主链是 9 个阶段:
flowchart LR
R["research<br/>调研"] --> D["docs<br/>PRD / 架构 / UIUX"]
D --> G1["docs_confirm<br/>文档确认"]
G1 --> S["spec<br/>执行计划"]
S --> F["frontend<br/>前端"]
F --> G2["preview_confirm<br/>预览确认"]
G2 --> B["backend<br/>后端"]
B --> Q["quality<br/>质量门"]
Q --> L["delivery<br/>交付"]
当前产品实现还在主链前增加了一个 clarify 微阶段:
flowchart LR
C["clarify<br/>澄清需求"] --> R["research<br/>调研"]
R --> D["docs"]
D --> Rest["...后续 7 个规范阶段"]
所以你可能先看到 UmaDev 生成:
output/<slug>-clarify.md
你可以回答澄清问题,也可以输入 c 跳过。
小任务有轻量路径:9 阶段是面向"完整商业级交付"的主链,不是每个需求都得全程走完。用
/kind(全栈 / 仅前端 / 仅后端 / bugfix / 重构)声明任务类型后,UmaDev 会据此裁剪阶段——bugfix、小改动不会强行拉你走 PRD/架构/UIUX 全套。
| 阶段 | 你能理解成 | 主要文件 |
|---|---|---|
clarify |
先把需求问清楚 | output/<slug>-clarify.md、output/<slug>-clarify-answers.md |
research |
联网调研竞品、领域、风险、设计趋势 | output/<slug>-research.md |
docs |
写三份核心文档 | output/<slug>-prd.md、output/<slug>-architecture.md、output/<slug>-uiux.md |
docs_confirm |
让你确认文档方向 | .umadev/workflow-state.json |
spec |
拆任务和执行计划 | output/<slug>-execution-plan.md、.umadev/changes/<id>/tasks.md |
frontend |
前端实现和预览说明 | output/<slug>-frontend-notes.md |
preview_confirm |
让你看前端效果 | TUI gate 状态 |
backend |
后端实现和集成说明 | output/<slug>-backend-notes.md |
quality |
独立质量检查 | output/<slug>-quality-gate.json、output/<slug>-quality-gate.md |
delivery |
最终交付 | output/<slug>-delivery-notes.md、release/proof-pack-*.zip、release/scorecard-*.html |
质量门可以理解成 UmaDev 的“交付前验收”。
它不是简单看文件在不在,而是会检查:
.env.example。输出文件:
output/<slug>-quality-gate.json
output/<slug>-quality-gate.md
默认通过线是 90 分,可以在 .umadevrc 调整:
[quality]
threshold = 90
skip_checks = []
UmaDev 最早来自治理工具,这部分仍然是核心能力。
这些规则是一条治理基线,不是绝对真理——每条都可以在 .umadev/rules.toml 里禁用、按路径排除或调参(见下文)。它们的作用是给底座的产出兜底,而不是替你做最终的工程判断。
规范层有 25 条 clause,实现层目前有 112 条规则,覆盖:
any、裸 fetch、缺少 a11y、缺少 ErrorBoundary 等。unwrap、Go panic、Python bare except、Java System.exit 等。治理入口有四个:
flowchart LR
A["Claude Code hook<br/>写入前拦截"] --> G["umadev-governance"]
B["umadev ci<br/>提交前/CI 扫描"] --> G
C["MCP server<br/>给其他 AI 工具调用"] --> G
D["quality gate<br/>交付前补扫"] --> G
项目可以通过 .umadev/rules.toml 调整:
[disabled]
clauses = []
[exclusions]
paths = ["src/legacy/**", "**/*.test.ts"]
[extra]
blocked_domains = ["internal-bad-proxy.corp"]