القائمة
维护 .ai_state/requirements/ 长效需求档 (软件要素: 为什么要这个能力). 原始用户故事 + 当时权衡, 独立于会演化的 design.md —— 代码烂掉时弃码重生的逃生通道. 借 CodeStable requirements 实体, 适配 agent-in-loop: 需求落盘可召回, 隐知识不丢.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Athena 全局首次配置 (跨项目, 一次性). 从分发包部署 settings/config/rules/standards/hooks/agents/skills 到 ~/.claude/ (CC) 与 ~/.codex/ (CX). 和 athena-init 区别: setup 全局一次性, init 每项目一次. 已装则转 verify/upgrade (走 athena-migrate).
会话记忆固化 skill (v9.8.0 新). 会话结束/中途, agent 自己总结本会话增量写进 .ai_state (_index.md 当前状态 + sprints/{slug}/session-log.md), 免去用户每次手动描述一堆让它存. 手动 /checkpoint 触发. 与 compact-snapshot hook 互补 (hook 机械兜底, skill 做需推理的总结).
Athena 主入口 skill. 接收用户任务, 做 PACE 路由分诊 (brainstorm/roadmap/plan/...), 启动对应 stage. v9.7.0: 铁律引用名称化 (CC/CX 编号非对称, 引用一律用 铁律[名称]).
Athena 项目初始化 skill. 在项目中执行 /athena-init 时调用. 职责: 探测平台 / 工具可用性, 创建 .ai_state/ 目录 + 复制 _index.md 模板 + 填入探测结果.
Bugfix 路径的结构化问题流程: report → analyze → fix-note 三件套档案, 落在 sprints/{slug}/. 把"偏轻"的 Bugfix 升级成可复现 / 可追溯 / 可复盘. 借 CodeStable issue 实体, 适配 agent-in-loop.
Athena 版本迁移工具. v9.6.4 重写: 含 v9.6.2 → v9.6.4 破坏式重构 (sprints/ + compound/ + 4 新 ai_state 文件 + lessons.md 三选项交互).
| name | athena-requirements |
| description | 维护 .ai_state/requirements/ 长效需求档 (软件要素: 为什么要这个能力). 原始用户故事 + 当时权衡, 独立于会演化的 design.md —— 代码烂掉时弃码重生的逃生通道. 借 CodeStable requirements 实体, 适配 agent-in-loop: 需求落盘可召回, 隐知识不丢. |
| effort | medium |
Athena 原本 brainstorm → design → impl, 没有独立的"原始需求 + 当时权衡"长效档. design.md 随实现演化, 半年后回看已认不出"最初到底要解决什么、为什么这么取舍". 本 skill 把需求作为软件要素独立存档 (借 CodeStable), WHY 与 HOW 分离。
| 档案 | 答什么 | 演化性 |
|---|---|---|
| requirements/{slug}.md (本) | 为什么要这能力 + 当时权衡 | 长效, 只在需求本身变时改 |
| architecture/{type}-{slug}.md | 现在长什么样 | 长效, 随实现刷新 |
| sprints/{slug}/design.md | 这次怎么做 | 一次性, 随 sprint 丢 |
| compound/decision-*.md | 为什么这样选 (技术) | 永久 |
逃生通道 (CodeStable 核心价值): 代码烂成一坨时, requirements/ 是弃码重生的依据 —— 留着需求和权衡, 让 agent 重新生成实现, 而不是对着烂代码缝缝补补.
| 时机 | 强制度 |
|---|---|
| Feature / System 路径 (新能力) plan 前 (brainstorm 收敛后) | 建议 先落 requirement |
用户显式 /athena-requirements {slug} | 触发 |
| 需求变更 (范围 / 验收标准变了) | 强制 更新对应 requirements/{slug}.md |
| roadmap 拆分大需求 | 每条子 feature 一条 requirement |
| Bugfix / Quick / Hotfix | 跳过 (无新需求, 是修既有) |
.ai_state/requirements/{slug}.md---
slug: jwt-refresh
status: active # active | superseded | dropped
created: 2026-06-22
linked_sprints: [] # 实现它的 sprint slug 列表
---
# 需求: {一句话}
## 原始用户故事
[用户原话 / 场景: 作为 X, 我想 Y, 以便 Z]
## 当时的权衡 (为什么这样圈定范围)
- 要: ...
- 不要 (本期划出去的): ... — 因为 ...
- 取舍: 选 A 不选 B, 因为 ...
## 高层验收 (能力级, 非实现级)
- [ ] ...
## 逃生通道备注
[若弃码重生, 哪些约束/边界必须保留]
design.md frontmatter 加 req_ref: requirements/{slug}.md. 这样 review 的 spec-compliance 不只对 design, 还能回溯原始需求, 抓"实现偏离了最初意图"这一层 (design 自己可能就已经偏了)。
requirements/{slug}.mdreq_ref_index.pointers.latest_requirementrequirements/ (WHY 长效) 和 architecture/ (HOW 长效) 是一对: 一个记"要解决什么", 一个记"现在长啥样". design.md 是连接两者的一次性桥。