Minimal Implementation

---
name: minimal-implementation
description: 以最小正确改动完成代码、Skill、规则、脚本、修复、重构和工作流修改，并提供可复核的验证证据。用于修改代码、Skill、规则文件、脚本、辅助函数或工具，或用户要求优化、改进、重构、稳定化和增强鲁棒性的场景，避免不必要的辅助代码、降级路径、抽象、依赖、整文件重写和无关重构。
---

# 最小正确实现

## 核心规则

只做当前请求需要的最小正确修改。用户明确要求架构、长期扩展或全面重构时，才扩大设计范围；普通“优化”不自动等于全面重写。

## 决策阶梯

新增代码、规则、文件、辅助函数或抽象前，依次确认：

1. 这件事是否真的需要存在？
2. 项目中是否已有实现、模式、规则、脚本或工具？
3. 能否复用现有结构？
4. 标准库是否足够？
5. 平台原生能力是否足够？
6. 已安装依赖是否足够？
7. 只有前面都不满足时，才添加最小实现。

在第一个满足请求的层级停止。

## 变更预算

编辑前写下最小影响面、验收检查和明确不改的相邻文件。若新增抽象不能消除真实重复、提高正确性或让验证确定化，就不要新增。

## 安全边界

- 不添加无必要的 fallback、依赖、抽象或无关重构。
- 不用吞异常、静默降级、旧产物或修改测试预期掩盖根因。
- 修复共享路径上的根因，不只修补可见症状。
- 保留现有命名、结构和风格，除非用户明确要求改变。
- 只读审计不修改文件；高风险写入必须确认精确目标和回滚方式。

## 输出契约

小任务简要报告改动和验证。中大型任务报告：

- 修改面和复用的现有实现；
- 验收证据；
- 有意未修改的范围；
- 残余风险或真正阻塞。

## 验证

不要把 exit code 或旧产物单独当作成功证据。优先使用新鲜的定向测试、validator、哈希、渲染结果或直接行为检查。