菜单
生成或审计模块的 SPEC.md。使用场景：用户要求"给 XX 模块写 spec"、"审计所有 spec"、"检查 spec 是否过期"。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Automates SailFish release workflow: fix build/type errors, update CHANGELOG (EN + CN), run npm version with pre/post hooks. Use when the user asks to release, 发版, 发布, bump version, or update changelog.
后端代码修改后，通过 CLI 测试验证功能正确性。使用场景：修改了 electron/services/ 下的代码需要测试、准备提交代码前跑回归、用户要求"跑测试"/"验证一下"。
完成新功能开发或较大修改后，使用本机 Claude CLI 进行代码审查。
使用 ts-morph 静态分析工具查询代码结构（类层次、方法签名、引用、依赖等），替代手动读源码。使用场景：需要了解类的方法/属性、继承链、符号引用、文件结构、依赖关系时。
When committing or staging changes, only include files related to the current task or conversation; do not stage or commit unrelated modifications. Use when the user asks to commit, stage, 提交, or when preparing to run git add/commit.
阿里云 CLI (aliyun) 安装配置、ECS 管理、OSS 操作、安全组、DNS、SLB 常用命令
| name | spec-management |
| description | 生成或审计模块的 SPEC.md。使用场景：用户要求"给 XX 模块写 spec"、"审计所有 spec"、"检查 spec 是否过期"。 |
按需为模块生成 SPEC.md，或审计已有 spec 与代码的一致性。
electron/services/agent/SPEC.md 了解格式和详细度基准。# <模块名> SPEC
> Last verified: <今天日期>
## 职责
<1-2 句话描述模块做什么>
## 设计目标
<!-- 最重要：来自与用户讨论并确认的思路，不是从代码反推 -->
- **要解决的问题** / **成功标准**
- **关键取舍**（选了什么、放弃了什么、为什么）
- **明确不做**（本期边界）
## 行为契约 / 关键约束
<对外可见行为、不变量、边界条件>
## 文件结构（多文件模块才需要）
<文件列表 + 一句话说明>
## 公开 API
<!-- 实现索引，可随代码更新；不得覆盖「设计目标」 -->
<方法/函数表格：名称 | 用途 | 关键参数>
## 依赖
<该模块依赖的其他服务/模块>
遵循原则：
types.ts"引用，不要抄一遍放置位置：
agent/）→ 放在目录下 SPEC.mdai.service.ts）→ 放在同级目录，命名为 <SERVICE>_SPEC.md（如 AISERVICE_SPEC.md）find electron/services -name '*SPEC.md'| Spec 文件 | 状态 | 问题 |
|---|---|---|
| agent/SPEC.md | ✅ 同步 | - |
| AISERVICE_SPEC.md | ⚠️ 过期 | 新增了 chatWithVision 方法未记录 |
| foo/SPEC.md | ⚠️ 不合格 | 仅有 API 表，无用户确认的设计目标 |
| config.service.ts | ❌ 缺失 | 无 SPEC.md |