From harness-flow
Implements single approved tasks, controlled hotfixes with repro paths, and review revisions via strict TDD (Red-Green-Refactor), fresh evidence, preparatory refactoring, and escalation gates.
npx claudepluginhub hujianbest/harness-flow --plugin harness-flowThis skill uses the workspace's default tool permissions.
HF workflow family 唯一实现入口。把单个活跃任务从"准备实现"推进到"已写回新鲜证据与 canonical 下一步"。不是任务循环控制器——跨 task 切换由 `hf-workflow-router` 决定。
Guides task implementation via Conductor's TDD workflow: mark plan.md progress, red-green-refactor cycle with pytest coverage checks, git commits, and verification protocols.
Enforces TDD workflow via RED (failing tests from specs) → GREEN → QA phases with intensity-based audits, mutation testing, and progress visibility. Use post-spec approval.
Guides test-driven development: decompose features/bugs into behaviors, cycle Red (failing test)→Green (minimal code)→Refactor. For test-first new features/bug fixes.
Share bugs, ideas, or general feedback.
HF workflow family 唯一实现入口。把单个活跃任务从"准备实现"推进到"已写回新鲜证据与 canonical 下一步"。不是任务循环控制器——跨 task 切换由 hf-workflow-router 决定。
三层职责:1) 唯一实现入口 2) TDD 执行入口 3) 向 review/gate 输出证据与 handoff 的交接入口。
本 skill 融合以下已验证方法。每个方法在 Workflow 中有对应的落地步骤。
| 方法 | 核心原则 | 来源 | 落地步骤 |
|---|---|---|---|
| TDD (Test-Driven Development) | 严格遵循 Red → Green → Refactor 循环 | Kent Beck, 2002 "Test-Driven Development: By Example" | 步骤 4 — 执行有效 TDD |
| Walking Skeleton | 优先建立最薄端到端可运行路径 | Alistair Cockburn, "Software Development as a Cooperative Game" | 步骤 4 — TDD 中优先走通关键路径 |
| Test Design Before Implementation | 在 Red-Green-Refactor 前完成测试设计 approval step | 项目化实践(HF 质量链约定) | 步骤 2 — 产出测试设计;步骤 3 — approval step |
| Fresh Evidence Principle | 所有验证证据必须在当前会话内产生 | 项目化实践(HF 证据链约定) | 步骤 4 — 有效 RED/GREEN;步骤 5 — 交接块 |
| Two Hats (Kent Beck / Fowler) | 任一时刻只戴 Changer 帽(写新行为)或 Refactor 帽(保持行为不变改结构),不混戴 | Martin Fowler, Refactoring Ch.2;Kent Beck, Tidy First? | 步骤 4 — RGR 步骤切分;步骤 4A — REFACTOR 帽下做 cleanup |
| Opportunistic + Boy Scout Refactoring | 接触代码时顺手把它留得更干净,但限定在 task 触碰范围且必须有可信回归 | Martin Fowler, Opportunistic Refactoring;Robert C. Martin, Clean Code | 步骤 4A — REFACTOR 步内 in-task cleanup |
| Preparatory Refactoring | 新行为难加时先重构出扩展点,再"做简单的改动";独立成步、不混入 RED | Kent Beck via Fowler, "make the change easy, then make the easy change" | 步骤 4 — RED 之前的可选 preparatory 步 |
| Clean Architecture Conformance | 实现遵循已批准设计的依赖方向、模块边界、接口契约;不重新论证架构决策 | Robert C. Martin, Clean Architecture;SOLID | 步骤 4A — Architectural Health Check |
| Escalation Boundary | 跨 task 范围的结构性重构、ADR 变更、模块边界变更不在 task 内做,escalate 到 hf-increment | 项目化实践(HF 节点边界约定) | 步骤 4A — escalation 触发即停 task;步骤 5 — Refactor Note 标记 |
适用:
不适用:任务计划未批准 → 回上游;hotfix 无复现路径 → hf-hotfix;需并行多任务 → hf-workflow-router。
前提:存在唯一活跃任务、有已批准计划或 hotfix handoff、能读取 feature progress.md(默认 features/<active>/progress.md)和规格/设计锚点(默认 features/<active>/spec.md / features/<active>/design.md)。证据冲突 → 回 router。
hf-hotfix 的复现路径和最小修复边界naive / pattern:<design § 4.5 战术模式名> / emergent);pattern:<name> 只允许承接已批准 design § 4.5 列出的战术模式,禁止引入 GoF 模式名hf-workflow-router,不在 task 内"先修着试试"读 feature progress.md(默认 features/<active>/progress.md)的 Current Active Task → 校验任务计划(默认 features/<active>/tasks.md)/hotfix handoff → 补读回流 findings → 证据冲突则暂停。
worktree-active:复用 Worktree Pathworktree-required:按本 skill references/worktree-isolation.md 准备 worktree(若 项目声明项目等价路径,优先遵循)in-place:仅干净工作区时继续TDD 前先输出测试设计:验证哪些行为、正反向场景、边界条件、预期 I/O、哪些应先失败、测试分层、与测试设计种子的差异。
自检:覆盖关键成功行为?覆盖反向/边界?能抓住"错误但看起来完成了"的实现?mock 限定在真正边界?
SUT Form 声明(Phase 0 新增):在测试设计中必须显式声明 SUT(System Under Test)的候选形态,三选一:
naive:直写实现,不引入任何实现层模式(单函数 / 单类 / 简单过程)pattern:<name>:以某个已批准 design 中列明的战术模式承载(Aggregate / Repository / Domain Service / Application Service / Domain Event 发布者)。只允许承接 design § 4.5 已写明的战术模式,不允许在此前置引入 GoF 模式emergent:本轮不预判具体形态,在 REFACTOR 步按实际 cleanup 需要浮现结构(Fowler vocabulary 命名)SUT Form 的 allowlist(唯一允许 pattern:<name> 的取值):
pattern:Aggregate / pattern:ValueObject / pattern:Repository / pattern:DomainService / pattern:ApplicationService / pattern:DomainEvent(源自已批准 design § 4.5)pattern:Aggregate;若 SUT 是某个 Aggregate 内的非 root Entity,通常说明 task 粒度过细,应该把 SUT 扩到 Aggregate Rootpattern:Strategy / pattern:Factory / pattern:Adapter / pattern:Observer / pattern:Decorator / pattern:Builder / pattern:Singleton ...)→ 退回 emergent;这些 GoF 模式必须在 REFACTOR 步按 Fowler 重构词汇(Replace Conditional with Polymorphism / Extract Factory Method / ...)emergent 浮现。HF 立场(已内联 hf-design/SKILL.md Methodology Emergent vs Upfront Patterns):GoF 代码模式刻意不在 design 阶段前置决策,由 REFACTOR 步在 Two Hats 纪律下按需浮现选择 emergent 是合法且常见的默认选项,不需要道歉。
整理成可回读确认输入。interactive → 展示给真人等待确认;auto → 写 approval record。完成后才能进入 TDD。
approval record 与交接块中必须包含声明好的 SUT Form;后续 REFACTOR 步的 Refactor Note 必须回写 pattern_actual 与声明对照。
严格按 Two Hats 切分步骤。每个步骤明确戴哪顶帽子;不混戴。
references/refactoring-playbook.md 的 Preparatory Refactoring 节。有效 RED:会话里真的执行了、失败对应行为缺口、能说清为什么预期失败。
不算有效 RED:只写没跑、一跑就绿、无关旧失败、看不出在证明什么。
有效 GREEN:任务测试转绿、证明命令本次会话成功、保留 fresh evidence。
仅在所有任务测试 + 相关回归 + (若项目存在) architectural fitness function 均为绿后进入。戴 Refactor 帽,不引入新行为。
按以下顺序执行,详细规则见 references/refactoring-playbook.md:
hf-design(默认 features/<active>/design.md)与相关 ADR(默认 docs/adr/),逐项确认本轮实现仍遵循:
references/refactoring-playbook.md 的 smells 速查表(god-class / cyclic-dep / hub-like-dep / unstable-dep / layering-violation / leaky-abstraction / feature-envy-cross-module / over-abstraction),逐项确认本轮触碰范围内是否有可见 smell。references/refactoring-playbook.md 的 Escalation 边界归档:
hf-workflow-router,由 router 路由到 hf-increment 或 hf-design红灯信号(任一出现立即停下回到 4A 顶部重新走):
写回稳定交接块:
## 实现交接块
- Task ID:
- 回流来源: 主链实现 | hf-hotfix | hf-bug-patterns | ...
- 触碰工件:
- Workspace Isolation / Worktree Path / Worktree Branch:
- 测试设计确认证据:
- RED 证据: <命令 + 失败摘要 + 为什么预期失败>
- GREEN 证据: <命令 + 通过摘要 + 关键结果>
- 与任务计划测试种子的差异:
- 剩余风险 / 未覆盖项:
- Pending Reviews And Gates:
- Next Action Or Recommended Skill:
### Refactor Note
- Hat Discipline: <RGR 是否守住 Two Hats;是否有独立 preparatory refactor 步骤>
- SUT Form Declared: <approval 中声明的 sut_form:naive | pattern:<tactical name> | emergent>
- Pattern Actual: <REFACTOR 后 SUT 实际呈现的形态:naive | pattern:<tactical name> | pattern:<Fowler vocabulary, e.g. Replace Conditional with Polymorphism → Strategy> | emergent-unchanged>
- SUT Form Drift: <声明与实际是否一致;不一致时说明触发的 Fowler cleanup 与原因;GoF 模式只能在此处以"实际浮现"的形式出现,不回写到 design>
- In-task Cleanups:
- <Fowler vocabulary> @ <文件:范围> — <一行说明>
- Boy Scout Touches:
- <文件:范围> — <清理类型>
- Architectural Conformance: <与 hf-design 中依赖方向 / 模块边界 / 接口契约的一致性结论;偏离需写明理由与可追溯锚点>
- Documented Debt:
- <smell 名> @ <影响范围> — <为什么不在本 task 内修>
- Escalation Triggers: <None | escalate to hf-increment | escalate to hf-design via hf-workflow-router>
- Fitness Function Evidence: <命令 + 结果摘要;不存在则写 not-configured>
Refactor Note 必填规则:
none,Documented Debt / Escalation Triggers 写 none,Hat Discipline 与 Architectural Conformance 仍须显式写结论。none 时,本轮 Next Action Or Recommended Skill 必须为 hf-workflow-router,不能为 hf-test-review;后续质量链由 router 重新路由。Next Action 用 canonical skill ID:full/standard 通常 → hf-test-review;lightweight 通常 → hf-regression-gate;回流修订完成 → 写回触发回流的那个 node。不把下一任务的实现写成输出。若 AI 发现当前问题命中了值得长期沉淀的重复错误,可额外建议独立触发 hf-bug-patterns,但不要把它写成 HF 主链的 canonical next action。
明确回流来源 → 只修当前活跃任务的相关 findings → 若改行为预期需重做测试设计确认 → 修订后写新 fresh evidence → 不从头重走质量链。
| 场景 | 用 hf-test-driven-dev | 不用 |
|---|---|---|
| 任务计划获批后的单任务 TDD 实现 | ✅ | |
| review/gate 回流修订 | ✅ | |
| 任务计划未批准 | → 上游(hf-tasks / hf-workflow-router) | |
| 热修复但无复现路径 | → hf-hotfix | |
| 需并行多任务 | → hf-workflow-router | |
| 评审测试质量 | → hf-test-review | |
| 评审代码质量 | → hf-code-review | |
| 评审追溯完整性 | → hf-traceability-review |
progress.md 靠印象决定活跃任务features/<active>/evidence/hf-incrementemergent 却在 RED/GREEN 步直接引入复杂 pattern——未走独立的 preparatory refactor 独立步,违反 Two Hatspattern:<name> 写入 sut_form 声明——这不合法,只允许承接 design § 4.5 列明的战术模式(Aggregate / VO / Repository / Domain Service / Application Service / Domain Event);GoF 只能以 Fowler vocabulary 的 REFACTOR 结果形式出现在 Refactor Note 的 Pattern Actual 字段| 文件 | 用途 |
|---|---|
references/refactoring-playbook.md | Two Hats / Boy Scout / Opportunistic / Preparatory 重构纪律、Fowler vocabulary、Architectural smells 速查表、Escalation 边界、SOLID conformance check、Refactor Note 模板 |
references/cpp-gtest-deep-guide.md | C++/GoogleTest/CMake 栈深度参考 |
references/testing-anti-patterns.md | C++ 测试反模式(mock 误用、测试专用方法等) |
references/worktree-isolation.md | Worktree 隔离操作指南(when to require / directory selection / safety verification / provisioning protocol / cleanup semantics);若 项目声明项目等价路径,优先遵循 |
C++/GoogleTest 项目且需要语言级细节时才加载深度参考。非 C++ 也必须遵守同一实现契约。
features/<active>/approvals/)naive / pattern:<tactical name> / emergent);pattern:<name> 取值在 design § 4.5 allowlist 内features/<active>/evidence/hf-workflow-router,不强行进入 hf-test-reviewprogress.md 已同步