tikalk/adlc-team-skills 源代码：https://github.com/tikalk/adlc-team-skills

ADLC 团队技能 —— 面向工程团队的 Agentic SDLC

停止在孤岛中“Vibe Coding”。为你的工程团队构建共享认知层。

个人提示词技巧能为独立开发者带来快速胜利，但一旦扩展到整个团队，“vibe coding”就会导致混乱的技术债务、上下文腐烂、无法审查的 PR，以及代码所有权的丧失。速度已经解决；信任与验证才是 AI 工程的新瓶颈。

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

团队 AI 指令（tikalk/agentic-sdlc-team-ai-directives (https://github.com/tikalk/agentic-sdlc-team-ai-directives)）是配套仓库，存放团队版本控制的上下文模块（章程、规则、角色、示例）、CDR 索引和技能清单。

快速开始

``bash

安装技能 + 生成斜杠命令 + 接线 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 标准 (https://agentskills.io) 的智能体 —— Claude Code、Codex、OpenCode、Cursor、GitHub Copilot 等。

斜杠命令 + 事件： adlc-skills-cli (https://github.com/tikalk/adlc-skills-cli) 包装了 npx skills add，并额外为 9 种编码智能体生成 /name 斜杠命令和接线 session_start 事件钩子（通过 .events.json）。没有 .events.json 的技能仓库仅获得命令。

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

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

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

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

然后选择 模式 3 —— 脚手架生成新的空 team-ai-directives，或 模式 1 —— 从 GitHub 克隆 以 fork tikalk/agentic-sdlc-team-ai-directives (https://github.com/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 (https://github.com/tikalk/agentic-sdlc-team-ai-directives)）
• 模式 2 —— 指向现有本地路径（接线你已经有的仓库）
• 模式 4 —— 已配置（验证现有设置）

工作原理：ADLC 之前 vs. 之后

指令即代码：四大团队支柱

[ 大过滤器 ]（人类团队负责人宏审查） ▲ │ ┌──────────────────┴──────────────────┐ │ 支柱 4：治理与评估 │ │ （第一层快速检查 + LLM 法官） │ └──────────────────▲──────────────────┘ │ ┌──────────────────┴──────────────────┐ │ 支柱 3：规格驱动工作流 │ │ （契约优先的任务管线） │ └──────────────────▲──────────────────┘ │ ┌──────────────────┴──────────────────┐ │ 支柱 2：产品与架构 │ │ （产品 PDR + 架构 ADR） │ └──────────────────▲──────────────────┘ │ ┌───────────────────┴───────────────────┐ │ 支柱 1：战略与团队指令 │ │ （team-boot / levelup / CDR 仓库） │ └───────────────────────────────────────┘

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

将团队置于 AI 战略的中心。个人开发者在本地机器上囤积提示词快捷方式，而团队标准则应存在于版本控制的 Git 仓库中（team-ai-directives (https://github.com/tikalk/agentic-sdlc-team-ai-directives)）。

• team-boot：在会话开始时通过事件钩子自动运行，将团队章程、CDR 索引、PDR/ADR 索引和技能注册表组装到系统提示词中。
• 渐进式披露（不浪费 Token）：team-boot 注入一个紧凑的约 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 的实时问题）、代码证据和里程碑门禁。

产品：product-init → product-clarify → product-implement → product-analyze 架构：architect-init → architect-clarify → architect-implement → architect-analyze 路线图：product-roadmap（跟踪 PDR + 问题 + 代码 + 门禁）

📐 支柱 3：规格驱动工作流（“调试规格，而非代码”）

AI 是一个强迫性的猜测者 —— 面对歧义时，它会发明解决方案，而不是提问。从对话式模型转向契约式模型。

• mission-brief：团队自主管线运行器。接收功能提示词，推导正式契约（目标、约束、非目标、成功标准），生成有序步骤列表，并走完 specify → plan → tasks → implement ↺ converge 循环直到完成。
• 口号：“调试规格，而非代码”：当智能体犯错时，不要只修补代码 —— 将缺失的约束添加到规格中，这样错误就不会重复发生。

mission-brief "添加带 JWT 的用户资料 API" ├── 阶段 2：Brief（目标、约束、非目标、成功标准） ├── 阶段 3：路线分类（规格 | 变更 | 快速） ├── 阶段 4：发现（自动接线本地已安装技能与 SDD 框架） └── 阶段 5：执行（specify → plan → tasks → implement ↺ converge）

🛡️ 支柱 4：团队治理、验证优先评估与“为删除而构建”

绝不让编写代码的智能体决定代码是否合格。“将制造者与检查者分离。”

• evals 技能：使用评估驱动开发（EDD）构建应用级评估套件（PromptFoo 或 DeepEval）。在人类宏观审查（大过滤器）之前，运行第一层快速检查 + 第二层 LLM 法官子智能体，对照已定义的业务风险测试代码。
• levelup：将会话胜利捕获为永久的团队记忆。levelup-specify 提取会话执行轨迹，并将其作为可复用规则（上下文指令记录 —— CDR）提交到 Git。
• “为删除而构建”：随着底层基础模型的改进，使用 team-repair --build-to-delete 修剪过时的规则和提示词脚手架。

LevelUp：levelup-init → levelup-specify → levelup-clarify → levelup-publish 评估：evals-init → evals-specify → evals-clarify → evals-implement → evals-validate → evals-analyze

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

因子 XII —— 为删除而构建。因子 XIII —— 循环工程。

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

工作原理

1. 发现 —— 任务开始时，mission-brief 扫描所有技能目录（.claude/skills、.agents/skills 等），并读取每个 SKILL.md frontmatter，构建已安装技能及其名称和描述的供应商无关清单。
2. LLM 决定路由 —— 每个步骤的委派提示词包含完整技能清单。子智能体决定哪个技能（如果有）适合当前阶段 —— 由 LLM 匹配，而非脆弱的查找表。
3. 优雅回退 —— 如果没有技能匹配，子智能体直接执行。如果技能匹配，则调用它。无论哪种方式，任务管线都会继续。

``bash

从多个团队或社区来源安装技能

npx skills add mattpocock/skills npx skills add tikalk/adlc-team-skills

mission-brief 自动发现并路由它们

mission-brief “添加带 JWT 的用户资料 API” ``

仓库布局

技能按 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}

这使得每个技能都恰好位于 2 层深度，完全解决 skills CLI 的默认深度限制，确保所有技能开箱即用。

参考

团队指令（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 生命周期（5 个技能）

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

• levelup-init —— 从现有代码库进行棕地 CDR 发现，包括从代码模式中提取配对的评估 CDR。说“从该代码库发现指令。”
• levelup-specify —— 从当前会话提取 CDR 和配对的评估 CDR。说“从本次会话提取经验教训。”
• levelup-clarify —— 审查、接受、拒绝或推迟待处理的 CDR。默认运行评估回归门禁。说“审查待处理的 CDR。”
• levelup-publish —— 将已接受的 CDR 编译为团队指令工件、评估金集和 PR 草稿。说“发布已接受的 CDR”或“从 CDR 构建一个技能”（--skill CDR-NNN）。

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

全部用户调用。将产品决策记录为单独的 PDR，并编译为自包含的 PRD.md。

• product-init —— 从现有代码库和文档进行棕地 PDR 发现。说“从该代码库发现产品决策。”
• product-specify —— 通过交互式产品探索创建绿地 PDR。说“让我们定义产品策略。”
• product-clarify —— 在 PRD 生成之前细化、验证和批准 PDR。说“审查我们的产品决策。”
• product-implement —— 从已接受的 PDR 生成 PRD.md（多智能体 DAG 编排）。说“生成我们的 PRD。”
• product-analyze —— 只读 PDR↔PRD 一致性和质量分析。说“分析我们的产品文档。”
• product-roadmap —— 跟踪里程碑进度：决策状态、通过 MCP 的实时问题、代码证据和门禁。说“显示路线图进度。”

架构（5 个技能）

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

• architect-init —— 从现有代码库逆向工程 ADR（棕地）。说“从该代码库逆向工程架构。”
• architect-specify —— 从 PRD 或功能描述创建 ADR（绿地）。说“从该 PRD 创建 ADR。”
• architect-clarify —— 细化并验证现有 ADR。说“细化并验证我的 ADR。”
• architect-implement —— 生成一个 Arch