@chongyan/autospec 1.0.1

package/knowledge/guides/support/skill-validator.md

@@ -0,0 +1,72 @@
+---
+name: skill-validator
+description: 当新建或修改了skill文件、需要验证其是否符合框架标准和质量要求时触发
+type: review
+---
+
+## 定位
+验证新建或修改的skill是否符合框架标准，确保skill质量。是skill生命周期的质量关卡。
+
+## 输入
+- 必须输入：待验证的skill文件
+- 可选输入：skills/_template.md（做/审模板标准）、现有skills列表、methodology/
+
+## 评判标准
+必须满足：
+- [ ] 符合对应模板结构（做类或审类）
+- [ ] frontmatter完整（name, description, type）
+- [ ] description符合CSO原则（只写触发条件，不写工作流摘要）
+- [ ] 输入/输出定义清晰，区分必须/可选
+- [ ] 输出包含关键假设清单和证据清单
+- [ ] 执行步骤/评审步骤可操作（人或AI能直接执行）
+- [ ] 包含反模式清单（至少5条通用 + skill特有）
+- [ ] 至少包含一个完整示例
+- [ ] 与现有skills无功能重叠或逻辑矛盾
+- [ ] 与methodology/principles.md和constitution.md无矛盾
+
+建议满足：
+- [ ] 适用场景与边界描述充分，标注前置/后续skill
+- [ ] 审类skill的评判标准具体可量化
+- [ ] 审类skill的输出格式包含证据表格
+- [ ] 示例覆盖典型场景和边界情况
+
+## 评审步骤
+1. 检查文件格式是否符合模板
+   - 证据获取：逐section对照模板
+2. 检查description是否符合CSO原则
+   - 证据获取：description是否包含触发条件而非工作流摘要
+3. 逐section检查内容完整性
+4. 评估可执行性：假设自己是执行者，能否只凭这个skill文件完成任务
+5. 检查反模式清单的完整性和实用性
+6. 检查与现有skills的关系（有无重叠、冲突、可组合）
+7. 检查与methodology和constitution的一致性
+8. 逐项输出判定结果，**每项附具体证据**
+
+## 输出格式
+
+```
+## 验证结论：通过 / 不通过
+
+### 逐项判定
+| 检查项 | 结论 | 证据 | 备注 |
+|--------|------|------|------|
+| 模板符合 | ✅/❌ | {缺失section列表} | {修复建议} |
+| CSO description | ✅/❌ | {当前description} | {建议修改} |
+| ... | ... | ... | ... |
+
+### 必须修复
+- ...
+
+### 建议改进
+- ...
+```
+
+## 反模式清单（DP7）
+1. **橡皮图章**：不逐项检查就通过。检测：每项必须附证据
+2. **形式主义**：只查格式不查内容质量。检测：必须评估"可执行性"
+3. **标准漂移**：验证标准随意放松。检测：对照模板和宪法逐项检查
+4. **遗漏CSO检查**：不验证description格式。检测：CSO是独立检查项
+
+## 适用场景与边界
+- 适用：新建skill、修改skill后的验证、定期skill质量巡检
+- 不适用：验证非skill类型的文件

package/knowledge/guides/support/team-orchestrator.md

@@ -0,0 +1,323 @@
+---
+name: team-orchestrator
+description: 当需要协调多个角色Agent并行执行对抗审查时触发
+type: support
+---
+
+## 定位
+团队协调器，负责并行启动角色Agent、汇总意见、生成综合审查报告。实现多角色对抗审查的核心调度器。
+
+**AI Native 理念**：创业团队 Agent Team 是可扩展的核心概念，各类任务都可由相关成员组队完成。
+
+## 配置文件依赖
+
+本协调器依赖以下配置文件：
+- `${KNOWLEDGE}/config/team-stage.yaml` - 团队阶段配置
+- `${KNOWLEDGE}/config/role-composition.yaml` - 角色组合规则
+- `${KNOWLEDGE}/config/team-tasks.yaml` - 团队任务分配
+
+## 输入
+- 被审查文档路径
+- 复杂度评估结果（来自 complexity-assessor）
+- 当前阶段（requirement/design/implementation/testing/delivery）
+- 团队阶段（seed/growth/mature，默认 growth）
+
+## 输出
+团队对抗审查报告：
+```markdown
+## 团队对抗审查报告
+
+### 审查概述
+- 审查对象：{文档路径}
+- 当前阶段：{阶段}
+- 团队阶段：{seed/growth/mature}
+- 参与角色：{角色列表}
+- 审查时间：{时间}
+- AI Native 关注：{aiNative描述}
+
+### 各角色意见
+
+#### CEO 视角
+- **结论**：✅ 通过 / ⚠️ 有建议 / ❌ 不通过
+- **关键发现**：...
+- **建议**：...
+- **AI Native 视角**：...
+
+#### 产品负责人 视角
+...
+
+### 意见汇总
+
+| 角色 | 结论 | 关键发现 | 建议 | AI Native视角 |
+|------|------|----------|------|---------------|
+| CEO | ✅ | ... | ... | ... |
+| 产品负责人 | ⚠️ | ... | ... | ... |
+| ... | ... | ... | ... | ... |
+
+### 一致通过项
+- ...
+
+### 分歧项（需决策）
+| 分歧点 | 角色A意见 | 角色B意见 | 建议处理方式 |
+|--------|-----------|-----------|--------------|
+| ... | ... | ... | ... |
+
+### 必须修复
+- ...
+
+### 建议改进
+- ...
+
+### 综合结论
+- [ ] 通过 — 可进入下一阶段
+- [ ] 有条件通过 — 需修复必须项
+- [ ] 不通过 — 需重新设计/分析
+```
+
+## 执行步骤
+
+### Step 1: 读取配置文件
+
+**【强制】** 读取团队阶段配置和角色组合配置：
+
+```
+1. 读取 ${KNOWLEDGE}/config/team-stage.yaml
+   - 获取当前团队阶段配置（seed/growth/mature）
+   - 默认使用 growth 阶段
+
+2. 读取 ${KNOWLEDGE}/config/role-composition.yaml
+   - 获取当前阶段、当前复杂度对应的角色组合
+   - 获取 AI Native 关注点
+
+3. 读取 ${KNOWLEDGE}/config/team-tasks.yaml（如适用）
+   - 如果是特定任务（环境衔接、技术分析等），获取任务配置
+```
+
+### Step 2: 确定参与角色
+
+根据配置文件确定角色列表：
+
+```
+角色确定流程：
+1. 从 team-stage.yaml 获取团队阶段配置
+2. 从 role-composition.yaml 获取 {stage}.{complexity} 对应的角色组合
+3. 应用强制触发规则（mandatoryTriggers）
+4. 合并最终角色列表
+
+示例配置读取：
+# 团队阶段配置
+stages:
+  growth:
+    triggers:
+      medium: [ceo, product-owner, tech-lead, backend-engineer, ai-engineer]
+
+# 角色组合配置
+compositions:
+  requirement:
+    medium:
+      roles: [ceo, product-owner, tech-lead, ai-engineer]
+      aiNative: "AI工程师参与评估AI方案可行性"
+```
+
+### Step 3: 并行启动角色Agent
+
+使用 Agent 工具并行启动每个角色的审查Agent：
+
+```
+为每个角色并行启动 Agent：
+  Agent.run({
+    name: "{role}-reviewer",
+    prompt: `
+      请从{角色名称}视角审查以下文档。
+
+      角色画像：${KNOWLEDGE}/guides/roles/{role}.md
+      被审查文档：{文档路径}
+      当前阶段：{阶段}
+
+      AI Native 关注：{从配置获取}
+
+      审查要求：
+      1. 先读取角色画像，理解该角色的关注点
+      2. 从该角色视角审查文档
+      3. 输出：结论 + 关键发现 + 建议 + AI Native视角
+
+      注意：你是独立审查者，只看产出物和角色标准，不参考其他角色的意见
+    `
+  })
+```
+
+**关键原则**：
+- **做审分离**：每个角色Agent独立运行，不共享上下文
+- **信息隔离**：只传入被审查文档 + 角色画像 + 审查标准
+- **并行执行**：所有角色Agent同时启动，不串行等待
+- **AI Native**：每个角色都从AI思维视角审查
+
+### Step 4: 收集并汇总意见
+
+等待所有Agent完成后，收集并汇总意见：
+
+```
+意见汇总逻辑：
+1. 收集各角色审查结果
+2. 分类：通过 / 有建议 / 不通过
+3. 识别分歧点
+4. 提取 AI Native 相关建议
+```
+
+### Step 5: 处理分歧点
+
+当不同角色意见不一致时：
+
+1. **识别分歧**：找出结论相反或建议冲突的点
+2. **分析原因**：是视角不同还是理解偏差
+3. **提出处理建议**：
+   - 视角不同 → 提交用户决策
+   - 理解偏差 → 补充信息后重新审查
+
+### Step 6: 生成综合报告
+
+汇总所有角色的意见，生成结构化报告。
+
+### Step 7: 综合判定
+
+根据汇总结果做出判定：
+
+| 情况 | 判定 | 处理 |
+|------|------|------|
+| 全部通过 | 通过 | 进入下一阶段 |
+| 有建议但无必须修复 | 有条件通过 | 记录建议，进入下一阶段 |
+| 有必须修复 | 不通过 | 返回修正 |
+| 有分歧 | 待决策 | 标记NEEDS_CLARIFICATION，升级用户 |
+
+## AI Native 角色审查视角
+
+每个角色都有 AI Native 思维特质：
+
+### CEO 视角
+- 战略一致性：需求是否符合公司战略
+- 商业价值：投入产出比是否合理
+- 风险把控：是否存在重大风险
+- **AI Native**：战略决策考虑AI能力边界，识别AI带来的新机会
+
+### 产品负责人 视角
+- 用户价值：是否解决用户问题
+- 商业目标：是否支撑商业目标
+- 用户体验：是否影响用户体验
+- **AI Native**：AI产品思维，理解AI能力边界
+
+### 技术负责人 视角
+- 架构合理性：架构是否清晰合理
+- 过度设计：是否引入不必要复杂度
+- 技术选型：选型是否合理
+- **AI Native**：AI架构思维，评估AI方案可行性
+
+### AI工程师 视角
+- AI方案可行性：技术方案是否可实现
+- 模型选型：模型/技术选型是否合理
+- 效果评估：如何验证AI效果
+- **AI Native**：核心能力，模型选型、Prompt工程、效果优化
+
+### 数据工程师 视角
+- 数据架构：数据流是否合理
+- 数据质量：数据质量如何保障
+- 数据安全：数据是否安全
+- **AI Native**：数据驱动基石，数据质量、管道、特征工程
+
+### 工程师 视角
+- 可实现性：设计是否可实现
+- 工程质量：代码质量、测试覆盖
+- 性能安全：是否有隐患
+- **AI Native**：AI集成思维，API设计考虑AI调用
+
+### 安全工程师 视角
+- 安全漏洞：是否有安全风险
+- 合规性：是否符合合规要求
+- 数据安全：敏感数据处理是否安全
+- **AI Native**：AI安全思维，Prompt注入防护、数据隐私
+
+### 运维工程师 视角
+- 部署可行性：部署方案是否可行
+- 监控告警：监控是否完善
+- 成本控制：资源成本是否合理
+- **AI Native**：AI运维思维，模型部署、GPU资源管理
+
+## 效率优化策略
+
+### 1. 并行执行
+所有角色Agent并行运行，不串行等待：
+```
+启动时间：T0
+角色A审查：T0 → T1
+角色B审查：T0 → T2
+角色C审查：T0 → T3
+总耗时：max(T1, T2, T3)
+```
+
+### 2. 增量审查
+对于修改后的文档，只审查变更部分：
+```
+如果文档有版本标记：
+  只启动相关角色审查变更部分
+  其他角色的历史意见保留
+```
+
+### 3. 结果缓存
+相似问题的审查结果可复用：
+```
+如果文档内容相似度 > 80%：
+  复用上次审查结果
+  只重新审查差异部分
+```
+
+## 反模式清单
+
+1. **串行执行**：一个一个启动Agent。检测：必须并行启动
+2. **信息泄露**：角色Agent看到其他角色的意见。检测：每个Agent只传入文档和角色画像
+3. **忽略分歧**：不一致意见直接忽略。检测：分歧必须记录并处理
+4. **过度审查**：简单任务也启动全部角色。检测：按配置文件确定角色列表
+5. **忽略AI Native视角**：每个角色都应该有AI思维视角
+
+## 与现有流程的集成
+
+### 需求阶段
+```
+需求分析完成
+    ↓
+complexity-assessor 评估复杂度
+    ↓
+team-orchestrator 协调团队审查（读取配置）
+    ↓
+生成团队对抗审查报告
+    ↓
+处理结果：通过 → 进入设计阶段 | 不通过 → 返回修正
+```
+
+### 设计阶段
+```
+方案设计完成
+    ↓
+继承或重新评估复杂度
+    ↓
+team-orchestrator 协调团队审查（读取配置）
+    ↓
+生成团队对抗审查报告
+    ↓
+处理结果：通过 → 进入编码阶段 | 不通过 → 返回修正
+```
+
+### 与 Layer 2 的关系
+- 团队对抗审查在 Layer 2 之前执行
+- 团队对抗审查不通过 → 不进入 Layer 2
+- 团队对抗审查通过 → 执行 Layer 2 独立审查（做审分离）
+
+## 团队任务支持
+
+除了阶段审查，team-orchestrator 还支持以下团队任务（从 team-tasks.yaml 读取配置）：
+
+| 任务 | 团队组合 | 说明 |
+|------|---------|------|
+| 环境衔接 | tech-lead + devops + backend | 项目环境扫描、技术栈识别 |
+| 技术分析 | tech-lead + backend + frontend + ai | 技术栈深入分析 |
+| AI评测 | ai-engineer + quality + data | AI效果评测、Badcase分析 |
+| 安全审计 | security + tech-lead + backend | 安全漏洞扫描、合规检查 |
+| 一致性检查 | tech-lead + quality | 跨产物一致性检查 |

package/knowledge/guides/support/tech-stack-analyzer.md

@@ -0,0 +1,139 @@
+# 技术栈分析器
+
+## 功能
+
+分析项目技术栈，识别框架、语言、工具链。对于配置规则中未定义的依赖，使用 AI 进行智能推测。
+
+## 触发条件
+
+- 检测器发现未识别的依赖
+- 需要更精确的技术栈分析
+- 项目结构复杂，需要 AI 辅助判断
+
+## 输入
+
+```json
+{
+  "projectDir": "项目根目录",
+  "buildFiles": [
+    {
+      "path": "package.json",
+      "content": "文件内容"
+    }
+  ],
+  "unknownDeps": ["未识别的依赖列表"],
+  "directoryStructure": "目录结构概览"
+}
+```
+
+## 输出
+
+```json
+{
+  "identifiedStacks": [
+    {
+      "framework": "框架名称",
+      "type": "frontend/backend/ai/data",
+      "confidence": "high/medium/low",
+      "reasoning": "判断依据"
+    }
+  ],
+  "suggestions": [
+    {
+      "dependency": "依赖名",
+      "possibleFramework": "可能的框架",
+      "type": "类型",
+      "confidence": "置信度"
+    }
+  ]
+}
+```
+
+## 执行步骤
+
+1. **分析构建文件**
+   - 读取 package.json、pom.xml、requirements.txt 等
+   - 提取依赖列表和版本信息
+
+2. **识别已知框架**
+   - 匹配配置规则中定义的框架
+   - 记录高置信度识别结果
+
+3. **分析未知依赖**
+   - 对于未在规则中的依赖，使用 AI 推测：
+     - 依赖名称语义分析
+     - 常见命名模式识别
+     - 版本号格式分析
+
+4. **推断项目类型**
+   - 结合目录结构判断项目类型
+   - monorepo: 有 packages/、apps/ 目录
+   - microservices: 多个独立服务模块
+   - single-app: 单一入口项目
+
+5. **生成分析报告**
+   - 汇总所有识别结果
+   - 提供置信度评估
+   - 建议是否需要添加新规则
+
+## 规则
+
+1. **优先使用确定性规则**
+   - 配置文件中定义的规则优先级最高
+   - AI 推测仅作为补充
+
+2. **置信度评估**
+   - high: 配置规则匹配
+   - medium: AI 基于语义推测
+   - low: AI 基于模式推测
+
+3. **避免过度推测**
+   - 不确定时不强行判断
+   - 建议人工确认
+
+## 示例
+
+### 输入
+
+```json
+{
+  "unknownDeps": ["@astrojs/vue", "astro"],
+  "directoryStructure": "src/pages/, src/components/, astro.config.mjs"
+}
+```
+
+### 输出
+
+```json
+{
+  "identifiedStacks": [
+    {
+      "framework": "Astro",
+      "type": "frontend",
+      "confidence": "high",
+      "reasoning": "检测到 astro 依赖和 astro.config.mjs 配置文件"
+    }
+  ],
+  "suggestions": [
+    {
+      "dependency": "@astrojs/vue",
+      "possibleFramework": "Astro Vue Integration",
+      "type": "frontend",
+      "confidence": "high"
+    }
+  ]
+}
+```
+
+## 配置更新建议
+
+当发现新的框架或工具时，建议将其添加到配置文件：
+
+```yaml
+# 添加到 knowledge/environment/detection-patterns.yaml
+frameworks:
+  javascript:
+    - deps: [astro]
+      framework: Astro
+      type: frontend
+```