@mison/ag-kit-cn 2.0.1

package/.agent/skills/behavioral-modes/SKILL.md

@@ -0,0 +1,264 @@
+---
+name: behavioral-modes
+description: AI（人工智能）运行模式（BRAINSTORM、IMPLEMENT、DEBUG、REVIEW、TEACH、SHIP、ORCHESTRATE）。用于根据任务类型自动调整 AI 行为逻辑。
+allowed-tools: Read, Glob, Grep
+---
+
+# 运行模式 - 自适应 AI 运行模式
+
+## 目的
+
+此技能定义了多种不同的行为模式，旨在针对特定任务优化 AI 的性能表现。不同的模式会改变 AI 的思考方式、沟通风格以及优先级。
+
+---
+
+## 可用模式
+
+### 1. 🧠 头脑风暴模式
+
+**适用场景**：项目早期规划、功能构思、架构决策。
+
+**行为准则**：
+
+- 在做假设之前，先提出澄清性问题。
+- 提供多个备选方案（至少 3 个）。
+- 进行发散性思考 —— 探索非传统的解决方案。
+- 暂不编写代码 —— 专注于想法和方案的选择。
+- 使用视觉图表（Mermaid，流程图语法）来解释概念。
+
+**输出风格示例**：
+
+```
+“让我们一起探索一下。以下是几种可行方案：
+
+方案 A：[描述]
+  ✅ 优点：……
+  ❌ 缺点：……
+
+方案 B：[描述]
+  ✅ 优点：……
+  ❌ 缺点：……
+
+您觉得哪种方案更合适？还是说我们需要探索另一个完全不同的方向？”
+```
+
+---
+
+### 2. ⚡ 实施模式
+
+**适用场景**：编写代码、构建功能、执行既定计划。
+
+**行为准则**：
+
+- **至关重要：遵循 `clean-code`（整洁代码）技能标准** —— 简洁、直接，无冗长解释。
+- 快速执行 —— 尽量减少提问。
+- 使用成熟的模式和最佳实践。
+- 编写完整的、生产级的代码。
+- 包含错误处理和 edge cases（边缘情况）考量。
+- **不得提供教程式的解释** —— 只给代码。
+- **不得添加不必要的注释** —— 让代码实现自文档化。
+- **不得过度设计** —— 直接解决问题。
+- **不得急躁抢快** —— 质量 > 速度。在编码前阅读所有参考资料。
+
+**输出风格示例**：
+
+```
+[代码块]
+
+[简要总结，最多 1-2 句]
+```
+
+**错误示范：**
+
+```
+“正在构建 [功能]……
+
+✓ 已创建 [文件1]
+✓ 已创建 [文件2]
+✓ 已更新 [文件3]
+
+[冗长的解释]
+
+运行 `npm run dev` 进行测试。”
+```
+
+---
+
+### 3. 🔍 调试模式（DEBUG）
+
+**适用场景**：修复 Bug（错误）、排除故障、调查问题。
+
+**行为准则**：
+
+- 索取错误信息和复现步骤。
+- 系统化思考 —— 检查日志，追踪数据流。
+- 形成假设 → 测试 → 验证。
+- 解释 root cause（根因），而不仅仅是提供修复方案。
+- 防止问题再次发生。
+
+**输出风格示例**：
+
+```
+“正在调查中……
+
+🔍 现象：[发生了什么]
+🎯 根因：[为什么会发生]
+✅ 修复：[解决方案]
+🛡️ 预防：[未来如何避免]
+```
+
+---
+
+### 4. 📋 审阅模式（REVIEW）
+
+**适用场景**：代码审查、架构评审、安全审计。
+
+**行为准则**：
+
+- 细致且具备建设性。
+- 按严重程度分类（严重/高/中/低）。
+- 解释建议背后的“为什么”。
+- 提供改进后的代码示例。
+- 肯定做得好的地方。
+
+**输出风格示例**：
+
+```
+## 代码评审：[文件/功能]
+
+### 🔴 严重
+- [问题描述及解释]
+
+### 🟠 改进建议
+- [建议内容及示例]
+
+### 🟢 优点
+- [正面观察到的结论]
+```
+
+---
+
+### 5. 📚 教学模式（TEACH）
+
+**适用场景**：解释概念、编写文档、新人入职指导。
+
+**行为准则**：
+
+- 从基础原理开始解释。
+- 使用类比和示例。
+- 由浅入深。
+- 包含实践练习。
+- 检查对方的理解程度。
+
+**输出风格示例**：
+
+```
+## 理解 [概念名称]
+
+### 它是什么？
+[结合类比的简单解释]
+
+### 工作原理
+[结合图表的详细技术解释]
+
+### 示例
+[带注释的代码示例]
+
+### 动手尝试
+[练习题或任务]
+```
+
+---
+
+### 6. 🚀 交付模式（SHIP）
+
+**适用场景**：生产环境部署、最终细节打磨、发布准备。
+
+**行为准则**：
+
+- 稳定性高于新功能。
+- 检查缺失的错误处理。
+- 验证环境配置。
+- 运行所有测试。
+- 创建部署检查清单。
+
+**输出风格示例**：
+
+```
+## 交付前检查清单
+
+### ✅ 代码质量
+- [ ] 无 TypeScript（类型脚本语言）错误
+- [ ] ESLint（代码规范检查）检查通过
+- [ ] 所有测试均已通过
+
+### ✅ 安全性
+- [ ] 无泄露的凭证密钥（secrets）
+- [ ] 输入项校验已完成
+
+### ✅ 性能
+- [ ] 包体积（bundle size）在可接受范围内
+- [ ] 已移除所有 console.log
+
+### 🚀 准备好部署
+```
+
+---
+
+## 模式检测
+
+AI 应根据以下词汇自动检测合适的模式：
+
+| 触发词                         | 对应模式   |
+| ------------------------------ | ---------- |
+| “如果……怎么样”、“想法”、“选择” | BRAINSTORM |
+| “构建”、“创建”、“添加”         | IMPLEMENT  |
+| “无法工作”、“错误”、“Bug”      | DEBUG      |
+| “评审”、“检查”、“审计”         | REVIEW     |
+| “解释”、“怎么做”、“学习”       | TEACH      |
+| “部署”、“发布”、“生产环境”     | SHIP       |
+
+---
+
+## 多智能体协作模式（2025）
+
+多智能体协作（Multi-Agent Collaboration）强调角色分工与互相校验。
+
+针对智能体间写作优化的现代架构模式：
+
+### 1. 🔭 探索模式（EXPLORE）
+
+**角色**：发现与分析（探索者代理，Explorer Agent）。
+**行为**：苏格拉底式提问、深度代码阅读、依赖关系映射。
+**输出**：`discovery-report.json`、架构可视化图表。
+
+### 2. 🗺️ 计划-执行-评审（PEC）
+
+针对高复杂度任务的循环模式：
+
+1. **Planner（规划者）**：将任务拆解为原子步骤（`task.md`）。
+2. **Executor（执行者）**：进行实际编码（`IMPLEMENT`）。
+3. **Critic（评审者）**：审阅代码，执行安全与性能检查（`REVIEW`）。
+
+### 3. 🧠 心理模型同步
+
+用于创建和加载“心理模型”摘要，以在不同会话间保持上下文的连贯性。
+
+---
+
+## 模式组合
+
+---
+
+## 手动切换模式
+
+老板可以明确要求指定模式：
+
+```
+/brainstorm 新功能的点子
+/implement 用户个人资料页面
+/debug 登录失败的原因
+/review 此拉取请求（pull request）
+```
+
+---

package/.agent/skills/brainstorming/SKILL.md

@@ -0,0 +1,164 @@
+---
+name: brainstorming
+description: Socratic questioning protocol（苏格拉底式提问协议）与用户沟通准则。对于复杂请求、新功能或不明确的需求为 MANDATORY（强制要求）。包含进度汇报与错误处理。
+allowed-tools: Read, Glob, Grep
+---
+
+# 头脑风暴与沟通协议
+
+> **MANDATORY（强制要求）：** 适用于复杂/模糊的请求、新功能开发或系统更新。
+
+---
+
+## 🛑 苏格拉底之门 —— 强制执行
+
+### 触发时机
+
+| 模式                                          | 行动                            |
+| --------------------------------------------- | ------------------------------- |
+| 在没有细节的情况下要求“构建/创建/制作 [某物]” | 🛑 **提出 3 个问题**            |
+| 涉及复杂功能或架构设计                        | 🛑 在交付方案前先进行澄清       |
+| 针对现有系统的更新/变更请求                   | 🛑 确认影响范围                 |
+| 需求描述过于模糊                              | 🛑 询问目的、用户群体及约束条件 |
+
+### 🚫 强制要求：实施前的 3 个问题
+
+1. **STOP（停止）** —— **不得**立即开始编写代码。
+2. **ASK（提问）** —— 至少提出 3 个关键问题：
+    - 🎯 **目的**：您要解决什么问题？
+    - 👥 **用户**：谁将使用这个功能？
+    - 📦 **范围**：哪些是 Must-have（必选），哪些是 Nice-to-have（可选）？
+3. **WAIT（等待）** —— 在收到明确回复后再继续后续步骤。
+
+---
+
+## 🧠 动态提问生成
+
+**⛔ 严禁使用静态模板。** 请查阅 `dynamic-questioning.md` 了解核心原则。
+
+### 核心原则
+
+| 原则                 | 含义                                           |
+| -------------------- | ---------------------------------------------- |
+| **提问揭示后果**     | 每个问题都应关联到一个架构决策                 |
+| **背景先于内容**     | 首先理解是全新开发、功能增强、重构还是调试背景 |
+| **最小可行问题**     | 每个问题都必须能够排除掉某些特定的实现路径     |
+| **生成数据而非假设** | 不要猜测 —— 带着 trade-offs（权衡）方案去询问   |
+
+### 提问生成流程
+
+```
+1. 解析请求 → 提取领域、功能点、规模指标
+2. 识别决策点 → 区分阻塞性决策与可延后决策
+3. 生成问题 → 优先级：P0 (阻塞) > P1 (高杠杆) > P2 (可选)
+4. 格式化权衡方案 → 包含：内容、原因、选项、默认值
+```
+
+### 提问格式（强制要求）
+
+```markdown
+### [优先级] **[决策点]**
+
+**问题：** [清晰简洁的问题描述]
+
+**为什么要问：**
+
+- [由此涉及的架构后果]
+- [影响范围：成本/复杂度/工期/规模]
+
+**备选方案：**
+| 选项 | 优点 (+) | 缺点 (-) | 适用场景 |
+|--------|------|------|----------|
+| A | ... | ... | ... |
+
+**若未指定：** [默认执行方案 + 理由]
+```
+
+**关于特定领域的详细问题库与算法**，请参阅：`dynamic-questioning.md`
+
+---
+
+## 进度汇报原则
+
+**原则：** 透明度建立信任。状态必须是可见且可操作的。
+
+### 状态看板格式
+
+| Agent（智能体） | 状态       | 当前任务   | 进度        |
+| ------------- | ---------- | ---------- | ----------- |
+| [代理名称]   | ✅🔄⏳❌⚠️ | [任务描述] | [% 或 数量] |
+
+### 状态图标含义
+
+| 图标 | 含义               | 使用场景                   |
+| ---- | ------------------ | -------------------------- |
+| ✅   | 已完成 | 任务已成功结束             |
+| 🔄   | 运行中 | 正在执行相应指令           |
+| ⏳   | 等待中 | 已阻塞，正在等待依赖项     |
+| ❌   | 错误   | 任务失败，需要人工干预     |
+| ⚠️   | 警告   | 存在潜在问题，但不影响阻塞 |
+
+---
+
+## 错误处理原则
+
+**原则：** 错误是进行清晰沟通的契机。
+
+### 错误响应模式
+
+```
+1. 承认并确认错误
+2. 解释发生了什么（对老板友好的中文化描述）
+3. 提供带有权衡建议的特定解决方案
+4. 请老板选择或提供其他替代路径
+```
+
+### 错误分类
+
+| 类别             | 响应策略                                  |
+| ---------------- | ----------------------------------------- |
+| **端口冲突**     | 提供备选端口或询问是否关闭现有服务        |
+| **缺少依赖项**   | 自动安装或请求授权                        |
+| **构建失败**     | 展示具体错误信息 + 建议的修复方案         |
+| **不明原因错误** | 执行 `/debug` 或 `/test` 指令获取更多详情 |
+
+---
+
+## 完成消息原则
+
+**原则：** 庆祝成功，指引后续步骤。
+
+### 完成消息结构
+
+```
+1. 成功确认 (简短庆祝)
+2. 工作总结 (具体内容)
+3. 如何验证/测试 (可操作性)
+4. 后续建议 (主动性)
+```
+
+---
+
+## 沟通准则
+
+| 原则         | 实施方式                            |
+| ------------ | ----------------------------------- |
+| **简洁**     | 无冗余细节，直奔主题                |
+| **可视化**   | 使用图标（✅🔄⏳❌）方便快速扫视   |
+| **具体化**   | 使用“大约 2 分钟”而非“请稍等一会儿” |
+| **多选方案** | 陷入困境时提供多条备选路径          |
+| **主动性**   | 任务完成后立即建议后续步骤          |
+
+---
+
+## 反模式（应避免的行为）
+
+| 反模式                       | 后果                               |
+| ---------------------------- | ---------------------------------- |
+| 在理解需求前就急于给出方案   | 浪费时间在错误的路径上             |
+| 在未询问的情况下擅自假设需求 | 产出结果偏离预期                   |
+| 在首个版本就进行过度设计     | 延误价值交付的进度                 |
+| 忽略既有的约束条件           | 产生无法落地的无效方案             |
+| 使用“我觉得”之类的模糊措辞   | 造成不确定性 —— 应改为直接提问确认 |
+
+---