From hw
Manages a persistent lightweight Patch track for small fixes across cycles, supporting creation, listing, closing, and fixing patches without opening a full milestone.
How this skill is triggered — by the user, by Claude, or both
Slash command
/hw:patchThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
📌 输出语言规则:
📌 输出语言规则: 读取 config.yaml → output.language
当用户调用 /hw:patch 或 /hypo-workflow:patch 时使用此 skill。
Patch 是一个持久的轻量级旁路轨道,用于处理不值得开 Milestone 的小问题、清理和热观察。它独立于 pipeline 状态机,跨 Cycle 持久存在。
规范的 Patch 目录:
.pipeline/patches/当示例中出现 patches/P001-fix-login.md 时,应解释为 .pipeline/patches/P001-fix-login.md。
支持的格式:
/hw:patch "描述" [--severity critical|normal|minor]/hw:patch list [--open] [--severity critical|normal|minor]/hw:patch close P{NNN}/hw:patch fix P{NNN} [P{NNN} ...]/hw:patch accept P{NNN}/hw:patch reject P{NNN} "feedback"OpenCode 命令契约:
accept 和 reject 是 /hw-patch 的参数子命令:使用 /hw-patch accept P{NNN} 和 /hw-patch reject P{NNN} "feedback"。/hw-patch-accept 或 /hw-patch-reject。# P001: 修复登录页 CSS 错位
- 严重级: normal
- 状态: open
- 发现于: C2/M3
- 创建时间: 28日 11:30
- 改动: (待填写)
- 测试: (待填写)
- 关联: (无)
- resolved_by: null
- related: []
- supersedes: []
生成新内容时使用 output.language 作为标签语言,但编辑现有文件时保留其原有语言。
Patch 编号是全局的,跨 Cycle 从不重置。
.pipeline/patches/ 不存在则创建。P[0-9][0-9][0-9]-*.md 的文件名。P001、P002,依此类推。对于 /hw:patch "描述" [--severity ...]:
normalcritical、normal、minor.pipeline/cycle.yaml 存在且状态为 active,使用 C{cycle.number}.pipeline/state.yaml 有当前 Milestone 或 prompt 索引,追加 /M{N}discovered_in 留为 (无) 或 implicit C1output.timezone 解析创建时间。.pipeline/patches/P{NNN}-{slug}.md。对于 /hw:patch list:
.pipeline/patches/P*.md 文件。过滤器:
--open:仅包含 状态: open--severity critical|normal|minor:仅包含匹配的严重级如果没有匹配的 Patch,直接说明。
对于 /hw:patch close P{NNN}:
状态: open 替换为 状态: closed。output.timezone 添加或更新关闭时间戳。当 Milestone 解决了一个或多个 Patch 时,用 C{N}/M{N} 更新 resolved_by,且仅在 Milestone 实际交付了修复时才关闭 Patch。
使用 /hw:patch fix P001 立即修复单个 Patch,或 /hw:patch fix P001 P003 P007 依次修复多个 Patch。Patch 修复是轻量级执行通道,不是 Milestone,也不是 TDD pipeline 运行。
Patch 修复是轻量级的,但仍然是生产工作。Patch 修复必须保留真实的 implement、test 和 audit Worker Separation:
test:负责复现、失败证据、测试设计,以及在实现开始前的任何测试/fixture/assertion/snapshot 编辑implement:仅负责生产/运行时/文档实现编辑;不得创建、编辑或重写测试、fixture、snapshot 或 assertionaudit:在自动关闭前独立审查最终 diff 和关闭证据implement、test 和 audit 中的多个角色test、implement 和 audit Subagent 或原生 worker;绝不允许 implement worker 生成或冒充 test 或 audit workeropen 或移至 pending_acceptance,直到独立的 test 和 audit worker 验证通过test、implement 和 audit subworker;仅调用 /hw:patch fix 本身不构成足够授权test、implement 和 audit worker 身份.pipeline/log.yaml 中记录 requested、started、completed|failed|blocked 和 closed/released 状态,包含 worker id、role、scope 和 evidence pathclose_failed;未解决的 worker 生命周期意味着 Patch 无法自动关闭.pipeline/log.yaml 中记录委托证据、worker 身份、生命周期状态或阻塞性非委托理由test、implement 和 audit workerstatus: pending_acceptance 或保持 status: open,并告知用户需要独立审查pending_acceptance 是在用户明确批准本地实现后或实现已存在时的后备选项;它不是跳过编辑前授权门禁的许可❌ 绝对禁止:
test / audit worker 且缺少授权时,先本地实现再把 Patch 标成 pending_acceptanceimplement worker 创建、修改或重写测试、fixture、snapshot、assertion,或让它再 spawn/委托 test、audit 身份✅ 必须做到:
test、implement 和 audit worker 都通过且生命周期已关闭/记录后才自动关闭 Patch;否则保持 open 或 pending_acceptancetest、implement 和 audit subworker;未授权时先停止,除非用户明确确认降级且 Patch 不自动关闭对于每个请求的 Patch,严格按顺序执行以下步骤:
.pipeline/patches/P{NNN}-*.md,解析标题、描述、discovered_in 和严重级。如果 Patch 状态已是 closed,报告该 Patch 的错误并跳过变更。test、implement 和 audit worker。在 Codex 上,编辑前询问用户是否授权独立的 test、implement 和 audit subworker;如果授权被拒绝,停止或仅在用户明确确认降级实现(不能自动关闭 Patch)的情况下继续。在 Claude Code 和 OpenCode 上,使用已配置的 subworker,无需额外授权门禁。不要先静默实现。test worker。test worker 负责复现、失败证据、测试设计以及任何测试/fixture/assertion/snapshot 编辑。implement worker 不得先写测试,也不得在没有新的 test worker 轮次的情况下重写 test worker 的覆盖。implement worker 或明确降级的本地实现应用最小的目标生产/运行时/文档变更。如果修复需要改动超过 5 个文件,停止该 Patch 并建议升级为 Milestone 或 Cycle 计划项。不要进行机会性重构。implement worker 不得生成 subworker 或满足验证角色。test 验证和 audit 关闭审查。如果测试失败,仅回滚该 Patch 所做的更改,保持 Patch open,并继续下一个请求的 Patch。如果测试通过但没有独立的 test 或 audit worker 可用,不要自动关闭 Patch。git commit -m "fix(P001): <Patch title>"。对于批量修复,不要合并 Patch commit。test 验证和 audit 审查通过,且所有必需的 worker 任务已成功完成并关闭/释放生命周期状态,将 Patch 文件更新为 closed,刷新 .pipeline/PROGRESS.md 看板表格,并向 .pipeline/log.yaml 追加生命周期事件。如果任何 worker 任务为 failed 或 blocked,或缺少独立验证或生命周期关闭,设置 pending_acceptance 或保持 open,记录缺失的 Worker Separation 证据,并在声称完成前停止。Patch 完成或进入 pending_acceptance 的最终回应和 Patch 记录必须按 references/completion-report-contract.md 覆盖:改动摘要、技术思路、修改文件/模块、测试设计、验证结果、预期结果、遇到的问题、风险/后续。Patch 修复仍然不得生成 Milestone report.md;详细完成负载应写入 Patch 文件、.pipeline/log.yaml 链接字段或最终回应,PROGRESS.md 仅保留紧凑看板行。
当步骤 8 关闭 Patch 时,在保留现有备注的同时更新或追加 Patch 文件中的以下字段:
- 状态: closed
- 修复时间: 29日 14:30
- 改动: src/scheduler.py:120 — 修正条件判断逻辑
- 测试: ✅ 回归通过(39/39)
- worker_separation: implement=<worker-id>, test=<worker-id>, audit=<worker-id>
- worker_lifecycle: test=requested/started/completed/closed, implement=requested/started/completed/closed, audit=requested/started/completed/closed
- commit: `a1b2c3d`
- completion:
- 改动摘要: 修复登录页 CSS 错位
- 技术思路: 最小化调整样式选择器并保留现有布局结构
- 修改文件/模块: src/login.css
- 测试设计: 运行现有 UI 回归并由 test worker 复核
- 验证结果: 39/39 通过
- 预期结果: 登录页在目标视口不再错位
- 遇到的问题: 无
- 风险/后续: 无
使用 output.language 和 output.timezone 生成散文和时间格式。如果现有 Patch 语言已清晰,保留原有语言。
更新 .pipeline/PROGRESS.md 为看板式摘要:
Patch 轨道 下的 Patch 行时间线 顶部插入一行.pipeline/log.yaml时间线行示例:
| 14:30 | Patch | P001 closed | 修复登录页 CSS 错位 |
不要向 PROGRESS.md 底部追加独立的单行进度条目。
向 .pipeline/log.yaml 追加生命周期事件,包含:
type: patch_fixpatch: P001status: closedcommit: <hash>worker_separation: implement=<worker-id>, test=<worker-id>, audit=<worker-id>worker_lifecycle: test=<status>, implement=<status>, audit=<status>summary: <one-line change summary>tests: <test command and result>Patch fix must never write .pipeline/state.yaml. Patch 修复绝不能写入 .pipeline/state.yaml,也绝不能生成 report.md。
对于 /hw:patch fix P001 P003:
3/4 修复成功,P003 失败(测试未通过) 的摘要结束。discovered_in:发现 Patch 的 Cycle 和 Milestoneresolved_by:解决该 Patch 的 Cycle 和 Milestone 或 Patchrelated:相关 Patch IDsupersedes:被此 Patch 取代的旧 Patch IDiteration:当前修复尝试编号acceptance_requested_at:请求手动 Patch 验收的时间accepted_at:Patch 被接受并关闭的时间rejection_refs:.pipeline/patches/feedback/ 下的结构化反馈文件Patch 验收仅是 Patch 轨道状态。它绝不能写入 .pipeline/state.yaml。
Patch 元数据可使用以下状态:
openpending_acceptanceclosedrejected当手动验收模式激活时,Patch 修复步骤 6 通过设置以下内容结束:
- status: pending_acceptance
- iteration: 1
- acceptance_requested_at: 2026-05-03T01:20:00+08:00
/hw:patch accept P001:
OpenCode 格式:/hw-patch accept P001。
.pipeline/patches/P001-*.md。status: pending_acceptance。status: closed。accepted_at。.pipeline/log.yaml 追加 patch_accept。.pipeline/PROGRESS.md。/hw:patch reject P001 "feedback":
OpenCode 格式:/hw-patch reject P001 "feedback"。
.pipeline/patches/P001-*.md。status: pending_acceptance。.pipeline/patches/feedback/P001-rejection-<timestamp>.yaml。status: open。iteration。rejection_refs。.pipeline/log.yaml 追加 patch_reject。.pipeline/PROGRESS.md。acceptance.reject_escalation_threshold 或更高时,建议升级为 Cycle。反馈文件必须包含 problem、reproduce_steps、expected、actual、context、iteration 和 created_at。为了兼容旧版读取器,可以存在一个 feedback 字段。
下一次 /hw:patch fix P001 必须读取 rejection_refs 并在编辑前注入结构化的拒绝上下文。
Patch 在 Cycle 关闭时不会被归档。它们保留在 .pipeline/patches/ 中,可以通过 /hw:plan --context patches 或 cycle.context_sources: [patches] 注入到未来的规划中。
references/completion-report-contract.md — Patch 完成汇报必需字段skills/cycle/SKILL.md — 活跃 Cycle 检测skills/plan-discover/SKILL.md — Patch 上下文注入references/config-spec.md — 输出语言和时区默认值SKILL.md — 根命令路由npx claudepluginhub hypoxanthineovo/hypo-workflow --plugin hwCreates minimal patch plans for targeted code fixes from reviews or bugs, analyzing with git/grep and templating precise changes with validation steps.
Runs an automated bug-fix pipeline on a single ticket or batch, with checkpoint resume, step dispatch, and dry-run support.
Fixes review findings, CI failures, or selected items from /age reports, runs tests/lint/build, and pushes to an open PR on clean cure.