@chongyan/autospec 1.0.1

package/knowledge/guides/stages/release-checker.md

@@ -0,0 +1,205 @@
+---
+name: release-checker
+description: 当代码准备部署到生产环境、需要逐项检查所有发布前置条件是否满足时触发
+type: review
+---
+
+## 定位
+交付阶段的"审"类skill。发布前的最后一道关卡，确保所有前置条件就绪，不带病上线。
+
+## 输入
+- 必须输入：QA测试报告、回滚方案
+- 可选输入：变更记录、methodology/checklists/release.md（检查标准）、关键假设清单（全链路）
+
+## 评判标准
+
+### 必须满足（所有模式）
+- [ ] QA测试报告结论为通过
+- [ ] 无未解决的Critical/Major级别缺陷
+- [ ] 回滚方案已准备并验证可行
+- [ ] 变更记录已编写
+- [ ] 数据库变更（如有）已review并有回滚脚本
+- [ ] 配置变更（如有）已确认
+- [ ] 关键假设全链路已验证
+
+### 多系统模式额外检查
+- [ ] 各子系统变更已确认
+- [ ] 跨系统接口变更已同步
+- [ ] 部署顺序已确定（通常：后端→前端→移动端；有ml时：模型服务可能需要先部署）
+
+### AI/模型功能额外检查
+- [ ] 效果评测已完成
+- [ ] 效果指标达到基线要求
+- [ ] 评测报告已产出
+- [ ] Badcase已分析和处理
+
+### 数据系统额外检查
+- [ ] 数据质量检查通过
+- [ ] ETL流程验证通过
+- [ ] 数据回滚方案已准备
+
+### 必须满足（高可用）
+- [ ] 应急开关/降级方案已准备（限流、降级、熔断）
+- [ ] 关键业务指标监控已配置（不仅技术指标，也含业务指标）
+- [ ] 资损点已识别并有针对性保障措施（如涉及资金）
+
+### 建议满足
+- [ ] 相关方已通知
+- [ ] 监控告警已配置或确认（含业务趋势波动监控）
+- [ ] 灰度/分批发布策略已确定（如适用）
+- [ ] 遗留风险已记录并经确认可接受
+- [ ] 发布时间窗口合适
+- [ ] 容量评估已完成（压测数据支撑）
+- [ ] 变更回滚预案已演练验证
+
+## 评审步骤
+
+### Step 1: 确定模式
+
+读取 `.autospec/config.json`，检查 `subsystems` 字段：
+- **无 subsystems 或长度为1** → 单系统模式
+- **有 subsystems 且长度>1** → 多系统模式
+
+检查是否需要效果验收：
+- 有 `type: ai` 的子系统或 `needsEvaluation: true` → 需要效果验收
+
+### Step 2: 单系统模式
+
+1. 检查QA测试报告状态和结论
+   - 证据获取：直接引用测试报告结论
+2. 检查是否有未关闭的blocking缺陷
+3. 检查回滚方案是否存在且可行
+   - 证据获取：回滚方案的具体步骤和预计耗时
+4. 检查变更记录是否完整
+5. 检查数据库和配置变更（如适用）
+6. 检查宪法门禁（不可违反红线）
+7. 检查通知和监控准备
+8. **检查关键假设全链路验证状态**
+9. **影响分析**：
+   - 分析任务依赖的表/接口
+   - 查询这些依赖被哪些下游使用
+   - 评估影响范围和风险
+   - 输出影响分析报告
+10. 汇总遗留风险
+11. 逐项输出判定结果，**每项附具体证据**
+
+### Step 3: 多系统模式
+
+1. **各子系统发布检查**：
+   ```
+   for subsystem in config.subsystems:
+     a. 检查 {subsystem.path} 变更内容
+     b. 确认 {subsystem.build} 成功
+     c. 确认 {subsystem.test} 通过
+     d. 检查依赖版本
+     e. 记录发布项
+   ```
+
+2. **跨系统一致性检查**：
+   - 确认跨系统接口变更已同步
+   - 确认部署顺序合理
+
+3. **汇总检查结果**
+
+### Step 4: 效果验收（AI/模型功能）
+
+当项目包含 AI/模型 相关功能时，需要额外验收：
+
+1. **检查评测报告**：
+   - 评测数据集是否覆盖典型场景
+   - 效果指标是否达到设计阶段定义的基线
+   - Badcase是否已分析和处理
+
+2. **效果指标验收**：
+   - 核心效果指标是否达标
+   - 业务效果指标是否达标（如有）
+   - 未达标指标是否有改进计划
+
+3. **智能体验收**（如适用）：
+   - 任务完成率是否达标
+   - 响应质量是否达标
+   - 工具使用正确率是否达标
+
+4. **产出验收结论**：
+   - 通过：效果达标，可发布
+   - 有风险：效果部分达标，需确认是否接受
+   - 不通过：效果未达标，阻止发布
+
+### Step 5: 数据系统验收
+
+当项目包含数据系统时：
+
+1. **数据质量验收**：
+   - 数据完整性检查结果
+   - 数据一致性检查结果
+   - 数据准确性检查结果
+
+2. **ETL流程验收**：
+   - 数据转换正确性
+   - 性能是否满足要求
+
+3. **数据回滚方案验收**：
+   - 回滚脚本是否准备
+   - 回滚是否可执行
+
+## 输出格式
+
+```
+## 审查结论：可发布 / 不可发布 / 有风险需确认
+
+### 逐项判定
+| 检查项 | 结论 | 证据 | 备注 |
+|--------|------|------|------|
+| QA测试通过 | ✅/❌ | {报告引用} | |
+| 回滚方案就绪 | ✅/❌ | {方案摘要} | {预计回滚耗时} |
+| ... | ... | ... | ... |
+
+### 多系统模式额外项
+| 子系统 | 类型 | 构建 | 测试 | 变更内容 |
+|--------|------|------|------|----------|
+| backend | 后端 | ✅/❌ | ✅/❌ | ... |
+| frontend | 前端 | ✅/❌ | ✅/❌ | ... |
+| ai | AI/模型 | - | ✅/❌ | ... |
+
+### 效果验收（如适用）
+| 指标 | 基线 | 实际 | 结论 |
+|------|------|------|------|
+| 准确率 | ≥90% | 92% | ✅达标 |
+| 召回率 | ≥85% | 83% | ❌未达标 |
+| ... | ... | ... | ... |
+
+### 阻塞项（如不可发布）
+- {具体阻塞原因} → {解决建议}
+
+### 遗留风险汇总
+- {风险描述} / 影响范围 / 建议处理方式（需人工确认可接受）
+
+### 关键假设最终状态
+- 假设X：已验证通过 / 未验证（风险：...）
+
+### 不可逆动作清单（需人工确认）
+- [ ] 数据库迁移：{描述}
+- [ ] 配置变更：{描述}
+- [ ] 外部API调用：{描述}
+- [ ] 模型部署：{描述}（AI/模型功能）
+
+### 部署方案（多系统模式）
+- 部署顺序：{子系统顺序}
+- 依赖关系：{描述}
+- 回滚计划：{描述}
+```
+
+## 反模式清单（DP7）
+1. **带病上线**：有已知blocking问题但放行。检测：blocking缺陷存在则必须判不可发布
+2. **回滚方案缺失**：忽略回滚方案检查。检测：回滚方案是必选项，不可跳过
+3. **环境差异忽视**：不检查测试/生产环境差异。检测：前置检查包含环境一致性
+4. **不可逆动作放行**：未标记需要人工确认的不可逆动作。检测：输出必须包含不可逆动作清单
+5. **跳过效果验收**：AI/模型功能不验收效果就发布。检测：ml类型子系统必须有效果验收结论
+6. **效果不达标放行**：效果未达标但无改进计划就发布。检测：效果不达标必须有明确的改进计划或人工确认接受
+
+## 适用场景与边界
+- 适用：所有准备发布到生产环境的部署
+- 不适用：开发/测试环境的部署（标准可降低）
+
+## 示例
+（待从实践中积累第一个完整示例）

package/knowledge/guides/stages/requirement-analyzer.md

@@ -0,0 +1,195 @@
+---
+name: requirement-analyzer
+description: 当收到原始需求（口头/文字/issue）需要转化为结构化需求文档时触发
+type: produce
+---
+
+## 定位
+需求阶段的核心"做"类skill。将非结构化的原始需求转化为可指导设计的结构化需求文档。
+
+## 输入
+- 必须输入：原始需求（口头描述、文字记录、issue、用户反馈等）
+- 可选输入：项目背景信息、现有系统信息、相关业务知识
+
+## 输出
+
+结构化需求文档，包含：
+- 需求背景与目的（为什么要做）
+- 功能需求列表（含优先级：P0/P1/P2）
+- 非功能需求（性能、安全、兼容性等）
+- 每条功能需求的验收标准
+- 依赖和约束
+- 不做的事项（明确排除）
+- 待澄清问题列表（最多3个NEEDS CLARIFICATION，其余做合理默认）
+- **关键假设清单**（已确认 / 待确认）
+- **证据清单**（支撑需求合理性的依据：用户反馈来源、数据支撑等）
+
+### 产出物模板（增强版）
+
+产出 `.autospec/specs/{feature}/requirement.md`，建议包含以下章节：
+
+#### 文档头部
+
+```markdown
+---
+document_id: REQ-{feature}-001
+version: v1.0
+created: YYYY-MM-DD
+updated: YYYY-MM-DD
+status: Draft/Review/Approved
+upstream: []
+downstream: [DES-{feature}-001]
+---
+
+## 版本历史
+
+| 版本 | 日期 | 修改人 | 修改说明 |
+|-----|------|--------|---------|
+| v1.0 | YYYY-MM-DD | | 初始版本 |
+```
+
+#### 第一章：背景与目的
+
+- **业务背景**：为什么需要做这个功能？当前痛点是什么？
+- **业务目标**：期望达成的业务指标（可量化）
+- **技术目标**：期望达成的技术指标（如有）
+
+#### 第二章：功能范围
+
+- **功能列表**：做什么
+  - 功能ID | 功能名称 | 优先级 | 验收标准
+- **非功能需求**：性能/安全/兼容性/可用性
+- **不做的事项**：明确排除的范围
+
+#### 第三章：用户场景
+
+- **目标用户**：谁使用这个功能
+- **使用场景**：什么情况下使用
+- **用户故事**：As a... I want to... So that...
+
+#### 第四章：业务规则
+
+从需求提取的业务规则，每个规则引用 BR-ID：
+
+```markdown
+| 规则ID | 规则名称 | 规则描述 | 来源 |
+|--------|---------|---------|------|
+| BR-01 | （规则名） | （描述） | requirement.md#章节 |
+```
+
+如规则未在 `knowledge/domain/rules.md` 中定义，需同步新增。
+
+#### 第五章：边界定义
+
+- **边界案例**：极端情况如何处理
+- **约束条件**：时间/资源/技术约束
+- **依赖识别**：依赖的系统/服务/数据
+
+#### 第六章：风险评估
+
+```markdown
+| 风险ID | 风险名称 | 类型 | 可能性 | 影响 | 缓解措施 |
+|--------|---------|------|--------|------|---------|
+| R-01 | （风险名） | 业务/技术 | 高/中/低 | 高/中/低 | （措施） |
+```
+
+#### 第七章：知识缺失
+
+- **待确认项**：需要进一步确认的问题
+- **假设清单**：当前做的假设（继承关键假设清单）
+
+#### 第八章：Open Questions
+
+待澄清问题列表（最多3个），每个问题附AI推荐答案：
+
+```markdown
+| 序号 | 问题 | AI推荐答案 | 状态 |
+|-----|------|----------|------|
+| 1 | （问题） | （推荐答案） | 待确认/已确认 |
+```
+
+#### 附录
+
+- **术语引用**：引用 `knowledge/domain/glossary.md` 中的术语
+- **流程引用**：引用 `knowledge/domain/flows/` 中的流程图
+
+### 自查清单（嵌入式）
+
+产出完成后，执行自查：
+
+- [ ] 每条功能有明确的验收标准
+- [ ] 业务规则已提取并ID化
+- [ ] 术语已在 glossary.md 中定义（如有新术语）
+- [ ] 关键流程已有流程图（如有）
+- [ ] 风险已评估并有缓解措施
+- [ ] 假设已明确记录
+- [ ] 待澄清问题不超过3个
+
+## 执行步骤
+1. 通读原始需求，理解背景和目的
+   - 预期产出：对需求背景的一段话总结
+   - 失败处理：背景不清晰则标记为NEEDS CLARIFICATION
+2. **需求穿透**：至少追问两层"为什么"
+   - 用户方案（What）→ 产品需求（How）→ 真实痛点（Why）
+   - 用JTBD三维度分析：功能任务 / 情感任务 / 社会任务
+3. **价值验证**：检查客户价值公式
+   - 客户价值 = 新方案价值 - 旧方案价值 - 转换成本 > 0
+   - 如不成立，标记为待讨论
+4. 提取功能点，拆解为独立的功能需求条目（MECE原则）
+5. 对每条功能需求，按5W标准描述：
+   a. Who（用户角色）/ Where+When（场景）/ What（需求）/ Why（动机）
+   b. 定义验收标准（可验证的条件）
+   c. 识别模糊点（如有，加入待澄清列表）
+6. 补充非功能需求（参考 methodology/checklists/requirement.md）
+7. 识别依赖关系和约束条件
+8. 明确不做的事项（防止范围蔓延）
+9. 排定优先级（P0必做/P1应做/P2可做）
+10. 定义效果指标和基线（当前是什么、目标是什么）
+11. **整理关键假设清单**，标注已确认/待确认
+12. **整理证据清单**，标注每条需求的支撑依据
+
+## 反模式清单（DP7）
+1. **需求镀金**：加入原始需求未提及的功能。检测：每条功能回溯到原始诉求，无法回溯的删除
+2. **隐含需求遗漏**：用户没说但理应包含的。检测：用checklist逐项检查非功能需求
+3. **边界模糊**：什么算做完没说清。检测：强制填写验收标准和排除项
+4. **假设隐藏**：假设了条件但未显式记录。检测：强制填写关键假设清单
+5. **过度澄清**：无限追问延迟推进。检测：最多3个NEEDS CLARIFICATION，其余做合理默认
+6. **范围蔓延**：拆解过程中不断扩大范围。检测：定期回溯原始需求核心诉求
+
+## 适用场景与边界
+- 适用：所有需要从原始需求产出结构化文档的场景
+- 不适用：需求已经结构化只需评审（用requirement-reviewer）
+- 边界：分析和结构化需求，但不做技术可行性深度评估（那是设计阶段的事）
+- 前置：无
+- 后续：requirement-reviewer审查 → 通过后进入design-planner
+
+## 示例
+**输入**："我们需要给商机项目加一个企业标签筛选功能，用户可以按行业、地区、规模筛选企业"
+**输出**：
+```
+## 需求背景
+商机项目用户需要从大量企业中快速定位目标客户，当前只能通过搜索，无法按维度筛选。
+
+## 功能需求
+1. [P0] 行业筛选：用户可按行业分类筛选企业列表
+   - 验收标准：支持多级行业分类选择，选择后列表实时更新
+2. [P0] 地区筛选：用户可按省/市筛选
+   - 验收标准：支持多选，选择后与行业筛选联动
+3. [P1] 规模筛选：用户可按企业规模档位筛选
+   - 验收标准：支持预设档位（微型/小型/中型/大型）
+
+## 非功能需求
+- 筛选响应时间 < 500ms
+- 支持10万+企业数据量
+
+## 不做
+- 不做自定义筛选维度（本期只做固定3个维度）
+- 不做筛选结果导出
+
+## 关键假设
+- [已确认] 企业数据已有行业、地区、规模字段
+- [待确认] 行业分类使用国标分类体系
+
+## 证据
+- 用户反馈中提及"找不到目标企业"的占比：来自support tickets统计
+```

package/knowledge/guides/stages/requirement-reviewer.md

@@ -0,0 +1,83 @@
+---
+name: requirement-reviewer
+description: 当结构化需求文档完成、需要评审其完整性和无歧义性以决定是否可进入设计阶段时触发
+type: review
+---
+
+## 定位
+需求阶段的"审"类skill。独立审查需求文档质量，作为进入设计阶段的Layer 2质量关卡。
+
+> **做审分离（DP2）**：必须由独立于requirement-analyzer的AI实例执行。
+
+## 输入
+- 必须输入：结构化需求文档（requirement-analyzer的输出）、原始需求（对照是否偏题）
+- 可选输入：methodology/checklists/requirement.md（检查标准）
+
+## 评判标准
+必须满足：
+- [ ] 每条功能需求有明确的验收标准
+- [ ] 需求描述无歧义（不同人读到的理解一致）
+- [ ] 技术可行性已初步评估
+- [ ] 边界清晰（明确列出做什么、不做什么）
+- [ ] 非功能需求已覆盖
+- [ ] 依赖和约束已识别
+- [ ] 未偏离原始需求的核心诉求
+- [ ] 关键假设清单已填写且分类（已确认/待确认）
+- [ ] 待确认假设不超过3个
+
+建议满足：
+- [ ] 有用户场景描述
+- [ ] 优先级已排定
+- [ ] 与现有功能的关联已标注
+- [ ] 效果指标和基线已定义
+
+每条标准必须是可客观判断的。
+
+## 评审步骤
+1. 对照原始需求，检查结构化文档是否覆盖了原始诉求（没有遗漏、没有偏题）
+   - 证据获取：逐条将功能需求回溯到原始需求中的表述
+2. 逐条检查功能需求的验收标准是否可验证
+   - 证据获取：尝试用验收标准判断一个假设的实现"是否通过"
+3. 检查是否有歧义表述（找出可能被不同理解的描述）
+   - 证据获取：列出可能的不同解读
+4. 检查非功能需求是否完整（参考checklist）
+5. 检查边界是否清晰（"不做"列表是否充分）
+6. 检查关键假设清单的完整性和分类准确性
+7. 逐项输出判定结果，**每项附具体证据**
+
+## 输出格式
+
+```
+## 审查结论：通过 / 不通过
+
+### 逐项判定
+| 检查项 | 结论 | 证据 | 备注 |
+|--------|------|------|------|
+| 验收标准完整 | ✅/❌ | {具体引用} | {修复建议} |
+| 无歧义 | ✅/❌ | {歧义实例} | {建议措辞} |
+| ... | ... | ... | ... |
+
+### 必须修复（blocking）
+- ...
+
+### 建议改进（non-blocking）
+- ...
+
+### 关键假设验证
+- 假设X：合理/存疑（证据：...）
+```
+
+## 反模式清单（DP7）
+1. **橡皮图章**：无证据通过。检测：每条"通过"必须附具体证据引用
+2. **吹毛求疵**：纠结措辞等非关键问题。检测：措辞问题归为non-blocking
+3. **脱离上下文**：不参照原始需求审查。检测：审查步骤必须先对照原始需求
+4. **假设验证遗漏**：不检查关键假设清单。检测：输出必须包含假设验证section
+5. **范围蔓延建议**：审查中建议增加功能。检测：审查只判断现有内容质量，不扩展范围
+
+## 适用场景与边界
+- 适用：需求文档完成后，进入设计阶段前
+- 不适用：原始需求还没有被结构化（先用requirement-analyzer）
+- 对应做类skill：requirement-analyzer
+
+## 示例
+（待从实践中积累第一个完整示例）

package/knowledge/guides/stages/security-reviewer.md

@@ -0,0 +1,89 @@
+---
+name: security-reviewer
+description: 当代码包含Skill/Agent相关实现时，审查Skill内容的安全性，防止提示词注入和恶意指令
+type: review
+---
+
+## 定位
+
+安全审查阶段的"审"类skill。专门审查Skill/Agent相关代码，检测提示词注入、输入校验缺失等安全风险。
+
+> **适用场景**：代码中包含Skill定义、Agent提示词、动态指令构建等场景时必须触发。
+
+## 输入
+
+- 必须输入：包含Skill/Agent实现的代码文件
+- 可选输入：Skill定义文件（*.md）、提示词模板
+
+## 评判标准
+
+必须满足：
+
+- [ ] Skill内容无直接用户输入拼接（防止注入）
+- [ ] 输入参数有长度/类型校验
+- [ ] 敏感操作有权限检查
+- [ ] 无硬编码的API密钥或凭证
+- [ ] 动态指令构建有过滤机制
+
+建议满足：
+
+- [ ] 提示词模板与动态内容分离
+- [ ] 有审计日志记录Skill激活
+- [ ] 有速率限制防止滥用
+
+## 审查步骤
+
+1. **识别Skill相关代码**
+   - 搜索 `skill`、`agent`、`prompt`、`instruction` 关键词
+   - 定位Skill定义文件和加载逻辑
+
+2. **审查提示词注入风险**
+   - 检查Skill内容是否直接拼接用户输入
+   - 检查是否有内容过滤/转义机制
+   - 证据获取：列出所有动态注入点
+
+3. **审查输入校验**
+   - 检查参数是否有长度限制
+   - 检查是否有类型校验
+   - 检查是否有敏感词过滤
+
+4. **审查权限控制**
+   - 检查Skill激活是否有权限校验
+   - 检查敏感操作是否有访问控制
+
+5. **审查凭证管理**
+   - 检查是否有硬编码密钥
+   - 检查凭证是否通过安全方式获取
+
+## 输出格式
+
+```
+## 审查结论：通过 / 不通过
+
+### 逐项判定
+| 检查项 | 结论 | 证据 | 备注 |
+|--------|------|------|------|
+| 提示词注入防护 | ✅/❌ | {注入点列表} | {修复建议} |
+| 输入校验 | ✅/❌ | {校验逻辑} | {缺失项} |
+| 权限控制 | ✅/❌ | {权限检查} | {缺失项} |
+| 凭证管理 | ✅/❌ | {凭证处理} | {问题} |
+
+### 必须修复（blocking）
+- ...
+
+### 建议改进（non-blocking）
+- ...
+```
+
+## 反模式清单
+
+1. **直接拼接**：用户输入直接拼接到提示词中
+2. **无校验**：参数传入后不做任何校验
+3. **硬编码密钥**：API密钥直接写在代码中
+4. **无审计**：敏感操作无日志记录
+
+## 适用场景
+
+- 适用：代码中包含Skill/Agent实现、需要审查提示词安全性
+- 不适用：普通业务代码（使用code-reviewer即可）
+- 对应做类skill：code-implementer（需在实现时遵循安全规范）