规范化 Git 提交 + 知识库同步（~commit 命令）
显示 HelloAGENTS 可用命令和当前设置（~help 命令）
初始化项目工作流并同步知识库
已进入显式 UI 工作流、宿主全局模式下的 UI 任务、已初始化项目的视觉变更、设计系统改造或需要视觉验收时使用；在通用 UI 基线之上补充项目契约执行、设计系统映射与视觉验证。
按任务类型适用 — 建立质量驱动工作流，通过技能标准、流程纪律和检查清单保障交付质量
长任务入口 — 在 Codex 中优先走 `/goal -> ~auto -> ~qa`，把长程续跑交给 `/goal`，把执行推进交给 `~auto`，把最终质量闭环交给 `~qa`（~loop 命令）
| name | ~plan |
| description | 结构化规划工作流 — 需求澄清、方案确认、任务分解与方案包生成（~plan 命令） |
| policy | {"allow_implicit_invocation":false} |
Trigger: ~plan [description]
~plan 是实现前的主规划命令。它负责需求澄清、方案设计、任务拆解与方案写入；直接显式执行 ~plan 时，默认停在“形成可执行方案”，只有用户明确授权继续时才继续执行。
执行 ~plan 时，通用阶段边界按当前已加载的 HelloAGENTS 规则执行；本 skill 负责补充 ~plan 的需求澄清、方案确认、方案包写入与继续执行要求。
.helloagents/ 在本 skill 中统一按项目级存储路径理解：状态文件只使用 state_path；会话证据使用当前 state_path 所在目录下的 artifacts/*.json；若 project_store_mode=repo-shared，知识库、DESIGN.md 与 plans/ / archive/ 按当前上下文中已注入的项目知识/方案目录解析。
~auto，则“开始执行”视为已包含在 ~auto 授权内；方案包写入后默认继续执行，只有命中阻塞判定时才停下。~design 是 ~plan 的兼容别名，只有在 ~auto 内触发其语义时才默认继续进入 ~build.helloagents/DESIGN.md；.helloagents/DESIGN.md（按当前项目存储模式解析）优先于已读取的 hello-ui 规则；同时所有 UI 任务都必须满足 UI 质量基线已有项目：
state_path，再用当前用户消息、显式命令、活跃方案包 / PRD 与代码事实确认当前任务.helloagents/context.md、.helloagents/guidelines.md（按当前项目存储模式解析）；涉及 UI 时，如存在 .helloagents/DESIGN.md（按当前项目存储模式解析），一并读取现有设计契约全新项目（无 .helloagents/ 目录）：
目标：通过自然对话明确目的、约束、成功标准与验收边界。
根据项目类型选择模式：
假设模式（已有代码库，优先使用）：
.helloagents/context.md 的领域语言冲突时，立即澄清并统一术语交互模式（全新项目或信息不足）：
涉及视觉/交互/体验的问题时：
基于已确认需求，给出 2-3 个可行方案：
涉及 UI 的方案：
hello-ui SKILL.mdplan.md，后者同步到 .helloagents/DESIGN.md（按当前项目存储模式解析）用户确认方向后，一次性输出完整可执行方案：
qaMode、qaFocus、进入收尾前必须补齐的质量证据）DESIGN.md 更新点.helloagents/context.md 的“领域语言”区块（按当前项目存储模式解析）将确认的方案写入本地项目：
.helloagents/ 与最小流程状态.helloagents/plans/YYYYMMDDHHMM_{feature}/（按当前项目存储模式解析；repo-shared 时写入当前项目方案目录）{HELLOAGENTS_READ_ROOT}/templates/plans/ 为源模板，在上述方案包目标目录内写入：
requirements.mdplan.mdtasks.mdcontract.jsoncontract.json 时，至少落成以下字段：qaMode、qaFocus；涉及 UI 时再写 ui.required、ui.designContract 与 ui.sourcePriorityui.styleAdvisor.required、ui.styleAdvisor.reason 与 ui.styleAdvisor.focus；它复用当前会话 artifacts/advisor.json，不是默认常驻步骤ui.visualValidation.required、ui.visualValidation.reason、ui.visualValidation.screens 与 ui.visualValidation.states；不要把视觉验收扩成所有 UI 任务的固定步骤T3、非 UI 的高风险审查或确需额外跨模型建议时，才写 advisor.required、advisor.reason、advisor.focus 与 advisor.preferredSources；不要把 advisor 变成默认常驻流程scripts/plan-contract.mjs write 写 contract.json，不要让后续检查脚本再从 plan.md 的自然语言说明里猜验证主路径tasks.md 中保留 “Codex /goal 执行入口”，内容必须引用当前方案包路径、AFK/HITL 边界，并明确 /goal -> ~auto -> ~qa 这条链路；不要把普通 PRD 原文当作 /goal 目标.helloagents/DESIGN.md（按当前项目存储模式解析）；若原文件不存在，先按模板建立最小设计契约，再写入已确认的稳定设计决策state_path，其中“主线目标”写本次规划要完成的目标，不保留其他任务的内容知识库完整创建与归档按当前已加载的 HelloAGENTS 规则继续处理。
展示方案摘要后，仅在是否进入执行仍构成阻塞决策时才询问用户：
~buildstate_path；“主线目标”写当前已确认方案要解决的问题，下一步写为“方案已确认；执行需用户明确启动”如果用户已明确表示继续执行，则视为授权成立，可直接继续执行。
如果当前任务来自 ~auto，且方案包已足够支撑实现、也未命中阻塞判定，则默认直接进入 ~build，不再追加一次“是否开始执行”的询问。
如果当前任务是显式 ~plan 或 ~design，且尚未获得执行授权，最终回复按通用输出格式使用等待输入态：正文说明方案包与验证结果，🔄 下一步 写清待确认动作。
方案包中的 tasks.md 必须满足：
AFK 或 HITL：AFK 表示代理可独立完成，HITL 表示需要用户决策、外部凭据、人工视觉确认或手动验收tasks.md 执行，默认主执行命令是 ~auto，最终必须进入 ~qa，而不是直接消费未拆分需求文档方案包中的 contract.json 必须满足：
qaMode 只能是 standard 或 deepqaFocus 必填ui.styleAdvisor，必须写清触发原因与 focusui.visualValidation，必须写清触发原因，以及至少一组关键 screens 或 states