@pigcloud/skills 1.0.10 → 1.1.2

package/rules/coding/backend/transaction-rollback.md

@@ -1,30 +0,0 @@
-# Backend Transaction Rollback Rules
-
-## 默认做法
-
-- Define rollback behavior for failure paths explicitly.
-- Keep local consistency and failure handling together.
-- Make retry or compensation decisions visible when needed.
-- Say what must roll back, what must compensate, and what can stay committed.
-- Mention when retry is safe and when it is not.
-
-## 禁区
-
-- Do not rely on implicit rollback assumptions.
-- Do not leave partial-write behavior undocumented.
-- Do not hide compensation logic behind a generic failure note.
-
-## 检查
-
-- Is rollback behavior explicit?
-- Are failure and compensation paths clear?
-- Can the reader see whether the action is retryable, compensatable, or both?
-
-## 回放信号
-
-- Trigger when the task touches rollback, partial failure, or compensation.
-
-## References
-
-- `coding/backend/index.md`
-- `coding/backend/transaction.md`

package/rules/coding/backend/transaction.md

@@ -1,38 +0,0 @@
-# Backend Transaction Rules
-
-## 默认做法
-
-- Use this file to choose between boundary and rollback notes.
-- Keep the top-level transaction rule focused on the scope decision.
-- Use the smallest transaction rule that answers the task.
-- If the task needs both scope and failure behavior, answer boundary first and rollback second.
-- Keep the result anchored to one service operation or one failure path.
-- Tell the reader whether the issue is boundary placement, rollback behavior, or both.
-- Use this file for transaction scope selection, not business logic.
-
-## 禁区
-
-- Do not repeat boundary details that already belong in `transaction-boundary`.
-- Do not repeat rollback details that already belong in `transaction-rollback`.
-- Do not turn this file into a full transaction tutorial.
-- Do not hide a rollback concern inside a boundary-only answer.
-- Do not use this file as a generic service rule.
-
-## 检查
-
-- Is the task about scope selection, not a detailed rule?
-- Should the answer come from the boundary or rollback subrule?
-- Is the file still short enough to stay an entry point?
-- Would the next step be obvious after reading the chosen subrule?
-- Did the answer keep one business operation in view?
-- Is this a transaction question rather than a service design question?
-
-## 回放信号
-
-- Trigger when the task touches cross-step data consistency or rollback behavior.
-
-## References
-
-- `coding/backend/index.md`
-- `coding/backend/transaction-boundary.md`
-- `coding/backend/transaction-rollback.md`

package/rules/coding/boundary.md

@@ -1,25 +0,0 @@
-# Coding Boundary Rules
-
-## 默认做法
-
-- Keep the change inside the agreed technical boundary.
-- Respect layer direction, transaction scope, and dependency direction.
-- Prefer narrowing a change over pushing a larger refactor through.
-
-## 禁区
-
-- Do not cross layers just to get the task done faster.
-- Do not widen the scope without an explicit boundary change.
-
-## 检查
-
-- Does the change stay within the agreed boundary?
-- Are layer and dependency directions still intact?
-
-## 回放信号
-
-- Trigger when the task needs boundary enforcement during coding or refactoring.
-
-## References
-
-- `coding/index.md`

package/rules/coding/implementation.md

@@ -1,26 +0,0 @@
-# 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/coding/index.md

@@ -1,38 +0,0 @@
-# Coding Rules
-
-`coding/` contains rules for coding, refactoring, testing, and code-adjacent delivery.
-
-## 默认做法
-
-- Keep changes within the confirmed scope.
-- Prefer the smallest correct code change that still passes validation.
-- Use code rules only when the task actually touches code.
-- Keep implementation and validation concerns separated.
-
-## 禁区
-
-- Do not mix product discovery into coding rules.
-- Do not let coding rules become a rule encyclopedia.
-- Do not expand the implementation boundary because it is convenient.
-- Do not ship unvalidated code changes.
-
-## 检查
-
-- Is the current task about code or code-adjacent delivery?
-- Is there a smaller bundle that still covers the task?
-- Is the change still within the agreed boundary?
-- Is there a validation path?
-
-## 回放信号
-
-- Trigger when the request needs analysis, implementation, testing, or scaffolding around code.
-
-## References
-
-- `coding/analysis.md`
-- `coding/implementation.md`
-- `coding/testing.md`
-- `coding/scaffold.md`
-- `coding/boundary.md`
-- `coding/validation.md`
-- `coding/backend/index.md`

package/rules/coding/scaffold.md

@@ -1,28 +0,0 @@
-# Coding Scaffold Rules
-
-## 默认做法
-
-- Create the minimum structure needed to start work safely.
-- Standardize package names, module layout, and baseline config.
-- Make the scaffold ready for the next stage.
-- Leave room for the implementation rules to take over without rework.
-
-## 禁区
-
-- Do not add business logic to a scaffold task.
-- Do not preload unrelated system details.
-- Do not overfit the scaffold to one feature unless the task explicitly says so.
-
-## 检查
-
-- Can the module start from the scaffold?
-- Is the next stage ready to take over?
-- Is the generated structure minimal and understandable?
-
-## 回放信号
-
-- Trigger when the request is about project bootstrap, starter setup, or environment preparation.
-
-## References
-
-- `coding/index.md`

package/rules/coding/testing.md

@@ -1,29 +0,0 @@
-# Coding Testing Rules
-
-## 默认做法
-
-- Turn the implementation into testable assertions.
-- Cover behavior, regressions, and important edge cases.
-- Keep the testing scope aligned with the change scope.
-- Prefer tests that fail for the right reason and explain the intended contract.
-
-## 禁区
-
-- Do not write tests that ignore the actual behavior.
-- Do not change production code from the testing stage.
-- Do not add broad tests that cannot point to the changed behavior.
-
-## 检查
-
-- Do the tests prove the expected behavior?
-- Do they expose the main regression risks?
-- Do they fail when the behavior changes in the wrong way?
-- Can another maintainer tell which assertion protects which behavior?
-
-## 回放信号
-
-- Trigger when the request is about test design, regression coverage, or verification.
-
-## References
-
-- `coding/index.md`

package/rules/coding/validation.md

@@ -1,29 +0,0 @@
-# Coding Validation Rules
-
-## 默认做法
-
-- Validate the change with the lightest checks that prove correctness.
-- Prefer compile, unit, and targeted regression checks before broad verification.
-- Keep validation evidence explicit.
-- Name the exact command, target, or dataset used for the proof.
-
-## 禁区
-
-- Do not mark a coding task done without validation.
-- Do not rely on unverified assumptions about correctness.
-- Do not use a broad check when a targeted one already proves the point.
-
-## 检查
-
-- Is there a runnable validation step?
-- Is the evidence easy to inspect?
-- Does the validation cover the changed path rather than the whole repo by default?
-- Can the result be reproduced with the same inputs?
-
-## 回放信号
-
-- Trigger when the request needs compile, test, or local correctness verification.
-
-## References
-
-- `coding/index.md`

package/rules/core/code-quality.md

@@ -1,30 +0,0 @@
-# 代码质量规则
-
-## 默认做法
-
-- 命名遵守项目约定。
-- 简单对象可以减少样板代码，但不要以可读性为代价。
-- 代码必须可读、可测、可审查。
-
-## 禁区
-
-- 重复 getter/setter。
-- 魔法值。
-- 过深嵌套。
-
-## 检查
-
-| 类型 | 约定 |
-|---|---|
-| 类 | PascalCase |
-| 方法 | camelCase |
-| 常量 | UPPER_SNAKE_CASE |
-| 变量 | camelCase |
-
-## 回放信号
-
-- 只要出现可读性、命名、复杂度，就应该读这里。
-
-## References
-
-- `core/index.md`

package/rules/core/evidence.md

@@ -1,26 +0,0 @@
-# Evidence Rules
-
-## 默认做法
-
-- Base conclusions on inspectable facts, commands, files, or runtime output.
-- Mark uncertainty explicitly instead of filling gaps with guesses.
-- Prefer direct evidence over memory or impression.
-
-## 禁区
-
-- Do not present speculation as fact.
-- Do not hide weak evidence behind confident wording.
-- Do not assume a rule applies if the source does not show it.
-
-## 检查
-
-- Is there a file, command output, or runtime result backing the conclusion?
-- Is uncertainty labeled?
-
-## 回放信号
-
-- Trigger when the task requires factual verification, comparison, or validation.
-
-## References
-
-- `core/index.md`

package/rules/core/interface.md

@@ -1,26 +0,0 @@
-# 接口与契约规则
-
-## 默认做法
-
-- 先定义契约，再写实现。
-- 输入输出字段要稳定。
-- 对外字段命名要清晰。
-
-## 禁区
-
-- 先写实现再补接口。
-- 用临时字段名对外暴露。
-- 让一个接口同时承担多个职责。
-
-## 检查
-
-- 入参是否足够表达业务。
-- 出参是否足够支撑下一阶段。
-
-## 回放信号
-
-- 只要涉及 API 契约或内部接口边界，就应该读这里。
-
-## References
-
-- `core/index.md`

package/rules/core/iteration.md

@@ -1,26 +0,0 @@
-# Iteration Rules
-
-## 默认做法
-
-- Use feedback to narrow the next pass instead of restarting the whole task.
-- Keep revision notes short and specific.
-- Preserve already confirmed boundaries while iterating.
-
-## 禁区
-
-- Do not reopen completed decisions without cause.
-- Do not use iteration as a reason to drift scope.
-- Do not replace the current artifact when a focused fix is enough.
-
-## 检查
-
-- Does the next iteration only change what is actually needed?
-- Are confirmed decisions still preserved?
-
-## 回放信号
-
-- Trigger when the user asks for a refinement, correction, or follow-up pass.
-
-## References
-
-- `core/index.md`

package/rules/core/layer-boundary.md

@@ -1,25 +0,0 @@
-# 分层边界规则
-
-## 默认做法
-
-- 上层不直接穿透下层。
-- 业务编排放在明确的服务层。
-- 数据访问层不写业务规则。
-
-## 禁区
-
-- 让控制层绕过服务层。
-- 让持久层承载业务编排。
-- 在一个层里混入多层职责。
-
-## 检查
-
-- 每个变更是否只有一个主要职责。
-
-## 回放信号
-
-- 只要出现“分层”“穿透”“越层”，就应该读这里。
-
-## References
-
-- `core/index.md`

package/rules/core/logging.md

@@ -1,26 +0,0 @@
-# 日志规则
-
-## 默认做法
-
-- 关键路径要留日志。
-- 错误要有上下文。
-- 日志不要泄漏敏感信息。
-
-## 禁区
-
-- 打印密码、token、密钥。
-- 没有上下文的错误日志。
-- 过量噪声日志。
-
-## 检查
-
-- 关键操作是否可追踪。
-- 故障信息是否能直接定位。
-
-## 回放信号
-
-- 只要出现埋点、诊断、错误定位，就应该读这里。
-
-## References
-
-- `core/index.md`

package/rules/core/security.md

@@ -1,26 +0,0 @@
-# 安全规则
-
-## 默认做法
-
-- 密钥、token、密码不能写进代码。
-- 外部输入必须校验。
-- 敏感输出必须脱敏。
-
-## 禁区
-
-- 明文配置凭证。
-- 把安全检查留到上线后。
-- 忽略租户和权限边界。
-
-## 检查
-
-- 是否存在凭证泄漏。
-- 是否存在越权或数据外泄。
-
-## 回放信号
-
-- 只要出现认证、授权、密钥、敏感数据，就应该读这里。
-
-## References
-
-- `core/index.md`

package/rules/core/task-boundary.md

@@ -1,27 +0,0 @@
-# Task Boundary Rules
-
-## 默认做法
-
-- Restate the task in one sentence before expanding it.
-- Separate in-scope, out-of-scope, and assumptions.
-- Keep the current step small enough to finish cleanly.
-
-## 禁区
-
-- Do not silently widen the task.
-- Do not skip boundary confirmation when the request is ambiguous.
-- Do not continue after the stop condition is met.
-
-## 检查
-
-- Is the task boundary explicit?
-- Are the expected outputs visible?
-- Is the stop condition clear?
-
-## 回放信号
-
-- Trigger when the request is ambiguous, broad, or likely to drift.
-
-## References
-
-- `core/index.md`

package/rules/docs/api.md

@@ -1,34 +0,0 @@
-# API Docs Rules
-
-## 默认做法
-
-- Use this file to choose between `contract`, `examples`, and `reference`.
-- Route stable behavior and caller guarantees to `contract`.
-- Route walkthrough-style usage to `examples` only when the example adds value.
-- Route reusable background material to `reference` when it is not a usage guide.
-- If a request mixes all three, split the answer and name the owner of each part.
-- Prefer the smallest doc that can answer the request without repeating the full API surface.
-
-## 禁区
-
-- Do not repeat the full contract when `contract` already owns it.
-- Do not turn API docs into implementation notes.
-- Do not invent behavior that the code does not support.
-- Do not let examples become the source of truth.
-- Do not hide breaking changes inside a reference page.
-
-## 检查
-
-- Is the task about API docs routing, not the full write-up?
-- Should the answer come from contract, examples, or reference?
-- Are examples still aligned with the real behavior?
-- Would a reader know which file owns the final answer after reading this entry?
-- Is the output split cleanly when the request spans more than one doc type?
-
-## 回放信号
-
-- Trigger when the task is about API reference docs or contract explanation.
-
-## References
-
-- `docs/index.md`

package/rules/docs/capture-summary.md

@@ -1,29 +0,0 @@
-# Docs Capture Summary Rules
-
-## 默认做法
-
-- Capture the minimal summary needed for future reuse.
-- Link the summary to the originating artifact and the key decision.
-- Keep the summary short enough to scan quickly.
-- Use it when the next stage needs only the essence, not the full note.
-
-## 禁区
-
-- Do not recreate the whole discussion.
-- Do not mix stable reference content into the capture summary.
-- Do not expand the summary into a new decision log entry.
-
-## 检查
-
-- Can another skill reuse the summary without rereading the conversation?
-- Is the origin artifact linked?
-- Is the summary small enough to fit into a handoff note?
-
-## 回放信号
-
-- Trigger when the task is about a handoff summary or short reusable capture.
-
-## References
-
-- `docs/index.md`
-- `docs/capture.md`

package/rules/docs/capture.md

@@ -1,34 +0,0 @@
-# Knowledge Capture Rules
-
-## 默认做法
-
-- Capture the minimum decisions, constraints, and handoff notes needed downstream.
-- Normalize the content so later work can reuse it.
-- Keep the capture focused on what the next actor needs, not the full discussion.
-- Prefer compact notes that can be copied into the next stage without cleanup.
-- Route the note into the correct knowledge layer: requirements knowledge, realtime code knowledge, CodeWiki, or enterprise knowledge.
-
-## 禁区
-
-- Do not re-run upstream analysis.
-- Do not generate new requirements or code while capturing.
-- Do not mix in long-lived reference content.
-- Do not turn capture into a reference page or decision archive.
-- Do not merge different knowledge layers into one blob.
-
-## 检查
-
-- Can another skill reuse the note without rereading the whole conversation?
-- Is the note concise and linked to its source?
-- Does it stay short enough to hand off without cleanup?
-- Does it avoid restating background that the next stage does not need?
-- Is the target knowledge layer explicit?
-
-## 回放信号
-
-- Trigger when the request is about summaries, decision logs, or reusable handoff notes.
-
-## References
-
-- `docs/index.md`
-- `docs/capture-summary.md`

package/rules/docs/contract.md

@@ -1,30 +0,0 @@
-# Docs Contract Rules
-
-## 默认做法
-
-- Document the stable behavior, inputs, outputs, and constraints.
-- Keep the contract independent of walkthrough style.
-- Preserve the source of truth for callers.
-- Treat the contract as the canonical answer for usage-facing behavior.
-- Make the contract testable, precise, and version-aware.
-
-## 禁区
-
-- Do not smuggle implementation detail into the contract.
-- Do not make the contract depend on one-off examples.
-- Do not move time-bound decisions into the contract.
-
-## 检查
-
-- Is the contract stable enough to survive code changes?
-- Can callers rely on it without reading examples?
-- Would a breaking change be visible here first?
-- Could a test or consumer validate the statement directly?
-
-## 回放信号
-
-- Trigger when the task is about stable API or interface behavior.
-
-## References
-
-- `docs/index.md`

package/rules/docs/decision-log.md

@@ -1,32 +0,0 @@
-# Docs Decision Log Rules
-
-## 默认做法
-
-- Record a decision, the reason for it, and the date or context.
-- Keep each entry concise and searchable.
-- Link each entry to the artifact or change it affects.
-- Keep decision logs separate from stable reference pages and captures.
-- Use one entry per decision when possible.
-
-## 禁区
-
-- Do not rewrite the whole history.
-- Do not mix stable reference content into the decision log.
-- Do not turn the decision log into a reference manual.
-- Do not store reusable contract content here.
-
-## 检查
-
-- Is the decision explicit?
-- Is the rationale concise and tied to the affected artifact?
-- Is the entry clearly time-bound?
-- Would a later reader know why the decision was made without inferring extra context?
-- Can the decision be located quickly by artifact or date?
-
-## 回放信号
-
-- Trigger when the task is about capture, decision history, or a durable rationale note.
-
-## References
-
-- `docs/index.md`

package/rules/docs/examples.md

@@ -1,28 +0,0 @@
-# Docs Examples Rules
-
-## 默认做法
-
-- Provide small examples that demonstrate the contract.
-- Keep examples aligned with the current behavior.
-- Prefer examples that help readers understand common use.
-- Keep examples subordinate to the contract, not parallel to it.
-
-## 禁区
-
-- Do not let examples drift into hidden requirements.
-- Do not use examples to redefine the contract.
-- Do not mix example content with policy or decision history.
-
-## 检查
-
-- Do examples match the contract?
-- Are they small and representative?
-- Can the example be updated without rewriting the rule?
-
-## 回放信号
-
-- Trigger when the task is about usage samples, snippets, or walkthrough examples.
-
-## References
-
-- `docs/index.md`