# Enough

> Use when editing software. Choose the right workflow.

- Skill: `zhizhixia/enough` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add zhizhixia/enough`
- Raw SKILL.md: https://api.skillmd.com/api/skills/zhizhixia/enough/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- License: MIT
- Author: zhizhixia (https://skillmd.com/u/zhizhixia)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/zhizhixia/enough

---


# Enough 开发流程

`enough` 是软件实现、修改、修复、重构和界面/配置变更的默认总入口。它决定范围、风险、复用、设计、验证与验收；专业 Skill 只提供局部方法，不接管总流程。纯解释、只读检查和仅规划任务不实施，也不创建无价值产物。

## 总则

- 服从平台安全边界、用户当前授权和项目硬性规则；本 Skill 不得覆盖它们。
- 保留用户已有修改。用户要求只读、仅规划或不写文件时，不创建笔记、索引、克隆或临时文件。
- 先检查项目已有模块、依赖、接口、测试、规范和可信基线；能复用已有能力就不重复自建。
- 只向用户询问真正改变范围、架构、成本、安全、数据边界或外部状态的阻断性问题；给出推荐及理由。已明确的局部行为请求本身构成范围内实施授权。
- 用户已批准的设计与任务策略在范围未变时继续沿用；恢复会话从首个未完成验收项继续，不重新选型或审批。
- 能力不可用时执行等价的简化步骤，不中断；不得以流程为由制造无价值文档、测试或审查。

## 分流：FAST / NORMAL / DEEP

先依据失败影响、波及范围、可逆性、不确定性和外部状态影响，简短说明所选路径与理由。文件类型、任务长度或关键词不能单独定级；认证或生产路由配置可能是 DEEP。

| 路径 | 适用情形 | 必要动作 | 默认不做 |
| --- | --- | --- | --- |
| **FAST** | 局部、低影响、可逆且验收明确 | 检查改动范围与上下文，实施，运行最近的原生检查或必要冒烟 | 外部选型、正式设计、永久新测试、完整审查链 |
| **NORMAL** | 普通功能或修复，边界明确且风险可控 | 写出简短验收和可信失败模式，优先复用现有证据，完成受影响的真实路径，独立验收 | 默认严格 TDD、逐函数测试、固定双审、全层级回归 |
| **DEEP** | 高影响、难恢复、关键契约不确定、并发、认证/隐私、迁移或外部状态 | 针对具体风险补强设计、异常证据、受控环境和恢复措施 | 自动开启所有措施、未经授权的真实操作 |

FAST 默认不加载下列参考。NORMAL 在验证路径明确时直接执行相称检查；只有证据选择存在实质不确定性时才加载验证参考或调用 `verification-planning`。

## 复用与选型

1. **先查已有能力。** 对现有项目检查模块、依赖、接口、既有决策和测试；已有结论仍适用时直接复用，仅在约束实质变化时补查受影响部分。
2. **只在真正选型时外部搜索。** 新项目、新增重要依赖、引入新的自建能力，或需要在成熟方案与自建之间做取舍时，完整读取 [GitHub 复用门禁](references/github-reuse-gate.md)。进入该分支后，必须给出用户可见的复用决策，才开始自建或扩展。
3. 常规修复、文案、已有实现的局部扩展不因 GitHub 不可用而阻塞。真正选型时搜索不完整必须披露限制；未经用户确认，不把不完整调研伪装成已验证的自建取舍。

## 设计与实施

- 只有复杂功能、新项目、重要数据模型、关键契约或安全/数据边界变化才先给出设计并取得批准。小而明确的任务用聊天中的目标、边界、验收与失败行为即可。
- 先定义用户可观察结果、不应改变的行为和可信失败模式。关键契约未确认前不扩大并行；小任务不强造全系统纵向链路。
- 有真实跨边界的系统时，先完成一条最小纵向闭环，并以真实契约验证；Mock 或孤立组件成功不能代替集成结论。
- 默认串行确定核心契约和系统集成；只并行文件范围不重叠、输入输出明确的独立工作。每批立即集成。
- 主代理负责风险、授权、接口一致性、整合和验收；子代理继承既定策略，发现范围或风险变化时回报，不重跑全局流程。
- 仅在委派子代理、安排跨角色协作或需要统一回传证据时，完整读取[委派卫生](references/delegation-hygiene.md)；普通单人任务不加载该参考。
- 仅在存在具体可维护性疑点时调用 `simplify` 或专项审查；不把它们列为固定后续步骤。

## 验证策略

按顺序作出三个独立决定，不能用单一评分代替：

1. **要证明什么，已有证据够吗？** 列出可观察结果、不变项和可信失败模式，检查既有测试、类型/静态检查、构建、启动或真实场景。足够时不新增永久测试。
2. **证据缺口值得新增永久测试吗？** 仅当存在可重复真实风险、稳定观察边界、独立预期和持续回归价值时新增；否则用临时诊断、冒烟、集成运行或可重复人工步骤。
3. **是否测试先行？** 只有用户明确要求，或契约清楚、反例稳定且先写测试确有约束收益时，才在指定边界采用 TDD。实现后补的独立行为测试仍有效，不为追求时间顺序删除实现重写。

完整加载 [验证与发布](references/verification-and-release.md) 以确定重大证据缺口、设计新增测试、治理既有测试，或处理 DEEP 风险。始终区分 Mock、自动测试、构建成功与真实环境验证。

## 验收、停止与安全边界

- 开发中运行最近改动的相关检查；跨模块、共享基础设施变化或项目规则要求时才运行全套。先主流程，后边界与失败路径。
- 主代理不能以子代理“完成”代替交付：独立检查实际产物，并独立运行所选验证路径。重要本地写入以重新读取、差异、哈希或实际运行证据确认。
- 按批准验收项逐项标记“已验证、部分验证、未验证或不适用”，附命令、输出、产物、截图或真实运行证据。构建成功不能掩盖单项缺口。
- 选定验收项证据充分、无阻断问题且剩余限制已披露时停止；不为再保险无限新增测试、审查或重构。
- 同一实现、验证、写入、工具或权限路径连续失败两次后，先分类为代码、环境、权限或工具问题，再换证据路径或报告阻塞。
- 外部写入、安全、隐私、资金、部署、账号、生产数据和工业设备属于 DEEP：执行前明确具体目标、授权、不可逆影响与补救；按适用性采用最小权限、Dry Run、状态查询、受控 Canary、恢复方案和异常验证。结果不确定时先核验状态，禁止盲目重试；不得将 DEEP 视为真实调用授权。
- 除非用户明确授权，不提交、推送、创建 PR、发布、部署或进行真实外部写入。

## 交付

报告实际改动、逐项验收、验证与未验证范围、已知限制及适用的恢复方式。仅在形成重复模式或重要教训时沉淀 Skill；不要把单次任务细节写入长期流程。