@mison/ag-kit-cn 2.0.1

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

@@ -0,0 +1,194 @@
+---
+name: parallel-agents
+description: 多智能体（Multi-agent）编排模式。当多个独立任务需要不同领域的专业知识，或需要多视角的综合分析时使用。
+allowed-tools: Read, Glob, Grep
+---
+
+# 原生并行智能体
+
+> 通过 Antigravity 内置的智能体工具实现编排（Orchestration）。
+
+---
+
+## 概览（Overview）
+
+本技能旨在通过 Antigravity 的原生智能体系统协调多个专业化 Agent（智能体）。与外部脚本不同，这种方法将所有编排逻辑完全置于 Antigravity 的控制之下。
+
+---
+
+## 何时使用编排
+
+✅ **适用场景：**
+
+- 需要跨多个专业领域的复杂任务。
+- 从安全、性能和代码质量等多维度进行代码分析。
+- 综合评审（架构 + 安全 + 测试）。
+- 需要后端 + 前端 + 数据库协同工作的需求实现。
+
+❌ **不适用场景：**
+
+- 简单的、仅涉及单一领域的任务。
+- 快速修复或细微变动。
+- 单个 Agent 即可胜任的任务。
+
+---
+
+## 原生 Agent 调用
+
+### 调用单个 Agent
+
+```
+请使用 security-auditor 智能体来审阅身份认证逻辑。
+```
+
+### 顺序链式调用
+
+```
+首先，使用 explorer-agent 探索项目结构。
+然后，使用 backend-specialist 审阅 API 端点。
+最后，使用 test-engineer 识别测试缺口。
+```
+
+### 带上下文传递的调用
+
+```
+使用 frontend-specialist 分析 React 组件。
+基于该分析结果，让 test-engineer 生成对应的组件测试。
+```
+
+### 恢复先前的工作
+
+```
+恢复智能体 [agentId] 并继续执行其他需求。
+```
+
+---
+
+## 编排模式
+
+### 模式 1：全面分析
+
+```
+智能体流：explorer-agent → [领域专家级 Agents] → 综合汇总（Synthesis）
+
+1. explorer-agent：绘制代码库结构图。
+2. security-auditor：评估安全态势。
+3. backend-specialist：评估 API 质量。
+4. frontend-specialist：评估 UI/UX（界面/体验）模式。
+5. test-engineer：评估测试覆盖率。
+6. 综合汇总所有发现。
+```
+
+### 模式 2：功能评审
+
+```
+智能体流：[受影响领域的 Agents] → test-engineer
+
+1. 识别受影响的领域（后端？前端？还是二者兼有？）。
+2. 调用相关的领域 Agent。
+3. 由 test-engineer 验证变更。
+4. 综合汇总改进建议。
+```
+
+### 模式 3：安全审计
+
+```
+智能体流：security-auditor → penetration-tester → 综合汇总
+
+1. security-auditor：进行配置与代码审计。
+2. penetration-tester：执行主动漏洞测试。
+3. 综合汇总并给出按优先级排列的补救方案。
+```
+
+---
+
+## 可用智能体清单
+
+| 智能体（Agent） | 专业领域 | 触发词/场景 |
+| -------------- | -------- | ---------- |
+| `orchestrator` | 全局协调 | "全面的", "多维度的", "综合的" |
+| `security-auditor` | 安全审计 | "安全", "认证", "漏洞" |
+| `penetration-tester` | 渗透测试 | "渗透测试", "红队", "exploit（利用）" |
+| `backend-specialist` | 后端开发 | "API（接口）", "服务器", "Node.js", "Express" |
+| `frontend-specialist` | 前端开发 | "React", "UI（界面）", "组件", "Next.js" |
+| `test-engineer` | 测试工程 | "测试", "覆盖率", "TDD（测试驱动开发）" |
+| `devops-engineer` | 运维开发 | "部署", "CI/CD（持续集成/交付）", "基础设施" |
+| `database-architect` | 数据库架构 | "模式（Schema）", "Prisma", "迁移" |
+| `mobile-developer` | 移动端开发 | "React Native", "Flutter", "移动端" |
+| `api-designer` | API 设计 | "REST（表述性状态转移）", "GraphQL（图查询语言）", "OpenAPI（开放 API 规范）" |
+| `debugger` | 调试专家 | "Bug（缺陷）", "错误", "不工作" |
+| `explorer-agent` | 探索发现 | "探索", "映射", "结构" |
+| `documentation-writer` | 文档编写 | "写文档", "创建 README（说明文档）", "生成 API 文档" |
+| `performance-optimizer` | 性能优化 | "慢", "优化", "分析（Profiling）" |
+| `project-planner` | 项目策划 | "计划", "路线图", "里程碑" |
+| `seo-specialist` | SEO 专家 | "SEO", "Meta（元）标签", "搜索排名" |
+| `game-developer` | 游戏开发 | "游戏", "Unity", "Godot", "Phaser" |
+
+---
+
+## Antigravity 内置智能体
+
+这些智能体与自定义 Agent 协同工作：
+
+| 智能体 | 模型（Model） | 用途 |
+| ------ | ------------ | ---- |
+| **Explore** | Haiku | 快速的只读代码库搜索 |
+| **Plan** | Sonnet | 计划模式下的调研工作 |
+| **通用型（General）** | Sonnet | 复杂的、跨步骤的代码修改 |
+
+针对快速搜索，请使用 **Explore**；针对特定领域知识，请使用**自定义智能体**。
+
+---
+
+## 综合汇总协议
+
+当所有 Agent 完成工作后，进行综合汇总：
+
+```markdown
+## 编排综合报告
+
+### 任务总结
+
+[已完成的工作内容]
+
+### 各智能体贡献
+
+| 智能体 | 主要发现 |
+| ------ | -------- |
+| security-auditor | 发现了 X 安全缺陷 |
+| backend-specialist | 识别了 Y 优化点 |
+
+### 整合建议
+
+1. **紧急（Critical）**: [来自 Agent A 的问题]
+2. **重要（Important）**: [来自 Agent B 的问题]
+3. **建议（Nice-to-have）**: [来自 Agent C 的改进点]
+
+### 待办动作
+
+- [ ] 修复紧急安全问题
+- [ ] 重构 API 端点
+- [ ] 补全缺失的测试
+```
+
+---
+
+## 最佳实践
+
+1. **Agent 多样性** —— 共有 17 个专业 Agent 可供编排调用。
+2. **逻辑顺序** —— 遵循“探索 → 分析 → 实现 → 测试”的链路。
+3. **共享上下文** —— 将关键发现传递给后续的 Agent。
+4. **统一汇总** —— 输出一份完整的综合报告，而非零散的结果。
+5. **验证变更** —— 凡涉及代码修改，务必由 `test-engineer` 介入。
+
+---
+
+## 核心优势
+
+- ✅ **单次会话** —— 所有 Agent 共享上下文。
+- ✅ **AI 自控** —— Claude 自主进行编排协调。
+- ✅ **原生集成** —— 与内置的 Explore 和 Plan 智能体无缝配合。
+- ✅ **支持恢复** —— 可继续先前 Agent 未完成的工作。
+- ✅ **上下文流转** —— 发现结果在 Agent 之间顺畅传递。
+
+---

package/.agent/skills/performance-profiling/SKILL.md

@@ -0,0 +1,149 @@
+---
+name: performance-profiling
+description: 性能分析原则。测量、分析与优化技术。
+allowed-tools: Read, Glob, Grep, Bash
+---
+
+# 性能分析
+
+> 测量、分析、优化 —— 必须严格遵循此顺序。
+
+---
+
+## 🔧 运行脚本
+
+**执行以下脚本进行自动化性能分析：**
+
+| 脚本                          | 用途                | 执行命令                                                 |
+| ----------------------------- | ------------------- | -------------------------------------------------------- |
+| `scripts/lighthouse_audit.py` | Lighthouse（性能审计工具）审计 | `python scripts/lighthouse_audit.py https://example.com` |
+
+---
+
+## 1. 核心 Web 指标
+
+核心 Web 指标（Core Web Vitals）用于衡量加载与交互质量。
+
+### 目标值
+
+| 指标    | 优（Good） | 劣（Poor） | 衡量维度   |
+| ------- | --------- | --------- | ---------- |
+| **LCP** | < 2.5s    | > 4.0s    | 加载体验   |
+| **INP** | < 200ms   | > 500ms   | 交互响应   |
+| **CLS** | < 0.1     | > 0.25    | 视觉稳定性 |
+
+### 何时进行测量
+
+| 阶段                   | 工具选择                                |
+| ---------------------- | --------------------------------------- |
+| 开发环境（Development） | 本地 Lighthouse                          |
+| CI/CD 流程              | Lighthouse CI（持续集成）                 |
+| 生产环境（Production）   | RUM（真实用户监控，Real User Monitoring） |
+
+---
+
+## 2. 性能分析工作流
+
+### 四步走流程
+
+```
+1. 建立基准（Baseline）→ 测量当前状态
+2. 识别瓶颈（Identify）→ 找出性能卡点
+3. 实施修复（Fix）     → 进行针对性改动
+4. 验证改进（Validate）→ 确认性能提升
+```
+
+### 分析工具选择建议
+
+| 待解决问题             | 推荐工具                  |
+| ---------------------- | ------------------------- |
+| 页面加载速度              | Lighthouse                          |
+| 打包体积（Bundle size）   | Bundle analyzer（包分析器）         |
+| 运行时性能                | DevTools（开发者工具）Performance（性能）面板 |
+| 内存占用                  | DevTools（开发者工具）Memory（内存）面板      |
+| 网络请求                  | DevTools（开发者工具）Network（网络）面板     |
+
+---
+
+## 3. 打包产物分析
+
+### 观察重点
+
+| 潜在问题             | 识别指标                     |
+| -------------------- | ---------------------------- |
+| 巨大的外部依赖       | 位于打包产物顶部             |
+| 冗余/重复代码        | 存在于多个 Chunk（代码块）中 |
+| 未使用的代码         | 低覆盖率（Coverage）          |
+| 缺失分包（Splitting） | 产物呈现为一个巨大的单体文件 |
+
+### 优化手段
+
+| 发现的问题           | 对应动作                                 |
+| -------------------- | ---------------------------------------- |
+| 库文件过大           | 按需导入（Import specific modules）      |
+| 依赖项重复           | 去重（Dedupe）、更新版本                 |
+| 主包代码包含路由逻辑 | 实施代码分割（Code split）               |
+| 存在未引用的导出     | 启用 Tree shake（摇树优化）              |
+
+---
+
+## 4. 运行时分析
+
+### Performance 面板分析
+
+| 模式                       | 含义                             |
+| -------------------------- | -------------------------------- |
+| 长任务（Long tasks > 50ms） | 会导致 UI 阻塞                    |
+| 密集的小任务               | 可能存在批处理（Batching）的机会 |
+| 布局/绘制（Layout/paint）  | 渲染层的瓶颈                      |
+| 脚本执行（Script）         | JavaScript（脚本语言）执行开销过高 |
+
+### Memory 面板分析
+
+| 模式                            | 含义             |
+| ------------------------------- | ---------------- |
+| 堆内存持续增长（Growing heap）   | 可能存在内存泄漏 |
+| 被持有的对象过多（Retained）     | 检查引用关系     |
+| Detached DOM（脱离文档树的 DOM，Document Object Model） | 未被正确清理     |
+
+---
+
+## 5. 常见性能瓶颈
+
+### 按症状分类
+
+| 症状表现            | 可能的原因                              |
+| ------------------- | --------------------------------------- |
+| 首次加载缓慢        | JS 体积过大、渲染阻塞（Render blocking） |
+| 交互卡顿            | 事件处理器（Event handlers）逻辑过重    |
+| 滚动时的掉帧（Jank） | 布局抖动（Layout thrashing）             |
+| 内存持续上升        | 内存泄漏、未释放的引用                  |
+
+---
+
+## 6. 优先实施的“速赢”方案
+
+| 优先级 | 动作                        | 预期影响 |
+| ------ | -------------------------- | ----------------- |
+| 1      | 开启资源压缩（Gzip/Brotli，压缩算法） | **高**            |
+| 2      | 图片懒加载（Lazy load）     | **高**            |
+| 3      | 路由层级的代码分割         | **高**            |
+| 4      | 配置静态资源缓存           | 中                |
+| 5      | 图片压缩与格式优化         | 中                |
+
+---
+
+## 7. 应避免的反模式
+
+| ❌ 禁止（Don't）                 | ✅ 推荐（Do）                     |
+| ------------------------------- | -------------------------------- |
+| 凭空猜测性能问题                | 优先进行性能分析（Profile first，先分析） |
+| 进行微比例优化（Micro-optimize） | 优先修复最大的性能卡点            |
+| 过早优化                        | 在真正需要的时候再优化           |
+| 忽视真实用户的体验              | 参考 RUM 数据                    |
+
+---
+
+> **谨记：** 最快的代码是那些根本不需要运行的代码。在着手优化之前，先考虑是否可以移除。
+
+---

package/.agent/skills/performance-profiling/scripts/lighthouse_audit.py

@@ -0,0 +1,76 @@
+#!/usr/bin/env python3
+"""
+Skill: performance-profiling
+Script: lighthouse_audit.py
+Purpose: Run Lighthouse performance audit on a URL
+Usage: python lighthouse_audit.py https://example.com
+Output: JSON with performance scores
+Note: Requires lighthouse CLI (npm install -g lighthouse)
+"""
+import subprocess
+import json
+import sys
+import os
+import tempfile
+
+def run_lighthouse(url: str) -> dict:
+    """Run Lighthouse audit on URL."""
+    try:
+        with tempfile.NamedTemporaryFile(suffix='.json', delete=False) as f:
+            output_path = f.name
+        
+        result = subprocess.run(
+            [
+                "lighthouse",
+                url,
+                "--output=json",
+                f"--output-path={output_path}",
+                "--chrome-flags=--headless",
+                "--only-categories=performance,accessibility,best-practices,seo"
+            ],
+            capture_output=True,
+            text=True,
+            timeout=120
+        )
+        
+        if os.path.exists(output_path):
+            with open(output_path, 'r') as f:
+                report = json.load(f)
+            os.unlink(output_path)
+            
+            categories = report.get("categories", {})
+            return {
+                "url": url,
+                "scores": {
+                    "performance": int(categories.get("performance", {}).get("score", 0) * 100),
+                    "accessibility": int(categories.get("accessibility", {}).get("score", 0) * 100),
+                    "best_practices": int(categories.get("best-practices", {}).get("score", 0) * 100),
+                    "seo": int(categories.get("seo", {}).get("score", 0) * 100)
+                },
+                "summary": get_summary(categories)
+            }
+        else:
+            return {"error": "Lighthouse failed to generate report", "stderr": result.stderr[:500]}
+            
+    except subprocess.TimeoutExpired:
+        return {"error": "Lighthouse audit timed out"}
+    except FileNotFoundError:
+        return {"error": "Lighthouse CLI not found. Install with: npm install -g lighthouse"}
+
+def get_summary(categories: dict) -> str:
+    """Generate summary based on scores."""
+    perf = categories.get("performance", {}).get("score", 0) * 100
+    if perf >= 90:
+        return "[OK] Excellent performance"
+    elif perf >= 50:
+        return "[!] Needs improvement"
+    else:
+        return "[X] Poor performance"
+
+if __name__ == "__main__":
+    if len(sys.argv) < 2:
+        print(json.dumps({"error": "Usage: python lighthouse_audit.py <url>"}))
+        sys.exit(1)
+    
+    result = run_lighthouse(sys.argv[1])
+    print(json.dumps(result, indent=2))

package/.agent/skills/plan-writing/SKILL.md

@@ -0,0 +1,152 @@
+---
+name: plan-writing
+description: 结构化任务规划能力。强调清晰拆解、依赖关系与可验证标准。适用于功能实现、重构与多步骤工作。
+allowed-tools: Read, Glob, Grep
+---
+
+# 计划编写
+
+> 来源：obra/superpowers
+
+## 概览
+该技能提供一套框架，用于将工作拆解为清晰、可执行、可验证的任务。
+
+## 任务拆解原则
+
+### 1. 小而聚焦的任务
+- 每个任务建议控制在 2-5 分钟内
+- 每个任务只对应一个明确结果
+- 每个任务都应可独立验证
+
+### 2. 明确的验证标准
+- 如何判断它已经完成？
+- 可以检查/测试什么？
+- 预期输出是什么？
+
+### 3. 合理的执行顺序
+- 识别任务依赖关系
+- 尽可能并行执行
+- 标出关键路径（Critical Path）
+- **阶段 X：验证（Verification）永远放在最后**
+
+### 4. 在项目根目录动态命名
+- 计划文件保存为项目根目录下的 `{task-slug}.md`
+- 文件名由任务语义派生（例如“添加鉴权” → `auth-feature.md`）
+- **绝不能**放在 `.claude/`、`docs/` 或临时目录中
+
+## 规划原则（不是模板）
+
+> 🔴 **不要使用固定模板。每份计划都必须匹配当前任务。**
+
+### 原则 1：保持简洁
+
+| ❌ 错误 | ✅ 正确 |
+|---------|---------|
+| 50 个任务并含多层子任务 | 最多 5-10 个清晰任务 |
+| 罗列所有微步骤 | 只保留可执行项 |
+| 描述冗长 | 每个任务一行说明 |
+
+> **规则：** 如果计划超过 1 页，通常就过长了。请继续精简。
+
+---
+
+### 原则 2：具体，不要泛化
+
+| ❌ 错误 | ✅ 正确 |
+|---------|---------|
+| “搭建项目” | “运行 `npx create-next-app`” |
+| “添加鉴权” | “安装 next-auth，并创建 `/api/auth/[...nextauth].ts`” |
+| “美化界面” | “为 `Header.tsx` 添加 Tailwind 类” |
+
+> **规则：** 每个任务都要有清晰且可验证的完成结果。
+
+---
+
+### 原则 3：按项目类型动态生成内容
+
+**对于新项目（NEW PROJECT）：**
+- 技术栈是什么？（先决定）
+- MVP（最小可行产品）是什么？（最小功能集合）
+- 文件结构如何设计？
+
+**对于功能新增（FEATURE ADDITION）：**
+- 会影响哪些文件？
+- 需要哪些依赖？
+- 如何验证功能可用？
+
+**对于缺陷修复（BUG FIX）：**
+- 根因是什么？
+- 需要改哪一个文件/哪一行？
+- 如何验证修复有效？
+
+---
+
+### 原则 4：脚本必须与项目匹配
+
+> 🔴 **不要复制粘贴脚本命令。必须按项目类型选择。**
+
+| 项目类型 | 相关脚本 |
+|----------|----------|
+| Frontend/React（前端/React） | `ux_audit.py`, `accessibility_checker.py` |
+| Backend/API（后端/API） | `api_validator.py`, `security_scan.py` |
+| Mobile（移动端） | `mobile_audit.py` |
+| Database（数据库） | `schema_validator.py` |
+| Full-stack（全栈） | 根据修改范围组合上述脚本 |
+
+**错误：** 每份计划都塞入所有脚本  
+**正确：** 仅保留与当前任务相关的脚本
+
+---
+
+### 原则 5：验证应简单直接
+
+| ❌ 错误 | ✅ 正确 |
+|---------|---------|
+| “验证组件工作正常” | “运行 `npm run dev`，点击按钮，看到 toast” |
+| “测试 API” | “`curl localhost:3000/api/users` 返回 200” |
+| “检查样式” | “打开浏览器，确认深色模式切换可用” |
+
+---
+
+## 计划结构（灵活而非固定）
+
+```
+# [任务名称]
+
+## 目标（Goal）
+一句话：我们要构建/修复什么？
+
+## 任务（Tasks）
+- [ ] 任务 1：[具体动作] → 验证：[如何检查]
+- [ ] 任务 2：[具体动作] → 验证：[如何检查]
+- [ ] 任务 3：[具体动作] → 验证：[如何检查]
+
+## 完成标准（Done When）
+- [ ] [主要成功标准]
+```
+
+> **就这些。** 除非确实必要，否则不要额外加阶段和子章节。  
+> 保持最小化，只有在需要时才增加复杂度。
+
+## 备注（Notes）
+[任何重要注意事项]
+```
+
+---
+
+## 最佳实践（速查）
+
+1. **先写目标** - 明确构建/修复的对象
+2. **最多 10 个任务** - 超过就拆为多份计划
+3. **每个任务可验证** - 给出清晰“完成”标准
+4. **与项目绑定** - 不使用复制粘贴模板
+5. **边做边更新** - 完成后及时标记 `[x]`
+
+---
+
+## 适用场景
+
+- 从零开始新项目
+- 新增功能
+- 修复复杂缺陷
+- 涉及多文件的重构