@winspan/claude-forge 8.53.2 → 8.54.3

package/src/skills/official/find-skills.md

@@ -1,142 +0,0 @@
----
-name: find-skills
-description: Helps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skill should be used when the user is looking for functionality that might exist as an installable skill.
----
-
-# Find Skills
-
-This skill helps you discover and install skills from the open agent skills ecosystem.
-
-## When to Use This Skill
-
-Use this skill when the user:
-
-- Asks "how do I do X" where X might be a common task with an existing skill
-- Says "find a skill for X" or "is there a skill for X"
-- Asks "can you do X" where X is a specialized capability
-- Expresses interest in extending agent capabilities
-- Wants to search for tools, templates, or workflows
-- Mentions they wish they had help with a specific domain (design, testing, deployment, etc.)
-
-## What is the Skills CLI?
-
-The Skills CLI (`npx skills`) is the package manager for the open agent skills ecosystem. Skills are modular packages that extend agent capabilities with specialized knowledge, workflows, and tools.
-
-**Key commands:**
-
-- `npx skills find [query]` - Search for skills interactively or by keyword
-- `npx skills add <package>` - Install a skill from GitHub or other sources
-- `npx skills check` - Check for skill updates
-- `npx skills update` - Update all installed skills
-
-**Browse skills at:** https://skills.sh/
-
-## How to Help Users Find Skills
-
-### Step 1: Understand What They Need
-
-When a user asks for help with something, identify:
-
-1. The domain (e.g., React, testing, design, deployment)
-2. The specific task (e.g., writing tests, creating animations, reviewing PRs)
-3. Whether this is a common enough task that a skill likely exists
-
-### Step 2: Check the Leaderboard First
-
-Before running a CLI search, check the [skills.sh leaderboard](https://skills.sh/) to see if a well-known skill already exists for the domain. The leaderboard ranks skills by total installs, surfacing the most popular and battle-tested options.
-
-For example, top skills for web development include:
-- `vercel-labs/agent-skills` — React, Next.js, web design (100K+ installs each)
-- `anthropics/skills` — Frontend design, document processing (100K+ installs)
-
-### Step 3: Search for Skills
-
-If the leaderboard doesn't cover the user's need, run the find command:
-
-```bash
-npx skills find [query]
-```
-
-For example:
-
-- User asks "how do I make my React app faster?" → `npx skills find react performance`
-- User asks "can you help me with PR reviews?" → `npx skills find pr review`
-- User asks "I need to create a changelog" → `npx skills find changelog`
-
-### Step 4: Verify Quality Before Recommending
-
-**Do not recommend a skill based solely on search results.** Always verify:
-
-1. **Install count** — Prefer skills with 1K+ installs. Be cautious with anything under 100.
-2. **Source reputation** — Official sources (`vercel-labs`, `anthropics`, `microsoft`) are more trustworthy than unknown authors.
-3. **GitHub stars** — Check the source repository. A skill from a repo with <100 stars should be treated with skepticism.
-
-### Step 5: Present Options to the User
-
-When you find relevant skills, present them to the user with:
-
-1. The skill name and what it does
-2. The install count and source
-3. The install command they can run
-4. A link to learn more at skills.sh
-
-Example response:
-
-```
-I found a skill that might help! The "react-best-practices" skill provides
-React and Next.js performance optimization guidelines from Vercel Engineering.
-(185K installs)
-
-To install it:
-npx skills add vercel-labs/agent-skills@react-best-practices
-
-Learn more: https://skills.sh/vercel-labs/agent-skills/react-best-practices
-```
-
-### Step 6: Offer to Install
-
-If the user wants to proceed, you can install the skill for them:
-
-```bash
-npx skills add <owner/repo@skill> -g -y
-```
-
-The `-g` flag installs globally (user-level) and `-y` skips confirmation prompts.
-
-## Common Skill Categories
-
-When searching, consider these common categories:
-
-| Category        | Example Queries                          |
-| --------------- | ---------------------------------------- |
-| Web Development | react, nextjs, typescript, css, tailwind |
-| Testing         | testing, jest, playwright, e2e           |
-| DevOps          | deploy, docker, kubernetes, ci-cd        |
-| Documentation   | docs, readme, changelog, api-docs        |
-| Code Quality    | review, lint, refactor, best-practices   |
-| Design          | ui, ux, design-system, accessibility     |
-| Productivity    | workflow, automation, git                |
-
-## Tips for Effective Searches
-
-1. **Use specific keywords**: "react testing" is better than just "testing"
-2. **Try alternative terms**: If "deploy" doesn't work, try "deployment" or "ci-cd"
-3. **Check popular sources**: Many skills come from `vercel-labs/agent-skills` or `ComposioHQ/awesome-claude-skills`
-
-## When No Skills Are Found
-
-If no relevant skills exist:
-
-1. Acknowledge that no existing skill was found
-2. Offer to help with the task directly using your general capabilities
-3. Suggest the user could create their own skill with `npx skills init`
-
-Example:
-
-```
-I searched for skills related to "xyz" but didn't find any matches.
-I can still help you with this task directly! Would you like me to proceed?
-
-If this is something you do often, you could create your own skill:
-npx skills init my-xyz-skill
-```

package/src/skills/official/official-api-design.md

@@ -1,30 +0,0 @@
----
-name: official-api-design
-version: 1.0.0
-description: "API 设计规范：RESTful/RPC 接口设计最佳实践"
-tags: [api, rest, design, backend]
----
-
-# API 设计规范
-
-## 设计顺序
-1. 先定义资源和操作（不要先想 URL）
-2. 写 OpenAPI/Protobuf 规格
-3. 用 mock 验证调用方能用
-4. 再实现
-
-## RESTful 规范
-- URL 用名词复数：`/users`，不用动词 `/getUser`
-- 用 HTTP 动词表达操作：GET/POST/PUT/PATCH/DELETE
-- 错误返回统一结构：`{ code, message, data }`
-- 分页用 `?page=1&size=20`，返回 `total`
-
-## 版本管理
-- URL 版本：`/api/v1/users`（推荐）
-- 破坏性变更必须升版本
-
-## 通用原则
-- 幂等性：PUT/DELETE 必须幂等
-- 认证统一走 Authorization header
-- 敏感字段不出现在 URL（用 body）
-- 响应时间 P99 < 200ms，超时统一 30s

package/src/skills/official/official-architecture-decision.md

@@ -1,41 +0,0 @@
----
-name: official-architecture-decision
-version: 1.0.0
-description: "架构决策记录（ADR）：结构化记录重要技术决策"
-tags: [architecture, adr, design, decision]
----
-
-# 架构决策记录（ADR）
-
-每个重要的技术决策都应该留下可追溯的记录。
-
-## 何时写 ADR
-- 技术选型（框架、数据库、消息队列）
-- 系统边界划分
-- 接口协议选择
-- 影响超过 1 个模块的设计决策
-
-## ADR 模板
-
-```markdown
-# ADR-{编号}: {标题}
-
-## 状态
-Proposed / Accepted / Deprecated
-
-## 背景
-为什么需要做这个决策？当前面临什么问题？
-
-## 决策
-我们选择做什么？
-
-## 备选方案
-考虑过哪些其他方案？为什么没选？
-
-## 后果
-这个决策带来什么好处？有什么代价或风险？
-```
-
-## 规则
-- ADR 一旦 Accepted 不得修改，只能新建 ADR 来废弃或替代
-- 存放在项目 `docs/adr/` 目录

package/src/skills/official/official-bmad.md

@@ -1,118 +0,0 @@
----
-name: official-bmad
-version: 1.0.1
-description: "BMAD 方法论：四角色敏捷协作指南（完整四阶段流程）"
-tags: [bmad, agile, four-role, collaboration]
----
-
-# BMAD 方法论（Four-Role Agile）
-
-BMAD 是一种四角色敏捷协作模式，适用于复杂功能开发和端到端的用户故事实现。
-
-## 核心理念
-
-通过明确的角色划分和阶段流程，确保需求、设计、实现和评审的质量。
-
-## 四个角色
-
-1. **Business（业务/产品经理）**：定义需求和验收标准
-2. **Maker（实现者/开发者）**：编写代码和实现功能
-3. **Architect（架构师）**：设计系统结构和接口
-4. **Developer（开发/集成者）**：集成和测试
-
----
-
-## 阶段 1：分析（Analyze）
-
-**角色**：Business + Architect
-
-**目标**：澄清需求，识别技术约束和依赖。
-
-**步骤**：
-1. 澄清需求（用户故事、验收标准）
-2. 识别技术约束和依赖
-3. 评估风险和可行性
-4. 定义输入输出和边界条件
-
-**输出**：需求文档（requirements document）
-
-**建议**：调用 `researcher` 或 `planner` Agent
-
----
-
-## 阶段 2：设计（Design）
-
-**角色**：Architect + Developer
-
-**目标**：设计技术方案和模块结构。
-
-**步骤**：
-1. 设计模块划分和接口
-2. 选择技术栈和工具
-3. 制定实施计划
-4. 设计数据流和架构图
-5. 定义模块间的接口契约
-
-**输出**：设计文档（design document）
-
-**建议**：调用 `planner` Agent
-
----
-
-## 阶段 3：实现（Implement）
-
-**角色**：Maker + Developer
-
-**目标**：按设计编写代码并集成。
-
-**步骤**：
-1. 按设计编写代码
-2. 编写单元测试
-3. 遵循编码规范
-4. 集成到主分支
-5. 编写清晰、可维护的代码
-
-**输出**：可运行的代码和测试
-
-**建议**：调用 `coder` 或 `feature-developer` Agent
-
----
-
-## 阶段 4：评审（Review）
-
-**角色**：全员（Tech Lead 主导）
-
-**目标**：确保代码质量、安全性和可维护性。
-
-**步骤**：
-1. Code review（检查代码质量）
-2. 功能验收（Business 验证是否满足需求）
-3. 技术债评估（Architect 审查架构合理性）
-4. 安全性检查
-5. 性能评估
-
-**输出**：评审报告（review report）
-
-**建议**：调用 `reviewer` Agent
-
----
-
-## 何时使用
-
-- 跨职能团队协作
-- 复杂功能需要多角色参与
-- 需要明确的职责划分
-- 用户故事级别的完整功能开发
-- Sprint 迭代开发
-- 端到端（end-to-end）功能实现
-
-## 决策规则
-
-- **简单功能**（complexity: simple）：只需实现阶段
-- **中等功能**（complexity: moderate）：设计 + 实现 + 评审
-- **复杂功能**（complexity: complex）：完整四阶段流程
-
-## 参考
-
-- BMAD Framework: https://bmad.dev
-- Four-Role Agile Development Methodology

package/src/skills/official/official-db-schema-design.md

@@ -1,34 +0,0 @@
----
-name: official-db-schema-design
-version: 1.0.0
-description: "数据库 Schema 设计：建模、迁移和演进最佳实践"
-tags: [database, schema, sql, migration]
----
-
-# 数据库 Schema 设计
-
-## 设计原则
-- 先建模（ER 图），再建表
-- 每张表只表达一个实体
-- 外键约束在数据库层面强制
-
-## 命名规范
-- 表名：snake_case 复数（`user_profiles`）
-- 主键：`id`（自增或 UUID）
-- 时间戳：`created_at`、`updated_at`（每张表必有）
-- 软删除：`deleted_at` nullable
-
-## 索引策略
-- 外键列必须建索引
-- 高频查询的 WHERE 条件列建索引
-- 复合索引遵循最左前缀原则
-
-## 迁移规范
-- 每次变更写迁移文件，不手动改生产库
-- 迁移必须可回滚（写 down migration）
-- 破坏性变更分三步：加新列 → 双写 → 删旧列
-
-## 常见陷阱
-- 不用 `ENUM` 类型，用关联表或字符串
-- JSON 列只存真正非结构化数据
-- 避免 EAV 模式（Entity-Attribute-Value）

package/src/skills/official/official-debug.md

@@ -1,25 +0,0 @@
----
-name: official-debug
-version: 1.2.0
-description: "系统化调试工作流：复现、隔离、修复、验证"
-tags: [debug, troubleshooting]
----
-
-# 系统化调试
-
-## 步骤
-
-1. **复现** — 确认 bug 可稳定复现
-   - 记录：环境、输入、期望行为、实际行为
-
-2. **隔离** — 缩小根因范围
-   - 二分法排查代码路径
-   - 检查近期变更（`git bisect`）
-   - 加日志，不要靠猜
-
-3. **假设** — 清晰陈述假设再验证，每次只验证一个
-
-4. **修复** — 最小化修复，解决根本原因
-   - 修复前先写一个能复现 bug 的测试
-
-5. **验证** — 原始 bug 消失 + 无回归 + 测试通过

package/src/skills/official/official-doc-driven.md

@@ -1,31 +0,0 @@
----
-name: official-doc-driven
-version: 1.0.0
-description: "文档驱动开发：先写文档再写代码，保持文档与代码同步"
-tags: [documentation, doc-driven, readme]
----
-
-# 文档驱动开发
-
-## 核心理念
-如果你无法清晰地写出来，说明你还没想清楚。先写文档，逼自己想清楚再动手。
-
-## 步骤
-
-1. **写 README 先于代码**
-   - 描述模块是什么、解决什么问题
-   - 写出使用示例（即使 API 还不存在）
-   - 示例写起来别扭 = 设计有问题
-
-2. **接口文档先于实现**
-   - 函数签名 + JSDoc/注释先写
-   - 参数、返回值、异常都要说明
-
-3. **保持同步**
-   - 代码变更时同步更新文档
-   - PR 模板加入"文档是否已更新"检查项
-
-## 文档层级
-- README：模块概述 + 快速开始
-- ARCHITECTURE.md：系统设计和关键决策
-- 代码注释：解释"为什么"，不解释"是什么"

package/src/skills/official/official-harness-engineering.md

@@ -1,108 +0,0 @@
----
-name: official-harness-engineering
-version: 2.0.1
-description: "Harness Engineering：为遗留代码建立测试防护网再安全修改（四阶段完整指南）"
-tags: [harness, testing, legacy, refactor]
----
-
-# Harness Engineering 方法论
-
-当需要重构遗留代码（尤其是缺少测试的代码）时，按以下四阶段推进。
-
-## 核心理念
-
-在修改任何现有代码前，先建立测试防护网（harness），确保改动不破坏现有行为。
-
-## 与 TDD 的区别
-- TDD 用于新功能开发（先测试后实现）
-- Harness Engineering 用于改动现有代码（先理解后保护再修改）
-
----
-
-## 阶段 1：理解现有实现（Understand）
-
-**目标**：深入理解代码的当前行为和依赖关系。
-
-**步骤**：
-1. 阅读目标代码，识别关键逻辑和边界条件
-2. 绘制依赖关系图（哪些模块依赖这段代码）
-3. 识别潜在的副作用和隐藏依赖
-4. 找到所有入口点和输出点
-5. 记录边界条件和隐含假设
-
-**输出**：行为文档（behavior document），记录当前实际行为
-
-**建议**：调用 `researcher` Agent 进行深度分析
-
----
-
-## 阶段 2：建立特征测试（Characterize）
-
-**目标**：为现有行为建立测试"安全网"。
-
-**步骤**：
-1. 编写特征测试（Characterization Tests）— 记录当前行为，无论对错
-2. 覆盖所有已知的输入输出组合
-3. 覆盖所有主要代码路径
-4. 确保测试全绿（即使代码有 bug，先记录现状）
-5. 目标覆盖率 > 80%
-
-**关键原则**：
-- 测试描述"代码现在做什么"，不是"应该做什么"
-- 全部通过后才能继续下一阶段
-
-**建议**：调用 `tester` Agent 编写测试
-
----
-
-## 阶段 3：安全重构（Refactor）
-
-**目标**：在测试保护下进行重构。
-
-**步骤**：
-1. 小步重构（每次改动后立即运行测试）
-2. 消除重复代码、提取函数、改善命名
-3. 保持测试全绿
-4. 每次只改一处，改完立即运行 harness
-5. 测试失败 = 立即回滚，不要积累未验证的变更
-
-**重构优先级**：
-- 消除重复代码
-- 提取函数和模块
-- 改善命名和注释
-- 简化复杂逻辑
-
-**建议**：调用 `refactor-specialist` Agent 执行重构
-
----
-
-## 阶段 4：验证重构结果（Verify）
-
-**目标**：确认重构没有破坏功能。
-
-**步骤**：
-1. 运行完整测试套件
-2. 手动验证关键路径
-3. Code review
-4. 对比原始行为文档，确认行为一致性
-5. 逐步替换：新行为用新测试覆盖，旧 harness 逐步退役
-
----
-
-## 何时使用
-
-- 遗留代码缺少测试
-- 代码复杂度高，不敢直接改
-- 需要大规模重构但风险高
-- 接手不熟悉的代码库
-- 修改高风险核心模块
-
-## 决策规则
-
-- **简单重构**（complexity: simple）：跳过理解阶段，直接建立特征测试
-- **中等重构**（complexity: moderate）：完整四阶段流程
-- **复杂迁移**（complexity: complex）：完整四阶段流程，额外谨慎
-
-## 参考
-
-- Michael Feathers, *Working Effectively with Legacy Code*

package/src/skills/official/official-performance-optimization.md

@@ -1,30 +0,0 @@
----
-name: official-performance-optimization
-version: 1.0.0
-description: "性能优化工作流：先度量再优化，数据驱动"
-tags: [performance, optimization, profiling]
----
-
-# 性能优化
-
-## 黄金法则
-**永远先度量，再优化。** 没有数据的优化是猜测。
-
-## 步骤
-
-1. **建立基线** — 用真实数据测量当前性能
-   - 定义指标：延迟（P50/P95/P99）、吞吐量、内存
-
-2. **找瓶颈** — Profile，不要猜
-   - CPU：火焰图；内存：heap 分析；I/O：慢查询日志
-
-3. **优化** — 从收益最大的瓶颈开始
-   - 算法复杂度 > 减少 I/O > 缓存 > 并发
-
-4. **验证** — 对比基线，功能测试全部通过
-
-## 常见优化方向（按收益排序）
-- 数据库：索引、消除 N+1、连接池
-- 缓存：热点数据、计算结果
-- 异步化：I/O 密集型操作
-- 批处理：替代逐条处理

package/src/skills/official/official-pr-review.md

@@ -1,35 +0,0 @@
----
-name: official-pr-review
-version: 1.2.0
-description: "结构化 PR 审查：覆盖正确性、安全性和可维护性"
-tags: [review, pr, quality]
----
-
-# Pull Request 审查
-
-## 审查顺序（重要性从高到低）
-
-### 1. 正确性
-- [ ] 逻辑在所有边界条件下正确
-- [ ] 错误处理恰当，异常不被静默吞掉
-- [ ] 无竞态条件或并发问题
-
-### 2. 安全性
-- [ ] 无注入漏洞（SQL、命令、XSS、SSRF）
-- [ ] 敏感数据未被日志记录或暴露
-- [ ] 权限检查在正确的层级
-
-### 3. 性能
-- [ ] 无 N+1 查询
-- [ ] 大数据量场景有分页或流式处理
-
-### 4. 可维护性
-- [ ] 代码可读，命名自文档化
-- [ ] 单一职责，函数不超过 40 行
-
-### 5. 测试
-- [ ] 新功能有对应测试
-- [ ] 边界条件有测试覆盖
-
-## 输出格式
-**[BLOCKER|MAJOR|MINOR]** `文件:行号` — 问题 → 建议

package/src/skills/official/official-release-checklist.md

@@ -1,30 +0,0 @@
----
-name: official-release-checklist
-version: 1.0.0
-description: "发布上线清单：从代码冻结到生产验证的完整流程"
-tags: [release, deploy, checklist, devops]
----
-
-# 发布上线清单
-
-## 发布前
-- [ ] 所有测试通过（单元、集成、E2E）
-- [ ] 代码已 review 并合并到主干
-- [ ] 数据库迁移脚本已准备，可回滚
-- [ ] 配置变更已确认（环境变量、feature flag）
-- [ ] 监控告警已配置
-- [ ] 回滚方案已明确
-
-## 发布中
-- [ ] 灰度/金丝雀发布（先放 5% 流量）
-- [ ] 观察关键指标 5 分钟：错误率、P99 延迟
-
-## 发布后
-- [ ] 生产环境冒烟测试
-- [ ] 监控观察 30 分钟
-- [ ] 通知相关方
-
-## 回滚触发条件
-- 错误率上升 > 1%
-- P99 延迟上升 > 50%
-- 出现 CRITICAL 级别日志

package/src/skills/official/official-security-hardening.md

@@ -1,32 +0,0 @@
----
-name: official-security-hardening
-version: 1.0.0
-description: "安全加固清单：覆盖 OWASP Top 10 和常见安全实践"
-tags: [security, owasp, hardening]
----
-
-# 安全加固
-
-## 输入验证
-- 所有外部输入在边界处验证（类型、长度、格式）
-- 参数化查询，禁止字符串拼接 SQL
-- 文件上传：验证类型、大小、存储路径隔离
-
-## 认证与授权
-- 密码：bcrypt/argon2 哈希，禁止 MD5/SHA1
-- Token：短有效期 + refresh token 机制
-- 每个接口显式检查权限，不依赖前端隐藏
-
-## 数据保护
-- 敏感字段（密码、密钥、PII）不写日志
-- HTTPS only，HSTS header
-- 密钥走环境变量，不进代码库
-
-## 依赖安全
-- 定期运行 `npm audit` / `pip audit` / `govulncheck`
-- lockfile 提交到仓库
-
-## 常见漏洞速查
-- XSS：输出时转义，CSP header
-- CSRF：SameSite cookie + CSRF token
-- SSRF：白名单限制外部请求目标

package/src/skills/official/official-spec-driven-design.md

@@ -1,31 +0,0 @@
----
-name: official-spec-driven-design
-version: 1.0.0
-description: "SDD：先写规格文档再写代码，需求驱动实现"
-tags: [sdd, spec, design, requirements]
----
-
-# Spec-Driven Design（规格驱动开发）
-
-在写任何代码之前，先把规格写清楚。规格是代码的合同。
-
-## 步骤
-
-1. **写 SPEC.md**，包含：
-   - 功能目标（一句话）
-   - 输入/输出定义（含类型和边界）
-   - 不做什么（明确排除项）
-   - 验收标准（可测试的条件列表）
-
-2. **评审规格** — 在写代码前确认规格无歧义
-   - 每条验收标准都能写成测试吗？
-   - 边界条件是否覆盖？
-
-3. **按规格实现** — 代码只做规格里写的事
-   - 遇到规格未覆盖的情况，先更新规格再写代码
-
-4. **验收** — 逐条对照验收标准，全部通过才算完成
-
-## 规则
-- 规格变更必须先于代码变更
-- 实现不得超出规格范围（避免过度设计）