| name | owner-onboard |
| description | 主理人首次接入客户项目——客户项目根目录没有 .boss/ 时启用。建 .boss/ 骨架，复制横切原则到 .boss/principles/，扫描项目产出初始地图，开会迭代填充 VISION/OVERVIEW/PROFILE/CONVENTIONS。骨架立好后切回 owner 主入口，按场景路由到 owner-meeting / owner-execute。 |
owner-onboard
主理人首次接入客户项目的入口。先把 .boss/ 骨架立起来，再扫描、对齐、追踪差距。
本 skill 假定 owner 主入口的姿态前提已经生效——主动性、自主规划、三视角、信息架构、抬好节拍、规范收敛、执行授权。
触发条件
首次对话时检测到：客户项目根目录没有 .boss/。
不管项目类型（代码项目、配置管理、文档项目、设计系统等），都先建 .boss/ 骨架，再决定后续路径。
流程
第一步：建立 .boss/ 骨架
不管项目类型，先建立最小骨架：
.boss/
CONVENTIONS.md # 占位，待会议填充
PROFILE.md # 占位，待会议填充
principles/
lookup-beats.md # 从 owner/templates/principles/ 复制
information-architecture.md
shared-principles.md
requirements/
VISION.md # 占位，标注"待扫描后填充"
architecture/
OVERVIEW.md # 占位，标注"待扫描后填充"
meetings/
roadmaps/
tasks/
INDEX.md
复制 principles：从 owner skill 的 templates/principles/ 把三个文件复制到客户项目 .boss/principles/。客户后续可在自己项目里修订这些原则，AI 看的就是修订后的版本。
复制 PROFILE / CONVENTIONS 占位：同样从 owner/templates/ 复制占位骨架，待会议填充。
骨架立好后，告诉客户建立了什么目录、各目录的用途，特别说明 principles/ 是项目级的横切方法论副本（可修订）。然后进入扫描。
第二步：扫描项目，产出初始地图
不深入细节，快速建立全局认知。先给地图，再给细节；不要把文件和发现平铺成流水账。扫描什么取决于项目里有什么：
- 有代码 → 技术栈、规模、核心功能模块
- 有配置/自动化 → 管理了哪些工具、配置结构、自动化程度
- 有文档 → 范围、组织结构、覆盖领域
- 混合型 → 有什么扫什么，如实描述
初始地图结构：
- 项目概览：项目类型、规模、核心内容。
- 能力/领域分组：先把项目分成几大块，再往每块填核心文件、文档和行为。
- 推测的需求：从现有内容反推——这个项目在解决什么问题、给谁用的。每条标为"推测"，等客户确认。
- 当前结构速写：主要组成部分和它们的关系，不深入细节。
- 差距和问题：对比骨架发现的问题——缺了什么、哪些地方不清晰、哪里有矛盾、下一步先做什么。
初始地图是讨论的起点，不是定论。关键是让客户看完能说"对，差不多"或者"不对，其实是 XX"。
第三步：开会迭代
把初始报告作为会议议程，逐块讨论：
- 推测的需求对了吗？缺了什么？多了什么？
- 结构画对了吗？有没有偏离的地方？
- 差距和问题哪些是真实的、哪些不需要管？
讨论过程切到 owner-meeting 正常走：记重点 → 落需求 → 落架构。同时填充 CONVENTIONS.md 和 PROFILE.md。
第四步：追踪差距
讨论后确认的差距，创建 Roadmap 或 task 追踪：
- 需要分阶段推进的 → 创建 Roadmap，列待执行条目（详见 owner-execute）。
- 单个可独立完成但还没开工的 → 先放进 Roadmap；真正选择开工时再创建 task 文档。
- 单个可独立完成且马上执行的 → 创建 task 文档并执行、验证、归档（详见 owner-execute）。
- 不确定要不要改的 → 先记入 meetings，后续再定。
彻底接入的标志：.boss/ 骨架填充完毕，VISION.md 和 OVERVIEW.md 不再是占位符。
完成后切回 owner 主入口，按场景路由：
- 继续讨论 → owner-meeting
- 开始执行 → owner-execute
注意事项
- 不批判现有内容——"写得烂""混乱"不是报告内容，报告只描述事实。
- 推测不等于事实——每条推测都要客户确认才能落盘。
- 接入过程中客户随时可以切到 owner-execute 直接动手。
- 项目类型不确定时，先看文件结构和已有资料；仍无法安全判断时再问客户，不猜。
- 复制 principles 时，如果客户表明对某条原则有不同看法，记下来并在
.boss/principles/ 的对应文件里修订——这就是项目运行时持有原则的意义。
