القائمة
生成或审计模块的 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 |