csxj2026/junhong_cmp_fiber
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

重置项目上下文与规范文档

Browse Source
This commit is contained in:
break
2026-08-07 16:18:07 +08:00
parent 6611ca5226
commit 79e2d9ff92
1900 changed files with 1552 additions and 348365 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
.claude/settings.json
View File

@@ -1,5 +0,0 @@
{
"enabledPlugins": {
"ralph-loop@claude-plugins-official": true
}
}

151
.claude/skills/api-routing/SKILL.md
View File

@@ -1,151 +0,0 @@
---
name: api-routing
description: API 路由注册规范。注册新 API 路由、添加新 Handler 时使用。包含 Register() 函数用法、RouteSpec 必填项、文档生成器更新等规范。
---
# API 路由注册规范
**所有 HTTP 接口必须使用统一的 `Register()` 函数注册，以自动加入 OpenAPI 文档生成。**
## 触发条件
在以下情况下必须遵守本规范：
- 注册新的 API 路由
- 修改现有路由配置
- **添加新的 Handler（必须同步更新文档生成器！）**
## 新增 Handler 检查清单（⚠️ 最容易遗漏）
新增 Handler 时，必须完成以下 **4 个步骤**，否则接口不会出现在 OpenAPI 文档中：
| 步骤 | 文件 | 操作 |
|------|------|------|
| 1️⃣ | `internal/bootstrap/types.go` | 添加 Handler 字段 |
| 2️⃣ | `internal/bootstrap/handlers.go` | 实例化 Handler |
| 3️⃣ | `internal/routes/admin.go` | 调用路由注册函数 |
| 4️⃣ | `cmd/api/docs.go` + `cmd/gendocs/main.go` | **添加到文档生成器** |
### 步骤 4 详解（最常遗漏！）
```go
// cmd/api/docs.go 和 cmd/gendocs/main.go 都要改！
handlers := &bootstrap.Handlers{
// ... 现有 Handler
IotCard: admin.NewIotCardHandler(nil), // 添加
IotCardImport: admin.NewIotCardImportHandler(nil), // 添加
}
```
## 核心规则
### 必须使用 Register() 函数
```go
// ✅ 正确
Register(router, doc, basePath, "POST", "/shops", handler.Create, RouteSpec{
Summary: "创建店铺",
Tags: []string{"店铺管理"},
Input: new(model.CreateShopRequest),
Output: new(model.ShopResponse),
Auth: true,
})
// ❌ 错误：直接注册不会生成文档
router.Post("/shops", handler.Create)
```
## RouteSpec 必填项
| 字段 | 类型 | 说明 | 示例 |
|------|------|------|------|
| `Summary` | string | 操作说明（中文，简短） | `"创建店铺"` |
| `Tags` | []string | 分类标签（用于文档分组） | `[]string{"店铺管理"}` |
| `Input` | interface{} | 请求 DTO（`nil` 表示无参数） | `new(model.CreateShopRequest)` |
| `Output` | interface{} | 响应 DTO（`nil` 表示无返回） | `new(model.ShopResponse)` |
| `Auth` | bool | 是否需要认证 | `true` |
## 常见路由模式
### CRUD 路由组
```go
// 列表查询
Register(router, doc, basePath, "GET", "/shops", handler.List, RouteSpec{
Summary: "获取店铺列表",
Tags: []string{"店铺管理"},
Input: new(model.ListShopRequest),
Output: new(model.ShopListResponse),
Auth: true,
})
// 详情查询
Register(router, doc, basePath, "GET", "/shops/:id", handler.Get, RouteSpec{
Summary: "获取店铺详情",
Tags: []string{"店铺管理"},
Input: new(model.IDReq),
Output: new(model.ShopResponse),
Auth: true,
})
// 创建
Register(router, doc, basePath, "POST", "/shops", handler.Create, RouteSpec{
Summary: "创建店铺",
Tags: []string{"店铺管理"},
Input: new(model.CreateShopRequest),
Output: new(model.ShopResponse),
Auth: true,
})
// 更新
Register(router, doc, basePath, "PUT", "/shops/:id", handler.Update, RouteSpec{
Summary: "更新店铺",
Tags: []string{"店铺管理"},
Input: new(model.UpdateShopRequest),
Output: new(model.ShopResponse),
Auth: true,
})
// 删除
Register(router, doc, basePath, "DELETE", "/shops/:id", handler.Delete, RouteSpec{
Summary: "删除店铺",
Tags: []string{"店铺管理"},
Input: new(model.IDReq),
Output: nil,
Auth: true,
})
```
### 无认证路由
```go
// 公开接口（如健康检查）
Register(router, doc, basePath, "GET", "/health", handler.Health, RouteSpec{
Summary: "健康检查",
Tags: []string{"系统"},
Input: nil,
Output: new(model.HealthResponse),
Auth: false,
})
```
## AI 助手检查清单
### 注册路由时
1. ✅ 是否使用 `Register()` 函数而非直接注册
2. ✅ `Summary` 是否使用中文简短描述
3. ✅ `Tags` 是否正确分组
4. ✅ `Input` 和 `Output` 是否指向正确的 DTO
5. ✅ `Auth` 是否根据业务需求正确设置
### 新增 Handler 时（⚠️ 必查）
1. ✅ `internal/bootstrap/types.go` 添加了 Handler 字段
2. ✅ `internal/bootstrap/handlers.go` 实例化了 Handler
3. ✅ `internal/routes/admin.go` 调用了路由注册函数
4. ✅ **`cmd/api/docs.go` 添加了 Handler**
5. ✅ **`cmd/gendocs/main.go` 添加了 Handler**
6. ✅ 运行 `go run cmd/gendocs/main.go` 验证文档生成
7. ✅ 运行 `grep "接口路径" docs/admin-openapi.yaml` 确认接口存在
**完整指南**: 参见 [`docs/api-documentation-guide.md`](docs/api-documentation-guide.md)

1
.claude/skills/ask-matt
View File

@@ -1 +0,0 @@
../../.agents/skills/ask-matt

1
.claude/skills/caveman
View File

@@ -1 +0,0 @@
../../.agents/skills/caveman

1
.claude/skills/code-review
View File

@@ -1 +0,0 @@
../../.agents/skills/code-review

1
.claude/skills/codebase-design
View File

@@ -1 +0,0 @@
../../.agents/skills/codebase-design

139
.claude/skills/comment-standards/SKILL.md
View File

@@ -1,139 +0,0 @@
---
name: comment-standards
description: Go 注释规范。编写 Go 代码注释、文档注释时使用。包含包注释、结构体注释、接口注释、函数注释、内联注释的完整规范与示例。
---
# Go 注释规范
**基本原则**：
- **所有注释使用中文**
- **导出符号必须有文档注释**（包、函数、方法、类型、接口、常量、变量）
- **复杂逻辑必须有实现注释**（解释"为什么"，而不是"做了什么"）
- **禁止废话注释**（不要用注释复述代码本身）
- **修改代码时必须同步更新注释**
---
## 包注释
每个包的入口文件（通常是主文件或 `doc.go`）必须有包注释：
```go
// Package account 提供账号管理的业务逻辑服务
// 包含账号创建、修改、删除、权限分配等功能
package account
```
## 结构体注释
所有导出结构体必须有文档注释，说明该结构体代表什么：
```go
// Service 账号业务服务
// 负责账号的 CRUD、角色分配、密码管理等业务逻辑
type Service struct {
store *Store
auditService AuditServiceInterface
}
```
## 接口注释
导出接口必须注释接口用途，每个方法必须说明契约：
```go
// PermissionChecker 权限检查器接口
// 用于查询用户的权限列表
type PermissionChecker interface {
// CheckPermission 检查用户是否拥有指定权限
// userID: 用户ID
// permCode: 权限编码（格式: module:action）
// platform: 端口类型 (all/web/h5)
CheckPermission(ctx context.Context, userID uint, permCode string, platform string) (bool, error)
}
```
## 函数和方法注释
**导出函数/方法**必须以函数名开头，说明功能：
```go
// Create 创建账号
// POST /api/admin/accounts
func (h *AccountHandler) Create(c *fiber.Ctx) error {
```
**复杂方法**（超过 30 行或包含复杂业务逻辑）必须额外说明实现思路：
```go
// ActivateByRealname 首次实名激活套餐
// 当用户完成实名认证后，自动激活处于"囤货待实名"状态的套餐：
// 1. 查找该卡所有 status=3（待实名激活）的套餐
// 2. 按创建时间排序，第一个主套餐立即激活（status=1）
// 3. 其余主套餐进入排队状态（status=4）
// 4. 加油包如果绑定了已激活的主套餐则一并激活
func (s *UsageService) ActivateByRealname(ctx context.Context, cardID uint) error {
```
**未导出函数/方法**：
- 简单逻辑（< 15 行）：可以不加注释
- 复杂逻辑（≥ 15 行）或非显而易见的算法：必须加注释
```go
// buildPermissionTree 递归构建权限树
// 采用 map 索引 + 单次遍历算法，时间复杂度 O(n)
func (s *Service) buildPermissionTree(permissions []*model.Permission) []*dto.PermissionTreeNode {
```
## 常量和枚举注释
分组常量必须有组注释，每个值必须有行内注释：
```go
// 用户类型常量
const (
UserTypeSuperAdmin = 1 // 超级管理员
UserTypePlatform = 2 // 平台用户
UserTypeAgent = 3 // 代理账号
UserTypeEnterprise = 4 // 企业账号
)
```
## 内联注释规范
**必须添加内联注释的场景**：
| 场景 | 要求 |
|------|------|
| 复杂条件判断 | 解释判断的业务含义 |
| 多步骤业务流程 | 用编号注释标明每一步 |
| 非显而易见的设计决策 | 解释"为什么这样做"而不是"做了什么" |
| 缓存/事务/并发处理 | 说明策略和原因 |
| 临时方案/兼容逻辑 | 标注 TODO 或说明背景 |
**✅ 好的内联注释（解释为什么）**：
```go
// 使用 Redis 分布式锁防止并发重复创建，锁超时 10 秒
if !s.acquireLock(ctx, lockKey, 10*time.Second) {
return errors.New(errors.CodeTooManyRequests, "操作过于频繁，请稍后重试")
}
// 先冻结佣金再扣款，保证资金安全（失败时佣金自动解冻）
if err := s.freezeCommission(ctx, tx, orderID); err != nil {
return err
}
```
**❌ 废话注释（禁止）**：
```go
// 获取用户ID ← 禁止：代码本身已经很清楚
userID := middleware.GetUserIDFromContext(ctx)
// 创建账号 ← 禁止：变量名已说明意图
account := &model.Account{}
// 返回错误 ← 禁止：return err 不需要注释
return err
```

212
.claude/skills/db-migration/SKILL.md
View File

@@ -1,212 +0,0 @@
---
name: db-migration
description: 数据库迁移规范。创建迁移、修改数据库结构、执行 migrate 命令时使用。包含迁移工具、文件规范、执行流程、失败处理等完整指南。
---
# 数据库迁移规范
**项目使用 golang-migrate 进行数据库迁移管理。**
## 触发条件
在以下情况下必须遵守本规范：
- 创建新的数据库迁移
- 修改数据库表结构
- 执行 `make migrate-*` 命令
- 处理迁移失败问题
## 基本命令
```bash
# 查看当前迁移版本
make migrate-version
# 执行所有待迁移
make migrate-up
# 回滚上一次迁移
make migrate-down
# 创建新迁移文件
make migrate-create
# 然后输入迁移名称，例如: add_user_email
```
## 迁移文件规范
### 文件位置和命名
迁移文件位于 `migrations/` 目录：
```
migrations/
├── 000001_initial_schema.up.sql
├── 000001_initial_schema.down.sql
├── 000002_add_user_email.up.sql
├── 000002_add_user_email.down.sql
```
**命名规范**:
- 格式: `{序号}_{描述}.{up|down}.sql`
- 序号: 6位数字，从 000001 开始
- 描述: 小写英文，用下划线分隔
- up: 应用迁移（向前）
- down: 回滚迁移（向后）
### 编写规范
```sql
-- up.sql 示例
-- 添加字段时必须考虑向后兼容
ALTER TABLE tb_users
ADD COLUMN email VARCHAR(100);
-- 添加注释
COMMENT ON COLUMN tb_users.email IS '用户邮箱';
-- 为现有数据设置默认值（如果需要）
UPDATE tb_users SET email = '' WHERE email IS NULL;
-- down.sql 示例
ALTER TABLE tb_users
DROP COLUMN IF EXISTS email;
```
## 迁移执行流程（必须遵守）
当你创建迁移文件后，**必须**执行以下验证步骤：
### 1. 执行迁移
```bash
make migrate-up
```
### 2. 验证迁移状态
```bash
make migrate-version
# 确认版本号已更新且 dirty=false
```
### 3. 验证数据库结构
使用 PostgreSQL MCP 工具检查：
- 字段是否正确创建
- 类型是否符合预期
- 默认值是否正确
- 注释是否存在
```
PostgresGetObjectDetails:
- schema_name: "public"
- object_name: "tb_users"
- object_type: "table"
```
### 4. 验证查询功能
编写临时脚本测试新字段的查询功能
### 5. 更新 Model
在 `internal/model/` 中添加对应字段
### 6. 清理测试数据
如果插入了测试数据，记得清理
## 迁移失败处理
如果迁移执行失败，数据库会被标记为 dirty 状态：
```bash
# 1. 检查错误原因
make migrate-version
# 如果显示 dirty=true，说明迁移失败
# 2. 手动修复数据库状态
# 使用 PostgreSQL MCP 连接数据库
# 检查失败的迁移是否部分执行
# 手动清理或完成迁移
# 3. 清除 dirty 标记
UPDATE schema_migrations SET dirty = false WHERE version = {失败的版本号};
# 4. 修复迁移文件中的错误
# 5. 重新执行迁移
make migrate-up
```
## 迁移最佳实践
### 1. 向后兼容
- 添加字段时使用 `DEFAULT` 或允许 NULL
- 删除字段前确保代码已不再使用
- 修改字段类型要考虑数据转换
### 2. 原子性
- 每个迁移文件只做一件事
- 复杂变更拆分成多个迁移
### 3. 可回滚
- down.sql 必须能完整回滚 up.sql 的所有变更
- 测试回滚功能: `make migrate-down && make migrate-up`
### 4. 注释完整
- 迁移文件顶部说明变更原因
- 关键 SQL 添加行内注释
- 数据库字段使用 COMMENT 添加说明
### 5. 测试数据
- 不要在迁移文件中插入业务数据
- 可以插入配置数据或枚举值
- 测试数据用临时脚本处理
## PostgreSQL MCP 工具使用
### 查看表结构
```
PostgresGetObjectDetails:
- schema_name: "public"
- object_name: "tb_permission"
- object_type: "table"
```
### 列出所有表
```
PostgresListObjects:
- schema_name: "public"
- object_type: "table"
```
### 执行查询
```
PostgresExecuteSql:
- sql: "SELECT * FROM tb_permission LIMIT 5"
```
## 注意事项
- ⚠️ MCP 工具只支持只读查询（SELECT）
- ⚠️ 不要直接修改数据，修改必须通过迁移文件
- ⚠️ 测试数据可以通过临时 Go 脚本插入
## AI 助手检查清单
创建迁移后必须：
1. ✅ 执行 `make migrate-up`
2. ✅ 执行 `make migrate-version` 确认成功
3. ✅ 使用 PostgresGetObjectDetails 验证表结构
4. ✅ 在 `internal/model/` 中更新对应 Model
5. ✅ 测试回滚：`make migrate-down && make migrate-up`

151
.claude/skills/db-validation/SKILL.md
View File

@@ -1,151 +0,0 @@
---
name: db-validation
description: 数据库验证规范。测试 API 接口、验证业务逻辑、调试数据问题时使用。包含 PostgreSQL MCP 工具使用方法和验证示例。
---
# 数据库验证规范
**AI 在测试接口或验证业务逻辑时，必须使用 PostgreSQL MCP 工具直接查询数据库验证数据的正确性。**
## 触发条件
在以下情况下必须遵守本规范：
- 测试 API 接口后验证数据
- 检查数据库表结构
- 验证数据库迁移结果
- 调试业务逻辑
- 验证事务处理
- 检查数据权限过滤
## 何时使用 PostgreSQL MCP
### ✅ 必须使用的场景
- 测试 API 接口后验证数据是否正确写入数据库
- 检查数据库表结构是否符合 Model 定义
- 验证数据库迁移是否成功执行
- 调试业务逻辑时查看实际数据状态
- 验证事务是否正确提交或回滚
- 检查数据权限过滤是否生效
### ❌ 不要
- 仅依赖 API 响应判断数据是否正确（响应可能只是内存中的临时数据）
- 通过日志推测数据库状态
- 假设代码逻辑正确就认为数据正确
## 可用的 PostgreSQL MCP 工具
```
1. PostgresListSchemas - 列出所有数据库模式
2. PostgresListObjects - 列出指定模式下的表/视图/序列
3. PostgresGetObjectDetails - 查看表结构详情（字段、类型、约束、注释）
4. PostgresExecuteSql - 执行只读 SQL 查询（SELECT）
```
## 验证示例
### 场景 1：测试创建用户接口
```
1. 调用 POST /api/v1/accounts 创建用户
→ 响应：{"code":0, "data":{"id":123, "username":"testuser"}}
2. ✅ 使用 PostgreSQL MCP 验证数据库
PostgresExecuteSql:
- sql: "SELECT id, username, user_type, status, created_at FROM tb_account WHERE id = 123"
3. 检查查询结果：
✅ 用户确实已创建
✅ 字段值与请求参数一致
✅ status = 1（启用）
✅ created_at 有值
```
### 场景 2：测试数据权限过滤
```
1. 以代理用户登录，查询店铺列表
→ 响应：返回 5 个店铺
2. ✅ 使用 PostgreSQL MCP 验证过滤逻辑
PostgresExecuteSql:
- sql: "SELECT id, shop_name, parent_id FROM tb_shop WHERE deleted_at IS NULL"
3. 检查：
✅ 数据库实际有 10 个店铺
✅ API 只返回了当前用户及下级的 5 个店铺
✅ 数据权限过滤生效
```
### 场景 3：验证迁移执行
```
1. 执行迁移：make migrate-up
2. ✅ 验证表结构
PostgresGetObjectDetails:
- schema_name: "public"
- object_name: "tb_account"
- object_type: "table"
3. 检查：
✅ 新字段 enterprise_id 已添加
✅ 类型为 bigint
✅ 允许 NULL
✅ 注释为"企业ID"
```
## 工具使用方法
### 查看表结构
```
PostgresGetObjectDetails:
- schema_name: "public"
- object_name: "tb_permission"
- object_type: "table"
```
### 列出所有表
```
PostgresListObjects:
- schema_name: "public"
- object_type: "table"
```
### 执行查询
```
PostgresExecuteSql:
- sql: "SELECT * FROM tb_permission LIMIT 5"
```
## 注意事项
### ⚠️ 限制
- PostgreSQL MCP 只支持只读查询（SELECT），不能执行 INSERT/UPDATE/DELETE
- 如需插入测试数据，使用 Go 脚本或迁移文件
### ⚠️ 安全
- 避免在查询中暴露敏感数据（如密码哈希）
- 生产环境使用时需谨慎，避免查询大量数据
### ✅ 最佳实践
- 每次 API 测试后都验证数据库状态
- 使用 LIMIT 限制查询结果数量（如 `LIMIT 10`）
- 验证完成后清理测试数据
## AI 助手检查清单
测试接口后必须：
1. ✅ 使用 PostgresExecuteSql 查询相关数据
2. ✅ 验证数据是否正确写入
3. ✅ 验证字段值是否符合预期
4. ✅ 验证关联数据是否正确
5. ✅ 如有数据权限，验证过滤是否生效

1
.claude/skills/diagnose
View File

@@ -1 +0,0 @@
../../.agents/skills/diagnose

1
.claude/skills/diagnosing-bugs
View File

@@ -1 +0,0 @@
../../.agents/skills/diagnosing-bugs

141
.claude/skills/doc-management/SKILL.md
View File

@@ -1,141 +0,0 @@
---
name: doc-management
description: 规范文档管理。添加新规范、更新规范文档、维护 AGENTS.md 时使用。包含规范文档流程和维护规则。
---
# 规范文档管理
**当你需要为项目添加新的开发规范时，必须遵循以下流程。**
## 触发条件
在以下情况下必须遵守本规范：
- 添加新的开发规范
- 更新现有规范文档
- 维护 AGENTS.md 文件
- 创建技术指南文档
## 添加新规范的流程
### 步骤 1：创建详细规范文档
在 `docs/` 目录下创建详细的规范文档（Markdown 格式）：
```
docs/
├── api-documentation-guide.md # API 文档生成规范
├── code-review-checklist.md # 代码审查清单
├── testing-guide.md # 测试规范
└── ...
```
**文档内容要求**：
- ✅ 包含完整的规范说明、示例代码、常见问题
- ✅ 使用中文编写，代码示例使用英文
- ✅ 提供正确示例（✅）和错误示例（❌）的对比
- ✅ 包含故障排查和调试指南
### 步骤 2：在 AGENTS.md 中添加简短引导
在 `AGENTS.md` 的相关章节中添加**简短**的规范说明 + 引导链接：
```markdown
## XXX 规范
**核心要求：一句话说明最重要的规则。**
```go
// ✅ 正确示例（3-5 行）
...
// ❌ 错误示例（3-5 行）
...
```
**关键要点**：
- 规则 1
- 规则 2
- 规则 3
**完整指南**: 参见 [`docs/xxx-guide.md`](docs/xxx-guide.md)
```
**注意**：
- ⚠️ AGENTS.md 中的说明不超过 20 行
- ⚠️ 只保留最核心的规则和示例
- ⚠️ 必须包含引导链接到详细文档
### 步骤 3：在 README.md 中添加文档链接
在 `README.md` 的"## 文档"章节中添加链接：
```markdown
## 文档
### 开发规范
- **[API 文档生成规范](docs/api-documentation-guide.md)**：路由注册规范、DTO 规范、OpenAPI 文档生成流程
- **[XXX 规范](docs/xxx-guide.md)**：简短的一句话说明
```
**分类规则**：
- 开发规范：代码规范、API 规范、测试规范
- 功能指南：功能使用指南、配置指南
- 架构设计：设计文档、技术选型
## 规范文档的维护
### 更新规范时
1. 优先更新 `docs/` 下的详细文档
2. 如果核心规则变化，同步更新 AGENTS.md 中的简短说明
3. 保持 AGENTS.md 简洁，避免冗余
### 删除规范时
1. 删除 `docs/` 下的详细文档
2. 删除 AGENTS.md 中的相关章节
3. 删除 README.md 中的链接
4. 说明删除原因（在 commit message 中）
## Skill 规范管理
### 何时创建 Skill
当规范内容满足以下条件时，应该提取为 Skill：
- 内容超过 50 行
- 只在特定任务场景需要
- 包含详细的步骤和示例
### Skill 文件结构
```
.claude/skills/{skill-name}/
└── SKILL.md
```
### Skill 命名规范
- 使用小写字母和连字符
- 名称应描述规范主题
- 示例：`dto-standards`、`db-migration`、`api-routing`
### Skill Frontmatter
```yaml
---
name: skill-name
description: 简短描述（1-2 句话），说明何时使用此 skill
---
```
## AI 助手检查清单
添加/更新规范后必须：
1. ✅ 详细文档在 `docs/` 目录
2. ✅ AGENTS.md 中有简短引导（≤20 行）
3. ✅ README.md 中有文档链接
4. ✅ 如果内容 >50 行，考虑提取为 Skill
5. ✅ Skill 的 name 与目录名一致
6. ✅ Skill 的 description 清晰描述触发条件

1
.claude/skills/domain-modeling
View File

@@ -1 +0,0 @@
../../.agents/skills/domain-modeling

246
.claude/skills/dto-standards/SKILL.md
View File

@@ -1,246 +0,0 @@
---
name: dto-standards
description: DTO 数据传输对象规范。创建或修改 DTO 文件、请求/响应结构时使用。包含 description 标签、枚举字段、验证标签等规范。
---
# DTO 规范
**所有 DTO 文件必须遵循以下规范，这是 API 文档生成的基础。**
## 触发条件
在以下情况下必须遵守本规范：
- 创建或修改 `internal/model/` 下的请求/响应 DTO
- 创建 `XXXRequest`、`XXXResponse`、`XXXReq`、`XXXResp` 结构体
- 添加或修改 API 接口的输入输出参数
---
## 必须项（MUST）
### 1. Description 标签规范
**所有字段必须使用 `description` 标签，禁止使用行内注释**
❌ **错误**：
```go
type CreateUserRequest struct {
Username string `json:"username"` // 用户名
Status int `json:"status"` // 状态
}
```
✅ **正确**：
```go
type CreateUserRequest struct {
Username string `json:"username" description:"用户名"`
Status int `json:"status" description:"状态 (0:禁用, 1:启用)"`
}
```
### 2. 枚举字段：int vs string 选择
**必须按以下规则选择类型，禁止混用：**
| 场景 | 类型 | 示例 |
|------|------|------|
| 状态类（生命周期阶段） | `int` | 待支付→已完成→已关闭 |
| 布尔状态（启用/禁用） | `int` | `0=禁用, 1=启用` |
| 类型/方式类（种类） | `string` | `"wechat"`, `"single_card"` |
| 平台/标识符类 | `string` | `"web"`, `"h5"`, `"all"` |
```go
// ✅ 状态 → int
Status int `json:"status"`
PaymentStatus int `json:"payment_status"`
// ✅ 类型/方式 → string
PaymentMethod string `json:"payment_method" validate:"required,oneof=wechat offline"`
OrderType string `json:"order_type" validate:"required,oneof=single_card device"`
```
### 3. Int 状态值约定
#### 3.1 通用禁用/启用
**必须用全局常量，禁止自定义（尤其禁止 1=启用 2=禁用 这种反向写法）**：
```go
// pkg/constants/constants.go 已定义，直接使用
StatusDisabled = 0 // 禁用
StatusEnabled = 1 // 启用
```
✅ 正确：`description:"状态 (0:禁用, 1:启用)"`
❌ 禁止：`description:"状态 (1:启用, 2:禁用)"`
#### 3.2 生命周期状态
从 **1** 开始递增，0 不使用（避免与 Go 零值混淆）：
```go
const (
RechargeStatusPending = 1 // 待支付
RechargeStatusPaid = 2 // 已支付
RechargeStatusCompleted = 3 // 已完成
RechargeStatusClosed = 4 // 已关闭
)
```
### 4. 枚举列表必须从 constants 原文抄写
**DTO description 的枚举列表必须与 `pkg/constants/` 定义完全一致，不可凭记忆填写。**
操作步骤：
1. 先查/定义 `pkg/constants/` 中的枚举常量
2. 将常量注释**原文抄写**到 description
```go
// constants.go 中：
RechargeStatusPending = 1 // 待支付
RechargeStatusPaid = 2 // 已支付
RechargeStatusCompleted = 3 // 已完成
RechargeStatusClosed = 4 // 已关闭
RechargeStatusRefunded = 5 // 已退款
// DTO description 从上面抄：
Status int `json:"status" description:"状态 (1:待支付, 2:已支付, 3:已完成, 4:已关闭, 5:已退款)"`
```
❌ 禁止（description 与 constants 不一致，是历史 bug 的根因）：
```go
// constants 说 3=已完成，description 却写 3:已取消
Status int `json:"status" description:"状态 (1:待支付, 2:已完成, 3:已取消)"`
```
### 5. description 格式标准
**统一格式**：`字段含义 (值1:中文含义1, 值2:中文含义2)`
- 值与含义之间用**冒号** `:`（禁止用等号 `=`）
- 多个值之间用**逗号加空格** `, `
- 含义必须是**中文**
```go
// ✅ 统一格式
Status int `description:"状态 (1:待支付, 2:已支付, 3:已完成)"`
Platform string `description:"适用端口 (all:全部, web:Web后台, h5:H5端)"`
// ❌ 格式混乱
Status int `description:"状态 (0=禁用, 1=启用)"` // 用等号
Status int `description:"0=禁用 1=启用"` // 无括号无逗号
```
### 6. Response DTO 的状态字段必须同时返回 int 和 text
**所有 Response DTO 中的 int 状态字段，必须同时提供对应的 `_name` 文字字段。**
原因：防止前端维护映射表出错（历史上已有因此产生 bug 的案例）。
```go
// ✅ Response DTO 标准写法
type XxxResponse struct {
Status int `json:"status" description:"状态 (1:待支付, 2:已支付, 3:已完成, 4:已关闭, 5:已退款)"`
StatusName string `json:"status_name" description:"状态名称（中文）"`
}
// toResponse 函数中赋值
func rechargeStatusName(status int) string {
switch status {
case constants.RechargeStatusPending:
return "待支付"
case constants.RechargeStatusCompleted:
return "已完成"
// ...
default:
return "未知"
}
}
```
字段命名约定：`status` → `status_name`，`payment_status` → `payment_status_name`
**例外**：Request DTO（查询过滤、创建请求）不需要 `_name` 字段。
### 7. 验证标签与 OpenAPI 标签一致
```go
Username string `json:"username" validate:"required,min=3,max=50" required:"true" minLength:"3" maxLength:"50" description:"用户名"`
```
| validate 标签 | OpenAPI 标签 |
|--------------|--------------|
| `required` | `required:"true"` |
| `min=N,max=M`（数值） | `minimum:"N" maximum:"M"` |
| `min=N,max=M`（字符串） | `minLength:"N" maxLength:"M"` |
| `oneof=A B C` | description 中说明枚举值 |
### 8. 请求参数类型标签
```go
// Query 参数
type ListRequest struct {
Page int `json:"page" query:"page" validate:"omitempty,min=1" minimum:"1" description:"页码"`
Status *int `json:"status" query:"status" validate:"omitempty,min=1,max=4" minimum:"1" maximum:"4" description:"状态 (1:待支付, 2:已支付, 3:已完成, 4:已关闭)"`
}
// Path 参数
type IDReq struct {
ID uint `path:"id" description:"ID" required:"true"`
}
```
### 9. 响应 DTO 完整性
```go
type AccountResponse struct {
ID uint `json:"id" description:"账号ID"`
Username string `json:"username" description:"用户名"`
UserType int `json:"user_type" description:"用户类型 (1:超级管理员, 2:平台用户, 3:代理账号, 4:企业账号)"`
Status int `json:"status" description:"状态 (0:禁用, 1:启用)"`
StatusName string `json:"status_name" description:"状态名称（中文）"`
CreatedAt string `json:"created_at" description:"创建时间"`
UpdatedAt string `json:"updated_at" description:"更新时间"`
}
```
---
## AI 助手必须执行的检查
**在创建或修改任何 DTO 文件后，必须执行以下检查：**
1. ✅ 所有字段有 `description` 标签（无行内注释）
2. ✅ 枚举类型选择正确（状态用 int，类型/方式用 string）
3. ✅ 禁用/启用使用 `0=禁用, 1=启用`（禁止 1=启用 2=禁用）
4. ✅ description 枚举列表已从 `pkg/constants/` 原文抄写，无遗漏
5. ✅ description 格式统一（冒号 `:`，括号，逗号）
6. ✅ Response DTO 有 `_name` 伴生字段
7. ✅ validate 标签与 OpenAPI 标签一致
8. ✅ 重新生成 OpenAPI 文档验证：`go run cmd/gendocs/main.go`
**完整枚举规范**: 参见 [`docs/enum-status-standards.md`](../../docs/enum-status-standards.md)
---
## 常见枚举字段标准值
```go
// 用户类型（从 constants.UserType* 抄）
description:"用户类型 (1:超级管理员, 2:平台用户, 3:代理账号, 4:企业账号)"
// 通用启用/禁用（从 constants.StatusEnabled/Disabled 抄）
description:"状态 (0:禁用, 1:启用)"
// 充值状态（从 constants.RechargeStatus* 抄）
description:"状态 (1:待支付, 2:已支付, 3:已完成, 4:已关闭, 5:已退款)"
// 权限类型
description:"权限类型 (1:菜单, 2:按钮)"
// 适用端口
description:"适用端口 (all:全部, web:Web后台, h5:H5端)"
// 店铺层级
description:"店铺层级 (1-7级)"
```

1
.claude/skills/grill-me
View File

@@ -1 +0,0 @@
../../.agents/skills/grill-me

1
.claude/skills/grill-with-docs
View File

@@ -1 +0,0 @@
../../.agents/skills/grill-with-docs

1
.claude/skills/grilling
View File

@@ -1 +0,0 @@
../../.agents/skills/grilling

1
.claude/skills/handoff
View File

@@ -1 +0,0 @@
../../.agents/skills/handoff

777
.claude/skills/hurl-test/SKILL.md
View File

@@ -1,777 +0,0 @@
---
name: hurl-test
description: Hurl 接口测试生成器。用户描述要测试的接口或业务流程，自动探索代码、确认需求、生成完整的 .hurl 测试文件（含 DTO 驱动的字段完整性断言）。触发词：测试、hurl、写测试、接口测试。
---
# Hurl 接口测试生成器
**用户描述要测试什么，你来读代码、问确认、生成 .hurl 文件。**
适用于任何后端项目（Go / Python / Node / Java 等），不预设框架和目录结构。
---
## 触发条件
以下情况必须使用本 Skill：
- 用户说"测试 XX 接口"、"写 hurl 测试"、"给 XX 加测试"
- 用户说"测试 XX 流程"、"测试 XX 的业务逻辑"
- 用户说"验证 XX 接口的字段"、"测试接口契约"
- 用户提到 hurl、.hurl、接口测试、集成测试、冒烟测试
---
## 四阶段工作流（必须按顺序执行）
```
Phase 1: 探索 → Phase 2: 确认 → Phase 3: 生成 → Phase 4: 验证
读代码搞清楚 展示给用户确认 输出 .hurl 文件 语法检查 + 试跑
```
---
### Phase 1: 探索（Explore）
**目标：读代码，搞清楚项目约定 + 涉及的接口 + 字段 + 依赖。**
#### 1.1 项目画像（首次使用时必须执行，后续复用）
首次为项目生成 Hurl 测试时，先回答以下问题（通过读代码，不要猜）：
| 问题 | 怎么找 |
|------|--------|
| **语言/框架** | 看 go.mod / package.json / requirements.txt / pom.xml |
| **路由注册在哪** | 搜索 `router`、`app.Get`、`@GetMapping`、`@app.route` 等关键词 |
| **请求/响应 schema 定义在哪** | 搜索 DTO / schema / serializer / model 目录，看 json tag 或装饰器 |
| **统一响应格式是什么** | 找 response helper 文件（如 `response.go`、`response.py`），记录 JSON 结构 |
| **认证方式是什么** | 找 auth middleware，确定是 Bearer Token / Cookie / API Key / Basic Auth |
| **登录接口是什么** | 找登录 handler，记录路径、请求体、响应中 token 的位置 |
| **分页格式是什么** | 找列表接口的响应结构，记录 items/total/page 等字段名 |
| **已有 hurl 测试吗** | 搜索 `*.hurl` 文件，复用已有的约定 |
将画像结果**写入 `tests/hurl/.project-profile.md` 文件持久化保存**。
#### 画像持久化（关键机制）
**首次使用时**：完成 1.1 探索后，将画像写入 `tests/hurl/.project-profile.md`，格式如下：
```markdown
# 项目画像（Hurl 测试自动生成用）
<!-- 由 hurl-test skill 自动生成，请勿手动修改 -->
<!-- 如需刷新，删除此文件后重新运行 skill -->
## 技术栈
- 语言: Go 1.25
- 框架: Fiber v2
- ORM: GORM
## 路由定义位置
- 路由注册入口: internal/routes/routes.go
- 按模块拆分: internal/routes/{module}.go
- 路由注册函数: Register(router, doc, basePath, method, path, handler, spec)
## Schema 定义位置
- DTO 目录: internal/model/dto/
- 命名规则: {module}_dto.go
- 字段标签: json / validate / description
## 统一响应格式
{code: int, msg: string, data: any, timestamp: string(RFC3339)}
- 成功: code=0, msg="success"
- 错误: code!=0
## 分页格式
{items: [], total: int, page: int, size: int}
- 包裹在 data 字段内: $.data.items / $.data.total
## 认证方式
- 后台: POST /api/auth/admin-login → $.data.access_token → Authorization: Bearer {token}
- C端: JWT → Authorization: Bearer {token}
## 默认测试账号
- 用户名: admin
- 密码: Admin@123456
## 服务端口
- 默认: 3000
```
**后续使用时**：检查 `tests/hurl/.project-profile.md` 是否存在：
- **存在** → 直接读取，跳过 1.1 的探索步骤，节省时间
- **不存在** → 执行 1.1 完整探索，然后生成此文件
- **用户说"刷新画像"** → 删除旧文件，重新执行 1.1
#### 1.2 找接口定义
根据用户要测的模块，定位路由注册代码，提取：
- **HTTP 方法**（GET / POST / PUT / DELETE / PATCH）
- **路由路径**（含路径参数格式，如 `/users/:id` 或 `/users/{id}`）
- **接口说明**（注释、Summary、装饰器描述）
- **是否需要认证**
- **请求 schema 类型名**（Input / Request DTO）
- **响应 schema 类型名**（Output / Response DTO）
#### 1.3 读 schema 定义（DTO / struct / class / type）
定位请求和响应的 schema 定义文件，提取每个字段的：
- **字段名**：JSON 序列化后的名称（json tag / @JsonProperty / serializer field）
- **语言类型**：string / int / bool / 数组 / 嵌套对象 / 可空等
- **是否必填**：validate tag / required 装饰器 / 非空标注
- **是否可空**：指针类型 / Optional / nullable
- **是否参与序列化**：`json:"-"` / @JsonIgnore / exclude
- **是否 omitempty**：`json:",omitempty"` / 条件序列化
- **字段描述**：description tag / docstring / 注释
#### 1.4 识别业务依赖
读 service / business logic 层，识别：
- 创建操作需要哪些前置数据（如创建订单需要先有商品和用户）
- 是否有唯一性约束（如用户名不能重复）
- 是否依赖外部服务（支付网关、短信、OAuth 等）
- 业务流转逻辑（状态机、级联操作）
---
### Phase 2: 确认（Clarify）
**目标：向用户展示发现的内容，确认模糊点。不要闷头生成。**
#### 2.1 必须展示的内容
```
我梳理了相关代码，发现以下信息：
📋 涉及接口：
- [方法] [路径] - [说明]（认证: 是/否）
- ...
📦 响应字段（基于 {SchemaName}）：
- [字段名]: [类型] - [说明]
- ...（共 N 个字段，将全部生成断言）
🔗 依赖关系：
- [创建 X 需要先创建 Y]
- ...
⚠️ 特殊情况：
- [涉及外部服务 / 文件上传 / 特殊认证等]
```
#### 2.2 按需确认（只问有歧义的）
| 场景 | 要问的 |
|------|--------|
| 流程范围不明确 | "要测到哪一步？" |
| 多种用户角色 | "用哪种身份测？" |
| 是否测异常 | "需要包含异常 case 吗？（参数校验失败、权限不足等）" |
| 是否测数据隔离 | "需要验证不同用户间数据不可见吗？" |
| 涉及第三方 | "XX 部分怎么处理？绕过 / 模拟回调 / 跳过？" |
| 前置数据来源 | "XX 依赖数据是通过 API 创建还是假设已存在？" |
**如果用户说"越完整越好"或"都要"→ 默认全部包含，不再追问。**
---
### Phase 3: 生成（Generate）
**目标：生成完整的 .hurl 文件，字段断言基于 schema 代码，不能编造。**
#### 3.1 文件头注释
```hurl
# ============================================================
# 测试：{测试名称}
# 生成时间：{日期}
# 涉及模块：{module1, module2, ...}
# 涉及接口：{N} 个
# 断言数量：{N} 条
# 前置条件：{服务运行 + 必要的前置条件}
# ============================================================
# 流程：
# 1. {步骤描述}
# 2. {步骤描述}
# ...
# ============================================================
```
#### 3.2 请求生成规则
**认证**：
- 根据 Phase 1 画像中的登录接口和 token 位置生成
- token 必须通过 `[Captures]` 捕获，后续请求引用
- 如果是 Cookie 认证，用 `[Cookies]` 或 cookie capture
**CRUD 标准模式**：
| 操作 | 生成要求 |
|------|---------|
| **创建（POST）** | capture 返回的 ID；唯一字段用 `{{newUuid}}` 防冲突 |
| **查询详情（GET）** | **逐字段断言**（类型 + 值，见 3.3） |
| **查询列表（GET）** | 分页结构断言 + items[0] 逐字段断言 |
| **修改（PUT/PATCH）** | 修改后**紧跟一个 GET 验证修改生效** |
| **删除（DELETE）** | 删除后**紧跟一个 GET 验证已删除** |
**业务流程模式**：
- 按用户描述的流程顺序编排请求
- 上一步的输出（ID、状态等）通过 `[Captures]` 传给下一步
- 关键步骤加中间状态验证（如创建订单后验证状态为"待支付"）
#### 3.3 schema 到断言的映射
读到 schema 字段后，按以下规则生成 jsonpath 断言：
**通用类型映射（所有语言）**：
| Schema 类型特征 | Hurl 断言 |
|----------------|-----------|
| 字符串（string / str / String） | `isString` |
| 整数（int / integer / long / Int） | `isInteger` |
| 浮点（float / double / decimal / Float） | `isNumber` |
| 布尔（bool / boolean / Boolean） | `isBoolean` |
| 数组 / 列表（[] / List / Array） | `isList` |
| 嵌套对象（struct / class / dict / object） | `isObject`，并递归检查子字段 |
| 可空类型（指针 / Optional / nullable） | `exists`（不强制类型，因为可能是 null） |
| 不参与序列化（json:"-" / @JsonIgnore / exclude=True） | **跳过，不生成断言** |
| 条件序列化（omitempty / if not None） | `exists` 或不生成（取决于场景） |
**Go 特定映射**：
| Go 类型 | Hurl 断言 |
|---------|-----------|
| `string` | `isString` |
| `int`, `int8/16/32/64`, `uint`, `uint8/16/32/64` | `isInteger` |
| `float32`, `float64` | `isNumber` |
| `bool` | `isBoolean` |
| `[]T` | `isList` |
| `*string`, `*int`, `*uint` 等指针 | `exists` |
| `time.Time` | `isString`（通常序列化为字符串） |
| `map[string]any` | `isObject` |
**Python 特定映射（Pydantic / Django / FastAPI）**：
| Python 类型 | Hurl 断言 |
|------------|-----------|
| `str` | `isString` |
| `int` | `isInteger` |
| `float`, `Decimal` | `isNumber` |
| `bool` | `isBoolean` |
| `list[T]`, `List[T]` | `isList` |
| `Optional[T]`, `T | None` | `exists` |
| `dict`, `Dict` | `isObject` |
| `datetime`, `date` | `isString` |
**TypeScript/JavaScript 特定映射**：
| TS/JS 类型 | Hurl 断言 |
|-----------|-----------|
| `string` | `isString` |
| `number`（整数上下文） | `isInteger` |
| `number`（通用） | `isNumber` |
| `boolean` | `isBoolean` |
| `T[]`, `Array<T>` | `isList` |
| `T \| null`, `T \| undefined` | `exists` |
| `object`, `Record<>` | `isObject` |
| `Date` | `isString` |
**Java 特定映射**：
| Java 类型 | Hurl 断言 |
|----------|-----------|
| `String` | `isString` |
| `Integer`, `Long`, `int`, `long` | `isInteger` |
| `Double`, `Float`, `BigDecimal` | `isNumber` |
| `Boolean`, `boolean` | `isBoolean` |
| `List<T>` | `isList` |
| `@Nullable`, `Optional<T>` | `exists` |
| `Map<K,V>` | `isObject` |
| `LocalDateTime`, `Instant` | `isString` |
#### 3.4 统一响应格式断言
根据 Phase 1 画像中发现的统一响应格式，为**每个成功响应**添加格式断言。
示例：如果项目的统一格式是 `{code, msg, data, timestamp}`：
```hurl
[Asserts]
jsonpath "$.code" == 0
jsonpath "$.msg" == "success"
jsonpath "$.timestamp" isIsoDate
```
示例：如果项目的格式是 `{status, message, result}`：
```hurl
[Asserts]
jsonpath "$.status" == "ok"
jsonpath "$.message" isString
```
示例：如果项目无统一包装，直接返回数据：
```hurl
[Asserts]
# 直接断言业务字段
jsonpath "$.id" isInteger
jsonpath "$.name" isString
```
**不要假设响应格式，必须从代码中确认。**
#### 3.5 分页断言
根据 Phase 1 画像中发现的分页结构生成。
示例：如果是 `{items, total, page, size}` 格式：
```hurl
jsonpath "$.data.items" isList
jsonpath "$.data.total" isInteger
jsonpath "$.data.total" >= 1
jsonpath "$.data.page" isInteger
jsonpath "$.data.size" isInteger
# items 内元素逐字段断言
jsonpath "$.data.items[0].{field}" {type_assert}
```
示例：如果是 `{results, count, next, previous}` 格式（Django 风格）：
```hurl
jsonpath "$.results" isList
jsonpath "$.count" isInteger
jsonpath "$.count" >= 1
# results 内元素逐字段断言
jsonpath "$.results[0].{field}" {type_assert}
```
**根据实际代码调整字段名，不硬编码。**
#### 3.6 异常 Case 模板
**参数校验失败**：
```hurl
# ── 异常：参数校验失败 ──
POST {{base_url}}/{path}
Authorization: Bearer {{token}}
Content-Type: application/json
{
"required_field": ""
}
HTTP {expected_error_status}
[Asserts]
# 断言错误响应格式（根据项目约定调整）
```
> HTTP 状态码根据项目实际返回确定：有的项目错误也返回 200 + 业务错误码，有的返回 400/422。
**未认证访问**：
```hurl
# ── 异常：未认证访问 ──
GET {{base_url}}/{protected_path}
HTTP {expected_unauth_status}
```
**越权访问**（如果用户要求）：
```hurl
# ── 异常：用户 B 不能访问用户 A 的资源 ──
GET {{base_url}}/{path}/{{user_a_resource_id}}
Authorization: Bearer {{user_b_token}}
HTTP {expected_forbidden_status}
```
#### 3.7 特殊场景处理
| 场景 | 处理策略 |
|------|---------|
| **短信/邮件验证码** | 建议服务端加 test_mode 开关，固定验证码写入 env 文件；注释提醒用户 |
| **第三方支付** | 优先用项目内部支付方式（如钱包支付）；如需测回调，直接 POST 回调接口模拟 |
| **OAuth 登录（微信/Google/GitHub）** | 建议服务端加 test_mode 支持直接传 openid/email；注释提醒用户 |
| **文件上传** | 用 Hurl 的 `[Multipart]` 语法 + testdata 目录下的样本文件 |
| **外部 API 依赖** | 只测参数校验和错误响应格式，不断言业务结果；注释说明依赖 |
| **WebSocket** | Hurl 不支持，注释说明跳过 |
| **异步任务结果** | 用 Hurl 的 `retry` + `retry-interval` 轮询直到状态变更 |
异步轮询示例：
```hurl
# 等待异步任务完成（最多重试 10 次，间隔 500ms）
GET {{base_url}}/{path}/{{task_id}}
Authorization: Bearer {{token}}
[Options]
retry: 10
retry-interval: 500ms
HTTP 200
[Asserts]
jsonpath "$.data.status" == "completed"
```
#### 3.8 文件输出
**目录结构**（首次使用时创建，如不存在）：
```
tests/hurl/
├── env/
│ └── dev.env # 环境变量
├── testdata/ # 测试用的样本文件
├── flows/ # 业务流程测试
├── modules/ # 按模块的接口测试
│ └── {module}/
│ └── 01-crud.hurl
├── negative/ # 异常/边界测试
├── contract/ # 接口契约验证
└── Makefile # 快捷命令
```
文件放置规则：
| 用户描述 | 输出路径 |
|---------|---------|
| 测试 XX 流程 / 业务流程 | `tests/hurl/flows/{flow-name}.hurl` |
| 测试 XX 模块的 CRUD / 接口 | `tests/hurl/modules/{module}/01-crud.hurl` |
| 测试异常/边界/权限 | `tests/hurl/negative/{name}.hurl` |
| 测试接口契约/字段对齐 | `tests/hurl/contract/{name}.hurl` |
**如果项目已有 hurl 测试目录结构，沿用已有约定，不要另起炉灶。**
#### 3.9 env 和 Makefile
**env/dev.env**（首次创建时生成，内容基于 Phase 1 画像）：
```properties
# 服务地址
base_url=http://localhost:{port}
# 认证信息（根据项目实际填写）
admin_username={默认用户名}
admin_password={默认密码}
# 测试模式变量（如果有特殊场景）
# test_sms_code=888888
# test_openid=test_openid_001
```
**Makefile**（首次创建时生成）：
```makefile
SHELL := /bin/bash
ENV ?= dev
HURL_OPTS := --variables-file env/$(ENV).env --test
.PHONY: test test-flows test-modules test-negative report
test: ## 运行所有测试
hurl $(HURL_OPTS) .
test-flows: ## 运行业务流程测试
hurl $(HURL_OPTS) flows/
test-modules: ## 运行模块接口测试
hurl $(HURL_OPTS) modules/
test-negative: ## 运行异常测试
hurl $(HURL_OPTS) negative/
report: ## 生成 HTML 报告
hurl $(HURL_OPTS) --report-html build/report/ .
```
---
### Phase 4: 验证（Verify）
**目标：确保生成的 .hurl 文件语法正确、可运行。**
#### 4.1 语法自检
- [ ] 每个请求之间有空行分隔
- [ ] `[Captures]` 和 `[Asserts]` 拼写正确（大小写敏感）
- [ ] 所有 `{{变量}}` 引用都有来源（env 文件定义 或 上游 `[Captures]`）
- [ ] JSON body 无尾逗号、格式正确
- [ ] `HTTP {status}` 在请求之后、`[Captures]` / `[Asserts]` 之前
- [ ] 请求和断言之间没有多余空行（`HTTP` 行必须紧跟请求）
- [ ] 文件上传路径相对于 hurl 文件位置正确
#### 4.2 运行测试
```bash
hurl --variables-file tests/hurl/env/dev.env --test tests/hurl/{生成的文件}
```
- 服务在跑 → 执行，如有失败分析修正
- 服务没跑 → 跳过，告知用户手动验证命令
---
## 红线规则
| 规则 | 说明 |
|------|------|
| **不跳过 Phase 1** | 必须读代码确认接口路径和字段，不能凭记忆或猜测 |
| **不跳过 Phase 2** | 必须向用户展示发现的接口和字段，确认后再生成 |
| **不编造字段** | 所有断言的字段名必须来自实际 schema 代码 |
| **不编造路径** | 所有接口路径必须来自实际路由代码 |
| **不遗漏字段** | schema 中每个参与序列化的字段都必须有对应断言 |
| **不硬编码 ID** | 所有依赖的 ID 通过 `[Captures]` 从上游请求获取 |
| **不假设响应格式** | 统一响应结构必须从代码中确认，不同项目格式不同 |
| **唯一值防冲突** | 创建类请求的唯一字段使用 `{{newUuid}}` 或 `{{newDate}}` |
| **自给自足** | 每个 .hurl 文件自己创建测试数据，不依赖外部数据准备 |
---
## AI 助手检查清单
生成 .hurl 文件后自检：
1. ✅ 文件头注释包含流程描述和前置条件
2. ✅ 认证步骤正确 capture 了 token / cookie
3. ✅ 所有依赖数据通过 API 链式创建（自给自足）
4. ✅ 每个成功响应断言了项目的统一响应格式
5. ✅ 查询详情接口**逐字段断言**（类型 + 值，基于 schema）
6. ✅ 分页接口断言了分页结构 + 第一条记录的字段
7. ✅ 修改操作后紧跟 GET 验证修改生效
8. ✅ 删除操作后紧跟 GET 验证已删除
9. ✅ 唯一字段使用了 `{{newUuid}}`
10. ✅ `{{变量}}` 引用无悬空（都有 env 或 capture 来源）
11. ✅ 文件放在了正确的目录位置
12. ✅ 特殊场景有明确的处理策略和注释提醒
---
## 附录：Hurl 语法速查
**生成 .hurl 文件时必须参照本速查，不可凭记忆编造语法。**
### 文件结构
一个 .hurl 文件由多个 entry 组成，每个 entry = 请求 + 可选响应：
```
请求1
响应1（可选）
请求2
响应2（可选）
```
entry 之间用空行分隔。
### 请求格式
```hurl
METHOD URL
Header1: value1
Header2: value2
[Options]
key: value
[Query]
param1: value1
[Form]
field1: value1
[Multipart]
file1: file,path/to/file;
[BasicAuth]
username: password
[Cookies]
name: value
BODY（JSON / XML / multiline string / file）
```
**规则**：
- Method + URL 是第一行，必须
- Headers 紧跟 URL 之后（无 section 标记）
- Sections（`[Query]`、`[Form]`、`[Options]` 等）顺序任意
- Body 必须在最后
- JSON body 直接写 `{ }` 即可，自动设置 Content-Type: application/json
### 响应格式
```hurl
HTTP {status_code}
Header1: expected_value1
[Captures]
var_name: jsonpath "$.path"
[Asserts]
jsonpath "$.field" == "value"
```
**规则**：
- `HTTP {status}` 紧跟请求之后（中间不能有空行）
- `HTTP *` 表示不检查状态码
- Headers 检查紧跟 HTTP 行之后
- `[Captures]` 和 `[Asserts]` 顺序任意
### 变量和模板
```hurl
# 引用变量（从 env 文件、命令行或上游 capture 获取）
GET {{base_url}}/api/users/{{user_id}}
# 内置函数
POST {{base_url}}/api/users
{
"email": "{{newUuid}}@test.com",
"created_at": "{{newDate}}"
}
```
可用函数：
- `{{newUuid}}` — 生成 UUID v4
- `{{newDate}}` — 生成 RFC 3339 UTC 时间戳
### Capture 语法
```hurl
[Captures]
# JSONPath
token: jsonpath "$.data.access_token"
user_id: jsonpath "$.data.id"
first_item: jsonpath "$.items[0].name"
# Header
location: header "Location"
# Cookie
session: cookie "SESSIONID"
# Body（整个响应体作为字符串）
full_body: body
# Status code
code: status
# 正则表达式
csrf: regex "name=\"csrf\" value=\"([^\"]+)\""
# 响应时间（毫秒）
response_time: duration
```
### Assert 语法
```hurl
[Asserts]
# ── 状态码 ──
status == 200
status >= 200
status < 300
# ── JSONPath 断言 ──
jsonpath "$.name" == "Alice" # 等于
jsonpath "$.name" != "Bob" # 不等于
jsonpath "$.age" > 18 # 大于
jsonpath "$.age" >= 18 # 大于等于
jsonpath "$.count" < 100 # 小于
jsonpath "$.items" count == 5 # 集合长度
jsonpath "$.name" startsWith "Al" # 前缀
jsonpath "$.name" endsWith "ce" # 后缀
jsonpath "$.name" contains "lic" # 包含
jsonpath "$.date" matches /\\d{4}-\\d{2}-\\d{2}/ # 正则
# ── 类型断言 ──
jsonpath "$.name" isString
jsonpath "$.age" isInteger
jsonpath "$.score" isFloat
jsonpath "$.count" isNumber # 整数或浮点
jsonpath "$.active" isBoolean
jsonpath "$.items" isList
jsonpath "$.meta" isObject
jsonpath "$.id" isUuid
jsonpath "$.created_at" isIsoDate # RFC 3339 格式
jsonpath "$.field" isEmpty # 空集合
# ── 存在性 ──
jsonpath "$.field" exists
jsonpath "$.field" not exists
# ── 否定 ──
jsonpath "$.name" not contains "Bob"
jsonpath "$.status" not == "deleted"
# ── Header 断言 ──
header "Content-Type" contains "application/json"
header "X-Request-Id" exists
# ── 性能 ──
duration < 1000 # 响应时间（毫秒）
# ── Body 断言 ──
body contains "Hello"
bytes count == 1024
```
### Options（逐请求配置）
```hurl
GET {{base_url}}/api/task/{{task_id}}
[Options]
retry: 10 # 最大重试次数（-1 = 无限）
retry-interval: 500ms # 重试间隔
delay: 2s # 请求前等待
location: true # 跟随重定向
insecure: true # 允许不安全 SSL
verbose: true # 输出详细日志
very-verbose: true # 输出更详细日志
skip: true # 跳过此请求
variable: key=value # 定义变量
HTTP 200
```
### Multipart 文件上传
```hurl
POST {{base_url}}/api/upload
[Multipart]
file: file,testdata/sample.xlsx;
field1: value1
# 指定 Content-Type
file2: file,testdata/data.bin; application/octet-stream
```
### 运行命令
```bash
# 运行单个文件
hurl --test file.hurl
# 带变量文件
hurl --variables-file env/dev.env --test file.hurl
# 运行目录下所有 .hurl
hurl --test tests/hurl/
# 生成 HTML 报告
hurl --test --report-html build/report/ tests/hurl/
# 生成 JUnit 报告（CI 用）
hurl --test --report-junit build/report.xml tests/hurl/
# 并行执行（--test 默认并行，同文件内串行）
hurl --test --jobs 4 tests/hurl/
# 指定单个变量
hurl --variable base_url=http://localhost:3000 --test file.hurl
# 失败后继续执行
hurl --test --continue-on-error tests/hurl/
```
### 常见错误
| 错误 | 原因 | 修正 |
|------|------|------|
| `HTTP 200` 和请求之间有空行 | 空行会被当作 entry 分隔符 | 删除空行，HTTP 行紧跟请求 |
| JSON body 有尾逗号 | Hurl 严格解析 JSON | 删除最后一个逗号 |
| `jsonpath` 写成 `json_path` 或 `JsonPath` | 关键字大小写敏感 | 必须小写 `jsonpath` |
| `[Captures]` 写成 `[Capture]` | 必须是复数 | `[Captures]`、`[Asserts]`、`[Options]` |
| 变量 `{{ var }}` 有空格 | 允许，但建议统一 | `{{var}}` 或 `{{ var }}` 都可以 |
| `isIsoDate` 用在非 RFC 3339 格式 | 只认 `YYYY-MM-DDTHH:mm:ss` 格式 | 如果是其他格式用 `matches` |
| `file,path;` 路径含 `..` | Hurl 禁止相对父目录 | 用 `--file-root` 或调整路径 |

1
.claude/skills/implement
View File

@@ -1 +0,0 @@
../../.agents/skills/implement

1
.claude/skills/improve-codebase-architecture
View File

@@ -1 +0,0 @@
../../.agents/skills/improve-codebase-architecture

93
.claude/skills/model-standards/SKILL.md
View File

@@ -1,93 +0,0 @@
---
name: model-standards
description: GORM Model 模型规范。创建或修改数据库模型时使用。包含模型结构、字段标签、TableName 实现等规范。
---
# Model 模型规范
**创建或修改 `internal/model/` 下的数据库模型时必须遵守本规范。**
## 触发条件
在以下情况下必须遵守本规范：
- 创建新的数据库模型
- 修改现有模型的字段
- 添加新的数据库表
## 必须遵守的模型结构
```go
// ModelName 模型名称模型
// 详细的业务说明（2-3行）
// 特殊说明（如果有）
type ModelName struct {
gorm.Model // 包含 ID、CreatedAt、UpdatedAt、DeletedAt
BaseModel `gorm:"embedded"` // 包含 Creator、Updater
Field1 string `gorm:"column:field1;type:varchar(50);not null;comment:字段1说明" json:"field1"`
// ... 其他字段
}
// TableName 指定表名
func (ModelName) TableName() string {
return "tb_model_name"
}
```
## 关键要点
### 必须嵌入基础模型
- ✅ **必须**嵌入 `gorm.Model` 和 `BaseModel`
- ❌ **禁止**手动定义 ID、CreatedAt、UpdatedAt、DeletedAt、Creator、Updater
### 必须添加中文注释
- ✅ **必须**为模型添加中文注释，说明业务用途（参考 `internal/model/iot_card.go`）
- ✅ **必须**在每个字段的 `comment` 标签中添加中文说明
- ✅ **必须**为导出的类型编写 godoc 格式的文档注释
### 必须实现 TableName
- ✅ **必须**实现 `TableName()` 方法
- ✅ 表名使用 `tb_` 前缀
### 字段标签规范
- ✅ 所有字段必须显式指定 `gorm:"column:field_name"` 标签
- ✅ 金额字段使用 `int64` 类型，单位为分
- ✅ 时间字段使用 `*time.Time`（可空）或 `time.Time`（必填）
- ✅ JSONB 字段需要实现 `driver.Valuer` 和 `sql.Scanner` 接口
## 完整示例
```go
// IotCard 物联网卡模型
// 记录物联网卡的基础信息、状态和套餐关联
// 支持单卡和设备绑定两种使用模式
type IotCard struct {
gorm.Model
BaseModel `gorm:"embedded"`
ICCID string `gorm:"column:iccid;type:varchar(20);uniqueIndex;not null;comment:ICCID卡号" json:"iccid"`
IMSI string `gorm:"column:imsi;type:varchar(20);comment:IMSI号" json:"imsi"`
Status int `gorm:"column:status;type:smallint;default:0;comment:状态(0:未激活,1:已激活,2:已停机)" json:"status"`
ActivatedAt *time.Time `gorm:"column:activated_at;comment:激活时间" json:"activated_at"`
ShopID uint `gorm:"column:shop_id;index;comment:所属店铺ID" json:"shop_id"`
}
// TableName 指定表名
func (IotCard) TableName() string {
return "tb_iot_card"
}
```
## AI 助手检查清单
修改模型后必须检查：
1. ✅ 是否嵌入了 `gorm.Model` 和 `BaseModel`
2. ✅ 是否有 godoc 格式的模型注释
3. ✅ 所有字段是否有 `gorm:"column:xxx"` 标签
4. ✅ 所有字段是否有 `comment:xxx` 说明
5. ✅ 是否实现了 `TableName()` 方法
6. ✅ 表名是否使用 `tb_` 前缀
7. ✅ 金额字段是否使用 `int64`（单位：分）

97
.claude/skills/openspec-api-contract/SKILL.md
View File

@@ -1,97 +0,0 @@
---
name: openspec-api-contract
description: OpenSpec API 契约规范。创建涉及接口的 OpenSpec 提案时使用。探索阶段提供业务与契约引导清单，提案文档要求 API 契约设计、错误码与完成标准等必填章节。
---
# OpenSpec API 契约规范
**适用场景**：创建涉及 API/接口的 OpenSpec 提案时，探索和提案两个阶段均须遵守本规范。
---
## 一、探索阶段引导清单
在 `openspec-explore` 阶段，当内容涉及接口时，讨论必须覆盖以下所有维度。
### 业务与契约确认
**输入与输出**
- 请求方是谁？用户类型（SuperAdmin/Platform/Agent/Enterprise/Personal）？
- 输入参数：必填/选填字段、格式约束、参数来源（路径/查询/Body）？
- 输出结构：哪些字段必须返回？是否需要分页？
**业务规则**
- 核心业务规则与边界条件？
- 是否涉及状态流转？状态机的完整定义？
- 依赖外部服务时，外部异常的降级行为？
**权限与资源所有权**
- 哪些用户类型可以访问？
- 是否涉及跨用户/跨店铺/跨企业的资源访问？（需三层越权防护）
- 资源所有权校验方式：`CanManageShop` / `CanManageEnterprise` / 自有资源？
**幂等性**
- 操作类型：查询（天然幂等）/ 创建 / 更新 / 删除？
- 写操作幂等策略：状态条件更新 / Redis 业务键防重 + 分布式锁 / 乐观锁（version）？
- 异步任务是否需要任务锁？
**数据模型变更**
- 是否需要新建表、修改现有表或数据回填？
- 迁移策略：上线顺序、兼容旧数据的方式？
- 是否影响 GORM Callback 自动数据权限过滤？
**错误码与异常语义**
- 预期错误场景及对应错误码？
- 错误响应是否泄露敏感信息？（参数校验失败统一返回 `CodeInvalidParam`）
---
## 二、提案文档必填章节
在 `openspec-propose` 生成的提案（`proposal.md` / `design.md`）中，涉及接口时以下内容**不可缺失**。
### API 契约设计
**接口定义**
| 项 | 内容 |
|---|---|
| Endpoint | `METHOD /api/{scope}/{resource}[/:id]` |
| 请求参数 | 字段名、类型、必填/选填、说明 |
| 响应结构 | `data` 字段的完整结构定义 |
| 鉴权要求 | 允许的用户类型 |
| 资源所有权 | 所有权校验方式 |
**列表接口额外要求**
- 分页：`page` + `page_size`（默认 20，最大 100）
- 排序：默认排序字段与方向
- 过滤：支持的过滤条件列表
**错误码清单**
| 场景 | 错误码 | 说明 |
|---|---|---|
| 参数校验失败 | `CodeInvalidParam` | 统一返回，不泄露细节 |
| 资源不存在/越权 | `CodeForbidden` | 不区分两者，防止信息泄露 |
| （业务错误场景...） | （对应错误码） | （说明） |
### 完成标准
**最小验证步骤**（按顺序列出可操作的验证步骤）
1. （例：调用创建接口，验证返回 `code=0`）
2. （例：查询接口确认数据存在且字段正确）
3. （例：PostgreSQL MCP 查询确认数据库记录符合预期）
**影响范围说明**
- 新增/修改的表：
- 影响的现有接口：
- 影响的权限与数据过滤范围：
---
## 约束（必须遵守）
- **优先复用现有架构与库**：不引入新依赖，错误码优先复用已有定义
- **不做顺手重构**：提案范围严格限定在目标功能；发现可优化点，记录到 backlog 但不执行
- **数据库设计**：禁止外键约束，禁止 GORM 关联标签，关联通过 ID 字段手动维护

281
.claude/skills/openspec-lock-consensus/SKILL.md
View File

@@ -1,281 +0,0 @@
---
name: openspec-lock-consensus
description: 锁定共识 - 在探索讨论后，将讨论结果锁定为正式共识文档。防止后续提案偏离讨论内容。
license: MIT
compatibility: Requires openspec CLI.
metadata:
author: junhong
version: "1.1"
---
# 共识锁定 Skill
在 `/opsx:explore` 讨论后，使用此 skill 将讨论结果锁定为正式共识。共识文档是后续所有 artifact 的基础约束。
## 触发方式
```
/opsx:lock <change-name>
```
或在探索结束后，AI 主动提议：
> "讨论已经比较清晰了，要锁定共识吗？"
---
## 工作流程
### Step 1: 整理讨论要点
从对话中提取以下四个维度的共识：
| 维度 | 说明 | 示例 |
|------|------|------|
| **要做什么** | 明确的功能范围 | "支持批量导入 IoT 卡" |
| **不做什么** | 明确排除的内容 | "不支持实时同步，仅定时批量" |
| **关键约束** | 技术/业务限制 | "必须使用 Asynq 异步任务" |
| **验收标准** | 如何判断完成 | "导入 1000 张卡 < 30s" |
### Step 2: 使用 Question_tool 逐维度确认
**必须使用 Question_tool 进行结构化确认**，每个维度一个问题：
```typescript
// 示例：确认"要做什么"
Question_tool({
questions: [{
header: "确认：要做什么",
question: "以下是整理的功能范围，请确认：\n\n" +
"1. 功能点 A\n" +
"2. 功能点 B\n" +
"3. 功能点 C\n\n" +
"是否准确完整？",
options: [
{ label: "确认无误", description: "以上内容准确完整" },
{ label: "需要补充", description: "有遗漏的功能点" },
{ label: "需要删减", description: "有不应该包含的内容" }
],
multiple: false
}]
})
```
**如果用户选择"需要补充"或"需要删减"**：
- 用户会通过自定义输入提供修改意见
- 根据反馈更新列表，再次使用 Question_tool 确认
**确认流程**：
```
┌─────────────────────────────────────────────────────────────────────┐
│ Question_tool: 确认"要做什么" │
│ ├── 用户选择"确认无误" → 进入下一维度 │
│ └── 用户选择其他/自定义 → 修改后重新确认 │
├─────────────────────────────────────────────────────────────────────┤
│ Question_tool: 确认"不做什么" │
│ ├── 用户选择"确认无误" → 进入下一维度 │
│ └── 用户选择其他/自定义 → 修改后重新确认 │
├─────────────────────────────────────────────────────────────────────┤
│ Question_tool: 确认"关键约束" │
│ ├── 用户选择"确认无误" → 进入下一维度 │
│ └── 用户选择其他/自定义 → 修改后重新确认 │
├─────────────────────────────────────────────────────────────────────┤
│ Question_tool: 确认"验收标准" │
│ ├── 用户选择"确认无误" → 生成 consensus.md │
│ └── 用户选择其他/自定义 → 修改后重新确认 │
└─────────────────────────────────────────────────────────────────────┘
```
### Step 3: 生成 consensus.md
所有维度确认后，创建文件：
```bash
# 检查 change 是否存在
openspec list --json
# 如果 change 不存在，先创建
# openspec new <change-name>
# 写入 consensus.md
```
**文件路径**: `openspec/changes/<change-name>/consensus.md`
---
## Question_tool 使用规范
### 每个维度的问题模板
**1. 要做什么**
```typescript
{
header: "确认：要做什么",
question: "以下是整理的【功能范围】：\n\n" +
items.map((item, i) => `${i+1}. ${item}`).join('\n') +
"\n\n请确认是否准确完整？",
options: [
{ label: "确认无误", description: "功能范围准确完整" },
{ label: "需要补充", description: "有遗漏的功能点" },
{ label: "需要删减", description: "有不应该包含的内容" }
]
}
```
**2. 不做什么**
```typescript
{
header: "确认：不做什么",
question: "以下是明确【排除的内容】：\n\n" +
items.map((item, i) => `${i+1}. ${item}`).join('\n') +
"\n\n请确认是否正确？",
options: [
{ label: "确认无误", description: "排除范围正确" },
{ label: "需要补充", description: "还有其他需要排除的" },
{ label: "需要删减", description: "有些不应该排除" }
]
}
```
**3. 关键约束**
```typescript
{
header: "确认：关键约束",
question: "以下是【关键约束】：\n\n" +
items.map((item, i) => `${i+1}. ${item}`).join('\n') +
"\n\n请确认是否正确？",
options: [
{ label: "确认无误", description: "约束条件正确" },
{ label: "需要补充", description: "还有其他约束" },
{ label: "需要修改", description: "约束描述不准确" }
]
}
```
**4. 验收标准**
```typescript
{
header: "确认：验收标准",
question: "以下是【验收标准】（必须可测量）：\n\n" +
items.map((item, i) => `${i+1}. ${item}`).join('\n') +
"\n\n请确认是否正确？",
options: [
{ label: "确认无误", description: "验收标准清晰可测量" },
{ label: "需要补充", description: "还有其他验收标准" },
{ label: "需要修改", description: "标准不够清晰或无法测量" }
]
}
```
### 处理用户反馈
当用户选择非"确认无误"选项或提供自定义输入时：
1. 解析用户的修改意见
2. 更新对应维度的内容
3. 再次使用 Question_tool 确认更新后的内容
4. 重复直到用户选择"确认无误"
---
## consensus.md 模板
```markdown
# 共识文档
**Change**: <change-name>
**确认时间**: <timestamp>
**确认人**: 用户
---
## 1. 要做什么
- [x] 功能点 A（已确认）
- [x] 功能点 B（已确认）
- [x] 功能点 C（已确认）
## 2. 不做什么
- [x] 排除项 A（已确认）
- [x] 排除项 B（已确认）
## 3. 关键约束
- [x] 技术约束 A（已确认）
- [x] 业务约束 B（已确认）
## 4. 验收标准
- [x] 验收标准 A（已确认）
- [x] 验收标准 B（已确认）
---
## 讨论背景
<简要总结讨论的核心问题和解决方向>
## 关键决策记录
| 决策点 | 选择 | 原因 |
|--------|------|------|
| 决策 1 | 选项 A | 理由... |
| 决策 2 | 选项 B | 理由... |
---
**签字确认**: 用户已通过 Question_tool 逐条确认以上内容
```
---
## 后续流程绑定
### Proposal 生成时
`/opsx:continue` 生成 proposal 时，**必须**：
1. 读取 `consensus.md`
2. 确保 proposal 的 Capabilities 覆盖"要做什么"中的每一项
3. 确保 proposal 不包含"不做什么"中的内容
4. 确保 proposal 遵守"关键约束"
### 验证机制
如果 proposal 与 consensus 不一致，输出警告：
```
⚠️ Proposal 验证警告：
共识中"要做什么"但 Proposal 未提及：
- 功能点 C
共识中"不做什么"但 Proposal 包含：
- 排除项 A
建议修正 Proposal 或更新共识。
```
---
## Guardrails
- **必须使用 Question_tool** - 不要用纯文本确认
- **逐维度确认** - 四个维度分开确认，不要合并
- **不要跳过确认** - 每个维度都必须让用户明确确认
- **不要自作主张** - 只整理讨论中明确提到的内容
- **避免模糊表述** - "尽量"、"可能"、"考虑"等词汇需要明确化
- **验收标准必须可测量** - 避免"性能要好"这类无法验证的标准
---
## 与其他 Skills 的关系
| Skill | 关系 |
|-------|------|
| `openspec-explore` | 探索结束后触发 lock |
| `openspec-new-change` | lock 后触发 new（如果 change 不存在）|
| `openspec-continue-change` | 生成 proposal 时读取 consensus 验证 |
| `openspec-generate-acceptance-tests` | 从 consensus 的验收标准生成测试骨架 |

1
.claude/skills/prototype
View File

@@ -1 +0,0 @@
../../.agents/skills/prototype

1
.claude/skills/research
View File

@@ -1 +0,0 @@
../../.agents/skills/research

1
.claude/skills/resolving-merge-conflicts
View File

@@ -1 +0,0 @@
../../.agents/skills/resolving-merge-conflicts

1
.claude/skills/setup-matt-pocock-skills
View File

@@ -1 +0,0 @@
../../.agents/skills/setup-matt-pocock-skills

1
.claude/skills/tdd
View File

@@ -1 +0,0 @@
../../.agents/skills/tdd

1
.claude/skills/teach
View File

@@ -1 +0,0 @@
../../.agents/skills/teach

1
.claude/skills/to-issues
View File

@@ -1 +0,0 @@
../../.agents/skills/to-issues

1
.claude/skills/to-prd
View File

@@ -1 +0,0 @@
../../.agents/skills/to-prd

1
.claude/skills/to-spec
View File

@@ -1 +0,0 @@
../../.agents/skills/to-spec

1
.claude/skills/to-tickets
View File

@@ -1 +0,0 @@
../../.agents/skills/to-tickets

1
.claude/skills/triage
View File

@@ -1 +0,0 @@
../../.agents/skills/triage

1
.claude/skills/wayfinder
View File

@@ -1 +0,0 @@
../../.agents/skills/wayfinder

1
.claude/skills/write-a-skill
View File

@@ -1 +0,0 @@
../../.agents/skills/write-a-skill

1
.claude/skills/writing-great-skills
View File

@@ -1 +0,0 @@
../../.agents/skills/writing-great-skills

1
.claude/skills/zoom-out
View File

@@ -1 +0,0 @@
../../.agents/skills/zoom-out