Stats
Actions
Tags
From hw
Guides a structured planning workflow (P0-P4) to design milestones, configure execution, separate workers, and enforce authorization gates before starting implementation.
How this skill is triggered — by the user, by Claude, or both
Slash command
/hw:planThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
📌 输出语言规则：
📌 输出语言规则： 读取 config.yaml → output.language
将此 skill 用于完整的 P1-P4 规划流程。
普通的 /hw:plan 命令保持完整的 P1-P4 规划流程。如果用户传递 --deep，在普通分解之前路由到 /hw:plan:deep。--deep 别名启动 Deep Plan 讨论包，不得跳过 P1-P4；在 Deep Plan convert 之后，普通的 /hw:plan 仍然运行 P0 Configure、P1 Discover、P2 Decompose、P3 Generate 和 P4 Confirm。
在 P1 Discover 之前，为新 Cycle 运行或确认 P0 Configure，除非当前 Cycle 已经有配置决策。P0 Configure 在 cycle new 之后、P1 Discover 之前运行；它询问自动化、Subagent 授权、验收模式、PR/MR 远程写入确认、完整回归、分析边界和 Worker Separation。用户可以重用先前的设置，按 cycle_explicit -> previous_cycle_snapshot -> project_config -> global_config -> built_in_default 顺序解析，重用必须留下可审计的注释或 .plan-state/p0-configure.yaml。
没有 --batch 时，保留现有的单 Feature P1-P4 流程。普通的 /hw:plan 命令仍然运行一次 Discover 访谈、一次 Decompose 检查点、一次 Generate 阶段和一次 Confirm 门控。
默认情况下启用 Progressive Discover 作为 P1 的结构。首先从大问题开始：
在 P1 开始之前，运行或显式重用 Cycle 级别的 P0 Configure 前置阶段。P0 Configure 在 cycle new 之后、P1 Discover 之前运行；它询问自动化、Subagent 授权、验收模式、PR/MR 远程写入策略、完整回归、分析边界和 Worker Separation。重用必须按以下顺序记录其来源：cycle_explicit、previous_cycle_snapshot、project_config、global_config、built_in_default。
当项目尚未声明 execution.worker_separation.mode 时，Discover 还应询问项目是否需要 off、recommended 或 strict 的 implement/test/audit 分离，并在 Generate 期间持久化该决策。
如果为 Worker Separation 选择了降级模式，则需要用户明确确认，并且必须记录非委托理由、缺失角色、降级原因、验证所有者和下游验收影响。
P1 Discover 在分解之前有一个强制的执行子工作器授权门控。即使项目已声明 execution.worker_separation.mode=recommended 或 strict，也要应用它。
/hw:start 和 /hw:resume 或 execution/start-resume 角色，询问用户是否授权 /hw:start 和 /hw:resume 的执行子工作器；如果授权，选择 recommended 或 strictexecution.worker_separation.mode=offsubcodex 还是 subclaude，然后选择 recommended 或 strictrecommended 或 strict，或显式 off该模式仍然管理 implement/test/audit 分离：recommended 在可能时分离 implement 和 test，而 strict 要求 implement/test/audit 是不同的。
仅限 Codex：不要将缺失授权视为 recommended，也不要静默降级为 off。recommended 和 strict 要求要么显式执行子工作器授权，要么显式阻止门控防止 /hw:start 和 /hw:resume 直到获得授权；off 要求用户显式确认快速单代理降级。此 Codex 授权门控不适用于 Claude Code 或 OpenCode。
计划时的 Subagent、审查者、挑战者和验证者与执行工作器具有相同的生命周期契约：
requested、started、completed|failed|blocked 和 closed|close_failedtest、implement 或 audit 工作器，除非新的授权和范围显式分配该角色P1 在 Codex 授权门控有一个显式结果之前不得进入 P2：
recommendedstrictoff如果用户已完成正常的需求访谈但此授权决策仍然缺失，请留在 P1 并接下来仅询问此门控问题。在门控解决之前不要生成 Milestone、提示或架构产物。
验证答案必须被捕获为真实测试方法契约：确切命令或场景、可观测的通过/失败信号、独立验证者，以及审计是否必须拒绝伪测试。例如：对于 Heaticy 风格的 agent-service 项目，真实方法可能是"使用 NapCat 模拟主账户向代理发送消息"；如果测试工作器仅运行单元模拟或假消息路径，审计工作器必须拒绝它。
然后根据需要继续假设陈述、歧义解决、权衡审查和验证标准。保持此结构强大，但不要将其变成僵化的问卷。
Test Profiles 位于 preset 之上。保持 preset 用于步骤顺序，但通过 execution.test_profiles 或推断的 Discover 上下文收集特定类别的验证策略。
对于可测试的交付，计划必须在分解之前设计闭环验证路径和独立验证所有权。不要接受仅描述代码编写或"稍后运行某些东西"行为的开环计划。
当 execution.worker_separation.mode 为 recommended 或 strict，或功能非平凡到需要独立实现和验证时，P3 Generate 必须始终在生成的提示中分配子工作器任务。此分配是提示契约，而不是可选的运行时即兴创作：
Subworker Assignment Plan 部分test、implement 和 audit，每个角色的范围、禁止重叠、预期证据和交接产物路径test 绑定到 P1 中收集的真实测试方法契约，包括命令/场景、通过/失败信号和伪测试拒绝规则test 拥有红色测试/复现/测试夹具/断言/快照编辑，implement 不得创建、编辑或重写这些测试资产implement 不得生成、模拟或满足 test 或 audit；只有主代理编排工作器创建和生命周期audit 工作器检查最终差异、测试证据、工作器身份分离和验收风险；review_code 是审查步骤/产物阶段，而不是工作器角色Subworker Assignment Plan，但标记为 blocked_until_authorized 并编写启动/恢复门控；hw:start 必须在角色敏感工作之前询问授权而不是删除子工作器分配仅当用户希望在一次对话中规划多个 Feature 并创建 Feature Queue 时，才使用 /hw:plan --batch。
Feature DAG 概念仅属于长期运行、批量、多 Feature、AFK 或 HITL 协调。普通的单 Feature /hw:plan 必须保持简单，不应要求或显示 Feature DAG 字段。
P2 Decompose 是 Milestone 拆解和技术路线拆解的双重检查点。实现型 Milestone 不能只包含目标、验收标准、功能队列或待办列表；如果缺少技术方案和路线，P2 必须保持 in_progress 或 revision，不得标记为 proposed，也不得进入 P3 Generate。
每个实现型 Milestone 必须包含以下字段：
technical_solution：架构选择、数据/接口/状态契约、关键实现策略technical_route：有序实现路线，说明要触达的模块、边界和迁移/兼容处理research_required：调研项状态、证据、阻塞问题或用户确认延后项risks_and_alternatives：主要风险、被拒绝的替代方案和拒绝理由validation_path：闭环验证命令或可执行场景、通过/失败信号和验证负责人audit_focus：审计工作器需要重点检查的行为、证据和风险以下信号是硬性的 research_required 触发器：未知工具、外部服务、第三方库、平台能力、用户私有 schema 或专有数据契约。触发后必须在 P2 确认/P3 之前完成目标调研、向用户提出阻塞问题，或由用户明确接受延后；不能凭猜测把 P2 标记为 proposed。仍有未回答的阻塞问题时，P2 可以展示为待答复检查点，但不得被确认或进入 P3。
如果用户质疑技术路线、指出欠调研或提出替代路线，P2 必须回到 revision 或 in_progress，记录被质疑点，执行有针对性的调研，然后重新展示包含修订结论的 P2 检查点。
使用 /hw:plan --insert <自然语言> 编辑现有 Feature Queue。首先将自然语言请求转换为结构化队列操作，显示队列差异，然后在写入 .pipeline/feature-queue.yaml 之前等待显式确认。
.pipeline/ 已存在，则将规划视为修订或附加，不一定是全新项目plan.mode=interactive（默认）
plan.interaction_depth 并将其转换为最小问题轮次：
low -> 2 轮medium -> 3 轮high -> 5 轮plan.interactive.min_rounds，将其用作额外下限plan.interactive.require_explicit_confirm 缺失，将其视为 trueplan.mode=auto
automation.gates.planning=auto 时，P4 Confirm 才变为仅摘要通过；默认的 confirm 门控即使在自动计划模式下仍然是硬停止/hw:plan --batch 将规划目标从一个 Feature 更改为 Feature Queue。
批量行为：
.pipeline/feature-queue.yaml。upfront 读取 batch.decompose_mode。batch.decompose_mode=upfront，立即将每个 Feature 分解为初始 Milestone。batch.decompose_mode=just_in_time，首先创建队列条目，并延迟 Milestone 分解直到每个 Feature 成为当前。plan.mode=auto 且配置允许无人值守规划，否则保持 P1 交互硬门控。depends_on、blocked_by、execution_hint、handoff_hint 和 ready/blocked 状态。不要创建 Milestone 级别的 DAG 调度。批量产物：
.pipeline/feature-queue.yaml.pipeline/metrics.yaml 缺失时浅初始化.plan-state/batch-discover.yaml.plan-state/batch-decompose.yaml.plan-state/batch-architecture.md/hw:plan --insert 是队列编辑界面，而不是新的规划周期。
支持的自然语言意图：
gate: confirm 暂停 Featuredecompose_mode安全规则：
.pipeline/feature-queue.yaml.pipeline/log.yaml 中记录应用的操作交互式规划是硬对话门控，而不是建议。
❓ 最少提问轮数：
interaction_depth: low -> 至少 2 轮提问interaction_depth: medium -> 至少 3 轮提问（默认）interaction_depth: high -> 至少 5 轮提问❌ 绝对禁止：
✅ 必须做到：
🚨 P1 -> P2 的唯一过渡条件： 用户明确表示「够了」「开始吧」「可以了」等结束信号。用户只是回答问题、补充信息、或说「确认一下」时，继续 P1 追问，不得进入 P2。
Codex 执行子工作器授权也是 P1 -> P2 门控的一部分。如果当前平台是 Codex 且 /hw:start + /hw:resume 执行子工作器授权未被显式授权、显式阻止或显式降级为最快的单代理 off，即使用户说"可以了"，P1 也未完成。在 P2 之前询问授权门控。
当存在 --context 时，注入的上下文可以锐化第一个问题，但不得跳过所需的交互轮次。
除非在 .pipeline/rules.yaml 中禁用，否则 plan-tool-required 内置规则对 Plan Mode 处于活动状态。
todowrite 作为可见的规划状态，使用原生 question / Ask 处理每个交互硬门控。~/.hypo-workflow/config.yaml（如果存在）。.pipeline/config.yaml 读取 plan.mode 和 plan.interaction_depth。--context <sources>。拆分逗号分隔的值，仅允许 audit、patches、deferred、debug 和 explore:E001 风格的探索上下文引用。--batch 和 --insert。没有 --batch 或 --insert 时，保留现有的单 Feature P1-P4 流程。--insert，读取 .pipeline/feature-queue.yaml，将用户请求转换为结构化队列操作，显示队列差异，等待确认，然后应用并记录队列编辑。--context 标志，读取 cycle.yaml 并在存在时使用 cycle.context_sources。plan.mode > 全局 plan.default_mode > interactive。plan.interaction_depth 解析最小轮次，然后应用 plan.interactive.min_rounds 作为下限。/hw:start 和 /hw:resume 或 execution/start-resume 角色authorized recommended、authorized strict、not authorized block start/resume 或 not authorized explicit fastest single-agent offsubcodex 还是 subclaude；不需要单独的授权门控--batch 时，在离开 Discover 之前收集多个 Feature 候选项、优先级、门控、依赖项、验收边界、类别和验证要求technical_solution、technical_route、research_required、risks_and_alternatives、validation_path 和 audit_focusin_progress 或 revision，不得标记为 proposedresearch_required 项；在 P2 确认/P3 前完成调研、询问用户或记录用户明确延后；未回答的阻塞问题不得穿越到 P3revision 或 in_progress，完成针对性调研后重新展示 P2 检查点--batch 且 batch.decompose_mode=upfront 时，分解所有 Feature；当 just_in_time 时，仅创建 Feature 脚手架.pipeline/ 产物和架构基线technical_solution、technical_route、research_required、risks_and_alternatives、validation_path 和 audit_focus 原样保留到生成的提示中，不能压缩成普通目标摘要Subworker Assignment Plan，至少分配：
test：拥有 write_tests 和 review_tests；独立验证计划的真实测试方法、失败证据、最终测试运行和伪测试拒绝规则implement：拥有 Milestone 范围内的实现编辑audit：审查最终差异、证据质量、工作器身份分离和验收风险test 和 implement 工作器被授权或分配之前绝不本地编写测试或实现，并且绝不自身满足三个工作器角色中的任何一个/hw:start 和 /hw:resume 的范围、角色和 Worker Separation 模式execution.worker_separation.mode=off 并记录用户的显式降级确认加上单代理理由Subworker Assignment Plan，标记为 blocked_until_authorized，并编写启动阻止授权门控，以便 /hw:start 和 /hw:resume 在角色敏感工作之前询问或停止subcodex 或 subclaude--batch 时，生成 Feature Queue、Markdown 表格、Mermaid 图和批量架构笔记current.phase 为匹配的规划阶段。plan/PLAN-SKILL.md — 详细的 P1-P4 规划系统references/commands-spec.md — 命令路由语义references/config-spec.md — 计划模式回退规则SKILL.md — 整体管道上下文当请求是调查性的、根因导向的、指标导向的或仓库/系统分析时，使用 workflow_kind: analysis 对其进行分类，并选择 analysis_kind: root_cause | metric | repo_system。
分析规划应将一个 Milestone 视为一个调查问题。Milestone 可能包含多个假设和实验，被反驳的假设是进展而不是失败。
npx claudepluginhub hypoxanthineovo/hypo-workflow --plugin hwRuns the discovery phase of Hypo-Workflow planning: requirement clarification, constraint gathering, repo context analysis, and worker separation decisions. Use before decomposition.
Plans implementation by decomposing work into atomic tasks completable in one context window. Includes goal-backward must-haves, file paths, commands, and code snippets.
Structured deep discussion for Plan Mode. Runs inside EnterPlanMode to ensure thorough questioning before writing a plan. Covers motivation, assumptions, design, acceptance criteria. Call this immediately after entering Plan Mode for any non-trivial task.