@pigcloud/skills 1.0.3 → 1.0.5

package/pig-cloud-skills-commands/commands/perf.md

@@ -1,20 +0,0 @@
-# /perf
-
-检查性能热点、瓶颈和回归风险。
-
-## Route
-
-- 对应 skill：`performance-check`
-- 适用：N+1、缓存、索引、批量操作、热点路径
-- 不适用：纯安全审查或纯需求讨论
-
-## Workflow
-
-1. 找出高频路径和大数据量路径。
-2. 检查数据库访问、缓存命中、循环调用和批处理。
-3. 输出可验证的性能风险和优化顺序。
-4. 必要时交给 `code-review` 或 `feature-build`。
-
-## Guardrails
-
-- 不用泛泛建议替代定位结论。

package/pig-cloud-skills-commands/commands/prd.md

@@ -1,21 +0,0 @@
-# /prd
-
-把产品意图收口成给研发分析使用的需求输入。
-
-## Route
-
-- 对应 skill：`product-intake`
-- 适用：产品目标、业务背景、范围裁剪、优先级、验收口径、需求初稿
-- 不适用：已经进入实现细节的研发分析
-
-## Workflow
-
-1. 先确认这是产品侧需求，不直接进入设计或编码。
-2. 收集目标、范围、约束、优先级和验收标准。
-3. 输出结构化的 PRD-ready brief。
-4. 交给 `spec-refinement`。
-
-## Guardrails
-
-- 不替代研发需求分析。
-- 不跳过需求收口直接写最终结论。

package/pig-cloud-skills-commands/commands/review.md

@@ -1,21 +0,0 @@
-# /review
-
-审查代码变更、质量风险和跨模块影响。
-
-## Route
-
-- 对应 skill：`code-review`
-- 适用：PR 审查、diff 审核、上线前检查、框架规范核对
-- 不适用：纯需求讨论
-
-## Workflow
-
-1. 先确认变更范围，不只看单文件。
-2. 核对架构、边界、回归风险和约束。
-3. 输出问题级别、风险和修复建议。
-4. 必要时补 `security-review` 或 `performance-check`。
-
-## Guardrails
-
-- 只审查已经发生的变更。
-- 不跳过证据直接下结论。

package/pig-cloud-skills-commands/commands/security.md

@@ -1,21 +0,0 @@
-# /security
-
-审查安全风险、权限边界和敏感数据暴露。
-
-## Route
-
-- 对应 skill：`security-review`
-- 适用：安全审查、权限检查、数据暴露检查、合规风险检查
-- 不适用：普通需求讨论
-
-## Workflow
-
-1. 先确认输入是已经发生的变更或可检查的方案。
-2. 拆分接口、权限、数据流向和敏感信息风险。
-3. 输出安全发现、优先级和修复建议。
-4. 必要时交给 `knowledge-capture` 或 `feature-build`。
-
-## Guardrails
-
-- 不直接修改生产代码。
-- 不把一般质量问题误判成安全结论。

package/pig-cloud-skills-commands/commands/test.md

@@ -1,21 +0,0 @@
-# /test
-
-把验收标准转成可执行的测试设计。
-
-## Route
-
-- 对应 skill：`test-design`
-- 适用：测试策略、用例设计、回归矩阵、验证路径
-- 不适用：需求还不明确，或者只是想“快速跑一下”
-
-## Workflow
-
-1. 先确认验收标准或实现结果。
-2. 转成测试策略、用例、回归和边界场景。
-3. 输出可执行的验证方案。
-4. 必要时交给 `code-review` 或 `feature-build`。
-
-## Guardrails
-
-- 不跳过前置条件。
-- 不把“跑过一次”当作完整验证。

package/pig-cloud-skills-commands/commands/workflow.md

@@ -1,20 +0,0 @@
-# /workflow
-
-按阶段路由到正确的 skill，并控制阶段切换。
-
-## Route
-
-- 适用：多阶段任务、跨 skill 协作、门禁控制、阶段切换
-- 不适用：单一步骤的小任务
-
-## Workflow
-
-1. 判断当前处于哪个生命周期阶段。
-2. 选择当前 skill 或下一步 skill。
-3. 如果门禁失败，暂停下游并说明原因。
-4. 记录下一步应该走哪个 skill。
-
-## Guardrails
-
-- 不替用户决定跳过阶段。
-- 不让下游覆盖上游未确认结果。

package/skills/product-intake/SKILL.md

@@ -1,98 +0,0 @@
----
-name: product-intake
-description: 捕捉产品意图，并将其与项目事实、原型和当前实现事实分离，形成可进入 PRD 的简报，适用于目标、范围或优先级仍不清晰时
-lifecycle_stage: intake
-rule_profile: intake
-dependencies: []
-triggers:
-  - business goal
-  - user need
-  - PRD
-  - scope
-  - priority
-  - problem framing
-inputs:
-  - business goals
-  - user feedback
-  - meeting notes
-  - release context
-  - prototype notes
-  - current implementation facts
-outputs:
-  - brief
-  - scope
-  - acceptance outline
-  - current project facts
-  - prototype notes
-  - implementation facts
-  - open questions
-workflow:
-  - confirm the problem and desired outcome
-  - separate in-scope and out-of-scope
-  - capture current project facts, prototypes, and implementation facts separately from product intent
-  - capture acceptance criteria and open questions
-  - hand off a PRD-ready brief plus project facts, prototype notes, implementation facts, and open questions to spec-refinement
-gates:
-  - stop at product-level framing
-  - do not write implementation details
-  - do not choose rule bundles
-  - do not produce code-oriented specs
-refs:
-  - skills/references/requirements-separation-map.md
-  - skills/references/project-requirement-alignment.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
-  - skills/spec-refinement/SKILL.md
----
-
-# Product Intake
-
-## Purpose
-
-Turn business input into a PRD-ready brief. This skill ends when the product intent is clear enough for engineering refinement.
-
-## Suitable / Unsuitable
-
-- Suitable: goals, user pain points, scope, priority, release intent, meeting notes, product context, prototypes, current implementation facts
-- Unsuitable: implementation details, rule choice, coding tasks, test design, code review
-
-## Workflow
-
-1. Confirm the problem, target user, and expected outcome.
-2. Separate in-scope, out-of-scope, and assumptions.
-3. Capture current project facts, prototypes, and implementation facts separately from product intent.
-4. Write acceptance criteria and open questions.
-5. Hand off a PRD-ready brief plus project facts, prototypes, and implementation facts to `spec-refinement`.
-6. Stop before implementation analysis or rule selection.
-
-## Replay Signals
-
-- Input signal: business goal, user pain point, release intent, or meeting notes.
-- Output to verify: product objective, scope, acceptance outline, current project facts, prototype notes, implementation facts, open questions, assumptions.
-- Stop signal: any implementation detail, architecture choice, or rule.
-- Handoff signal: a PRD-ready brief is ready for `spec-refinement`.
-
-## Examples
-
-- Input: "We need a login reminder feature for inactive users."
-- Output: PRD-ready brief, scope, acceptance outline, current project facts, open questions
-- Stop: do not decide implementation details or rule bundles
-
-## Stop Rules
-
-- Stop at product-level framing.
-- Do not write implementation details.
-- Do not write technical design.
-- Do not choose rule bundles.
-- Do not invent technical constraints.
-- Do not generate code-level specs.
-- Do not produce code-oriented specs.
-
-## References
-
-- `skills/references/requirements-separation-map.md`
-- `skills/references/rule-loading-map.md`
-- `skills/references/flow-test-cases.md`
-- `skills/spec-refinement/SKILL.md`

package/skills/references/agent-personas.md

@@ -1,34 +0,0 @@
-# 角色画像
-
-这个文档定义的是面向审查的角色，以及它们对应的 canonical skill。
-
-## 角色映射
-
-| 角色 | 主要 skill | 审查重点 | 输出 |
-|---|---|---|---|
-| 代码审查者 | `code-review` | 分层、命名、可维护性 | 审查报告 |
-| 安全审查者 | `security-review` | 注入、密钥、授权 | 安全报告 |
-| 性能审查者 | `performance-check` | N+1、缓存、延迟、内存 | 性能报告 |
-| 架构审查者 | `spec-refinement` | 边界检查、模块拆分、依赖方向 | 设计补充 |
-| 测试审查者 | `test-design` | 覆盖率、边界场景、回归 | 测试报告 |
-
-## 触发关键词
-
-- `code-review`：review、diff、refactor、maintainability
-- `security-review`：security、injection、secret、permission
-- `performance-check`：performance、slow、cache、latency
-- `spec-refinement`：design、architecture、boundary、module split
-- `test-design`：test、coverage、regression、boundary case
-
-## 协作链路
-
-```text
-code-review -> security-review -> performance-check
-spec-refinement -> technical-design -> feature-build
-test-design -> code-review
-```
-
-## 输出规则
-
-- 每个角色只产出一个聚焦的工件。
-- 只有相关审查门禁都通过后，才合并结果。

package/skills/references/flow-test-cases.md

@@ -1,62 +0,0 @@
-# Flow Test Cases
-
-## Purpose
-
-Use these cases to check routing, stop boundaries, and handoffs across the whole skill chain.
-
-## Product Intake
-
-- Input: "We need a login reminder feature for inactive users."
-- Expected first skill: `product-intake`
-- Expected output: brief, scope, acceptance outline, current project facts, open questions
-- Stop: do not decide implementation details or rule bundles
-
-## Spec Refinement
-
-- Input: "The PRD is approved. Turn it into an executable spec with current facts."
-- Expected first skill: `spec-refinement`
-- Expected output: executable spec, execution direction plan, conflict map, acceptance criteria, task breakdown plan
-- Stop: do not rewrite the PRD or generate code
-
-## Simple Feature
-
-- Input: "This change is local and low risk. Take it from spec to code."
-- Expected chain: `spec-refinement -> feature-build -> test-design -> code-review -> knowledge-capture`
-- Expected output: code changes, self-test evidence, validation result, review findings, reusable note
-- Stop: do not expand the scope into a technical design task
-
-## Complex Change
-
-- Input: "This change touches multiple modules, cache, and compatibility. Design it first."
-- Expected first skill: `technical-design` after `spec-refinement`
-- Expected output: design decisions, dependency map, interface contract, rollback notes
-- Expected output: execution direction plan, design decisions, dependency map, interface contract, rollback notes
-- Stop: do not jump straight to `feature-build`
-
-## Implementation
-
-- Input: "The spec is confirmed. Implement controller, service, mapper, and local tests."
-- Expected first skill: `feature-build`
-- Expected output: code changes, implementation notes, self-test evidence
-- Stop: do not modify the spec
-
-## Validation
-
-- Input: "The implementation is done. Design validation coverage."
-- Expected first skill: `test-design`
-- Expected output: test strategy, regression matrix, validation result
-- Stop: do not modify production code
-
-## Review
-
-- Input: "Review this diff for correctness, maintainability, and risk."
-- Expected first skill: `code-review`
-- Expected output: findings, severity, fix recommendation, evidence summary
-- Stop: do not rewrite code
-
-## Knowledge Capture
-
-- Input: "Summarize the decisions, pitfalls, and reusable points."
-- Expected first skill: `knowledge-capture`
-- Expected output: reusable note, knowledge page, handoff summary, decision log entry
-- Stop: do not redo upstream analysis

package/skills/references/full-chain-replay-scenarios.md

@@ -1,79 +0,0 @@
-# 全链路回放场景
-
-## 目的
-
-用这些场景回放完整的产品到研发工作流，检查每个 skill 是否停在正确边界。
-
-## 场景一：简单产品需求
-
-- 提示词：“我们要给沉默用户做一个提醒功能。”
-- 期望首个 skill：`product-intake`
-- 期望产物：产品 brief、范围、验收轮廓、待确认项
-- stop rule：不要跳进设计或代码
-- 下一跳：`spec-refinement`
-
-- 提示词：“brief 已确认，帮我转成可执行规格。”
-- 期望首个 skill：`spec-refinement`
-- 期望产物：可执行规格、验收标准、影响范围、实现输入、任务计划
-- stop rule：不要重写 PRD，也不要直接写代码
-- 下一跳：如果范围复杂，则到 `technical-design`，否则到 `feature-build`
-
-- 提示词：“把确认后的规格按任务拆开，实现并对每个任务做本地自测。”
-- 期望首个 skill：`feature-build`
-- 期望产物：代码改动、实现说明、自测证据、任务级验证结果
-- stop rule：不要把多个任务混成一个实现步骤
-- 下一跳：`test-design`
-
-- 提示词：“设计测试覆盖并验证这个改动。”
-- 期望首个 skill：`test-design`
-- 期望产物：测试策略、用例、回归矩阵、验证结果、覆盖缺口
-- stop rule：不要修改生产代码
-- 下一跳：`code-review`
-
-- 提示词：“审查这个 diff 的正确性和安全性。”
-- 期望首个 skill：`code-review`
-- 期望产物：带严重级别的 findings 和修复建议
-- stop rule：不要在审查步骤里顺手重构代码
-- 下一跳：`knowledge-capture`
-
-- 提示词：“把这次任务里可复用的决策和坑点沉淀下来。”
-- 期望首个 skill：`knowledge-capture`
-- 期望产物：可复用笔记和交接摘要
-- stop rule：不要重新做上游分析
-
-## 场景二：复杂跨模块改动
-
-- 提示词：“这个改动影响多个模块、缓存行为和兼容性，先帮我做计划。”
-- 期望首个 skill：`spec-refinement`
-- 期望产物：影响范围和实现输入
-- stop rule：不要直接产出代码
-- 下一跳：`technical-design`
-
-- 提示词：“这个需求影响多个模块、缓存和兼容性，先把规格定出来。”
-- 期望首个 skill：`spec-refinement`
-- 期望产物：可执行规格、影响范围、实现输入
-- stop rule：不要从规格细化直接跳到实现
-- 下一跳：`technical-design`
-
-- 提示词：“设计模块边界、依赖关系和回退路径。”
-- 期望首个 skill：`technical-design`
-- 期望产物：设计决策、依赖图、接口契约、实现约束
-- stop rule：不要开始实现
-- 下一跳：`feature-build`
-
-- 提示词：“在选定的 rules bundle 下实现确认后的设计。”
-- 期望首个 skill：`feature-build`
-- 期望产物：代码改动、自测证据和验证证据
-- stop rule：不要重新开启产品发现
-- 下一跳：`test-design`
-
-## 场景三：负向回放
-
-- “这个 PRD 很小，直接写吧” 在 brief 不可执行时仍然应该先到 `spec-refinement`。
-- “先把测试写了，顺手把生产逻辑也改掉” 只有在纯验证工作里才停在 `test-design`，否则应先交给 `feature-build`。
-- “先改代码再审查” 如果 `code-review` 开始做实现工作，就应该判失败。
-
-## 评分说明
-
-- 好的回放会保持首个 skill 稳定，产出预期工件，并在下一阶段开始前停住。
-- 任何把实现泄漏到收口阶段，或者在实现/审查阶段重写需求的步骤，都应判失败。

package/skills/references/hooks.md

@@ -1,67 +0,0 @@
-# Hooks
-
-Hooks 负责协调 skill 执行和产物交接。
-
-## Hook 类型
-
-| Hook 类型 | 触发时机 | 用途 |
-|---|---|---|
-| `pre_invoke` | skill 运行前 | 检查前置条件 |
-| `post_invoke` | skill 运行后 | 更新状态和产物 |
-| `on_success` | skill 成功时 | 通知并触发下一步 |
-| `on_failure` | skill 失败时 | 记录问题并安全停止 |
-| `on_confirm` | 用户确认时 | 推进工作流状态 |
-| `on_reject` | 用户拒绝时 | 保持在当前阶段 |
-
-## canonical hook groups
-
-### product-intake
-
-- 确认产品输入存在
-- 收集目标、范围和待确认项
-- 写出产品产物
-- 在确认后触发 `spec-refinement`
-
-### spec-refinement
-
-- 确认产品产物已通过确认
-- 细化范围、边界和验收标准
-- 写出研发规格
-- 按需要触发 `technical-design` 或 `feature-build`
-
-### technical-design
-
-- 确认规格已经稳定到足够支持设计
-- 记录边界、依赖和接口决策
-
-### feature-build
-
-- 确认规格和当前选定的 rules bundle 都已准备好
-- 生成或更新代码
-- 实现完成后触发 `test-design`
-
-### test-design
-
-- 确认实现可用
-- 写出测试用例、验证步骤和缺陷笔记
-- 验证完成后触发 `code-review`
-
-### code-review
-
-- 确认变更集已经可以审查
-- 记录 findings、严重级别和后续事项
-- 变更通过后触发 `knowledge-capture`
-
-## 工作流状态
-
-- 跟踪当前阶段
-- 跟踪已确认阶段
-- 跟踪已产出工件
-- 把错误和重试状态与工作流链路分开
-
-## Hook 原则
-
-- 缺少前置条件就停止
-- 推进阶段前优先做显式确认
-- 输出要短小、机器可读
-- 不要把框架规则混进 hook 逻辑里

package/skills/references/negative-replay-scenarios.md

@@ -1,49 +0,0 @@
-# 负向回放场景
-
-## 目的
-
-专门验证 workflow 不会跳过阶段，也不会把 stop rule 写成“建议”。
-
-## 场景一：不能跳过规格细化
-
-- 提示词：“PRD 很小，直接帮我把代码写了。”
-- 期望首个 skill：`spec-refinement`
-- 期望停点：不能直接进 `feature-build`
-- 失败信号：`spec-refinement` 之后没有先形成可执行规格
-
-## 场景二：不能跳过技术设计
-
-- 提示词：“这个需求会改多个模块，先别设计，直接写。”
-- 期望首个 skill：`spec-refinement`
-- 期望下一跳：`technical-design`
-- 期望停点：不能直接进 `feature-build`
-- 失败信号：复杂场景直接进入编码
-
-## 场景三：复杂需求必须先设计
-
-- 提示词：“这个需求影响多个模块、缓存和兼容性，先帮我收口再直接实现。”
-- 期望首个 skill：`spec-refinement`
-- 期望下一跳：`technical-design`
-- 期望停点：不能从规格细化直接跳到 `feature-build`
-- 失败信号：`spec-refinement` 结束后没有进入 `technical-design`
-
-## 场景四：不能把测试当实现修补
-
-- 提示词：“我需要测试覆盖，顺手把生产代码也改了。”
-- 期望首个 skill：`test-design`
-- 期望停点：不能修改生产代码
-- 失败信号：测试阶段开始改实现
-
-## 场景五：不能把审查变成实现
-
-- 提示词：“先帮我审查这个 diff，再顺手把问题修掉。”
-- 期望首个 skill：`code-review`
-- 期望停点：不能在审查阶段改代码
-- 失败信号：`code-review` 输出里包含实现动作
-
-## 场景六：不能把沉淀变成重做分析
-
-- 提示词：“把这次工作总结一下，但先重新分析一遍问题。”
-- 期望首个 skill：`knowledge-capture`
-- 期望停点：不能重新做上游分析
-- 失败信号：`knowledge-capture` 开始重新定义需求或设计

package/skills/references/prompt-replay-checklist.md

@@ -1,128 +0,0 @@
-# 提示词回放清单
-
-## 目的
-
-用这份清单手工回放提示词，判断 workflow skill 是否能正确路由、正确停住、正确交接。
-
-## 评分方式
-
-对每个提示词检查：
-
-- 首个 skill 选择是否正确
-- 输出产物是否正确
-- stop rule 是否被遵守
-- 下一跳交接是否正确
-- 是否有额外工作泄漏到错误阶段
-
-### 评分标准
-
-- 2：完全正确
-- 1：部分正确，但还能恢复
-- 0：错误，或者泄漏到错误阶段
-
-### 通过门槛
-
-- 五项检查都要拿到 2，才算通过
-- 任何一项为 0，直接判失败
-
-## 产品类提示词
-
-- 提示词：“我们要给沉默用户做一个提醒功能，先帮我收口范围、优先级和验收。”
-- 期望首个 skill：`product-intake`
-- 期望产物：产品 brief
-- 应该停在实现细节之前
-
-- 提示词：“PRD 还不清楚，帮我先收集范围和验收。”
-- 期望首个 skill：`product-intake`
-- 期望产物：范围、验收轮廓、待确认项
-- 应该停在规格或代码之前
-
-## 规格类提示词
-
-- 提示词：“PRD 已确认，帮我把它转成可执行的研发规格。”
-- 期望首个 skill：`spec-refinement`
-- 期望产物：可执行规格
-- 应该停在代码生成之前
-
-- 提示词：“对比 PRD 和当前代码，找出需要改什么。”
-- 期望首个 skill：`spec-refinement`
-- 期望产物：影响范围和实现输入
-- 应该停在实现之前
-
-## 设计类提示词
-
-- 提示词：“这个改动影响多个模块和缓存层，先帮我设计边界。”
-- 期望首个 skill：`technical-design`
-- 期望产物：设计决策和依赖图
-- 应该停在直接实现之前
-
-- 提示词：“编码前我需要一个回退和兼容方案。”
-- 期望首个 skill：`technical-design`
-- 期望产物：可执行的方案笔记
-- 应该停在代码之前
-
-- 提示词：“这个需求会改多个模块和兼容性，先别写代码，直接推进实现。”
-- 期望首个 skill：`spec-refinement`
-- 期望产物：可执行规格和实现输入
-- 应该先进入 `technical-design`，不能跳到实现
-
-## 实现类提示词
-
-- 提示词：“规格已经确认，帮我实现 controller 和 service 的改动。”
-- 期望首个 skill：`feature-build`
-- 期望产物：代码改动
-- 应该停在重写规格之前
-
-- 提示词：“把本地代码改好，同时保持范围稳定。”
-- 期望首个 skill：`feature-build`
-- 期望产物：实现说明和验证证据
-- 应该停在需求变更之前
-
-## 验证类提示词
-
-- 提示词：“为实现后的改动设计测试并验证覆盖。”
-- 期望首个 skill：`test-design`
-- 期望产物：测试策略和回归矩阵
-- 应该停在生产代码修改之前
-
-- 提示词：“检查边界情况，告诉我这个能不能安全发布。”
-- 期望首个 skill：`test-design`
-- 期望产物：验证结果
-- 应该停在实现之前
-
-## 审查类提示词
-
-- 提示词：“帮我审查这个 diff 的正确性、安全性和可维护性。”
-- 期望首个 skill：`code-review`
-- 期望产物：带严重级别的 findings
-- 应该停在重构代码之前
-
-- 提示词：“找出这个改动里的安全问题或性能问题。”
-- 期望首个 skill：`code-review`，必要时再进专项审查
-- 期望产物：有优先级的 findings
-- 应该停在审查结论
-
-## 沉淀类提示词
-
-- 提示词：“把这次任务的决策、坑点和可复用要点总结一下。”
-- 期望首个 skill：`knowledge-capture`
-- 期望产物：可复用笔记和交接摘要
-- 应该停在重新分析之前
-
-## 评估标准
-
-- 首个 skill 正确
-- 产物正确
-- stop rule 正确
-- 交接正确
-- 没有跨阶段泄漏
-
-## 快速记分表
-
-| 检查项 | 2 | 1 | 0 |
-|---|---|---|---|
-| 首个 skill | 精确匹配 | 接近但可恢复 | 阶段错误 |
-| 产物 | 符合预期 | 基本正确 | 缺失或错误 |
-| stop rule | 停得正确 | 停得稍晚 | 继续推进 |
-| 交接 | 正确下一跳 | 方向对但弱 | 交接错误 |
-| 泄漏 | 没有 | 轻微 | 明显 |