sdd-skills 1.1.1 → 1.1.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "sdd-skills",
-  "version": "1.1.1",
+  "version": "1.1.2",
   "description": "Spec-Driven Development Skills for Claude Code - SAE/ADE workflow automation",
   "type": "module",
   "main": "install.js",

package/skills/sae/SKILL.md

@@ -30,104 +30,156 @@ description: 软件架构工程师，负责需求分析、架构设计和技术
 - 当存在多个可行方案时，提供对比分析
 - 考虑团队技术栈熟悉度
 
-### 4. 编写需求规格文档
+### 4. 编写 Spec 文档
 
-需求规格文档应保存在 `specs/requirements/[feature-name].md`，包含以下结构：
+每个功能需求应拆分为小的 Spec 文档，保存在 `openspec/changes/[change-id]/specs/[capability]/spec.md`。
+
+**重要原则**：
+- 每个 Spec 应聚焦一个小需求，保持简洁
+- DESIGN 部分不要过于复杂，能让前后端及 AI 正确理解意图即可
+- 避免歧义，使用明确的描述和示例
+
+#### Spec 文档格式
+
+```markdown
+# [Capability Name]
+
+## DESCRIPTION
+
+### 需求背景
+[1-2 句话说明为什么需要这个功能]
+
+### 目标
+- [具体目标 1]
+- [具体目标 2]
+
+### 验收标准
+- [ ] 标准 1：具体可验证的条件
+- [ ] 标准 2：具体可验证的条件
+
+## DESIGN
+
+### 前后端分工
+
+**后端职责**：
+- [具体职责 1]
+- [具体职责 2]
+
+**前端职责**：
+- [具体职责 1]
+- [具体职责 2]
+
+### 接口设计
+
+```
+[HTTP Method] /api/v1/[resource]
+Request:
+{
+  "field1": "类型和说明",
+  "field2": "类型和说明"
+}
+Response:
+{
+  "field1": "类型和说明"
+}
+```
+
+### 数据模型（如有）
+
+| 字段名 | 类型 | 说明 |
+|--------|------|------|
+| field1 | string | 说明 |
+
+### 核心逻辑
+
+[用简洁的步骤描述实现逻辑，避免歧义]
+
+1. 步骤 1：具体操作
+2. 步骤 2：具体操作
+3. 步骤 3：具体操作
+
+### 边界情况
+
+- 情况 1：如何处理
+- 情况 2：如何处理
+```
+
+#### 示例：用户登录 Spec
 
 ```markdown
-# [功能名称] 需求规格
+# User Login
+
+## DESCRIPTION
+
+### 需求背景
+用户需要通过账号密码登录系统以访问受保护的资源。
 
-## 1. 需求概述
-- **业务背景**: 为什么需要这个功能
-- **目标用户**: 谁会使用这个功能
-- **核心价值**: 解决什么问题，带来什么价值
+### 目标
+- 支持邮箱+密码登录
+- 返回 JWT Token 用于后续认证
+- 登录失败时返回明确错误信息
 
-## 2. 功能需求
+### 验收标准
+- [ ] 正确的邮箱和密码可以成功登录并获取 Token
+- [ ] 错误的密码返回 401 和提示信息
+- [ ] 不存在的邮箱返回 401（不透露邮箱是否存在）
+- [ ] Token 有效期为 24 小时
 
-### 2.1 功能列表
-- [ ] 功能点 1：具体描述
-- [ ] 功能点 2：具体描述
-- [ ] 功能点 3：具体描述
+## DESIGN
 
-### 2.2 用户故事
-- 作为 [角色]，我想要 [功能]，以便 [价值]
-- 作为 [角色]，我想要 [功能]，以便 [价值]
+### 前后端分工
 
-## 3. 技术方案
+**后端职责**：
+- 实现 `/api/v1/auth/login` 接口
+- 验证用户凭证
+- 生成 JWT Token
 
-### 3.1 系统架构
-- **前后端分工**:
-  - 后端职责：API 提供、业务逻辑、数据持久化
-  - 前端职责：用户界面、交互逻辑、状态管理
-- **模块划分**: 列出主要模块及其职责
+**前端职责**：
+- 登录表单页面
+- 调用登录接口
+- 存储 Token 到 localStorage
 
-### 3.2 技术选型
-| 技术点 | 选择方案 | 选择理由 |
-|--------|----------|----------|
-| 后端框架 | Gin / Echo | 高性能、团队熟悉 |
-| 前端框架 | Vue 3 | Composition API、生态成熟 |
-| 数据库 | PostgreSQL / MySQL | 根据数据特点选择 |
-| 缓存 | Redis | 高性能键值存储 |
+### 接口设计
 
-### 3.3 接口设计（前后端契约）
 ```
-POST /api/v1/[resource]
-GET  /api/v1/[resource]/{id}
-PUT  /api/v1/[resource]/{id}
-DELETE /api/v1/[resource]/{id}
+POST /api/v1/auth/login
+Request:
+{
+  "email": "string, 必填, 邮箱格式",
+  "password": "string, 必填, 6-32位"
+}
+Response (200):
+{
+  "token": "string, JWT Token",
+  "expires_at": "int64, Unix 时间戳"
+}
+Response (401):
+{
+  "error": "string, 错误信息"
+}
 ```
 
-### 3.4 数据模型
-- 数据库表结构设计
-- 关键字段说明
-- 索引设计
-- 数据关系
-
-### 3.5 核心流程
-使用 Mermaid 图或文字描述关键业务流程
-
-## 4. 非功能需求
-- **性能要求**: 响应时间 < 200ms (P95)
-- **安全要求**: 认证授权机制、数据加密
-- **可用性**: 目标可用性（如 99.9%）
-- **扩展性**: 预期用户规模和增长
-
-## 5. 验收标准
-- [ ] 标准 1：用户可以成功完成核心操作
-- [ ] 标准 2：错误情况下有友好提示
-- [ ] 标准 3：性能满足要求
-- [ ] 标准 4：通过安全测试
-
-## 6. 实施计划
-
-### 6.1 关键文件
-**后端需要修改/新建的文件：**
-- `backend/api/[resource]_handler.go`
-- `backend/service/[resource]_service.go`
-- `backend/repository/[resource]_repository.go`
-- `backend/model/[resource].go`
-
-**前端需要修改/新建的文件：**
-- `frontend/src/views/[Feature]View.vue`
-- `frontend/src/components/[Feature]Component.vue`
-- `frontend/src/stores/[resource]Store.ts`
-- `frontend/src/api/[resource].ts`
-
-### 6.2 技术风险
-| 风险 | 影响 | 缓解措施 |
-|------|------|----------|
-| 风险 1 | 中/高 | 具体措施 |
-
-## 7. 测试策略
-- **单元测试**: 后端覆盖率 >= 90%，前端 >= 90%
-- **集成测试**: API 接口测试
-- **E2E 测试**: 关键用户流程
+### 核心逻辑
+
+1. 校验请求参数格式
+2. 根据 email 查询用户
+3. 比对密码哈希（bcrypt）
+4. 生成 JWT Token（包含 user_id, 过期时间）
+5. 返回 Token
+
+### 边界情况
+
+- 邮箱格式错误：返回 400，提示格式不正确
+- 密码长度不符：返回 400，提示长度要求
+- 账号被锁定：返回 403，提示联系管理员
 ```
 
 ## 输出工件
 
 完成需求分析后，应生成：
-- **需求规格文档**: `specs/requirements/[feature-name].md`
+- **Spec 文档**: `openspec/changes/[change-id]/specs/[capability]/spec.md`（包含 DESCRIPTION 和 DESIGN）
+- **Proposal 文档**: `openspec/changes/[change-id]/proposal.md`（变更说明）
+- **Tasks 文档**: `openspec/changes/[change-id]/tasks.md`（实施任务清单）
 - **明确的待办事项**: 下一步交给 Backend Engineer 和 Frontend Engineer
 
 ## 决策原则
@@ -212,12 +264,14 @@ DELETE /api/v1/[resource]/{id}
 
 明白了。我将设计一个基于 JWT 的认证系统...
 
-已生成需求规格：specs/requirements/user-login.md
+已生成以下文件：
+- Spec 文档: openspec/changes/add-user-login/specs/auth/spec.md
+- Proposal: openspec/changes/add-user-login/proposal.md
+- Tasks: openspec/changes/add-user-login/tasks.md
 
-主要包含：
-- 后端：JWT 认证 API (Gin框架)
-- 前端：登录表单组件 (Vue 3)
-- 验收标准：10 个测试场景
+Spec 概要：
+- DESCRIPTION: 邮箱+密码登录，JWT 认证，24小时有效期
+- DESIGN: 后端 Gin API，前端 Vue 登录表单，bcrypt 密码验证
 
-下一步请 Backend Engineer 和 Frontend Engineer 分别生成 OpenSpec。
+下一步请 Backend Engineer 和 Frontend Engineer 分别实现各自部分。
 ```