输入：template_name (e.g., "web-nextjs")
     change_branch (e.g., "add-user-account-features")
     test_level ("quick" | "full" | "e2e", default: "e2e")

输出：测试报告（PASS/FAIL）
     合并建议（READY/BLOCKED）
     下一步行动清单

这样设计的好处：

通用性：适用于任何模板，不限于 web-nextjs
可扩展：可以轻松添加新的测试级别
小模型友好：清晰的输入输出格式便于理解

原则 2：关键判断标准

为每个检查项定义明确的通过/失败标准：

检查项	通过标准	失败处理
ESLint	无错误退出码 0	列出错误，建议修复
TypeScript	编译成功	显示类型错误位置
Build	生成 .next 目录	检查构建日志
Dev Server	60s 内响应 200	检查端口占用、缓存损坏
Layer 2	无违规 import	强制使用 Repository 模式
安全检查	无硬编码密钥	BLOCK MERGE

关键点：

量化标准：避免模糊描述（如"快速启动" → "60s 内响应"）
分级处理：区分致命错误和警告
** actionable**：每个失败都有对应的修复建议

原则 3：必要约束 & 质量检查点

识别任务执行中的关键约束和质量检查点：

必要约束：

必须在 monorepo 内测试（模板依赖 workspace packages）
必须使用 npx 而非 pnpm（避免 workspace 依赖检查干扰）
必须清理 Turbopack 缓存（防止缓存损坏导致 500 错误）
必须自动清理（测试结束后停止服务器、删除临时文件）

质量检查点：

# Phase 1: 静态检查
✓ ESLint passed
✓ TypeScript compilation successful
✓ Production build successful

# Phase 2: 运行时检查
✓ Dev server started (<60s)
✓ Homepage returns 200
✓ New feature pages return 200

# Phase 3: 安全检查
✓ No Layer 2 violations
✓ Open redirect protection present
✓ No hardcoded secrets

原则 4：让 LLM 自主规划执行路径

提供决策树而非固定步骤：

1. 检测当前分支和待测试模板
2. 选择合适的测试脚本：
   - quick: scripts/validate-template.sh
   - full/e2e: scripts/e2e-template-test-v2.sh
3. 运行测试并捕获输出
4. 解析测试结果：
   - 如果 PASS_COUNT > 0 && FAIL_COUNT == 0 → READY FOR MERGE
   - 如果 FAIL_COUNT > 0 → BLOCKED，分析失败原因
5. 生成结构化报告
6. 提供下一步行动建议
7. 确保 cleanup 已执行

这种设计的优势：

适应性：LLM 可以根据实际情况调整策略
容错性：遇到意外情况时可以灵活应对
小模型友好：清晰的决策逻辑易于跟随

Skill 的结构

一个完整的 Skill 包含以下文件和目录：

.lingma/skills/{skill-name}/
├── SKILL.md                    # 核心定义文件（必需）
├── assets/                     # 支持文件（可选）
│   ├── script.sh              # 测试脚本、工具脚本
│   ├── template.md            # 报告模板、配置文件
│   └── checklist.json         # 验收清单
├── examples/                   # 使用示例（推荐）
│   └── usage-examples.md      # 场景化示例
└── README.md                   # 快速入门（可选）

SKILL.md 文件结构

# {Skill Name}

## 核心思想（Essence）
- 目标
- 重点
- 边界

## 设计原则（Design Principles）
1. 任务目标抽象
2. 关键判断标准
3. 必要约束 & 质量检查点
4. LLM 自主执行路径

## 使用方法（Usage）
- 基本用法
- 在 Skill 中调用

## 测试流程（Test Workflow）
- Phase 1: ...
- Phase 2: ...

## 常见问题排查（Troubleshooting）

## 验收标准（Acceptance Criteria）

## 输出格式（Output Format）

## 相关文件（Related Files）

Skill 最佳实践

1. 保持专注（Single Responsibility）

每个 Skill 只解决一类问题。

好例子：

template-testing - 专门测试模板可用性
openspec-new-change - 专门创建 OpenSpec 变更

坏例子：

do-everything - 试图处理所有任务

2. 明确边界（Clear Boundaries）

清楚定义什么可以做、什么不可以做。

✅ 可以：运行测试、读取日志、分析结果
❌ 不可以：自动修改代码、跳过测试、忽略警告

3. 量化标准（Quantifiable Criteria）

避免模糊描述，使用可测量的标准。

模糊："快速启动服务器" 清晰："60 秒内响应 HTTP 200"

4. 提供示例（Provide Examples）

包含多个实际使用场景，帮助 LLM 理解如何应用 Skill。

5. 小模型友好（Small-Model Friendly）

使用清晰的结构和标题
避免冗长的段落
多用表格、列表、代码块
提供决策树而非开放式指令

6. 持续迭代（Iterate）

收集实际使用中的反馈
记录新的失败模式和解决方案
定期更新 SKILL.md 和 assets

Skill 管理策略

注意：当项目中有几十甚至几百个 Skills 时，如何有效管理是一个重要课题。本节内容将在后续完善。

待讨论话题

分类体系：如何对 Skills 进行分类和标签化？
命名规范：如何确保 Skill 名称的一致性和可发现性？
版本控制：如何管理 Skill 的版本和兼容性？
依赖关系：如何处理 Skills 之间的依赖和组合？
性能优化：如何在大量 Skills 中快速检索和加载？
权限管理：如何控制不同用户对 Skills 的访问和修改权限？
质量评估：如何评估 Skill 的有效性和使用情况？
生命周期管理：如何归档废弃的 Skills？

欢迎贡献你的想法和经验！

项目中的 Skills

以下是 AgentDock 项目中已创建的 Skills：

1. Template Testing Skill

位置：.lingma/skills/template-testing/

功能：在合并模板变更到 main 分支之前，通过自动化测试验证模板的可用性和质量。

核心能力：

运行 ESLint、TypeScript、Build 检查
启动开发服务器并验证 HTTP 端点
检查 Layer 2 架构约束和安全防护
生成结构化测试报告和合并建议

使用方法：

# 完整 E2E 测试（推荐）
./scripts/e2e-template-test-v2.sh

# 快速验证
./scripts/validate-template.sh

详细文档：Template Testing Skill

创建你自己的 Skill

想创建一个新 Skill？遵循以下步骤：

定义核心思想：目标、重点、边界
设计原则：抽象任务模型、判断标准、约束条件
创建文件结构：SKILL.md、assets、examples
编写 SKILL.md：按照模板填充内容
测试和优化：在实际使用中迭代改进

参考 Template Testing Skill 作为示例。

Skills

Skills

什么是 Skill？

Skill 的价值

Skill 的核心范式

1. 精髓/灵魂/核心思想（Essence）

目标是什么？（Goal）

重点该干嘛？（Focus）

不可以做啥、不干预、明确边界内自主规划（Boundaries）

2. 设计原则（Design Principles）

原则 1：任务目标抽象