athena-dev

name	athena-dev
description	Athena 主入口 skill. 接收用户任务, 做 PACE 路由分诊 (brainstorm/roadmap/plan/...), 启动对应 stage. v9.7.0: 铁律引用名称化 (CC/CX 编号非对称, 引用一律用 铁律[名称]). v9.9.1: 路由输出可审计决策摘要 (候选、证据、权衡、决策、置信度), 不要求暴露私有思维链; re-route 只升不降.

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

触发

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

路由审议 (铁律[分诊] · v9.9.1 决策摘要)

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

路由是 triage, 不是查表. 主 agent 基于证据决策; 对用户只展示结论性摘要, 不展示私有思维链:

Step 0 · 检查上下文

• _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

Step 4 · 护栏校验 (地板, 不可击穿)

≥3 模块 → 至少 roadmap; 跨模块 / 预估 ≥5 文件 → 至少 Refactor. 审议结果低于地板 → 取地板.

Step 5 · 落盘

sprints/{slug}/route-note.md 记录候选、证据、关键权衡、决策、置信度与退出点; 更新 _index.route_confidence. 不写逐步思维过程.