@pigcloud/skills 1.0.10 → 1.1.2

package/rules/docs/index.md

@@ -1,49 +0,0 @@
-# Docs Rules
-
-`docs/` contains rules for API docs, knowledge capture, and other durable written artifacts.
-
-## 默认做法
-
-- Keep docs tied to real artifacts.
-- Write for reuse, not for one-off narration.
-- Capture decisions and terms that future work needs.
-- Distinguish reference docs from decision logs.
-- Separate stable contracts from usage examples.
-- Route consumer-facing material to `api` when contract and examples must stay together.
-- Route durable knowledge to `reference` when the material should outlive one change.
-
-## 选择
-
-- Use `contract` for stable behavior that callers rely on.
-- Use `api` for API-facing docs that need contract plus examples.
-- Use `examples` for usage illustrations that support a contract.
-- Use `reference` for reusable long-lived docs and artifact notes.
-- Use `decision-log` for time-bound decisions and rationale.
-- Use `capture` for context transfer, and `capture-summary` for the smallest reusable handoff note.
-
-## 禁区
-
-- Do not mix documentation with implementation work.
-- Do not turn docs into a full tutorial when the task only needs a reference.
-- Do not mix stable reference material with time-bound decisions.
-- Do not mix examples with the contract itself when they have different lifecycles.
-
-## 检查
-
-- Is the doc reusable?
-- Does it point back to the artifact it describes?
-- Does it belong to exactly one lifecycle bucket?
-
-## 回放信号
-
-- Trigger when the request is about API docs, knowledge notes, or reusable documentation.
-
-## References
-
-- `docs/api.md`
-- `docs/capture.md`
-- `docs/reference.md`
-- `docs/decision-log.md`
-- `docs/contract.md`
-- `docs/examples.md`
-- `docs/capture-summary.md`

package/rules/docs/reference.md

@@ -1,32 +0,0 @@
-# Docs Reference Rules
-
-## 默认做法
-
-- Write stable reference material for callers and maintainers.
-- Keep reference pages small, reusable, and artifact-backed.
-- Point readers to the source of truth, not the discussion trail.
-- Keep reference pages independent from decision logs and captures.
-- Include only facts that should survive a normal implementation change.
-
-## 禁区
-
-- Do not bury a reference inside a decision log.
-- Do not invent behavior the code does not support.
-- Do not embed transient decisions into the reference.
-- Do not use reference pages to retell the whole history.
-
-## 检查
-
-- Is the document stable enough to be reused later?
-- Does it point at the underlying artifact or contract?
-- Is it free of time-bound rationale?
-- Would this still be useful after several code changes?
-- Would a new reader use this without checking recent discussions?
-
-## 回放信号
-
-- Trigger when the task is about reusable reference material, contracts, or long-lived docs.
-
-## References
-
-- `docs/index.md`

package/rules/overlays/pig-cloud/controller.md

@@ -1,33 +0,0 @@
-# Pig Cloud Controller 规则
-
-`overlays/pig-cloud/controller.md` 定义 Controller 层边界。
-
-## 默认做法
-
-- Controller 只负责协议接入、参数接收、结果返回。
-- 只做轻量编排，不做业务决策。
-- 返回值默认配合 `rules/overlays/pig-cloud/rest-response.md`。
-
-## 禁区
-
-- 不要在 Controller 里写业务判断、流程编排或状态机。
-- 不要直接依赖 Mapper 做写入。
-- 不要在这里做异常分类、错误码映射或统一兜底。
-- 不要把 DTO 转换逻辑扩散到多个接口方法里。
-
-## 检查
-
-- 这个方法是否仍然只是入口？
-- 有没有把业务逻辑、异常处理或持久化操作塞回 Controller？
-- Controller 是否只依赖 Service 和请求/响应模型？
-
-## 回放信号
-
-- 当新增接口、拆接口、调整入参或更改返回结构时触发。
-
-## References
-
-- `rules/overlays/pig-cloud.md`
-- `rules/overlays/pig-cloud/layering.md`
-- `rules/overlays/pig-cloud/rest-response.md`
-- `rules/overlays/pig-cloud/exception.md`

package/rules/overlays/pig-cloud/dto-vo.md

@@ -1,33 +0,0 @@
-# Pig Cloud DTO/VO 规则
-
-`overlays/pig-cloud/dto-vo.md` 定义 DTO 与 VO 的边界。
-
-## 默认做法
-
-- DTO 用于输入承接和校验。
-- VO 用于输出展示，不回流成写入对象。
-- 请求模型与响应模型分离。
-
-## 禁区
-
-- 不要拿实体直接充当接口输入输出。
-- 不要让 DTO、VO、Entity 三者边界混乱。
-- 不要让返回对象反向承担写入语义。
-- 不要把字段补齐逻辑和展示逻辑混进输入模型。
-
-## 检查
-
-- 这个模型是输入、输出还是持久化实体？
-- 是否存在复用过度导致边界模糊？
-- 是否把展示字段混进了写入模型？
-- 是否把写入字段混进了展示模型？
-
-## 回放信号
-
-- 当接口模型、字段映射或展示层结构变化时触发。
-
-## References
-
-- `rules/overlays/pig-cloud.md`
-- `rules/overlays/pig-cloud/rest-response.md`
-- `rules/overlays/pig-cloud/entity.md`

package/rules/overlays/pig-cloud/entity.md

@@ -1,32 +0,0 @@
-# Pig Cloud 实体规则
-
-`overlays/pig-cloud/entity.md` 定义实体边界和删除语义。
-
-## 默认做法
-
-- 逻辑删除语义明确时，使用 `MpLogicDelEntity`。
-- 真实删除语义明确时，使用 `MpRealDelEntity`。
-- 实体设计与删除语义保持一致，不混搭。
-
-## 禁区
-
-- 不要在同一实体上同时混用真实删除和逻辑删除语义。
-- 不要为删除状态再发明一套平行字段。
-- 不要把删除语义散落到多个层里重复解释。
-- 不要把 Entity 当成接口输入输出对象。
-
-## 检查
-
-- 这个实体到底是逻辑删除还是物理删除？
-- 删除语义是否在模型层已经说清楚？
-- 是否需要更新相关查询、恢复或审计逻辑？
-- 是否有人把 Entity 直接暴露到 Controller？
-
-## 回放信号
-
-- 当新增实体、变更删除策略或调整删除字段时触发。
-
-## References
-
-- `rules/overlays/pig-cloud.md`
-- `rules/index.md`

package/rules/overlays/pig-cloud/exception.md

@@ -1,32 +0,0 @@
-# Pig Cloud Exception 规则
-
-`overlays/pig-cloud/exception.md` 定义异常与错误语义。
-
-## 默认做法
-
-- 业务异常要有稳定语义。
-- 错误输出与 `Result<T>` 的返回约定保持一致。
-- 异常转换尽量集中处理，不要分散到多个层。
-
-## 禁区
-
-- 不要在接口层随意吞异常。
-- 不要把异常语义写得模糊。
-- 不要让错误码和错误信息各自漂移。
-- 不要把异常处理和 REST 封装逻辑拆成两套平行实现。
-
-## 检查
-
-- 这个异常是否能被稳定识别？
-- 错误输出是否和返回约定一致？
-- 异常转换是否被重复实现？
-- 是否应当由统一异常出口兜底？
-
-## 回放信号
-
-- 当业务失败、错误码或异常转换方式变化时触发。
-
-## References
-
-- `rules/overlays/pig-cloud.md`
-- `rules/overlays/pig-cloud/rest-response.md`

package/rules/overlays/pig-cloud/layering.md

@@ -1,31 +0,0 @@
-# Pig Cloud 分层规则
-
-`overlays/pig-cloud/layering.md` 定义本仓库的默认分层形态。
-
-## 默认做法
-
-- 默认使用 `Controller -> Service -> Mapper`。
-- Controller 只负责接收请求和返回结果。
-- Service 负责业务编排、事务控制和规则聚合。
-- Mapper 只负责持久化访问。
-
-## 禁区
-
-- 不要把业务逻辑塞进 Controller。
-- 不要把编排逻辑塞进 Mapper。
-- 不要绕过 Service 直接操作持久层完成业务写入。
-
-## 检查
-
-- 业务流是否仍然是 Controller 进、Service 承接、Mapper 落库？
-- Controller 是否保持轻量？
-- Service 是否承担了应有的编排和事务职责？
-
-## 回放信号
-
-- 当接口调用链、分层职责或写入路径发生变化时触发。
-
-## References
-
-- `rules/overlays/pig-cloud.md`
-- `rules/index.md`

package/rules/overlays/pig-cloud/mapper.md

@@ -1,32 +0,0 @@
-# Pig Cloud Mapper 规则
-
-`overlays/pig-cloud/mapper.md` 定义 Mapper 层边界。
-
-## 默认做法
-
-- Mapper 只负责数据访问，不承载业务编排。
-- 保持查询和更新风格与 `rules/overlays/pig-cloud/query-style.md` 一致。
-- 访问模型尽量稳定，避免无意义的映射漂移。
-
-## 禁区
-
-- 不要在 Mapper 中放业务规则。
-- 不要在 Mapper 中管理事务。
-- 不要在 Mapper 中拼 HTTP 或 UI 语义。
-- 不要让接口层绕过 Mapper 去模拟持久化行为。
-
-## 检查
-
-- 这个方法是不是只做数据访问？
-- 查询和更新风格是否一致？
-- 有没有把业务逻辑下沉成 SQL 拼装？
-- 是否有跨层数据访问绕路？
-
-## 回放信号
-
-- 当数据访问方法、SQL 组织或映射策略变化时触发。
-
-## References
-
-- `rules/overlays/pig-cloud.md`
-- `rules/overlays/pig-cloud/query-style.md`

package/rules/overlays/pig-cloud/query-style.md

@@ -1,32 +0,0 @@
-# Pig Cloud 查询规则
-
-`overlays/pig-cloud/query-style.md` 定义查询和更新写法。
-
-## 默认做法
-
-- 优先使用 lambda query/update。
-- 条件表达式保持可读、可重构。
-- 查询和更新风格保持一致，不在同模块内漂移。
-
-## 禁区
-
-- 不要把字段名字符串散落在业务逻辑里。
-- 不要为了图快引入难维护的拼接式查询。
-- 不要让查询风格和数据访问职责分离到不同层。
-- 不要把临时统计逻辑伪装成常规查询风格。
-
-## 检查
-
-- 这段读写是否还能保持 lambda 风格？
-- 条件是否容易重构和复用？
-- 是否引入了不必要的字符串字段依赖？
-- 是否把特殊 SQL 当成默认风格？
-
-## 回放信号
-
-- 当读写条件、查询方式或更新方式变化时触发。
-
-## References
-
-- `rules/overlays/pig-cloud.md`
-- `rules/overlays/pig-cloud/mapper.md`

package/rules/overlays/pig-cloud/rest-response.md

@@ -1,33 +0,0 @@
-# Pig Cloud 响应规则
-
-`overlays/pig-cloud/rest-response.md` 定义 REST 返回封装。
-
-## 默认做法
-
-- REST 接口默认使用 `Result<T>` 作为返回封装。
-- 成功、失败和业务异常返回保持统一结构。
-- 返回内容尽量稳定，避免临时拼装不同响应形状。
-
-## 禁区
-
-- 不要在同一仓库里混用多套响应封装。
-- 不要让 Controller 直接暴露随意的原始对象形状。
-- 不要为了局部方便引入不一致的错误返回格式。
-- 不要把业务异常、HTTP 状态和封装协议混成一层规则。
-
-## 检查
-
-- 新增接口是否沿用了统一响应封装？
-- 是否需要兼容旧响应结构？
-- 是否有局部响应形状漂移风险？
-- 是否把响应协议和异常语义混写了？
-
-## 回放信号
-
-- 当接口出入参、返回结构或错误包装方式发生变化时触发。
-
-## References
-
-- `rules/overlays/pig-cloud.md`
-- `rules/index.md`
-- `rules/overlays/pig-cloud/exception.md`

package/rules/overlays/pig-cloud/service.md

@@ -1,33 +0,0 @@
-# Pig Cloud Service 规则
-
-`overlays/pig-cloud/service.md` 定义 Service 层边界。
-
-## 默认做法
-
-- Service 负责业务编排、规则组合和事务边界。
-- 以用例为中心组织方法，不把流程拆碎到上层。
-- 需要落库时，由 Service 统一调度 Mapper。
-
-## 禁区
-
-- 不要把复杂流程放到 Controller。
-- 不要把事务边界拆散到多个层重复声明。
-- 不要把业务步骤写成纯透传。
-- 不要在 Service 里输出 HTTP 响应语义。
-
-## 检查
-
-- 这段逻辑是否应该留在 Service？
-- 事务和编排是否由 Service 统一掌控？
-- 是否把业务用例拆得过碎？
-- 是否把接口层语义带进了业务层？
-
-## 回放信号
-
-- 当业务流程、事务边界或编排顺序变化时触发。
-
-## References
-
-- `rules/overlays/pig-cloud.md`
-- `rules/overlays/pig-cloud/layering.md`
-- `rules/overlays/pig-cloud/transactions.md`

package/rules/overlays/pig-cloud/transactions.md

@@ -1,32 +0,0 @@
-# Pig Cloud 事务规则
-
-`overlays/pig-cloud/transactions.md` 定义事务边界。
-
-## 默认做法
-
-- 事务默认放在 Service 层。
-- 以业务用例为单位管理事务边界。
-- Controller 和 Mapper 不承担事务编排职责。
-
-## 禁区
-
-- 不要把事务放进 Controller。
-- 不要把事务逻辑散落到 Mapper。
-- 不要让多个事务边界互相打架。
-- 不要把补偿逻辑当成事务替代品。
-
-## 检查
-
-- 这个写操作是否已经在 Service 层包住？
-- 事务边界是否和业务用例一致？
-- 是否存在跨层重复声明事务的情况？
-- 失败路径是事务回滚还是业务补偿，是否说清楚了？
-
-## 回放信号
-
-- 当写路径、补偿逻辑或事务边界调整时触发。
-
-## References
-
-- `rules/overlays/pig-cloud.md`
-- `rules/overlays/pig-cloud/service.md`

package/rules/overlays/pig-cloud/validation.md

@@ -1,33 +0,0 @@
-# Pig Cloud 校验规则
-
-`overlays/pig-cloud/validation.md` 定义请求校验边界。
-
-## 默认做法
-
-- 写接口默认使用 `@Valid @RequestBody`。
-- 入口层先校验，Service 不补救请求格式错误。
-- 校验规则跟随请求 DTO，不散到业务方法里。
-
-## 禁区
-
-- 不要用手写解析代替标准校验。
-- 不要把入参合法性检查下沉到 Service 再兜底。
-- 不要让同类接口各自定义一套校验入口。
-- 不要把校验结果包装成业务语义。
-
-## 检查
-
-- 校验是否在边界层完成？
-- 是否存在跳过校验的写接口？
-- 校验失败是否由统一错误出口处理？
-- 是否把参数合法性和业务失败混在一起？
-
-## 回放信号
-
-- 当请求 DTO、写接口约束或校验注解变化时触发。
-
-## References
-
-- `rules/overlays/pig-cloud.md`
-- `rules/overlays/pig-cloud/exception.md`
-- `rules/overlays/pig-cloud/dto-vo.md`

package/rules/product/acceptance.md

@@ -1,25 +0,0 @@
-# Product Acceptance Rules
-
-## 默认做法
-
-- Turn business intent into observable acceptance criteria.
-- Make assumptions explicit when the input is incomplete.
-- Separate happy path, edge cases, and non-goals.
-
-## 禁区
-
-- Do not make acceptance criteria depend on implementation details.
-- Do not leave vague qualifiers where a testable condition is possible.
-
-## 检查
-
-- Can each criterion be checked?
-- Are the boundaries and non-goals explicit?
-
-## 回放信号
-
-- Trigger when the request needs acceptance criteria, scope confirmation, or product sign-off support.
-
-## References
-
-- `product/index.md`

package/rules/product/briefing.md

@@ -1,27 +0,0 @@
-# Product Briefing Rules
-
-## 默认做法
-
-- Convert raw input into a compact, decision-ready brief.
-- Record problem, target users, business goal, scope, non-scope, and open questions.
-- Preserve the phrasing that downstream engineering needs.
-
-## 禁区
-
-- Do not write code-level solutions.
-- Do not jump into architecture before scope is settled.
-- Do not hide unresolved questions.
-
-## 检查
-
-- Is the brief short enough to scan quickly?
-- Are the unresolved questions visible?
-- Is the business goal separated from solution ideas?
-
-## 回放信号
-
-- Trigger when the input is a draft request, meeting note, or rough business idea.
-
-## References
-
-- `product/index.md`

package/rules/product/index.md

@@ -1,36 +0,0 @@
-# Product Rules
-
-`product/` contains rules for product intent, scope, and requirement shaping.
-
-## 默认做法
-
-- Capture the business problem before solution details.
-- Separate in-scope, out-of-scope, and open questions.
-- Keep current project facts separate from product intent.
-- Keep the output ready for engineering refinement, not implementation.
-
-## 禁区
-
-- Do not write implementation details.
-- Do not choose technical constraints too early.
-- Do not let product notes become code specs.
-- Do not collapse business ambiguity into fake certainty.
-
-## 检查
-
-- Is the problem statement clear?
-- Is the scope bounded?
-- Is the output ready for the next stage?
-- Is the business outcome measurable?
-
-## 回放信号
-
-- Trigger when the request is about business intent, requirements, or scope discovery.
-
-## References
-
-- `product/intake.md`
-- `product/project-context.md`
-- `product/modeling.md`
-- `product/briefing.md`
-- `product/acceptance.md`

package/rules/product/intake.md

@@ -1,27 +0,0 @@
-# Product Intake Rules
-
-## 默认做法
-
-- Capture the user need, business goal, and release context.
-- Turn noisy input into a PRD-ready brief.
-- Record scope, priority, acceptance outline, and open questions.
-
-## 禁区
-
-- Do not write implementation details.
-- Do not pick technical solutions too early.
-- Do not produce code-oriented specs.
-
-## 检查
-
-- Is the business outcome explicit?
-- Are scope and non-scope separated?
-- Are the follow-up questions visible?
-
-## 回放信号
-
-- Trigger when the input is raw business intent, meeting notes, or a draft PRD.
-
-## References
-
-- `product/index.md`

package/rules/product/modeling.md

@@ -1,25 +0,0 @@
-# Product Modeling Rules
-
-## 默认做法
-
-- Normalize domain concepts, terms, and entity relationships.
-- Keep the model understandable to both product and engineering.
-- Link terminology back to the brief.
-
-## 禁区
-
-- Do not redesign the business problem into a technical implementation.
-- Do not overload the model with code details.
-
-## 检查
-
-- Are the core terms stable?
-- Are the relationships clear enough for downstream design?
-
-## 回放信号
-
-- Trigger when the request is about domain concepts, terminology, or business object modeling.
-
-## References
-
-- `product/index.md`

package/rules/product/project-context.md

@@ -1,29 +0,0 @@
-# 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`

package/rules/review/code.md

@@ -1,35 +0,0 @@
-# Code Review Rules
-
-## 默认做法
-
-- Read the diff against the current rules bundle.
-- Report correctness, safety, maintainability, and regression risks.
-- Keep the output actionable.
-- Mention the exact code path or symbol that causes the finding.
-- Prefer one finding per line of reasoning.
-- Format each finding as: location, issue, why it matters, and a concrete fix direction.
-- When stack overlays apply, anchor the finding to the smallest relevant stack surface.
-- If there are no findings, say why the change is acceptable instead of hand-waving.
-- Separate must-fix issues from optional suggestions.
-
-## 禁区
-
-- Do not rewrite code from review mode.
-- Do not widen the scope beyond the submitted change.
-- Do not mix findings with implementation patches.
-
-## 检查
-
-- Are the findings backed by evidence?
-- Is each recommendation directly actionable?
-- Would a maintainer know what to change without re-reading the whole diff?
-- Does each finding stand on its own?
-- Would the report still make sense if the author were unavailable?
-
-## 回放信号
-
-- Trigger when the request is a standard code review or PR review.
-
-## References
-
-- `review/index.md`