align

Files (1)

• SKILL.md

SKILL.md (first lines)

# 执行前对齐

用户提出新的、非简单开发需求或尚需定位修法的故障时先执行本 Skill；只读分析、review、用户明确限定的小改动，以及根因明确、具体改动足够确定的直接修复，直接进入相应任务。报错位置明确或已有修复猜测，不等于根因和具体修法已明确。当前请求与适用的全局、项目指令优先于本 Skill 的默认值；已确认的授权、验证和交付要求不因选择推进模式而清空。

当前任务推进中，以下情况沿用原模式，不重复询问推进模式：

- 当前任务执行过程中刚产生的测试、构建、CI、部署或运行失败；
- 对当前实现的局部修正、补漏或继续执行已授权的验证与交付动作。

续接须能核实当前任务及其原模式；同一项目或相似报错不代表同一任务。当前任务产生的失败视为原任务的证据：继承其 Scope、Evidence 和 Delivery；根因未知时直接转 `skill:systematic-debugging`，定位后回到原合同继续修复。只有失败暴露出新的业务目标、明显扩大影响范围、需要更换实现路线，或要求未授权的外部动作时才停下询问。

形成或恢复执行合同时，分别保留用户实际确认的要求、已核实的项目事实与代理自行选择的实现方式；将方案称为“已确认”须有对应对话依据。用户批准执行后，常规实现取舍在授权内自行处理，以满足目标所需的最小改动为准，并说明关键选择的实际依据。

形成修复方案时，优先复用语义匹配的既有能力；新增权限、配置、状态或抽象，应有既有能力无法满足当前目标的依据。根据业务目标分别判断事件、入口和授权的关系，再确定必要改动。

## 从诊断转入首次修复

此前只做只读诊断，用户随后首次要求修复时，按上述入口判断是否适用本 Skill。根因已经定位，但实现路线、改动范围或验证仍需收敛的修复，先在这里形成执行合同；继承已有诊断的原诉求、根因证据、建议方向和待定事项，按需补齐会改变方案的证据。

用户同意修复及指定交付终点后，保留这些授权；建议方向中的实现选择仍按其实际依据收敛。按下节选择推进模式，已有明确选择或免交互授权时直接沿用。当前已在实施合同内排查故障的，定位后回到原合同继续修复。

## 选择推进模式

先依靠现有上下文粗略判断任务难度，必要时只做确认范围所需的只读检查，不为选择模式启动 subagent。对适用本 Skill 的任务，按以下顺序选择模式：

1. 用户已明确选择模式，或能核实当前任务的原模式时，沿用该模式。
2. 尚未确定模式，但用户明确免除交互（如“不用问，直接做”）、将推进方式交由代理决定，或说明 AFK 时，采用搞快点；同时要求测试和独立 review 时，采用快速验证。
3. 其余情况通过结构化交互询问并等待回答，不先开始实现或完整根因调查。

故障描述、“帮我修好”表达的是任务目标；“那改一下吧”“按这个方案做”只是同意实现方案，允许自行决定普通实现细节也不等于把推进方式交给代理。对适用本 Skill 的任务，从方案讨论转入首次实现且尚未选定模式时，仍须询问。已有测试、提交推送或部署约定只约束验证与交付，不代表选定推进模式。任务复杂度决定推荐项，不决定是否跳过提问。

首次进入执行且无需提问时，开工提示须简短说明所用模式及依据，如用户已选、授权代选、明确免交互或沿用可核实的原模式。

提问提供以下选项：

- **搞快点**：主线程确定最小合同并完成最小修改，不主动启动子代理；默认只做 diff 与目标文本检查，测试、构建和浏览器验证按明确要求执行；
- **快速验证**：沿用搞快点的少交互流程，默认运行相关测试并完成独立 review，不增加合同问卷；
- **对齐推进**：先扫描项目并确认执行合同，默认在开工前独立审查方案；开发后是否独立 review 另行选择。

疑似单点、报错集中且预计影响范围小的故障，推荐搞快点；范围已清楚、希望少交互且需要测试与独立审核时，推荐快速验证；涉及业务取舍或明显跨模块影响时，推荐对齐推进。标出推荐项并简述依据，等待回答。没有结构化交互工具时才使用普通文本提问。任何模式下，无法推断的高影响业务取舍或未授权外部动作仍须停在相应边界。

## 搞快点

内部形成最小执行合同后直接修改，不创建计划文档、持久 spec、ADR。实现、排查和已要求的验证均由主线程完成，不主动启动子代理；批量测试、重复操作、并行收益或通用委派建议不构成例外。仅本次明确指定的委派或独立 review 按 `skill:delegation` 执行，不把验证授权等同于委派授权。

普通细节按用户目标、现有代码和项目约定处理。若新发现会改变已确认的核心行为、完成标准、公开接口、数据结构、架构、外部副作用或明显扩大范围，停止相关动作并询问；用户离线时完成不受影响且已授权的部分，记录阻塞项。

默认仅完成本地修改与 diff、目标文本检查，不运行测试、构建或浏览器验证，不提交推送，不部署发版；已有明确要求与长期交付约定仍然执行。检查只能证明其覆盖的内容，未执行的验证如实标明。

## 快速验证

继承搞快点的最小合同、主线程实现、范围确认与交付边界，仅将默认验证改为相关测试和独立 review。选择本模式即确认这两项，无需再询问是否测试或 review，也不进入对齐推进的合同问卷。

按项目现有入口运行覆盖本次改动的聚焦测试和必要回归；现有测试不足以覆盖变更行为时，补最小必要用例，不自动切换为测试先行或扩建测试体系。构建按测试前置条件或项目明确要求执行，浏览器验证按明确要求执行。

完成实现和相关测试后，按“review 与任务续接”交接当前需求、验收标准与完整变更范围，委派独立 review。核实发现后修复原合同范围内的问题，重跑受影响测试并针对修复复核；无新改动、失败或未解决疑点时不重复验证。

缺少测试入口、运行环境或独立审核能力时，继续完成不受影响的已授权工作，并如实报告未完成项；不将静态检查或主线程自审冒充测试或独立 review。

## 对齐推进

先扫描相关代码、spec 和项目约定，再形成轻量执行合同：

- **Scope**：目标、非目标和可观察的完成标准；
- **Approach**：直接实现、先设计、定位根因或测试先行，并简述足以判断方向的关键行为或排查路线；
- **Evidence**：用哪些现有测试、构建、复现或其他证据判断结果；
- **Delivery**：是否本地测试、提交推送，以及 Web 项目是否发布测试环境并进行浏览器验证。

能从请求和项目事实可靠推断的直接采用，只询问会改变执行路线且无法确定的事项。使用结构化交互提供 2–4 个真实选项、说明影响并标出推荐项，然后等待回答；没有真实取舍时不凑选项。

Evidence 能由现有测试体系和项目约定确定时直接采用。非 Git 项目不询问提交推送；无远端不询问推送；没有已确认测试环境入口时不询问部署。生产部署或正式发版仅在用户明确要求时执行。

分批实施时，合同保留整体目标与完成标准，说明本批覆盖和后续工作如何衔接。批次终点只是进度节点；交付终点的缩减应有用户明确调整的依据。

### 开工前方案审核

对齐推进默认在合同与简短方案形成后、实施前，按 `skill:delegation` 委派一次独立方案审核，无需再问是否前审。按 `skill:delegation` 的需求对话格式交接本任务相关的用户原话与 Assistant 极简上下文，并提供已知使用条件、当前合同及方案，复用独立审核场景；先审核合同范围、依赖与完成标准能否覆盖原始目标，再判断拟议行为能否达成。分批方案一并交接后续安排；此时审核对象是方案，不是尚不存在的实现或 diff。不另建方案报告，也不因前审创建临时验收文档。

交接时明确：子代理默认只依据所给材料审判断与方向，不常规扫描仓库或执行测试；只有缺失信息会改变结论时，才定点核实或报告待确认，不把快速审核变成完整技术调查。调用方处理会改变方向的发现后再实施：有依据的误读直接修正，需要用户作业务取舍的再问；缺少独立审核能力时说明阻塞，不以自审冒充通过或先开始受影响的实现。

前审与开发后 review 分开。回答“开发后是否 review”时取消后审，不影响默认前审；明确取消前审、禁止任何 review 或禁止子代理时遵守其范围。搞快点、快速验证不因此默认增加前审。普通任务续接不补做或重复前审；目标或路线发生需重新确认的实质变化时，只重审受影响的方案。

## review 与任务续接

在对齐推进的合同交互中，本次是否开发后独立 review 尚未明确时，询问“开发完成后是否需要独立 review”，提供需要与不需要两个选择并等待回答；已明确选择时不重问。AFK 且未选择时不自动安排开发后 review。

对齐推进已选择开发后独立 review 的，在开发前按 `skill:code-as-spec` 建立临时验收输入，并按该 Skill 维护到本次问题处置结束。快速验证，以及搞快点中显式要求独立 review 时，直接提供当前需求与验收标准，不强制补建临时文档。搞快点未选择 review 时不创建 review 文档、不自动安排 review。

开发后 review 的代码取证范围由调用方明确：实施前记录任务起点，完成后按 `skill:delegation` 委派独立审核，显式提供当前验收输入、审核目标与工作区变更或明确的 base/head；包含未跟踪的新文件时一并提供，不因已提交而漏审。分批 review 同时交接整体目标覆盖情况与剩余工作，目标 diff 只限定本批实现证据。原合同范围内的缺陷修复沿用已有授权；单独的只读 review 请求不附带修改权限，扩围或新增外部动作仍须确认。

新任务确定推进模式后，根因未知时转 `skill:systematic-debugging`；选择测试先行时转 `skill:tdd`。任务内失败沿用已确认模式直接调查。专项 Skill 返回后继续按原合同执行，不重复询问。

跨轮次或上下文恢复时，先恢复本次 Scope、Approach、Evidence、Delivery、前审状态、开发后 review 选择和已完成状态；分批任务同时恢复整体目标、本批进度与剩余工作，再继续下一步。优先使用现有任务清单或会话台账，不另建治理文档；无法核实的授权不按已获授权处理。

## 结果与后续

按当前输出约定报告结果、关键取舍、实际验证、未完成项和剩余风险；证据只陈述实际观察到的结果，不把写了测试或 reviewer 未报问题等同于验证通过。

存在会改变后续动作的未决事项时才给出下一步。AFK 任务在已授权交付终点停止，并集中报告阻塞项。

From cheng6563/litepowers, MIT.

More from cheng6563/litepowers