메뉴
维护 .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 是连接两者的一次性桥。