name: harness-fission
description: >-
  通用 harness 管理工作法「工作裂变」(self-contained, 任意项目可用)。把任何一块有分量的新工作裂变成 MECE 树状的独立、自包含、原子工单——  每个工单 = 一份带「声明参考」的 bounded-agent 任务简报,好让干净上下文的 agent 蜂群 (/effort→Ultracode→Workflow) 并行执行而不过拟合。  自带通用模板、不依赖任何项目的既有文件;陌生项目里先 orient 再裂变。  WHENEVER 用户要结构化/拆解一块有分量的新工作、整理项目工作树、为并行 agent 搭工作区、担心 agent 过拟合仓库文档、或准备放 agent 蜂群——即使没点名也要用。  触发词:拆分/结构化这块工作 · 怎么组织这个项目的工作 · set up workspace for agents · break this down · 开 agent 蜂群 · 上下文隔离/过拟合 · harness 管理 · MECE 拆解 · 工作裂变。

Harness Fission — 上下文可控的工作裂变法

把一块新工作裂变成「许多干净上下文的 agent 各做一小块、互不污染」的形态。自包含、任务无关——自带模板，不依赖任何项目既有文件。

何时用

• 结构化 / 拆解任何有分量的新工作：一个目标、一个功能、一次发布、一次重构、一次调研。
• 整理项目工作树、决定什么留在当前上下文、什么进历史。
• 准备 /effort → Ultracode → Workflow 放 agent 蜂群之前（这是它的主舞台）。
• 担心 agent 被仓库里一堆文档带偏（过拟合）。

为什么（核心信念）

能力强的模型会过拟合上下文：仓库里显式文档对 agent 引力极大，注意力会被工作树里的东西拽走。两个推论：

• 工作树只含「当前判断 + 在用基础设施」；被取代 / 低质内容 → git 历史，不归档，免得持续拉扯注意力。
• 蜂群很强但喂全仓库就过拟合：每个 agent 只喂它那一个工单 + 它声明的参考＝干净 bounded 上下文。

三条铁律

1. 旧内容 → git 历史，不归档：被取代 / 不合格的直接 git rm（前提先 commit 留底），不建 _归档/。归档夹本身也是注意力黑洞。
2. 按工作区隔离，严禁跨混：每块独立工作各自独立文件夹；每个隔离工作区带一份边界契约（见 assets/_boundary.md）——「只在本目录干、核心只读引用、不碰兄弟工作区」。这是放 bounded agent 的入口。
3. 叶子 = 自包含 bounded-agent 任务简报：空文件是占位符不是工单。每个原子工单 = frontmatter（status / owner / evidence / next-action / refs）+ 五段（定义 / 现状 / 交付物 / Next Action / 阻断·边界）。一个 agent 或人冷启动拿起来就能做、能交付。

方法（6 步）

0. Orient（陌生项目必做）

没有假定上下文。先读 README / AGENTS.md / 目录结构搞清三件事：①这是什么项目 ②哪些是共享只读基础设施（核心层）③这块工作具体是什么。心里有图再裂变。

1. 选透镜 + MECE 拆

按工作类型选对的拆解透镜（别硬套同一种）：

工作类型	拆解透镜
目标 / 成败（"在 X 上成功 / 赚钱"）	充分必要条件（断一条整体就断）
构建 / 功能（"做出 Z"）	WBS 组件 / 交付物（缺一块就不完整）
发布 / 迁移 / 流程	阶段 / 关卡（有序门）
代码库 / 重构	模块 / 子系统
调研 / 排障	问题 / 假设
检验恒等式：所有单元做完 = 整体；每个单元必要；彼此不重叠（MECE）。

2. 裂变

每个单元 → 一个独立工作区文件夹，标准子结构（套 assets/ 模板，文件夹名按领域本地化）：

<单元>/
├── _scope.md      # 范围 / 不含 / 完成判据(+ MECE 边界声明)
├── 现状(known)/    # 已确立的:我方现状 + 外部实证
├── 瓶颈(open)/     # 每个待办 = 一个原子工单文件
└── 参考(refs)/     # 证据/引用,按 L1/L2/L3

3. 声明

每个工单 frontmatter 标 owner(🤖AI / 🧑human)、status、evidence_level(L1实测 > L2推断 > L3假设)、next-action、refs(声明可读的参考，只读)。正文「阻断·边界」写明：它只碰什么、读哪些参考、绝不碰哪些（兄弟工单 / 别的工作区）。

4. 蜂群

/effort → Ultracode → Workflow。一个工单 = 一个 bounded agent，prompt 里只喂「该工单 + 它声明的参考」，绝不喂别的工单 / 工作区（喂全仓库 = 过拟合源头）。owner:🤖AI 的派 agent 去做；owner:🧑human 的留给人（AI 给不了的实测 / 决策 / 资源 / 资金 / 法律）。

5. 收口

工单完成 → git commit（msg 如 close: 单元/工单）→ 从活跃工作树消失进历史。结论按证据级裁决（L1 > L2 > L3），别拿假设当事实。

反模式（过度工程警戒）

• ❌ 给蜂群喂全仓库上下文（过拟合源头）；只喂工单 + 声明参考。
• ❌ 建 _归档/（用 git 历史）；上重型编号体系 / schema 校验插件 / 看板（<10 工单时纯负担）。
• ❌ 空文件冒充工单；把综合稿（Structure Note）全量强拆（只拆高优先待核项，综合稿合法存在）。
• ❌ 一个文件塞多件事；跨工作区物料混放；硬套不合工作类型的透镜。

模板（自带，自包含）

本 skill 在 assets/ 自带通用模板，不依赖任何项目既有文件：

• ticket.md（原子工单 = bounded-agent 简报）· scope.md · state.md（现状）· reference.md（参考）· _boundary.md（工作区边界契约）

落地时：

• 项目已有工作区规范 / 模板 → 用项目的（本 skill 让步于本地约定）。
• 项目没有 → 把 assets/ 复制进项目（如 _templates/），按领域改名，bootstrap 一份规范。

一句话

把「成功需要什么」翻译成 MECE 工作树，把每个叶子收敛成一张干净上下文 agent 能拾起的原子工单——人填人的、蜂群填机器的、旧的全进 git 历史。