athena-dev

name	athena-dev
description	Athena 主入口 skill. 接收用户任务, 做 PACE 路由分诊 (brainstorm/roadmap/plan/...), 启动对应 stage. v9.7.0: 铁律引用名称化 (CC/CX 编号非对称, 引用一律用 铁律[名称]). v9.9.0: 路由审议思维链 — 感知→假设→四维权衡→决策+置信度→落盘 route-note; 中途 re-route 只升不降.
effort	medium

/athena-dev — Athena 主入口 (v9.9.0)

触发

用户进任意项目, 说 "开始", "做个 X", "帮我 Y" 等. 主 agent 进入路由分诊.

路由审议 (铁律[分诊] · v9.9.0 思维链协议)

前置: 无 .ai_state/ → 提示先跑 /athena-init, 停. 用户显式声明生产事故/hotfix → 直接进 plan(Hotfix) (唯一免审议).

路由是 triage, 不是查表. 每次收到任务, 在回复里走一遍审议 (对用户可见, 3-8 行, 不长篇大论):

Step 0 · 感知 (30 秒内能拿到的事实)

• _index.md: 当前 stage / path / route_history (上次路由错在哪) / counts (项目成熟度)
• git log --oneline -10: 最近在动哪些模块
• 输入中的显式信号: "重构" / "bug" / "讨论" 等关键词是强证据, 计入权衡但不短路直判 — "重构一下这个函数"不该触发 Refactor 全套流程

Step 1 · 假设

提出 ≥2 个候选 (路径或 stage), 各列支持/反对证据. 只有一个候选 = 没认真想.

Step 2 · 四维权衡

维度	问自己
爆炸半径	波及几个文件/模块? 碰 CI / 数据 / 外部接口吗?
可逆性	做错了 revert 一个 commit 能回来吗?
紧急度	用户在救火还是在建设?
需求不确定性	能直接写出验收标准吗? 写不出 = 模糊 → brainstorm

Step 3 · 决策 + 置信度

• ≥0.8: 直接进路径
• 0.5–0.8: 带假设进 — route-note 写明假设 + 廉价退出点 (什么信号出现就 re-route)
• <0.5: 停. 问用户 1-2 个决定性问题 (能砍掉一半候选的那种), 或进 brainstorm