mcpField
T
team-boot

team-boot

github.com/tikalkAgent 工作流143188 次安装今天更新
代码仓库

关于 team-boot

team-boot 是一项在 Agent 会话中载入团队指令与决策上下文的技能,并按需补充记录类别信息。它面向使用 ADLC 记录的团队,支持自动会话钩子和手动备用流程。

主要功能

  1. 01会话开始时注入团队上下文
  2. 02按需载入记录类别索引
  3. 03将决策记录为草稿
  4. 04用表格跟踪上下文与决策
  5. 05支持自动钩子与手动备用流程

适用场景

  1. 01开始任务前查看相关团队指令
  2. 02确定架构方案或产品范围
  3. 03实施期间记录决策

MCP 相关

该技能会将 MCP 服务列表纳入注入会话的团队上下文。

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/tikalk/adlc-team-skills --skill team-boot

安装后在 Claude Code 中输入/team-boot确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

references/
decision-capture.md
manual-fallback.md
scripts/bash/
boot.sh
scripts/powershell/
boot.ps1

详细介绍

team-boot

概述

在会话开始时,组装团队 AI 指令上下文并将其注入系统提示词。 CDR 索引列出了所有可用团队上下文模块及其描述符——当任务匹配时, 按需读取完整模块文件。

team-boot 只注入始终相关的层:章程标题、 精简的 CDR 索引、Class Boots 目录、技能注册表和 MCP 服务。四种记录类别(ADR/PDR/ChDR/CDR 深入内容) 以及技术选型会通过下方的 Class Boots 按需加载——每个 Boot 都会将索引注入与决策记录相结合。

发现是原生的:LLM 会在每个提示词中自行将注入的 CDR 索引 与当前任务进行匹配,无需调用技能。 /team-discover 是单独的、由用户调用的命令,用于显式的 结构化重新发现(例如,开始一项复杂功能时),不属于 引导流程的一部分。

**快速通道:**如果团队 AI 指令上下文(章程、CDR 索引、 Class Boots 目录)已经位于系统提示词或第一条用户消息中, 则事件钩子已经运行——无需执行任何操作。

Class Boots

Boot注入内容调用时机记录方式
architect-bootADR 索引(docs/adlc/memory/adr/ + 旧版 .adlc/memory/adr/)架构工作;技术栈/模式选择直接写入 .adlc/drafts/adr/
product-bootPDR 索引(docs/adlc/memory/pdr/ + 旧版 .adlc/memory/pdr/)产品/功能范围、用户画像、变现直接写入 .adlc/drafts/pdr/
change-bootChDR 索引(docs/adlc/memory/chdr.md + 旧版 .adlc/memory/chdr.md)变更历史原因、回滚、关联问题的提交直接写入 .adlc/drafts/chdr/
team-levelupCDR 模块正文(team-ai-directives)会话结束;匹配 CDR 描述符;可复用的团队模式直接写入 adlc 分支 drafts/cdr/
tech-radar-bootTikal Tech Radar 上下文选择/评估技术Radar 上下文 + 直接写入 .adlc/drafts/adr/

当任务或决策符合某一行时,调用相应的 Class Boot——应在匹配任务 开始时调用,在制定待办事项列表和开始实现之前,以便类上下文能为规划提供依据。 切勿推迟到会话结束时。如果当前工作目录中不存在本地记忆索引,且该目录位于 某个工作区内(通过祖先目录中的 .gitmodules 标记检测),Boot 会改为读取工作区根目录的 docs/adlc/memory/ 索引。每个 Boot 都会输出其类别上下文部分和自身的搜索行 (_Searched N <class> records, K matched._),并包含该类别的完整 检测与记录指导。匹配到 0 行时,Boot 只输出其部分标题和搜索行——不输出表格。

事件钩子(自动)

session_start 和 session_compact 事件钩子(在 .events.json 中声明,由 adlc-cli 接线)会运行 scripts/bash/boot.sh(POSIX)或 scripts/powershell/boot.ps1(Windows),读取 .adlc/init-options.json, 组装上下文块(章程、CDR.md 索引表、 .skills.json),并将其输出到 stdout。插件会缓存结果, 并在每个步骤中将其推送到系统提示词(幂等——使用相同的 缓存内容,不会累积)。声明 session_compact 会将 压缩后的重新注入纳入约定:当运行环境 总结历史记录时,生成的插件会重新运行处理器,去重 保护机制可防止重复注入。适配器尚未映射 session_compact 的 Agent 会跳过此钩子——这些映射由 adlc-cli 负责。

手动回退(适用于不支持事件的 Agent)

  1. 从当前工作目录读取 .adlc/init-options.json。 不要遍历父目录。不要使用 glob、find 或任何 文件搜索工具来查找它。
  2. 如果尚未配置(文件缺失、值为 null 或路径不存在):调用 team-setup 技能。
  3. 如果当前会话中已安装 factory-setup 技能,且仓库根目录下未解析到 .adlc/issues-provider.yml:询问用户是否现在运行 /factory-setup(提供方选择由问题驱动, 与 team-setup 模式相同)。如果用户拒绝,则本次会话跳过—— 有意不设置持久性退出标记。
  4. 如果已配置:组装上下文并遵循上面的 Class Boots 目录。完整流程见 references/manual-fallback.md。

决策记录

发现决策时,直接在会话期间将轻量级草稿写入 .adlc/drafts/{type}/ — 无需调用 specify 技能。 唯一的门槛是在会话结束时进行澄清。

检测触发条件
模式类型草稿写入位置通过以下方式澄清
技术栈选择、模式选择、“我们选择 X 而不是 Y”decisiondrafts/adr//architect-clarify
功能范围、用户画像、变现productdrafts/pdr//product-clarify
可复用的团队规则、“我们总是这样做”patterndrafts/cdr//team-levelup
回滚/热修复理由、关联 issue 的提交、带有人工编写说明的 git 命令、编写的 PR 标题/正文、CHANGLEOG 编辑incidentdrafts/chdr//change-clarify
已采用的变通方案、“暂时采用 X,因为 Y”workarounddrafts/chdr//change-clarify
运行约束、“之所以能运行只是因为 Z”constraintdrafts/adr//architect-clarify
放弃的变更、“简化 X,但 Y 阻碍了它”abandoneddrafts/chdr//change-clarify
发现评估标准evaldrafts/evals//evals-clarify

比例原则和信任模型见 references/decision-capture.md: 根据决策的非显而易见程度匹配文档深度,并综合项目知识 — 切勿照抄指令。

团队上下文与决策(每条回复)

每条回复都包含一个合并部分 — 在同一个 6 列表格中列出上下文依据行和待处理决策行:

## Team Context & Decisions

| ID | Name | Type | Rel | Status | Clarify |
|--|--|--|--|--|--|
| CDR-YYYY-NNN | <name> | <type> | <relevance> | in use | — |
| — | <decision> | <ADR/PDR/CDR/ChDR/Eval> | <trigger> | pending | <clarify skill> |

_Scope: N CDRs · A ADRs · P PDRs · C ChDRs · E evals · M skills — J rows shown · Unrecorded: N pending · Unclarified: M captured drafts._

状态为 in use 且澄清为 — = 上下文依据(仅已接受的记录)。 状态为 pending/captured/clarified/handed off 且包含澄清技能 = 待处理 决策。草稿行不得使用状态 in use — 草稿仅作为待处理决策行显示。J = 显示所有行。

  • 检测:根据上述触发条件匹配会话中的决策。
  • 分类:指定记录类型(ADR/PDR/CDR/ChDR)。
  • 写入:使用对应类型的草稿模板,直接将轻量级草稿写入 .adlc/drafts/{type}/。
  • 跟踪:更新表格行(ID = 草稿 ID 或 —,状态 = pending/captured/clarified/handed off,澄清 = 对应技能)。
  • 呈现:将每个检测到的决策同步为任务列表待办事项(草稿 → 会话结束时运行对应的澄清技能)。完成修改代码的任务后,添加一条末尾待办事项,检查“团队上下文与决策”,直到达到 Unrecorded: 0 pending · Unclarified: 0 drafts(草稿只有通过其澄清技能或用户明确将其移交给指定的澄清或执行技能,才能从 Unclarified 中移除)。
  • 会话结束:结束前,给出澄清提示,列出每份已记录草稿(ID + 澄清技能);如果用户推迟澄清,则将这些行标记为 handed off。

Specify 技能(/architect-specify、/product-specify 等)仍可用于交互式深入探索,以获得引导式权衡分析 — 但常规记录无需使用这些技能。

故障处理

  • 缺少索引且缺少记录 → 仅输出章节标题 + _Scope: 0 CDRs · 0 ADRs · 0 PDRs · 0 ChDRs · 0 evals · 0 skills — 0 rows shown._ — 不要输出表格 — 然后继续用户的任务;绝不阻塞。
  • 索引行无法解析 → 跳过格式错误的行,并注明跳过数量。

验证

  • 已输出 Team Context & Decisions,格式为 _Scope: N CDRs · A ADRs · P PDRs · C ChDRs · E evals · M skills — J rows shown · Unrecorded: N pending · Unclarified: M captured drafts._ (J = 显示的所有行;Status=in use 的行仅包含已接受的记录,决策行带有澄清技能。)
  • 已在任务开始时触发 Class boots(在待办规划之前),绝不延后; 当 CWD 没有本地记忆时,已启用工作区根目录回退。
  • 已将检测到的决策作为表格行添加,并附上匹配的澄清技能。
  • 已将检测到的决策同步为任务列表中的待办项;代码修改任务后已添加收尾账本清理 待办项;仅当达到 Unrecorded: 0 pending · Unclarified: 0 drafts 且已交付会话结束时的 澄清提示后,才关闭清理任务。

未配置的项目

调用 team-setup,为此项目配置团队 AI 指令。

如果已安装 factory 技能,但未解析出任何提供方配置,请询问是否运行 factory-setup。

评论

支持 Markdown