@tinkcarlos/skillora 0.2.0

package/.claude/skills/bug-fixing/references/skill-delegation-guide.md

@@ -0,0 +1,350 @@
+# Skill Delegation Guide (技能委托指南)
+
+> 在 Bug 修复过程中，何时、如何正确委托其他技能来完成辅助工作。
+
+---
+
+## 核心原则
+
+### 委托 vs 直接修复
+
+| 场景 | 处理方式 |
+|------|---------|
+| 修复只需改现有代码 | **直接修复**，不需要委托 |
+| 修复需要新增 API | **委托** `fullstack-developer` |
+| 修复需要新增/改前端组件 | **委托** `frontend-design` |
+| 修复需要改数据库 Schema | **委托** `database-migrations` |
+| 修复需要添加测试 | **委托** `unit-testing` / `webapp-testing` |
+
+### 委托的黄金法则
+
+1. **最小范围**: 只做修复 Bug 必须的工作
+2. **明确边界**: 清楚定义做什么和不做什么
+3. **快速返回**: 完成后立即返回主上下文
+4. **约束继承**: 委托任务继承 bug-fixing 的约束
+
+---
+
+## 技能委托路由表
+
+### 前端相关
+
+| 修复需要 | 委托技能 | 范围约束 | 退出条件 |
+|---------|---------|---------|---------|
+| 修复 React/Vue 组件 | `frontend-design` | 仅修复问题组件 | 组件正常工作 |
+| 新增 UI 组件 | `frontend-design` | 最小功能实现 | 组件可用 |
+| 修复样式问题 | `frontend-design` | 仅修复问题样式 | 显示正确 |
+| 修复状态管理 | `frontend-design` | 仅修复状态逻辑 | 状态同步正确 |
+
+### 后端相关
+
+| 修复需要 | 委托技能 | 范围约束 | 退出条件 |
+|---------|---------|---------|---------|
+| 新增 API 接口 | `fullstack-developer` | 仅创建必需接口 | API 可调用 |
+| 修复 API 逻辑 | `fullstack-developer` | 仅修复问题逻辑 | API 返回正确 |
+| 修复认证/授权 | `backend-api-security` | 仅修复安全问题 | 安全检查通过 |
+| Python 性能问题 | `python-development` | 仅优化问题代码 | 性能达标 |
+| Node.js 问题 | `javascript-typescript` | 仅修复问题代码 | 功能正常 |
+
+### 数据库相关
+
+| 修复需要 | 委托技能 | 范围约束 | 退出条件 |
+|---------|---------|---------|---------|
+| Schema 变更 | `database-migrations` | 仅必需的变更 | 迁移成功 |
+| 数据修复 | `database-design` | 仅修复问题数据 | 数据正确 |
+| 索引优化 | `database-design` | 仅添加必需索引 | 查询性能达标 |
+
+### 测试相关
+
+| 修复需要 | 委托技能 | 范围约束 | 退出条件 |
+|---------|---------|---------|---------|
+| 添加单元测试 | `unit-testing` | 仅修复相关测试 | 测试通过 |
+| 添加 E2E 测试 | `webapp-testing` | 仅回归测试用例 | 测试通过 |
+
+---
+
+## 委托执行流程
+
+### Step 1: 识别委托需求
+
+在 Phase 4 (Fix) 阶段，评估修复工作：
+
+```markdown
+## 修复工作评估
+
+### 直接可修复
+- [ ] 修改 `user_service.py` 中的验证逻辑 → 直接修复
+
+### 需要委托
+- [ ] 新增 `/api/v1/validate` 接口 → 委托 fullstack-developer
+- [ ] 创建 `ValidationError.tsx` 组件 → 委托 frontend-design
+```
+
+### Step 2: 准备委托
+
+**输出委托通知 (必须)**：
+
+```markdown
+---
+## 🔧 技能委托通知
+
+### 主上下文锚定
+- **Bug ID**: BUG-123
+- **原始症状**: 用户输入无效数据时页面崩溃
+- **根因**: 缺少输入验证和错误展示
+- **当前阶段**: Phase 4.1 - 修复实施
+
+### 委托任务 1/2
+- **委托技能**: `fullstack-developer`
+- **委托目的**: 创建验证 API 接口
+- **范围限定**:
+  - ✅ 创建 `POST /api/v1/validate` 接口
+  - ✅ 实现基本验证逻辑
+  - ❌ 不重构现有 API
+  - ❌ 不添加额外功能
+- **退出条件**: API 可调用并返回验证结果
+
+### 约束继承
+- 遵循项目现有 API 风格
+- 不引入新依赖
+- 最小 LOC
+
+---
+⏱️ 开始委托任务 1/2...
+```
+
+### Step 3: 执行委托
+
+**加载目标技能规范**：
+
+```markdown
+## 执行委托: fullstack-developer
+
+### 加载技能规范
+参考 fullstack-developer SKILL.md 中的:
+- API 设计原则
+- 代码风格规范
+- 验证模式
+
+### 执行
+[按技能规范执行，但遵守委托范围约束]
+```
+
+**范围监控**：
+
+```markdown
+## ⚠️ 范围警戒检查
+
+当前步骤: 创建 validate API
+- [x] 是否在委托范围内? → 是
+- [x] 是否有超出范围的冲动? → 否
+- [x] 是否仍聚焦于修复 Bug? → 是
+
+继续执行...
+```
+
+### Step 4: 退出委托
+
+**输出委托完成通知 (必须)**：
+
+```markdown
+---
+## ✅ 委托任务 1/2 完成
+
+### 完成情况
+- **创建的文件**: `app/api/v1/validate.py`
+- **修改的文件**: `app/api/__init__.py` (注册路由)
+- **目标达成**: ✅ API 可调用
+- **范围遵守**: ✅ 未超出
+
+### 验证
+```bash
+curl -X POST http://localhost:8000/api/v1/validate -d '{"email": "test"}'
+# 返回: {"valid": false, "errors": ["Invalid email format"]}
+```
+
+### 返回主上下文
+- **继续阶段**: Phase 4.2 - 前端组件
+- **下一委托**: frontend-design (ValidationError.tsx)
+
+---
+🔄 返回主上下文，准备下一个委托任务...
+```
+
+---
+
+## 多委托任务管理
+
+当修复需要多个委托任务时：
+
+### 委托任务清单
+
+```markdown
+## 委托任务计划
+
+| # | 技能 | 目的 | 状态 |
+|---|------|------|------|
+| 1 | `fullstack-developer` | 创建验证 API | ✅ 完成 |
+| 2 | `frontend-design` | 创建错误展示组件 | 🔄 进行中 |
+| 3 | `unit-testing` | 添加回归测试 | ⏳ 待执行 |
+```
+
+### 任务间过渡
+
+```markdown
+---
+## 🔄 委托任务过渡
+
+### 上一任务: fullstack-developer
+- 状态: ✅ 完成
+- 产出: `/api/v1/validate` 接口
+
+### 下一任务: frontend-design
+- 目的: 创建 ValidationError.tsx
+- 依赖上一任务产出: 调用 validate API
+
+---
+⏱️ 开始委托任务 2/3...
+```
+
+---
+
+## 委托范围约束详解
+
+### 允许 vs 禁止
+
+| 委托技能 | ✅ 允许 | ❌ 禁止 |
+|---------|--------|--------|
+| **fullstack-developer** | 创建修复所需 API | 重构其他 API |
+| | 添加必需的字段 | 添加"顺便"的功能 |
+| | 修复 API 逻辑 | 更换 API 框架 |
+| **frontend-design** | 修复问题组件 | 重新设计整个页面 |
+| | 创建缺失组件 | 更换 UI 库 |
+| | 修复样式问题 | 实施设计系统 |
+| **database-migrations** | 修复所需 Schema 变更 | 重构数据模型 |
+| | 添加必需字段/表 | 性能优化 (除非是 Bug 根因) |
+| **unit-testing** | 添加修复相关测试 | 重写测试套件 |
+| | 修复失败的测试 | 添加无关测试 |
+
+### 范围超出处理
+
+```markdown
+## 🚨 范围超出警报
+
+### 发现的超出范围工作
+- 发现 UserService 代码结构可以优化
+- 发现缺少全局错误处理
+
+### 处理方式
+1. ⏸️ 暂停超出范围工作
+2. 📝 记录发现
+3. 💬 建议后续处理:
+   - 建议单独创建重构任务
+   - 建议单独处理全局错误处理
+4. 🔄 继续当前 Bug 修复
+
+### 返回正轨
+继续委托任务，仅完成必需工作...
+```
+
+---
+
+## 委托质量检查
+
+### 委托完成时的检查清单
+
+```markdown
+## 委托质量检查
+
+### 目标达成
+- [ ] 委托目的已实现
+- [ ] 产出物可用于修复 Bug
+
+### 范围遵守
+- [ ] 未超出预定范围
+- [ ] 未"顺便"做其他事
+- [ ] 未引入无关变更
+
+### 质量标准
+- [ ] 代码符合项目风格
+- [ ] 无 lint 错误
+- [ ] 可与现有代码集成
+
+### 文档
+- [ ] 委托完成通知已输出
+- [ ] 产出物已记录
+```
+
+---
+
+## 常见问题
+
+### Q1: 委托任务中发现新问题怎么办?
+
+**A**: 记录但不处理：
+
+```markdown
+## 发现的问题 (委托中)
+- UserService 缺少日志
+- 数据库连接池配置不优
+
+### 处理方式
+- 记录到 Related Issues
+- 不在当前委托中处理
+- 建议修复完成后单独评估
+```
+
+### Q2: 多个委托任务有依赖怎么办?
+
+**A**: 按依赖顺序执行：
+
+```markdown
+## 委托依赖图
+
+fullstack-developer (创建 API)
+    ↓
+frontend-design (调用 API 的组件)
+    ↓
+unit-testing (测试 API 和组件)
+
+执行顺序: 1 → 2 → 3
+```
+
+### Q3: 委托任务失败怎么办?
+
+**A**: 立即返回主上下文评估：
+
+```markdown
+## ❌ 委托任务失败
+
+### 失败原因
+[描述为什么失败]
+
+### 返回主上下文
+- 重新评估修复策略
+- 考虑替代方案
+- 可能需要调整根因分析
+```
+
+---
+
+## 检查清单
+
+### 委托前
+- [ ] 确认需要委托 (不能直接修复)
+- [ ] 明确委托目的
+- [ ] 定义范围约束
+- [ ] 设定退出条件
+- [ ] 输出委托通知
+
+### 委托中
+- [ ] 加载目标技能规范
+- [ ] 遵守范围约束
+- [ ] 持续范围监控
+- [ ] 保持主上下文意识
+
+### 委托后
+- [ ] 验证目标达成
+- [ ] 确认范围遵守
+- [ ] 输出完成通知
+- [ ] 返回主上下文

package/.claude/skills/bug-fixing/references/skill-orchestration.md

@@ -0,0 +1,155 @@
+# 多技能协作协议 (Multi-Skill Orchestration Protocol)
+
+本文档定义了 Bug 修复过程中何时、如何调用其他技能以实现完整、规范的修复。
+
+## 核心原则
+
+**单一技能无法完成完美的开发工作。** Bug 修复往往涉及多个领域：代码审查、数据库变更、测试编写、文档更新等。本协议确保在正确的时机调用正确的技能。
+
+## 技能路由表 (Skill Router)
+
+### Bug 类型 → 推荐技能组合
+
+| Bug 类型 | 主技能 | 协作技能 | 调用时机 |
+|----------|--------|----------|----------|
+| **前端 UI/样式问题** | `bug-fixing` | `frontend-design` | 修复涉及视觉/交互时 |
+| **后端 API 错误** | `bug-fixing` | `api-design-principles` | API 契约/设计需调整时 |
+| **数据库相关** | `bug-fixing` | `database-migration` + `postgresql-table-design` | Schema/索引变更时 |
+| **性能问题 (Python)** | `bug-fixing` | `python-performance-optimization` + `async-python-patterns` | 性能分析后 |
+| **性能问题 (JS/TS)** | `bug-fixing` | `modern-javascript-patterns` + `typescript-advanced-types` | 性能分析后 |
+| **分布式/微服务问题** | `bug-fixing` | `microservices-patterns` + `distributed-tracing` | 跨服务追踪时 |
+| **认证/授权问题** | `bug-fixing` | `auth-implementation-patterns` | 安全逻辑修改时 |
+| **测试覆盖不足** | `bug-fixing` | `python-testing-patterns` / `javascript-testing-patterns` | 添加回归测试时 |
+
+### 强制技能调用 (Mandatory)
+
+| 触发条件 | 必须调用的技能 | 原因 |
+|----------|----------------|------|
+| **修复完成后** | `code-review` | 确保修复质量，防止引入新问题 |
+| **审查发现问题** | `bug-fixing` (再次) | 循环直到所有问题解决 |
+| **涉及 UI 变更** | `frontend-design` | 确保视觉/交互一致性 |
+| **修改 ORM 模型** | `database-migration` | 确保 schema-model 同步 |
+| **修改 API 契约** | `api-design-principles` | 确保 API 设计合理 |
+
+## 技能调用决策树
+
+```
+Bug 修复开始
+       │
+       ▼
+┌──────────────────────────────────────────────────────┐
+│ Phase 0: 分类 & 分析                                  │
+│ ─────────────────────────────────────────────────────│
+│ 1. 识别 Bug 类型（前端/后端/全栈/数据库/性能）         │
+│ 2. 查询技能路由表，确定协作技能                       │
+│ 3. 记录到分析报告                                     │
+└──────────────────────────────────────────────────────┘
+       │
+       ▼
+┌──────────────────────────────────────────────────────┐
+│ Phase 1-4: 修复实施                                   │
+│ ─────────────────────────────────────────────────────│
+│ 🔴 触发点检测：                                       │
+│ - 涉及 UI? → 调用 `frontend-design`                   │
+│ - 涉及数据库? → 调用 `database-migration`             │
+│ - 涉及 API? → 调用 `api-design-principles`            │
+│ - 需要测试? → 调用对应语言的 testing-patterns        │
+└──────────────────────────────────────────────────────┘
+       │
+       ▼
+┌──────────────────────────────────────────────────────┐
+│ Phase 5: 验证 (MANDATORY)                             │
+│ ─────────────────────────────────────────────────────│
+│ 🔴 强制调用 `code-review`                             │
+│ 🔴 发现问题? → 返回 bug-fixing 循环                   │
+└──────────────────────────────────────────────────────┘
+       │
+       ▼
+   修复完成 ✅
+```
+
+## 技能调用语法
+
+在修复过程中，使用以下格式记录技能调用：
+
+```markdown
+## 🔄 技能协作记录
+
+| 阶段 | 调用技能 | 原因 | 结果 |
+|------|----------|------|------|
+| Phase 2 | `database-migration` | 修复需要添加索引 | 创建迁移文件 |
+| Phase 4 | `python-testing-patterns` | 添加回归测试 | 新增 3 个测试用例 |
+| Phase 5 | `code-review` | 强制审查 | 发现 1 个潜在问题 |
+| Phase 5.1 | `bug-fixing` | 修复审查问题 | 问题已解决 |
+```
+
+## 技能协作输出模板
+
+修复报告必须包含技能协作部分：
+
+```markdown
+## 📊 技能协作报告
+
+### 调用的技能
+| 技能 | 调用原因 | 贡献 |
+|------|----------|------|
+| `bug-fixing` (主) | Bug 修复主流程 | 根因分析、修复实施 |
+| `database-migration` | Schema 变更 | 创建迁移文件 |
+| `code-review` | 强制审查 | 发现潜在问题 |
+
+### 未调用但建议后续调用的技能
+| 技能 | 建议原因 |
+|------|----------|
+| `python-testing-patterns` | 测试覆盖率可进一步提升 |
+```
+
+## 常见协作场景
+
+### 场景 1: 前端 Bug + 样式问题
+
+```
+bug-fixing (主)
+    │
+    ├─→ frontend-design (样式/交互修改)
+    │
+    ├─→ javascript-testing-patterns (组件测试)
+    │
+    └─→ code-review (强制)
+```
+
+### 场景 2: 后端 API Bug + 数据库问题
+
+```
+bug-fixing (主)
+    │
+    ├─→ database-migration (Schema 变更)
+    │
+    ├─→ api-design-principles (API 契约调整)
+    │
+    ├─→ python-testing-patterns (API 测试)
+    │
+    └─→ code-review (强制)
+```
+
+### 场景 3: 性能问题
+
+```
+bug-fixing (主)
+    │
+    ├─→ python-performance-optimization / modern-javascript-patterns
+    │
+    ├─→ sql-optimization-patterns (如果涉及查询)
+    │
+    ├─→ async-python-patterns / nodejs-backend-patterns (如果涉及并发)
+    │
+    └─→ code-review (强制)
+```
+
+## Definition of Done
+
+修复完成前，确认：
+
+- [ ] 技能路由表已查询，协作技能已确定
+- [ ] 所有触发条件对应的技能已调用
+- [ ] `code-review` 已调用且通过
+- [ ] 技能协作报告已输出