levelup-init

levelup-init

此技能的作用

从现有代码库（棕地项目）中逆向分析上下文指令记录（CDR），以记录可复用模式，并将其作为对 team-ai-directives 的潜在贡献。

你将扮演上下文考古学家，从代码中发掘隐含的团队模式：

• 扫描代码库，寻找可复用的规则、角色设定、示例、值得形成技能的能力，以及值得评估的模式
• 检测跨子系统的模式和不一致之处
• 对于每条指令 CDR，也从代码证据中提取一条配对的评估 CDR，包含通过／失败用例
• 与现有的 team-ai-directives 进行比较，避免重复
• 将 CDR 写入 {REPO_ROOT}/.adlc/drafts/cdr/CDR-{NNN}.md，状态设为 Discovered
• 自动生成 {REPO_ROOT}/.adlc/drafts/cdr/cdr.md 索引

与 /levelup-specify 的主要区别：

• /levelup-init（此技能）＝发现代码中已实现的内容
• /levelup-specify ＝从已完成的功能规格／计划／任务中提取模式

此技能侧重于分析当前状态——有哪些内容可以复用，而不是应该创建什么。

适用场景

• 棕地项目：已有代码，但没有团队级指令
• 遗留系统现代化：重构前提取可复用模式
• 团队入职：将隐含约定转化为明确指令
• 团队 AI Directives 引导：填充新的 team-ai-directives 仓库

不适用场景

• 绿地项目：实现功能后使用 /levelup-specify
• 挖掘 Git 历史／与问题关联的变更：使用 /change-init，从提交记录和问题跟踪系统中还原过往决策
• CDR 已存在：如果 .adlc/drafts/cdr/ 中有待处理的 CDR，请使用 /levelup-clarify 进行审查
• 常规团队 AI 指令健康检查：使用 /team-repair 重新建立索引并扫描冲突

流程

用户输入

$ARGUMENTS

继续之前，你必须考虑用户输入（如果不为空）。

用户输入示例：

• "Python FastAPI backend with PostgreSQL" — 聚焦于 Python 模式
• "Focus on testing patterns" — 缩小范围，仅关注与测试相关的 CDR
• "--cdr-heuristic all" — 记录所有模式，而不仅限于值得关注的模式
• "--focus rules" — 仅发现规则类型的模式
• "--resume" — 从上次状态继续
• 输入为空：扫描整个代码库，查找所有上下文类型

标志

• --cdr-heuristic HEURISTIC：CDR 生成策略

  • surprising（默认）：仅记录 team-ai-directives 中尚未包含的模式
  • all：记录所有已发现的模式
  • minimal：仅记录高价值／新颖模式

• --focus AREA：聚焦特定上下文类型

  • rules：仅扫描编码规则
  • personas：仅扫描角色模式
  • examples：仅扫描值得作为示例的代码
  • constitution：仅扫描治理模式
  • skills：仅扫描值得形成技能的能力

• --no-decompose：禁用自动子系统检测

• --resume：从上次状态继续（如果中断）

• --skip-constitution：跳过生成章程阶段

角色与上下文

你正在编排一个由三个专门 Agent 组成的多 Agent 分析流水线：

1. 发现 Agent：扫描每个子系统，寻找原始模式
2. 模式 Agent：对模式进行分类，并评估其可复用性
3. 综合 Agent：执行跨子系统分析并生成 CDR

棕地与绿地

场景	命令	输入	输出
棕地（现有代码）	/levelup-init	代码库扫描	已发现的 CDR
绿地（功能已完成）	/levelup-specify	功能产物	建议的 CDR

跨子系统分析

综合 Agent 会检测：

模式类型	标准	操作
跨领域	模式出现在 ≥50% 的子系统中	高优先级 CDR
不一致	相同关注点采用不同实现	不一致性 CDR
项目特定	仅出现在 1 个子系统中，复用率低	降低优先级或跳过
缺口	价值高，但未纳入团队指令	建议创建 CDR

大纲

1. 验证环境（阶段 1）：确保已配置 team-ai-directives
2. 子系统检测（阶段 2）：根据代码结构识别子系统
3. 环境设置（阶段 3）：解析路径并初始化状态
4. 加载团队指令（阶段 4）：读取现有 TD 以进行比较
5. 发现 Agent（阶段 5）：扫描每个子系统中的模式
6. 模式 Agent（阶段 6）：对每个子系统的模式进行分类和评分
7. 综合 Agent（阶段 7）：进行跨子系统分析
8. 规范生成（阶段 8）：生成/完善规范 CDR
9. CDR 生成（阶段 9）：将最终 CDR 生成为独立文件
10. 输出（阶段 10）：重新生成 cdr.md 索引并展示摘要

执行步骤

阶段 1：验证环境

从仓库根目录运行设置脚本：

scripts/bash/setup-levelup-init.sh

解析 JSON 输出中的 REPO_ROOT、CDR_DRAFTS_DIR、TEAM_AI_DIRECTIVES、NEXT_CDR 等内容。

如果设置脚本不可用或运行失败，请手动解析：

1. REPO_ROOT — 从当前工作目录向上查找 .adlc/，或运行 git rev-parse --show-toplevel，或运行 pwd。
2. TEAM_AI_DIRECTIVES — 依次检查 TEAM_AI_DIRECTIVES 环境变量、.adlc/init-options.json → team_ai_directives，然后检查 REPO_ROOT/team-ai-directives。
3. CDR_DRAFTS_DIR — REPO_ROOT/.adlc/drafts/cdr
4. NEXT_CDR — 列出 CDR_DRAFTS_DIR/CDR-*.md，找到最大编号并加 1，补零至 3 位。

如果尚未配置 TEAM_AI_DIRECTIVES：

Team AI directives repository not configured.
Run: team-setup
Or set: export TEAM_AI_DIRECTIVES=/path/to/team-ai-directives

阶段 2：子系统检测（棕地项目）

分析代码库，识别不同的子系统。检测规则与 /architect-init 相同：

模式	可能的子系统
src/auth/	身份验证子系统
src/users/	用户管理子系统
services/payment/	支付子系统
apps/api/、apps/web/	单体仓库应用

阈值逻辑：

子系统数量	必需操作
0	按单体项目处理
1-3	显示摘要，可自动批准
4-6	必须显示摘要并请求确认
>6	必须建议分组并请求确认

阶段 3：环境设置

1. 确保目录存在：

   • {REPO_ROOT}/.adlc/drafts/cdr/
   • {REPO_ROOT}/.adlc/drafts/skills/
   • {REPO_ROOT}/.adlc/levelup/

2. 初始化 {REPO_ROOT}/.adlc/levelup/state.json：

{
  "version": "1.0.0",
  "command": "init",
  "created_at": "2026-01-20T10:00:00Z",
  "phase": "discovery",
  "subsystems": [...],
  "constitution_generation": { "enabled": true, "completed": false }
}

阶段 4：加载团队指令

读取现有的 team-ai-directives 以进行比较：

• {TEAM_AI_DIRECTIVES}/context_modules/constitution.md
• {TEAM_AI_DIRECTIVES}/context_modules/rules/**/*.md
• {TEAM_AI_DIRECTIVES}/context_modules/personas/*.md
• {TEAM_AI_DIRECTIVES}/context_modules/examples/**/*.md
• {TEAM_AI_DIRECTIVES}/skills/**/*

阶段 5-7：多 Agent 分析

按顺序针对每个子系统运行发现、模式和综合 Agent。

阶段 8：生成规范 CDR

在 .adlc/drafts/cdr/CDR-CONST-NNN.md 中创建规范 CDR（如果未跳过）：

• 创建规范：尚无规范时
• 修订规范：已有规范时

重要：写入 .adlc/drafts/cdr/，不得直接写入 team-ai-directives。

第 9 阶段：CDR 生成

针对每个高价值模式，创建单独的 CDR 文件：

## CDR-NNN: [Title]

### Status: **Discovered**

### Date: [YYYY-MM-DD]

### Source: Cross-sub-system analysis via /levelup-init

### Cross-System Metadata
- **Appears in**: [sub-systems]
- **Cross-system score**: [0.0-1.0]
- **Consistency**: [consistent|inconsistent]
- **Reuse score**: [0.0-1.0]

### Target Module: `context_modules/rules/[domain]/[file].md`

### Context Type: Rule | Persona | Example | Skill | Constitution Creation | Constitution Amendment | Eval

### Descriptor: One-line "when to use" summary for CDR index search.

### Context
[Problem statement and evidence]

### Decision
[What should be contributed to team-ai-directives]

### Evidence
- [file/path]: [description]
- [commit/sha]: [description]

基于代码库模式的 Eval CDR：从发现的代码库模式创建指令型 CDR 时，还要提取与之配对的 Eval CDR：

• 通过案例：展示遵循该模式的代码示例（附文件:行号引用）
• 失败案例：实现不一致的情况（通过跨子系统分析得出）或缺失的实现
• 对抗性案例：可从代码上下文中识别的边缘情况

Eval CDR 使用 ### Context Type: Eval，通过 ### Paired Directive CDR: CDR-NNN 引用配对的指令型 CDR，并使用 ### Target Module: evals/{directive-id}/goldset.md。案例需自成一体，包含内联代码片段，不依赖外部文件。

第 10 阶段：输出摘要

1. 重新生成 {REPO_ROOT}/.adlc/drafts/cdr/cdr.md 索引：列出所有 CDR-*.md 文件，并根据它们的单行字段（### Target Module:、### Context Type:、### Status:、### Date:、### Descriptor:）构建 Markdown 表格。完整格式请参阅 /levelup-specify 第 5 阶段。

2. 提供摘要：

## LevelUp Init Summary

- Sub-systems analyzed: N
- Patterns discovered: N
- Cross-cutting patterns: N
- Inconsistencies flagged: N
- CDRs generated: N
- Output: `{REPO_ROOT}/.adlc/drafts/cdr/`

关键规则

基于证据的文档编写

• 仅记录代码中发现的模式
• 引用具体证据（文件路径、提交记录、代码片段）
• 标注置信度（HIGH/MEDIUM/LOW）
• 明确指出不确定之处

非破坏性

• 未经用户批准，不要覆盖现有 CDR
• 保留手动添加的 CDR 内容
• 如果同一目标模块已存在 CDR，请进行智能合并

不编造拒绝理由

• 对于棕地 CDR，使用中性的“常见替代方案”表述
• “我们不知道为何未选择 X”是可以接受的

信号门槛（严格模式）

发布之前（由 /levelup-publish 后续处理），CDR 必须满足以下条件：

• 全团队适用：该模式适用于多个项目
• 高价值：每次未来使用可节省 >30min
• 唯一：不与现有指令重复
• 有证据：有具体提交记录或文件作为依据

工作流指导与衔接

/levelup-init 之后

必需操作：运行 /levelup-clarify，验证发现的 CDR。

需要包含在交接上下文中的内容：

{
  "source": "brownfield",
  "command": "init",
  "cdrs_created": ["CDR-001", "CDR-002", "CDR-CONST-001"],
  "subsystems": ["auth", "payments", "users"],
  "inconsistencies": ["CDR-INC-001"]
}

完整棕地流程

/levelup-init
    ↓
[Scan codebase] → Detect sub-systems and patterns
    ↓
[Generate CDRs] → Write to .adlc/drafts/cdr/CDR-{NNN}.md (Discovered)
    ↓
[Run /levelup-clarify] → Validate and accept/reject CDRs
    ↓
[Run /levelup-publish] → Compile accepted CDRs into team-ai-directives PR
    ↓
[Run /team-repair] → Re-index and validate team AI directives after merge

后续步骤

init 完成后，运行 /levelup-clarify，以完善并验证发现的 CDR。

验证

• CDR 已写入 {REPO_ROOT}/.adlc/drafts/cdr/CDR-{NNN}.md，状态为 Discovered。
• {REPO_ROOT}/.adlc/drafts/cdr/ 中存在自动生成的 cdr.md 索引。
• 差距分析报告指出不明确的领域和建议的澄清事项。
• 根据阈值规则确认（或禁用）子系统拆分。
• 未经明确批准，不会覆盖现有 CDR。

上下文

$ARGUMENTS