@pigcloud/skills 1.0.0

package/skills/references/anti-rationalization.md

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

package/skills/references/engineering-delivery-method.md

@@ -0,0 +1,63 @@
+# Engineering Delivery Method
+
+## Goal
+
+Help engineering teams turn an approved spec into executable work, decide complexity before coding, implement inside `feature-build`, self-verify locally, and then hand off to validation and review.
+
+Use [`engineering-delivery-template.md`](engineering-delivery-template.md) when you need the copyable one-page form.
+
+## Flow
+
+1. Start from an approved spec or executable design.
+2. Align the spec with current project facts and selected rules.
+3. Plan the task execution direction before coding.
+4. Decide whether the change is simple or complex before coding.
+5. If the change is complex, produce `technical-design` first.
+6. Enter `feature-build` and split the work into small tasks.
+7. Implement one task at a time.
+8. Run local self-tests after each task.
+9. Record validation evidence.
+10. Hand off the verified result to `test-design`, then `code-review`.
+
+## Task Split Rules
+
+- Prefer acceptance-item first, then module-boundary refinement.
+- Each task should be small enough to finish and verify independently.
+- Each task should have a clear owner surface, dependency list, and done criteria.
+- Split mixed-stack work by the smallest verifiable implementation unit.
+- Treat task splitting as a working artifact, not as a separate lifecycle stage.
+
+## Task Card Shape
+
+- task goal
+- impacted surface
+- implementation boundary
+- dependencies
+- completion criteria
+- self-test steps
+- evidence to record
+
+## Self-Test Rules
+
+- Verify the smallest relevant unit first.
+- Record the evidence immediately after the task is finished.
+- If a task fails locally, fix it before moving to the next task.
+- Do not wait until the end to discover basic correctness issues.
+
+## Handoff Rules
+
+- `feature-build` hands off code changes plus validation evidence.
+- `test-design` receives implementation notes, self-test results, and coverage gaps.
+- `code-review` receives the validated diff and evidence summary.
+
+## Spec Stage Direction
+
+- Before execution, produce an execution direction plan.
+- Keep the direction explicit enough for a user to confirm.
+- Do not enter `feature-build` until the direction is accepted.
+
+## References
+
+- `skills/references/project-requirement-alignment.md`
+- `skills/references/flow-test-cases.md`
+- `skills/references/full-chain-replay-scenarios.md`

package/skills/references/engineering-delivery-template.md

@@ -0,0 +1,80 @@
+# Engineering Delivery Template
+
+## How to Use
+
+- Start from an approved spec or executable design.
+- Fill this page before implementation.
+- Keep each task small enough to implement and self-test independently.
+- Do not add long background text.
+
+## 1. Current State Alignment
+
+- Product intent:
+- Current project facts:
+- Existing constraints:
+- Conflicts or gaps:
+- Alignment notes:
+
+## 2. Execution Direction Plan
+
+- Preferred execution path:
+- What should be done first:
+- What should be done next:
+- What must wait for confirmation:
+- Why this direction fits the current facts:
+
+## 3. Task Breakdown
+
+| Task | Goal | Impacted surface | Boundary | Dependencies | Done criteria |
+|---|---|---|---|---|---|
+| T1 |  |  |  |  |  |
+| T2 |  |  |  |  |  |
+| T3 |  |  |  |  |  |
+
+Rules:
+
+- Prefer acceptance-item first, then module-boundary refinement.
+- Split mixed-stack work by the smallest verifiable implementation unit.
+- Keep each task finishable in one implementation pass.
+
+## 4. Task-by-Task Implementation
+
+For each task, record:
+
+- Task ID:
+- What changed:
+- Files or surfaces:
+- Rule bundle used:
+- Notes:
+
+## 5. Task-Level Self-Test
+
+For each task, record:
+
+- Task ID:
+- Self-test steps:
+- Expected result:
+- Actual result:
+- Evidence:
+
+Rules:
+
+- Run self-test immediately after the task is done.
+- Fix failures before starting the next task.
+- Record evidence as soon as the task passes.
+
+## 6. Validation and Handoff
+
+- Overall validation result:
+- Coverage gaps:
+- Remaining risks:
+- Handoff target: `test-design`
+- Review target: `code-review`
+
+## Minimum Acceptance
+
+- The spec is split into small tasks.
+- The execution direction is explicit before confirmation.
+- Every task has a done criteria and a self-test.
+- The implementation was verified task by task.
+- The handoff includes evidence, not just code.

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

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

@@ -0,0 +1,79 @@
+# 全链路回放场景
+
+## 目的
+
+用这些场景回放完整的产品到研发工作流，检查每个 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 稳定，产出预期工件，并在下一阶段开始前停住。
+- 任何把实现泄漏到收口阶段，或者在实现/审查阶段重写需求的步骤，都应判失败。