rewriting-code-strictly

严格重写代码

用于保持行为一致地重写 Python、TypeScript/JavaScript 或 Go 代码的严格重写协调器。一次只进行思考、决策并调度一个子 Agent；仅保留状态、决策、验证结论、变更路径、风险和重要 URL。

输入

输入	必填	示例
TARGET_CODE	是	src/api/users.py 或粘贴的代码
LANGUAGE	否	python、typescript、go
USER_GOAL	否	"让代码更严格且更易于维护"
VALIDATION_COMMAND	否	mypy src/api/users.py
SCOPE_LIMITS	否	"不要添加依赖"
REFERENCE_NEED	否	"Pydantic strict mode"
EXTERNAL_FETCH_APPROVAL	否	"仅批准获取 Pydantic 文档"

缺少 TARGET_CODE 或语言不明确时 → 调度前提出一个有针对性的问题。

输出约定

交接顺序：(1) 原始行为，(2) 弱点，(3) 类型与验证决策，(4) 文件/代码，(5) 验证结果，(6) 使用的参考资料或无法获取的资料，(7) 假设/风险，(8) G_STRICT_STRATEGY_APPROVAL、G_MUTATION_SCOPE、G_IMPLEMENTATION_VALIDATION、G_STRICT_REVIEW_PASS、G_FINAL_HANDOFF_EVIDENCE 的关卡证据。

停止状态（NO_CHANGE、NEEDS_CLARIFICATION、BLOCKED、ERROR）：状态、最简原因、下一步决策，以及已完成的任何验证。

状态机概览

Mermaid：flow-diagram.md。表格：state-machine.md。

组别	结果
输入关卡	目标、语言、范围；推导 MUTATION_LIMITS
基线	映射器；NO_CHANGE_CANDIDATE 会继续（不是停止状态）
策略	策略制定者；只有 NO_CHANGE 会在编辑前停止
关卡与审批	检查关卡；AskApproval 批准后恢复实现
实现/审查	修改、审查；最多 2 次修复会重新进入实现
终态	PASS、NO_CHANGE、NEEDS_CLARIFICATION、BLOCKED、ERROR

流水线概览

阶段	状态	执行	输出
输入	Intake…DeriveLimits	内联；角色设定	数据包 + 限制
基线	DispatchBaseline/RouteBaseline	strict-baseline-mapper	STRICT_BASELINE
策略	DispatchStrategy/RouteStrategy	策略制定者 + 一个操作手册	STRICT_STRATEGY
关卡	CheckGates/GateExpansion/AskApproval	内联	继续、阻止或恢复
实现	DispatchImplement/RouteImplement	strict-rewrite-implementer	STRICT_IMPLEMENTATION
审查	DispatchReview…GateFixCycles	审查者；修复 → 实现	STRICT_REVIEW
交接	Handoff→TerminalPass	内联	最终回复

子 Agent 注册表

子 Agent	路径	用途
strict-baseline-mapper	./subagents/strict-baseline-mapper.md	只读基线映射
strict-rewrite-strategist	./subagents/strict-rewrite-strategist.md	操作手册、可选抓取、最简计划
strict-rewrite-implementer	./subagents/strict-rewrite-implementer.md	应用重写；运行获准的检查
strict-rewrite-reviewer	./subagents/strict-rewrite-reviewer.md	独立审查结论

仅在调度子 Agent 时读取它。

渐进式加载图

只加载当前决策所需的内容。此处的路径相对于此 SKILL.md；后续文件使用各自的相对路径。

需求	加载内容
操作立场	./references/personality.md
Python / TS/JS / Go 默认项	对应的 ./references/*-playbook.md
外部 URL 映射	./references/external-sources.md（编排器或策略制定者）
示例	./references/orchestration-examples.md
状态机	./flow-diagram.md、./state-machine.md
子 Agent 契约	调度时加载 ./subagents/<name>.md

确定语言后加载一本操作手册。操作手册不会级联加载 external-sources.md；映射表和策略制定者负责处理该环节。调度时传递相对于软件包根目录的路径；子 Agent 可以使用 ../references/...。

仅通过 REFERENCE_NEED、EXTERNAL_FETCH_APPROVAL 或项目本地必需证据抓取 URL。URL 无法访问时 → 使用本地证据并注明风险，或标记为 NEEDS_CLARIFICATION。常规运行不必联网。

默认修改限制

在 DeriveLimits 中推导限制。除非 SCOPE_LIMITS 扩大范围，否则仅可修改 TARGET_CODE 中的内容，以及直接由此导致的编译、类型、导入和测试事项；保留行为、公开契约、依赖项、设置及无关工作；未经批准不得添加依赖项、进行大范围清理、修改公共 API、私有配置、生成的产物或仓库工具；修复仅限于审查者指出且处于限制范围内的问题。超出范围的需求 → 先澄清或扩大范围，再进行编辑。报告必须包含修改边界的证据。

关键输出门槛

门槛	证据
G_STRICT_STRATEGY_APPROVAL	状态、非目标、审批事项、验证计划
G_MUTATION_SCOPE	限制、计划/实际路径、范围扩展
G_IMPLEMENTATION_VALIDATION	命令、结果、不可用/未获批准的说明
G_STRICT_REVIEW_PASS	STRICT_REVIEW: PASS 或修复后的阻塞项
G_FINAL_HANDOFF_EVIDENCE	门槛判定、文件、验证、参考资料、风险

核心决策规则

稳定的内部实现使用静态类型；在信任边界执行运行时验证；将边界数据转换为类型化内部数据后再深入使用；逃生机制应局部且有充分理由。项目设置若更严格，则优先于操作手册默认项。

执行步骤

推进 state-machine.md：

1. Intake → DeriveLimits。 加载个性配置；推导限制。回答 Ask* 后恢复之前的关卡；无人值守时 → TerminalNeedsClarification。
2. DispatchBaseline。 路由至 PASS | NO_CHANGE_CANDIDATE | NEEDS_CLARIFICATION | ERROR。PASS 和 NO_CHANGE_CANDIDATE 都会继续进入策略阶段。
3. DispatchStrategy。 路由至 PASS | NO_CHANGE | NEEDS_CLARIFICATION | ERROR。NO_CHANGE → TerminalNoChange，不做任何编辑。
4. CheckGates → GateExpansion → 可选的 AskApproval。 需要扩展时，只询问一次。批准 → DispatchImplement。 拒绝 → TerminalBlocked。未回复 → TerminalNeedsClarification。缺少验证命令时，继续执行，并附上实现者警告证据。
5. DispatchImplement。 路由至 PASS | PASS_WITH_WARNINGS | BLOCKED | ERROR；检查范围和验证关卡；然后进入审查阶段或终止。
6. DispatchReview。 PASS → 交接。若 FAIL 且存在修复项，并且 repair_counter 小于 2 → 重新进入 DispatchImplement。否则进入 TerminalBlocked。
7. Handoff → TerminalPass，附上输出契约和最终关卡证据。

验证循环摘要

map → plan → gate/approve → change/check → review → targeted fix → re-check。实现者负责获准的检查；审查者负责检查实现者可能遗漏的偏差。

示例

TARGET_CODE=src/payments/webhook.ts，移除不安全的 any，验证 webhook，REFERENCE_NEED 为 Zod。映射器发现 TS 和不可信的请求体。策略制定者加载 typescript playbook；仅在需要时加载 external-sources.md 和获准的 Zod URL。无需扩展 → 实现 → 审查 → 交接。有关审批恢复、无变更以及参考资料不可用时的往返流程，请参见 ./references/orchestration-examples.md。