@specpow/framework 0.2.0

package/skills/planning-write-design/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: planning-write-design
+description: SpecPow planning-write-design skill
+---
+
+# 编写设计
+
+> 根据规范编写技术设计文档
+
+## 触发条件
+
+- specs 完成后需要编写设计
+- 用户提到"写设计"/"技术设计"/"design"
+
+## 铁律
+
+1. **ADR 先行** — 先确定架构决策
+2. **接口定义** — 明确模块间接口
+3. **前后端分离** — 明确职责边界
+
+## 设计文档结构
+
+```markdown
+# 技术设计: [变更标题]
+
+## 1. 架构决策 (ADR)
+### ADR-001: [决策标题]
+- 状态: 已决定
+- 背景: 为什么需要这个决策
+- 决策: 选择了什么方案
+- 理由: 为什么选这个
+- 影响: 这个决策带来什么
+
+## 2. 模块划分
+- 模块 A: 职责描述
+- 模块 B: 职责描述
+
+## 3. 接口定义
+### 3.1 API 接口
+| Method | Path | 描述 | 请求体 | 响应体 |
+|--------|------|------|--------|--------|
+
+### 3.2 内部接口
+- 模块间调用方式
+
+## 4. 数据模型
+- 新增/修改的表结构
+- ER 关系图
+
+## 5. 前后端分工
+| 功能 | 前端 | 后端 |
+|------|------|------|
+```
+
+## 红旗
+
+- 未确定架构决策 → 先讨论 ADR
+- 接口未定义 → 不能开始编码
+- 数据模型不清晰 → 先设计 DB

package/skills/planning-write-plans/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: planning-write-plans
+description: SpecPow planning-write-plans skill
+---
+
+# 编写计划
+
+> 根据设计文档编写任务计划（tasks.md）
+
+## 触发条件
+
+- design 完成后需要编写任务计划
+- 用户提到"写计划"/"任务拆分"/"tasks"
+
+## 铁律
+
+1. **原子任务** — 每个任务可独立执行和验证
+2. **依赖明确** — 标注任务间依赖关系
+3. **验证步骤** — 每个任务有明确的验证方式
+4. **文件路径** — 标注涉及的文件
+
+## 任务格式
+
+```markdown
+## 任务列表
+
+### 全局约束
+- 分支: feature/xxx
+- 基础: main 分支最新代码
+
+### Task-001: [任务标题]
+- 文件: `src/main/java/xxx/Entity.java`
+- 依赖: 无
+- 描述: 创建 XxxEntity 实体类
+- 验证: 编译通过
+
+### Task-002: [任务标题]
+- 文件: `src/main/java/xxx/Mapper.java`, `src/main/resources/mapper/XxxMapper.xml`
+- 依赖: Task-001
+- 描述: 创建数据访问层
+- 验证: 单元测试通过
+```
+
+## 拆分原则
+
+1. **按层拆分** — Entity → Mapper → Service → Controller
+2. **按功能拆分** — 每个 CRUD 操作一个任务
+3. **按文件拆分** — 每个文件一个任务（如果不太小）
+4. **工作量标记** — S(<0min) / M(30min-2h) / L(2h+)
+
+## 红旗
+
+- 任务过大(>4h) → 继续拆分
+- 无验证步骤 → 补充验证
+- 依赖关系不清 → 明确依赖

package/skills/planning-write-specs/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: planning-write-specs
+description: SpecPow planning-write-specs skill
+---
+
+# 编写规范
+
+> 根据提案编写 Delta 规范（spec.md）
+
+## 触发条件
+
+- proposal 完成后需要编写规范
+- 用户提到"写规范"/"spec"/"需求规范"
+
+## 铁律
+
+1. **Delta 格式** — 使用 ADDED/MODIFIED/REMOVED/RENAMED
+2. **验收标准** — 每个需求必须有 Given/When/Then
+3. **唯一 ID** — 每个需求有唯一标识
+
+## 规范格式
+
+```markdown
+# 规范: [变更标题]
+
+## ADDED Requirements
+
+### REQ-001: [需求标题]
+系统应当 [具体行为描述]。
+
+**验收标准:**
+- **Given** [前置条件]
+- **When** [触发动作]
+- **Then** [预期结果]
+
+### REQ-002: [需求标题]
+...
+
+## MODIFIED Requirements
+
+### REQ-010: [需求标题]
+变更描述: [修改了什么]
+原因: [为什么修改]
+
+**更新后的验收标准:**
+- **Given** ...
+- **When** ...
+- **Then** ...
+
+## REMOVED Requirements
+
+### REQ-020: [需求标题]
+移除原因: [为什么移除]
+影响: [移除后的影响]
+
+## RENAMED Requirements
+
+### REQ-030 → REQ-031: [旧名称 → 新名称]
+重命名原因: [为什么重命名]
+```
+
+## 编写原则
+
+1. **具体** — "系统应当在 3 秒内返回结果" 而非 "系统应当快速响应"
+2. **可测试** — 每个需求都能写出测试用例
+3. **无歧义** — 避免"可能"、"也许"等模糊词
+4. **独立** — 需求之间尽量不互相依赖
+
+## 红旗
+
+- 无验收标准 → 必须补充
+- 需求模糊 → 与用户确认
+- 需求冲突 → 解决冲突后再继续