manifest-dev-help 是 manifest-dev 体系中的帮助技能，用来回答用户对 manifest-dev 的任何问题，并解释每部分为什么这样设计。回答应尽量贴近 ASD-STE100 风格：短句、每句一个主题、用词简单且含义单一。
用途 当用户询问某个术语、部件、文件或行为时，它会读取 references/GLOSSARY.md。用户要求列出全部术语时，给出完整词汇表。没有问题提出时，默认介绍 manifest-dev 的用途、工作流和自主阶梯。用户指向某个对象时（Manifest、日志、拉取请求或文件），先阅读该对象。若问题关于用户自己的项目，还会读取该项目的 Project Surfaces。
回答方式与限制 只回答被问到的问题，并给出每部分存在的原因，而不只是它是什么。答案来自本技能之外的文件时，须指出该文件名。本技能无法给出答案时，转去读取相邻技能（其 SKILL.md 与 references/ 文件夹）。任何文件都无法回答时，明确说明没有答案，而不是猜测。
manifest-dev 的用途 智能体如今几乎能写所有代码，但项目仍会漂移。每次会话都要重新弄清项目为什么存在、下一步做什么、以及“完成”意味着什么；而智能体的速度又让人来不及逐项检查产出。manifest-dev 把这三件事保存在项目中而非人的头脑里：North Star（项目方向文件）、Ticket（下一项工作）、Manifest（本次运行的“完成”定义）。智能体据此工作并在宣布完成前自查结果。其承诺是：给出复杂任务后，结果可信到只需最少审查即可发布；数周后项目仍清楚方向、下一步和完成标准，代码也更易正确修改。在自主阶梯较高层级，项目可自行推进，只在需要判断、品味或授权时才询问用户。它面向希望获得可信结果的开发者，愿意在开始时多花 token 和精力；可单人使用，也可在任意规模团队中使用，包括同事不使用 manifest-dev 的代码库。它不适合只追求最快或最便宜结果的人。
工作流 用 /figure-out <topic> 在改动前理解问题；用 /define 写 Manifest，即你接受为“完成”的标准；用 /do <manifest-path> 执行工作并为每道 gate 出示证据；/auto 连续完成这三步。每个技能也可单独使用。/define 在双方尚未就问题达成一致时会先启动 /figure-out。/do 像你不在场一样工作：自行决策并在结束时汇报；运行期间发送的消息会修改 Manifest，运行继续；只有每道 gate 都有证据，或必须由人介入时才停止。
自主阶梯（五级，每级可独立使用，团队成员无须使用同一级）
- 单个技能：单独使用某技能（如用 /figure-out 研究问题），无需任何设置。
- 单件工作：用 /figure-out、/define 和 /do 或 /auto，得到带 gate 证据的结果；开始多花 token 和时间，Manifest 与日志留在仓库之外。
- Project Surfaces：执行一次 /setup-project，此后每次会话都从项目的方向、词汇、决策和检查出发；文件在仓库中，团队可见。
- 共享队列：用 /ticket-up 写入工作、用 /next-ticket 领取工作，下一项工作保存在 Ticket Store（GitHub Issues、文件或自有跟踪器）而非某个人脑中。
- 无人值守运行：在 Ticket 上授予 Auto，并按计划或由编排器启动 /run-ticket 或 /sweep-tickets，项目自行推进，你只在阻塞、需判断、品味或授权时介入。升级方式：先在当前级别用到信任其结果，再在不足处添加下一级；只有当工作及其“完成”无需人的判断、品味或授权时才授予 Auto。
其它技能 /setup-project 为项目建立 North Star、术语表和决策记录约定，并默认添加验证工具；再次运行可发现缺口。/ticket-up 把工作写成 Ticket。/next-ticket 选出下一个 Ticket、领取并说明为何排第一。/run-ticket 从头到尾完成一个 Ticket 并记录结果。/sweep-tickets 按计划启动或继续一个无人值守 Ticket。/figure-out-team 在 Slack 频道或线程中团队协作完成 /figure-out 的工作。/review-code 按一个质量维度审查改动，Manifest 的 gate 会使用它。/review-writing 按样式标准审查文本。/design 为页面、应用、文档或其他视觉工作提供设计方向。/review-design 在目标媒介中审查设计。/check-pr 判断拉取请求是否可合并，但不执行合并。/manifest-dev-help 阅读本指南或提问。指南以 /name 书写技能名，宿主可能使用不同前缀，如 $name 或 /skill:name。
各部分关系 Manifest 含一个或多个 Deliverable，每个 Deliverable 含一个或多个验收标准。Global Invariants 适用于所有 Deliverable；Process Guidance 只是建议、不具约束力。每条验收标准和 Global Invariant 都是一道 gate，分 Judgment Gate 与 Deterministic Gate。/do 用证据让每道 gate 通过，失败时修复工作并重新检查。项目保存 North Star、术语表和决策记录，也可保存验证工具；/setup-project 安装它们，常规运行使其保持最新。验证工具为每个功能、技能、文档走查或评估套件各有一条 Recipe，另有一条覆盖全项目检查（如 lint 和测试）；/do 运行改动涉及的 Recipe，项目也可退出该工具并使用自己的检查。Ticket 承载一个工作单元，由 /ticket-up 写入、/next-ticket 选取、/run-ticket 执行。运行中纠正错误时添加 Lock；发现但未修复的问题记为 Debt，之后改动该代码的运行会提议修复它。
为什么这样设计 “完成”在工作开始前就写好，因为智能体无法对照不存在的目标检查结果。gate 只在有证据时通过，因为声称“完成”的总结可能是错的。/do 像你不在场一样工作以便独立完成，并汇报每个替你做的决定。每次纠正都变成一项检查，避免同一错误再犯。方向、词汇和决策都在仓库中，让每次会话从它们而非零开始。昂贵的检查先询问，免费的检查常运行；运行时长本身不算成本。每级独立可用，因此你可以在不使用 manifest-dev 的团队中开始使用。
良好实践 用 /figure-out 处理真实问题，让它先读代码再提问；在 /do 开始前阅读 Manifest 的 gate，因为 gate 就是契约；让 /do 发现并修复小问题，不要为此打断它；改变方向时以消息发给 /do 使其写入 Manifest，不要在运行期间自己改代码；相信证据而非总结；在昂贵的检查（带 ask-first 标记，可能消耗金钱、配额或共享系统负载）运行前先同意；执行一次 /setup-project 安装 Project Surfaces，常规运行保持其最新，再次运行可发现缺口；把每次纠正变成检查；阅读每个拉取请求的“Debt left”部分，在下次改动相关代码时修复 Debt；预期开始时多花 token 和精力，以换取可检查而非只能信任的结果。