@pigcloud/skills 1.0.10 → 1.1.2

package/skills/performance-audit/SKILL.md

@@ -1,118 +0,0 @@
----
-name: performance-audit
-description: 当需要性能结论时，对变更中的延迟、吞吐量或资源瓶颈进行审查
-rule_profile: performance
-dependencies:
-  - feature-build
-triggers:
-  - performance
-  - slow
-  - latency
-  - cache
-  - bottleneck
-  - slow path
-  - hotspot
-inputs:
-  - diff
-  - hotspots
-  - response timings
-outputs:
-  - performance findings
-  - bottleneck map
-  - optimization advice
-  - measured path summary
-  - review summary
-workflow:
-  - locate the expensive path
-  - inspect queries, cache, memory, and concurrency
-  - route correctness-only issues to `code-review`
-  - rank the bottlenecks by impact
-  - produce optimization advice
-gates:
-  - stop at performance findings
-  - do not rewrite code
-  - do not become a general review
-refs:
-  - skills/references/rule-loading-map.md
-  - skills/references/prompt-replay-checklist.md
-  - skills/references/full-chain-replay-scenarios.md
-  - rules/index.md
----
-
-# Performance Audit
-
-## Purpose
-
-Find performance bottlenecks and optimization opportunities.
-
-## Suitable / Unsuitable
-
-- Suitable: slow paths, latency, cache behavior, query cost, concurrency, measurable bottlenecks
-- Unsuitable: implementation work, broad code review, requirement discovery, generic correctness review
-
-## Quick Start
-
-- Identify the hottest path first.
-- Check queries, cache, memory, and concurrency in that order.
-- Return a bottleneck map plus optimization advice.
-- If the issue is only about correctness or maintainability, hand off to `code-review`.
-
-## Report Format
-
-- Use one entry per bottleneck.
-- Include `location`, `bottleneck type`, `evidence`, `expected impact`, and `optimization advice`.
-- Anchor each bottleneck to the smallest relevant performance surface:
-  - query, cache path, allocation path, concurrency path, or hot loop
-- Keep the bottleneck map explicit about CPU, memory, network, database, or allocation pressure.
-- Keep the review summary short when no performance issue is present.
-- If there are no findings, explain what was measured or inspected and why it was acceptable.
-
-## Inputs / Outputs
-
-- Inputs:
-  - diff
-  - hotspots
-  - response timings
-- Outputs:
-  - performance findings
-  - bottleneck map
-  - optimization advice
-  - measured path summary
-
-## Workflow
-
-1. Locate the expensive path.
-2. Inspect queries, cache, memory, and concurrency.
-3. Route correctness-only issues to `code-review`.
-4. Rank the bottlenecks by impact.
-5. Produce optimization advice.
-
-## Replay Signals
-
-- Input signal: diff, hotspots, response timings, or a performance concern.
-- Output to verify: performance findings, bottleneck map, optimization advice, measured path summary, review summary.
-- Stop signal: rewrite code or turn into a general review.
-- Handoff signal: the findings are ready for `knowledge-capture`.
-
-## Gotchas
-
-- Do not stop at vague "slow" labels.
-- Do not turn the task into a generic review.
-- Do not skip the bottleneck map.
-- Do not give advice without an identifiable path.
-- Do not file a generic correctness issue as a performance finding.
-
-## Stop Rules
-
-- Stop at performance findings.
-- Do not rewrite code.
-- Do not become a general review.
-
-## References
-
-- `skills/references/rule-loading-map.md`
-- `skills/references/prompt-replay-checklist.md`
-- `skills/references/full-chain-replay-scenarios.md`
-- `rules/index.md`
-
-# Performance Audit

package/skills/project-bootstrap/SKILL.md

@@ -1,81 +0,0 @@
----
-name: project-bootstrap
-description: 当项目需要初始化时，为新工作区装载合适的技能和规则包
-lifecycle_stage: scaffold
-rule_profile: scaffold
-dependencies: []
-triggers:
-  - bootstrap
-  - init
-  - new project
-  - workspace setup
-  - starter
-  - setup
-inputs:
-  - client type
-  - workspace markers
-  - desired rules bundle
-outputs:
-  - starter structure
-  - installed bundle
-  - setup notes
-workflow:
-  - detect the target client
-  - install the required skill and rules layout
-  - write the starter files
-  - hand off to the router or intake skill
-gates:
-  - stop after setup
-  - do not design product scope
-  - do not generate application code
-refs:
-  - skills/references/rule-loading-map.md
-  - skills/references/prompt-replay-checklist.md
-  - skills/references/full-chain-replay-scenarios.md
-  - rules/index.md
----
-
-# Project Bootstrap
-
-## Purpose
-
-Create a new workspace with the right skills and rules layout.
-
-## Suitable / Unsuitable
-
-- Suitable: workspace setup, starter files, rules bundle installation
-- Unsuitable: product discovery, architecture design, feature implementation
-
-## Workflow
-
-1. Detect the target client.
-2. Install the required skill and rules layout.
-3. Write the starter files.
-4. Hand off to the router or intake skill.
-
-## Replay Signals
-
-- Input signal: client type, workspace markers, desired rules bundle.
-- Output to verify: starter structure, installed bundle, setup notes.
-- Stop signal: product scope design or application code generation.
-- Handoff signal: the workspace is ready for `workflow-router` or `spec-refinement`.
-
-## Examples
-
-- Input: "Set up a new workspace for Codex with the right skills and rules."
-- Output: starter structure, installed bundle, setup notes
-- Stop: do not design product scope or generate application code
-
-## Stop Rules
-
-- Stop after setup.
-- Do not design product scope.
-- Do not generate application code.
-
-## References
-
-- `skills/references/rule-loading-map.md`
-- `skills/references/prompt-replay-checklist.md`
-- `skills/references/full-chain-replay-scenarios.md`
-- `rules/index.md`
-

package/skills/references/anti-rationalization.md

@@ -1,144 +0,0 @@
-# Anti-rationalization 表格
-
-> 常见借口 + 反驳理由 + 正确做法，防止借口驱动开发
-
----
-
-## 编码阶段 (BUILD)
-
-| 常见借口 | 反驳理由 | 正确做法 |
-|---------|---------|---------|
-| "这只是临时方案" | 临时方案会变成永久债务 | 按标准实现 |
-| "用户不会这样操作" | 用户总会找到边界情况 | 处理所有边界 |
-| "这个字段以后会用到" | 未使用的字段增加维护成本 | 按需求添加 |
-| "性能问题以后优化" | 早期设计决定性能上限 | 设计时考虑性能 |
-| "这个检查太严格了" | 严格检查防止生产事故 | 保持检查 |
-| "框架默认值够用了" | 默认值可能不适合业务场景 | 明确配置 |
-| "这段代码很清楚，不需要注释" | 6个月后你自己也看不懂 | 添加必要注释 |
-| "测试覆盖率80%够了" | 未覆盖的20%可能是关键路径 | 追求更高覆盖率 |
-| "这个异常不会发生" | 所有可能的异常都会发生 | 处理异常 |
-| "这个逻辑很简单，不需要设计" | 简单逻辑也会变复杂 | 完整设计 |
-| "这个功能单体和微服务都一样" | 架构差异影响设计决策 | 明确架构类型 |
-| "这个依赖关系很简单" | 简单依赖也会产生循环 | 分析依赖图 |
-
----
-
-## 设计阶段 (PLAN)
-
-| 常见借口 | 反驳理由 | 正确做法 |
-|---------|---------|---------|
-| "先实现功能，设计文档以后补" | 无文档的设计无法维护 | 先设计后实现 |
-| "这个实体很简单，不需要设计" | 简单实体也会变复杂 | 完整设计 |
-| "状态流转很直观，不用画图" | 直观的流转也有边界情况 | 绘制状态图 |
-| "接口定义很清楚，不需要文档" | 清楚的定义也需要确认 | 编写API文档 |
-| "SOLID检查太耗时" | 违反SOLID的代码更耗时维护 | 执行SOLID检查 |
-| "这个类以后会扩展" | 未预留扩展点会导致修改 | 使用开闭原则 |
-| "这个接口方法不多" | 接口方法会逐渐增加 | 控制接口方法数 |
-| "这个依赖可以硬编码" | 硬编码依赖难以测试 | 使用依赖注入 |
-
----
-
-## 需求阶段 (DEFINE)
-
-| 常见借口 | 反驳理由 | 正确做法 |
-|---------|---------|---------|
-| "需求很清楚，不需要文档" | 清楚的需求也会变化 | 编写需求文档 |
-| "这个功能很简单" | 简单功能也有边界情况 | 完整需求分析 |
-| "用户会这样操作" | 用户操作方式多样 | 分析所有场景 |
-| "这个边界不会发生" | 边界情况总会发生 | 处理边界 |
-| "这个功能以后再加" | 以后加的成本更高 | 现在规划 |
-| "这个影响范围很小" | 小影响也会产生连锁反应 | 完整影响分析 |
-| "这个模块不依赖其他模块" | 模块间总有依赖 | 分析依赖 |
-
----
-
-## 测试阶段 (VERIFY)
-
-| 常见借口 | 反驳理由 | 正确做法 |
-|---------|---------|---------|
-| "这个逻辑很简单，不需要测试" | 简单逻辑也有边界情况 | 编写测试 |
-| "测试覆盖率80%够了" | 未覆盖的20%可能是关键路径 | 追求更高覆盖率 |
-| "这个异常不会发生" | 所有可能的异常都会发生 | 测试异常场景 |
-| "这个边界不会触发" | 边界总会被触发 | 测试边界 |
-| "集成测试太耗时" | 集成问题修复成本更高 | 编写集成测试 |
-| "回归测试以后再做" | 回归问题修复成本更高 | 编写回归测试 |
-| "Mock太复杂了" | 无Mock的测试不可靠 | 使用Mock |
-
----
-
-## 评审阶段 (REVIEW)
-
-| 常见借口 | 反驳理由 | 正确做法 |
-|---------|---------|---------|
-| "这个问题不会发生" | 所有可能的问题都会发生 | 处理问题 |
-| "这个漏洞很难利用" | 难利用不代表不会被利用 | 修复漏洞 |
-| "评审太严格会延误进度" | 严格评审减少返工 | 保持严格 |
-| "这个警告可以忽略" | 警告是潜在问题的信号 | 处理警告 |
-| "这个问题以后修复" | 以后修复的成本更高 | 立即修复 |
-| "这是框架的问题，不是我写的" | 使用框架也要遵守规范 | 检查框架使用 |
-| "这个性能问题用户不会感知" | 用户感知是累积的 | 优化性能 |
-| "这个安全问题不严重" | 安全问题会累积 | 修复安全问题 |
-| "这个代码风格不重要" | 代码风格影响可维护性 | 保持风格一致 |
-| "这个命名很清楚" | 清楚的命名也会变化 | 规范命名 |
-
----
-
-## 发布阶段 (SHIP)
-
-| 常见借口 | 反驳理由 | 正确做法 |
-|---------|---------|---------|
-| "这个配置以后再优化" | 配置问题会影响生产 | 现在优化 |
-| "这个监控以后再加" | 无监控的系统不可运维 | 现在添加监控 |
-| "这个日志以后再规范" | 日志不规范影响排查 | 现在规范日志 |
-| "这个文档以后再补" | 无文档的系统不可维护 | 现在补充文档 |
-| "这个交接以后再做" | 交接不及时影响团队 | 现在做交接 |
-| "这个知识以后再沉淀" | 知识不沉淀会流失 | 现在沉淀知识 |
-
----
-
-## 安全审查阶段 (Security Review)
-
-| 常见借口 | 反驳理由 | 正确做法 |
-|---------|---------|---------|
-| "这个问题不会发生" | 所有可能的问题都会发生 | 处理问题 |
-| "这个漏洞很难利用" | 难利用不代表不会被利用 | 修复漏洞 |
-| "用户不会这样操作" | 用户总会找到边界情况 | 处理所有边界 |
-| "这只是内部系统" | 内部系统也可能被攻击 | 同样严格检查 |
-| "这个数据不重要" | 不重要数据也可能泄露 | 保护所有数据 |
-| "以后再修复" | 安全问题修复成本更高 | 立即修复 |
-| "这是框架的问题" | 使用框架也要遵守规范 | 检查框架使用 |
-| "测试环境不需要" | 测试环境也可能泄露 | 全环境检查 |
-
----
-
-## 性能审查阶段 (Performance Review)
-
-| 常见借口 | 反驳理由 | 正确做法 |
-|---------|---------|---------|
-| "性能问题用户不会感知" | 用户感知是累积的 | 优化性能 |
-| "这个查询很快" | 快查询也会累积 | 批量优化 |
-| "缓存以后再加" | 无缓存的系统不可用 | 设计时考虑缓存 |
-| "这个数据量很小" | 数据量会增长 | 设计时考虑增长 |
-| "这个接口不常用" | 不常用接口也可能被频繁调用 | 所有接口优化 |
-| "性能优化太耗时" | 性能问题修复成本更高 | 设计时考虑性能 |
-| "这是数据库的问题" | 应用层也能优化 | 应用层优化 |
-| "测试环境性能够用" | 生产环境数据量更大 | 生产环境验证 |
-
----
-
-## 使用方法
-
-1. **技能执行时**：在执行过程中遇到借口，查阅对应阶段的表格
-2. **评审时**：作为评审依据，反驳常见借口
-3. **培训时**：作为培训材料，帮助团队理解正确做法
-
----
-
-## 引用方式
-
-在各技能 SKILL.md 中添加：
-
-```markdown
-## Anti-rationalization
-常见借口反驳见 [Anti-rationalization 表格](../references/anti-rationalization.md)
-```