@pigcloud/skills 1.0.6 → 1.0.8

package/rules/coding/implementation.md

@@ -1,31 +1,26 @@
-# Coding Implementation Rules
-
-## 榛樿鍋氭硶
-
-- Implement only the confirmed scope.
-- Keep the change small, reviewable, and verifiable.
-- Preserve the agreed boundary while coding.
-- Prefer one implementation path over speculative alternatives unless the task explicitly asks for options.
-
-## 绂佸尯
-
-- Do not rewrite the spec-refinement while implementing.
-- Do not widen the scope because implementation is difficult.
-- Do not skip validation.
-- Do not bundle unrelated cleanup into the same change unless it reduces risk.
-
-## 妫€鏌?
-
-- Does the code stay within scope?
-- Can the result be validated locally?
-- Is the implementation easy to review in one pass?
-- Would the diff still make sense if the task title were removed?
-
-## 鍥炴斁淇″彿
-
-- Trigger when the request is about delivery, refactor, or code changes.
-
-## References
-
-- `coding/index.md`
-
+# Coding Implementation Rules
+
+## 默认做法
+
+- Implement only the confirmed scope.
+- Keep the change small, reviewable, and verifiable.
+- Preserve the agreed boundary while coding.
+- Prefer one implementation path over speculative alternatives unless the task explicitly asks for options.
+
+## 禁区
+
+- Do not rewrite the spec-refinement while implementing.
+- Do not widen the scope because implementation is difficult.
+- Do not skip validation.
+- Do not bundle unrelated cleanup into the same change unless it reduces risk.
+
+## 检查
+
+- Does the code stay within scope?
+- Can the result be validated locally?
+- Is the implementation easy to review in one pass?
+- Would the diff still make sense if the task title were removed?
+
+## 回放信号
+
+- Trigger when the task is about implementing a confirmed change.

package/rules/product/project-context.md

@@ -1,30 +1,29 @@
-# Project Context Rules
-
-## 榛樿鍋氭硶
-
-- Capture what the current project already guarantees before rewriting the requirement.
-- Separate product intent, existing project facts, and assumptions.
-- Prefer current repo docs, release notes, and existing behavior over memory.
-- Record conflicts when product demand does not match current project facts.
-
-## 绂佸尯
-
-- Do not turn implementation details into product requirements.
-- Do not ignore existing project facts when they are available.
-- Do not hide conflicts behind vague wording.
-
-## 妫€鏌?
-
-- Are product intent and project facts separated?
-- Are conflicts and open questions explicit?
+# Project Context Rules
+
+## 项目上下文规则
+
+- Capture what the current project already guarantees before rewriting the requirement.
+- Separate product intent, existing project facts, and assumptions.
+- Prefer current repo docs, release notes, and existing behavior over memory.
+- Record conflicts when product demand does not match current project facts.
+
+## 禁区
+
+- Do not turn implementation details into product requirements.
+- Do not ignore existing project facts when they are available.
+- Do not hide conflicts behind vague wording.
+
+## 检查项
+
+- Are product intent and project facts separated?
+- Are conflicts and open questions explicit?
 - Does the output still work for spec-refinement?
-- Is the project context based on current evidence?
-
-## 鍥炴斁淇″彿
-
-- Trigger when the task needs product understanding aligned with the current project state.
-
-## References
-
-- `product/index.md`
-
+- Is the project context based on current evidence?
+
+## 触发信号
+
+- Trigger when the task needs product understanding aligned with the current project state.
+
+## References
+
+- `product/index.md`

package/skills/code-review/references/template-review.md

@@ -1,214 +1,39 @@
-# 代码评审报告模板
-
-> 用于 code-review Skill 输出的标准格式
-
----
-
-## 模板内容
-
-```markdown
-# 代码评审报告
-
-## 评审概要
-
-| 字段 | 内容 |
-|------|------|
-| 评审时间 | {datetime} |
-| 评审文件数 | {count} |
-| 变更行数 | +{add} / -{del} |
-| 评审耗时 | {duration} |
-| 规则覆盖率 | {coverage}% |
-| Rubric 评分 | {score}/10 |
-
----
-
-## 问题列表
-
-### P0 问题（阻断性 - 必须修复）
-
-#### 问题 #1
-
-| 字段 | 内容 |
-|------|------|
-| 文件 | `{filePath}` |
-| 行号 | {lineNumber} |
-| 规则 | {ruleId}: {ruleName} |
-| 类型 | MUST / NEVER |
-| 问题 | {问题描述} |
-| 代码 | `{问题代码片段}` |
-| 修复 | `{修复建议}` |
-| 依据 | [规则定义](references/rules.md#{ruleId}) |
-
----
-
-### P1 问题（严重 - 必须修复）
-
-#### 问题 #2
-
-| 字段 | 内容 |
-|------|------|
-| 文件 | `{filePath}` |
-| 行号 | {lineNumber} |
-| 规则 | {ruleId}: {ruleName} |
-| 类型 | MUST / NEVER |
-| 问题 | {问题描述} |
-| 代码 | `{问题代码片段}` |
-| 修复 | `{修复建议}` |
-| 依据 | [规则定义](references/rules.md#{ruleId}) |
-
----
-
-### P2 问题（最佳实践 - 建议修复）
-
-#### 问题 #3
-
-| 字段 | 内容 |
-|------|------|
-| 文件 | `{filePath}` |
-| 行号 | {lineNumber} |
-| 规则 | {ruleId}: {ruleName} |
-| 问题 | {问题描述} |
-| 修复 | `{修复建议}` |
-
----
-
-### P3 问题（建议改进）
-
-#### 问题 #4
-
-| 字段 | 内容 |
-|------|------|
-| 文件 | `{filePath}` |
-| 规则 | {ruleId}: {ruleName} |
-| 问题 | {问题描述} |
-| 建议 | `{改进建议}` |
-
----
-
-## 跨模块影响分析
-
-### 变更文件
-
-| 文件 | 类型 | 模块 |
-|------|------|------|
-| `{filePath}` | 新增 / 修改 / 删除 | `{module}` |
-
-### 影响模块
-
-| 模块 | 影响类型 | 变更内容 | 建议 |
-|------|----------|----------|------|
-| `{module}` | API变更 / 依赖变更 / 数据变更 | `{content}` | `{suggestion}` |
-
-### 依赖关系图
-
-```
-{moduleA} → {moduleB} → {moduleC}
-    ↓
-{moduleD}
-```
-
----
-
-## 安全检查结果
-
-| 维度 | 结果 | 问题数 | 详情 |
-|------|------|--------|------|
-| 硬编码 | ✅ / ⚠️ | {count} | {details} |
-| 日志 | ✅ / ⚠️ | {count} | {details} |
-| SQL注入 | ✅ / ⚠️ | {count} | {details} |
-| XSS | ✅ / ⚠️ | {count} | {details} |
-
----
-
-## 性能检查结果
-
-| 维度 | 结果 | 问题数 | 详情 |
-|------|------|--------|------|
-| N+1查询 | ✅ / ⚠️ | {count} | {details} |
-| Left-fuzzy LIKE | ✅ / ⚠️ | {count} | {details} |
-| 批量操作 | ✅ / ⚠️ | {count} | {details} |
-
----
-
-## Rubric 自检结果
-
-| 规则 | 结果 | 说明 |
-|------|------|------|
-| R1: 渐进式加载 | ✅ / ⚠️ | {message} |
-| R2: 规则覆盖率 | ✅ / ⚠️ | {coverage}% |
-| R3: 位置准确性 | ✅ / ⚠️ | 偏差 {diff} 行 |
-| R4: 可解释性 | ✅ / ⚠️ | {coverage}% |
-| R5: 问题分级 | ✅ / ⚠️ | {message} |
-| R6: 跨模块影响 | ✅ / ⚠️ | {message} |
-| R7: 输出格式 | ✅ / ⚠️ | {message} |
-| R8: 确认节点 | ✅ / ⚠️ | {message} |
-| R9: Pre-Delivery | ✅ / ⚠️ | {message} |
-| R10: 反 Slop | ✅ / ⚠️ | {message} |
-
----
-
-## 评审结论
-
-| 结论 | 条件 | 当前状态 |
-|------|------|----------|
-| ✅ 通过 | 0 个 P0/P1 问题 | {status} |
-| ⚠️ 需修改后通过 | 有 P0/P1 问题，修复后重新评审 | {status} |
-| ❌ 不通过 | >5 个 P0 问题 | {status} |
-
----
-
-## 下一步建议
-
-1. {修复建议1}
-2. {修复建议2}
-3. 执行 `mvn compile -q` 验证编译
-4. 执行 `mvn test -q` 验证测试
-5. 重新提交评审
-
----
-
-## 评审人
-
-| 字段 | 内容 |
-|------|------|
-| 评审工具 | pig-skills code-review v{version} |
-| 评审模型 | {model} |
-| Rubric 评分 | {score}/10 |
-
----
-
-*报告生成时间: {timestamp}*
-```
-
----
-
-## 使用说明
-
-### 填充变量
-
-| 变量 | 来源 |
-|------|------|
-| `{datetime}` | 当前时间 |
-| `{count}` | Git diff 文件数 |
-| `{add}` / `{del}` | Git diff 行数统计 |
-| `{duration}` | 评审耗时 |
-| `{coverage}` | lint 脚本计算 |
-| `{score}` | Rubric 自检结果 |
-| `{filePath}` | 变更文件路径 |
-| `{lineNumber}` | lint 脚本定位 |
-| `{ruleId}` | 规则ID（MUST-001 等） |
-| `{ruleName}` | 规则名称 |
-| `{module}` | 模块名称（包路径） |
-
-### 输出位置
-
-```
-.agents/specs/REVIEW-{timestamp}.md
-```
-
-### 命名规则
-
-```
-REVIEW-{YYYYMMDD}-{HHMMSS}.md
-例如: REVIEW-20260616-143000.md
-```
+# 代码审查报告模板
+
+> 代码审查结果的标准输出格式，用于保持结论清晰、可复核、可归档。
+
+---
+
+## 基本信息
+
+| 字段 | 说明 |
+|------|------|
+| 审查时间 | {datetime} |
+| 审查对象 | {repo / branch / pr} |
+| 审查人 | {reviewer} |
+| 审查范围 | {diff / files / modules} |
+
+## 结论摘要
+
+- 总体结论：{pass / pass with comments / fail}
+- 风险等级：{low / medium / high}
+- 是否建议合并：{yes / no}
+
+## 发现项
+
+| 等级 | 文件 | 问题 | 建议 |
+|------|------|------|------|
+| P0 | {file} | {issue} | {fix} |
+| P1 | {file} | {issue} | {fix} |
+| P2 | {file} | {issue} | {fix} |
+
+## 验证信息
+
+- 已运行的检查：{lint / test / manual check}
+- 未覆盖的风险：{gaps}
+- 需要补充的证据：{evidence}
+
+## 备注
+
+- 如果没有发现问题，也要明确说明“未发现阻断项”。
+- 如果有假设，要明确标注假设来源。

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

@@ -1,152 +1,44 @@
-# 蒸馏质量验收检查清单
-
-> 用于验证蒸馏产物是否符合规范
-
----
-
-## 静态检查清单
-
-### 目录结构检查
-
-- [ ] `distilled/` 目录存在
-- [ ] `README.md` 存在且内容完整
-- [ ] `00-overview.md` 存在且包含"给 AI 的关键约定"
-- [ ] `01-glossary.md` 存在
-- [ ] `domain/_index.md` 存在
-- [ ] `domain/<对象>.md` 每个核心对象一个文件
-- [ ] `api/_index.md` 存在且包含典型编排
-- [ ] `api/<域>/<用例>.md` 每个用例一个文件
-- [ ] `reference/schema/*.md` 字段级 Schema
-- [ ] `reference/enums.md` 存在
-- [ ] `reference/error-codes.md` 存在
-- [ ] `reference/model-code-conflicts.md` 存在
-- [ ] `requirements/_index.md` 存在
-
----
-
-### 领域对象检查
-
-- [ ] 每个对象有"一句话定义"
-- [ ] 每个对象有"业务语义"段落
-- [ ] 每个对象有"生命周期/状态"段落
-- [ ] 每个对象有"关键属性"表（语义级）
-- [ ] 每个对象有"组合/关系"说明
-- [ ] 每个对象有"核心业务规则"段落
-- [ ] 每条规则有执行方标注（【服务端强制】/【调用方需预判】等）
-- [ ] 每个对象有"相关能力"链接
-- [ ] 每个对象有"明细索引"
-
----
-
-### API 接口检查
-
-- [ ] 每个接口有"业务场景"说明
-- [ ] 每个接口有"能力边界"说明（做什么/不做什么）
-- [ ] 每个接口有"输入"表（参数/类型/必填/说明/约束）
-- [ ] 每个接口有"输出"表（字段/说明）
-- [ ] 每个接口有"关键规则"段落
-- [ ] 每条规则有执行方标注
-- [ ] 每个接口有"涉及的数据对象"链接
-- [ ] 每个接口有"可能的错误"表
-- [ ] 每个接口有"调用示例"（真实可用）
-- [ ] 每个接口有"写权限分级"
-
----
-
-### 明细层检查
-
-- [ ] Schema 表有"对应领域属性/API字段"列
-- [ ] 枚举表有 ✅/⚠️ 标记
-- [ ] 错误码表有"AI 应如何向用户解释"列
-- [ ] 冲突清单有"本体/需求"、"代码"、"AI 影响"三列
-
----
-
-### 交叉引用检查
-
-- [ ] 所有链接使用 `[[slug]]` 格式
-- [ ] 对象↔接口↔Schema 三者互相链接
-- [ ] 无明显断链（链接目标不存在但未标记"待补")
-
----
-
-### 命名规范检查
-
-- [ ] 文件名使用小写 kebab-case
-- [ ] API 字段沿用代码实际返回的命名
-- [ ] 枚举值使用业务实际值（含中文）
-
----
-
-## 动态验证清单
-
-### 读/查询场景
-
-| 测试 | 验证内容 | 结果 |
-|------|----------|------|
-| 名称→ID 解析 | AI 能正确调用主数据接口解析名称 | ✅/❌ |
-| 查询参数 | AI 能正确构造查询参数 | ✅/❌ |
-| 结果解读 | AI 能正确解读返回结果 | ✅/❌ |
-
-### 写/录入场景
-
-| 测试 | 验证内容 | 结果 |
-|------|----------|------|
-| 必填字段 | AI 能识别必填字段并提示用户 | ✅/❌ |
-| 用例编排 | AI 能按正确顺序调用接口 | ✅/❌ |
-| 服务端维护字段 | AI 不传入服务端维护字段 | ✅/❌ |
-| 回显确认 | 写操作前回显给用户确认 | ✅/❌ |
-
-### 统计场景
-
-| 测试 | 验证内容 | 结果 |
-|------|----------|------|
-| 口径理解 | AI 能正确理解统计接口口径 | ✅/❌ |
-| 参数构造 | AI 能正确构造统计参数 | ✅/❌ |
-
-### 规则反例场景
-
-| 测试 | 验证内容 | 结果 |
-|------|----------|------|
-| 规则预判 | AI 能预判违反规则的错误 | ✅/❌ |
-| 错误解释 | AI 能根据 error-codes.md 解释错误 | ✅/❌ |
-
----
-
-## 验证结论
-
-| 检查项 | 通过数 | 总数 | 通过率 |
-|--------|--------|------|--------|
-| 目录结构 | | 13 | |
-| 领域对象 | | 9 | |
-| API 接口 | | 10 | |
-| 明细层 | | 4 | |
-| 交叉引用 | | 3 | |
-| 命名规范 | | 3 | |
-| 动态验证 | | 12 | |
-
-**总通过率要求**: >= 90%
-
----
-
-## 验证记录
-
-| 日期 | 验证人 | 通过率 | 备注 |
-|------|--------|--------|------|
-| | | | |
-
----
-
-## 发现的问题
-
-1. 
-2. 
-3. 
-
----
-
-## 修复计划
-
-| 问题 | 修复方案 | 状态 |
-|------|----------|------|
-| | | 待修复/已修复 |
+# 领域提炼检查清单
+
+> 用于检查领域建模提炼结果是否满足规范、是否可交接、是否可复用。
+
+---
+
+## 目录结构
+
+- [ ] `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
+
+## 备注
+
+- 如果某个目录暂时没有内容，也要在索引里明确说明。
+- 如果有未确认项，单独列在“待确认”区域，不要隐藏。