@pigcloud/skills 1.0.10 → 1.1.2

package/skills/domain-modeling/references/distillation-checklist.md

@@ -1,44 +0,0 @@
-# 领域提炼检查清单
-
-> 用于检查领域建模提炼结果是否满足规范、是否可交接、是否可复用。
-
----
-
-## 目录结构
-
-- [ ] `distilled/` 目录已创建
-- [ ] `README.md` 已说明提炼目标
-- [ ] `00-overview.md` 已说明 AI 的关键约束
-- [ ] `01-glossary.md` 已收录术语
-- [ ] `domain/_index.md` 已建立索引
-- [ ] `domain/<name>.md` 每个核心域有独立文件
-- [ ] `api/_index.md` 已建立接口索引
-- [ ] `api/<group>/<name>.md` 每个接口组都有独立文件
-- [ ] `reference/schema/*.md` 字段级 Schema 已整理
-- [ ] `reference/enums.md` 枚举已整理
-
-## 内容检查
-
-- [ ] 领域边界已明确
-- [ ] 核心概念已抽取
-- [ ] 术语表与代码命名一致
-- [ ] 当前事实与推断已区分
-- [ ] 关键不变量已记录
-
-## 证据检查
-
-- [ ] 每个结论都有代码、文档或会议纪要支撑
-- [ ] 关键例子可追溯到原始来源
-- [ ] 没有把猜测写成事实
-
-## 交接检查
-
-- [ ] 输出可以交给 `spec-refinement`
-- [ ] 输出可以交给 `technical-design`
-- [ ] 输出可以交给 `knowledge-capture`
-- [ ] 文件命名遵守 kebab-case
-
-## 备注
-
-- 如果某个目录暂时没有内容，也要在索引里明确说明。
-- 如果有未确认项，单独列在“待确认”区域，不要隐藏。

package/skills/domain-modeling/references/test-cases-template.md

@@ -1,128 +0,0 @@
-# 实跑验证测试集模板
-
-> 用于 S6 验证阶段的测试集准备
-
----
-
-## 测试集四类场景
-
-### 1. 读/查询场景
-
-| 测试ID | 用户输入 | 预期行为 | 验证点 |
-|--------|----------|----------|--------|
-| R01 | "查 X 部门今年的合同" | 调用 query-contracts 接口 | 名称→ID 解析、查询参数 |
-| R02 | "查看合同 C001 的详情" | 调用 get-contract-detail 接口 | ID 定位、详情字段解读 |
-| R03 | "列出所有待开票的合同" | 调用 query-open-invoices 接口 | 状态过滤、列表解读 |
-| R04 | "查客户 A 的所有合同" | 调用 query-contracts 接口 | 客户 ID 解析、过滤参数 |
-
----
-
-### 2. 写/录入场景
-
-| 测试ID | 用户输入 | 预期行为 | 验证点 |
-|--------|----------|----------|--------|
-| W01 | "给客户 A 录个合同，48 万，税率 13%" | 调用 create-contract 接口 | ID 解析、必填字段、回显确认 |
-| W02 | "给合同 C001 开票，阶段 1，金额 14.4 万" | 调用 create-invoice 接口 | 合同详情获取、可开票额计算 |
-| W03 | "确认发票 I001 已收款" | 调用 receive-payment 接口 | 发票状态检查、收款确认 |
-| W04 | "作废合同 C001" | 调用 void-contract 接口（如有） | 状态检查、权限确认 |
-
----
-
-### 3. 统计场景
-
-| 测试ID | 用户输入 | 预期行为 | 验证点 |
-|--------|----------|----------|--------|
-| S01 | "未来三个月各部门预计收多少" | 调用 receipt-budget 接口 | 统计口径理解、参数构造 |
-| S02 | "今年已开票总额是多少" | 调用统计接口 | 时间范围、聚合口径 |
-| S03 | "各部门合同数量分布" | 调用统计接口 | 分组维度、结果解读 |
-| S04 | "客户 A 的收款进度" | 调用 get-contract-detail 接口 | 累计收款计算、进度解读 |
-
----
-
-### 4. 规则反例场景
-
-| 测试ID | 用户输入 | 预期错误 | 验证点 |
-|--------|----------|----------|--------|
-| E01 | "付款比例：预付 20% + 验收 30%" | "付款比例合计必须等于 1" | 规则预判、错误解释 |
-| E02 | "给已收款的发票再次确认收款" | "发票已收款，不可重复确认" | 状态检查、错误解释 |
-| E03 | "开票金额超过合同总额" | "开票金额超过剩余可开票额" | 额度计算、错误解释 |
-| E04 | "使用不存在的客户 ID" | "客户不存在" | ID 验证、错误解释 |
-
----
-
-## 测试执行记录模板
-
-### 测试 R01
-
-| 字段 | 内容 |
-|------|------|
-| 测试ID | R01 |
-| 用户输入 | "查华东部门今年的合同" |
-| AI 推导 | 1. 调用 reference-data 解析"华东部门" → deptId=xxx<br>2. 调用 query-contracts(deptId=xxx, year=2026) |
-| 实际调用 | |
-| 返回结果 | |
-| 验证点 | 名称→ID 解析：✅/❌<br>查询参数：✅/❌ |
-| 结论 | 通过/失败 |
-| 备注 | |
-
----
-
-### 测试 W01
-
-| 字段 | 内容 |
-|------|------|
-| 测试ID | W01 |
-| 用户输入 | "给星河制造录个合同，集成交付服务，销售二部李强负责，48 万，税率 13%，分预付 30%/验收 40%/尾款 30%" |
-| AI 推导 | 1. 调用 reference-data 解析客户/产品/部门/负责人<br>2. 回显解析结果<br>3. 用户确认<br>4. 调用 create-contract |
-| 实际调用 | |
-| 返回结果 | |
-| 验证点 | ID 解析：✅/❌<br>必填字段：✅/❌<br>回显确认：✅/❌<br>服务端维护字段未传入：✅/❌ |
-| 结论 | 通过/失败 |
-| 备注 | |
-
----
-
-### 测试 E01
-
-| 字段 | 内容 |
-|------|------|
-| 测试ID | E01 |
-| 用户输入 | "付款比例：预付 20% + 验收 30%" |
-| AI 推导 | AI 应预判比例合计=0.5≠1，提示用户调整 |
-| 实际行为 | |
-| 返回结果 | |
-| 验证点 | 规则预判：✅/❌<br>错误解释：✅/❌ |
-| 结论 | 通过/失败 |
-| 备注 | |
-
----
-
-## 验证汇总
-
-| 类型 | 测试数 | 通过数 | 通过率 |
-|------|--------|--------|--------|
-| 读/查询 | 4 | | |
-| 写/录入 | 4 | | |
-| 统计 | 4 | | |
-| 规则反例 | 4 | | |
-| **总计** | **16** | | |
-
-**判定标准**：
-- 通过率 >= 90% → 文档可用性通过
-- 通过率 < 90% → 需迭代修复
-
----
-
-## 发现的文档缺口
-
-| 缺口 | 影响测试 | 修复方案 |
-|------|----------|----------|
-| | | |
-
----
-
-## 迭代修复记录
-
-| 日期 | 修复内容 | 重新验证结果 |
-|------|----------|----------|
-| | | |

package/skills/environment-deploy/SKILL.md

@@ -1,81 +0,0 @@
----
-name: environment-deploy
-description: 当工作区或目标环境需要配置时，准备部署和运行时前置条件
-lifecycle_stage: scaffold
-rule_profile: scaffold
-dependencies:
-  - project-bootstrap
-triggers:
-  - deploy
-  - environment
-  - runtime
-  - install
-  - bootstrap
-  - setup
-inputs:
-  - deployment target
-  - runtime requirements
-  - workspace state
-outputs:
-  - environment plan
-  - deployment notes
-  - bootstrap instructions
-workflow:
-  - verify the target environment
-  - prepare runtime and deployment prerequisites
-  - document the setup steps
-  - hand off to feature-build or project-bootstrap
-gates:
-  - stop at environment setup
-  - do not change product scope
-  - do not generate business logic
-refs:
-  - skills/references/rule-loading-map.md
-  - skills/references/prompt-replay-checklist.md
-  - skills/references/full-chain-replay-scenarios.md
-  - rules/index.md
----
-
-# Environment Deploy
-
-## Purpose
-
-Prepare deployment and runtime environments without changing application scope.
-
-## Suitable / Unsuitable
-
-- Suitable: runtime setup, deployment prerequisites, bootstrap instructions
-- Unsuitable: product discovery, architecture changes, implementation work
-
-## Workflow
-
-1. Verify the target environment.
-2. Prepare runtime and deployment prerequisites.
-3. Document the setup steps.
-4. Hand off to `feature-build` or `project-bootstrap`.
-
-## Replay Signals
-
-- Input signal: deployment target, runtime requirements, workspace state.
-- Output to verify: environment plan, deployment notes, bootstrap instructions.
-- Stop signal: product scope changes or business logic generation.
-- Handoff signal: the environment is ready for `feature-build` or `project-bootstrap`.
-
-## Examples
-
-- Input: "Prepare the runtime and deployment prerequisites for this workspace."
-- Output: environment plan, deployment notes, bootstrap instructions
-- Stop: do not change product scope or generate business logic
-
-## Stop Rules
-
-- Stop at environment setup.
-- Do not change product scope.
-- Do not generate business logic.
-
-## References
-
-- `skills/references/rule-loading-map.md`
-- `skills/references/prompt-replay-checklist.md`
-- `skills/references/full-chain-replay-scenarios.md`
-- `rules/index.md`

package/skills/feature-build/SKILL.md

@@ -1,122 +0,0 @@
----
-name: feature-build
-description: 在代码、重构或集成工作需要保持在既定边界内时，实现已批准的设计变更
-rule_profile: implementation
-dependencies:
-  - technical-design
-triggers:
-  - coding
-  - implementation
-  - refactor
-  - entity
-  - controller
-  - service
-  - mapper
-inputs:
-  - executable spec-refinement
-  - design decisions
-  - confirmed task breakdown plan
-  - rules bundle
-outputs:
-  - code changes
-  - implementation notes
-  - validation evidence
-  - self-test evidence
-workflow:
-  - load the selected rules bundle
-  - confirm the task breakdown plan before coding
-  - implement one task at a time within the approved scope
-  - run local self-tests after each completed task
-  - record evidence for each finished task
-  - validate compile-time and local correctness
-  - hand off to test-design
-gates:
-  - stop at implementation
-  - do not rewrite the spec-refinement
-  - do not change the agreed boundaries
-  - do not bypass the rules bundle
-refs:
-  - skills/references/rule-loading-map.md
-  - skills/references/flow-test-cases.md
-  - skills/references/full-chain-replay-scenarios.md
-  - skills/references/prompt-replay-checklist.md
-  - rules/index.md
----
-
-# Feature Build
-
-## Purpose
-
-Implement the approved design without changing the agreed scope.
-
-## Suitable / Unsuitable
-
-- Suitable: entity, mapper, service, controller, refactor, local validation, task-level implementation
-- Unsuitable: redesigning requirements, changing boundaries, bypassing rules, writing unrelated tests
-
-## Quick Start
-
-- Load the selected rules bundle first.
-- Implement only the confirmed scope from the approved design.
-- Split work into small tasks before implementation if the spec-refinement is still too coarse.
-- Treat the task as the smallest implementation unit.
-- Validate each task locally before starting the next one.
-- Record evidence immediately after each task is complete.
-- Validate compile-time and local correctness before handing off.
-
-## Inputs / Outputs
-
-- Inputs:
-  - executable spec-refinement
-  - design decisions
-  - confirmed task breakdown plan
-  - rules bundle
-- Outputs:
-  - code changes
-  - implementation notes
-  - validation evidence
-  - self-test evidence
-  - task-level evidence
-
-## Workflow
-
-1. Load the selected rules bundle.
-2. Confirm the task breakdown plan and smallest executable units.
-3. Implement one task at a time within the approved scope.
-4. Run local self-tests after each task and record the evidence.
-5. Validate compile-time and local correctness.
-6. Hand off to `test-design`.
-
-## Replay Signals
-
-- Input signal: confirmed spec-refinement, approved design, confirmed task breakdown plan, and selected rules bundle.
-- Output to verify: code changes, implementation notes, validation evidence, self-test evidence, task-level evidence.
-- Stop signal: spec-refinement rewrites, scope expansion, or bypassing the rules bundle.
-- Handoff signal: implementation is ready for `test-design`.
-
-## Gotchas
-
-- Do not rewrite the spec-refinement while implementing.
-- Do not expand the boundary because implementation is inconvenient.
-- Do not bypass the rules bundle for convenience.
-- Do not leave validation evidence implicit.
-- Do not batch unrelated tasks into a single implementation step.
-- Do not postpone self-test until the end of the whole change.
-- Do not lose task-level evidence.
-
-## Stop Rules
-
-- Stop at implementation.
-- Do not rewrite the spec-refinement.
-- Do not change the agreed boundaries.
-- Do not skip the rules bundle.
-- Do not bypass the rules bundle.
-
-## References
-
-- `skills/references/rule-loading-map.md`
-- `skills/references/flow-test-cases.md`
-- `skills/references/engineering-delivery-method.md`
-- `skills/references/engineering-delivery-template.md`
-- `rules/index.md`
-

package/skills/feature-build/references/coding-checklist.md

@@ -1,97 +0,0 @@
-# 编码检查清单
-
-> 以规则层为主，保留可执行检查，不重复展开规则正文。默认基线见 [rules/overlays/pig-cloud.md](/D:/work/java/pig-skills/rules/overlays/pig-cloud.md)。
-
----
-
-## Entity Layer
-
-- 基类继承是否符合 [rules/overlays/pig-cloud/entity.md](/D:/work/java/pig-skills/rules/overlays/pig-cloud/entity.md)
-- 主键策略是否符合项目约定
-- 状态字段是否使用约定枚举编码
-- 表名是否显式且稳定
-
----
-
-## DTO Layer
-
-- CreateDTO 是否具备必要校验
-- UpdateDTO 是否包含 id
-- VO 是否做好脱敏和输出边界控制
-- DTO / VO / Entity 是否严格分离
-
----
-
-## Mapper Layer
-
-- 是否只负责数据访问
-- 是否保持 lambda query / update 风格
-- 是否避免字符串列名和 `${}` 注入风险
-- 是否避免业务逻辑下沉到 Mapper
-
----
-
-## Service Layer
-
-- 是否通过 Service 统一组织业务编排
-- 是否在 Service 层管理事务边界
-- 是否避免事务内远程调用
-- 是否避免把接口层语义带入业务层
-
----
-
-## Controller Layer
-
-- 是否只负责接入、参数接收和结果返回
-- 是否通过 Service 调用业务逻辑
-- 是否符合 [rules/overlays/pig-cloud/validation.md](/D:/work/java/pig-skills/rules/overlays/pig-cloud/validation.md)
-- 是否避免直接访问 Mapper 和写事务
-
----
-
-## Comment Layer
-
-- 类注释是否一句话说明职责
-- 方法注释是否说明目的、输入、输出和异常
-- 复杂逻辑是否有必要的步骤说明
-- 外部调用和状态流转是否留下注释
-
----
-
-## Logging Layer
-
-- 外部调用是否记录接口名、参数和耗时
-- 业务事件是否记录关键上下文
-- 异常日志是否保留足够上下文
-- 敏感数据是否已脱敏
-
----
-
-## Shared Tools
-
-- String 是否使用统一工具
-- JSON 是否使用统一工具
-- Bean Copy 是否使用统一工具
-- DateTime 是否使用统一工具
-- Password 是否使用统一工具
-- Pagination 是否使用统一工具
-- Exception 是否使用统一异常类型
-
----
-
-## Anti-rationalization
-
-- 是否出现“临时方案”“以后再优化”“不会发生”的借口
-- 是否把边界问题推迟到未来处理
-- 是否把细节复杂度低估
-- 是否把覆盖率、性能、异常和安全问题合理化
-
----
-
-## Verification Gates
-
-- 编译是否通过
-- 每个任务的本地自测是否有证据
-- 规则检查是否通过
-- 分层检查是否通过
-- 安全检查是否通过

package/skills/feature-build/references/comment-specification.md

@@ -1,89 +0,0 @@
-# 注释规范
-
-> 代码注释标准，用于保持可读性和可维护性。这里只保留注释密度、模板和检查项；具体业务分层基线优先引用 `rules/overlays/pig-cloud.md` 及其子规则。
-
-## Class Comment
-
-### 必要内容
-
-| 内容 | 说明 |
-|------|------|
-| 类说明 | 一句话描述职责 |
-| 作者 | 创建者 |
-| 日期 | 创建日期 |
-| 版本 | 可选 |
-
-### 模板
-
-```java
-/**
- * 用户服务。
- *
- * <p>负责用户查询、创建与基础校验。</p>
- */
-```
-
-## Method Comment
-
-### 必要内容
-
-| 内容 | 说明 |
-|------|------|
-| 方法说明 | 方法做什么 |
-| 参数说明 | 每个参数的含义 |
-| 返回说明 | 返回值含义 |
-| 异常说明 | 可能抛出的异常 |
-| 前置条件 | 调用前要满足什么 |
-| 后置条件 | 执行后的状态变化 |
-
-### 模板
-
-```java
-/**
- * 根据用户 ID 查询用户信息。
- *
- * @param userId 用户 ID
- * @return 用户信息
- * @throws BusinessException 用户不存在时抛出
- */
-```
-
-## Inline Comment
-
-### 使用场景
-
-- 多条件判断
-- 状态流转
-- 复杂计算
-- 需要解释意图但代码本身又不适合再拆函数的地方
-
-### 规则
-
-- 注释要解释“为什么”，不要重复“是什么”。
-- 复杂逻辑必须留下能看懂的上下文。
-- 用短句说明约束、边界和原因。
-
-## 示例
-
-```java
-// 远程调用：查询用户信息，用于订单创建前校验
-UserDTO user = userApi.findById(dto.getUserId()).assertSucceed();
-```
-
-## 注释密度
-
-| 场景 | 建议 |
-|------|------|
-| Entity | 类注释 + 字段注释 |
-| DTO/VO | 类注释 + 字段注释 |
-| Mapper | 类注释即可 |
-| Service | 类注释 + 方法注释 + 逻辑注释 |
-| Controller | 类注释 + 方法注释 |
-| Convert | 类注释即可 |
-
-## 不建议
-
-- 代码很清楚，不需要注释。
-- 注释会过时，所以不注释。
-- 以后再补注释。
-- IDE 自动生成就够了。

package/skills/knowledge-capture/SKILL.md

@@ -1,93 +0,0 @@
----
-name: knowledge-capture
-description: 当上游任务已经产出证据，需要整理、沉淀或交接而不想重做分析时，提炼可复用的决策、需求知识、实时代码事实、CodeWiki 事实和交接笔记
-lifecycle_stage: capture
-rule_profile: capture
-dependencies: []
-triggers:
-  - capture
-  - handoff
-  - note
-  - summary
-  - decision log
-  - knowledge
-inputs:
-  - approved artifacts
-  - findings
-  - decisions
-  - staged fact packs
-outputs:
-  - reusable note
-  - knowledge page
-  - handoff summary
-  - knowledge-base write pack
-workflow:
-  - collect the produced artifact
-  - normalize it into a reusable note
-  - separate requirement knowledge, realtime code facts, CodeWiki facts, and decision-log content
-  - link it to the originating skill
-  - when persistence is needed, convert the note into a knowledge-base fact pack and write it with the capture writer
-  - publish the handoff summary for downstream reuse
-gates:
-  - stop at capture and organization
-  - do not redo upstream analysis
-  - do not generate new requirements or code
-  - do not rewrite the fact pack into a new analysis
-refs:
-  - skills/references/business-fact-extraction.md
-  - skills/references/skill-reference-matrix.md
-  - skills/references/rule-loading-map.md
-  - skills/references/flow-test-cases.md
-  - skills/references/full-chain-replay-scenarios.md
-  - skills/references/prompt-replay-checklist.md
-  - docs/codewiki-knowledge-base.md
----
-
-# Knowledge Capture
-
-## Purpose
-
-Store decisions, artifacts, and handoff notes so other skills can reuse them later.
-
-## Suitable / Unsuitable
-
-- Suitable: summaries, decision logs, reusable knowledge, artifact handoff, CodeWiki facts, requirements knowledge, realtime code facts, staged fact packs
-- Unsuitable: requirement discovery, design, implementation, review, test authoring
-
-## Workflow
-
-1. Collect the produced artifact.
-2. Normalize it into a reusable note.
-3. Separate requirement knowledge, realtime code facts, CodeWiki facts, decision log entries, and pitfall notes.
-4. Link it back to the originating skill.
-5. If the note should persist, map it to the knowledge-base file targets and write the fact pack.
-6. Publish the handoff summary for downstream reuse.
-
-## Replay Signals
-
-- Input signal: approved artifacts, findings, decisions, or staged fact packs.
-- Output to verify: reusable note, knowledge page, handoff summary, decision log entry, codewiki update, enterprise knowledge note, knowledge-base write pack.
-- Stop signal: redoing upstream analysis or generating new requirements/code.
-- Handoff signal: the reusable note is ready for later reuse by other skills.
-
-## Stop Rules
-
-- Stop at capture and organization.
-- Do not redo upstream analysis.
-- Do not generate new requirements or code.
-- Do not merge requirement knowledge, code facts, and decisions into one blob.
-- Do not treat persistence as a new analysis pass.
-- Do not rewrite the fact pack into a new analysis.
-
-## Examples
-
-- Input: "Capture the decisions and pitfalls from this task."
-- Output: reusable note, knowledge page, handoff summary, optional knowledge-base write pack
-- Stop: do not re-open the design or implementation debate
-
-## References
-
-- `skills/references/business-fact-extraction.md`
-- `skills/references/skill-reference-matrix.md`
-- `skills/references/rule-loading-map.md`
-- `docs/codewiki-knowledge-base.md`