@pigcloud/skills 1.0.3 → 1.0.5

package/skills/references/requirements-separation-map.md

@@ -1,71 +0,0 @@
-# 需求拆分图
-
-## 目标
-
-把需求工作拆成两个互相隔离的 skill：
-
-- 产品侧需求发现
-- 研发侧需求分析
-
-## 产品侧
-
-当任务主要涉及这些内容时，使用 `product-intake`：
-
-- 业务目标
-- 用户需求
-- PRD 收口
-- 范围和优先级
-- 发布规划
-- 会议纪要和需求讨论
-- 当前项目事实的整理
-
-### 产品输出
-
-- 业务目标
-- 用户场景
-- 需求列表
-- 范围和非范围
-- 验收标准
-- 优先级
-- 当前项目事实
-- 给研发的待确认项
-
-### 产品停规则
-
-- 不写实现细节。
-- 不判断框架约束。
-- 不把结果直接写成面向代码的规格。
-- 不把当前项目事实和产品意图混成一句话。
-
-## 研发侧
-
-当任务主要涉及这些内容时，使用 `spec-refinement`：
-
-- 把已确认的产品需求转成可执行规格
-- 细化实现范围
-- 补齐验收缺口
-- 分析影响范围
-- 在设计或实现前准备研发输入
-- 对齐产品需求和当前项目事实
-
-### 研发输出
-
-- 可执行需求规格
-- 验收标准
-- 影响范围
-- 对齐说明
-- 任务计划
-- 实现输入摘要
-
-### 研发停规则
-
-- 不把 PRD 从头重写一遍。
-- 不直接进入代码生成。
-- 不跳过边界检查或当前选定的 rules bundle。
-- 不忽略当前项目事实。
-- 不把任务计划丢给实现阶段临时补。
-
-## 知识交接
-
-- 产品产物和研发产物都沉淀到 `knowledge-capture`。
-- 产品事实和研发事实保持关联，但不要混写。

package/skills/references/slash-commands.md

@@ -1,34 +0,0 @@
-# Canonical Skill Entry Mapping
-
-This page maps older slash-command style entry points to canonical skill names.
-
-## Skill Mapping
-
-| Skill | Use |
-|---|---|
-| `workflow-router` | Stage routing and handoff |
-| `product-intake` | Product intent capture |
-| `spec-refinement` | PRD, facts, and knowledge alignment into executable spec |
-| `technical-design` | Boundaries, dependencies, and interfaces |
-| `feature-build` | Implementation and task-level self-test |
-| `test-design` | Test strategy and regression coverage |
-| `code-review` | Generic code review findings |
-| `security-review` | Security findings only |
-| `performance-check` | Performance findings only |
-| `knowledge-capture` | Decision and artifact capture |
-| `domain-modeling` | Boundary extraction and domain terms |
-| `api-docs` | API contract capture |
-
-## Common Chains
-
-```text
-workflow-router -> product-intake -> spec-refinement -> technical-design -> feature-build -> test-design -> code-review -> knowledge-capture
-product-intake -> spec-refinement
-feature-build -> test-design -> code-review -> knowledge-capture
-```
-
-## Notes
-
-- Canonical skill names take precedence over old slash-command names.
-- Keep framework rules in `rules/`.
-- Keep skill bodies short and stable.

package/skills/spec-refinement/references/ears-syntax.md

@@ -1,127 +0,0 @@
-# EARS 语法参考（Easy Approach to Requirements Syntax）
-
-> 消除需求歧义的结构化语法，参考 AWS Kiro 的 Spec 工作流
-
-## 核心句式
-
-### 1. 用户故事（User Story）
-As a [角色], I want [功能], so that [价值]
-
-**示例**:
-- As a 普通用户, I want 查看我的订单列表, so that 我可以追踪订单状态
-- As a 管理员, I want 审核退款申请, so that 我可以控制退款风险
-
-### 2. 验收标准（Acceptance Criteria）
-WHEN [事件/条件] THEN the system SHALL [响应/行为]
-
-**示例**:
-- WHEN 用户点击"提交订单" THEN the system SHALL 创建订单并返回订单号
-- WHEN 订单金额 <= 0 THEN the system SHALL 拒绝创建并提示"订单金额必须大于0"
-- WHEN 用户未登录 THEN the system SHALL 返回 401 NotLoginException
-
-### 3. 业务规则（Business Rule）
-IF [条件] THEN [动作/约束]
-
-**示例**:
-- IF 订单状态 != CREATED THEN 抛出 BusinessException("订单状态不正确")
-- IF 用户余额 < 订单金额 THEN 拒绝支付并提示余额不足
-
-### 4. 不变式（Invariant）
-ALWAYS [约束] / NEVER [动作]
-
-**示例**:
-- ALWAYS 订单号全局唯一
-- NEVER 在事务中执行远程调用
-- ALWAYS 敏感数据脱敏后返回
-
-## 语法模式识别
-
-从自然语言中识别 EARS 模式：
-
-| 自然语言模式 | EARS 句式 | 提取方法 |
-|-------------|----------|---------|
-| "用户可以..." | User Story | 识别角色 + 功能 |
-| "当...时，系统应该..." | Acceptance Criteria | 识别事件 + 响应 |
-| "如果...则..." | Business Rule | 识别条件 + 动作 |
-| "必须..." / "不能..." | Invariant | 识别约束 |
-| "只有...才能..." | Business Rule | 识别前置条件 |
-| "...之后自动..." | Acceptance Criteria | 识别触发事件 + 自动动作 |
-
-## 模糊关键词检测
-
-以下关键词表示需求可能不明确，需要追问：
-
-| 模糊词 | 风险 | 追问方向 |
-|--------|------|---------|
-| 大概/可能/也许 | 不确定性 | 具体条件是什么？ |
-| 合适的/适当的 | 主观判断 | 什么标准算"合适"？ |
-| 尽量/尽可能 | 非强制 | 是 Must 还是 Should？ |
-| 快速/高效 | 无量化 | 具体响应时间要求？ |
-| 大量/很多 | 无量化 | 预估数据量级？ |
-| 方便/好用 | 主观体验 | 具体交互方式？ |
-| 安全的 | 无具体措施 | 具体安全要求？ |
-| 有时候/偶尔 | 不确定性 | 触发条件是什么？ |
-| 等一下/稍后 | 时序不明确 | 具体时间要求？ |
-| 相关的/类似的 | 范围模糊 | 具体包含哪些？ |
-
-## INVEST 原则
-
-评估用户故事质量：
-
-| 原则 | 含义 | 检查方法 |
-|------|------|---------|
-| Independent | 独立的，不依赖其他故事 | 是否可单独交付？ |
-| Negotiable | 可协商的，细节可讨论 | 是否留有讨论空间？ |
-| Valuable | 有价值的，对用户有意义 | 用户是否在乎？ |
-| Estimable | 可估算的，复杂度可评估 | 是否能估算工作量？ |
-| Small | 足够小，一个迭代可完成 | 是否需要拆分？ |
-| Testable | 可测试的，有验收标准 | 是否有明确的通过/失败判定？ |
-
-## MoSCoW 优先级
-
-| 优先级 | 含义 | 判定标准 |
-|--------|------|---------|
-| **Must** | 必须有 | 核心功能，没有则系统不可用 |
-| **Should** | 应该有 | 重要功能，本次迭代尽量实现 |
-| **Could** | 可以有 | 锦上添花，资源允许时实现 |
-| **Won't** | 不会有 | 本次不实现，记录备查 |
-
-## 需求 ID 编码规范
-
-格式: REQ-{模块缩写}-{序号}
-
-示例:
-- REQ-ORD-001: 订单创建
-- REQ-ORD-002: 订单支付
-- REQ-ORD-003: 订单取消
-- REQ-USR-001: 用户注册
-- REQ-USR-002: 用户登录
-
-## 正反示例对比
-
-### 用户故事
-<good-example>
-As a 普通用户, I want 通过手机号+验证码登录, so that 我无需记住密码即可快速访问
-</good-example>
-
-<bad-example>
-用户要能登录系统
-</bad-example>
-
-### 验收标准
-<good-example>
-WHEN 用户输入正确手机号和验证码 THEN the system SHALL 返回 JWT Token 和用户信息，响应时间 < 500ms
-</good-example>
-
-<bad-example>
-登录成功后返回 Token
-</bad-example>
-
-### 业务规则
-<good-example>
-IF 验证码已过期（超过5分钟）THEN the system SHALL 抛出 ParameterIllegalException("验证码已过期，请重新获取") 【服务端强制】
-</good-example>
-
-<bad-example>
-验证码不能过期
-</bad-example>

package/skills/spec-refinement/references/requirement-checklist.md

@@ -1,139 +0,0 @@
-# 需求分析检查清单
-
-> 基于 FURPS+ 模型和 EARS 语法的完整需求分析检查项
-
-## 一、需求收集检查
-
-### 1.1 业务背景（Why）
-| 检查项 | 通过标准 | 常见问题 |
-|--------|---------|---------|
-| 业务目标明确 | 能用一句话描述功能目标 | "做一个管理系统" |
-| 业务价值清晰 | 能说明解决了什么问题 | "领导要求的" |
-| 业务背景完整 | 能说明触发原因 | 无背景说明 |
-
-### 1.2 用户角色（Who）
-| 检查项 | 通过标准 | 常见问题 |
-|--------|---------|---------|
-| 角色定义完整 | 所有操作者角色已列出 | 遗漏旁观者/审核者 |
-| 权限矩阵清晰 | 每个角色能做什么已定义 | "管理员可以操作" |
-| 角色关系明确 | 角色之间的关系已定义 | 无角色层级说明 |
-
-### 1.3 业务流程（How）
-| 检查项 | 通过标准 | 常见问题 |
-|--------|---------|---------|
-| 主流程完整 | 正常执行步骤无遗漏 | 跳过中间步骤 |
-| 异常流程覆盖 | 主要异常场景已列出 | "异常以后处理" |
-| 边界条件识别 | 边界值已识别 | 无边界分析 |
-| 分支流程定义 | 条件分支已定义 | "看情况" |
-
-### 1.4 数据范围（What）
-| 检查项 | 通过标准 | 常见问题 |
-|--------|---------|---------|
-| In Scope 明确 | 功能范围内的事项已列出 | 范围模糊 |
-| Out Scope 明确 | 明确不做什么 | 无 Out Scope |
-| 数据实体识别 | 涉及的数据实体已列出 | 遗漏关联实体 |
-| 数据量评估 | 预估数据量级 | 无数据量评估 |
-
-### 1.5 约束条件（Constraints）
-| 检查项 | 通过标准 | 常见问题 |
-|--------|---------|---------|
-| 性能要求 | 响应时间/并发量已明确 | "要快" |
-| 安全要求 | 认证/授权/脱敏已明确 | "要安全" |
-| 兼容性要求 | 浏览器/版本/接口兼容已明确 | 无兼容性说明 |
-| 技术约束 | 技术栈/框架限制已明确 | 无技术约束 |
-
-## 二、需求结构化检查（EARS 语法）
-
-### 2.1 用户故事
-| 检查项 | 通过标准 | 错误示例 | 正确示例 |
-|--------|---------|---------|---------|
-| 角色明确 | As a [具体角色] | As a user | As a 普通用户 |
-| 功能明确 | I want [具体功能] | I want 管理 | I want 创建、编辑、删除订单 |
-| 价值明确 | so that [具体价值] | so that 方便 | so that 可以追踪订单状态 |
-| INVEST 原则 | Independent/Negotiable/Valuable/Estimable/Small/Testable | - | - |
-
-### 2.2 验收标准
-| 检查项 | 通过标准 | 错误示例 | 正确示例 |
-|--------|---------|---------|---------|
-| WHEN 条件明确 | 触发事件清晰 | WHEN 用户操作 | WHEN 用户点击"提交订单"按钮 |
-| THEN 响应明确 | 系统响应可验证 | THEN 成功 | THEN 系统返回 Result<OrderVO>，订单状态变为 PAID |
-| 可验证性 | 有明确的通过/失败判定 | THEN 快速响应 | THEN 响应时间 < 500ms |
-| 边界覆盖 | 边界条件有验收标准 | - | WHEN 金额为 0.01 THEN ... |
-
-### 2.3 业务规则
-| 检查项 | 通过标准 | 错误示例 | 正确示例 |
-|--------|---------|---------|---------|
-| 条件清晰 | IF 条件明确 | IF 金额不对 | IF 订单金额 <= 0 |
-| 动作明确 | THEN 动作可执行 | THEN 报错 | THEN 抛出 ParameterIllegalException("订单金额必须大于0") |
-| 执行方标注 | 标注谁来保证 | 无标注 | 【服务端强制】/【调用方需预判】 |
-
-## 三、需求质量检查
-
-### 3.1 隐含假设
-| 检查项 | 检查方法 |
-|--------|---------|
-| 数据量假设 | "如果数据量增长 10 倍，这个需求还成立吗？" |
-| 并发假设 | "如果 100 个用户同时操作，会怎样？" |
-| 时序假设 | "如果操作顺序颠倒，会怎样？" |
-| 外部依赖假设 | "如果依赖的外部系统不可用，会怎样？" |
-| 权限假设 | "如果用户没有预期权限，会怎样？" |
-
-### 3.2 矛盾检测
-| 检查维度 | 检查方法 | 示例 |
-|---------|---------|------|
-| 权限矛盾 | A 要求开放 vs B 要求限制 | "所有接口公开" vs "需要管理员权限" |
-| 状态矛盾 | A 的流转 vs B 的流转 | "订单不可取消" vs "支持退款" |
-| 数据矛盾 | A 的唯一性 vs B 的重复 | "手机号唯一" vs "允许更换手机号" |
-| 时序矛盾 | A 实时 vs B 批量 | "实时通知" vs "每天汇总" |
-
-### 3.3 可测试性
-| 检查项 | 通过标准 | 不可测试示例 | 可测试示例 |
-|--------|---------|-------------|-----------|
-| 可验证 | 有明确通过/失败判定 | "系统应该快速响应" | "P99 响应时间 < 200ms" |
-| 可量化 | 有具体数值 | "支持大量数据" | "支持 10 万条记录分页查询" |
-| 可复现 | 测试步骤可重复 | "有时候会出错" | "当金额为负数时抛出异常" |
-
-## 四、需求完整性检查（FURPS+）
-
-| 维度 | 全称 | 检查项 | 通过标准 |
-|------|------|--------|---------|
-| F | Functionality | 功能完整性 | 每个功能点有输入/输出/规则 |
-| U | Usability | 可用性 | 用户角色和权限已定义 |
-| R | Reliability | 可靠性 | 异常处理策略已定义 |
-| P | Performance | 性能 | 响应时间/并发量已明确 |
-| S | Supportability | 可支持性 | 日志/监控/缓存策略已分析 |
-| + | 其他 | 安全/合规/兼容 | 安全要求/合规要求已明确 |
-
-## 五、迭代开发额外检查
-
-### 5.1 影响分析
-| 检查项 | 通过标准 |
-|--------|---------|
-| 模块依赖 | 受影响模块已识别 |
-| API 调用链 | Feign 调用影响已分析 |
-| 数据依赖 | 实体关联影响已分析 |
-| 状态流转 | 状态变更影响已分析 |
-| 回归风险 | 回归测试范围已评估 |
-
-### 5.2 风险评估
-| 风险等级 | 判定条件 | 处理方式 |
-|---------|---------|---------|
-| Critical | 涉及核心流程 + 跨服务调用 + 事务边界 | 必须有回滚方案 |
-| High | 涉及状态变更 + 权限变更 + 数据结构变更 | 需要回归测试 |
-| Medium | 涉及查询逻辑 + UI 字段调整 | 建议回归测试 |
-| Low | 涉及日志 + 注释 + 代码重构 | 常规测试 |
-
-## 六、Anti-rationalization Table (Requirement Analysis)
-
-| 常见借口 | 反驳理由 | 正确做法 |
-|---------|---------|---------|
-| "需求很清楚，不需要文档" | 清楚的需求也会变化 | 编写需求文档 |
-| "这个功能很简单" | 简单功能也有边界情况 | 完整需求分析 |
-| "用户会这样操作" | 用户操作方式多样 | 分析所有场景 |
-| "这个边界不会发生" | 边界情况总会发生 | 处理边界 |
-| "这个功能以后再加" | 以后加的成本更高 | 现在规划 |
-| "这个影响范围很小" | 小影响也会产生连锁反应 | 完整影响分析 |
-| "这个模块不依赖其他模块" | 模块间总有依赖 | 分析依赖 |
-| "先做再说，需求以后补" | 无文档的需求无法维护 | 先需求后实现 |
-| "用户说的就是需求" | 用户说的往往是解决方案而非需求 | 追问真实意图 |
-| "这个验收标准够了" | 不完整的验收标准导致返工 | 覆盖正常/异常/边界 |

package/skills/spec-refinement/references/spec-workbook.md

@@ -1,75 +0,0 @@
-# Requirement Spec Workbook
-
-> 闇€姹傚垎鏋愮殑鍙鐢ㄦā鏉夸笌妫€鏌ラ」銆俙SKILL.md` 鍙繚鐣欐祦绋嬶紝杩欓噷淇濈暀浜у嚭缁撴瀯鍜屽父鐢ㄦ槧灏勩€傞渶瑕佸叿浣撹鍒欐椂锛屼紭鍏堝紩鐢?[rules/index.md](/D:/work/java/pig-skills/rules/index.md) 鍜屽搴斿瓙瑙勫垯銆?
-## EARS Template
-
-```markdown
-### REQ-001: [闇€姹傛爣棰榏
-- **浼樺厛绾?*: Must | Should | Could | Won't
-- **鐢ㄦ埛鏁呬簨**: As a [role], I want [feature], so that [benefit]
-- **楠屾敹鏍囧噯**:
-  - WHEN [event] THEN the system SHALL [response]
-- **涓氬姟瑙勫垯**:
-  - IF [condition] THEN [action/constraint]
-- **涓嶅彉寮?*:
-  - ALWAYS [constraint]
-  - NEVER [action]
-```
-
-## Assumption Checklist
-
-| 鍋囪 ID | 鍏宠仈闇€姹?| 鍋囪鍐呭 | 椋庨櫓绛夌骇 | 楠岃瘉鏂瑰紡 |
-|---------|---------|---------|---------|---------|
-| ASM-001 | REQ-001 | 鐢ㄦ埛宸茬櫥褰曚笖鏈夋湁鏁堟敹璐у湴鍧€ | 楂?| 鍓嶇疆楠岃瘉 |
-| ASM-002 | REQ-003 | 鏀粯鎺ュ彛鍝嶅簲鏃堕棿 < 3s | 涓?| 鍘嬫祴楠岃瘉 |
-| ASM-003 | REQ-005 | 鍟嗗搧浠锋牸鍦ㄤ笅鍗曞悗涓嶅彉 | 楂?| 浠锋牸閿佸畾鏈哄埗 |
-
-## Conflict Report
-
-| 鍐茬獊 ID | 娑夊強闇€姹?| 鍐茬獊绫诲瀷 | 鎻忚堪 | 寤鸿鏂规 |
-|---------|---------|---------|------|---------|
-| CONFLICT-001 | REQ-002, REQ-004 | 鐘舵€佸啿绐?| 宸插彂璐ц鍗曠殑鍙栨秷绛栫暐鍐茬獊 | 缁熶竴涓轰笉鍙彇娑?/ 澧炲姞瀹℃牳鍙栨秷娴佺▼ |
-
-## Capability Map
-
-| 闇€姹?ID | 闇€姹傛弿杩?| 鑳藉姏鍒嗙被 | 妗嗘灦鏀寔鏂瑰紡 | 澶囨敞 |
-|---------|---------|---------|-------------|------|
-| REQ-001 | RESTful API 杩斿洖 | 鍘熺敓鏀寔 | Result<T> + @RestController | - |
-| REQ-003 | 鏁版嵁鏉冮檺闅旂 | 鍘熺敓鏀寔 | @IgnoreTenant + 澶氱鎴锋嫤鎴櫒 | - |
-| REQ-005 | PDF 瀵煎嚭 | 鍙墿灞曟敮鎸?| 鑷畾涔?Starter 鎴栨帴鍏?iText | 璇勪及宸ヤ綔閲?|
-| REQ-008 | 瀹炴椂娑堟伅鎺ㄩ€?| 涓嶆敮鎸?| 闇€寮曞叆 WebSocket/MQ | 璇勪及寮曞叆鎴愭湰 |
-
-## Output Template
-
-```markdown
-# {妯″潡鍚峿 闇€姹傛枃妗?
-
-## 1. 鍔熻兘姒傝堪
-## 2. 鍔熻兘鑼冨洿
-## 3. 缁撴瀯鍖栭渶姹傦紙EARS锛?
-## 4. 闅愬惈鍋囪
-## 5. 闇€姹傚啿绐佹鏌?
-## 6. 妗嗘灦鑳藉姏鏄犲皠
-## 7. 楠屾敹鏍囧噯锛圔DD锛?
-## 8. 闈炲姛鑳芥€ч渶姹?
-## 9. 瀹屾暣鎬ф鏌ユ姤鍛?
-## 10. 褰卞搷鍒嗘瀽锛堜粎杩唬妯″紡锛?
-## 11. 瀹炵幇闃舵杈撳叆鎽樿
-```
-
-## Iteration Impact Summary
-
-| 鍙樻洿椤?| 姒傜巼 | 褰卞搷 | 椋庨櫓绛夌骇 | 鍥炲綊绛栫暐 |
-|--------|------|------|---------|---------|
-| 璁㈠崟鐘舵€佹祦杞慨鏀?| 楂?| 楂?| Critical | 鍏ㄩ噺鍥炲綊 |
-| 鏂板瀹℃牳瀛楁 | 楂?| 涓?| High | 妯″潡鍥炲綊 |
-| API 鍝嶅簲鎵╁睍 | 涓?| 浣?| Low | 澧為噺娴嬭瘯 |
-
-## Anti-rationalization
-
-| 甯歌鍊熷彛 | 鍙嶉┏ |
-|---------|------|
-| 鈥滈渶姹傚凡缁忓緢娓呮浜嗭紝涓嶉渶瑕佸啀闂€?| 鍏堝仛涓€娆℃緞娓呭洖璺?|
-| 鈥滃厛鍋氳璁★紝闇€姹傚彲浠ヨ竟鍋氳竟瀹屽杽鈥?| 鍏堥渶姹傚悗璁捐 |
-| 鈥滃奖鍝嶅垎鏋愬お鑰楁椂浜嗏€?| 璺宠繃浼氭妸椋庨櫓甯﹀埌鍚庨潰 |
-