sdd-full 4.2.0 → 4.3.0

package/skills/chinese-git-workflow/SKILL.md

@@ -1,510 +0,0 @@
----
-name: chinese-git-workflow
-description: 适配国内 Git 平台和团队习惯的工作流规范——Gitee、Coding、极狐 GitLab 全覆盖
----
-
-# 国内 Git 工作流规范
-
-## 概述
-
-国内团队用 Git 经常踩的坑：GitHub 访问不稳定、CI/CD 方案照搬国外水土不服、commit message 中英混杂没有规范。本技能提供一套**完整适配国内平台和团队习惯的 Git 工作流**。
-
-**核心原则：** 工作流服务于团队效率，不是为了流程而流程。选适合团队规模的，别硬套大厂方案。
-
-## 国内 Git 平台适配
-
-### 平台对比
-
-| 特性 | Gitee | Coding.net | 极狐 GitLab | GitHub |
-|------|-------|------------|-------------|--------|
-| 国内访问 | 快 | 快 | 快 | 不稳定 |
-| 免费私有仓库 | 有 | 有 | 有 | 有 |
-| CI/CD | Gitee Go | Coding CI | 内置 GitLab CI | GitHub Actions |
-| 代码审查 | PR | MR | MR | PR |
-| 制品库 | 有限 | 完整 | 完整 | Packages |
-| 适合场景 | 开源/小团队 | 中大型团队 | 企业私有化 | 国际项目 |
-
-### Gitee 特有配置
-
-```bash
-# 设置 Gitee 远程仓库
-git remote add origin https://gitee.com/<org>/<repo>.git
-
-# Gitee 的 SSH 配置
-# ~/.ssh/config
-Host gitee.com
-    HostName gitee.com
-    User git
-    IdentityFile ~/.ssh/gitee_rsa
-    PreferredAuthentications publickey
-
-# 同时推送到 Gitee 和 GitHub（镜像同步）
-git remote set-url --add --push origin https://gitee.com/<org>/<repo>.git
-git remote set-url --add --push origin https://github.com/<org>/<repo>.git
-```
-
-### Coding.net 特有配置
-
-```bash
-# Coding 的仓库地址格式
-git remote add origin https://e.coding.net/<team>/<project>/<repo>.git
-
-# Coding 支持的 SSH 地址
-git remote add origin git@e.coding.net:<team>/<project>/<repo>.git
-```
-
-### 极狐 GitLab 特有配置
-
-```bash
-# 极狐 GitLab 私有化部署常见地址格式
-git remote add origin https://jihulab.com/<group>/<repo>.git
-
-# 或者企业内部部署
-git remote add origin https://gitlab.yourcompany.com/<group>/<repo>.git
-```
-
-## 工作流选择
-
-### 方案一：主干开发（Trunk-Based Development）
-
-**适合：** 小团队（2-8 人）、迭代速度快、有完善的自动化测试。
-
-```
-main ──●──●──●──●──●──●──●──●──●──
-        \   /  \   /       \   /
-feat/x  ●─●   ●─●    fix/y ●─●
-（短命分支，1-2 天内合回）
-```
-
-**规则：**
-- 主干（main）始终保持可发布状态
-- 功能分支生命周期不超过 2 天
-- 每天至少合并一次到主干
-- 用 Feature Flag 控制未完成功能的可见性
-
-```bash
-# 从 main 拉分支
-git checkout -b feat/user-login main
-
-# 开发完成后，rebase 到最新 main
-git fetch origin
-git rebase origin/main
-
-# 提交 PR/MR，合并后删除分支
-```
-
-### 方案二：Git Flow（经典分支模型）
-
-**适合：** 中大团队、版本发布节奏固定（如双周迭代）、需要维护多个版本。
-
-```
-main     ──●────────────────●────────────── 生产环境
-            \              / \
-release     ●──●──●──●──●    ●──●──●──●── 发布分支
-            \              /
-develop  ──●──●──●──●──●──●──●──●──●──●── 开发主线
-             \   /  \       /
-feat/x       ●─●    ●─────●               功能分支
-                      \   /
-                  fix/y ●─●                修复分支
-```
-
-**分支说明：**
-- `main` — 生产环境代码，只接受 release 和 hotfix 的合并
-- `develop` — 开发主线，功能分支从这里拉出，合回这里
-- `release/*` — 发布分支，从 develop 拉出，只修 bug 不加功能
-- `feat/*` — 功能分支
-- `hotfix/*` — 紧急修复，从 main 拉出，同时合回 main 和 develop
-
-### 方案三：国内团队常用简化流程
-
-**适合：** 大多数国内中小团队的实际情况。
-
-```
-main     ──●──────●──────●──── 生产环境（受保护）
-            \    / \    /
-dev      ──●──●─●──●──●─●──── 开发/测试环境
-             \  /    \  /
-feat/x       ●●      ●●       功能分支
-```
-
-**规则：**
-- `main` 分支受保护，只能通过 PR/MR 合并
-- `dev` 分支对应测试环境，自动部署
-- 功能分支从 `dev` 拉出，合回 `dev`
-- `dev` 测试通过后，合并到 `main` 进行发布
-
-## 分支命名规范
-
-### 国内团队常用命名
-
-```bash
-# 功能分支
-feat/user-login              # 新功能
-feat/JIRA-1234-order-refund  # 关联任务编号
-
-# 修复分支
-fix/payment-callback         # Bug 修复
-fix/JIRA-5678-null-pointer   # 关联 Bug 编号
-
-# 发布分支
-release/v2.1.0               # 版本发布
-release/2024-03-sprint       # 按迭代命名
-
-# 紧急修复
-hotfix/v2.0.1                # 线上紧急修复
-hotfix/fix-login-crash       # 描述性命名
-
-# 个人分支（部分团队使用）
-dev/zhangsan/feat-login      # 个人开发分支
-```
-
-### 命名规则
-
-1. 全部小写，用 `-` 连接单词（不用下划线或驼峰）
-2. 前缀明确分支类型：`feat/`、`fix/`、`hotfix/`、`release/`
-3. 关联任务管理平台的编号（如有）：`feat/TAPD-12345-description`
-4. 长度适中，能看出分支目的即可
-
-## 中文 Commit Message 规范
-
-### 约定式提交（Conventional Commits）中文版
-
-```
-<类型>(<范围>): <简要描述>
-                                    ← 空行
-<正文（可选）>
-                                    ← 空行
-<脚注（可选）>
-```
-
-### 类型清单
-
-| 类型 | 说明 | emoji（可选） |
-|------|------|--------------|
-| feat | 新增功能 | ✨ |
-| fix | 修复 Bug | 🐛 |
-| docs | 文档更新 | 📝 |
-| style | 代码格式（不影响逻辑） | 💄 |
-| refactor | 重构（不是新功能也不是修 Bug） | ♻️ |
-| perf | 性能优化 | ⚡ |
-| test | 测试相关 | ✅ |
-| build | 构建系统或外部依赖 | 📦 |
-| ci | CI/CD 配置 | 👷 |
-| chore | 其他杂项 | 🔧 |
-| revert | 回滚 | ⏪ |
-
-### 好的 commit message
-
-```
-feat(购物车): 支持批量删除商品
-
-- 新增全选/反选功能
-- 删除操作增加二次确认弹窗
-- 批量删除接口使用 POST /cart/batch-delete
-
-关联需求：TAPD-12345
-```
-
-```
-fix(支付): 修复微信支付在 iOS 16 上无法唤起的问题
-
-原因：微信 SDK 8.0.33 版本在 iOS 16 上 Universal Links 校验逻辑变更，
-导致 openURL 回调失败。
-
-方案：升级 SDK 至 8.0.38，并更新 Associated Domains 配置。
-
-Closes #567
-```
-
-### 不好的 commit message
-
-```
-# 太笼统
-update code
-fix bug
-修改了一些东西
-
-# 没有上下文
-fix: 修复问题
-feat: 新增功能
-
-# 中英混杂无规范
-fix：修复了一个bug，因为user login的时候会crash
-```
-
-## CI/CD 平台适配
-
-### Gitee Go
-
-```yaml
-# .gitee/pipelines/pipeline.yml
-name: 构建与测试
-displayName: '构建与测试流水线'
-
-triggers:
-  push:
-    branches:
-      include:
-        - main
-        - dev
-
-stages:
-  - name: 测试
-    jobs:
-      - name: 单元测试
-        steps:
-          - step: npmbuild@1
-            name: install_and_test
-            displayName: '安装依赖并执行测试'
-            inputs:
-              nodeVersion: 20
-              commands:
-                - npm ci
-                - npm test
-```
-
-### Coding CI
-
-```groovy
-// Jenkinsfile（Coding CI 支持 Jenkinsfile 语法）
-pipeline {
-    agent any
-
-    stages {
-        stage('安装依赖') {
-            steps {
-                sh 'npm ci'
-            }
-        }
-
-        stage('单元测试') {
-            steps {
-                sh 'npm test'
-            }
-        }
-
-        stage('构建') {
-            steps {
-                sh 'npm run build'
-            }
-        }
-
-        stage('部署到测试环境') {
-            when {
-                branch 'dev'
-            }
-            steps {
-                sh './scripts/deploy-staging.sh'
-            }
-        }
-
-        stage('部署到生产环境') {
-            when {
-                branch 'main'
-            }
-            steps {
-                sh './scripts/deploy-production.sh'
-            }
-        }
-    }
-
-    post {
-        failure {
-            // 企业微信/钉钉通知
-            sh './scripts/notify-failure.sh'
-        }
-    }
-}
-```
-
-### 极狐 GitLab CI
-
-```yaml
-# .gitlab-ci.yml
-stages:
-  - test
-  - build
-  - deploy
-
-variables:
-  NODE_IMAGE: node:20-alpine
-  # 使用国内镜像加速
-  NPM_REGISTRY: https://registry.npmmirror.com
-
-单元测试:
-  stage: test
-  image: $NODE_IMAGE
-  script:
-    - npm config set registry $NPM_REGISTRY
-    - npm ci
-    - npm test
-  coverage: '/Lines\s*:\s*(\d+\.?\d*)%/'
-
-构建:
-  stage: build
-  image: $NODE_IMAGE
-  script:
-    - npm config set registry $NPM_REGISTRY
-    - npm ci
-    - npm run build
-  artifacts:
-    paths:
-      - dist/
-
-部署测试环境:
-  stage: deploy
-  script:
-    - ./scripts/deploy-staging.sh
-  only:
-    - dev
-  environment:
-    name: staging
-
-部署生产环境:
-  stage: deploy
-  script:
-    - ./scripts/deploy-production.sh
-  only:
-    - main
-  environment:
-    name: production
-  when: manual  # 生产环境手动触发
-```
-
-### GitHub Actions 国内替代方案对照
-
-| GitHub Actions 功能 | Gitee Go | Coding CI | 极狐 GitLab CI |
-|---------------------|----------|-----------|----------------|
-| 触发条件 | triggers | Jenkinsfile triggers | only/rules |
-| 缓存依赖 | cache step | stash/unstash | cache |
-| 制品存储 | artifacts | 制品库 | artifacts |
-| 环境变量 | env | environment | variables |
-| 密钥管理 | 环境变量配置 | 凭据管理 | CI/CD Variables |
-| 手动触发 | 手动运行 | 手动触发 | when: manual |
-
-## PR/MR 描述模板
-
-### 中文模板
-
-在仓库中创建 PR/MR 模板文件：
-
-**Gitee：** `.gitee/PULL_REQUEST_TEMPLATE.md`
-
-**Coding / GitLab：** `.gitlab/merge_request_templates/default.md`
-
-```markdown
-## 变更说明
-
-<!-- 简要描述这次改动做了什么，解决了什么问题 -->
-
-## 变更类型
-
-- [ ] 新功能（feat）
-- [ ] Bug 修复（fix）
-- [ ] 重构（refactor）
-- [ ] 性能优化（perf）
-- [ ] 文档更新（docs）
-- [ ] 其他：
-
-## 关联信息
-
-- 需求/Bug 链接：
-- 设计文档：
-
-## 改动范围
-
-<!-- 列出主要改动的模块和文件 -->
-
-## 测试情况
-
-- [ ] 单元测试通过
-- [ ] 手动测试通过
-- [ ] 相关模块回归测试通过
-
-## 测试方法
-
-<!-- 描述如何验证这次改动 -->
-
-## 影响范围
-
-<!-- 这次改动可能影响哪些功能？是否需要通知其他团队？ -->
-
-## 部署注意事项
-
-- [ ] 需要执行数据库迁移
-- [ ] 需要更新配置文件
-- [ ] 需要更新环境变量
-- [ ] 无特殊注意事项
-
-## 截图/录屏
-
-<!-- 如果涉及 UI 变更，贴截图或录屏 -->
-```
-
-## 常用 Git 配置
-
-### 国内环境优化
-
-```bash
-# 设置用户信息
-git config --global user.name "张三"
-git config --global user.email "zhangsan@company.com"
-
-# commit message 编辑器设置为 VS Code
-git config --global core.editor "code --wait"
-
-# 解决中文文件名显示为转义字符的问题
-git config --global core.quotepath false
-
-# 设置默认分支名
-git config --global init.defaultBranch main
-
-# 代理设置（如果需要同时使用 GitHub）
-git config --global http.https://github.com.proxy socks5://127.0.0.1:7890
-
-# NPM 使用国内镜像
-npm config set registry https://registry.npmmirror.com
-```
-
-### .gitignore 国内项目常见配置
-
-```gitignore
-# IDE
-.idea/
-.vscode/
-*.swp
-
-# 依赖
-node_modules/
-vendor/
-
-# 构建产物
-dist/
-build/
-*.exe
-
-# 环境配置
-.env
-.env.local
-.env.*.local
-
-# 系统文件
-.DS_Store
-Thumbs.db
-desktop.ini
-
-# 国内平台特有
-.coding/
-```
-
-## 检查清单
-
-在推送代码前，确认：
-
-- [ ] 分支命名符合团队规范
-- [ ] commit message 格式正确，类型和范围准确
-- [ ] 关联了对应的需求/Bug 编号
-- [ ] PR/MR 描述填写完整
-- [ ] CI 流水线通过
-- [ ] 已请求相关同事 Review

package/skills/dispatching-parallel-agents/SKILL.md

@@ -1,182 +0,0 @@
----
-name: dispatching-parallel-agents
-description: 当面对 2 个以上可以独立进行、无共享状态或顺序依赖的任务时使用
----
-
-# 并行分派智能体
-
-## 概述
-
-你将任务委派给具有隔离上下文的专用智能体。通过精心设计它们的指令和上下文，确保它们专注并成功完成任务。它们不应继承你的会话上下文或历史记录——你要精确构造它们所需的一切。这样也能为你自己保留用于协调工作的上下文。
-
-当你遇到多个不相关的失败（不同的测试文件、不同的子系统、不同的 bug），逐一排查会浪费时间。每个排查都是独立的，可以并行进行。
-
-**核心原则：** 每个独立问题域分派一个智能体，让它们并发工作。
-
-## 何时使用
-
-```dot
-digraph when_to_use {
-    "存在多个失败?" [shape=diamond];
-    "它们是否独立?" [shape=diamond];
-    "单个智能体排查所有问题" [shape=box];
-    "每个问题域一个智能体" [shape=box];
-    "能否并行工作?" [shape=diamond];
-    "顺序执行智能体" [shape=box];
-    "并行分派" [shape=box];
-
-    "存在多个失败?" -> "它们是否独立?" [label="是"];
-    "它们是否独立?" -> "单个智能体排查所有问题" [label="否 - 有关联"];
-    "它们是否独立?" -> "能否并行工作?" [label="是"];
-    "能否并行工作?" -> "并行分派" [label="是"];
-    "能否并行工作?" -> "顺序执行智能体" [label="否 - 有共享状态"];
-}
-```
-
-**适用场景：**
-- 3 个以上测试文件因不同根因失败
-- 多个子系统独立出现故障
-- 每个问题无需其他问题的上下文即可理解
-- 排查之间无共享状态
-
-**不适用场景：**
-- 失败是相关的（修复一个可能修复其他的）
-- 需要理解完整的系统状态
-- 智能体之间会互相干扰
-
-## 模式
-
-### 1. 识别独立的问题域
-
-按故障分组：
-- 文件 A 测试：工具审批流程
-- 文件 B 测试：批量完成行为
-- 文件 C 测试：中止功能
-
-每个问题域是独立的——修复工具审批不会影响中止测试。
-
-### 2. 创建聚焦的智能体任务
-
-每个智能体获得：
-- **明确范围：** 一个测试文件或子系统
-- **清晰目标：** 让这些测试通过
-- **约束条件：** 不修改其他代码
-- **预期输出：** 你发现和修复内容的总结
-
-### 3. 并行分派
-
-```typescript
-// 在 Claude Code / AI 环境中
-Task("修复 agent-tool-abort.test.ts 的失败")
-Task("修复 batch-completion-behavior.test.ts 的失败")
-Task("修复 tool-approval-race-conditions.test.ts 的失败")
-// 三个任务并发运行
-```
-
-### 4. 审查与集成
-
-当智能体返回时：
-- 阅读每个总结
-- 验证修复之间没有冲突
-- 运行完整测试套件
-- 集成所有更改
-
-## 智能体提示词结构
-
-好的智能体提示词应该是：
-1. **聚焦的** - 一个清晰的问题域
-2. **自包含的** - 包含理解问题所需的所有上下文
-3. **明确输出要求** - 智能体应该返回什么？
-
-```markdown
-修复 src/agents/agent-tool-abort.test.ts 中 3 个失败的测试：
-
-1. "should abort tool with partial output capture" - 期望消息中包含 'interrupted at'
-2. "should handle mixed completed and aborted tools" - 快速工具被中止而非完成
-3. "should properly track pendingToolCount" - 期望 3 个结果但得到 0 个
-
-这些是时序/竞态条件问题。你的任务：
-
-1. 阅读测试文件，理解每个测试验证的内容
-2. 找到根因——是时序问题还是实际 bug？
-3. 修复方式：
-   - 用基于事件的等待替换任意超时
-   - 如果发现中止实现中的 bug 则修复
-   - 如果测试的是已变更的行为则调整测试期望
-
-不要只是增加超时时间——找到真正的问题。
-
-返回：你发现了什么以及修复了什么的总结。
-```
-
-## 常见错误
-
-**错误做法：太宽泛：** "修复所有测试" - 智能体会迷失方向
-**正确做法：具体明确：** "修复 agent-tool-abort.test.ts" - 聚焦的范围
-
-**错误做法：无上下文：** "修复竞态条件" - 智能体不知道在哪里
-**正确做法：提供上下文：** 粘贴错误信息和测试名称
-
-**错误做法：无约束：** 智能体可能会重构所有代码
-**正确做法：设置约束：** "不要修改生产代码" 或 "只修复测试"
-
-**错误做法：模糊的输出要求：** "修好它" - 你不知道改了什么
-**正确做法：明确要求：** "返回根因和修改内容的总结"
-
-## 不适用的场景
-
-**关联性失败：** 修复一个可能修复其他的——先一起排查
-**需要完整上下文：** 理解问题需要看到整个系统
-**探索性调试：** 你还不知道什么坏了
-**共享状态：** 智能体会互相干扰（编辑同一文件、使用同一资源）
-
-## 实际案例
-
-**场景：** 大规模重构后，3 个文件中出现 6 个测试失败
-
-**失败情况：**
-- agent-tool-abort.test.ts：3 个失败（时序问题）
-- batch-completion-behavior.test.ts：2 个失败（工具未执行）
-- tool-approval-race-conditions.test.ts：1 个失败（执行计数 = 0）
-
-**决策：** 独立的问题域——中止逻辑、批量完成、竞态条件各自独立
-
-**分派：**
-```
-智能体 1 → 修复 agent-tool-abort.test.ts
-智能体 2 → 修复 batch-completion-behavior.test.ts
-智能体 3 → 修复 tool-approval-race-conditions.test.ts
-```
-
-**结果：**
-- 智能体 1：用基于事件的等待替换了超时
-- 智能体 2：修复了事件结构 bug（threadId 位置不对）
-- 智能体 3：添加了等待异步工具执行完成的逻辑
-
-**集成：** 所有修复互相独立，无冲突，完整测试套件全部通过
-
-**节省的时间：** 3 个问题并行解决 vs 顺序解决
-
-## 核心优势
-
-1. **并行化** - 多个排查同时进行
-2. **聚焦** - 每个智能体范围窄，需要跟踪的上下文少
-3. **独立性** - 智能体之间互不干扰
-4. **速度** - 3 个问题在 1 个问题的时间内解决
-
-## 验证
-
-智能体返回后：
-1. **审查每个总结** - 理解改了什么
-2. **检查冲突** - 智能体是否编辑了同一段代码？
-3. **运行完整套件** - 验证所有修复协同工作
-4. **抽查** - 智能体可能犯系统性错误
-
-## 实际效果
-
-来自调试会话（2025-10-03）：
-- 3 个文件中 6 个失败
-- 并行分派 3 个智能体
-- 所有排查并发完成
-- 所有修复成功集成
-- 智能体之间的更改零冲突