@pigcloud/skills 1.0.11 → 1.1.2

package/rules/review/evidence.md

@@ -1,31 +0,0 @@
-# Review Evidence Rules
-
-## 默认做法
-
-- Tie every finding to a file, location, behavior, or observable output.
-- State why the issue matters and how to verify the fix.
-- Mark uncertainty instead of overstating it.
-- Prefer logs, tests, diffs, or reproducible output over inference.
-- If the proof is indirect, say what would make it direct.
-- Keep the evidence short enough to cite in the review itself.
-
-## 禁区
-
-- Do not use vague concerns as findings.
-- Do not claim a risk without showing the source.
-- Do not bury the proof in narrative that cannot be checked.
-
-## 检查
-
-- Can another reviewer confirm the finding from the evidence?
-- Is the proof close to the code path?
-- Would the evidence still make sense if the reporter were unavailable?
-- Does the evidence support the recommendation without extra interpretation?
-
-## 回放信号
-
-- Trigger when the review needs stronger proof, reproducibility, or traceability.
-
-## References
-
-- `review/index.md`

package/rules/review/index.md

@@ -1,50 +0,0 @@
-# Review Rules
-
-`review/` is the review entry point for correctness, security, performance, and stack-specific review guidance.
-
-## 默认做法
-
-- Inspect the submitted change, not the whole repo.
-- Produce concrete findings that are verifiable, actionable, and tied to the diff.
-- Keep each finding anchored to one file, one issue, and one fix path.
-- Include evidence, impact, and recommendation in the review output.
-- If evidence is weak, route the task to `evidence` before filing a finding.
-
-## 禁区
-
-- Do not rewrite the implementation during review.
-- Do not turn review into a new design discussion.
-- Do not file findings without proof.
-- Do not stretch the generic profile into a stack-specific baseline.
-
-## 检查
-
-- Are findings concrete?
-- Is the fix path small enough to act on?
-- Should the report move to `code`, `code-java`, `code-vue`, `code-ts`, `security`, or `performance`?
-- Is the finding specific enough to reproduce from the diff?
-- Does the finding include the smallest reproducible proof?
-
-## 回放信号
-
-- Trigger when the request is about diff review, risk review, or a quality gate.
-
-## References
-
-- `review/code.md`
-- `review/java.md`
-- `review/vue.md`
-- `review/ts.md`
-- `review/security.md`
-- `review/performance.md`
-- `review/rubric.md`
-- `review/evidence.md`
-
-## 选择
-
-- `code` is the generic review profile.
-- `code-java` is the Java / Spring / MyBatis / Pig Cloud review overlay.
-- `code-vue` is the Vue 3 / frontend review overlay.
-- `code-ts` is the TypeScript / frontend utility review overlay.
-- `security` stays focused on auth, secrets, and data exposure.
-- `performance` stays focused on latency, throughput, and resource usage.

package/rules/review/java.md

@@ -1,42 +0,0 @@
-# Java Review Rules
-
-## 默认做法
-
-- Apply this profile after `review/code.md` when the repository uses Java, Spring, MyBatis, and the Pig Cloud style baseline.
-- Use this profile to check the Java-specific contracts that generic review should not own.
-- Keep the profile focused on framework conventions, layer boundaries, and persistence behavior.
-- If a different stack appears later, add a new stack profile instead of broadening this one.
-
-## 禁区
-
-- Do not use this profile for non-Java syntax or non-Java framework conventions.
-- Do not move generic review logic here.
-- Do not turn this profile into a second copy of `review/code.md`.
-
-## 检查
-
-- Controller should call Service, not Mapper.
-- REST responses should use the unified `Result<T>` wrapper.
-- Entities should follow the project delete-base and primary-key conventions.
-- Write endpoints should use validation annotations consistently.
-- Service-layer transactions should cover multi-write operations.
-- MyBatis query code should prefer lambda-style field access.
-- Mapper XML should avoid injection-prone `${}` usage unless the value is fully safe and justified.
-
-## 回放信号
-
-- Trigger when the diff touches Java controllers, services, entities, mappers, DTO / VO types, or MyBatis XML.
-- Trigger when the task references the Pig Cloud application framework conventions.
-
-## References
-
-- `review/code.md`
-- `../overlays/pig-cloud.md`
-- `../overlays/pig-cloud/controller.md`
-- `../overlays/pig-cloud/service.md`
-- `../overlays/pig-cloud/mapper.md`
-- `../overlays/pig-cloud/entity.md`
-- `../overlays/pig-cloud/rest-response.md`
-- `../overlays/pig-cloud/validation.md`
-- `../overlays/pig-cloud/query-style.md`
-- `../overlays/pig-cloud/transactions.md`

package/rules/review/performance.md

@@ -1,38 +0,0 @@
-# Performance Review Rules
-
-## 默认做法
-
-- Check hotspots, unnecessary work, and scalability risks.
-- Keep findings tied to observable behavior or code paths.
-- Separate constant-factor waste from algorithmic or I/O bottlenecks.
-- State the expected impact only when the evidence supports it.
-- Mention whether the issue is CPU, memory, network, database, or allocation pressure.
-- Prefer a concrete slower path over a vague "this may be slow" statement.
-
-## 禁区
-
-- Do not guess about performance without evidence.
-- Do not turn the review into a redesign discussion.
-- Do not claim a hotspot without identifying the path that repeats or expands.
-
-## 检查
-
-- Is the bottleneck credible?
-- Is the improvement path practical?
-- Can the reported issue be observed without speculative load assumptions?
-- Can a maintainer reproduce the concern from the code path alone?
-
-## Output Shapes
-
-- Use `location`, `bottleneck type`, `evidence`, `expected impact`, and `optimization advice`.
-- Anchor to one query, cache path, allocation path, concurrency path, or hot loop.
-- State whether the pressure is CPU, memory, network, database, or allocation-related.
-- If the bottleneck is inferred, say what measurement would confirm it.
-
-## 回放信号
-
-- Trigger when the request mentions latency, throughput, load, or resource usage.
-
-## References
-
-- `review/index.md`

package/rules/review/rubric.md

@@ -1,28 +0,0 @@
-# Review Rubric Rules
-
-## 默认做法
-
-- Score findings by impact, likelihood, and blast radius.
-- Keep each finding focused on one issue.
-- Prefer a clear severity band over vague language.
-- Treat reproducibility and user impact as part of the score.
-
-## 禁区
-
-- Do not merge unrelated issues into one finding.
-- Do not bury severity under explanation.
-
-## 检查
-
-- Does each finding have a clear severity?
-- Is the recommendation actionable?
-- Does the rubric separate severity from the report narrative?
-- Can the score be explained in one sentence with evidence?
-
-## 回放信号
-
-- Trigger when a review report needs ranked findings rather than a simple pass/fail.
-
-## References
-
-- `review/index.md`

package/rules/review/security.md

@@ -1,38 +0,0 @@
-# Security Review Rules
-
-## 默认做法
-
-- Check authentication, authorization, secrets, and data exposure.
-- Keep findings evidence-based.
-- Prefer the smallest proof that demonstrates the exposure or bypass.
-- Name the violated trust boundary when it is clear.
-- State the attack path, impacted asset, and the minimum change needed to close it.
-- Prefer the weakest permission, token, or input that proves the issue.
-
-## 禁区
-
-- Do not assume a vulnerability without proof.
-- Do not rewrite the implementation while reviewing.
-- Do not report a generic security smell as a confirmed flaw.
-
-## 检查
-
-- Is the risk real and specific?
-- Is the fix path small and safe?
-- Could the issue be reproduced from the reported evidence?
-- Can the reader see why the trust boundary breaks?
-
-## Output Shapes
-
-- Use `location`, `risk level`, `attack path`, `impacted asset`, `evidence`, and `mitigation advice`.
-- Anchor to one endpoint, auth flow, permission boundary, secret path, or exposure path.
-- State the violated trust boundary when it is clear.
-- If the proof is indirect, say what direct evidence is still missing.
-
-## 回放信号
-
-- Trigger when the request mentions secrets, auth, privilege, or data leakage.
-
-## References
-
-- `review/index.md`

package/rules/review/ts.md

@@ -1,33 +0,0 @@
-# TypeScript Review Rules
-
-## 默认做法
-
-- Apply this overlay when the diff touches TypeScript source, typed frontend state modules, or TS build/config files.
-- Use this overlay to check type boundaries, module boundaries, async control flow, and shared utility correctness.
-- Keep the overlay focused on TypeScript-specific conventions. Do not move generic review logic here.
-- If the diff also touches Vue files, this overlay should stack with the Vue overlay, not replace it.
-
-## 禁区
-
-- Do not use this overlay for plain JavaScript-only backend files.
-- Do not turn this overlay into a second generic review file.
-- Do not let type concerns hide data-flow, lifecycle, or API-contract issues.
-
-## 检查
-
-- Types should encode real domain intent, not incidental implementation detail.
-- Public interfaces should avoid unnecessary `any` and unsafe narrowing.
-- Async functions should handle error and cancellation paths explicitly.
-- Shared utilities should be deterministic and side-effect aware.
-- State modules should keep mutation and derived state separated.
-- Build/config files should stay aligned with the actual TypeScript entrypoints.
-
-## 回放信号
-
-- Trigger when the diff touches `.ts`, `.tsx`, `.d.ts`, `tsconfig*.json`, or TypeScript build configuration.
-- Trigger when the task references TypeScript, typed state, or frontend utility review.
-
-## References
-
-- `review/code.md`
-- `review/index.md`

package/rules/review/vue.md

@@ -1,33 +0,0 @@
-# Vue Review Rules
-
-## 默认做法
-
-- Apply this overlay when the diff touches Vue 3, frontend components, or the frontend build layer.
-- Use this overlay to check component boundaries, reactivity usage, template correctness, and state flow.
-- Keep the overlay focused on Vue-specific conventions. Do not move generic review logic here.
-- If the diff also touches backend code, this overlay should stack with the Java overlay, not replace it.
-
-## 禁区
-
-- Do not use this overlay for backend-only files.
-- Do not turn this overlay into a second generic review file.
-- Do not let component style concerns hide correctness or data-flow issues.
-
-## 检查
-
-- Component props and emits should be explicit and stable.
-- `v-for` should use stable keys.
-- Computed state should not be replaced by ad hoc duplication.
-- Watchers and effects should have a clear trigger and cleanup path.
-- Async UI behavior should handle loading, empty, and error states.
-- Shared state should live in the right layer, not inside random components.
-
-## 回放信号
-
-- Trigger when the diff touches `.vue` files, Vue components, frontend state modules, or Vue-specific build configuration.
-- Trigger when the task references Vue 3, Composition API, Pinia, or frontend component review.
-
-## References
-
-- `review/code.md`
-- `review/index.md`

package/rules/skill-profile-map.json

@@ -1,59 +0,0 @@
-{
-  "workflow-router": {
-    "bundle": "workflow",
-    "profile": "router"
-  },
-  "spec-refinement": {
-    "bundle": "workflow",
-    "profile": "refinement"
-  },
-  "technical-design": {
-    "bundle": "coding",
-    "profile": "analysis"
-  },
-  "feature-build": {
-    "bundle": "coding",
-    "profile": "implementation"
-  },
-  "test-design": {
-    "bundle": "coding",
-    "profile": "testing"
-  },
-  "code-review": {
-    "bundle": "review",
-    "profile": "code"
-  },
-  "domain-modeling": {
-    "bundle": "product",
-    "profile": "modeling"
-  },
-  "business-fact-extraction": {
-    "bundle": "product",
-    "profile": "modeling"
-  },
-  "api-contract-docs": {
-    "bundle": "docs",
-    "profile": "api"
-  },
-  "security-audit": {
-    "bundle": "review",
-    "profile": "security"
-  },
-  "performance-audit": {
-    "bundle": "review",
-    "profile": "performance"
-  },
-  "knowledge-capture": {
-    "bundle": "docs",
-    "profile": "capture"
-  },
-  "project-bootstrap": {
-    "bundle": "coding",
-    "profile": "scaffold"
-  },
-  "environment-deploy": {
-    "bundle": "coding",
-    "profile": "scaffold"
-  }
-}
-

package/rules/skill-profile-map.md

@@ -1,29 +0,0 @@
-# Rule Profile Map
-
-This file explains which canonical skill loads which rules bundle and profile.
-
-## Mapping
-
-| Skill | Bundle | Profile |
-|---|---|---|
-| `workflow-router` | `workflow` | `router` |
-| `spec-refinement` | `workflow` | `refinement` |
-| `technical-design` | `coding` | `analysis` |
-| `feature-build` | `coding` | `implementation` |
-| `test-design` | `coding` | `testing` |
-| `code-review` | `review` | `code` |
-| `domain-modeling` | `product` | `modeling` |
-| `business-fact-extraction` | `product` | `modeling` |
-| `api-contract-docs` | `docs` | `api` |
-| `security-audit` | `review` | `security` |
-| `performance-audit` | `review` | `performance` |
-| `knowledge-capture` | `docs` | `capture` |
-| `project-bootstrap` | `coding` | `scaffold` |
-| `environment-deploy` | `coding` | `scaffold` |
-
-## Notes
-
-- `rule_profile` in skill frontmatter is the source of truth.
-- `skill-profile-map.json` is kept as a validation and routing fallback.
-- `code-review` intentionally uses the generic `code` profile in this repository. Stack-specific review behavior is added by overlays.
-

package/rules/workflow/handoff.md

@@ -1,25 +0,0 @@
-# Workflow Handoff Rules
-
-## 默认做法
-
-- Capture the current stage outcome and the next owner.
-- Keep the transfer note short and specific.
-- Link the handoff to the artifact that was just produced.
-
-## 禁区
-
-- Do not re-open completed upstream work.
-- Do not start the next stage inside the handoff note.
-
-## 检查
-
-- Is the next owner clear?
-- Is the artifact ready to reuse?
-
-## 回放信号
-
-- Trigger when the request is about transfer, wrap-up, or stage transition.
-
-## References
-
-- `workflow/index.md`

package/rules/workflow/index.md

@@ -1,37 +0,0 @@
-# Workflow Rules
-
-`workflow/` contains collaboration and handoff rules. It decides how a task moves between stages.
-
-## 默认做法
-
-- Route first, work second.
-- Keep handoff boundaries explicit.
-- Stop when the current stage has produced its expected artifact.
-- Pick the smallest workflow step that can safely move the task forward.
-
-## 禁区
-
-- Do not let workflow rules turn into implementation rules.
-- Do not let a routing file contain long task explanations.
-- Do not skip the stop boundary.
-- Do not skip the stage decision when the input is ambiguous.
-
-## 检查
-
-- Is the current stage clear?
-- Is the next stage and handoff target clear?
-- Is the artifact ready for the next skill?
-- Is the current step ending cleanly?
-
-## 回放信号
-
-- Use this bundle when the input is still ambiguous or the task is mainly about stage selection.
-- Use this bundle when a request must be narrowed before product, coding, docs, or review work starts.
-
-## References
-
-- `workflow/router.md`
-- `workflow/refinement.md`
-- `workflow/handoff.md`
-- `workflow/selection.md`
-- `workflow/stop.md`

package/rules/workflow/refinement.md

@@ -1,29 +0,0 @@
-# Workflow Refinement Rules
-
-## 默认做法
-
-- Turn rough input into a clear brief or scope note.
-- Clarify boundaries, assumptions, and missing inputs.
-- Stop before implementation detail.
-- Capture unresolved questions as explicit follow-up items.
-- Preserve decisions that the next stage must not reopen.
-
-## 禁区
-
-- Do not write code.
-- Do not turn refinement into product discovery from scratch.
-- Do not leave unresolved scope drift in the output.
-
-## 检查
-
-- Is the scope clear enough for the next stage?
-- Are assumptions and open questions explicit?
-- Can the next stage start without re-interpreting the request?
-
-## 回放信号
-
-- Trigger when the request needs narrowing before product, coding, or review work starts.
-
-## References
-
-- `workflow/index.md`

package/rules/workflow/router.md

@@ -1,25 +0,0 @@
-# Workflow Router Rules
-
-## 默认做法
-
-- Identify the next stage and the next skill.
-- Return a minimal handoff note.
-- Do not do the target skill's work.
-
-## 禁区
-
-- Do not start analysis, coding, or review work.
-- Do not add rule details to routing output.
-
-## 检查
-
-- Is the next skill unambiguous?
-- Is the handoff note minimal and actionable?
-
-## 回放信号
-
-- Trigger when the request only needs stage selection or handoff routing.
-
-## References
-
-- `workflow/index.md`

package/rules/workflow/selection.md

@@ -1,25 +0,0 @@
-# Workflow Selection Rules
-
-## 默认做法
-
-- Decide the next skill based on the current artifact, not the final desired outcome.
-- Prefer the earliest stage that can safely absorb the input.
-- If the stage is unclear, choose routing over execution.
-
-## 禁区
-
-- Do not skip to implementation when the input is still vague.
-- Do not choose a deeper stage just because it is more convenient.
-
-## 检查
-
-- Is the next stage the smallest safe step?
-- Is the reason for selection visible?
-
-## 回放信号
-
-- Trigger when the request is asking "what should happen next" or "where should this go".
-
-## References
-
-- `workflow/index.md`

package/rules/workflow/stop.md

@@ -1,25 +0,0 @@
-# Workflow Stop Rules
-
-## 默认做法
-
-- Stop as soon as the current stage has produced its expected artifact.
-- Preserve a clean handoff note for the next owner.
-- Do not carry next-stage work into the current stage.
-
-## 禁区
-
-- Do not keep refining past the stage boundary.
-- Do not smuggle implementation work into a routing or handoff task.
-
-## 检查
-
-- Is the artifact complete for this stage?
-- Is the next stage ready to take over?
-
-## 回放信号
-
-- Trigger when a stage boundary, handoff, or stop condition needs to be enforced.
-
-## References
-
-- `workflow/index.md`

package/skills/api-contract-docs/SKILL.md

@@ -1,77 +0,0 @@
----
-name: api-contract-docs
-description: 当接口需要可复用参考文档时，记录稳定的 API 行为、请求、响应契约和示例
-lifecycle_stage: capture
-rule_profile: api
-dependencies:
-  - spec-refinement
-triggers:
-  - API docs
-  - contract
-  - endpoint
-  - request response
-  - OpenAPI
-  - API reference
-inputs:
-  - interface behavior
-  - endpoint list
-  - request and response shapes
-outputs:
-  - API document
-  - contract notes
-  - examples
-workflow:
-  - extract endpoint behavior
-  - write request and response contracts
-  - include examples and constraints
-  - hand off an API document to knowledge-capture
-gates:
-  - stop at documentation
-  - do not change implementation
-  - do not rewrite product scope
-refs:
-  - skills/references/rule-loading-map.md
-  - skills/references/prompt-replay-checklist.md
-  - skills/references/full-chain-replay-scenarios.md
-  - rules/index.md
----
-
-# API Contract Docs
-
-## Purpose
-
-Write clear API documentation and contracts for already defined behavior.
-
-## Suitable / Unsuitable
-
-- Suitable: endpoint docs, request/response contracts, examples, API notes
-- Unsuitable: implementation changes, product scope changes, rewrite of behavior
-
-## Workflow
-
-1. Extract endpoint behavior.
-2. Write request and response contracts.
-3. Include examples and constraints.
-4. Hand off an API document to `knowledge-capture`.
-
-## Replay Signals
-
-- Input signal: interface behavior, endpoint list, request and response shapes.
-- Output to verify: API document, contract notes, examples.
-- Stop signal: implementation changes or product scope changes.
-- Handoff signal: an API document is ready for `knowledge-capture`.
-
-## Stop Rules
-
-- Stop at documentation.
-- Do not change implementation.
-- Do not rewrite product scope.
-- Do not turn the task into implementation notes.
-
-## References
-
-- `skills/references/rule-loading-map.md`
-- `skills/references/prompt-replay-checklist.md`
-- `skills/references/full-chain-replay-scenarios.md`
-- `rules/index.md`
-