jherr 开发工作流是一套系统化的迭代开发方法，灵感来自 Jack Harrington（jherr）以及经典的软件开发原则。其核心理念是：开发应当分为三个截然不同的阶段——先能用、再做好、后做快。每个阶段有不同的优先级和成功标准，过早进入下一阶段会带来问题。
一、用途 该工作流用于指导软件功能、组件或系统的构建过程，帮助开发者在不同阶段聚焦正确的目标，避免过早优化、过早抽象或跳过质量建设。它强调快速获得可运行反馈，再逐步提升代码质量，最后在确有需要时进行性能优化。
二、主要能力
- 三阶段划分：
- 第一阶段“Make it work”：目标是尽快做出端到端可运行的最小方案。优先跑通主流程，使用直接的方法，必要时硬编码，跳过非关键错误处理，暂时接受代码重复。若结合 TDD，则先为核心主路径写测试，用红绿循环（失败测试→最小代码→通过测试）证明功能可用，边界测试留到第二阶段。
- 第二阶段“Make it right”：目标是把可运行代码重构为可维护、结构良好的软件。优先消除重复（DRY）、补充错误处理与边界情况、提取可复用函数与组件、改善命名与清晰度、增加类型安全（如 TypeScript 类型、Python 类型提示）、为关键路径写测试、在行为不明显处添加文档。若结合 TDD，此时补充边界与错误测试，借助测试安全网进行重构，达到重要行为的良好覆盖。
- 第三阶段“Make it fast”：目标是在实际测量出瓶颈后优化性能。进入条件包括性能测试发现真实问题、用户反馈生产环境变慢、性能分析定位到明确瓶颈，或有具体性能要求需要满足。优先做性能分析、先优化最慢部分（80/20 法则）、测量每次优化的影响、考虑缓存策略、评估算法改进、查找不必要的重渲染或重复计算。若结合 TDD，可加入性能测试记录基准，确保优化后原有测试仍通过。
- 工作流指南：
- 开始新功能：明确核心需求，勾勒最简单可行方案，先完成第一阶段，演示或验证可用后再进入第二阶段。
- 出现问题时：在当前阶段修复，不要不必要地跳回“先能用”模式，保持已达到的质量水平。
- 推进时机：第一阶段到第二阶段是核心功能可用时；第二阶段到第三阶段是有性能要求且测量显示存在问题；大多数代码应长期停留在第二阶段，干净可用的代码不需要优化。
- 危险信号：第一阶段写复杂抽象、第一阶段讨论性能、完全跳过第二阶段、没有测量就进入第三阶段。
- 与 TDD 的整合： TDD 回答“怎么做”（先写测试再实现），jherr 回答“何时做”（何时重构、何时优化）。阶段映射为：第一阶段用红绿循环覆盖主路径（最少测试、最少代码）；第二阶段补充边界测试，在测试保护下重构；第三阶段用性能测试验证优化不破坏行为。最佳实践是：第一阶段只写足够证明可用的测试，第二阶段扩展覆盖边界情况，第三阶段确保每次优化后测试通过。测试在所有阶段都是预期行为的文档。
三、使用方式 该工作流以技能形式提供，可通过 skills.sh 平台上的 adrianbrowning/agent-skills 仓库获取。资料中未提供具体安装命令或调用方式，暂未提供。使用时按照三阶段原则组织开发活动，并可结合 /tdd-integration 与 /testing-best-practice 等相关技能。
四、适用场景
- 构建软件功能、组件或系统，尤其是需要快速交付可用版本再逐步提升质量的场景。
- 希望将 TDD 与迭代开发结合，用测试保障重构与优化安全性的团队或个人。
- 需要明确“何时重构、何时优化”判断标准的开发流程。
五、限制 该工作流可能不适用于以下情况：构建安全关键系统（正确性优先）；一开始就有严格性能要求；对现有代码做小修补；原型探索（可停留在第一阶段）；“正确”方案从一开始就显而易见。资料中未提供收费、价格、平台支持范围或具体效果数据，暂未提供。