team-levelup

team-levelup

此技能的作用

会话结束时的 CDR 生命周期——从已完成的会话中提取可复用模式，根据置信度评分，集中呈现以供审核，并将接受的 CDR 作为草稿 PR 发布到 team-ai-directives。

用一个精简的工作流取代原有的 levelup-specify、levelup-clarify 和 levelup-publish 技能。

已搜索 N 个 CDR，K 个匹配。 如果匹配 0 行 → 仅输出章节标题和搜索行，不要输出表格。0 行的表格标题会折叠成无法渲染的单行 Markdown；切勿输出此类表格。

如果当前工作目录中没有本地上下文模块记录，且该目录位于某个工作区内（通过某个上级目录中的 .gitmodules 标记检测），则读取工作区根目录中的记录。

使用时机

在匹配的任务开始时调用——在规划待办列表和开始实现之前——以便 CDR 上下文为规划提供参考。 切勿推迟到会话结束时再调用。

• 会话结束时（自动）：.events.json 将 session_end 映射到此技能
• 手动调用：完成工作后运行 /team-levelup
• 关闭分支前：提取团队级经验

不适用时机

• 棕地项目探索：使用 /team-init 扫描现有代码
• ADR/PDR/ChDR 记录：使用相应的澄清技能（architect-clarify、product-clarify、change-clarify）

存储

CDR 草稿位于 team-ai-directives 的 adlc 孤立分支中：

team-ai-directives (adlc branch, orphan)
├── drafts/cdr/
│   ├── CDR-001.md        # Pending CDR
│   └── cdr.md            # Draft index
└── reports/
    ├── sessions/<user>/<YYYY-MM>.md
    ├── projects/<project>.json
    └── confidence-scores.json

主分支中没有草稿目录——只有 context_modules/ 中已接受的 CDR。

流程

阶段 0：环境设置

运行设置脚本：

scripts/bash/team-levelup.sh --setup

解析 JSON 中的 REPO_ROOT、TEAM_AI_DIRECTIVES、NEXT_CDR、ADLC_BRANCH_EXISTS。

如果未配置 TEAM_AI_DIRECTIVES，则退出并提示运行 /team-setup。

阶段 1：从会话中提取 CDR

检查当前会话，识别可复用模式：

1. 用户提出了什么需求？
2. Agent 做了什么？（文件更改、关键决策、方法）
3. 出现了哪些可复用模式？
4. 创建或修改了哪些文件？（git diff --stat、git log --oneline -10）

对每种模式，使用共享模板 skills/team/templates/cdr-draft-template.md 创建 CDR 草稿。

将会话追踪记录写入 adlc 分支：reports/sessions/<user>/<YYYY-MM>.md。

阶段 2：评估置信度

为每个提取出的 CDR 计算置信度：

按类型划分的基础分数：

• 规则：0.60
• 人设：0.50
• 示例：0.50
• 宪章：0.70

加分项：

• +0.20：存在配套评估
• +0.10：证据包含文件路径/提交记录
• +0.10：多个项目引用了相同模式

使用乘数（来自 reports/confidence-scores.json）：

• success_rate > 0.8：×1.2
• success_rate 0.5-0.8：×1.0
• success_rate < 0.5：×0.8

阈值：

• ≥ 0.8：高——集中审核，审核后自动接受
• 0.5-0.79：中——必须集中审核
• < 0.5：低——保留为草稿

阶段 3：集中审核

逐个呈现 CDR（与之前的 team-learn 逻辑相同）：

## CDR-{ID}: {Title}

**Context Type**: {type}
**Confidence**: {score} ({HIGH/MEDIUM/LOW})
**Current Status**: {status}

### Current Content
...

### Choose Action

| Option | Action |
|---|---|
| A | Accept — Approve for implementation |
| B | Reject — Decline with reason |
| C | Defer — Skip for now, keep pending |
| D | Accept all remaining — Accept this and all pending CDRs |
| P | Promote to check (mechanical rules only) |

Reply with your choice (A/B/C/D/P).

等待用户输入后再继续。每次决策后更新 CDR 文件。

缺少上下文时

如果本次会话中 team-boot 未注入团队上下文（首条用户消息中没有 Team Context & Decisions 部分——项目未配置或钩子失败）：用一行说明此情况，在 Team Context & Decisions 中保留相应行，并添加来源行 0 CDRs matched (no team context injected — run /team-setup)，然后继续处理任务，直接读取 CDR 模块。绝不要将缺少注入视为记录集为空。恢复方法：运行 /team-diagnose。

阶段 4：发布

对于已接受的 CDR，向 team-ai-directives 主分支创建草稿 PR：

1. 切换到 adlc 分支工作树
2. 从 drafts/cdr/ 读取已接受的 CDR
3. 转换为带置信度前置元数据的 OKF v0.2 格式
4. 写入主分支的 context_modules/
5. 创建分支、提交、推送并打开草稿 PR

阶段 5：写入使用数据

写入 adlc 分支：

• reports/sessions/<user>/<YYYY-MM>.md — 已清除隐私信息的会话摘要
• reports/projects/<project>.json — CDR 匹配/应用次数
• 更新 reports/confidence-scores.json

阶段 6：通知

将报告写入 .adlc/team-levelup-report.md（本地，不提交）：

## Team-Levelup Report

**Date**: {date}
**CDRs Extracted**: N
**CDRs Accepted**: N
**CDRs Rejected**: N
**CDRs Deferred**: N
**PR**: {URL or "none — no accepted CDRs"}

### Next Steps
1. Review PR (if created)
2. Run `/team-repair --update-confidence` after merge

冲突解决

当两个项目起草了相同模式时：

1. 第一个草案创建 CDR-001，并设置 project: project-a
2. 第二个草案检测到描述符匹配的现有 CDR → 合并：
   • 将 project-b 添加到 project: 字段
   • 追加证据部分
   • 提高置信度（多项目验证）

团队上下文与决策

team-levelup 与 team-boot 维护的 Team Context & Decisions 集成。 会话期间检测到的 CDR 类决策会作为记录建议显示（运行 /team-levelup 以写入草案 — boot 绝不会写入），并 作为表格行进行跟踪。将每个 CDR 类决策镜像为任务列表待办事项 （建议记录 → 在会话结束时运行 /team-levelup）；完成修改代码的任务后，添加一个 收尾待办事项，以检查 Team Context & Decisions，直到 Unrecorded: 0 pending · Unclarified: 0 drafts（草案只有通过其澄清技能，或用户明确将其移交给指定的澄清或执行技能，才能从 Unclarified 中移除）。在会话结束时，提供澄清提示，列出每项尚未记录的决策（ID + 记录技能）以及每份已记录的草案（ID + 澄清技能）；如果用户推迟澄清，将这些行标记为已移交。不要捏造 表格行 — 只记录会话中实际产生的决策。

验证

• CDR 已写入 adlc 分支的 drafts/cdr/
• 会话摘要已写入 adlc 分支的 reports/sessions/
• 使用次数已写入 adlc 分支的 reports/projects/
• 已接受的 CDR 已作为草案 PR 发布到 main 分支
• team-levelup-report.md 已在本地写入
• main 分支中没有草案