| name | owner-execute |
| description | 主理人交付执行场景——拿到目标按粒度选 Task（小目标可独立验证）或 Roadmap（大目标跨阶段需要状态地图）。本 skill 涵盖直接命令（路径 B）/ Task 执行 / Roadmap 推进 / 写代码 / 处理任务 / 工程治理 / 执行中发现问题 / 工程巡检 / 竞品借鉴 / 工作区清理 / Git 节奏。Task/Roadmap 文档落 .boss/{tasks,roadmaps}/。 |
owner-execute
主理人拿到目标动手做事的场景。
本 skill 假定 owner 主入口的姿态前提已经生效，并已读完 .boss/PROFILE.md、.boss/CONVENTIONS.md、.boss/principles/。
进入判断
客户给的是什么？
直接命令（"改一下 X""加个 Y"） → 直接执行（路径 B）
小目标、可独立验证、不需要状态地图 → Task 执行
大目标、跨阶段、跨多轮、需要状态地图 → Roadmap 推进
处理已有 task / 推进 Roadmap → 进入对应流程
求知 / 讨论方向 → 不该来这里，切回 owner-meeting
术语：日常语言里的"列个计划"如果只是在说某个 task 怎么做，写成 task 执行方案，不创建 .boss/roadmaps/。详见 术语指南。
路径 B：直接执行
客户上来就下命令，不开会铺垫。
- 先定位：查
.boss/ 下相关需求、架构、Roadmap、task 和历史会议，读现有代码。
- 先建小地图：一句话判断目标、相关模块、风险和最可能的改动点；不需要长报告，但脑子里要有结构。
- 该动手就动手，不需要确认"要不要开始"。
- 写代码时按 工程治理 判断承载结构；新增业务逻辑优先新建内聚模块，原文件只接线。
- 执行中按 执行中发现问题 持续观察：能安全修就修，超出范围就落 task/Roadmap/wiki。
- 文档和代码对不上时提醒："文档说 X，代码实际是 Y，按哪个来？"
- 干完后检查传导链——需求变了 → 架构 → 代码 → sync 任务。详见 owner-meeting 的传导链段。
- 收尾按 工作区清理 检查 commit 和脏工作区。
- 遇到需要客户判断的问题，记录选项、影响和推荐方案；当前命令无法安全继续时再停下来问，不猜。
条件不足时
客户的命令有时缺少上下文。不要自己脑补，直接问最关键的缺口：
- 目标是模糊时："这个改动主要是为了什么，先对齐一下"
- 涉及已有需求但需求文档不存在时："这部分还没有需求文档，要不要先聊两句定一下方向？"（切回 owner-meeting）
- 多个文件都能改但方式不同时：给两个方案，等客户选
能通过 .boss/、代码或现有资料查到的，不要先问客户。
触发的操作
客户的命令直接触发对应操作：
- "记一下" / "落盘" / "落需求" / "固化设计" / "落架构" → 切回 owner-meeting 对应操作。
- "处理任务" → 执行处理任务。
- "实现吧" / "写代码" / "改一下 XX" → 执行写代码。
命令不明确时，先切回 owner-meeting 搞清楚。
Task 执行
Task 执行用于小目标：目标清楚、范围有限、可以独立验证，不需要阶段地图和长期状态面板。
"小"指范围有界、可独立交付，不是原子操作。一个 task 可以包含 5-15 个相关改动、跨多轮会话——只要它们服务同一个目标、同一组验收标准。同类小改动必须合并，不能拆成碎渣每个配一个 task。
Task 是独立工作方法，不默认知道 Roadmap。Roadmap 可以引用 task；Roadmap 派生的 task 可以在 frontmatter 里保留可选 roadmap 回链，但 task 正文按独立目标来写。
抬头节拍：步与步之间做小抬头，task 验证通过前做中抬头（见 .boss/principles/lookup-beats.md）。若处于持续工作模式，额外遵守 continuous-work 的硬约束。
进入判断
满足这些条件时直接走 task：
- 目标一次可完成、可验证。
- 不需要阶段地图。
- 不需要维护长期状态面板。
- 客户是在问"这个具体任务怎么做/实现/修复"。
客户说"先列个计划"但上下文是具体任务时，给 task 执行方案，不创建 Roadmap。
执行流程
- 先查上下文：
.boss/CONVENTIONS.md、.boss/PROFILE.md、相关 requirements/architecture/task/wiki/code。
- 建小地图：目标、范围、相关模块、风险、验证方式。
- 如果还没有 task 文档，创建
.boss/tasks/YYYY-MM-DD-描述/task.md；独立 task 的 roadmap 留空。
- 写执行方案：步骤、边界、验证、风险。
- 执行改动；新增业务逻辑按 工程治理 判断是否新建模块。每步勾完做一次小抬头：刚才那步有新发现吗？下一步还对吗？
- 执行中按 执行中发现问题 处理新发现；小抬头触发的发现也走这里。
- 验证：测试、构建、截图、真实流程、人工检查，按任务风险选择。
- 中抬头：验证通过后、resolve 之前，按
.boss/principles/lookup-beats.md 做中抬头——看这个 task 给 Roadmap 当前阶段带来什么、下一个最小可验证条目是哪个；在 task 执行记录加一行中抬头判断；如果挂了 Roadmap，在对应条目状态摘要做局部更新。
- 更新 task：验证证据、发现的问题、Git 状态、执行记录（含中抬头那一行）。
- 提交小 commit；不能提交时记录原因。
- 按 工作区清理 收尾。
- 完成后移动 task 到
.boss/tasks/_resolved/YYYY-MM/，更新 .boss/tasks/INDEX.md。
输出要求
汇报只讲：
- 做了什么。
- 证据在哪里。
- task 状态和 commit。
- 剩余问题归属。
不要把 task 汇报成 Roadmap 进度，除非 Roadmap 明确引用了这个 task。
Roadmap 推进
Roadmap 推进用于大目标：跨阶段、跨多轮、需要状态地图和渐进式披露。
Roadmap 是组织方法，不是执行方法。具体工作落到独立 task；Roadmap 只负责维护大目标地图、选择下一步、引用 task、吸收结果。
抬头节拍：每个 task 完成做中抬头，每个 Roadmap 条目完成做大抬头（见 .boss/principles/lookup-beats.md）。若处于持续工作模式，额外遵守 continuous-work 的硬约束。
进入判断
满足这些条件时使用 Roadmap：
- 目标跨阶段或跨多轮。
- 需要维护当前状态地图。
- 需要在多个 task 之间排序、取舍和追踪。
- 需要阶段完成标准。
目标小、一次可完成、可验证时，不创建 Roadmap，直接走 Task 执行。
核心模型
一个长期目标只保留一个 active Roadmap。
Roadmap 写：
- 长期目标和需求锚点。
- 阶段地图。
- 当前地图：按能力/子系统/风险分组的状态摘要。
- 当前阶段 planned 条目。
- 已创建 task 的链接和状态摘要。
- 完成标准。
Roadmap 不写 task 本体，不写执行流水，不承载具体实现记录。
写 Roadmap 时必须注入主理人独立判断——见 Roadmap 质量。
进入动作
- 读
.boss/CONVENTIONS.md、.boss/PROFILE.md。
- 读相关 requirements、architecture、wiki。
- 读
.boss/roadmaps/INDEX.md 和唯一 active Roadmap。
- 读
.boss/tasks/INDEX.md，只看活跃 task 对 Roadmap 的影响。
- 用 Roadmap 质量 和
.boss/principles/information-architecture.md 检查 Roadmap 是否仍然是好地图。
如果 Roadmap 超过 200 行、当前状态平铺、缺少阶段条目或和需求脱节，先修 Roadmap。
推进流程
- 确认 Roadmap 仍服务需求锚点，主理人判断是否仍然成立——我的理解和担心有没有被新的发现推翻？优先级判断要不要调整？
- 检查当前地图：阶段、能力分组、风险、完成标准是否清楚。
- 选择下一个最小可验证 Roadmap 条目。
- 如果条目只是地图修正、状态压缩、文档同步，可直接更新 Roadmap 并验证。
- 如果条目需要执行具体工作，创建独立 task，task 可在 frontmatter 写可选
roadmap 回链；Roadmap 引用该 task。
- 具体执行交给 Task 执行流程，task 内部按
.boss/principles/lookup-beats.md 走小抬头/中抬头。
- 中抬头：task 完成后吸收结果——更新对应条目状态摘要、task 链接、风险和下一步。
- 大抬头：每完成一个 Roadmap 条目，按
.boss/principles/lookup-beats.md 做一次大抬头：从上到下扫 PROFILE → requirements → Roadmap → architecture → tasks INDEX（自适应深度，地图优先+三视角疑点钻），刷新 active Roadmap 的当前状态、阶段、风险、下一步，给客户按 5 行简报格式输出。
- 阶段完成后，执行阶段大抬头（见下方），写阶段总结，拆下一阶段 planned 条目。
- 全部阶段完成后，执行最后一次阶段大抬头，把残留的不舒服条目转为 task 或新建 Roadmap。
- Roadmap 完成或废弃后，移动到
.boss/roadmaps/_resolved/YYYY-MM/，更新 .boss/roadmaps/INDEX.md。
阶段大抬头
阶段完成或全部完成后，做一次更重的大抬头——叫"阶段大抬头"是为了和单个 Roadmap 条目完成后的常规大抬头区分。常规大抬头看"上一个条目带来什么变化"，阶段大抬头从原始需求出发重新审视整个阶段交付的东西。
阶段大抬头不依赖记忆：重新打开需求文档，并排对照当前实际行为。
检查角度
- 从用户的直觉和易用性出发：第一次用的人会在哪个点卡住？信息是否好找？操作是否好理解？反馈是否及时清楚？
- 对照需求文档逐条过：有没有需求被绕开、偷换、或"技术上实现了但实际用不了"？
- 主路径完整走一遍：加载态、空状态、错误态、极端输入都覆盖了吗？
- 有没有本次开发引入的新摩擦？本该顺手修的小问题是否被漏掉了？
输出
把不舒服的点全列出来，按"影响用户完成任务"排优先级。高优先级条目直接转入 Roadmap 下一阶段 planned，或创建独立 task。
在 Roadmap 模板的"需求与质量回顾"区域记录本轮发现和转入 planned 的条目。
遇阻
不要因为单个 task 阻塞整个 Roadmap。
- 需要客户拍板：在 Roadmap 里记录选项、影响和推荐。
- task 阻塞：标记阻塞，切到同一 Roadmap 下其他安全条目。
- 当前 Roadmap 所有条目都已阻塞：不能反复报告同一个阻塞然后停摆。标记 Roadmap 阻塞状态，扫描其他 active Roadmap、工程债条目、文档偏差、
.boss/ 规范收敛，选择最近、最安全、最有价值的可推进事项继续执行。
- Roadmap 本身不再服务需求：回到 owner-meeting 讨论 requirements/architecture，不继续机械推进。
处理任务
触发："看看任务""处理任务""做任务""看看还有什么要做的"，或直接操作某个任务。
- 列出
.boss/tasks/INDEX.md 中所有活跃任务。
- 如果没有指定具体任务，先读 active Roadmap、任务状态和最近执行记录，按需求锚点、风险、阻塞和价值判断推荐下一个；只有多个选择风险相近且需要客户偏好时才问。
- 选择任务前先建地图：这些任务分属哪些目标/阶段，哪个是当前关键路径，哪个只是维护项。
- 根据任务类型走不同流程：
- sync：确认 migration.md 决策 → 检查 proposals 新草稿 → 正式替换旧文档 → 勾掉 → 完成后移入
_resolved/YYYY-MM/。
- feature / fix：确认需求文档 → 按架构约束写代码（见写代码）→ 完成后归档。
- research：打开 notes.md → 讨论调研方向 → 产出结果写入 wiki 或对应领域。
- 执行中发现新问题，按 执行中发现问题 处理；需要客户拍板才切回 owner-meeting 讨论。
客户在具体任务里说"先列个计划"时，默认是在要 task 执行方案，不要创建 .boss/roadmaps/。
写代码
触发："实现吧""写代码""改一下 XX""把这个故事做了"，或路径 B 中直接讨论代码改动。
写代码不是执行工单。要像挑剔的工程师一样先判断：这个改动应不应该在当前结构上做，是否需要先补架构、拆模块、升级技术栈、改善测试或清理工程现场。发现当前承载结构不配继续堆功能时，按 工程治理 先切回计划/架构讨论或创建工程化 task。
客户参与度（动手前）
跟架构一样自适应——抛球，看客户接不接：
| 客户类型 | AI 的行为 |
|---|
| 不关心实现细节 | 直接写。只有遇到架构约束冲突时才问 |
| 有技术判断力 | 动手前给一份简短设计——客户点头就干 |
| 深度参与 | 给出详细实现方案，逐项等客户确认后再写 |
第一性原理——什么是好代码
在 owner 语境下，好代码的标准：
1. 需求可追溯
代码的每一块都能对应回 .boss/requirements/ 里的某个用户故事。改了需求知道改哪里，反过来看到一段代码能知道它为什么存在。
2. 架构一致
代码结构服从 .boss/architecture/ 的组件划分。架构约束不是建议——绕开会造成文档和代码的偏离积累。
3. 改动局部化
一个需求故事改了，只影响一个局部。写的时候问自己：如果过两周客户说"这个需求变了"，改动范围多大？
4. 可读可退场
一个不熟悉的新人（或三个月后的自己，或下一个 AI）打开代码，能很快建立心智模型。做到：命名准确、小单元、不写聪明的抽象。
执行步骤
- 先读文档，再读代码：确认需求故事和架构决策，理解当前实现。文档和代码对不上时提醒客户。顺手 grep
tasks/ 和 tasks/_resolved/ 中提及当前文件路径的 task，扫一眼有没有前人留的坑。
- 先给执行方案：如果客户要求"先列计划/先说方案"，在当前 task 里给执行方案，不创建 Roadmap；只有长期目标才进
.boss/roadmaps/。
- 先判断承载结构：当前技术栈、模块边界、文件体积、测试方式是否配得上这个改动；新增业务逻辑先判断信息聚合程度，能独立成块就新建模块，原文件只接线。若不配，先创建/推进工程化任务，而不是继续堆功能。
- 按架构写：架构约束是硬杠。发现不合理的切回 owner-meeting 讨论。
- 按客户参与度给方案：见上方"客户参与度"。
- 写完回看文档：主动问"实现完成了，文档需要更新吗？"
- 和任务联动：处理任务中写代码就是任务执行的一部分，写完勾掉并归档。
- 执行中发现问题：按 执行中发现问题 留意周边——相邻代码有没有腐烂？同一个问题是不是在多处反复修？能安全修就修，超出范围就落 task/Roadmap/wiki，需要客户拍板就给选项。
领域目录规则（执行场景产出落盘的目标）
roadmaps：Roadmap 目标框架
.boss/roadmaps/ 保存 Roadmap 文档，是长期控制面板，不是日志仓库。单个 Roadmap 文件硬上限 200 行；超过就必须先压缩，再继续执行或汇报。
当前/最新阶段必须在 Roadmap 里先列出初步待执行条目，避免 Agent CLI 启动后只汇报"待拆任务"。这些条目只是 planned 条目，不是 task 文档；真正开工时才创建 .boss/tasks/.../task.md。
模板见 templates/roadmap.md。
Roadmap 完成或废弃后移动整个文件到 .boss/roadmaps/_resolved/YYYY-MM/，并更新 .boss/roadmaps/INDEX.md。active Roadmap 目录只保留仍在推进的路线图。
tasks：状态式 + 自动归档
task 是独立执行文档，不是一行 markdown 待办。task 不默认从属于 Roadmap；Roadmap 可以引用 task，Roadmap 派生的 task 可以在 frontmatter 里保留可选 roadmap 回链。
不要在规划阶段批量创建 task 文档。只有当真正选择某个具体事项开始执行时，才创建对应 .boss/tasks/YYYY-MM-DD-描述/task.md；如果该事项来自 Roadmap，则同时更新 Roadmap 与 tasks/INDEX.md。
task type 自由字段，不预枚举。大部分只要 task.md，需更多文件时才加（sync 带 migration.md + proposals/，research 带 notes.md）。
task 的执行记录必须能稳定排序。记录条目用 YYYY-MM-DDTHH:mm:ss+08:00，不要只写日期；同一秒多条时追加毫秒或序号。
task 完成并验证通过后，如果工作区是 git 仓库，提交一次只包含本 task 相关改动的小 commit。不是 git 仓库、无法安全拆分无关改动，或客户明确禁止提交时，在 task 记录里写明跳过原因。
tasks/
INDEX.md # 已创建且仍活跃的任务
YYYY-MM-DD-描述/ # 进行中；执行时才创建
_resolved/YYYY-MM/ # 已完成，按月归档
完成后即移入 _resolved/YYYY-MM/，INDEX.md 始终清爽。
模板见 templates/tasks/task.md。
护栏与禁止项
执行过程中的硬护栏（Roadmap / Task / Requirements / Git / 验证 / 阶段完成 / 禁止项）见 guardrails。
实践索引
执行场景下的高频实践指南：
- 术语指南：区分 Roadmap、task 执行方案和日常语言里的"计划"。
- Roadmap 质量：写长期路线图不只是拆功能——要注入主理人判断，覆盖产品/工程/设计/数据/验证/运维/风险。
- 工程治理：结构变坏、临时方案变正式方案、大脚本堆、新业务逻辑放置等场景怎么处理。
- 执行中发现问题：执行阶段持续观察，能修则修，不能修则归档或建任务。
- 工作区清理：每轮 task 结束如何处理 commit、漏文件和残留脏工作区。
- 工程巡检方法论：空转时怎么从架构对齐、模块巡检、模式审计、硬指标、模式提炼、文档完整性六个方向侦查项目。
- 竞品借鉴评审：参考竞品时用独立评审人视角判断，不能只做表象。
