一家做企业软件咨询的公司 Tikalk，在 GitHub 上开源了一套叫 ADLC Team Skills 的工具。仓库是 tikalk/adlc-team-skills，目前 27 颗星、66 次提交，规模不大，但思路值得说清楚：让 Claude Code、Codex、Cursor 这类编码智能体开工前先读一遍团队规矩，而不是每次从零猜测项目该怎么写。安装只要一行命令，npx adlc-skills-cli add tikalk/adlc-team-skills -a opencode，或者用 npx skills 只装技能不装命令。
这套东西真正的分水岭，不是打包了多少条“技能”。是它把团队规范做成了能进 Git 提交历史的版本化上下文。如果这个设计能落地，AI 编程会从个人攒的提示词，往可审查、可复用的工程流程上挪一步。但这终归是作者的设计意图，效果取决于团队愿不愿意长期维护规则库，以及手上那几款编码智能体到底兼不兼容。
团队规矩进代码库，而不是塞进每次对话
Tikalk 在项目自述里点出一个判断：AI 编程的瓶颈已经从“写得快”变成了“能不能信、能不能查”。个人靠提示词技巧能出活儿。一旦团队规模化，各自为战的结果就是技术债堆积、PR 没法评审、代码归属说不清。
ADLC Team Skills 想接的活儿分四块，用表格看更清楚：
| 模块 | 作用 | 触发时机 |
|---|---|---|
| team-boot | 加载团队章程与决策索引 | session 启动时自动执行 |
| mission-brief | 定义 Goal/Constraints/Non-Goals，跑 specify→plan→tasks→implement 流程 | 新任务立项时 |
| evals | 快速检查 + LLM 裁判子代理验证 | 变更提交前验证 |
| levelup | 把调试中发现的新规则写回 Git | 任务收尾、规则沉淀阶段 |
team-boot 塞进系统提示词的索引，项目自称只占约 100 token，完整规则靠 team-discover 按需拉取。这跟把一万字的规范墙直接糊进每次对话，是两种做法。这个数字是作者自述，没有第三方测过。
mission-brief 走的是“先立契约再动手”的路子，这跟 Spec-Kit、OpenSpec 这类规格驱动开发框架同宗同源。Tikalk 自己维护着一个 Spec-Kit 分支，OpenSpec 也被列进了 mission-brief 能对接的外部框架名单。
evals 和 levelup 负责把流程闭环。设计意图是让“这次踩过的坑”不再只活在某次聊天记录里，而是变成能复用的规则记录。这是意图，不是已验证的效果。
兼容性是卖点，维护成本是账单
项目宣称支持任何遵循 Agent Skills 标准的编码智能体：Claude Code、Codex、OpenCode、Cursor、GitHub Copilot 都在列，号称“开箱即用”。但仔细看它自己的说明，“支持多种智能体”不等于所有客户端体验一致：
| 技能库配置 | 能装的内容 |
|---|---|
| 带 .events.json | 技能 + 斜杠命令 + session_start 事件钩子 |
| 不带 .events.json | 只能装技能 |
adlc-skills-cli 生成的命令和钩子，项目自己写的是“为 9 个编码智能体生成”。跨工具的实际体验，得看每款编码智能体各自对 Agent Skills 标准的支持程度，不是装一次就自动对齐。
ADLC Team Skills 管的范围比 Spec-Kit、OpenSpec 这类专注“写清楚规格”的工具更宽。它还想管住团队章程、架构决策、评测集和规则沉淀，用四层结构堆起来。
范围越大，维护成本也越大。谁来维护配套仓库 agentic-sdlc-team-ai-directives 里的宪法、规则和评测集？谁来判断 levelup 沉淀出的新规则该不该合进主干？这些是工程负责人接下来要接的活，不是装个技能包就能自动解决的。
项目自己的架构图，把“人工宏观评审”（作者称之为 The Great Filter）放在最顶层。说明设计者自己也没打算让 AI 批准 AI 写的代码。规范自动加载和 LLM 评测，替代不了人工审查。
谁该现在就试，谁该再等等
对正在统一 AI 编程规范的工程负责人，这套工具值得当参考实现看一看。它把散落在每个人聊天记录里的经验，往版本控制搬了一步。
现实的做法是先小范围试点：挑一个团队、一个仓库，装上技能包，跑几周，看 evals 和 levelup 是否真能沉淀出有用的规则。不用等它成熟到企业级才动手，但也不必现在就把全公司标准迁进去。
同时用 Claude Code、Codex 的一线开发团队，不用纠结“选哪个”——项目的定位是补团队上下文，不是替换某个编码智能体。真正要盯的是命令和钩子在自己常用的那款工具里是不是真能跑起来，而不是看 README 里的支持列表。
接下来最该观察的，是两件事：配套的规则仓库有没有人持续更新提交，以及跨客户端的命令、钩子体验会不会随着 Agent Skills 标准成熟而逐渐拉齐。这两件事，现在都还看不清。