先看它的加载模型
HelloAGENTS 在 Claude Code、Gemini CLI、Grok Build、Cursor 和 Codex CLI 之上加了一层工作流。它的核心特性里有两件和「组织方式」直接相关：14 项内置工作流技能，以及一批 ~ 前缀命令。
README 给的原则很克制：技能只在当前阶段需要时才加载，简单任务保持轻量，复杂工作才接受更严格检查；命令技能直接读取，工作流不需要时不会加载无关技能。它不是把规则一次性灌进上下文，而是按阶段做路由。
装完之后，技能从哪里读
v3 是基于 Node.js 的完全重写版本，v2.x 的旧 Python 分支已归档到 helloagents-archive。安装与宿主部署是两件事。
第一条命令只装包。postinstall 会初始化 ~/.helloagents/helloagents.json 并把运行时文件同步到 ~/.helloagents/helloagents；除非设置 HELLOAGENTS=target[:mode]，否则不会部署任何宿主命令行。想在看证据前先对照同类插件的中文清单与安装形态，见 DeepSeek Harness Hub 插件清单。
部署后在 AI 命令行输入 ~help 验证；不识别时先跑 helloagents doctor 并重启目标 CLI。切换模式后也要重启或开新会话，已在跑的会话不会自动重载注入的规则。
14 项技能是按任务类型激活的
技能清单本身就能看出分类逻辑。UI 有 hello-ui（UI 规划、设计契约、实现映射、视觉验证）；接口有 hello-api（设计、校验、错误格式、兼容性）；安全有 hello-security（认证、密钥、权限、注入风险）；测试有 hello-test（TDD、覆盖率、边界情况、测试结构）。
质量与收尾由 qa-review 统一负责：统一质量审查、验证命令、阻塞性修复、交付证据、收尾。注意它和 ~qa 命令不是一回事------一个是技能，定义行为；一个是命令，触发流程。
再往下按领域切分：hello-errors（错误处理、日志、重试与恢复）、hello-perf（性能、缓存、查询与渲染风险）、hello-data（数据库、迁移、事务、索引）、hello-arch（架构、边界、代码规模、可维护性）、hello-debug（Bug 诊断，卡住时升级处理）。
最后是三项元能力：hello-subagent（子代理委派与结果整合）、hello-write（文档与报告）、hello-reflect（可复用的经验教训与知识更新）；加上 helloagents 技能本身，它负责命令路由、工作流阶段规则、项目知识、状态协调，把所有其他技能串起来。
~ 命令路由与兼容别名
命令以 ~ 前缀在聊天里运行，用于显式指定路径。澄清类有 ~ask（通过问答锁定目标、方向、范围和约束，不写文件）；推进类有 ~auto（选主路径并持续推进到交付或真阻塞）与 ~build（按当前请求或已有计划实现）；规划类有 ~plan（需求、方案设计、任务拆解、计划包）与 ~prd（逐维度引导生成现代 PRD）。
质量与维护类包括 ~qa（统一质量循环：审查、验证命令、修复、收尾）、~test（为目标模块或最近改动写测试）、~commit（生成 conventional commit 信息并同步知识）、~clean（归档已完成计划、清理临时运行时文件）。入口类有 ~init（初始化项目工作流并同步项目知识）、~loop（长时间运行入口，在 Codex 中优先走 /goal -> ~auto -> ~qa）、~help（显示命令和当前设置）。
兼容别名有四个：~do → ~build、~design → ~plan、~review → ~qa、~idea → ~ask（已废弃）。
路由的意义在于上下文经济：~ask 只做对话、不产生文件，所以在纯讨论场景下不会污染仓库；~plan 才落盘计划包（requirements.md、plan.md、tasks.md、contract.json），contract.json 决定 qaMode、qaFocus、可选的 advisor 检查与可视化验证。
命令技能与工作流阶段的加载边界
工作流阶段模型是：路由与分层 → 目标澄清 → 规划 → 实现 → 质量循环 → 收尾与归档。路由与分层决定任务该走 ~ask、~plan、~build、~qa、~prd 还是自动流；后面各阶段分别负责确认目标与成功标准、准备计划文件并选技能、跑本地检查、审查并检查契约与证据、更新状态与收尾证据。
命令技能与阶段规则的加载边界就体现在这里：命令技能负责「用户按了哪个入口」，阶段规则负责「进去之后按什么顺序走」，任务技能只在对应阶段被拉进来。三者不是同一层东西，混着理解就会觉得它「什么都管」。它另有一层常驻核心规则放在 bootstrap.md / bootstrap-lite.md，把智能体锚定为可信环境中有能力的执行者，并要求在宣告阻塞前穷尽替代路径。
Codex 这边的托管配置与 hook 信任状态
Codex 是这套集成里细节最多的一支，因为它默认是规则文件驱动的。
standby 模式下，它写 ~/.codex/AGENTS.md，写一条托管且可移植的 model_instructions_file = "~/.codex/AGENTS.md"，还写一条同样可移植的 notify = ["helloagents-js", "codex-notify"] 用于收尾通知------重装、更新或换机都不需要重写绝对路径。
它还写静默的 Codex hooks 到 ~/.codex/hooks.json。设计取舍是：SessionStart 保持静默，并在运行时读取当前的 ~/.helloagents/helloagents.json，而不是把配置快照烘进 config.toml，好处是首轮与压缩后的设置都保持最新。
安装与更新还会把托管的 Codex hook 信任状态同步到 ~/.codex/config.toml，这样 Codex 0.129.0+ 不会重复提示托管 hooks。但要注意：这个信任状态是机器本地生成元数据，由当前 ~/.codex/hooks.json 的绝对路径派生，不是可移植配置，每台机器都要重新生成。全局模式下 Codex 安装原生 local-plugin 链，但仍以 ~/.helloagents/helloagents 作为唯一的托管运行时来源；hooks 只同步运行时状态并执行 Stop 门禁，不注入规则，closeout 还会对 Stop hooks 与原 codex-notify 去重，一轮不会通知两次。
/goal 是可选加速器，不是依赖
Codex 的 /goal 是原生的，需要 helloagents codex goals enable 显式开启。README 口径很明确：当前 OpenAI 文档仍把 /goal 标为 experimental，Codex app 支持仍是 preview，所以 HelloAGENTS 把它当作可选的 Codex 原生加速器，而不是必需运行时依赖。
长任务链路的默认形态是 /goal -> ~auto -> ~qa：Codex 负责长时间运行的续接，~auto 执行 AFK 工作，~qa 在收尾前仍是最后的质量关卡。Goal 相关命令从 tasks.md、contract.json 和 state_path 恢复，不会自动创建 goal，也不会在验证与收尾前把它标记完成。tasks.md 里预置的 Codex /goal 入口，就是 ~loop 用的那个。
总结
把技能按阶段加载、把命令当作显式路由、把 Codex 的托管配置与机器本地信任状态分开处理，是这套组织方式的三条主线；想对照更多同类插件的中文清单与安装形态，见 DeepSeek Harness Hub 插件清单。
适合与不适合
适合 ：已经在用 Codex CLI、希望把托管注入、notify 与 Stop 门禁一次配好的人；希望通过 ~ 命令显式控制走澄清还是规划还是质检的多步任务；需要按任务类型自动加载质量技能的复杂项目；想通过 bootstrap 层约束智能体不甩锅的团队。
不适合 ：只需要单条命令、不打算理解阶段模型的轻度用户；无法接受安全扫描 🔴 高危（21 处证据、尚无人工评估）且不愿自行核查的人；依赖 Codex 之外宿主做深度定制，或期望 /goal 已经稳定的场景------它仍是 experimental。
标签：HelloAGENTS、DeepSeek Harness、技能与命令路由、进阶用法
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。