ADLC Team Skills —— 面向工程团队的 Agentic SDLC

停止各自为政的 Vibe Coding。为你的工程团队构建共享认知层。

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

ADLC Team Skills（tikalk/adlc-team-skills）是 Twelve-Factor Agentic SDLC 的开源 团队层（Team Layer）。它将 AI Agent 从各自孤立、凭猜测工作的执行者，转变为遵守规范、可追责的团队成员；这些成员共享你团队的章程、产品战略、架构标准和评估基准。

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

---

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

# 或者仅使用 npx skills（仅安装 skills，不含命令/事件）
npx skills add tikalk/adlc-team-skills -a claude -g

可直接配合任何支持 Agent Skills 标准 的 Agent 使用——包括 Claude Code、Codex、OpenCode、Cursor、GitHub Copilot 等。

斜杠命令 + 事件：adlc-skills-cli 封装了 npx skills add，并额外为 9 种编程 Agent 生成 /name 斜杠命令、通过 .events.json 接入 session_start 事件钩子。不包含 .events.json 的 skills 仓库仅生成命令。

通用编排：mission-brief 可从任意来源自动发现 skills（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   # 安装 skills + 命令 + 事件

随后选择 模式 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 索引 + skills 注册表
                        组装进系统提示词

已经有 directives 仓库？team-setup 还提供另外三种模式：

• 模式 1 —— 从 GitHub 克隆（例如 fork tikalk/agentic-sdlc-team-ai-directives）
• 模式 2 —— 指向现有本地路径（接入你已有的仓库）
• 模式 4 —— 已完成配置（验证现有设置）

---

工作方式：使用 ADLC 前后对比

未使用 ADLC（Vibe Coding）	使用 ADLC Team Skills
会话从零开始：Agent 对你的架构、团队规则或已废弃模式一无所知。	自动引导上下文：team-boot 会在会话启动时自动加载团队章程和生效中的决策。
提示词墙膨胀：塞入一整面长达 10,000 token 的提示词墙会浪费 token，并导致模型指令漂移。	渐进式披露：team-boot 注入约 100 token 的索引；team-discover 仅获取与任务相关的 1—2 条规则。
歧义导致猜测：Agent 不提问，反而虚构函数或数据库 schema。	契约优先规格：mission-brief 在编写代码之前定义目标、约束、非目标和成功标准。
经验教训会消失：调试修复和新发现的边界条件会在聊天结束后消失。	闭环反馈：levelup-specify 提取会话执行轨迹，并将新规则直接提交到 Git。
静默回归：提示词编辑或基础模型更新会在无声无息中降低 Agent 输出质量。	验证优先评估：在人工审查之前，自动化 LLM Judge 和二元评分器会依据业务风险测试代码。

---

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

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

🏛️ 支柱 1：战略与团队指令（团队优先的一致性）

将团队置于 AI 战略的中心。团队标准不再由个人开发者将提示词捷径囤积在本地机器上，而是存放于经 Git 版本控制的仓库（team-ai-directives）中。

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

• 渐进式披露（不浪费 Token）：不再在每次会话中塞入巨大的提示词墙，team-boot 会注入精简的约 100 token 索引。仅当与当前任务有关时，team-discover 才加载完整规则正文。

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

• team-repair：重新索引 CDR.md、扫描规则冲突，并验证指令的新鲜度。

  team-boot → 将章程 + CDR 索引 + PDR/ADR + skills 组装进系统提示词 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 获取的实时 issues）、代码证据和里程碑关卡。

  Product: product-init → product-clarify → product-implement → product-analyze Architecture: architect-init → architect-clarify → architect-implement → architect-analyze Roadmap: product-roadmap（追踪 PDR + issues + 代码 + 关卡）

---

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

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

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

• 箴言：“调试规格，而不是代码”：当 Agent 出错时，不要只修补代码——应将缺失的约束补充到规格中，从而避免同类错误再次发生。

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

---

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

绝不能让编写代码的 Agent 自己决定代码是否优秀。“将制作者与检查者分离。”

• evals skills：使用评估驱动开发（Eval-Driven Development，EDD）构建应用级评估套件（PromptFoo 或 DeepEval）。在**伟大过滤器（The Great Filter）**中的人工宏观审查之前，运行 Tier 1 快速检查和 Tier 2 LLM Judge 子 Agent，依据已定义的业务风险测试代码。

• levelup：将会话中的成功经验沉淀为永久团队记忆。levelup-specify 提取会话执行轨迹，并以可复用规则（上下文指令记录，即 CDR）形式提交到 Git。

• “构建以删除”：随着底层基础模型能力提升，使用 team-repair --build-to-delete 清理过时规则和提示词脚手架。

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

---

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

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

mission-brief 是一个开放、与供应商无关的编排器，可跨越所有主流 Agent skill 仓库和规格驱动开发（SDD）框架工作：

SDD 框架 / Skill 来源	支持的工作流
Agentic SDLC Spec-Kit（tikalk/agentic-sdlc-spec-kit）	Twelve-Factor SDD 流水线、原生 specify CLI 发现、契约验证
Spec-Kit（specify_cli）	原生命令发现和规格模板
OpenSpec	结构化边界条件契约和验证 schema
mattpocock/skills	/tdd、/grill-me、/grill-with-docs、/code-review、/prototype
addyosmani/agent-skills	退出标准检查清单、质量关卡 skills
superpowers	开发者工具与工作流 skills
ADLC Team Skills（本仓库）	product-specify、architect-specify、evals-validate、levelup-specify
你的自定义 Skills	任何遵循 SKILL.md 标准的 skill

1. 发现——在任务启动时，mission-brief 会扫描所有 skills 目录（.claude/skills、.agents/skills 等），读取每个 SKILL.md 的 frontmatter，构建一份与供应商无关的已安装 skills 清单，其中包含名称和描述。
2. 由 LLM 决定路由——每个步骤的委派提示都包含完整 skills 清单。子 Agent 决定当前阶段适合哪一个 skill（如果有）——由 LLM 进行匹配，而不是使用脆弱的查找表。
3. 优雅降级——如果没有匹配的 skill，子 Agent 会直接执行；如果存在匹配的 skill，则调用它。无论哪种情况，任务流水线都会继续。

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

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

---

Skills 按照 Twelve-Factor Agentic SDLC 的四大支柱组织，并直接扁平化放置在 skills/ 目录下：

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

这样每个 skill 的深度都恰好为 2 层，完全规避 skills CLI 的默认深度限制，确保所有 skills 都能开箱即用地安装。

---

团队指令（6 个 skills）

• team-boot —— 引导会话：在会话启动时将章程、CDR 索引、PDR/ADR 索引和 skill 注册表组装进系统提示词。对于未配置项目，输出提示用户运行 /team-setup 的警告。
• team-discover —— 手动重新扫描团队上下文模块 a

ADLC Team Skills — Agentic SDLC for Engineering Teams

Stop Vibe Coding in Silos. Build a Shared Cognitive Layer for Your Engineering Team.

Individual prompt hacks create quick wins for solo developers, but when scaled across a team, "vibe coding" leads to chaotic technical debt, context rot, unreviewable PRs, and lost code ownership. Speed is solved; Trust and Verification is the new bottleneck in AI engineering.

ADLC Team Skills (tikalk/adlc-team-skills) is the open-source Team Layer of the Twelve-Factor Agentic SDLC. It turns AI agents from isolated guessers into compliant, accountable team members that share your team's constitution, product strategy, architectural standards, and evaluation benchmarks.

Team AI Directives (tikalk/agentic-sdlc-team-ai-directives) is the companion repository that holds your team's version-controlled context modules (constitution, rules, personas, examples), CDR index, and skills manifest.

---

# Install skills + generate slash commands + wire session_start events
npx adlc-skills-cli add tikalk/adlc-team-skills -a opencode

# Or with npx skills only (skills without commands/events)
npx skills add tikalk/adlc-team-skills -a claude -g

Works out of the box with any agent supporting the Agent Skills standard — Claude Code, Codex, OpenCode, Cursor, GitHub Copilot, and others.

Slash commands + events: adlc-skills-cli wraps npx skills add and additionally generates /name slash commands and wires session_start event hooks (via .events.json) for 9 coding agents. Skills repos without .events.json get commands only.

Universal orchestration: mission-brief auto-discovers skills from any source (mattpocock/skills, addy osmani/agent-skills, superpowers, spec-kit, or your own) and dynamically wires them into the mission pipeline. No vendor lock-in.

Golden path — bootstrap a new team-ai-directives

team-boot auto-runs at session start via the event hook. On an unconfigured project it outputs a warning telling the user to run /team-setup. team-setup is also available on demand:

npx adlc-skills-cli add tikalk/adlc-team-skills -a opencode   # install skills + commands + events

Then choose Mode 3 — Scaffold new empty team-ai-directives , or Mode 1 — Clone from GitHub to fork tikalk/agentic-sdlc-team-ai-directives:

team-setup            → pick destination (default ./team-ai-directives) + team name
                      → scaffolds README / AGENTS.md / CDR.md / .skills.json /
                        constitution placeholder / OKF index files + git init

team-constitution     → interactively replace the placeholder with your real principles

team-boot (auto)      → assembles constitution + CDR index + PDR/ADR indexes + skills registry
                        into the system prompt at session start

Already have a directives repo? team-setup offers three other modes:

• Mode 1 — Clone from GitHub (e.g. fork tikalk/agentic-sdlc-team-ai-directives)
• Mode 2 — Point to existing local path (wire a repo you already have)
• Mode 4 — Already configured (verify an existing setup)

---

How It Works: Before vs. After ADLC

Without ADLC (Vibe Coding)	With ADLC Team Skills
Session starts from zero : Agent knows nothing about your architecture, team rules, or deprecated patterns.	Auto-bootstrapped context : team-boot auto-loads your Team Constitution & active decisions on session start.
Prompt wall bloat : Dumping a 10,000-token prompt wall wastes tokens and causes model instruction drift.	Progressive disclosure : team-boot injects a ~100-token index; team-discover fetches only the 1–2 rules relevant to the task.
Ambiguity leads to guessing : Agent invents functions or database schema instead of asking questions.	Contract-first specs : mission-brief defines Goal, Constraints, Non-Goals, and Success Criteria before writing code.
Learnings evaporate : Debugging fixes and newly discovered edge cases disappear when the chat ends.	Closed feedback loop : levelup-specify extracts session execution traces and commits new rules directly to Git.
Silent regressions : Prompt edits or base model updates silently degrade agent output.	Verification-first evals : Automated LLM judges and binary graders test code against business risks before human review.

---

Directives as Code: The Four Team Pillars

                             [ THE GREAT FILTER ]
                      (Human Team Lead Macro-Review)
                                     ▲
                                     │
                  ┌──────────────────┴──────────────────┐
                  │   Pillar 4: Governance & Evals      │
                  │   (Tier 1 Fast Checks + LLM Judges) │
                  └──────────────────▲──────────────────┘
                                     │
                  ┌──────────────────┴──────────────────┐
                  │   Pillar 3: Spec-Driven Workflow    │
                  │   (Contract-First Mission Pipeline) │
                  └──────────────────▲──────────────────┘
                                     │
                  ┌──────────────────┴──────────────────┐
                  │   Pillar 2: Product & Architecture  │
                  │   (Product PDRs + Architecture ADRs)│
                  └──────────────────▲──────────────────┘
                                     │
                 ┌───────────────────┴───────────────────┐
                 │   Pillar 1: Strategy & Team Directives│
                 │   (team-boot / levelup / CDR repository) │
                 └───────────────────────────────────────┘

🏛️ Pillar 1: Strategy & Team Directives (Team-First Alignment)

Put the team at the center of your AI strategy. Instead of individual developers hoarding prompt shortcuts on local machines, team standards live in a version-controlled Git repository (team-ai-directives).

• team-boot : Auto-runs at session start via the event hook, assembling the team constitution, CDR index, PDR/ADR indexes, and skill registry into the system prompt.

• Progressive Disclosure (No Token Waste) : Instead of dumping massive prompt walls into every session, team-boot injects a compact ~100-token index. team-discover loads full rule bodies only when relevant to the active task.

• team-constitution : Interactively define, review, or amend your engineering team's core principles.

• team-repair : Re-index CDR.md, scan for rule conflicts, and verify directive freshness.

  team-boot → assembles constitution + CDR index + PDR/ADR + skills into system prompt team-discover → manual re-scan for structured discovery tables (/team-discover) team-constitution → create or amend the team constitution interactively team-repair → re-index CDR.md, scan for conflicts, verify freshness

---

🎯 Pillar 2: Product Strategy & Architectural Governance (PDRs & ADRs)

Without documented decisions, every implementation session re-derives (or misinterprets) product intent and architectural rules.

• Product Decision Records (product-*): Capture product decisions as individual PDR files, resolve ambiguities through an interactive clarification workflow, and compile them into a self-contained PRD.md.

• Architectural Decision Records (architect-*): Reverse-engineer or define architectural decisions using Rozanski & Woods viewpoints (Functional, Security, Deployment, Performance) and compose them into a unified AD.md.

• product-roadmap : Track milestone progress across four layers of truth — decisions (PDRs), execution (live issues via MCP), code evidence, and milestone gates.

  Product: product-init → product-clarify → product-implement → product-analyze Architecture: architect-init → architect-clarify → architect-implement → architect-analyze Roadmap: product-roadmap (tracks PDRs + issues + code + gates)

---

📐 Pillar 3: Spec-Driven Workflow ("Debug the Spec, Not the Code")

AI is an obsessive guesser — when faced with ambiguity, it invents solutions instead of asking questions. Move from a Conversational model to a Contract model.

• mission-brief : The team's autonomous pipeline runner. Takes a feature prompt, derives a formal contract (Goal, Constraints, Non-Goals, Success Criteria), generates an ordered step list, and walks a specify → plan → tasks → implement ↺ converge loop to completion.

• Mantra: "Debug the Spec, Not the Code" : When an agent makes a mistake, don't just patch the code — add the missing constraint to the specification so the mistake is never repeated.

  mission-brief "add user profile API with JWT" ├── Phase 2: Brief (Goal, Constraints, Non-Goals, Success Criteria) ├── Phase 3: Route Classification (spec | change | quick) ├── Phase 4: Discovery (auto-wires local installed skills & SDD frameworks) └── Phase 5: Execute (specify → plan → tasks → implement ↺ converge)

---

🛡️ Pillar 4: Team Governance, Verification-First Evals & "Build to Delete"

Never let the agent that wrote the code decide if the code is good. "Separate the Maker from the Checker."

• evals skills: Build application-level evaluation suites (PromptFoo or DeepEval) using Eval-Driven Development (EDD). Runs Tier 1 fast checks + Tier 2 LLM judge subagents to test code against defined business risks before human macro-review in The Great Filter.

• levelup : Capture session wins into permanent team memory. levelup-specify extracts session execution traces and commits them to Git as reusable rules (Context Directive Records — CDRs).

• "Build to Delete" : Prune outdated rules and prompt scaffolding as underlying foundation models improve using team-repair --build-to-delete.

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

---

🌐 Universal Skill & SDD Framework Orchestration — Zero Lock-In

Factor XII — Build to Delete. Factor XIII — Loop Engineering.

mission-brief acts as an open, vendor-agnostic orchestrator across all popular agent skill repositories and Spec-Driven Development (SDD) frameworks:

SDD Framework / Skill Source	Supported Workflows
Agentic SDLC Spec-Kit (tikalk/agentic-sdlc-spec-kit)	Twelve-Factor SDD pipeline, native specify CLI discovery, contract verification
Spec-Kit (specify_cli)	Native command discovery and specification templates
OpenSpec	Structured edge-case contracts and verification schemas
mattpocock/skills	/tdd, /grill-me, /grill-with-docs, /code-review, /prototype
addyosmani/agent-skills	Exit criteria checklists, quality gate skills
superpowers	Developer tooling & workflow skills
ADLC Team Skills (this repo)	product-specify, architect-specify, evals-validate, levelup-specify
Your Custom Skills	Any skill following the SKILL.md standard

1. Discovery — At mission start, mission-brief scans all skills directories (.claude/skills, .agents/skills, etc.) and reads every SKILL.md frontmatter to build a vendor-agnostic inventory of installed skills with their names and descriptions.
2. LLM-decided routing — Each step's delegation prompt includes the full skills inventory. The subagent decides which skill (if any) fits the current phase — the LLM matches, not a brittle lookup table.
3. Graceful fallback — If no skill matches, the subagent executes directly. If a skill matches, it's invoked. Either way, the mission pipeline continues.

# Install skills from multiple team or community sources
npx skills add mattpocock/skills
npx skills add tikalk/adlc-team-skills

# mission-brief discovers and routes them automatically
mission-brief "add user profile API with JWT"

---

Skills are organized under the four pillars of the Twelve-Factor Agentic SDLC, flattened directly under the skills/ directory:

skills/
├── architect/             # architect-* (5 skills)
├── product/               # product-* (6 skills) + product-templates/
├── levelup/               # levelup-* (4 skills) + levelup-helpers.{sh,ps1}
├── mission-brief/         # core SDD orchestrator (1 skill)
├── evals/                 # evals-* (6 skills) + evals-templates/
├── tech-radar/            # tech-radar-* (1 skill) + resources/radar.json
├── workspace/             # workspace (1 skill) — multi-repo coordination
└── team/                  # team-* (6 skills) + team-helpers.{sh,ps1}

This places every single skill exactly 2 levels deep, fully resolving the default depth limit of the skills CLI and ensuring all skills install out of the box.

---

Team Directives (6 skills)

• team-boot — Bootstrap session: assembles constitution, CDR index, PDR/ADR indexes, and skill registry into the system prompt at session start. Outputs a warning to run /team-setup on unconfigured projects.

• team-discover — Manually re-scan team context modules and produce a structured discovery table. Available via /team-discover.

• team-setup — Clone, scaffold, or configure a team AI directives repository. Model-invoked by team-boot (self-install) and available on demand. Say "Set up team directives for this project."

• team-constitution — Create or amend the team constitution interactively. Say "Create our team constitution" or "Amend our team principles."

• team-repair — Re-index CDR.md, .skills.json, AGENTS.md; health check; conflict scan; freshness verification. Say "Check our team directives health" (--health-only), "Repair our CDR index," or "Scan for rule conflicts" (--conflicts).

• team-skills — Browse and install team skills from the team AI directives. Say "Show me available team skills."

LevelUp / CDR Lifecycle (5 skills)

All user-invoked. Capture and publish reusable patterns to team-ai-directives, including paired directive compliance evals.

• levelup-init — Brownfield CDR discovery from existing codebase, including paired eval CDRs from code patterns. Say "Discover directives from this codebase."
• levelup-specify — Extract CDRs and paired eval CDRs from the current session. Say "Extract lessons from this session."
• levelup-clarify — Review, accept, reject, or defer pending CDRs. Evals regression gate runs by default. Say "Review pending CDRs."
• levelup-publish — Compile accepted CDRs into team directives artifacts, evals goldensets, and draft PR. Say "Publish accepted CDRs" or "Build one skill from a CDR" (--skill CDR-NNN).

Product / PDR Lifecycle (6 skills)

All user-invoked. Document product decisions as individual PDRs and compile into a self-contained PRD.md.

• product-init — Brownfield PDR discovery from existing codebase and documentation. Say "Discover product decisions from this codebase."
• product-specify — Greenfield PDR creation through interactive product exploration. Say "Let's define our product strategy."
• product-clarify — Refine, validate, and approve PDRs before PRD generation. Say "Review our product decisions."
• product-implement — Generate PRD.md from accepted PDRs (multi-agent DAG orchestration). Say "Generate our PRD."
• product-analyze — Read-only PDR↔PRD consistency and quality analysis. Say "Analyze our product docs."
• product-roadmap — Track milestone progress: decision status, live issues via MCP, code evidence, and gates. Say "Show roadmap progress."

All user-invoked. Create and manage Architecture Decision Records using the Rozanski & Woods methodology.

• architect-init — Reverse-engineer ADRs from an existing codebase (brownfield). Say "Reverse-engineer architecture from this codebase."
• architect-specify — Create ADRs from a PRD or feature description (greenfield). Say "Create ADRs from this PRD."
• architect-clarify — Refine and validate existing ADRs. Say "Refine and validate my ADRs."
• architect-implement — Generate an Architecture Description (AD.md) from accepted ADRs. Say "Generate AD.md from my ADRs."
• architect-analyze — Check ADR↔AD consistency and architecture quality. Say "Analyze architecture consistency."

Governance / Verification (6 skills)

All user-invoked. Build and maintain application-level evaluation suites following EDD (Eval-Driven Development) principles (PromptFoo or DeepEval).

• evals-init — Initialize evaluation directory structure (evals/{system}/) with security baseline. Say "Initialize my evaluation harness."
• evals-specify — Extract eval criteria from specs and production failure traces (bottom-up open coding). Say "Specify evaluation criteria from this failure log."
• evals-clarify — Cluster related patterns, refine criteria, isolate 20% holdout split, and publish goldset. Say "Clarify and accept my draft evaluations."
• evals-implement — Generate executable graders and test configs, automatically running unit tests to verify evaluator correctness. Say "Generate graders from the goldset."
• evals-validate — Run the evaluation pyramid (Tier 1 fast checks + Tier 2 LLM judges) and compute quality metrics (TPR/TNR, SLA headroom). Say "Validate my evaluation suite."
• evals-analyze — Deep-analyze trajectory failure traces, routing spec-level failures to levelup-specify (rules) and generalization failures to backlog. Say "Analyze evaluation failures."

User-invoked. Structure a feature description into a Mission Brief and run it end-to-end with any installed SDD skill set.

• mission-brief — Takes a description, structures it into a Mission Brief (goal, constraints, success criteria), generates an ordered step list with prompts that trigger installed SDD skills, and walks those steps to converged implementation. Sync (gated) or --async (ungated, checkpoint across sessions). Say "Build this feature end to end" or mission-brief "add dark mode". Resume with mission-brief --resume.

Model-invoked. Grounds tech stack choices in Tikal's Israeli Tech Radar.

• tech-radar-context — Discovers technologies implied by the prompt, matches them against the Tikal Tech Radar (radar.json), and injects a context table with each technology's adoption ring (Keep/Start/Try/Stop), quadrant, and Tikal's "Why?" opinion — plus Tikal-aligned alternatives for anything on Stop. Auto-triggered whenever a technology, framework, database, library, or cloud tool is being chosen or evaluated. Fetches the live radar best-effort and falls back to a bundled snapshot at resources/radar.json.

User-invoked. Multi-repo workspace coordination for shared team context.

• workspace — Discover child repos at depth 1 and optionally link them as Git submodules, creating a multi-repo workspace analogous to VS Code's .code-workspace. The parent repo holds shared PDRs, ADRs, and CDRs under .adlc/ (created by product-specify, architect-specify, levelup-specify); child implementation repos are linked for unified context. Commands: /workspace (discover), /workspace --link (register submodules), /workspace --status (audit: branch, dirty, unpushed, SHA drift). No workspace.yml — pure auto-discovery by convention. Say "Set up multi-repo workspace" or /workspace --link.

---

Output File Layout

All skills write to .adlc/ (project root) and the team AI directives repo.

Team Directives (inside the team AI directives repository):

• AGENTS.md — agent instructions (loading order, rules, skills)
• CDR.md — index of approved context contributions
• .skills.json — skills manifest (schema v2.0.0)
• .mcp.json.example — MCP servers config example
• context_modules/constitution.md — team constitution (OKF frontmatter)
• context_modules/{rules,personas,examples}/**/*.md — context modules
• context_modules/{type}/index.md — progressive disclosure per concept type
• context_modules/{type}/log.md — chronological change log per concept type
• skills/{name}/SKILL.md + .skills-entry.json — published team skills
• evals/{directive-id}/goldset.md + goldset.json — directive compliance goldensets

LevelUp (inside .adlc/ of the target project):

• .adlc/drafts/cdr/CDR-{NNN}.md — proposed/discovered CDRs (including eval CDRs)
• .adlc/drafts/cdr/cdr.md — auto-generated CDR index
• .adlc/init-options.json — team AI directives path config

Product (inside .adlc/ and repo root):

• .adlc/drafts/pdr/PDR-{NNN}.md — proposed/discovered PDRs
• .adlc/drafts/pdr/pdr.md — auto-generated PDR index
• .adlc/memory/pdr/PDR-{NNN}.md — accepted/completed PDRs
• .adlc/memory/pdr/pdr.md — accepted PDR index
• .adlc/product/sections/{feature-area}/{section}.md — PRD section build artifacts
• .adlc/product/state.json — DAG execution state
• PRD.md — Product Requirements Document (repo root)

Architecture (inside .adlc/ and repo root):

• .adlc/drafts/adr/ADR-{NNN}.md — proposed/discovered ADRs
• .adlc/drafts/adr/adr.md — auto-generated ADR index
• .adlc/memory/adr/ADR-{NNN}.md — accepted ADRs
• .adlc/memory/adr/adr.md — accepted ADR index
• AD.md — Architecture Description (repo root)
• .adlc/architect/ — per-view DAG artifacts

Missions (inside .adlc/ of the target project):

• .adlc/workflow/workflow-config.yml — mission execution/supervision/budgets config
• .adlc/workflow/.mission-state.json — step list, completed steps, brief, discovery results
• .adlc/workflow/runs/<feature>/mission-log.json — final audit trail
• .adlc/workflow/runs/<feature>/iterations.md — per-implement audit entries

Governance (inside target project and repo root):

• .adlc/drafts/evals/EVAL-{NNN}.md — proposed/discovered eval criteria drafts
• .adlc/drafts/evals/evals.md — draft evals index
• .adlc/memory/evals/EVAL-{NNN}.md — accepted/completed eval criteria
• .adlc/memory/evals/evals.md — accepted evals index
• .adlc/memory/evals/holdout.json — isolated/reserved holdout test dataset
• evals/{system}/goldset.md — published goldset (human-readable)
• evals/{system}/goldset.json — published goldset (machine-readable)
• evals/{system}/config.yml — evaluation framework configuration
• evals/{system}/config.{js,py} — framework test config
• evals/{system}/graders/check_*.py — generated binary Python graders / metrics
• evals/{system}/tests/test_check_*.py — generated unit tests verifying grader correctness
• evals/results/validation_report.md — statistical validation results report

Workspace (inside parent repo root):

• .gitmodules — Git submodule registrations for child repos (created by --link)
• .adlc/ — shared team context (PDRs, ADRs, CDRs); parent is the single source of truth
• Child repos discovered at depth 1; each child's .adlc/ presence is reported (informational)

OKF Compliance

Generated context modules include Open Knowledge Format (OKF) v0.1 compliant frontmatter alongside custom fields.

OKF field	Status	Source
type	✅	CDR context type
title	✅	CDR title
description	✅	CDR descriptor
resource	✅	Relative path to artifact
tags	✅	Context type tag
timestamp	✅	ISO 8601 datetime

Custom fields co-exist with OKF frontmatter: id, cdr_ref, created, modified, verified, age_days, evidence.

Directory structure: context_modules/{type}/index.md (progressive disclosure), context_modules/{type}/log.md (change history), cross-links between related concepts.

Workflows

Team Directives setup:

team-setup → team-constitution → team-boot (auto at session start)

Product lifecycle:

Brownfield: product-init → product-clarify → product-implement → product-analyze
Greenfield: product-specify → product-clarify → product-implement → product-analyze
Roadmap:    product-roadmap (anytime)

Architecture lifecycle:

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

LevelUp / CDR lifecycle:

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 (review deletion CDRs)

Mission:

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

Multi-repo workspace:

product-specify / architect-specify → create shared PDRs/ADRs in parent .adlc/
workspace --link → register child repos as submodules
workspace --status → audit branch, dirty, unpushed, SHA drift

Application Evaluation lifecycle:

Greenfield (Spec-Driven): evals-init → evals-specify (from spec) → evals-clarify → evals-implement → evals-validate
Brownfield (Error-Driven): evals-init → evals-specify (from failures) → evals-clarify → evals-implement → evals-validate → evals-analyze

Full product → architecture → team:

Product:     product-specify → product-clarify → product-implement → product-analyze
Architecture: architect-specify → architect-clarify → architect-implement → architect-analyze
Team:        levelup-specify → levelup-clarify → levelup-publish → team-repair

12-Factor Alignment Factor	Skills	How
III — Mission Definition	Product skills	PRD/PDR lifecycle ensures product decisions are documented, reviewed, and traceable before execution
IV — Structured Planning	Architecture skills	ADRs and AD.md provide structured planning artifacts using Rozanski & Woods viewpoints
VII — Verification-First Evals	LevelUp + Evals skills	LevelUp creates directive-compliance eval CDRs; evals skills build and run application-level evaluation suites (PromptFoo/DeepEval) with binary graders, holdout splits, and statistical validation
VIII — Ratchet Effect	LevelUp + Evals skills	Each session extracts eval CDRs alongside directive CDRs; each goldset publication adds criteria that monotonically increase quality — evals-clarify publishes, evals-validate enforces
IX — Traceability	Product + Architecture	Every decision traces from PDR → PRD → feature and from ADR → AD → code
X — Context Engineering	Team Directives	team-boot assembles constitution, CDR index, and PDR/ADR indexes into the system prompt at session start; team-discover provides manual re-scan
XI — Directives as Code	Team + LevelUp + Product + Architecture	All directive lifecycles (CDR, PDR, ADR) live in version-controlled repos, each with draft → clarify → accept → publish → analyze stages
XII — Build to Delete	team-repair + evals-analyze	--build-to-delete runs evals without directives via LLM calls; if model passes, proposes deletion (Harness Decay); evals-analyze routes spec failures to levelup-specify (rules) and generalization failures to the evaluator backlog — the feedback loop that makes build-to-delete verifiable

---

See RELEASE.md for the release runbook, tag naming conventions, and recovery procedures.

MIT — see LICENSE.