用途
levelup-init 用于从已有代码库（brownfield）中逆向工程出 Context Directive Records（CDR），记录可复用的模式，作为对 team-ai-directives 的潜在贡献。它像一名“上下文考古学家”，从代码中发现隐含的团队模式。
它适用于：Brownfield 项目（已有代码但缺少团队级指令）；遗留系统现代化（在重构前抽取可复用模式）；团队入职（把隐性约定变成显性指令）；团队 AI 指令库的引导填充（为新 team-ai-directives 仓库填充内容）。
不适用于：Greenfield 项目（应在实现功能后用 /levelup-specify）；从 git 历史或 issue 关联变更中挖掘过往决策（用 /change-init）；已存在 CDR 时（应使用 /levelup-clarify 审阅）。团队 AI 指令例行健康检查则用 /team-repair。
主要能力
- 扫描代码库，寻找可复用的规则、角色、示例、可作为技能的能力，以及可评测的模式。
- 检测跨子系统模式和实现不一致。
- 为每个指令 CDR 额外抽取一个配对的 eval 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 从已完成功能的 spec/plan/tasks 中抽取模式。本技能聚焦现状分析——什么是可复用的，而非应该创建什么。
使用方式
接受用户输入 $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：跳过 constitution 生成阶段。
执行流程分为十个阶段：
- 校验环境：确保 team-ai-directives 已配置。可从仓库根运行 scripts/bash/setup-levelup-init.sh，并解析其 JSON 输出中的 REPO_ROOT、CDR_DRAFTS_DIR、TEAM_AI_DIRECTIVES、NEXT_CDR 等；若脚本不可用则手动解析。
- 子系统检测：从代码结构识别子系统（如 src/auth/、services/payment/、monorepo 的 apps/api/ 等）。按数量阈值处理：0 个按单块推进；1-3 个可自动确认；4-6 个必须展示摘要并请求确认；>6 个必须建议分组并请求确认。
- 环境设置：确保目录存在并初始化 state.json。
- 载入团队指令：读取现有 team-ai-directives 用于比较（constitution.md、rules、personas、examples、skills）。 5-7. 多智能体分析：按子系统依次运行 Discovery、Pattern、Synthesis 三个智能体。Synthesis 会识别跨切面（≥50% 子系统为高优先级 CDR）、不一致（同一关注点不同实现）、项目特有（仅 1 个子系统则低优先级或跳过）、空缺（高价值但不在团队指令中则推荐 CDR）。
- Constitution CDR 生成：在 .adlc/drafts/cdr/CDR-CONST-NNN.md 生成 Constitution CDR（若未跳过）。注意必须写入草稿目录，而非直接写入 team-ai-directives。
- CDR 生成：为每个高价值模式创建独立 CDR 文件，包含状态、日期、来源、跨系统元数据、目标模块、上下文类型、描述符、上下文、决策、证据等字段。从代码模式生成 eval CDR 时，抽取通过用例（展示模式被遵循的代码示例，带 file:line）、失败用例（不一致实现或缺失实现）、对抗用例（从代码上下文可识别的边界情况），用例自包含内联代码片段。
- 输出摘要：重新生成 cdr.md 索引并展示总结。
后续工作流
完成后必须运行 /levelup-clarify 校验发现的 CDR。完整的 brownfield 流程为：/levelup-init → 扫描代码库并检测子系统与模式 → 生成 CDR（状态 Discovered）→ /levelup-clarify 校验并接受/拒绝 → /levelup-publish 将接受的 CDR 编译成 team-ai-directives 的 PR → /team-repair 在合并后重新索引并校验。
关键规则与限制
- 基于证据：只记录代码中实际发现的模式，引用具体证据（文件路径、提交、代码片段），标注置信度（HIGH/MEDIUM/LOW），明确标记不确定项。
- 非破坏性：未经用户批准不覆盖现有 CDR；保留手动添加的 CDR 内容；若同一目标模块已有 CDR 则智能合并。
- 不编造拒绝理由：brownfield CDR 使用中性的“Common Alternatives”表述。
- 发布前需通过 Signal Gate：团队通用、高价值（每次未来使用节省 >30 分钟）、唯一（不与现有指令重复）、有证据（具体提交/文件）。
- 缺失事实：官方文档未提供具体的收费、价格、平台要求等信息。