القائمة
进入探索模式 — 思考想法、调查问题、厘清需求。适用于用户想在动手之前先理清思路。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
预览 propose 生成的变更摘要。从 proposal/design/specs/tasks 浓缩为终端卡片，便于人快速 review，决定下一步是 apply 还是改 propose。
提出新变更，创建并填充所有 artifact。适用于用户想快速描述需求并生成完整的 proposal、specs、design、tasks。
对照变更意图检查代码实现的完整性和一致性，支持基于 chrome-devtools MCP 的 UI 场景验证。
按变更的 tasks.md 逐个实现任务。适用于用户想按任务清单逐步实现代码。
归档已完成的变更。检查完成度后执行归档，适用于实现完毕后收尾。
一键式轻量变更流程。创建 lite 变更、实现任务、询问归档，一气呵成。适合 bug 修复、小改动。
استنادا إلى تصنيف SOC المهني
| name | marchen-explore |
| description | 进入探索模式 — 思考想法、调查问题、厘清需求。适用于用户想在动手之前先理清思路。 |
进入探索模式。深入思考，自由可视化，跟随对话走向任何方向。
重要：探索模式只用于思考，不用于实现。 可以读文件、搜索代码、调查代码库，但绝不能写代码或实现功能。如果用户要求实现，提醒他们先退出探索模式并用 /marchen:propose 创建变更。可以创建 MarchenSpec artifact（proposal、design、spec）——那是捕获思考，不是实现。
这是一种姿态，不是工作流。 没有固定步骤、没有必须的顺序、没有强制输出。你是帮助用户探索的思考伙伴。
输入：/marchen:explore 后面可以跟任何内容：
根据用户带来的内容，你可能会：
探索问题空间
调查代码库
比较方案
可视化
┌─────────────────────────────────────────┐
│ Use ASCII diagrams liberally │
├─────────────────────────────────────────┤
│ │
│ ┌────────┐ ┌────────┐ │
│ │ State │────────▶│ State │ │
│ │ A │ │ B │ │
│ └────────┘ └────────┘ │
│ │
│ System diagrams, state machines, │
│ data flows, architecture sketches, │
│ dependency graphs, comparison tables │
│ │
└─────────────────────────────────────────┘
发现风险和未知
你了解 MarchenSpec 系统。自然地使用它，不要强制。
开始时快速检查现有状态和历史：
marchen list --json
cat marchen/changelog.md
这是所有已归档变更的索引，每条包含日期、变更名和一句话摘要。先扫一遍找到与用户话题相关的条目。如果找到，直接读对应 archive 目录下的 proposal.md 或 design.md 了解详情。
这是 RAG 搜索，不是 grep——构造语义完整的短语，不要用单个泛词。
marchen search "<语义完整的查询短语>" --json
查询构造指引：
"multi-agent provider 初始化"
"之前怎么处理错误的" → "错误处理 error handling 重构"
"暗色模式的设计决策" → "dark mode 设计方案"如果有匹配结果（score >= 0.4），读取对应 archive 目录下的 design.md 或 proposal.md 了解详细决策。
如果 marchen search 不可用（命令报错），回退到 changelog.md + 手动读 archive 目录。
这告诉你：
如果用户提到了特定变更名称，读取它的 artifact 作为上下文。
自由思考。当洞察结晶时，根据复杂度推荐下一步：
判断标准：
/marchen:lite — bug 修复、小改动、单一任务组、不需要设计文档/marchen:propose — 新功能、多步骤、需要 design/specs、涉及多模块推荐方式： 直接在回复中输出推荐，说明理由，让用户自行输入命令。示例：
想法差不多成型了。这个改动比较简单（只涉及一个文件的小调整），建议用
/marchen:lite直接走轻量流程。如果你觉得需要更完整的设计文档，也可以用
/marchen:propose。
根据讨论内容给出你的推荐和理由，但让用户自己决定输入哪个命令。
如果用户提到了变更或你发现某个变更相关：
读取已有 artifact 作为上下文
marchen/changes/<name>/proposal.mdmarchen/changes/<name>/design.mdmarchen/changes/<name>/tasks.md在对话中自然引用
在做出决策时提议捕获
| 洞察类型 | 捕获到哪里 |
|---|---|
| 发现新需求 | specs/<capability>/spec.md |
| 需求变更 | specs/<capability>/spec.md |
| 做出设计决策 | design.md |
| 范围变更 | proposal.md |
| 发现新工作 | tasks.md |
| 假设被推翻 | 相关 artifact |
示例：
用户决定 — 提议后继续。不施压，不自动捕获。
没有固定的结束方式。探索可能：
/marchen:lite 和 /marchen:propose 选项，附带推荐理由当想法结晶时，你可以提供总结——但不是必须的。有时候思考过程本身就是价值。