开源项目：把团队代码规范封装成 Claude Code/Codex Agent 技能

停止在孤岛中凭感觉编程。为你的工程团队构建一套共享认知层。

个人层面的 prompt 技巧为独立开发者带来快速收益，但当扩大到一个团队时，"凭感觉编程"会导致混乱的技术债务、上下文腐化、无法审查的 PR，以及代码所有权的丧失。速度问题已经解决；信任与验证成为 AI 工程的新瓶颈。

ADLC Team Skills（tikalk/adlc-team-skills）是 Twelve-Factor Agentic SDLC 的开源团队层。它将 AI 智能体从孤立的猜测者转变为合规、可问责的团队成员，共享团队的章程、产品策略、架构标准和评估基准。

Team AI Directives（tikalk/agentic-sdlc-team-ai-directives）是配套仓库，存放团队版本控制的上下文模块（章程、规则、角色设定、示例）、CDR 索引和技能清单。

# 安装技能 + 生成斜杠命令 + 接入 session_start 事件
npx adlc-skills-cli add tikalk/adlc-team-skills -a opencode

# 或仅使用 npx skills（无命令/事件的技能）
npx skills add tikalk/adlc-team-skills -a claude -g

可与任何支持 Agent Skills 标准的智能体开箱即用——Claude Code、Codex、OpenCode、Cursor、GitHub Copilot 等。

斜杠命令 + 事件：adlc-skills-cli 封装了 npx skills add，并额外生成 /name 斜杠命令，通过 .events.json 为 9 种编码智能体接入 session_start 事件钩子。没有 .events.json 的技能仓库仅获得命令。

通用编排：mission-brief 可自动从任何来源发现技能（mattpocock/skills、addy osmani/agent-skills、superpowers、spec-kit，或你自己的），并动态接入任务管道。无供应商锁定。

黄金路径——引导新的 team-ai-directives

team-boot 通过事件钩子在会话开始时自动运行。在未配置的项目上，它会输出警告，告诉用户运行 /team-setup。team-setup 也可按需使用：

npx adlc-skills-cli add tikalk/adlc-team-skills -a opencode   # 安装技能 + 命令 + 事件

然后选择模式 3——脚手架新的空 team-ai-directives，或模式 1——从 GitHub 克隆以 fork tikalk/agentic-sdlc-team-ai-directives：

team-setup            → 选择目标目录（默认 ./team-ai-directives）+ 团队名称
                      → 脚手架 README / AGENTS.md / CDR.md / .skills.json /
                        章程占位符 / OKF 索引文件 + git init

team-constitution     → 交互式替换占位符为你的真实原则

team-boot (自动)      → 在会话开始时将章程 + CDR 索引 + PDR/ADR 索引 + 技能注册表
                        组装到系统提示词中

已经有指令仓库？team-setup 提供其他四种模式：

模式 1——从 GitHub 克隆（例如 fork tikalk/agentic-sdlc-team-ai-directives）

模式 2——指向现有本地路径（接入你已经拥有的仓库）

模式 4——已配置完成（验证现有设置）

工作原理：ADLC 前后对比

作为代码的指令：四大团队支柱

                             [ 大过滤器 ]
                      (人类团队负责人宏观审查)
                                     ▲
                                     │
                  ┌──────────────────┴──────────────────┐
                  │   支柱 4: 治理与评估      │
                  │   (一级快速检查 + LLM 评判) │
                  └──────────────────▲──────────────────┘
                                     │
                  ┌──────────────────┴──────────────────┐
                  │   支柱 3: 规范驱动的工作流    │
                  │   (契约优先的任务管道)      │
                  └──────────────────▲──────────────────┘
                                     │
                  ┌──────────────────┴──────────────────┐
                  │   支柱 2: 产品与架构      │
                  │   (产品 PDR + 架构 ADR)   │
                  └──────────────────▲──────────────────┘
                                     │
                 ┌───────────────────┴───────────────────┐
                 │   支柱 1: 策略与团队指令  │
                 │   (team-boot / levelup / CDR 仓库) │
                 └───────────────────────────────────────┘

🏛️ 支柱 1: 策略与团队指令（团队优先对齐）

将团队置于 AI 策略的中心。与其在个人开发者的本地机器上囤积 prompt 技巧，不如让团队标准活在版本控制的 Git 仓库中（team-ai-directives）。

team-boot：通过事件钩子在会话开始时自动运行，将团队章程、CDR 索引、PDR/ADR 索引和技能注册表组装到系统提示词中。

渐进式披露（不浪费 Token）：team-boot 不再将大量 prompt 内容倾倒到每个会话中，而是注入一个紧凑的约 100 token 的索引。team-discover 仅在与当前任务相关时才加载完整规则体。

team-constitution：交互式定义、审查或修订工程团队的核心原则。

team-repair：重新索引 CDR.md，扫描规则冲突，并验证指令的时效性。

team-boot        → 将章程 + CDR 索引 + PDR/ADR + 技能组装到系统提示词
team-discover    → 手动重新扫描结构化发现表（/team-discover）
team-constitution → 交互式创建或修订团队章程
team-repair      → 重新索引 CDR.md，扫描冲突，验证时效性

🎯 支柱 2: 产品策略与架构治理（PDR 与 ADR）

没有文档化的决策，每次实现会话都会重新推导（或误解）产品意图和架构规则。

产品决策记录（product-*）：将产品决策捕获为独立的 PDR 文件，通过交互式澄清工作流解决歧义，并将其编译成独立的 PRD.md。

架构决策记录（architect-*）：使用 Rozanski & Woods 视角（功能性、安全性、部署、性能）反向推导或定义架构决策，并将其组合成统一的 AD.md。

product-roadmap：在四个真实层跟踪里程碑进度——决策（PDR）、执行（通过 MCP 的 live issues）、代码证据和里程碑关卡。

产品:      product-init → product-clarify → product-implement → product-analyze
架构:      architect-init → architect-clarify → architect-implement → architect-analyze
路线图:    product-roadmap（跟踪 PDR + issues + 代码 + 关卡）

📐 支柱 3: 规范驱动的工作流（"调试规范，而非代码"）

AI 是一个执着的猜测者——当遇到歧义时，它会发明解决方案而不是提问。从对话模型转向契约模型。

mission-brief：团队的自主管道运行器。接收功能 prompt，推导出正式契约（目标、约束、非目标、成功标准），生成有序步骤列表，并走 specify → plan → tasks → implement ↺ converge 循环直到完成。

座右铭："调试规范，而非代码"：当智能体犯错时，不要只打补丁——而要将缺失的约束添加到规范中，这样错误就永远不会重复。

mission-brief "add user profile API with JWT"
  ├── 阶段 2: Brief（目标、约束、非目标、成功标准）
  ├── 阶段 3: 路由分类（spec | change | quick）
  ├── 阶段 4: 发现（自动接入本地已安装技能和 SDD 框架）
  └── 阶段 5: 执行（specify → plan → tasks → implement ↺ converge）

🛡️ 支柱 4: 团队治理、验证优先的评估与"构建为删除"

永远不要让编写代码的智能体决定代码是否好。"将制造者与检查者分离。"

evals 技能：使用评估驱动开发（EDD）构建应用级评估套件（PromptFoo 或 DeepEval）。运行一级快速检查 + 二级 LLM 判断子智能体，在人类宏观审查进入"大过滤器"之前，根据定义的业务风险测试代码。

levelup：将会话成果捕获到永久团队记忆中。levelup-specify 提取会话执行轨迹并将其作为可复用规则（上下文指令记录——CDR）提交到 Git。

"构建为删除"：使用 team-repair --build-to-delete 剪除过时的规则和 prompt 样板代码，因为底层基础模型在改进。

LevelUp: levelup-init → levelup-specify → levelup-clarify → levelup-publish
Evals:   evals-init → evals-specify → evals-clarify → evals-implement → evals-validate → evals-analyze

🌐 通用技能与 SDD 框架编排——零锁定

Factor XII——构建为删除。Factor XIII——循环工程。

mission-brief 作为一个开放的、供应商无关的编排器，跨越所有流行的智能体技能仓库和规范驱动开发（SDD）框架：

发现（Discovery） — 任务启动时，mission-brief 会扫描所有 skills 目录（.claude/skills、.agents/skills 等），并读取每个 SKILL.md 的 frontmatter，从而构建一份与供应商无关的已安装技能清单，包含名称和描述。

LLM 自主路由（LLM-decided routing） — 每个步骤的委托提示词（delegation prompt）都包含完整的技能清单。由子智能体决定当前阶段适用哪种技能（如果有的话）—— 由 LLM 来匹配，而非脆弱的查找表。

优雅降级（Graceful fallback） — 如果没有技能匹配，子智能体直接执行。如果有技能匹配，则调用该技能。无论哪种情况，任务管道都会继续执行。

# 从多个团队或社区来源安装技能
npx skills add mattpocock/skills
npx skills add tikalk/adlc-team-skills

# mission-brief 自动发现并路由
mission-brief "add user profile API with JWT"

技能按照 SDLC 十二要素智能体（Twelve-Factor Agentic SDLC）的四大支柱组织，直接平铺在 skills/ 目录下：

skills/
├── architect/             # architect-*（5 个技能）
├── product/               # product-*（6 个技能）+ product-templates/
├── levelup/               # levelup-*（4 个技能）+ levelup-helpers.{sh,ps1}
├── mission-brief/         # 核心 SDD 编排器（1 个技能）
├── evals/                 # evals-*（6 个技能）+ evals-templates/
├── tech-radar/            # tech-radar-*（1 个技能）+ resources/radar.json
├── workspace/             # workspace（1 个技能）— 多仓库协作
└── team/                  # team-*（6 个技能）+ team-helpers.{sh,ps1}

所有技能都被精确放置在两层深度目录下，彻底解决了 skills CLI 的默认深度限制问题，并确保所有技能开箱即用。

团队指令（Team Directives）（6 个技能）

team-boot — 引导会话：在会话启动时将章程、CDR 索引、PDR/ADR 索引和技能注册表组装到系统提示词中。对未配置的项目输出警告，提示运行 /team-setup。

team-discover — 手动重新扫描团队上下文模块并生成结构化发现表。可通过 /team-discover 调用。

team-setup — 克隆、搭建或配置团队 AI 指令仓库。由 team-boot 模型调用（自安装），也支持按需调用。说"为此项目设置团队指令"。

team-constitution — 交互式创建或修订团队章程。说"创建我们的团队章程"或"修订我们的团队原则"。

team-repair — 重新索引 CDR.md、.skills.json、AGENTS.md；健康检查；冲突扫描；新鲜度验证。说"检查我们的团队指令健康状况"（--health-only）、"修复我们的 CDR 索引"或"扫描规则冲突"（--conflicts）。

team-skills — 浏览并从团队 AI 指令中安装团队技能。说"展示可用的团队技能"。

LevelUp / CDR 生命周期（LevelUp / CDR Lifecycle）（5 个技能）

全部由用户调用。将可复用模式捕获并发布到 team-ai-directives，包括配对的指令合规性评估 CDRs。

levelup-init — 从现有代码库发现棕地（brownfield）CDR，包括代码模式中的配对评估 CDR。说"从此代码库发现指令"。

levelup-specify — 从当前会话提取 CDR 和配对评估 CDR。说"从此次会话提取经验"。

levelup-clarify — 审查、接受、拒绝或推迟待处理的 CDR。默认运行评估回归门（regression gate）。说"审查待处理的 CDR"。

levelup-publish — 将已接受的 CDR 编译为团队指令制品、评估金标准（goldensets）和草稿 PR。说"发布已接受的 CDR"或"从 CDR 构建一个技能"（--skill CDR-NNN）。

产品 / PDR 生命周期（Product / PDR Lifecycle）（6 个技能）

全部由用户调用。将产品决策文档化为独立的 PDR，并编译为自包含的 PRD.md。

product-init — 从现有代码库和文档中发现棕地 PDR。说"从此代码库发现产品决策"。

product-specify — 通过交互式产品探索创建绿地（greenfield）PDR。说"让我们定义产品策略"。

product-clarify — 在生成 PRD 之前完善、验证和批准 PDR。说"审查我们的产品决策"。

product-implement — 从已接受的 PDR 生成 PRD.md（多智能体 DAG 编排）。说"生成我们的 PRD"。

product-analyze — 只读的 PDR↔PRD 一致性和质量分析。说"分析我们的产品文档"。

product-roadmap — 跟踪里程碑进度：决策状态、通过 MCP 的实时 issue、代码证据和关卡。说"显示路线图进度"。

架构（Architecture）（5 个技能）

全部由用户调用。使用 Rozanski & Woods 方法论创建和管理架构决策记录（ADR）。

architect-init — 从现有代码库反向工程 ADR（棕地）。说"从此代码库反向工程架构"。

architect-specify — 从 PRD 或功能描述创建 ADR（绿地）。说"从此 PRD 创建 ADR"。

architect-clarify — 完善和验证现有 ADR。说"完善并验证我的 ADR"。

architect-implement — 从已接受的 ADR 生成架构描述（AD.md）。说"从我的 ADR 生成 AD.md"。

architect-analyze — 检查 ADR↔AD 一致性和架构质量。说"分析架构一致性"。

治理 / 验证（Governance / Verification）（6 个技能）

全部由用户调用。按照 EDD（Eval-Driven Development，评估驱动开发）原则构建和维护应用级评估套件（PromptFoo 或 DeepEval）。

evals-init — 使用安全基线初始化评估目录结构（evals/{system}/）。说"初始化我的评估工具"。

evals-specify — 从规格说明和生产故障追踪中提取评估标准（自下而上的开放编码）。说"从此故障日志指定评估标准"。

evals-clarify — 聚类相关模式、完善标准、隔离 20% 保留集（holdout split）并发布金标准。说"完善并接受我的评估草案"。

evals-implement — 从金标准生成可执行评分器和测试配置，自动运行单元测试以验证评估器正确性。说"从金标准生成评分器"。

evals-validate — 运行评估金字塔（第 1 层快速检查 + 第 2 层 LLM 评判），并计算质量指标（TPR/TNR、SLA 裕量）。说"验证我的评估套件"。

evals-analyze — 深度分析轨迹故障追踪，将规格级失败路由到 levelup-specify（规则），将泛化失败路由到待办列表。说"分析评估失败"。

任务简报（mission-brief）

由用户调用。将功能描述结构化为任务简报，并使用任何已安装的 SDD 技能集端到端运行。说"端到端构建此功能"或 mission-brief "add dark mode"。通过 --resume 恢复。

技术雷达上下文（tech-radar-context）

由模型调用。将技术栈选择锚定在 Tikal 的以色列技术雷达上。发现提示词中隐含的技术，与 Tikal 技术雷达（radar.json）进行匹配，并注入上下文表，包含每种技术的采用环（Keep/Start/Try/Stop）、象限以及 Tikal 的"为什么？"意见——同时为 Stop 环上的任何技术提供 Tikal 对齐的替代方案。每当选择或评估技术、框架、数据库、库或云工具时，自动触发。尽力获取实时雷达，失败时回退到 resources/radar.json 中的打包快照。

工作空间（workspace）

由用户调用。用于多仓库工作空间协调，实现共享团队上下文。发现在深度 1 的子仓库，并可选择将其作为 Git 子模块链接，创建类似于 VS Code .code-workspace 的多仓库工作空间。父仓库在 .adlc/ 下保存共享的 PDR、ADR 和 CDR（由 product-specify、architect-specify、levelup-specify 创建）；子实现仓库被链接以实现统一上下文。命令：/workspace（发现）、/workspace --link（注册子模块）、/workspace --status（审计：分支、dirty、未推送、SHA 漂移）。无 workspace.yml — 纯按约定的自动发现。说"设置多仓库工作空间"或 /workspace --link。

所有技能都写入 .adlc/（项目根目录）和团队 AI 指令仓库。

团队指令（位于团队 AI 指令仓库内）：

AGENTS.md — 智能体指令（加载顺序、规则、技能）

CDR.md — 已批准的上下文贡献索引

.skills.json — 技能清单（schema v2.0.0）

.mcp.json.example — MCP 服务器配置示例

context_modules/constitution.md — 团队章程（OKF frontmatter）

context_modules/{rules,personas,examples}/**/*.md — 上下文模块

context_modules/{type}/index.md — 按概念类型的渐进式披露

context_modules/{type}/log.md — 按概念类型的chronological变更日志

skills/{name}/SKILL.md + .skills-entry.json — 已发布的团队技能

evals/{directive-id}/goldset.md + goldset.json — 指令合规性金标准

LevelUp（位于目标项目的 .adlc/ 内）：

.adlc/drafts/cdr/CDR-{NNN}.md — 提议/发现的 CDR（包括评估 CDR）

.adlc/drafts/cdr/cdr.md — 自动生成的 CDR 索引

.adlc/init-options.json — 团队 AI 指令路径配置

产品（位于 .adlc/ 和仓库根目录）：

.adlc/drafts/pdr/PDR-{NNN}.md — 提议/发现的 PDR

.adlc/drafts/pdr/pdr.md — 自动生成的 PDR 索引

.adlc/memory/pdr/PDR-{NNN}.md — 已接受/已完成 的 PDR

.adlc/memory/pdr/pdr.md — 已接受 PDR 索引

.adlc/product/sections/{feature-area}/{section}.md — PRD 各部分构建产物

.adlc/product/state.json — DAG 执行状态

PRD.md — 产品需求文档（仓库根目录）

架构（位于 .adlc/ 和仓库根目录）：

.adlc/drafts/adr/ADR-{NNN}.md — 提议/发现的 ADR

.adlc/drafts/adr/adr.md — 自动生成的 ADR 索引

.adlc/memory/adr/ADR-{NNN}.md — 已接受的 ADR

.adlc/memory/adr/adr.md — 已接受 ADR 索引

AD.md — 架构描述（仓库根目录）

.adlc/architect/ — 各视图 DAG 产物

任务（位于目标项目的 .adlc/ 中）：

.adlc/workflow/workflow-config.yml — 任务执行/监督/预算配置

.adlc/workflow/.mission-state.json — 步骤列表、已完成步骤、简报、发现结果

.adlc/workflow/runs/{feature}/mission-log.json — 最终审计追踪

.adlc/workflow/runs/{feature}/iterations.md — 每次实现的审计条目

治理（位于目标项目和仓库根目录）：

.adlc/drafts/evals/EVAL-{NNN}.md — 提议/发现的评估标准草案

.adlc/drafts/evals/evals.md — 草案评估索引

.adlc/memory/evals/EVAL-{NNN}.md — 已接受/已完成 的评估标准

.adlc/memory/evals/evals.md — 已接受评估索引

.adlc/memory/evals/holdout.json — 隔离/保留的 holdout 测试数据集

evals/{system}/goldset.md — 已发布的 goldset（人类可读）

evals/{system}/goldset.json — 已发布的 goldset（机器可读）

evals/{system}/config.yml — 评估框架配置

evals/{system}/config.{js,py} — 框架测试配置

evals/{system}/graders/check_*.py — 生成的二进制 Python 评分器/指标

evals/{system}/tests/test_check_*.py — 生成的单元测试，验证评分器正确性

evals/results/validation_report.md — 统计验证结果报告

工作区（位于父仓库根目录）：

.gitmodules — 子仓库的 Git submodule 注册（由 --link 创建）

.adlc/ — 共享团队上下文（PDR、ADR、CDR）；父目录为单一真实来源

在深度 1 处发现的子仓库；每个子仓库的 .adlc/ 存在性会被报告（供参考）

生成的上下文模块包含 Open Knowledge Format（OKF）v0.1 兼容的 frontmatter 以及自定义字段。

自定义字段与 OKF frontmatter 共存：id、cdr_ref、created、modified、verified、age_days、evidence。

目录结构：context_modules/{type}/index.md（渐进式披露）、context_modules/{type}/log.md（变更历史）、相关概念之间的交叉链接。

团队指令设置：

team-setup → team-constitution → team-boot（会话启动时自动执行）

Brownfield：product-init → product-clarify → product-implement → product-analyze
Greenfield：product-specify → product-clarify → product-implement → product-analyze
Roadmap：   product-roadmap（任意时刻）

架构生命周期：

Brownfield：architect-init → architect-clarify → architect-implement → architect-analyze
Greenfield：architect-specify → architect-clarify → architect-implement → architect-analyze

LevelUp / CDR 生命周期：

Brownfield：levelup-init → levelup-clarify → levelup-publish → team-repair
Session：   levelup-specify → levelup-clarify → levelup-publish → team-repair
Build to Delete：team-repair --build-to-delete → levelup-clarify（审查删除 CDR）

mission-brief "feature" → review brief → execute steps → converge → mission-log.json

多仓库工作区：

product-specify / architect-specify → 在父级 .adlc/ 中创建共享 PDR/ADR
workspace --link → 将子仓库注册为 submodules
workspace --status → 审计分支、脏状态、未推送、SH A漂移

应用评估生命周期：

Greenfield（规范驱动）：evals-init → evals-specify（从规范） → evals-clarify → evals-implement → evals-validate
Brownfield（错误驱动）：evals-init → evals-specify（从失败） → evals-clarify → evals-implement → evals-validate → evals-analyze

完整产品 → 架构 → 团队：

产品：     product-specify → product-clarify → product-implement → product-analyze
架构：     architect-specify → architect-clarify → architect-implement → architect-analyze
团队：     levelup-specify → levelup-clarify → levelup-publish → team-repair

关于发布 runbook、标签命名规范和恢复流程，请参阅 RELEASE.md。