@chongyan/autospec 1.0.1

package/plugins/skills/requirement-stage/SKILL.md

@@ -0,0 +1,183 @@
+---
+name: requirement-stage
+description: "When requirement analysis, user story writing, feature scoping, or PRD creation is needed — loads AutoSpec requirement analysis process and skill."
+---
+
+# AutoSpec 需求分析（Stage 01）
+
+你正在执行需求分析阶段。此阶段将原始需求转化为结构化需求文档。
+
+## 前置检查
+
+1. 确认启动门禁已通过（`.autospec/runtime/state.json` 存在）
+2. 读取 `${KNOWLEDGE}/principles/constitution.md` → 确认红线
+3. 加载创业团队角色画像：读取 `${KNOWLEDGE}/guides/stages/` 目录下的角色文件
+4. 加载方法论原则：读取 `${KNOWLEDGE}/principles/core-principles.md` → 注入 P1(问题定义先行)、P2(价值驱动)、P31(目标设定三原则) 等通用原则意识
+5. 加载设计哲学：读取 `${KNOWLEDGE}/principles/design-philosophy.md` → 注入 DP17(结构化澄清) 和 DP16(模板即约束) 原则
+6. 加载认知增强原则：读取 `${KNOWLEDGE}/principles/core-principles.md` → 本阶段重点应用 CP1(合伙人模式)、CP3(先问后做)、CP5(置信度标注)
+
+## 认知姿态（本阶段：发散 + 挑战）
+
+- **CP1 合伙人模式**：你有权挑战用户的需求假设。如果发现需求可能是伪需求或方向有误，必须指出
+- **CP3 先问后做**：需求天然存在不确定性。识别歧义后，先列出选项和推荐，再继续分析
+- **CP5 置信度**：对不确定的需求推断，标注"高/中/低置信度"，低置信度的标记为 NEEDS CLARIFICATION
+
+## 执行
+
+### Step 1: 复杂度评估与团队组建
+
+在进入具体需求分析前，先评估任务复杂度，确定参与角色：
+
+**【强制】** 读取 `${KNOWLEDGE}/guides/support/complexity-assessor.md`，执行复杂度评估：
+- 评估维度：需求复杂度、技术复杂度、数据敏感度、业务复杂度
+- 输出：复杂度分数、级别（simple/medium/complex）、需要的角色列表
+
+**【强制】** 读取 `${KNOWLEDGE}/config/team-triggers.yaml`，检查强制触发规则：
+- 涉及用户数据 → 强制引入 security-engineer
+- 涉及支付/金融 → 强制引入 security-engineer
+- 跨系统变更 → 强制引入 tech-lead + devops-engineer
+
+### Step 2: 创业团队对抗探索
+
+根据复杂度评估结果，启动团队对抗审查：
+
+#### 简单任务（score <= 5）
+快速通道，仅核心角色参与：
+- CEO：战略对齐、商业价值确认
+- 产品负责人：用户价值、MVP范围
+
+#### 中等任务（score 6-8）
+引入技术视角：
+- CEO + 产品负责人 + 技术负责人
+
+#### 复杂任务（score >= 9）
+引入完整团队：
+- CEO + 产品负责人 + 技术负责人 + 相关工程师
+- 如触发强制规则，额外引入安全工程师/运维工程师
+
+**对抗审查执行方式**：
+
+**自主模式 — 多Agent并行对抗**：
+```
+**【强制】** 读取 `${KNOWLEDGE}/guides/support/team-orchestrator.md`
+并行启动角色Agent（信息隔离，做审分离）：
+  - CEO Agent：战略一致性、商业价值、风险把控
+  - 产品负责人 Agent：用户价值、产品方向、MVP范围
+  - 技术负责人 Agent：技术可行性、技术风险（如需要）
+  - 相关工程师 Agent：实现可行性（如需要）
+汇总意见，生成团队对抗审查报告
+```
+
+**交互模式 — 与用户互动完成**：
+将团队各角色的关注点作为提问框架，与用户交互：
+1. **CEO视角**：商业价值、战略对齐、成功指标
+2. **产品视角**：用户痛点、MVP范围、验收标准
+3. **技术视角**（如需要）：技术可行性、技术风险
+4. **安全视角**（如触发）：数据安全、合规要求
+
+### Step 3: 需求澄清（DP17 结构化澄清 + 双模式适配）
+
+在需求分析过程中发现的所有歧义，**收集后批量处理**，不逐个打断：
+
+1. 执行 11 维扫描（功能范围/数据模型/UX流程/非功能需求/集成接口/边界案例/约束条件/术语定义/优先级/风险项/验收标准）
+2. 按 Impact × Uncertainty 排序，取 Top 5
+3. 对每个歧义项分类：
+
+**AUTO-FIX**（直接修复）：术语不一致、格式缺失、引用错误 → 自动修正
+**AUTO-DECIDE**（自动决策）：
+  - 交互模式 → 加入批处理问题列表
+  - 自动模式 → 使用推荐值，记录到 `pendingConfirmations`，标注置信度
+**REQUIRE-REVIEW**（需人工审阅）：
+  - 交互模式 → 加入批处理问题列表，标记为 CRITICAL
+  - 自动模式 → 使用最保守选项，标记 `HIGH_PRIORITY_REVIEW`
+
+4. **交互模式：批处理提问**
+   收集所有 AUTO-DECIDE + REQUIRE-REVIEW 项，**一次性提问**（AskUserQuestion）：
+   - 每个问题附带 AI 推荐答案 + 推理过程
+   - 用户可接受推荐或给出不同答案
+   - 支持提前终止（"其余全用推荐值"）
+
+5. **自动模式：自动决策**
+   - 所有项使用推荐值
+   - 生成决策记录到 `.autospec/runtime/state.json` 的 `autoDecisions` 数组
+   - 输出摘要：已自动决策 N 项 + 待审阅 N 项
+
+### Step 4: 需求文档生成
+
+1. **【强制】** 加载做类skill：读取 `${KNOWLEDGE}/guides/stages/requirement-analyzer.md` → **按步骤执行**
+2. 加载检查清单：读取 `${KNOWLEDGE}/checklists/requirement.md` → 逐项核对
+3. 加载元学习方法：读取 `${KNOWLEDGE}/principles/core-principles.md` → 应用"三层知识漏斗"（原料→认知→执行）确保需求从模糊想法转化为可执行结构
+4. 将团队对抗结论融入需求文档（战略背景、商业价值、成功指标）
+5. 将澄清结果融入需求文档（每个决策标注来源：用户确认/自动决策/待审阅）
+6. **【强制】** 补充边界条件分析：
+   - 对每个功能需求，识别边界条件（空值、极值、并发、异常输入等）
+   - 在验收标准中明确定义边界条件测试标准
+   - 记录边界条件到需求文档的「边界条件」章节
+7. 产出结构化需求文档，写入 `.autospec/specs/{feature}/requirement.md`
+
+## 验证
+
+### Layer 1: 确定性验证
+- Schema校验：需求文档包含所有必须字段（背景、功能需求、验收标准、假设清单、边界条件）
+- 格式检查：每条需求有优先级(P0/P1/P2)和验收标准
+- **边界条件检查**：验收标准必须包含边界条件测试标准（空值、极值、并发、异常输入等）
+
+### Layer 2: AI审查（做审分离）
+使用 **independent-reviewer** Agent 执行独立审查：
+```
+**【强制】** 调用 Agent 工具：
+  prompt: 请审查以下需求文档。
+    1. 先读取审查标准: ${KNOWLEDGE}/guides/stages/requirement-reviewer.md
+    2. 被审查文档: .autospec/specs/{feature}/requirement.md
+    3. 原始需求（用于对照）
+    注意：你是独立审查者，只看产出物和标准，不参考生产过程
+```
+
+### Layer 3: Benchmarks 评测（新增）
+
+**【强制】** 执行 requirement benchmarks 评测：
+```
+1. 检测 requirement.md 是否生成
+2. 调用 benchmark-executor 执行评测：
+   - REQ-001: 需求文档完整性（字段完整率 >= 90%）
+   - REQ-002: 非功能需求覆盖（性能/安全/扩展性）
+   - REQ-003: 多系统需求一致性（跨系统接口定义）
+3. 生成评测报告到 .autospec/benchmarks/results/requirement-{run-id}.json
+4. 如评测未通过：
+   - 生成改进建议
+   - 返回 Step 2 完善需求
+   - 最多重试 3 次
+5. 如评测通过：
+   - 记录评测结果
+   - 允许进入 design stage
+```
+
+**评测触发方式**：
+- 自动触发：requirement.md 生成后自动执行
+- 手动触发：`/benchmark --run --stage=requirement`
+- 变更触发：requirement.md 修改后自动重新评测
+
+## 阶段门禁（所有自主级别）
+
+使用 **stage-gate-evaluator** Agent 评估产出物是否达到准出标准：
+```
+**【强制】** 调用 Agent 工具：
+  prompt: 请评估需求分析阶段的产出物是否达到准出标准。
+    当前阶段：Stage 01 需求分析
+    产出物：.autospec/specs/{feature}/requirement.md
+    准出标准：${KNOWLEDGE}/checklists/requirement.md
+    上游契约：原始需求
+    自主级别：{自主/交互}
+```
+
+**根据自主级别处理评估结果**：
+- **交互模式**：评估结果提交人工确认，AI 等待用户批准后继续
+- **自主模式**：评估通过后自动进入下一阶段，评估不通过进入精准回退
+
+## 完成
+
+- 两层验证通过 + 阶段门禁评估通过 → 输出精炼契约 → 更新 `.autospec/runtime/state.json` → 进入方案设计
+- 不通过 → 精准回退：
+  - Level 1: 内联重试（单次）
+  - Level 2: 修正循环（最多3次，只重处理失败项）
+  - Level 3: 3次后使用 **failure-diagnostician** Agent 执行根因分析，再升级用户

package/plugins/skills/skill-forge/SKILL.md

@@ -0,0 +1,223 @@
+---
+name: skill-forge
+description: "When creating a new skill from practice patterns, evolving an existing skill based on feedback, or optimizing skill description for better trigger accuracy — initiates the skill forging pipeline."
+---
+
+# AutoSpec 技能锻造系统
+
+端到端的技能锻造系统，统一处理技能的新建、迭代和优化，是框架自进化能力的核心引擎。
+
+## 跳过条件
+
+如果用户明确表示不需要走锻造流程，尊重用户选择。
+
+## 三场景触发
+
+### 场景A：蒸馏新建
+
+**触发信号**：
+- practice-log 中某模式出现 **3 次以上**
+- 信号强度 = 证据数量 × 问题影响度
+
+**输入**：
+- practice-log 中状态为"待处理"的条目
+- 流程执行轨迹、人工介入记录
+
+**输出**：
+- 新的 skill 文件（符合模板标准）
+- 锻造报告（含证据清单）
+
+### 场景B：迭代进化
+
+**触发信号**：
+- 同类问题出现 **3 次以上**
+- 审类 skill 打回记录 ≥ 3 条
+- description 触发准确率 < 70%
+
+**输入**：
+- 待升级的 skill 文件
+- 反馈数据（审类打回记录 / practice-log / 人工反馈）
+
+**输出**：
+- 升级后的 skill 文件
+- 变更说明 + 证据清单
+- A/B 对比报告（如适用）
+
+### 场景C：Description 优化
+
+**触发信号**：
+- description 触发准确率 < 70%
+- 误触发或漏触发案例 ≥ 3 个
+
+**输入**：
+- skill 文件
+- 触发准确率数据
+- 误触发/漏触发案例
+
+**输出**：
+- 优化后的 description
+- A/B 测试报告
+
+---
+
+## 锻造流水线
+
+### Phase 1: 信号诊断
+
+1. **信号分类**：
+   - 新建信号：模式出现 3 次以上 → 触发蒸馏
+   - 迭代信号：同类问题出现 3 次以上 → 触发进化
+   - 优化信号：description 触发准确率 < 70% → 触发优化
+
+2. **证据收集**：
+   - 收集至少 **3 条**支撑证据
+   - 标注证据类型（practice-log / 审查记录 / 人工反馈）
+   - 计算信号强度
+
+3. **分区判定**：
+   - 判断目标 skill 属于哪个进化分区（冻结区/受控区/自由区）
+   - 冻结区：停止，仅记录建议
+   - 受控区/自由区：继续
+
+### Phase 2: 草稿锻造
+
+**场景A：蒸馏新建**
+
+执行三场景蒸馏：
+1. **流程蒸馏（向内看）**：从执行轨迹识别可复用模式
+2. **业务蒸馏（向外看）**：从业务知识提取领域技能
+3. **测试知识蒸馏**：从测试执行中学习
+
+输出符合模板的 skill 草稿，重点：
+- CSO description（只写触发条件）
+- 反模式清单（≥ 5 条）
+
+**场景B：迭代进化**
+
+1. 收集该 skill 相关的所有反馈数据
+2. 分析问题模式：步骤不够具体？评判标准不准确？反模式不全面？
+3. 生成修改建议（明确改哪个 section、怎么改、预期效果）
+4. 保持向后兼容
+
+**场景C：Description 优化**
+
+1. 分析误触发案例（不该触发但触发了）
+2. 分析漏触发案例（该触发但没触发）
+3. 生成优化后的 description 候选版本
+4. 验证 CSO 格式（只含触发条件）
+
+### Phase 3: 双层验证
+
+**Layer 1: 确定性验证（skill-validator）**
+
+```
+检查项：
+- [ ] frontmatter 完整（name, description, type）
+- [ ] CSO description 符合格式
+- [ ] 输入/输出定义清晰
+- [ ] 执行步骤可操作
+- [ ] 反模式清单 >= 5 条
+- [ ] 包含完整示例
+```
+
+Layer 1 不过，不进 Layer 2。
+
+**Layer 2: AI 独立审查**
+
+使用 **skill-benchmarker** Agent 执行基准评测：
+- 用 skill 处理基准案例
+- 计算：完成率、首次通过率、平均回退次数
+- 输出结构化评测报告
+
+### Phase 4: 竞技场对比（仅迭代/优化场景）
+
+1. **盲评设置**：
+   - 旧版本 = Version A
+   - 新版本 = Version B
+   - 评测者不知道哪个是新版
+
+2. **多维度对比**：
+   | 维度 | 权重 | 评分方式 |
+   |------|------|----------|
+   | 输出质量 | 40% | AI 独立评分 |
+   | 执行效率 | 20% | 步骤数/时间 |
+   | 错误率 | 30% | 反模式触发次数 |
+   | 边界处理 | 10% | 边界案例通过率 |
+
+3. **胜者判定**：
+   - 综合得分高者胜出
+   - **平局时保留旧版本**（稳定性优先）
+   - 分差 < 5% 时建议人工评审
+
+### Phase 5: 发布审批
+
+**自由区 skills**（skills/domain/）：
+- Layer 1+2 通过 → 自动发布
+- 记录到 evolution-log.json
+
+**受控区 skills**（skills/stages/）：
+- 生成变更提案
+- 提交人工审批
+- 审批通过后发布
+
+**冻结区**：
+- 不自动执行
+- 仅记录建议
+
+---
+
+## 反模式清单
+
+1. **证据不足锻造**：支撑证据 < 3 条就锻造。检测：必须有 3+ 实例支撑
+2. **跳过基准验证**：不跑基准案例就发布。检测：基准验证是必选步骤
+3. **盲目替换**：不对比新旧版本直接替换。检测：迭代场景必须走竞技场对比
+4. **Description 泄漏**：description 包含工作流内容。检测：CSO 格式检查
+5. **反模式缺失**：新 skill 没有反模式清单。检测：反模式清单是必填项
+6. **过度泛化**：基于单一项目特有模式泛化。检测：判断复用层级
+
+---
+
+## 适用场景与边界
+
+- 适用：新建 skill、迭代 skill、优化 description
+- 不适用：方法论提取（用 methodology-extractor）、非 skill 类型文件
+
+---
+
+## 示例
+
+### 新建示例
+
+```
+触发：practice-log 记录了 5 次"需求冲突检测"模式
+锻造：蒸馏为 skills/stages/req-conflict-detector.md
+验证：通过基准案例测试
+发布：受控区变更提案，人工审批后合入
+```
+
+### 迭代示例
+
+```
+触发：code-reviewer 连续 3 次漏判 SQL 注入
+锻造：补充安全检查步骤
+竞技场：新版 vs 旧版盲评，新版胜出
+发布：受控区变更提案，人工审批后合入
+```
+
+### Description 优化示例
+
+```
+触发：某 skill 触发准确率仅 55%
+分析：误触发案例 5 个，漏触发案例 3 个
+优化：重写 description，聚焦用户意图
+验证：触发准确率提升至 85%
+发布：自动发布，记录到 evolution-log
+```
+
+---
+
+## 参考文档
+
+- `references/skill-template.md` — skill 标准模板
+- `references/description-guide.md` — CSO description 编写指南
+- `references/quality-rubric.md` — skill 质量评分标准

package/plugins/skills/skill-forge/references/description-guide.md

@@ -0,0 +1,92 @@
+# CSO Description 编写指南
+
+## 什么是 CSO？
+
+**C**ondition（条件）+ **S**ignal（信号）+ **O**nly（仅此）
+
+CSO 是 AutoSpec skill description 的编写原则，确保 description 只包含触发条件，不包含工作流摘要。
+
+## 为什么需要 CSO？
+
+1. **避免膨胀**：description 是注入到每次对话的，过长会浪费 token
+2. **精准触发**：只写触发条件，让 Claude 更容易判断是否应该使用这个 skill
+3. **避免混淆**：不写工作流摘要，防止 Claude 误以为 description 就是完整指令
+
+## CSO 格式
+
+```
+When [触发条件] — triggers [skill 名称/功能]
+```
+
+## 示例对比
+
+### ❌ 错误示例（包含工作流摘要）
+
+```
+这个 skill 帮助你分析用户需求，生成需求文档。它会执行11维扫描，
+包括功能完整性、边界条件、性能需求等，然后生成结构化的需求文档...
+```
+
+问题：
+- 包含工作流摘要
+- 过长（浪费 token）
+- 触发条件不明确
+
+### ✅ 正确示例（CSO 格式）
+
+```
+When analyzing user requirements to generate requirement specs — triggers requirement analysis pipeline.
+```
+
+优点：
+- 触发条件明确
+- 简洁（节省 token）
+- 不包含工作流内容
+
+## 编写技巧
+
+### 1. 从用户意图出发
+
+```
+❌ When the user wants to use the requirement-analyzer skill
+✅ When analyzing user requirements to generate requirement specs
+```
+
+### 2. 使用 When... — triggers... 句式
+
+```
+When [用户在做什么] — triggers [skill 提供什么能力]
+```
+
+### 3. 避免包含实现细节
+
+```
+❌ When the user needs to run 11-dimension scan on requirements
+✅ When analyzing user requirements for completeness and consistency
+```
+
+### 4. 长度控制在 200 字符以内
+
+```
+❌ When the user is working on a complex project that involves multiple subsystems including backend, frontend, and AI components, and needs to coordinate the development process across these subsystems — triggers multi-system development pipeline
+✅ When developing features spanning multiple subsystems (backend/frontend/AI) — triggers multi-system coordination pipeline
+```
+
+## 触发准确率优化
+
+如果 description 触发准确率 < 70%：
+
+1. **误触发**（不该触发但触发了）：
+   - 检查 description 是否过于宽泛
+   - 添加排除条件
+
+2. **漏触发**（该触发但没触发）：
+   - 检查 description 是否过于具体
+   - 添加更多触发场景
+
+## 反模式
+
+1. **工作流泄漏**：description 包含执行步骤
+2. **过度推销**：使用"强大的"、"完美的"等修饰词
+3. **模糊触发**：使用"当需要时"、"如果用户想要"等模糊表达
+4. **技术术语滥用**：使用只有开发者理解的术语

package/plugins/skills/skill-forge/references/quality-rubric.md

@@ -0,0 +1,104 @@
+# Skill 质量评分标准
+
+本文档定义 skill 质量的评分维度和标准，用于基准评测和版本对比。
+
+## 评分维度
+
+| 维度 | 权重 | 说明 |
+|------|------|------|
+| 输出质量 | 40% | 产出物的完整性和准确性 |
+| 执行效率 | 20% | 步骤精简度、时间效率 |
+| 错误率 | 30% | 反模式触发次数、回退次数 |
+| 边界处理 | 10% | 边界案例处理能力 |
+
+## 详细评分标准
+
+### 输出质量（40%）
+
+| 分数 | 标准 |
+|------|------|
+| 5 分 | 产出物完整、准确、可直接使用 |
+| 4 分 | 产出物完整，有轻微瑕疵但可接受 |
+| 3 分 | 产出物基本完整，需要少量修改 |
+| 2 分 | 产出物不完整，需要大量修改 |
+| 1 分 | 产出物严重缺失或错误 |
+
+### 执行效率（20%）
+
+| 分数 | 标准 |
+|------|------|
+| 5 分 | 步骤精简，无冗余操作 |
+| 4 分 | 步骤合理，有少量冗余 |
+| 3 分 | 步骤较多，但能完成任务 |
+| 2 分 | 步骤繁琐，效率低下 |
+| 1 分 | 步骤混乱，无法完成任务 |
+
+### 错误率（30%）
+
+| 分数 | 标准 |
+|------|------|
+| 5 分 | 无反模式触发，无回退 |
+| 4 分 | 反模式触发 1 次，回退 1 次 |
+| 3 分 | 反模式触发 2 次，回退 2 次 |
+| 2 分 | 反模式触发 3 次，回退 3 次 |
+| 1 分 | 反模式触发 > 3 次，回退 > 3 次 |
+
+### 边界处理（10%）
+
+| 分数 | 标准 |
+|------|------|
+| 5 分 | 所有边界案例正确处理 |
+| 4 分 | 大部分边界案例正确处理 |
+| 3 分 | 基本边界案例正确处理 |
+| 2 分 | 边界案例处理有问题 |
+| 1 分 | 边界案例完全无法处理 |
+
+## 综合得分计算
+
+```
+综合得分 = 输出质量 × 0.4 + 执行效率 × 0.2 + 错误率 × 0.3 + 边界处理 × 0.1
+```
+
+## 胜者判定规则
+
+1. **综合得分高者胜出**
+2. **平局时保留旧版本**（稳定性优先）
+3. **分差 < 5% 时建议人工评审**
+
+## 基准案例选择
+
+基准案例应覆盖：
+
+1. **典型场景**：skill 最常见的使用场景
+2. **边界场景**：极端输入、异常情况
+3. **竞争场景**：与其他 skill 可能混淆的场景
+
+每个 skill 至少需要 **3 个基准案例**。
+
+## 评测报告格式
+
+```markdown
+## 基准评测报告
+
+### 基本信息
+- 评测时间：{ISO 8601}
+- skill 名称：{name}
+- 基准案例数：{N}
+
+### 逐维度得分
+| 维度 | 得分 | 说明 |
+|------|------|------|
+| 输出质量 | X/5 | ... |
+| 执行效率 | X/5 | ... |
+| 错误率 | X/5 | ... |
+| 边界处理 | X/5 | ... |
+
+### 综合得分
+**{综合得分}/5**
+
+### 问题清单
+- ...
+
+### 建议改进
+- ...
+```

package/plugins/skills/skill-forge/references/skill-template.md

@@ -0,0 +1,106 @@
+# Skill 标准模板
+
+本文档定义 AutoSpec skill 的标准结构，融合 AutoSpec 和 Anthropic skill-creator 的最佳实践。
+
+## 文件结构
+
+```
+skill-name/
+├── SKILL.md (必须)
+│   ├── YAML frontmatter
+│   └── Markdown 内容
+└── references/ (可选)
+    └── 补充文档
+```
+
+## SKILL.md 模板
+
+```markdown
+---
+name: skill-name
+description: "CSO 格式的触发条件描述，只写何时触发，不写工作流摘要"
+type: produce | review
+---
+
+# Skill 标题
+
+## 定位
+
+一句话说明这个 skill 是什么，解决什么问题。
+
+## 跳过条件（可选）
+
+什么情况下不触发这个 skill。
+
+## 输入
+
+- 必须输入：...
+- 可选输入：...
+
+## 输出
+
+- 产出物：...
+- 证据清单：...
+
+## 执行步骤 / 评审步骤
+
+1. **步骤一**：...
+   - 预期产出：...
+   - 失败处理：...
+2. **步骤二**：...
+
+## 反模式清单
+
+1. **反模式名称**：描述。检测：如何发现
+2. ...
+
+## 适用场景与边界
+
+- 适用：...
+- 不适用：...
+
+## 示例
+
+**触发**：...
+**执行**：...
+**输出**：...
+```
+
+## Frontmatter 规范
+
+| 字段 | 必须 | 说明 |
+|------|------|------|
+| name | 是 | skill 标识符，小写-连字符格式 |
+| description | 是 | CSO 格式触发条件，≤ 200 字符 |
+| type | 是 | `produce`（做类）或 `review`（审类） |
+
+## CSO Description 原则
+
+**C**ondition（条件）+ **S**ignal（信号）+ **O**nly（仅此）
+
+```
+❌ 错误：这个 skill 帮助你分析需求，生成需求文档，包含11维扫描...
+✅ 正确：When analyzing user requirements to generate requirement specs — triggers requirement analysis pipeline.
+```
+
+## 反模式清单要求
+
+- 最少 5 条
+- 包含：反模式名称 + 描述 + 检测方法
+- 区分：通用反模式 + skill 特有反模式
+
+## 渐进式加载
+
+1. **Metadata 层**：name + description（~100 字符）
+2. **SKILL.md 层**：完整内容（< 500 行）
+3. **References 层**：补充文档（按需加载）
+
+## 质量检查清单
+
+- [ ] frontmatter 完整
+- [ ] description 符合 CSO 格式
+- [ ] 输入/输出定义清晰
+- [ ] 步骤可操作
+- [ ] 反模式清单 >= 5 条
+- [ ] 包含完整示例
+- [ ] 与现有 skills 无重叠冲突