ethos-explore 是一个面向智能体意图梳理的技能，产品定位是“先探索，再做意图访谈”。它解决的问题是：智能体的实现细节大多能从代码读懂，但开发者真正想要什么——使命、边界、权衡、愿景——只存在于人的脑中；如果这些意图缺省，后续评估与修改智能体时，所有人只能从代码和轨迹里去猜。
用途与输出 该技能捕获一个 AI 智能体“应该做什么”：它的角色、目的与结果、范围、边界与成功标准，形成一份持久快照。其输出是 ethos-write 写入 ETHOS.md 的数据——一份人们和智能体在构建、评估、审查或更改该智能体之前阅读的持久契约。创建 ETHOS.md 只记录意图，不授权对智能体应用做任何更改。
工作方式 本技能为“先探索，再强制意图访谈”。流程分两步：第一步扫描代码库与文档，推断实现形状的字段；第二步就源代码无法负责的意图向用户提问。分工原则是：推断实现，询问意图。限制、权衡、原则、使命与愿景存在于用户头脑中，因此是值得花注意力去问的问题。
第一步探索（建议限时约 5 分钟工具调用）：查找智能体定义与入口，如 agent.yaml/agent.yml、.workflow.yaml/.workflow.yml、agents 目录，以及 langgraph、StateGraph、create_react_agent、system_prompt、skills、MCP servers、工具定义等；查找设计上下文，如 README.md、AGENTS.md、产品/设计/规划文档、发布说明与 docs/ 内容；把发现映射到 schema 字段，并诚实区分“从系统提示推断”和“用户确认”。模型只作为约束记录，ETHOS.md 没有 Model 部分。
第二步意图访谈：扫描告诉你智能体是什么，但无法告诉你开发者想要什么，因此在展示 ETHOS.md 草稿前必须进行真实访谈。完成规则：在呈现完整草稿或继续 ethos-write 之前，至少需要三个已回答的意图问题，覆盖 Purpose & Outcomes（目的与结果）、Principles（原则）、Vision（愿景）；用户明确回答“我不知道”或拒绝也算回复，缺口记为 (none) 并写入 Open Questions。必答意图话题包括：目的与结果（确认使命与可问责结果，若从 README 推断出指标，展示并询问是否为目标）、原则（拒绝泛泛美德，追问“粗心的版本不会做、而这个智能体应该做什么”）、愿景（不要未经询问就把未来工作章节抄进愿景）。若 Role 缺失或模糊，应先问 Role，但它不能替代必答话题。其余话题按顺序询问：Constraints（约束）、Trade-offs（权衡）、当仓库只有评估接线时的排序 Success Criteria。不得询问哪些部分可以被优化或更改。
ETHOS.md 结构 前置字段：schema_version（新文件恒为 1，由 ethos-write 写入时填写）、name、created_timestamp（ISO 8601，写入时填写）、author（写入时从作者上下文填写，不明时才问）、owner（可选，仅在 Behavior 或 Constraints 中命名的运行时动作审批需要负责人时询问；已知组织安全政策的负责人也保留，但不开启变更权限访谈）、updated_timestamp（条件字段，编辑时设置，首次写入省略）。
正文十四节按规范顺序排列，全部必填，无内容时写 (none) 而非删除标题：1. Role——一句具体描述该智能体角色的句子，模糊答案下游无用；2. Purpose & Outcomes——分 Mission 与 Outcome 两部分，使命说明为何存在、提供什么用户价值、服务于什么产品或工作流上下文，结果说明可问责的外部结果、可测目标及数字负责人；若为无业务指标的内部工具应明说；3. Scope——受众、3-6 个任务类别、预期的范围内工作与明确的非目标；4. Tools——可用工具、API 与知识源，或写“Prompt-only”，按能力或来源分组，只记行为上重要的用途、凭据/范围、副作用、新鲜度与预期失败；5. Harness——智能体实际如何运行（循环、工具使用、运行时），写真实情况，不按目录挑选命名 harness，不能描述时写 (none)；6. Behavior——行为规则与边界：拒绝/升级策略、语气、安全合规要求、已接受限制与非目标；7. Principles——Behavior 未覆盖时的判断方式，两三个具体判断，不接受“有用、无害、诚实”这类通用答案；8. Success Criteria——独立于现有评估的良好生产行为，可排序；9. Trade-offs——需三项：绝不交易的硬门槛、对其余目标的优先级排序（质量、延迟、成本、可靠性）、不可接受的妥协；10. Constraints——硬外部边界：已批准的提供商/模型/区域、数据驻留与处理、合规义务、生产成本上限与延迟 SLO、需人工签核的运行时动作，已知测量数字放上限旁；不收集应用变更权限；11. Evaluation Setup——当前验证设置：如何运行、数据集/检查、打分器/指标、通过阈值、相对成功标准的已知覆盖缺口；若无评估套件应明说；12. Metric Semantics——模糊或关键指标与遥测字段名的实际含义，及它们不能支撑的结论，名称都明确时写 (none)；13. Vision——超越今日工作的意图，加一两个尚未服务但应成长到的具体用例，不要粘贴过期待办；14. Open Questions——影响安全使用或评估的未决事实，回答后移除。
十四节是下限而非上限：允许额外 ## 标题与额外 YAML 前置键，用户添加则保留，不得为显得“严格”而剥离自定义部分。ETHOS.md 记录持久意图，而非观察到的失败列表；已知问题与反复出现的失败模式应在团队追踪缺陷处记录。
预检与续接 独立入口时，先检查该智能体是否已有 ETHOS.md：在仓库根与智能体包旁查找，命令为 find . -maxdepth 4 -iname ETHOS.md -not -path '/.git/' -not -path '/node_modules/' 2>/dev/null | grep . || echo "no ETHOS.md yet"。若已存在，询问用户编辑现有文件还是重新开始；要编辑则直接转到 ethos-write。若仓库有更早的智能体规范或设计文档，读作先前答案；仍要为其从未回答的内容运行意图访谈。从先前上下文恢复时，遵循编排器续接指引，复用已选智能体、文件位置、来源发现、先前答案与未完成工作，不重复已确定的定位、仓库/智能体选择或编辑/重新开始问题，只检查缺失或已变化的来源上下文；已有文件需要意图澄清时保持该路线，不因文件存在就转向写入器；已完成的访谈从草稿审查恢复。先前答案仅在来源记录了明确用户回复或该话题被接受时才计数。
适用场景与限制 适用于为智能体建立持久意图契约、评估前对齐目的与标准、审查或修改智能体前的背景确认，以及绿地方案（此时先问 Role、Scope 与是否 prompt-only）。限制包括：需用户配合完成意图访谈；代码扫描无法提供意图；不收集应用变更权限；不收集单次运行限制（一次评估的花费上限或实验次数属于运行它的工具）；保留既有组织安全与审查政策，包括带写权限工具上线前的必需安全审查。