| 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.2)
触发
用户进任意项目, 说 "开始", "做个 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. 不写逐步思维过程.
