用途
map 解决的是“知道有事要做，但不知道由哪个技能负责”的定位问题。用户需要在下方找到对应的工作项，然后沿其路线执行。大多数路线会调用 Skill 工具；标注为 manual 的路线给出斜杠命令，由用户自行调用，因为此时模型调用被禁用。map 只负责路由与说明一次，不重复解释——每个被路由到的技能各自拥有自己的行为准则。
交付循环（主路线）
按顺序对应的工作项与技能：
- 外部工作到达（issues、PRs、reports）→ harbor
- 非工程人员把聊天记录作为需求交给你 → intent
- 目标尚不清晰，前三个决策还无法陈述 → ask-navigator
- 想法模糊，必须先提问再做其他事 → deep-interview
- 需求明确，需要一份计划 → plan（多视角共识：ralplan）
- 计划已批准，需要分解并端到端交付，带人工检查点 → launch
- 单个任务，持续执行直到验证完成 → ralph
- 从想法到代码的全自动 → autopilot
- 工作需要协调的并行执行者 → team
- 一个已批准的任务，一直做到通过验证的代码 → execute
- 一个散文无法解决的设计问题 → loft
- 已完成的工作需要判断 → review
- 有东西声称已完成 → verify
- 工作正作为 PR 落地 → pr
- 本次运行让环境学到了东西 → refit
入口路线（脱离主循环）
- 一个 bug 需要定位根因 → debug；竞争性假设追踪：trace
- 应由测试驱动实现 → tdd
- 代码库越来越难以修改 → architecture-survey
- AI 生成的劣质内容需要清理 → ai-slop-cleaner
- 一个开放问题需要扎实的答案 → research；外部文档：external-context
- 知识应在多次会话间积累 → wiki；持久项目记忆：remember
- 需要一个可重复的自主改进循环 → self-improve；持久目标账本：ultragoal
- 一次会话需要在其转向与结果之间重新定位 → session-flow — 手动运行 /oh-my-claudecode:session-flow
- 视觉工作需要判定或图表 → visual-verdict；diagram
实用工具
- 安装、诊断、配置 → omc-setup；omc-doctor；configure-notifications
- 管理技能自身 → skill（本地）；skillify（从会话中提取）
- 检查编排状态 → trace（同时也是追踪通道）；graph（DAG 运行时）
- 取消某个模式 → cancel
规则
map 只路由，从不执行。每个普通行对应一次 Skill 工具调用——进行该调用，然后遵循那个技能的行为准则。对于仅限手动的路线，向用户展示其斜杠命令；不要尝试调用 Skill 工具。
当两行都符合时，以上面的交付循环作为裁决依据：更靠前的环节优先。
阶段边界（继续／从磁盘重新进入／交接／压缩）在 launch 的 Context hygiene 中定义——map 不重复陈述这些内容。
找不到任何一行与之匹配的工作，本身就是信息：如实说明，而不是挑选听起来最接近的技能。
使用方式与限制
使用方式：先确定当前手上的工作项，在交付循环或入口路线中找到对应行，然后按该路线调用相应技能或手动输入斜杠命令。map 自身不执行任务，仅作导航。若同时匹配多行，按交付循环中更早的环节优先。若没有匹配项，应直接说明没有对应技能，而非勉强选择相似的技能。
限制：资料中未提供安装命令、收费标准、平台支持范围等信息，暂未提供。