helloagents 1.1.0 → 2.2.7

package/Codex/Skills/CN/skills/helloagents/analyze/SKILL.md

@@ -1,187 +0,0 @@
----
-name: analyze
-description: 需求分析阶段详细规则；进入需求分析时读取；包含需求评分、追问逻辑、代码分析步骤
----
-
-# 需求分析 - 详细规则
-
-**目标:** 验证需求完整性，分析代码现状，为方案设计提供基础
-
-**执行流程:**
-```
-阶段A (步骤1-4) → 关键检查点: 评分≥7分?
-  ├─ 是 → 执行阶段B (步骤5-6) → 输出总结
-  └─ 否 → 输出追问问题 → 等待用户补充 → 重新评分或取消
-```
-
-**重要:** 评分 < 7分时，禁止执行阶段B，禁止输出总结，只能输出追问格式
-
----
-
-## 阶段A: 需求评估
-
-### 步骤1: 检查知识库状态
-
-```yaml
-判定条件: 工作目录存在代码文件 且 需求不是"新建项目"
-执行方式: 按 G10 快速决策树判定，如需详细操作则读取 `kb` Skill执行
-问题标记: 如知识库不存在/不合格，标记问题（P1只读，不创建）
-```
-
-### 步骤2: 获取项目上下文
-
-```yaml
-执行方式: 按 G10 快速流程执行（先检查知识库 → 不足则扫描代码库）
-详细规则: 如需完整规则，读取 `kb` Skill
-目的: 为评分和追问提供完整项目上下文，避免低级问题
-```
-
-### 步骤3: 需求类型判定
-
-- 判定是否触发 G8 产品设计原则（新项目/新功能/重大重构）
-- 判定需求具体类型（新项目初始化、重大功能重构、常规功能开发、技术变更等）
-
-### 步骤4: 需求完整性评分 【关键检查点】
-
-<requirement_scoring>
-**评分原则:**
-- 如已完成项目上下文获取，评分时应考虑已获取的所有项目信息
-- 严格评分标准: 知识库和代码扫描只能提供技术上下文，不能替代用户需求明确性
-- 即使技术信息充足，如果用户需求本身模糊（如"优化代码"、"改进交互"），仍需追问
-
-**追问规则:**
-- 严格避免询问已知信息: 技术栈、框架、模块结构、可从代码推断的实现细节
-- 只询问用户相关信息: 具体需求、业务逻辑、期望结果、优先级、约束条件
-
-**评分维度(总分10分):**
-- 目标明确性 (0-3分): 任务目标是否清晰具体
-- 预期结果 (0-3分): 成功标准和交付物是否明确
-- 边界范围 (0-2分): 任务范围和边界是否清楚
-- 约束条件 (0-2分): 时间、性能、业务限制等是否说明
-
-**评分推理过程（在 <thinking> 标签中完成，不输出给用户）：**
-
-```
-<thinking>
-1. 逐项分析评分维度：
-   - 目标明确性 (0-3分): [分析用户需求的目标清晰度] → [X分]
-   - 预期结果 (0-3分): [分析成功标准是否明确] → [X分]
-   - 边界范围 (0-2分): [分析任务范围是否清楚] → [X分]
-   - 约束条件 (0-2分): [分析约束条件是否说明] → [X分]
-2. 列举支持该评分的具体证据（引用用户原话）
-3. 识别缺失的关键信息点
-4. 计算总分: X/10分
-5. 判定: [是否需要追问及理由]
-</thinking>
-```
-
-**基于推理结果执行：**
-- 评分≥7分 → 继续执行阶段B
-- 评分<7分 → 输出追问格式
-</requirement_scoring>
-
-### 追问输出格式（评分 < 7分时）
-
-使用统一输出格式，行首: `❓【HelloAGENTS】- 需求分析`
-
-内容格式: 简要说明(1-2句，含当前评分) + 空行 + 扁平化问题清单(3-5个带序号) + 结束语
-
-禁止显示: 评分维度明细、分类标题、下一步建议、文件变更
-
-**示例:**
-```
-❓【HelloAGENTS】- 需求分析
-
-当前需求完整性评分为 5/10 分，无法明确优化目标和预期效果。
-
-1. 您要优化哪个文件或模块的代码?
-2. 当前存在什么具体问题需要优化?（如性能慢、代码重复等）
-3. 期望优化后达到什么效果?
-4. 有具体的性能指标或时间要求吗?
-
-请按序号回答，或输入"以现有需求继续"跳过追问（可能影响方案质量）。
-```
-
-### 评分后处理
-
-```yaml
-评分≥7分: 继续执行阶段B
-
-评分<7分: 立即停止，输出追问，等待响应，不执行阶段B
-  追问循环:
-    - 用户补充 → 重新评分 → 评分≥7分则继续，评分<7分则再次追问
-  用户选择处理:
-    - "以现有需求继续": 直接执行阶段B（无需再次确认）
-    - "取消":
-      - 交互确认模式: 按G6.2输出取消格式
-      - 推进模式: 清除 MODE_FULL_AUTH/MODE_PLANNING，按G6.2输出取消格式
-      - 取消输出示例:
-        ```
-        🚫【HelloAGENTS】- 已取消
-
-        已取消: 需求分析
-        ────
-        🔄 下一步: 可重新描述需求或进行其他操作
-        ```
-  模式处理:
-    - 交互确认模式: 满足条件→阶段B→需求分析完成后需确认进入方案设计
-    - 推进模式: 暂停连续执行，满足条件→阶段B→恢复静默连续执行
-```
-
----
-
-## 阶段B: 代码分析（仅评分≥7分后执行）
-
-### 步骤5: 提取关键目标与成功标准
-
-- 提取关键目标: 从完整需求中提炼核心目标
-- 定义成功标准: 明确可验证的成功标准
-
-### 步骤6: 代码分析与技术准备
-
-```yaml
-执行内容:
-  - 判定项目规模（按 G4 规则）
-  - 定位相关模块
-  - 质量检查: 标记过时信息，扫描安全风险和代码异味
-  - 问题诊断: 分析日志或错误信息（如有）
-  - 技术信息收集（如需要）: 使用联网搜索或MCP工具(Context7)获取最新文档和最佳实践
-
-输出物: 项目上下文信息（技术栈、模块结构、质量问题、技术约束）供P2方案设计使用
-```
-
----
-
-## 需求分析 输出格式
-
-⚠️ **CRITICAL - 强制要求:**
-- ALWAYS使用G6.1统一输出格式
-- NEVER使用自由文本替代规范格式
-- 输出前MUST验证格式完整性
-
-**评分≥7分时（阶段A+B完成后输出）:**
-
-严格调用 G6.1 统一输出格式，填充以下数据：
-
-1. **阶段名称:** `需求分析`
-2. **阶段具体内容(≤5条要点):**
-   - 📋 完整需求描述(整理)
-   - 🏷️ 需求类型: 技术变更/产品功能
-   - 📊 需求完整性评分: X/10分
-   - 🎯 关键目标与成功标准
-   - 📚 知识库状态
-3. **文件变更清单:**
-   📁 变更: 无
-4. **下一步建议:**
-   - 交互确认模式: 是否进入方案设计?（是/否）
-   - 推进模式: 静默进入方案设计
-
----
-
-## 阶段转换规则
-
-```yaml
-评分 < 7分: 循环追问，直到评分≥7分或用户取消
-评分≥7分 且 交互确认模式: 输出总结→停止→等待确认
-评分≥7分 且 (MODE_FULL_AUTH=true 或 MODE_PLANNING=true): 完成需求分析→立即静默进入方案设计
-```

package/Codex/Skills/CN/skills/helloagents/design/SKILL.md

@@ -1,261 +0,0 @@
----
-name: design
-description: 方案设计阶段详细规则；进入方案设计时读取；包含方案构思、任务拆解、风险评估、方案包创建
----
-
-# 方案设计 - 详细规则
-
-**目标:** 构思可行方案并制定详细执行计划，生成 plan/ 目录下的方案包
-
-**前置条件:** 需求分析已完成（评分≥7分）
-
-**重要:** 方案设计必须创建新方案包，适用于所有模式（交互确认/全授权/规划命令）
-
-**执行流程:**
-```
-方案构思 → [用户确认/推进模式下连续] → 详细规划（创建新方案包）
-```
-
----
-
-## 方案构思
-
-### 动作步骤
-
-**1. 检查知识库状态并处理**
-- 按 G10 快速决策树判定
-- 如需创建/重建知识库 → 读取 `kb` Skill执行完整流程
-
-**2. 读取知识库**
-- 按 G10 快速流程执行（先检查知识库 → 不足则扫描代码库）
-- 如需详细规则 → 读取 `kb` Skill
-
-**3. 判定项目规模**
-- 按 G4 规则执行
-
-**4. 判定需求类型并选择模板**
-- 按G8判定是否触发产品设计原则
-- 技术变更（未触发G8）: 使用基础模板
-- 产品功能（触发G8）: 使用完整模板（包含产品分析章节）
-
-**5. 产品视角分析（步骤4判定为"产品功能"时执行）**
-- 用户画像、场景分析、痛点分析
-- 价值主张、成功指标
-- 人文关怀考量
-
-**6. 任务复杂度判定**
-
-满足任一条件为复杂任务:
-```yaml
-- 需求属于"新项目初始化"或"重大功能重构"
-- 涉及架构决策
-- 涉及技术选型
-- 存在多种实现路径
-- 涉及多个模块(>1)或影响文件数>3
-- 用户明确要求多方案
-```
-
-**7. 方案构思**
-
-<solution_design>
-**方案评估标准:**
-- 优点
-- 缺点
-- 性能影响
-- 可维护性
-- 实现复杂度
-- 风险评估（含EHRB）
-- 成本估算
-- 是否符合最佳实践
-
-**方案构思推理过程（在 <thinking> 标签中完成，不输出给用户）：**
-
-```
-<thinking>
-1. 列举所有可能的技术路径
-2. 逐一评估每个路径的优缺点、风险、成本
-3. 筛选出 2-3 个最可行的方案
-4. 确定推荐方案及理由
-</thinking>
-```
-
-**基于推理结果执行：**
-
-**复杂任务（强制方案对比）:**
-- 生成 2-3 个可行方案
-- 详细评估每个方案
-- 确定推荐方案和理由
-- 输出格式: 推荐方案标题后加"推荐"标识
-  - 例: "方案1（最小变更修复-推荐）" vs "方案2（完整重构）"
-- 交互确认模式: 输出方案对比，询问用户选择
-- 推进模式: 选择推荐方案（不输出对比）
-
-**简单任务:**
-- 直接确定唯一可行方案
-- 简要说明方案
-</solution_design>
-
-### 方案构思 输出格式（等待用户选择方案时）
-
-行首: `❓【HelloAGENTS】- 方案构思`
-
-**输出内容(≤5条要点):**
-```
-❓【HelloAGENTS】- 方案构思
-
-- 📚 上下文: [项目规模] | [知识库状态]
-- 📋 需求类型: [技术变更/产品功能]
-- 🔍 复杂度: [复杂任务] - [判定依据]
-- 💡 方案对比:
-  - 方案1: [名称-推荐] - [一句话说明]
-  - 方案2: [名称] - [一句话说明]
-- ⚠️ 风险提示: [如有EHRB或重大风险]
-
-────
-🔄 下一步: 请输入方案序号(1/2/3)选择方案
-```
-
-**详细方案说明:** 如用户需要详细对比，可追问后展开
-
-### 方案构思 子阶段转换
-
-```yaml
-复杂任务:
-  交互确认模式:
-    - 用户选择有效序号(1-N) → 进入详细规划
-    - 用户拒绝所有方案 → 输出重新构思询问格式
-      - 确认重新构思: 返回方案构思，重新构思
-      - 拒绝: 提示"已取消方案设计"，流程终止
-      - 其他输入: 再次询问
-  推进模式:
-    - 选择推荐方案 → 立即静默进入详细规划
-
-简单任务: 直接进入详细规划
-```
-
-**重新构思方案询问格式:**
-```
-❓【HelloAGENTS】- 方案确认
-
-所有方案均被拒绝。
-
-[1] 重新构思 - 基于反馈重新设计方案
-[2] 取消 - 终止方案设计
-
-────
-🔄 下一步: 请输入序号选择
-```
-
----
-
-## 详细规划
-
-**前提:** 用户已选择/确认方案（来自方案构思）
-
-**重要:** 必须创建新方案包，使用当前时间戳，不得复用 plan/ 中的遗留方案
-
-### 动作步骤
-
-**所有文件操作遵循G5静默执行规范**
-
-**1. 创建新方案包目录**
-
-```yaml
-路径: plan/YYYYMMDDHHMM_<feature>/
-冲突处理:
-  1. 检查 plan/YYYYMMDDHHMM_<feature>/ 是否存在
-  2. 如不存在 → 直接创建
-  3. 如存在 → 使用版本后缀: plan/YYYYMMDDHHMM_<feature>_v2/
-     (如 _v2 也存在，则递增为 _v3, _v4...)
-示例:
-  - 首次创建: plan/202511181430_login/
-  - 同名冲突: plan/202511181430_login_v2/
-```
-
-**2. 新库/框架文档查询（如需要）**
-```yaml
-触发条件: 方案涉及项目中从未使用过的第三方库/框架，或涉及重大版本升级
-执行方式: 使用联网搜索或MCP工具(Context7)查询最新文档
-记录位置: how.md 的 技术方案 章节
-```
-
-**3. 生成方案文件**
-
-读取 `templates` Skill 获取模板，生成:
-- `why.md` (变更提案/产品提案)
-- `how.md` (技术设计+ADR)
-- `task.md` (任务清单)
-
-**任务清单编写规则:**
-```yaml
-单任务代码改动量控制:
-  - 常规项目: ≤3文件/任务
-  - 大型项目: ≤2文件/任务
-验证任务: 定期插入
-安全检查: 必须包含安全检查任务
-```
-
-**4. 风险规避措施制定**
-- 基于方案构思风险评估，按G9制定详细规避措施
-- 交互确认模式: 询问用户
-- MODE_FULL_AUTH=true 或 MODE_PLANNING=true: 规避风险
-- 写入 `how.md` 的 安全与性能 章节
-
-**5. 设置方案包跟踪变量**
-```yaml
-设置: CREATED_PACKAGE = 步骤1创建的方案包路径
-用途: 在全授权命令中传递给开发实施，确保执行正确的方案包
-```
-
----
-
-## 方案设计 输出格式
-
-⚠️ **CRITICAL - 强制要求:**
-- ALWAYS使用G6.1统一输出格式
-- NEVER使用自由文本替代规范格式
-- 输出前MUST验证格式完整性
-
-严格调用 G6.1 统一输出格式，填充以下数据：
-
-1. **阶段名称:** `方案设计`
-2. **阶段具体内容(≤5条要点):**
-   - 📚 知识库状态
-   - 📝 方案概要（复杂度、方案说明）
-   - 📋 变更清单
-   - 📊 任务清单概要
-   - ⚠️ 风险评估（如检测到EHRB）
-3. **文件变更清单:**
-   - `helloagents/plan/YYYYMMDDHHMM_<feature>/why.md`
-   - `helloagents/plan/YYYYMMDDHHMM_<feature>/how.md`
-   - `helloagents/plan/YYYYMMDDHHMM_<feature>/task.md`
-4. **下一步建议:**
-   - 交互确认模式: 是否进入开发实施?（是/否）
-   - 规划命令: 方案包已生成，如需执行请输入`~exec`
-5. **遗留方案提醒:**
-   - 按G11扫描plan/目录
-   - 如检测到遗留方案包（排除本次创建的方案包），按G11规则显示
-
----
-
-## 阶段转换规则
-
-```yaml
-交互确认模式:
-  - 输出总结（包含"🔄 下一步: 是否进入开发实施?(是/否)"）
-  - 停止并等待用户明确确认
-  - 用户响应处理：
-    - 明确确认("是"/"继续"/"确认"等) → 进入开发实施
-    - 明确拒绝("否"/"取消"等) → 流程终止
-    - Feedback-Delta(提出修改意见) → 按Feedback-Delta规则处理
-    - 其他输入 → 视为新的用户需求，按路由机制重新判定
-
-推进模式:
-  - 全授权命令: 完成方案设计 → 立即静默进入开发实施
-  - 规划命令: 输出整体总结 → 停止 → 清除MODE_PLANNING
-
-关键约束（只有以下3种情况可以进入开发实施）：
-  1. 方案设计完成后用户明确确认
-  2. 全授权命令(~auto等)触发且已完成方案设计
-  3. 执行命令(~exec等)触发且plan/中存在方案包
-```