{"id":"9cbb9eeb-11f1-4f63-ac0e-22bb015bd99a","entityType":"agent","slug":"clawhub-qomob-skillcompiler","name":"Skill Compiler","canonicalUrl":"https://www.xpersona.co/agent/clawhub-qomob-skillcompiler","canonicalPath":"/agent/clawhub-qomob-skillcompiler","generatedAt":"2026-10-14T17:01:18.233Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-11T23:50:08.587Z","emptyReason":null},"description":"Use when you need to compile any prompt OR multi-source content (PDF/video/URL/image/doc) into a production-grade, reusable AI Skill. Triggers on: 'prompt to... Skill: Skill Compiler Owner: qomob Summary: Use when you need to compile any prompt OR multi-source content (PDF/video/URL/image/doc) into a production-grade, reusable AI Skill. Triggers on: 'prompt to... Tags: latest:1.2.2 Version history: v1.2.2 | 2026-07-12T08:14:32.951Z | auto - Removed redundant documentation file: skill-card.md. - No changes to functionality, logic, or features. - Internal documentation houseke","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 973 downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s1712hx0t1qgg41g18p2bb0d6583ms02:skillcompiler","sourceUrl":"https://clawhub.ai/qomob/skillcompiler","homepage":"https://clawhub.ai/qomob/skills/skillcompiler","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/qomob/skillcompiler","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/qomob/skills/skillcompiler","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":60,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Use when you need to compile any prompt OR multi-source content (PDF/video/URL/image/doc) into a production-grade, reusable AI Skill. Triggers on: 'prompt to..."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T23:50:08.587Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T23:50:08.587Z","emptyReason":null},"stars":null,"forks":null,"downloads":973,"likes":null,"task":null,"library":null,"packageName":null,"latestVersion":"1.2.2","tractionLabel":"973 downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T23:50:08.487Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T23:50:08.587Z","lastCrawledAt":"2026-10-11T23:50:08.487Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T23:50:08.487Z","lastVerifiedAt":null,"highlights":[{"version":"1.2.2","createdAt":"2026-07-12T08:14:32.951Z","changelog":"- Removed redundant documentation file: skill-card.md. - No changes to functionality, logic, or features. - Internal documentation housekeeping only.","fileCount":23,"zipByteSize":68428},{"version":"1.2.1","createdAt":"2026-07-10T04:32:24.397Z","changelog":"Version 1.2.1 - Added support for multi-source ingestion from PDF, video, URL, image, and document inputs, not just prompts - Introduced Pass I: Ingestion for standardizing and sourcing non-text inputs - Integrated evidence grading and provenance; Pass 2 now tags knowledge with evidence levels (primary/secondary/inferred) - Enforced \"honest boundaries\"—all skills must declare limitations and scope - Embedded meta-reflection (8-dimension self-audit) as a requirement at key pipeline stages - Updated and extended references and profiles; removed legacy/duplicated documentation and schema files","fileCount":23,"zipByteSize":68267},{"version":"1.2.0","createdAt":"2026-06-29T00:24:18.602Z","changelog":"Skillcompiler v0.1.1 Changelog - Major refactor: Introduced target platform selection (`generic`, `trae`, `claude`) and platform-specific output rules. - Added support for multiple compilation modes (`quick`, `full`, `audit`) and token budget management. - Expanded and clarified Pass 0 Triage, now includes target platform and compilation mode selection. - Enhanced validation (Pass 6) with multi-layer evaluation and platform compliance checks. - Added extensive documentation and references, including IR and trace schemas, platform profiles, and anti-patterns. - Removed obsolete file: skill-card.md.","fileCount":23,"zipByteSize":55271},{"version":"0.1.0","createdAt":"2026-06-26T02:15:02.504Z","changelog":"Initial release of Skill Compiler, a tool for converting prompts into modular, production-grade AI Skills. - Introduces a compiler pipeline with 6 core passes and 3 conditional passes, driven by an intermediate representation (IR) model. - Defines strict optimization goals and principles, focusing on reusability, modularity, maintainability, and evolvability. - Includes clear triage and validation processes to ensure only suitable prompts are compiled. - Outputs a detailed compilation report with skill summary, folder structure, pass execution logs, module dependency graph, validation results, and future roadmap. - Provides robust architecture guidelines, references, and templates for building high-quality skill packages from any prompt.","fileCount":13,"zipByteSize":23231}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s1712hx0t1qgg41g18p2bb0d6583ms02:skillcompiler","setupComplexity":"low","setupSteps":["Setup complexity is LOW. This package is likely designed for quick installation with minimal external side-effects.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-qomob-skillcompiler/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-qomob-skillcompiler/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-qomob-skillcompiler/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-qomob-skillcompiler/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-qomob-skillcompiler/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-qomob-skillcompiler/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-14T17:01:18.231Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-qomob-skillcompiler/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-qomob-skillcompiler/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-qomob-skillcompiler/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-qomob-skillcompiler/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-11T23:50:08.587Z","emptyReason":null},"readme":"Skill: Skill Compiler\n\nOwner: qomob\n\nSummary: Use when you need to compile any prompt OR multi-source content (PDF/video/URL/image/doc) into a production-grade, reusable AI Skill. Triggers on: 'prompt to...\n\nTags: latest:1.2.2\n\nVersion history:\n\nv1.2.2 | 2026-07-12T08:14:32.951Z | auto\n\n- Removed redundant documentation file: skill-card.md.\n- No changes to functionality, logic, or features.\n- Internal documentation housekeeping only.\n\nv1.2.1 | 2026-07-10T04:32:24.397Z | auto\n\nVersion 1.2.1\n\n- Added support for multi-source ingestion from PDF, video, URL, image, and document inputs, not just prompts\n- Introduced Pass I: Ingestion for standardizing and sourcing non-text inputs\n- Integrated evidence grading and provenance; Pass 2 now tags knowledge with evidence levels (primary/secondary/inferred)\n- Enforced \"honest boundaries\"—all skills must declare limitations and scope\n- Embedded meta-reflection (8-dimension self-audit) as a requirement at key pipeline stages\n- Updated and extended references and profiles; removed legacy/duplicated documentation and schema files\n\nv1.2.0 | 2026-06-29T00:24:18.602Z | user\n\nSkillcompiler v0.1.1 Changelog\n\n- Major refactor: Introduced target platform selection (`generic`, `trae`, `claude`) and platform-specific output rules.\n- Added support for multiple compilation modes (`quick`, `full`, `audit`) and token budget management.\n- Expanded and clarified Pass 0 Triage, now includes target platform and compilation mode selection.\n- Enhanced validation (Pass 6) with multi-layer evaluation and platform compliance checks.\n- Added extensive documentation and references, including IR and trace schemas, platform profiles, and anti-patterns.\n- Removed obsolete file: skill-card.md.\n\nv0.1.0 | 2026-06-26T02:15:02.504Z | auto\n\nInitial release of Skill Compiler, a tool for converting prompts into modular, production-grade AI Skills.\n\n- Introduces a compiler pipeline with 6 core passes and 3 conditional passes, driven by an intermediate representation (IR) model.\n- Defines strict optimization goals and principles, focusing on reusability, modularity, maintainability, and evolvability.\n- Includes clear triage and validation processes to ensure only suitable prompts are compiled.\n- Outputs a detailed compilation report with skill summary, folder structure, pass execution logs, module dependency graph, validation results, and future roadmap.\n- Provides robust architecture guidelines, references, and templates for building high-quality skill packages from any prompt.\n\nArchive index:\n\nArchive v1.2.2: 23 files, 68428 bytes\n\nFiles: profiles/claude.md (2694b), profiles/generic.md (2417b), profiles/trae.md (2783b), references/anti-patterns.md (2498b), references/evidence-grading.md (6419b), references/example-generation.md (1283b), references/honest-boundaries.md (5099b), references/meta-reflection.md (8544b), references/parallel-extractors.md (8971b), references/pass-1-analyze.md (4820b), references/pass-2-extract.md (6951b), references/pass-3-design.md (12798b), references/pass-4-generate.md (7107b), references/pass-5-optimize.md (4743b), references/pass-6-validate.md (16498b), references/pass-ingestion.md (13228b), references/plugin-discovery.md (1377b), schemas/ir-schema.json (16440b), skill-card.md (3047b), SKILL.md (13891b), templates/ir-schema.md (5293b), templates/skill-md-template.md (1615b), _meta.json (132b)\n\nFile v1.2.2:SKILL.md\n\n---\nname: skill-compiler\ndescription: \"Use when you need to compile any prompt OR multi-source content (PDF/video/URL/image/doc) into a production-grade, reusable AI Skill. Triggers on: 'prompt to skill', 'compile prompt', '把 prompt 变成 skill', '提示词编译', 'PDF转skill', '视频转skill', '网页转skill', 'skill from prompt', 'skill from document'. Outputs a complete skill package with evidence grading, honest boundaries, and modular architecture. Not for: prompt wording optimization, one-shot Q&A, translation, or authoring skills from scratch.\"\nversion: 2.0.0\n---\n\n# Skill Compiler\n\n**任意来源 → Skill IR → Optimized Skill Package**\n\n你不是 Prompt Engineer。你是一位 AI Skill Architect + Compiler Engineer。你的任务不是优化 Prompt，而是把任意来源（文本 Prompt、PDF、视频、网页、图片、文档）**编译** 成一个可复用、可维护、可扩展、可持续演化的 AI Skill。\n\n---\n\n## Optimization Goals\n\n整个编译过程中持续优化，而非机械转换。对每个设计决策回答：能否降低 Prompt 长度 / 提高复用性 / 模块化 / 参数化 / 插件化 / 拆分 Reference / 减少重复 / 提高可维护性 / 支持多 Agent / 支持版本演进？答案为\"是\"时自动重构。\n\n---\n\n## Core Principles\n\n| # | 原则 | 含义 |\n|---|------|------|\n| P1 | Prompt 不是 Skill | Skill = Role + Workflow + Knowledge + Decision Logic + Checklist + Rubric + Templates + Examples + Config + References + Output Schema |\n| P2 | 重复内容外置 | 超过一次使用的内容 → `references/` |\n| P3 | Prompt 最小化 | 知识外置，Workflow 独立，配置参数化 |\n| P4 | 不照搬 Prompt | 以 Skill 为中心重新设计，保留\"能力\"而非\"文字\" |\n| P5 | 元反思审计 | 在关键决策后自省：问题定义 / 假设 / 推理 / 证据 / 替代解释 / 边界 / 目标 / 不确定性 — 8 维度二次审视 |\n\n📍 [references/meta-reflection.md](references/meta-reflection.md)\n\n---\n\n## Compiler Pipeline\n\n```\nSource (Prompt / PDF / Video / URL / Image / Doc)\n  → [Pass I: Ingestion?] → [Pass 0: Triage] → [Pass 1: Analyze] → [Pass 2: Extract]\n  → [Pass 3: Design] → [Pass 4: Generate] → [Pass 5: Optimize?]\n  → [Pass 6: Validate] → Skill Package\n```\n\n| Pass | 执行 | 职责 | 详情 |\n|------|------|------|------|\n| **I Ingestion** | ⚠️ 条件 | 多源摄取：PDF/视频/网页/图片/文档 → 标准化结构化内容 + 来源溯源 | 📍 [references/pass-ingestion.md](references/pass-ingestion.md) |\n| **0 Triage** | ✅ 总是 | 判断是否值得编译 | 内联（决策表见下） |\n| **1 Analyze** | ✅ 总是 | 理解内容：目标/输入输出/边界/假设 | 📍 [references/pass-1-analyze.md](references/pass-1-analyze.md) |\n| **2 Extract** | ✅ 总是 | 能力图谱 + 知识清单（含证据分级）+ 角色矩阵 | 📍 [references/pass-2-extract.md](references/pass-2-extract.md) |\n| **3 Design** | ✅ 总是 | 架构类型 + 模块拆分（含诚实边界）+ Workflow + 目录结构 + 自测用例 + Skill 链接图 | 📍 [references/pass-3-design.md](references/pass-3-design.md) |\n| **4 Generate** | ✅ 总是 | 生成完整 Skill 文件包 | 📍 [references/pass-4-generate.md](references/pass-4-generate.md) |\n| **5 Optimize** | ⚠️ 条件 | 内容 > 500字 / 重复 / multi-agent 时执行 | 📍 [references/pass-5-optimize.md](references/pass-5-optimize.md) |\n| **6 Validate** | ✅ 总是 | 四层评估：结构完整性（A）+ IR 一致性（B）+ 触发质量（C，含压力测试）+ 平台合规（D） | 📍 [references/pass-6-validate.md](references/pass-6-validate.md) |\n\n**条件 Pass：**\n\n| Pass | 触发条件 | 详情 |\n|------|---------|------|\n| Plugin Discovery | Prompt 涉及外部能力（搜索/GitHub/DB/浏览器/MCP） | 📍 [references/plugin-discovery.md](references/plugin-discovery.md) |\n| Example Generation | Skill 涉及复杂流程/规则/评分体系 | 📍 [references/example-generation.md](references/example-generation.md) |\n\n**v2.0 核心知识资源（被各 Pass 按需引用）：**\n\n| 资源 | 职责 | 引用方 |\n|------|------|--------|\n| Evidence Grading | 三级证据体系（primary/secondary/inferred）+ 冲突保留 | Pass 2, Pass 6 Layer B |\n| Honest Boundaries | 诚实边界规范（局限性/失败模式/适用前提） | Pass 3, Pass 6 Layer A |\n| Parallel Extractors | 五并行提取器 + 三重验证 | Pass 2（多源/长内容时） |\n| Meta Reflection | 8 维度编译自省框架（问题/假设/推理/证据/替代/边界/目标/不确定性） | Pass 1, Pass 2, Pass 3, Pass 6 Decision Gates |\n\n📍 [references/evidence-grading.md](references/evidence-grading.md) · [references/honest-boundaries.md](references/honest-boundaries.md) · [references/parallel-extractors.md](references/parallel-extractors.md) · [references/meta-reflection.md](references/meta-reflection.md)\n\n---\n\n## Pass 0 — Triage（内联决策）\n\n**输入：** 若 Pass I Ingestion 执行过，此处输入为其产出的 `structured_content`（已标准化的多源内容）。否则为用户原始 Prompt。\n\n### Step 0.1 — 判断输入是否值得编译\n\n| 输入类型 | 判定 | Action |\n|---------|------|--------|\n| 一次性问答，无复用价值 | 不是 Skill | REJECT — 直接回答 |\n| 纯翻译/摘要/解释 | 不是 Skill | REJECT — 直接执行 |\n| 会反复使用 + 有可复用输出契约 | 是 Skill | → Step 0.2 |\n| 容易路由错误的复杂工作流 | 是 Skill | → Step 0.2 |\n\nREJECT 时告知\"这不建议做成 skill，因为 X\"，并直接完成请求。\n\n### Step 0.2 — 确定目标平台\n\n选择生成的 Skill 将在哪个平台运行。平台选择影响 frontmatter 格式、description 渲染风格、触发词策略和文件结构约束。\n\n| 平台 | 适用场景 | 特性 |\n|------|---------|------|\n| `trae` | TRAE IDE Skill | description 单行、触发词关键词匹配、references/ 懒加载 |\n| `claude` | Claude.ai / Claude Code | description 可多行、语义匹配、agents/ 目录支持 |\n| `generic` | 未知平台/未来平台 | 最保守的规范，最大兼容性 |\n\n**用户未指定时**，默认为 `generic`。高级用户可在编译过程中的 `unknowns` 阶段被询问。\n\n📍 平台规范文件: [profiles/trae.md](profiles/trae.md), [profiles/claude.md](profiles/claude.md), [profiles/generic.md](profiles/generic.md)\n\n### Step 0.3 — 选择编译模式\n\n根据源 Prompt 的复杂度和用户对成本/质量的权衡选择模式：\n\n| 模式 | Token 开销 | 执行 Pass | 适用场景 |\n|------|-----------|-----------|---------|\n| `quick` | 低（~3 次调用） | 0 → 1 → 3(轻) → 4 → 6(A层) | Prompt < 200 字，已熟悉 Skill 结构 |\n| `full` | 高（~6+ 次调用） | 0 → 1 → 2 → 3 → 4 → 5?(条件) → 6(全部三层) | Prompt 复杂，需要完整能力提取与验证 |\n| `audit` | 中（~2 次调用） | 6(全部四层) | 评估已有 Skill，不生成新文件 |\n\n**默认模式：** `full`。Token 敏感时建议手动选 `quick`。\n\n### Step 0.4 — 设定 Token 预算（可选）\n\n用户可设定本次编译的 token 总预算上限：\n\n- `total_budget` — 硬上限。0 表示无限制（默认）\n- `mode_change_at_pct` — 消耗达到预算 N% 时自动降级模式（默认 80%）\n- 超预算时编译器自动降级（`full` → `quick`）并记录到 trace\n\n**未设定预算时**，使用模式默认的调用次数估算。\n\n### Step 0.5 — 写入 IR\n\n```\nmeta.target_platform       = 用户选择或默认\nmeta.compilation_mode      = 用户选择或默认\nmeta.token_budget          = 用户设定或默认值\n```\n\n---\n\n## Execution Rules\n\n1. **Pass I Ingestion 优先（v2.0）** — 若输入为 URL/文件/图片/视频等非纯文本，先执行 Ingestion 标准化为结构化内容 + 来源溯源，再进 Pass 0。纯文本 Prompt 时跳过 Ingestion。\n2. **Pass 1-3 产出 Skill IR**（中间表示），不生成文件。📍 IR schema 见 [templates/ir-schema.md](templates/ir-schema.md)\n3. **Pass 4 基于 IR + 目标平台 profile 生成文件。** 按平台规范渲染 frontmatter、description 和文件结构。📍 生成模板见 [templates/skill-md-template.md](templates/skill-md-template.md)\n4. **每个 Pass 通过 IR 通信**，不直接传递未结构化文本\n5. **Decision Gate：** 每个 Pass 末尾有通过条件（详见各 pass 文件），不满足时向用户澄清\n6. **条件 Pass 由编译器自主判断**，不强制执行全部\n7. **平台 profile 应用时机：** Pass 4 生成时同时加载目标 platform profile，按 profile 规范渲染输出。Pass 6 Layer D 反向验证。\n8. **Token 估计门槛：** 每次 Pass 完成后在 IR 中更新 `token_budget.current_estimate`。若 `current_estimate > total_budget × mode_change_at_pct / 100`，自动降级编译模式。\n9. **诚实边界强制（v2.0）** — 生成的 skill 必须包含 honest-boundaries 声明。Pass 3 规划模块，Pass 6 Layer A 验证存在性。\n10. **证据可溯源（v2.0）** — 多源输入时，每条知识携带 evidence 等级。Pass 2 标注，Pass 6 Layer B 验证完整性。冲突不静默丢弃。\n11. **元反思自省（v2.1）** — 关键 Pass（1/2/3/6）Decision Gate 处执行 8 维度自检。Quick 模式跳过。自省结果写入 trace，不阻塞编译流程。📍 [references/meta-reflection.md](references/meta-reflection.md)\n\n---\n\n## Final Output\n\n编译完成后输出 Compilation Report：\n\n- **Skill Summary** — 名称 + 一句话描述\n- **Folder Tree** — 生成的目录结构\n- **Passes Executed** — 实际执行的 Pass 列表\n- **Module Dependency Graph** — 核心模块依赖关系\n- **Evaluation Report** — Pass 6 四层评估结果：\n  - Layer A 结构完整性 pass_rate\n  - Layer B IR 一致性 pass_rate（IR 作为 test oracle 验证产出）\n  - Layer C 触发质量 trigger_precision（self_test_cases 静态匹配）\n  - Layer D 平台合规 pass_rate（按 target platform profile 验证）\n  - 综合评分 `skill_quality_score`（0-100，含 Layer D）\n- **Cost Summary** — 编译成本汇总：\n  - 总 token 消耗（输入 + 输出）\n  - 执行的 Pass 列表 / 跳过的 Pass 列表\n  - Token 预算消费百分比（如设定了预算）\n- **Validation Result** — Pass 6 verdict + issues\n- **Technical Debt** — 已知技术债务\n- **Extension Roadmap** — 未来可扩展方向\n\n---\n\n## Gotchas / Footguns\n\n> 以下为已知的编译失败模式和风险点。\n\n1. **AP-11 风险（单轨迹过拟合）** — 不要基于单次编译经验调整哪些 Pass 该执行/跳过。Pass 的触发/跳过条件应基于显式规则（本 SKILL.md 定义的条件），而非\"上次编译时我跳过了这个 Pass 所以这次也跳\"。批量编译经验归纳后才可调整 Pass 触发策略。\n2. **IR 字段缺失是最常见的失败原因** — LLM 产出 IR 时常遗漏 `capability_graph.primary` 或 `folder_structure`。Pass 3→4 门控必须校验全部必填字段（见 [schemas/ir-schema.json](schemas/ir-schema.json)），缺失时回退而非硬闯 Pass 4。\n3. **Pass 5 条件判断不能只看输入长度** — 即使 Source Prompt < 500 字，生成的文件包中也可能出现重复知识（>= 3 处相同内容）。Pass 5 的触发条件应同时检查\"输入长度\"和\"输出重复度\"。\n4. **trace 产出不能省略** — trace-schema.json 定义的执行 trace 是下游消费者（如 SkillForge L4/L5）的契约输入。每次编译必须在 Final Output 中产出 trace。\n5. **平台 profile 必须显式指定才生效** — 默认 `generic` profile 生成最保守的输出。若要利用特定平台特性（如 TRAE 的触发词策略、Claude 的多行 description），需在 Pass 0 显式选择目标平台。先编译后改 description 会丢失 Pass 6 Layer D 的验证闭环。\n6. **Token 预算不能设得过于紧张** — `quick` 模式 ≈ 3 次 LLM 调用。如果 `total_budget` 设得低于 3 次调用的估算量，编译器可能在 Pass 0 就触发降级，实际执行与预期不符。建议 `quick` 预算 ≥ 5K tokens，`full` 预算 ≥ 15K tokens（估算值，因模型而异）。\n7. **不同平台间迁移需要重新编译** — 同一个 prompt 编译为 TRAE 和 Claude 的 skill 是两个不同的输出。平台 profile 不同，frontmatter、description 格式、触发词策略、文件结构都可能不同。直接复制文件到另一个平台大概率不可用。\n8. **Ingestion 不做内容理解（v2.0）** — Pass I 只负责\"格式转换 + 来源标注\"，不提取能力边界或知识。越界做内容理解会导致 IR 过早膨胀，且与 Pass 1/2 职责重叠。\n9. **OCR/转写结果必须保留置信度（v2.0）** — Ingestion 阶段的提取置信度是 Pass 2 证据分级（primary/secondary/inferred）的判定依据。丢弃置信度等于丢弃证据等级的根基。\n10. **冲突不要在编译过程中静默消除（v2.0）** — 多源输入时，不同来源对同一事实的矛盾表述必须保留并标注（写入 conflicts.md）。强行统一会丢失真实信号，让用户误以为 skill 比实际更可靠。\n11. **Pass I 外部命令执行需遵守安全边界（v2.0）** — Ingestion 涉及在用户提供的文件/URL 上执行 pdftotext/ffmpeg/tesseract/git clone 等命令。用户输入的路径和 URL 必须视为不可信输入，遵守路径限制、不拼接 shell、不执行嵌入代码等约束。📍 详见 [references/pass-ingestion.md](references/pass-ingestion.md) 的 Security Boundaries 章节。\n\n---\n\n## Provenance\n\n- **Built with:** SkillForge (Full mode)\n- **Source:** User-provided \"Prompt → Skill Compiler v1.0\" spec, refactored from 16 fixed phases to 6 core + 3 conditional compiler passes\n- **Design decision:** Phase → Compiler Pass model (conditional execution, IR-based)\n\nFile v1.2.2:_meta.json\n\n{\n  \"ownerId\": \"kn72r3ww47r1qyfaf233sf7q1982rh5f\",\n  \"slug\": \"skillcompiler\",\n  \"version\": \"1.2.2\",\n  \"publishedAt\": 1783844072951\n}\n\nFile v1.2.2:references/anti-patterns.md\n\n# Anti-Patterns — Skill 设计反模式\n\n**加载时机：** 📍 Pass 5 Optimize 执行 O1-O8 检查时加载。\n\n> 本文件定义 Skill Compiler 优化阶段（Pass 5）引用的反模式编号。\n> 完整 13 反模式库见 SkillForge [rubrics/anti-patterns.md](../../skillforge/rubrics/anti-patterns.md)。\n\n---\n\n## AP-02: Prompt Black Hole（Prompt 黑洞）\n\n**症状：** 把所有逻辑、规则、领域知识塞进一个巨大的 SKILL.md。token 爆炸，模型注意力分散。\n\n| 维度 | 详情 |\n|------|------|\n| 检测方法 | SKILL.md 超过 300 行 |\n| 修正 | 拆分为多 agent 或 reference 文件，SKILL.md 只做路由 manifest |\n| 严重度 | 🟠 High |\n| Pass 5 检查项 | O1（Prompt 长度优化） |\n\n## AP-04: Verification Theater（验证表演）\n\n**症状：** 声称有质量验证，但验证者和产出者是同一个 agent（或同一段 prompt）。\n\n| 维度 | 详情 |\n|------|------|\n| 检测方法 | 检查 verifier 是否独立于 producer |\n| 修正 | 使用独立的 Verifier Agent（干验分离原则） |\n| 严重度 | 🟠 High |\n| Pass 5 检查项 | O6（拆分检查） |\n\n## AP-06: Infinite Loop Without Guard（无界循环）\n\n**症状：** 工作流中有循环/迭代逻辑，但没有设置最大轮次上限。\n\n| 维度 | 详情 |\n|------|------|\n| 检测方法 | 检查 loop/feedback 步骤是否有 max_iterations |\n| 修正 | 设置硬性上限（推荐最多 3 轮） |\n| 严重度 | 🟠 High |\n| Pass 5 检查项 | O6（拆分检查） |\n\n## AP-07: God Agent（上帝 Agent）\n\n**症状：** 单个 agent 负责太多职责，prompt 中有 5+ 个不相关的\"功能\"。\n\n| 维度 | 详情 |\n|------|------|\n| 检测方法 | 读 agent 的 Capabilities/功能列表，检查是否有 >= 5 个不相关功能 |\n| 修正 | 按职责拆分为多个 agent，每个 agent 只负责一件事 |\n| 严重度 | 🟠 High |\n| Pass 5 检查项 | O5（模块化检查） |\n\n## AP-12: Trust-Domain Conflation（信任域混淆）\n\n**症状：** 同一逻辑概念被同一个文件承载，但该文件同时被\"隔离验证者\"和\"知情决策者\"读取。知情数据泄漏到隔离通道，导致隔离失效。\n\n| 维度 | 详情 |\n|------|------|\n| 检测方法 | ① 检查是否有 blind/isolated verifier；② 追踪其输入来源；③ 检查白名单文件是否包含知情数据 |\n| 修正 | 按信任域拆分文件（clean file vs dirty file） |\n| 严重度 | 🟠 High |\n| Pass 5 检查项 | O4（知识耦合检测） |\n\nFile v1.2.2:references/evidence-grading.md\n\n# Evidence Grading — 证据分级体系\n\n**加载时机：** 📍 Pass 2 Extract 执行知识提取时加载；Pass 6 Layer B 契约验证时加载。\n\n---\n\n## 设计哲学\n\n从多源内容（PDF/视频/网页/图片）提取的知识，可信度并不相同。原文直引、模型转述、编译器推断——这三类知识如果在 skill 中被同等对待，会导致用户把\"推测\"当成\"事实\"使用。\n\n本体系为每条知识打上证据等级，让 skill 的消费者（AI agent + 人类用户）知道\"这条结论多可靠\"。核心原则：**矛盾的信息不强行统一，而是保留并标注**——人本来就前后不一致，强制洗白会丢失真实信号。\n\n---\n\n## 三级证据体系\n\n| 等级 | 标签 | 含义 | 典型来源 |\n|------|------|------|---------|\n| **L1** | `primary` | 原文直引，可直接溯源到原始载体 | PDF 文本层、字幕原文、网页正文、代码注释 |\n| **L2** | `secondary` | 经过一次模型转述，存在转述损失 | OCR 结果、whisper 转写、视觉理解描述、摘要 |\n| **L3** | `inferred` | 编译器从上下文推断，原始载体未直接陈述 | 隐含假设、跨段推理、模式归纳 |\n\n### 判定规则\n\n| 内容形态 | 等级 | 理由 |\n|---------|------|------|\n| 引号内的原文 | `primary` | 可逐字核对 |\n| 代码块 | `primary` | 机器可验证 |\n| 表格数据 | `primary` | 结构化事实 |\n| OCR 提取的文字 | `secondary` | 可能有字符错误 |\n| 语音转写 | `secondary` | 可能有同音错误 |\n| \"这意味着...\" 的解读 | `inferred` | 推断而非原文 |\n| 从多个案例归纳的规律 | `inferred` | 归纳推理 |\n| 图表的结构化描述 | `secondary` | 视觉理解转述 |\n\n---\n\n## 在 Pass 2 中的应用\n\n### 提取时标注\n\nPass 2 Extract 从 `structured_content`（Pass I 产出）提取知识时，**每条知识必须带 `evidence` 字段**：\n\n```json\n{\n  \"content\": \"所有 API 响应必须包含 request_id 字段\",\n  \"source\": \"spec.pdf:p47\",\n  \"evidence\": \"primary\",\n  \"confidence\": 0.98\n}\n```\n\n### 默认值继承\n\n- 若 Pass I 为整份内容设定了默认 `evidence_grade`，Pass 2 提取的单条知识默认继承此等级\n- 但 Pass 2 可**逐条覆盖**：如从 `secondary` 内容中识别出一段原文直引，可升级为 `primary`\n\n### confidence 字段\n\n`confidence`（0-1）补充 `evidence` 的细粒度：\n- `primary` + `confidence: 0.95` = 高可信原文\n- `secondary` + `confidence: 0.6` = 低质量转写，需人工复核\n- `inferred` + `confidence: 0.7` = 中等把握的推断\n\n来源：OCR 置信度、whisper 置信度、或编译器对推断的自评。\n\n---\n\n## 冲突保留规则\n\n**核心原则：** 当多个来源对同一事实给出矛盾表述时，**不强行统一，保留所有版本并标注冲突**。\n\n### 冲突检测\n\nPass 2 提取时，若两条知识描述同一实体但内容矛盾：\n\n```json\n{\n  \"conflicts\": [\n    {\n      \"id\": \"C-001\",\n      \"topic\": \"API 限流策略\",\n      \"status\": \"open\",\n      \"versions\": [\n        { \"content\": \"每分钟 100 次\", \"source\": \"doc-v1.md\", \"evidence\": \"primary\", \"confidence\": 0.95 },\n        { \"content\": \"每分钟 1000 次\", \"source\": \"doc-v2.md\", \"evidence\": \"primary\", \"confidence\": 0.95 }\n      ],\n      \"resolution\": null,\n      \"resolved_by\": null,\n      \"resolved_at\": null,\n      \"note\": \"两个版本表述不一致，保留待用户裁决\"\n    }\n  ]\n}\n```\n\n### 冲突状态机\n\n```\nopen ──────────────────────────────► resolved\n  │                                     │\n  ├──► wontfix（不影响核心功能）         ├── resolution: prefer_higher_evidence\n  │                                     ├── resolution: prefer_newer\n  └──► deprecated（源已过期）            ├── resolution: merged\n                                        ├── resolution: user_override\n                                        └── resolved_by: user | compiler | cross_reference\n```\n\n| 状态 | 含义 | 终态？ |\n|------|------|--------|\n| `open` | 新发现冲突，待处理 | 否 |\n| `resolved` | 已裁决，标注了 resolution 和 resolved_by | 是 |\n| `wontfix` | 不影响核心功能，保留但不处理 | 是 |\n| `deprecated` | 冲突源已不再适用 | 是 |\n\n### 冲突处理策略\n\n| 策略 | 适用场景 |\n|------|---------|\n| `prefer_higher_evidence` | 一方 primary 一方 inferred，采用 primary |\n| `prefer_newer` | 来源有时间戳且差异显著，采用较新版本（需标注理由） |\n| `flag_for_user` | 矛盾影响 skill 核心功能，必须用户裁决 |\n| `merged` | 两版本可合并为更完整的表述 |\n| `user_override` | 用户明确选择了某一版本 |\n\n**禁止操作：** 静默丢弃任一版本、强行取平均值、随机选择一方。\n\n### 冲突在生成 skill 中的呈现\n\n冲突不隐藏，写入生成的 skill 的 `references/gotchas.md` 或 `references/conflicts.md`：\n\n```markdown\n## 已知冲突\n\n### API 限流策略\n- 来源 A（doc-v1.md）称\"每分钟 100 次\"\n- 来源 B（doc-v2.md）称\"每分钟 1000 次\"\n- 状态：未裁决。使用前请核实当前版本。\n```\n\n---\n\n## 在 Pass 6 中的应用\n\n### Layer B 契约验证新增检查\n\n| # | 检查项 | PASS 标准 | 严重度 |\n|---|--------|-----------|--------|\n| B9 | evidence 字段完整性 | 所有 knowledge_inventory 条目都有 evidence 字段 | 🟠 High |\n| B10 | inferred 条目有标注 | evidence=inferred 的条目在生成文件中明确标注为\"推断\" | 🟡 Medium |\n| B11 | 冲突未被静默丢弃 | IR 中 conflicts 数组的每个条目在生成文件中都有对应呈现 | 🟠 High |\n\n### 诚实性原则\n\n生成的 skill 不应把 `inferred` 知识当作 `primary` 事实陈述。Pass 6 Layer A 检查：\n\n> reference 文件中，推断性结论是否使用了\"可能\"、\"推测\"、\"建议核实\"等限定词，而非确定性表述。\n\n---\n\n## 与 Ingestion 阶段的衔接\n\n| Pass I 产出 | Pass 2 继承 |\n|------------|-------------|\n| `evidence_grade: primary`（默认） | 单条知识默认 primary，可被覆盖 |\n| `evidence_grade: secondary`（OCR/转写） | 单条知识默认 secondary |\n| `extraction_warnings: [OCR 置信度低]` | 相关段落 confidence 降至 0.6 以下 |\n| `provenance: [{source, extractor, confidence}]` | 每条知识的 source 字段溯源到此 |\n\nFile v1.2.2:references/example-generation.md\n\n# Conditional Pass: Example Generation\n\n**加载时机：** 📍 仅当 Skill 涉及复杂流程/规则/评分体系时加载。\n\n---\n\n## 触发条件\n\n满足任一：\n- architecture_type = workflow 或 multi-agent\n- 有 rubrics（评分体系）\n- 有 5+ 条 rules\n- 用户显式要求\n\n---\n\n## 生成规则\n\n### 示例类型\n\n| 类型 | 用途 | 何时生成 |\n|------|------|---------|\n| Minimal | 最简输入输出，验证基本流程 | 总是 |\n| Normal | 典型使用场景 | 总是 |\n| Complex | 边界条件或复杂输入 | 当有复杂规则时 |\n| Edge Case | 极端输入 | 当有数值阈值时 |\n| Failure Case | 应该失败的输入 | 当有输入验证时 |\n| Anti-pattern | 不应该这样用 | 当有常见误用时 |\n\n### 示例格式\n\n```markdown\n# Example: {Title}\n\n**Type:** minimal | normal | complex | edge-case | failure | anti-pattern\n\n## Input\n{输入内容}\n\n## Expected Output\n{期望输出}\n\n## Notes\n{为什么是这个输出，关键决策点}\n```\n\n### 生成原则\n\n1. **从 Prompt 中提取** — 如果 Prompt 自带示例，优先用\n2. **覆盖关键路径** — 每个主要 workflow 步骤至少有一个示例\n3. **不过度生成** — 3-5 个高质量示例 > 10 个低质量示例\n4. **可扩展** — examples/ 目录设计为可追加\n\nFile v1.2.2:references/honest-boundaries.md\n\n# Honest Boundaries — 诚实边界规范\n\n**加载时机：** 📍 Pass 3 Design 规划模块时加载；Pass 6 Layer A 结构审查时加载。\n\n---\n\n## 设计哲学\n\n一个不告诉你\"它做不到什么\"的 skill，不值得信任。\n\n大多数 skill 只描述自己的能力，却不声明局限。这导致用户在边界外使用时得到错误结果，却以为是 skill 质量问题。诚实边界的核心是：**每个 skill 必须显式声明自己的能力边界、失败模式、和适用前提**，让用户在使用前就知道风险。\n\n这不是\"谦虚\"，是工程契约——类似 API 文档里的 `throws` 声明。\n\n---\n\n## 三类边界声明\n\n每个生成的 skill 必须包含以下三类边界声明：\n\n### 1. 能力边界（Cannot Do）\n\n明确列出 skill **做不到**的事。来源：\n\n- Pass 1 的 `boundary.out_of_scope`\n- Pass I 的 `extraction_warnings`（如内容不完整）\n- 领域知识中隐含的适用限制\n\n**示例：**\n\n```markdown\n## 局限性\n\n本 skill **不能**：\n- 处理实时数据流（设计为批处理模式）\n- 识别 0-day 漏洞（规则库更新周期为周级）\n- 保证 100% 准确率（基于启发式规则，误报率约 5%）\n```\n\n### 2. 失败模式（Failure Modes）\n\n描述 skill 在什么情况下会**给出低质量或错误结果**：\n\n```markdown\n## 已知失败模式\n\n- 输入代码超过 2000 行时，审查质量下降（注意力分散）\n- 混合语言的代码块（如 SQL 内嵌在 Python）可能漏报\n- 高度抽象的设计模式代码，规则匹配可能误报\n```\n\n来源：Pass 6 审查中发现的弱点、Pass 2 的 `inferred` 知识、领域经验。\n\n### 3. 适用前提（Prerequisites）\n\n使用 skill 前必须满足的条件：\n\n```markdown\n## 适用前提\n\n- 输入必须是可编译的源码（不支持伪代码）\n- 项目需有基本的测试覆盖（否则\"未覆盖\"警告无意义）\n- 单次审查文件数 ≤ 50（超过需分批）\n```\n\n---\n\n## 在 Pass 3 中的应用\n\n### 模块规划\n\nPass 3 Design 必须在 `module_decomposition` 中规划边界声明模块：\n\n```json\n{\n  \"module_decomposition\": {\n    \"references\": [\n      \"references/honest-boundaries.md — 局限性、失败模式、适用前提\"\n    ]\n  }\n}\n```\n\n### 边界声明来源映射\n\n| 边界类型 | 数据来源 | IR 字段 |\n|---------|---------|---------|\n| Cannot Do | 显式排除项 | `pass_1.boundary.out_of_scope` |\n| Cannot Do | 提取警告 | `pass_ingestion.extraction_warnings` |\n| Failure Modes | 推断性知识的弱点 | `pass_2` 中 evidence=inferred 的条目 |\n| Failure Modes | 架构固有限制 | `pass_3.architecture_type` 的已知弱点 |\n| Prerequisites | 输入要求 | `pass_1.input_spec` |\n\n### 生成模板（Pass 4 使用）\n\n```markdown\n# Honest Boundaries\n\n## 局限性（Cannot Do）\n{从 boundary.out_of_scope 逐条生成}\n\n## 已知失败模式\n{从 inferred 知识 + 架构弱点生成}\n\n## 适用前提\n{从 input_spec + 架构约束生成}\n\n## 证据强度提示\n{当 skill 包含 secondary/inferred 知识时，声明\"部分结论基于转述/推断，建议核对原文\"}\n```\n\n---\n\n## 在 Pass 6 中的应用\n\n### Layer A 结构审查新增角色检查\n\n**Role 2 — Knowledge Engineer** 新增检查项：\n\n| 检查项 | 问题信号 | 严重度 |\n|--------|---------|--------|\n| 边界声明存在 | 生成的 skill 是否有 honest-boundaries / gotchas / limitations 章节 | 🟠 High |\n| 边界完整性 | out_of_scope 项是否都在生成文件中有对应声明 | 🔴 Critical |\n| 推断标注 | inferred 知识是否被标注为\"推断/可能\"而非\"事实\" | 🟠 High |\n| 失败模式诚实 | 是否声明了至少 1 个已知失败模式（非空壳） | 🟡 Medium |\n\n### 空壳检测\n\n若生成的 `references/honest-boundaries.md` 只有骨架无实质内容（全是 TODO/占位符），标记为：\n\n> 🟡 Medium — 边界声明为空壳。建议基于 Pass 6 审查发现补充实际失败模式。\n\n### 评分影响\n\n- 缺失边界声明章节：Layer A pass_rate 扣减\n- out_of_scope 项未在生成文件中体现：Layer B B2 直接 FAIL（Critical）\n- inferred 知识未标注：Layer B B10 FAIL（Medium）\n\n---\n\n## 与 Gotchas 的区别\n\n| 文档 | 职责 | 时态 |\n|------|------|------|\n| `honest-boundaries.md` | 系统性的能力边界声明 | 设计时已知 |\n| `gotchas.md` | 上线后发现的踩坑记录 | 运行时发现 |\n\n两者互补：honest-boundaries 是\"出生时就知道的局限\"，gotchas 是\"踩坑后补的\"。新生成的 skill 优先填充 honest-boundaries，gotchas 留骨架待运行时填充。\n\n---\n\n## 反模式\n\n| 反模式 | 说明 | 检测 |\n|--------|------|------|\n| **全能声明** | description 声称能做所有事，无任何局限 | Layer C 触发质量检查：negative case 未被排斥 |\n| **空壳边界** | 有 honest-boundaries 章节但全是占位符 | Pass 6 空壳检测 |\n| **隐藏推断** | inferred 知识用确定性语气陈述 | Layer B B10 检查 |\n| **静默丢弃冲突** | 多源矛盾信息只保留一方 | evidence-grading.md 冲突保留规则 + Layer B B11 |\n\nFile v1.2.2:references/meta-reflection.md\n\n# Meta-Reflection — 编译过程自省框架\n\n**加载时机：** 在各 Pass 的 Decision Gate 处按需引用。编译器在执行关键决策后，用此框架对自己的判断进行二次审视。\n\n---\n\n## 设计哲学\n\n编译 Skill 不仅是机械的\"输入→分析→设计→生成\"。编译器在高模糊性的决策点（如\"这个能力是 primary 还是 secondary？\"\"这个架构选 workflow 还是 multi-agent？\"）容易陷入经验惯性或盲区。\n\n**元反思是编译器的\"自我审计\"机制**——在关键决策后，暂停片刻，用结构化维度审视刚才的判断是否经得起推敲。\n\n---\n\n## 八维度框架\n\n| # | 维度 | 核心问题 | 适用阶段 |\n|---|------|---------|---------|\n| D1 | **问题定义** | 我是否理解了真正的问题？有没有更好的问题表述？ | Pass 1 Analysis |\n| D2 | **假设** | 我的关键假设是什么？哪些未经验证？ | Pass 1 Analysis |\n| D3 | **推理** | 推理链是否存在跳跃、循环或逻辑漏洞？ | Pass 3 Design |\n| D4 | **证据** | 哪些观点有证据支持？哪些只是推测？ | Pass 2 Extract, Pass 6 Validate |\n| D5 | **替代解释** | 是否存在其他同样合理甚至更好的解释？ | Pass 3 Design |\n| D6 | **边界条件** | 结论适用于哪些场景？什么时候会失效？ | Pass 3 Design |\n| D7 | **目标** | 当前优化目标是否正确？是否应该优化更高层目标？ | Pass 1 Analysis, Pass 6 Validate |\n| D8 | **不确定性** | 我最没有把握的部分是什么？还需要哪些信息才能提高可信度？ | Pass 1 Analysis, Pass 6 Validate |\n\n---\n\n## 各维度详解\n\n### D1 — 问题定义（Problem Definition）\n\n**核心问题：** 我是否理解了真正的问题？有没有更好的问题表述？\n\n**在编译上下文中的含义：**\n- 用户给的 Prompt 字面含义 vs 真实需求是否一致？\n- `prompt_goal.stated` 和 `prompt_goal.actual` 的差距有多大？\n- 有没有更精确的方式描述这个 Skill 要解决的问题？\n\n**触发时刻：** Pass 1 Step 1.2 Goal Extraction 完成后\n\n**自检清单：**\n- [ ] stated goal 是否只是 actual goal 的表面表述？\n- [ ] 如果换一种方式定义这个问题，skill 的设计会完全改变吗？\n- [ ] 用户可能没有说出来的深层需求是什么？\n\n---\n\n### D2 — 假设（Assumptions）\n\n**核心问题：** 我的关键假设是什么？哪些未经验证？\n\n**在编译上下文中的含义：**\n- `hidden_assumptions` 列表中的每一项——有没有办法在编译过程中验证而非假设？\n- 假设用户\"熟悉 Skill 结构\"是否导致跳过了必要的解释？\n- 假设\"输入格式稳定\"是否忽略了格式退化场景？\n\n**触发时刻：** Pass 1 Step 1.6 Hidden Assumptions 完成后\n\n**自检清单：**\n- [ ] 每个 hidden_assumption 是否标注了\"可验证\"还是\"不可在编译期内验证\"？\n- [ ] 是否存在\"假设用户会正确使用\"这一隐含假设？\n- [ ] 最脆弱的一个假设如果错了，哪些设计决策会崩塌？\n\n---\n\n### D3 — 推理（Reasoning）\n\n**核心问题：** 推理链是否存在跳跃、循环或逻辑漏洞？\n\n**在编译上下文中的含义：**\n- architecture_type 的决策链是否有跳跃？(\"因为有多个步骤 → 所以选 workflow\"——但步骤间是否需要不同专业角色？)\n- workflow pattern 的选择是否自洽？(classify-and-act + pipeline 的组合是否合理？)\n- 模块拆分的依据是否一致？(为什么规则 A 独立成文件而规则 B 内联？)\n\n**触发时刻：** Pass 3 Step 3.1 Architecture Type 决策后、Step 3.4 Module Decomposition 后\n\n**自检清单：**\n- [ ] 每个\"因为 X 所以 Y\"的推理步骤是否可以回溯到明确的条件？\n- [ ] 是否存在循环推理——\"选 A 是因为 B，而 B 的定义来自 A\"？\n- [ ] 模块拆分标准是否前后一致？\n\n---\n\n### D4 — 证据（Evidence）\n\n**核心问题：** 哪些观点有证据支持？哪些只是推测？\n\n**在编译上下文中的含义：**\n- 每条知识的 `evidence` 字段：primary / secondary / inferred 的分布是否健康？\n- inferred 条目是否标注了推断依据？\n- 是否存在大量 inferred 知识被当作 primary 使用？\n\n**触发时刻：** Pass 2 Step 2.2 Knowledge Inventory 后、Pass 6 Layer B 验证时\n\n**自检清单：**\n- [ ] inferred 条目占比是否 > 30%？如果是，skill 的可信度是否足够？\n- [ ] 是否存在\"所有人都知道\"但其实只是推断的知识？\n- [ ] 冲突条目（conflicts）是否都有来源标注？\n\n---\n\n### D5 — 替代解释（Alternative Explanations）\n\n**核心问题：** 是否存在其他同样合理甚至更好的解释？\n\n**在编译上下文中的含义：**\n- 能力图谱的 primary/secondary 划分是否有替代方案？\n- 架构类型的选择是否有同等级有力的替代方案？\n- 当前选定的 workflow pattern 之外，是否存在另一个 pattern 同样合理？\n\n**触发时刻：** Pass 3 Step 3.1-3.2 架构与 workflow 决策后\n\n**自检清单：**\n- [ ] 至少考虑过 1 个替代的 architecture_type 并给出淘汰理由\n- [ ] 至少考虑过 1 个替代的 workflow pattern 并给出淘汰理由\n- [ ] 替代方案的优势是否被诚实评估？（而非刻意贬低以证明当前选择正确）\n\n---\n\n### D6 — 边界条件（Boundary Conditions）\n\n**核心问题：** 结论适用于哪些场景？什么时候会失效？\n\n**在编译上下文中的含义：**\n- boundary.out_of_scope 是否足够具体？还是泛泛的\"不处理无关请求\"？\n- 当前设计的 architecture 在什么条件下会变成错误选择？\n- 生成的 skill 在什么使用场景下会表现不佳？\n\n**触发时刻：** Pass 3 Step 3.4-3.8 模块设计与目录规划后\n\n**自检清单：**\n- [ ] out_of_scope 条目是否都足够具体，可被 Pass 6 Layer C 的压力测试验证？\n- [ ] 设计的架构在以下极端条件下是否仍适用：输入为空 / 输入极长 / 输入格式退化？\n- [ ] skill 的失效模式是否在 honest-boundaries 中声明？\n\n---\n\n### D7 — 目标（Goals）\n\n**核心问题：** 当前优化目标是否正确？是否应该优化更高层目标？\n\n**在编译上下文中的含义：**\n- 当前在优化\"Prompt 长度\"还是\"Skill 可维护性\"——这两个目标冲突时优先级是什么？\n- 是不是在过度优化某个指标而牺牲了更重要的指标？\n- 编译的最终目标是\"产出高质量 skill\"还是\"通过所有 Pass\"？\n\n**触发时刻：** Pass 1 完成后、Pass 6 综合评分前\n\n**自检清单：**\n- [ ] \"降低 token 消耗\"是否导致关键知识被移除？\n- [ ] \"提高评分\"是否导致过度设计——加了不必要但能加分的模块？\n- [ ] 最终产出对用户而言真的可用吗？（而非只是在 IR 中看起来好）\n\n---\n\n### D8 — 不确定性（Uncertainty）\n\n**核心问题：** 我最没有把握的部分是什么？还需要哪些信息才能提高可信度？\n\n**在编译上下文中的含义：**\n- unknowns 列表中是否遗漏了关键的不确定信息？\n- 编译过程中哪些决策是\"猜测\"而非\"推理\"？\n- 哪些推断如果能向用户确认，会显著提高 skill 质量？\n\n**触发时刻：** Pass 1 Step 1.7 Unknowns 后、Pass 6 最终审查时\n\n**自检清单：**\n- [ ] 是否有超过 3 个未被询问的 unknowns？（如果是，选最重要的 3 个问用户）\n- [ ] 最终的 skill 中哪些部分是\"我们猜的\"而非\"确定的\"？\n- [ ] 如果只能向用户确认一件事来提高 skill 质量，那件事是什么？\n\n---\n\n## 检查点放置\n\n| 阶段 | 检查点 | 覆盖维度 | 位置 |\n|------|--------|---------|------|\n| Pass 1 收尾 | 分析后自省 | D1, D2, D7, D8 | pass-1-analyze.md Step 1.8 |\n| Pass 2 收尾 | 知识提取后自省 | D4 | pass-2-extract.md Step 2.4 |\n| Pass 3 收尾 | 设计后自省 | D3, D5, D6 | pass-3-design.md Step 3.11 |\n| Pass 6 评前 | 验证前自省 | D4, D7, D8 | pass-6-validate.md Step 6.0 |\n\n---\n\n## 使用约束\n\n1. **每个检查点不超过 3 个维度**——不是所有维度都要在每处应用\n2. **只问能改变决策的问题**——如果某个维度的回答不会改变任何设计，跳过它\n3. **记录但不阻塞**——meta-reflection 的输出写入 trace 或日志，但不应成为 Decision Gate 的硬阻塞条件。它是编译器自我校准的机制，而非额外的审批门槛\n4. **快速模式跳过**——compilation_mode 为 `quick` 时，meta-reflection 检查点全部跳过（token 成本优先）\n\nFile v1.2.2:references/parallel-extractors.md\n\n# Parallel Extractors — 并行知识提取器\n\n**加载时机：** 📍 Pass 2 Extract 执行知识提取时加载（当 source 来自多源摄取或内容复杂时）。\n\n---\n\n## 设计哲学\n\n从长内容（整份 PDF、视频转写、网页文档）提取知识时，单线程逐句扫描效率低且容易遗漏。并行提取器的核心：**派多个专项提取器同时扫描同一份内容，每个只关注一类知识，最后合并去重**。\n\n类比编译器的并行优化 pass：每个 pass 只做一个具体的优化（常量折叠、死代码消除），但它们可以并行跑，最后合并 IR。\n\n---\n\n## 五个专项提取器\n\n| 提取器 | 关注的知识类型 | 输出 |\n|--------|--------------|------|\n| **F1 框架提取器** | 方法论、流程、步骤模型、决策树 | 结构化的流程描述 |\n| **F2 原则提取器** | 规则、约束、最佳实践、戒律 | 规则清单 |\n| **F3 案例提取器** | 具体实例、应用场景、成功案例 | 带上下文的案例 |\n| **F4 反例提取器** | 失败案例、常见错误、反模式、边界外的行为 | 负面清单 |\n| **F5 术语提取器** | 领域概念、专有名词、定义、术语表 | 术语词典 |\n\n### 为什么是这五类\n\n这五类覆盖了 skill 所需知识的完整光谱：\n\n- **F1 框架** 回答\"怎么做\"（Workflow）\n- **F2 原则** 回答\"必须遵守什么\"（Rules）\n- **F3 案例** 回答\"什么时候用\"（Examples）\n- **F4 反例** 回答\"什么时候不该用\"（Boundary）\n- **F5 术语** 回答\"关键词什么意思\"（Domain Knowledge）\n\n对应 skill 架构：F1→workflows，F2→references/rules，F3→examples，F4→honest-boundaries/gotchas，F5→references/domain。\n\n---\n\n## 执行机制\n\n### 并行触发条件\n\n当满足任一条件时，启用并行提取器（而非 Pass 2 的默认单线程提取）：\n\n| 条件 | 理由 |\n|------|------|\n| Pass I 执行了（多源摄取） | 摄取后的内容通常量大且杂 |\n| `structured_content` > 3000 字 | 单线程扫描长内容易遗漏 |\n| 内容含 3+ 个独立主题 | 需要多维度并行覆盖 |\n| 用户显式要求深度提取 | 质量优先 |\n\n### 并行执行模型\n\n五个提取器**逻辑并行**（在同一轮中分别扫描全文），每个独立产出候选知识列表：\n\n```\nstructured_content\n      │\n  ┌───┼───┬───┬───┬───┐\n  F1  F2  F3  F4  F5\n  │   │   │   │   │\n  ▼   ▼   ▼   ▼   ▼\n 候选  候选  候选  候选  候选\n  │   │   │   │   │\n  └───┴───┴───┴───┴───┘\n      │\n  合并去重 + 三重验证\n      │\n      ▼\n  validated knowledge_inventory\n```\n\n---\n\n## 各提取器规格\n\n### F1 — 框架提取器\n\n**扫描目标：** 方法论、流程、步骤性内容。\n\n**识别信号：**\n- 编号步骤（\"第一步...第二步...\"）\n- 流程图/决策树的文字描述\n- \"流程是\"、\"按以下步骤\"、\"方法论包括\"\n- 时序性叙述（先...再...最后...）\n\n**产出格式：**\n```json\n{\n  \"extractor\": \"F1-framework\",\n  \"candidates\": [\n    {\n      \"content\": \"代码审查三阶段：自动检查 → 人工审查 → 安全审计\",\n      \"source\": \"SEG-014\",\n      \"evidence\": \"primary\",\n      \"framework_steps\": [\"自动检查\", \"人工审查\", \"安全审计\"]\n    }\n  ]\n}\n```\n\n### F2 — 原则提取器\n\n**扫描目标：** 规则、约束、强制要求。\n\n**识别信号：**\n- 强制词：\"必须\"、\"禁止\"、\"不要\"、\"always\"、\"never\"、\"强制\"\n- 建议词：\"应该\"、\"建议\"、\"推荐\"、\"避免\"\n- 约束词：\"不得超过\"、\"至少需要\"、\"限定为\"\n\n**产出格式：**\n```json\n{\n  \"extractor\": \"F2-principle\",\n  \"candidates\": [\n    {\n      \"content\": \"禁止硬编码 API key 在源码中\",\n      \"source\": \"SEG-022\",\n      \"evidence\": \"primary\",\n      \"rule_type\": \"prohibition\"\n    }\n  ]\n}\n```\n\n### F3 — 案例提取器\n\n**扫描目标：** 具体实例、应用场景。\n\n**识别信号：**\n- \"例如\"、\"示例\"、\"case\"、\"场景\"\n- 具体的输入输出对\n- \"当...时，应该...\"\n\n**产出格式：**\n```json\n{\n  \"extractor\": \"F3-case\",\n  \"candidates\": [\n    {\n      \"content\": \"处理用户登录时，先验证 CSRF token 再查数据库\",\n      \"source\": \"SEG-031\",\n      \"evidence\": \"primary\",\n      \"case_type\": \"application\"\n    }\n  ]\n}\n```\n\n### F4 — 反例提取器\n\n**扫描目标：** 失败案例、反模式、常见错误。\n\n**识别信号：**\n- \"不要\"、\"错误\"、\"避免\"、\"反模式\"、\"常见错误\"\n- \"踩坑\"、\"教训\"、\"失败的\"\n- 负面表述（\"这样会导致...\"）\n\n**产出格式：**\n```json\n{\n  \"extractor\": \"F4-antipattern\",\n  \"candidates\": [\n    {\n      \"content\": \"不要在循环中创建数据库连接，会导致连接池耗尽\",\n      \"source\": \"SEG-040\",\n      \"evidence\": \"primary\",\n      \"antipattern_type\": \"performance\"\n    }\n  ]\n}\n```\n\n**重要：** F4 的产出直接喂给 [honest-boundaries.md](honest-boundaries.md) 的失败模式章节。\n\n### F5 — 术语提取器\n\n**扫描目标：** 领域概念、专有名词。\n\n**识别信号：**\n- 定义句（\"X 是指...\"、\"X 定义为...\"）\n- 首字母缩写（CSRF、SSRF、XSS）\n- 反复出现的领域名词\n- 中英文对照术语\n\n**产出格式：**\n```json\n{\n  \"extractor\": \"F5-term\",\n  \"candidates\": [\n    {\n      \"content\": \"CSRF（Cross-Site Request Forgery）：跨站请求伪造\",\n      \"source\": \"SEG-005\",\n      \"evidence\": \"primary\",\n      \"term\": \"CSRF\"\n    }\n  ]\n}\n```\n\n---\n\n## 合并去重\n\n五个提取器产出后，合并为统一候选池：\n\n### 去重规则\n\n| 情况 | 处理 |\n|------|------|\n| 同一内容被多个提取器命中 | 保留证据等级最高的版本，合并 source 标注 |\n| 语义相同表述不同 | 保留表述最清晰的版本，记录变体 |\n| 矛盾内容（F2 说\"必须\" vs 另一来源说\"可选\"） | 不去重，触发 [evidence-grading.md](evidence-grading.md) 冲突保留规则 |\n\n### 去重后\n\n候选池进入**三重验证**。\n\n---\n\n## 三重验证\n\n**核心原则：** 不是所有候选都值得变成 skill 知识。每个候选必须通过三项检验才能进入 `knowledge_inventory`。\n\n### V1 — 独立佐证（Corroboration）\n\n候选知识必须在原始内容中有 **≥ 2 处独立佐证**，或来自 `primary` 证据且表述明确。\n\n| 通过条件 | 说明 |\n|---------|------|\n| 同一观点出现 2+ 次（不同段落） | 强佐证 |\n| 1 次 primary + 1 次 secondary | 中佐证，通过 |\n| 仅 1 次 inferred | **不通过**（孤立推断不可靠） |\n\n### V2 — 预测力（Predictive Power）\n\n候选知识必须能回答原始内容中**未明说的新问题**。\n\n**测试方法：** 构造一个原始内容未直接讨论的场景，看这条知识是否能给出指导。若不能（即只是重复原文事实），则预测力不足。\n\n| 通过条件 | 说明 |\n|---------|------|\n| 能指导原文未覆盖的新场景 | 通过 |\n| 仅在原文特定上下文成立 | 降级为 example（而非 rule） |\n| 纯事实陈述无泛化能力 | **不通过**（不是可复用知识） |\n\n### V3 — 非常识性（Non-triviality）\n\n候选知识不应是\"所有从业者都知道\"的常识。\n\n| 通过条件 | 说明 |\n|---------|------|\n| 包含领域特定的非显而易见洞察 | 通过 |\n| 是通用编程/写作常识（如\"变量要命名清晰\"） | **不通过**（无增值） |\n| 是原始内容的独特观点 | 通过 |\n\n### 验证结果\n\n| 通过几项 | 处理 |\n|---------|------|\n| V1 + V2 + V3 全通过 | 进入 `knowledge_inventory` |\n| 通过 2 项 | 降级为 `examples`（参考用，非规则） |\n| 通过 ≤ 1 项 | 淘汰 |\n\n**典型通过率：** 经验上，候选池中只有 25-50% 能通过三重验证。这是正常的——高门槛保证 skill 质量不注水。\n\n---\n\n## Output\n\n并行提取器的产出合并进 Pass 2 的标准 `knowledge_inventory` 结构，每条知识额外携带：\n\n```json\n{\n  \"extractor\": \"F1-framework\",\n  \"verification\": {\n    \"v1_corroboration\": true,\n    \"v2_predictive\": true,\n    \"v3_non_trivial\": true,\n    \"passed\": true\n  }\n}\n```\n\n---\n\n## Gotchas\n\n1. **并行提取器不是必须的** — 纯文本短 Prompt 直接用 Pass 2 默认单线程提取即可。强制对 200 字 Prompt 跑 5 个提取器是过度设计。\n2. **F4 反例提取器最易被忽略但最有价值** — 反例直接喂给诚实边界，是 skill 可信度的关键。不要因为\"负面内容少\"就跳过 F4。\n3. **三重验证的 V2 最难判定** — \"预测力\"需要构造假设场景测试，容易被跳过。但跳过 V2 会导致 skill 充满不可复用的碎片事实。\n4. **去重不要在提取器内部做** — 每个提取器只管自己那类，跨类去重在合并阶段统一做。提取器内部去重会丢失跨类关联。\n5. **通过率低是好事** — 若通过率 > 70%，说明验证门槛太松，skill 会注水。调整验证标准而非降低门槛。\n\nFile v1.2.2:references/pass-1-analyze.md\n\n# Pass 1: Analyze — 理解 Prompt\n\n**加载时机：** 📍 执行到 Pass 1 时加载。\n**输入来源：** 若 Pass I Ingestion 执行过，本 Pass 的输入是其产出的 `structured_content`（标准化文本），需额外关注来源溯源与证据等级。若未执行 Ingestion，输入为用户原始 Prompt。\n\n---\n\n## 执行步骤\n\n### Step 1.1 — Prompt Summary\n\n用一句话概括 Prompt 的核心功能。不照搬原文，用自己的话重述。\n\n### Step 1.2 — Goal Extraction\n\n区分 Prompt\"说的\"和\"真正需要的\"：\n- **说的：** Prompt 字面要求做什么\n- **真正需要的：** 这个能力长期来看应该解决什么问题\n\n### Step 1.3 — Input/Output Spec\n\n| 字段 | 如何确定 |\n|------|---------|\n| input | Prompt 接收什么？用户输入？文件？API 响应？结构化内容？ |\n| output | Prompt 产出什么？文本？JSON？文件？结构化报告？ |\n\n如果 Prompt 没有明确说明，从上下文推断并标注为 `inferred`。\n\n**多源输入识别（v2.0）：** 若 Pass I 执行过（IR 含 `pass_ingestion` 字段），`input_spec.type` 设为 `structured_content`，并在 description 中注明原始来源类型（如\"来自 PDF 规范文档的结构化内容\"）。同时检查 `pass_ingestion.extraction_warnings`，若存在 critical 警告，在 `hidden_assumptions` 中记录\"输入内容可能不完整\"。\n\n### Step 1.4 — Capability Hints\n\n快速扫描 Prompt 中暗示的能力关键词：\n\n```\n决策类：decision, choose, recommend, 判断, 推荐, 决策\n规划类：plan, strategy, roadmap, 规划, 策略, 路线图\n写作类：write, draft, compose, 写, 起草, 撰写\n审查类：review, audit, check, 审查, 检查, 审核\n研究类：research, investigate, search, 调研, 搜索, 调查\n分析类：analyze, assess, evaluate, 分析, 评估\n编码类：code, implement, debug, 编码, 实现, 调试\n推理类：reason, infer, deduce, 推理, 推断\n模拟类：simulate, model, predict, 模拟, 建模, 预测\n评估类：score, rate, benchmark, 评分, 打分, 基准\n分类类：classify, categorize, sort, 分类, 归类\n排名类：rank, prioritize, 排序, 优先级\n```\n\n记录命中的关键词，传给 Pass 2 做深度抽取。\n\n### Step 1.5 — Boundary Definition\n\n明确 Skill 的边界——**不处理什么**：\n\n1. Prompt 中暗示但不应包含的场景\n2. 与其他 Skill 的职责划分\n3. 用户可能误用的方向\n\n### Step 1.6 — Hidden Assumptions\n\nPrompt 中隐含但未明说的前提：\n\n- 隐含的角色假设（\"你是专家\" → 需要领域知识）\n- 隐含的格式假设（\"输出报告\" → 需要模板）\n- 隐含的质量假设（\"高质量\" → 需要评分标准）\n\n### Step 1.7 — Unknowns\n\n需要向用户澄清的问题。**最多问 3 个**，只问能改变架构设计的：\n\n- 不确定的核心目标？\n- 不确定的使用频率（影响 archetype）？\n- 不确定的输出消费者（影响输出格式）？\n\n### Step 1.8 — Meta-Reflection Checkpoint（v2.1）\n\n在进入 Pass 2 之前，用以下 4 个维度二次审视刚才的分析结论。Quick 模式跳过此步。\n\n📍 完整框架见 [meta-reflection.md](meta-reflection.md)\n\n| 维度 | 自检问题 | 触发条件 |\n|------|---------|---------|\n| D1 问题定义 | `prompt_goal.actual` 是否比 `stated` 更深一层？有没有更好的问题表述？ | 总是 |\n| D2 假设 | `hidden_assumptions` 中是否有\"假设用户会正确使用\"？最脆弱的假设如果错了，哪些结论崩塌？ | hidden_assumptions 非空 |\n| D7 目标 | 是否为了降低 token 消耗而在牺牲 skill 的准确度？最终产出对用户真的可用吗？ | 总是 |\n| D8 不确定性 | `unknowns` 之外是否还有未记录的不确定点？如果只能向用户确认一件事，是什么？ | 总是 |\n\n**输出：** 将自省结果追加到 `unknowns`（如有新发现的不确定点）或写入 trace。不阻塞 Decision Gate。\n\n---\n\n## Output Schema\n\n```json\n{\n  \"prompt_summary\": \"一句话，不照搬原文\",\n  \"prompt_goal\": {\n    \"stated\": \"字面目标\",\n    \"actual\": \"真正需要的能力\"\n  },\n  \"input_spec\": {\n    \"type\": \"string | structured_content | file | api | mixed\",\n    \"description\": \"输入描述\",\n    \"inferred\": false\n  },\n  \"output_spec\": {\n    \"type\": \"string | json | file | report\",\n    \"description\": \"输出描述\",\n    \"inferred\": false\n  },\n  \"capability_hints\": [\"命中的能力关键词\"],\n  \"boundary\": {\n    \"in_scope\": [\"处理的场景\"],\n    \"out_of_scope\": [\"不处理的场景\"]\n  },\n  \"hidden_assumptions\": [\"隐含前提\"],\n  \"unknowns\": [\"需要澄清的问题（<= 3 个）\"]\n}\n```\n\n## Decision Gate\n\n| 条件 | 动作 |\n|------|------|\n| unknowns 为空 | → Pass 2 |\n| unknowns 非空 | 向用户提问，收到回答后更新 IR → Pass 2 |\n\nFile v1.2.2:references/pass-2-extract.md\n\n# Pass 2: Extract — 能力/知识/角色抽取\n\n**加载时机：** 📍 执行到 Pass 2 时加载。\n\n---\n\n## 三合一抽取\n\n原 16-phase 设计把 Capability Extraction、Knowledge Extraction、Role Extraction 拆成三步。但它们本质都是\"分析 Prompt 的组成要素\"，强关联且无独立决策门。合并为一次扫描，产出三个 IR 字段。\n\n---\n\n## Step 2.1 — Capability Graph 构建\n\n### 能力识别\n\n从 Pass 1 的 `capability_hints` 出发，构建能力依赖图：\n\n```\nPrimary Capability（核心能力，1-3 个）\n  ├── Sub-capability（子能力）\n  └── Supporting Capability（支撑能力）\n```\n\n### 能力分类参考\n\n| 类别 | 能力 |\n|------|------|\n| 认知 | Decision Making, Reasoning, Analysis, Prediction |\n| 创造 | Writing, Brainstorming, Coding, Mapping |\n| 评估 | Review, Evaluation, Scoring, Ranking, Classification |\n| 执行 | Planning, Workflow, Research, Knowledge Retrieval |\n| 交互 | Role Playing, Simulation |\n\n### Graph 构建规则\n\n1. **Primary** = Prompt 的核心功能对应的能力（1-3 个）\n2. **Secondary** = 支撑核心能力的能力\n3. **Graph edges** = 能力间的依赖关系（A 需要 B 先完成）\n\n---\n\n## Step 2.2 — Knowledge Inventory 提取\n\n扫描内容，逐句分类：\n\n| 知识类型 | 识别信号 | 去向 |\n|---------|---------|------|\n| **Rules** | \"必须\"、\"禁止\"、\"不要\"、\"always\"、\"never\" | `references/rules.md` |\n| **Templates** | 有结构化输出格式、固定 section | `templates/*.md` |\n| **Domain Knowledge** | 行业术语、专业概念、法规 | `references/domain-*.md` |\n| **Examples** | \"例如\"、\"示例\"、\"case\" | `examples/*.md` |\n| **Standards** | 评分标准、质量标准、验收标准 | `rubrics/*.md` |\n| **Roles** | \"你是...\"、\"作为...\"、persona 定义 | Pass 2.3 处理 |\n| **Processes** | 步骤、流程、phase | Pass 3 Design 处理 |\n| **Experience** | 经验法则、最佳实践、教训 | `references/best-practices.md` |\n\n### 并行提取（v2.0）\n\n当输入来自 Pass I 多源摄取，或内容较长（> 3000 字）时，启用并行提取器代替单线程扫描。五个专项提取器（框架/原则/案例/反例/术语）并行扫描，合并后经三重验证筛入知识库。\n\n📍 并行提取器与三重验证详见 [parallel-extractors.md](parallel-extractors.md)\n\n### 提取规则\n\n- **去重：** 相同规则出现多次，只保留一次\n- **去噪：** 过渡句、寒暄语不提取\n- **标注来源：** 每条知识标注 `[from source prompt]` 或 `[inferred by compiler]`\n\n### 证据分级标注（v2.0）\n\n每条提取的知识**必须携带 `evidence` 字段**，表示其可信度等级：\n\n| 等级 | 含义 | 典型场景 |\n|------|------|---------|\n| `primary` | 原文直引，可溯源 | PDF 文本层、字幕原文、代码注释 |\n| `secondary` | 经过一次模型转述 | OCR 结果、语音转写、视觉理解 |\n| `inferred` | 编译器从上下文推断 | 隐含假设、跨段推理 |\n\n默认值继承自 `pass_ingestion.evidence_grade`（若存在），但可逐条覆盖。\n\n📍 完整证据分级体系与 confidence 字段定义见 [evidence-grading.md](evidence-grading.md)\n\n### 冲突保留（v2.0）\n\n当多条知识描述同一事实但内容矛盾时，**不强行统一，保留所有版本**并记录到 IR 的 `conflicts` 字段。冲突处理策略（unresolved / prefer_higher_evidence / prefer_newer / flag_for_user）见 [evidence-grading.md](evidence-grading.md) 的\"冲突保留规则\"章节。\n\n**禁止：** 静默丢弃任一版本、强行取平均值、随机选择一方。\n\n---\n\n## Step 2.3 — Role Matrix 构建\n\n### 识别现有角色\n\n扫描 Prompt 中的 persona 定义：\n\n| 信号 | 示例 |\n|------|------|\n| 显式角色声明 | \"你是世界级 AI Skill Architect\" |\n| 隐式角色 | \"审查代码质量\"（隐含 Reviewer 角色） |\n| 多角色切换 | Prompt 中有多个\"你是...\" |\n\n### 角色分析\n\n对每个识别到的角色：\n\n| 字段 | 说明 |\n|------|------|\n| name | 角色名 |\n| responsibility | 职责描述 |\n| capabilities | 需要的能力（关联 Capability Graph） |\n| should_split | 是否应该拆分为独立 agent |\n| split_reason | 拆分理由（如果 should_split=true） |\n\n### 拆分判断\n\n| 条件 | should_split |\n|------|-------------|\n| 单一角色，职责清晰 | false |\n| 角色有 3+ 不相关职责 | true |\n| 角色同时负责\"产出\"和\"验证\" | true（干验分离原则） |\n| 角色需要不同的知识域 | true |\n\n### 建议新增角色\n\n分析 Prompt 缺失但 Skill 需要的角色：\n- 缺少 Verifier？（产出后需要独立验证）\n- 缺少 Router？（多种输入类型需要路由）\n- 缺少 Formatter？（需要统一输出格式）\n\n### Step 2.4 — Meta-Reflection Checkpoint（v2.1）\n\n在进入 Pass 3 之前，用证据维度审视知识提取质量。Quick 模式跳过此步。\n\n📍 完整框架见 [meta-reflection.md](meta-reflection.md)\n\n| 维度 | 自检问题 |\n|------|---------|\n| D4 证据 | 所有知识条目是否都携带 `evidence` 字段？inferred 条目占比是否 > 30%？是否存在\"公认事实\"其实只是推断的知识？ |\n\n**输出：** 如发现大量 inferred 条目缺少推断依据标注，补充标注后写入 IR。不阻塞 Decision Gate。\n\n---\n\n## Output Schema\n\n```json\n{\n  \"capability_graph\": {\n    \"primary\": [\"能力1\", \"能力2\"],\n    \"secondary\": [\"能力3\"],\n    \"graph\": {\n      \"能力1\": [\"子能力A\", \"子能力B\"],\n      \"能力2\": [\"子能力C\"]\n    }\n  },\n  \"knowledge_inventory\": {\n    \"rules\": [\n      { \"content\": \"规则内容\", \"source\": \"from source prompt | inferred\", \"target_file\": \"references/rules.md\" }\n    ],\n    \"templates\": [\n      { \"name\": \"模板名\", \"structure\": \"结构描述\", \"target_file\": \"templates/xxx.md\" }\n    ],\n    \"domain_knowledge\": [\n      { \"content\": \"知识内容\", \"domain\": \"领域\", \"target_file\": \"references/domain-xxx.md\" }\n    ],\n    \"examples\": [\n      { \"type\": \"minimal | normal | complex\", \"content\": \"示例内容\", \"target_file\": \"examples/xxx.md\" }\n    ],\n    \"standards\": [\n      { \"type\": \"scoring | quality | acceptance\", \"content\": \"标准内容\", \"target_file\": \"rubrics/xxx.md\" }\n    ],\n    \"best_practices\": [\n      { \"content\": \"实践内容\", \"target_file\": \"references/best-practices.md\" }\n    ]\n  },\n  \"role_matrix\": {\n    \"existing\": [\n      {\n        \"name\": \"角色名\",\n        \"responsibility\": \"职责\",\n        \"capabilities\": [\"关联能力\"],\n        \"should_split\": false,\n        \"split_reason\": \"\"\n      }\n    ],\n    \"to_add\": [\n      {\n        \"name\": \"建议角色名\",\n        \"reason\": \"为什么需要这个角色\",\n        \"responsibility\": \"职责\"\n      }\n    ]\n  }\n}\n```\n\n## Decision Gate\n\n| 条件 | 动作 |\n|------|------|\n| capability_graph.primary 非空 | → Pass 3 |\n| capability_graph 为空 | REJECT — Prompt 没有可提取的能力，不适合做 Skill |\n\nFile v1.2.2:references/pass-3-design.md\n\n# Pass 3: Design — Skill 架构设计\n\n**加载时机：** 📍 执行到 Pass 3 时加载。\n\n---\n\n## 设计原则\n\n**先设计系统，再设计 Prompt。绝不反过来。**\n\n原 16-phase 把 Workflow / References / Templates / Rubrics / Checklists / Config 拆成六步。但它们强关联——Workflow 决定需要什么 Checklist，Checklist 决定需要什么 Rubric。合并为一次架构设计。\n\n---\n\n## Step 3.1 — Architecture Type 决策\n\n| 条件 | architecture_type |\n|------|------------------|\n| 单次 LLM 调用，无状态 | `single-prompt` |\n| 多步骤顺序执行，有中间产出 | `workflow` |\n| 多角色并行或专业化 | `multi-agent` |\n\n### 决策树\n\n```\nPrompt 有多个步骤？\n  ├─ No → single-prompt\n  └─ Yes → 步骤间有并行或需要不同专业角色？\n            ├─ No → workflow\n            └─ Yes → multi-agent\n```\n\n---\n\n## Step 3.2 — Workflow Pattern 选择\n\n**仅 workflow / multi-agent 执行。** single-prompt 跳过。\n\n| 需求 | Pattern | 核心机制 |\n|------|---------|---------|\n| 输入类型多样，先判路再执行 | classify-and-act | 分类器路由 |\n| 多个独立子任务可并行 | fan-out-synthesize | 扇出+综合 |\n| 质量关键，需独立验证 | adversarial-verify | 对抗验证 |\n| 需要创意多样性，筛选最优 | generate-filter | 生成+过滤 |\n| 多方案成对比较选优 | tournament | 锦标赛 |\n| 需要迭代优化直到达标 | loop-until-done | 循环（上限3轮） |\n| 强制顺序，不能跳步 | pipeline | 管道+检查点 |\n\n可组合：如 classify-and-act 路由 → 每条路径内部用 pipeline。\n\n---\n\n## Step 3.3 — Single-Skill Pattern 选择\n\n**所有 Skill 必须选一个。** 与 workflow pattern 正交。\n\n| 需要什么？ | Pattern | 核心机制 |\n|------------|---------|---------|\n| 特定技术栈的专家知识 | tool-wrapper | SKILL.md 指向 references/ |\n| 一致的结构化输出 | generator | 模板 + 风格指南 |\n| 自动化代码/内容审查 | reviewer | 分离\"检查什么\"与\"怎么查\" |\n| 需求不明确，需先收集 | inversion | Agent 先采访用户 |\n| 复杂的多步骤任务 | pipeline | 强制顺序 + 检查点门控 |\n| 不确定？ | tool-wrapper | 最通用，可演进 |\n\n---\n\n## Step 3.4 — Module Decomposition\n\n基于 Pass 2 的 knowledge_inventory，决定模块拆分：\n\n| IR 字段 | 去向 | 拆分条件 |\n|---------|------|---------|\n| rules（> 5 条） | `references/rules.md` | 规则数 > 5 或总字数 > 200 |\n| rules（<= 5 条） | 内联 SKILL.md | 规则少且短 |\n| templates | `templates/*.md` | 有结构化输出 |\n| domain_knowledge | `references/domain-*.md` | 有领域知识 |\n| standards | `rubrics/*.md` | 有评分/质量标准 |\n| examples | `examples/*.md` | 有示例（或触发 Example Generation pass） |\n| honest-boundaries（v2.0） | `references/honest-boundaries.md` | **强制**：有 out_of_scope 或失败模式时必生成 |\n| conflicts（v2.0） | `references/conflicts.md` | Pass 2 检测到未裁决冲突时生成 |\n\n### 拆分原则\n\n1. **SKILL.md 最小化** — 只含路由 + 流程概览，< 300 行\n2. **知识外置** — 任何 > 200 字的知识块 → references/\n3. **配置参数化** — 可变的参数 → config/\n4. **模板独立** — 固定格式的输出 → templates/\n5. **诚实边界强制（v2.0）** — 每个 skill 必须规划 honest-boundaries 模块，即使初版为骨架。📍 详见 [honest-boundaries.md](honest-boundaries.md)\n\n---\n\n## Step 3.5 — Workflow Reconstruction\n\n**不要沿用 Prompt 顺序。** 以 Skill 为中心重新设计。\n\n### 每步定义\n\n| 字段 | 说明 |\n|------|------|\n| purpose | 这一步为什么存在 |\n| input | 输入是什么（来自上游或用户） |\n| output | 输出是什么（传给下游） |\n| decision_gate | 什么条件下继续/停止/重试 |\n| exit_criteria | 这一步完成的标志 |\n| retry_strategy | 失败时怎么办（最多 3 次） |\n| rollback_strategy | 无法完成时怎么办 |\n\n### Workflow 设计原则\n\n- **阶段化** — 每步有明确的进入/退出条件\n- **可恢复** — 任何一步失败不丢失上游产出\n- **可重试** — 失败后带反馈重试，有上限\n- **可扩展** — 新步骤可以插入，不破坏现有流程\n\n---\n\n## Step 3.6 — Reference Tree 设计\n\n规划 references/ 目录结构：\n\n```\nreferences/\n  ├── rules.md          # 规则集合\n  ├── domain-xxx.md     # 领域知识\n  ├── best-practices.md # 最佳实践\n  └── gotchas.md        # 常见陷阱（首次留骨架）\n```\n\n### 设计原则\n\n- 按主题分文件，不按 Prompt 顺序\n- 每个文件独立可读\n- 引用深度 = 1 层（SKILL.md → references/file.md，不嵌套）\n\n---\n\n## Step 3.7 — Checklist / Rubric / Config 设计\n\n### Checklist（检查清单）\n\n根据 architecture_type 生成：\n\n| 清单 | 内容 |\n|------|------|\n| Architecture Checklist | 模块边界、依赖方向、扩展点 |\n| Quality Checklist | 无 TODO、无 placeholder、< 300 行 |\n| Skill Checklist | frontmatter 合规、触发词、懒加载标记 |\n\n### Rubric（评分体系）\n\n当 Pass 2 有 standards 时生成。包含：\n\n| 组件 | 用途 |\n|------|------|\n| Scoring Rubric | 评分维度 + 权重 |\n| Risk Matrix | 风险等级矩阵 |\n| Priority Matrix | 优先级排序 |\n| Maturity Model | 成熟度分级 |\n\n### Config（配置）\n\n找出应该参数化的内容：\n\n```yaml\n# config/settings.yaml\nskill_name: string\nversion: string\nmax_iterations: 3  # 循环上限\noutput_format: markdown | json\n```\n\n---\n\n## Step 3.8 — Folder Structure 规划\n\n基于以上设计，输出目标目录树：\n\n```\nskill-name/\n  SKILL.md              # 入口 + 路由\n  references/           # 外置知识（按需加载）\n  workflows/            # 工作流定义（workflow/multi-agent）\n  templates/            # 输出模板\n  checklists/           # 检查清单\n  rubrics/              # 评分体系\n  config/               # 参数化配置\n  examples/             # 示例\n  schemas/              # JSON schema\n```\n\n**最小化原则：** 只创建需要的目录。single-prompt skill 不需要 workflows/。\n\n---\n\n## Step 3.9 — Self-Test Cases 派生\n\n**Pass 3 收尾必做。** 从 Pass 1 的 boundary 和 Pass 2 的 capability_graph 派生静态自测用例，供 Pass 6 Layer B/C 消费。\n\n**这是 IR 作为 test oracle 的关键步骤——不派生用例，Pass 6 就无 oracle 可用。**\n\n### 派生规则\n\n| 用例集 | 来源 | 说明 |\n|--------|------|------|\n| `positive` | `pass_1.boundary.in_scope` × `pass_2.capability_graph.primary` | 应触发 skill 的用户输入（组合场景 × 主能力） |\n| `negative` | `pass_1.boundary.out_of_scope` | 不应触发的用户输入（显式排除项） |\n| `near_miss` | `pass_2.capability_graph.secondary` − `pass_2.capability_graph.primary` | 语义近邻、容易误触发但不在主职责内的输入 |\n\n### 派生要求\n\n1. **positive 至少 3 条** — 覆盖主能力的典型用户表述\n2. **negative 至少 1 条** — 来自 boundary.out_of_scope（若为空，标注 `inferred: \"无显式排除项\"`）\n3. **near_miss 至少 0 条** — 若 secondary 为空则空数组（无近邻误触发风险）\n4. **用用户视角表述** — 写用户会怎么问，不写内部能力名（如\"帮我审一下这段 Python 代码\"而非\"调用 code-reviewer skill\"）\n\n### 示例\n\n```json\n{\n  \"self_test_cases\": {\n    \"positive\": [\n      \"审查这段 Python 代码的安全问题\",\n      \"检查这个函数有没有 bug\",\n      \"帮我 review 一下这个 PR\"\n    ],\n    \"negative\": [\n      \"帮我写一段 Python 代码\",\n      \"翻译这段技术文档\"\n    ],\n    \"near_miss\": [\n      \"审查这段 JavaScript 代码\"\n    ]\n  }\n}\n```\n\n### 派生完成后\n\n`self_test_cases` 写入 IR 的 `pass_3_design.self_test_cases`。Pass 6 Layer B/C 直接读取此字段，无需重新生成用例。\n\n---\n\n## Step 3.10 — Skill Interlinking（v2.0 可选）\n\n**仅当一次编译产出多个相关 skill 时执行**（如从一份长文档蒸馏出多个方法论 skill）。单 skill 编译跳过此步。\n\n当输出包含多个 skill 模块时，规划它们之间的关系图谱，生成 `INDEX.md` 作为技能地图：\n\n### 关系类型\n\n| 关系 | 含义 | 示例 |\n|------|------|------|\n| `depends_on` | A 的执行依赖 B 先完成 | \"代码审查\" depends_on \"静态分析\" |\n| `complements` | A 与 B 互补，组合使用效果更好 | \"PEP8 检查\" complements \"安全审计\" |\n| `contradicts` | A 与 B 在某些场景给出冲突建议 | 记录冲突，指向 conflicts.md |\n| `alternative` | A 与 B 是同一问题的不同方案 | 标注各自适用场景 |\n\n### INDEX.md 模板\n\n```markdown\n# Skill Index — 技能地图\n\n## 包含的 Skills\n| Skill | 职责 | 触发场景 |\n|-------|------|---------|\n| {name} | {一句话} | {when} |\n\n## 关系图\n- {SkillA} → depends_on → {SkillB}\n- {SkillC} → complements → {SkillD}\n\n## 推荐组合\n{哪些 skill 适合串联使用}\n```\n\n### 设计原则\n\n- INDEX.md 是**可选输出**，只在多 skill 产出时生成\n- 关系图帮助用户理解 skill 间的协作方式，而非孤立使用\n- `contradicts` 关系必须指向 `references/conflicts.md` 的具体条目\n\n### Step 3.11 — Meta-Reflection Checkpoint（v2.1）\n\n在设计产出 IR 之前，用以下 3 个维度二次审视设计决策。Quick 模式跳过此步。\n\n📍 完整框架见 [meta-reflection.md](meta-reflection.md)\n\n| 维度 | 自检问题 | 触发条件 |\n|------|---------|---------|\n| D3 推理 | architecture_type 的决策链是否有跳跃？模块拆分标准是否前后一致？ | 总是 |\n| D5 替代解释 | 是否考虑过至少 1 个替代架构并给出诚实的淘汰理由？替代方案的优势是否被如实评估？ | architecture_type 非 single-prompt |\n| D6 边界条件 | out_of_scope 条目是否足够具体？当前设计在输入为空/极长/格式退化时是否仍适用？ | 总是 |\n\n**输出：** 自省结果写入 trace。如果发现设计漏洞，在进入 Pass 4 前修正 IR。\n\n---\n\n## Output Schema\n\n```json\n{\n  \"architecture_type\": \"single-prompt | workflow | multi-agent\",\n  \"workflow_pattern\": \"pattern name | null\",\n  \"single_skill_pattern\": \"tool-wrapper | generator | reviewer | inversion | pipeline\",\n  \"self_test_cases\": {\n    \"positive\": [\"应触发的用户输入\"],\n    \"negative\": [\"不应触发的用户输入\"],\n    \"near_miss\": [\"易误触发的近邻输入\"]\n  },\n  \"module_decomposition\": {\n    \"core_prompt\": \"SKILL.md 核心职责描述\",\n    \"workflows\": [\"workflow 文件列表\"],\n    \"references\": [\"reference 文件列表 + 内容概述\"],\n    \"checklists\": [\"checklist 列表\"],\n    \"rubrics\": [\"rubric 列表\"],\n    \"templates\": [\"template 列表\"],\n    \"configs\": [\"config 参数列表\"]\n  },\n  \"workflow_steps\": [\n    {\n      \"id\": \"step-1\",\n      \"purpose\": \"为什么存在\",\n      \"input\": \"输入\",\n      \"output\": \"输出\",\n      \"decision_gate\": \"继续条件\",\n      \"exit_criteria\": \"完成标志\",\n      \"retry_strategy\": \"重试策略\",\n      \"rollback_strategy\": \"回滚策略\"\n    }\n  ],\n  \"reference_tree\": [\"references/xxx.md\"],\n  \"folder_structure\": \"目录树字符串\"\n}\n```\n\n## IR 合并\n\nPass 3 完成后，将 pass_1_analyze、pass_2_extract、pass_3_design 三个字段合并为完整 Skill IR。合并后必须通过 schema 校验才能进入 Pass 4。\n\n## Decision Gate\n\n| 条件 | 动作 |\n|------|------|\n| architecture_type 确定 + folder_structure 非空 + IR 通过 schema 校验 | → Pass 4 |\n| IR 校验失败（字段缺失/类型错误） | 修复 IR 缺失字段后重新校验 |\n| 无法确定 architecture_type | 向用户澄清使用场景 |\n\n### IR 校验\n\n📍 IR schema 定义见 [schemas/ir-schema.json](../schemas/ir-schema.json)\n\nPass 3→4 门控时，对合并后的 IR 执行以下校验：\n\n| # | 校验项 | FAIL 处理 |\n|---|--------|----------|\n| 1 | `meta`、`pass_1_analyze`、`pass_2_extract`、`pass_3_design` 四个顶层字段齐全 | 补齐缺失 Pass 的 IR |\n| 2 | `pass_2_extract.capability_graph.primary` 非空（≥1 个） | 回退 Pass 2 补充能力图谱 |\n| 3 | `pass_3_design.architecture_type` 为 single-prompt / workflow / multi-agent 之一 | 回退 Pass 3 确定架构类型 |\n| 4 | `pass_3_design.single_skill_pattern` 已选择 | 回退 Pass 3 选择 single-skill pattern |\n| 5 | `pass_3_design.folder_structure` 非空 | 回退 Pass 3 规划目录结构 |\n| 6 | `pass_3_design.self_test_cases.positive` ≥ 3 条 | 回退 Pass 3 Step 3.9 补充 positive 用例 |\n| 7 | `pass_3_design.self_test_cases.negative` ≥ 1 条（或标注 inferred） | 回退 Pass 3 Step 3.9 补充 negative 用例 |\n\n全部 PASS → 进入 Pass 4。\n\nFile v1.2.2:references/pass-4-generate.md\n\n# Pass 4: Generate — 生成 Skill 包\n\n**加载时机：** 📍 执行到 Pass 4 时加载。\n\n---\n\n## 生成原则\n\n1. **IR 驱动** — 所有文件内容来自 Pass 1-3 的 IR，不凭空创造\n2. **三层加载** — L1 frontmatter / L2 SKILL.md 路由 / L3 references 懒加载\n3. **平台感知渲染** — frontmatter、description、文件结构按 `target_platform` 对应的 profile 规范渲染\n4. **frontmatter 卫生** — 只含目标平台要求的字段（generic/trae 仅 name + description）\n5. **无占位符** — 不留 TODO/TBD/placeholder\n6. **文件最小化** — 只生成 IR 要求的文件，不多创建\n\n---\n\n## Step 4.1 — SKILL.md 生成\n\n### Step 4.0 — 加载目标平台 Profile\n\n读取 `meta.target_platform` 并加载对应 profile：\n\n| target_platform | Profile 文件 |\n|----------------|-------------|\n| `trae`         | 📍 [profiles/trae.md](../profiles/trae.md) |\n| `claude`       | 📍 [profiles/claude.md](../profiles/claude.md) |\n| `generic`      | 📍 [profiles/generic.md](../profiles/generic.md) |\n\n后续渲染步骤全部参考 profile 中定义的约束（description 格式、触发词策略、文件结构支持列表）。\n\n### Frontmatter — 按平台渲染\n\n#### TRAE 平台\n\n```yaml\n---\nname: {kebab-case-name}\ndescription: \"Use when {触发场景}. Triggers on: {触发词1}, {触发词2}, {触发词3}. {核心功能一句话}\"\n---\n```\n\n**约束：**\n- description 必须为**严格单行 YAML 字符串**，不支持多行 block scalar\n- ≤ 500 字符\n- 触发词用「逗号 + 空格」分隔\n- 不包含 `version` 等额外 frontmatter 字段\n\n#### Claude 平台\n\n```yaml\n---\nname: {kebab-case-name}\ndescription: >\n  Use when {触发场景}.\n\n  Triggers on:\n  - {触发词1}\n  - {触发词2}\n  - {触发词3}\n\n  {核心功能一句话描述}\nversion: 1.0.0\n---\n```\n\n**约束：**\n- description 支持多行 block scalar（`>` 或 `|`）\n- ≤ 500 字符\n- 触发词支持列表格式（每行一个）\n- 可包含 `version` 等额外字段\n\n#### Generic 平台（默认）\n\n```yaml\n---\nname: {kebab-case-name}\ndescription: \"Use when {触发场景}. Triggers on: {触发词1}, {触发词2}, {触发词3}. {核心功能一句话}\"\n---\n```\n\n**约束：**\n- description 严格单行（兼容所有 YAML 解析器）\n- ≤ 300 字符（最严格限制）\n- frontmatter 只保留 name + description\n\n---\n\n**description 通用规则（所有平台）：**\n- 以 \"Use when\" / \"Use for\" 开头\n- 包含 3+ 用户可能输入的触发词\n- 聚焦用户意图，不描述内部机制\n\n### Body 结构\n\n```markdown\n# {Skill Name}\n\n{一句话定位}\n\n## 核心流程\n{3-5 步流程概览，每步一句话}\n\n## 执行步骤\n### Step 1 — {名称}\n📍 加载文件: references/xxx.md\n{简要说明 + 输入输出}\n\n### Step 2 — {名称}\n...\n\n## 输出格式\n{输出 schema 或模板引用}\n\n## Gotchas\n{常见陷阱，首次留骨架}\n```\n\n### 行数控制\n\n- **< 150 行：** 理想\n- **150-300 行：** 可接受\n- **> 300 行：** 必须拆分（AP-02 Prompt Black Hole）\n\n### 平台感知的文件结构约束\n\n生成 `references/` 和可能的工作流/agent 目录时，参考目标平台的 profile：\n\n| 目录 | generic | trae | claude |\n|------|---------|------|--------|\n| `references/` | ✅ | ✅ | ✅ |\n| `templates/` | ✅ | ✅ (放 references/ 更安全) | ✅ |\n| `workflows/` | ❌ | ❌ | ✅ |\n| `agents/` | ❌ | ❌ | ✅ |\n| `rubrics/` | ❌ | 放 references/ 内 | ✅ |\n| `checklists/` | ❌ | 放 references/ 内 | ✅ |\n\n**规则：** 不生成目标平台不支持的目录。必须生成的 reference 文件全部放在 `references/` 或模板所在平台允许的位置。\n\n---\n\n## Step 4.2 — References 生成\n\n对 Pass 3 的 `reference_tree` 中每个文件：\n\n### rules.md 模板\n\n```markdown\n# Rules\n\n{从 knowledge_inventory.rules 逐条列出}\n\n## 规则列表\n\n| # | 规则 | 来源 |\n|---|------|------|\n| 1 | {规则内容} | source / inferred |\n```\n\n### domain-xxx.md 模板\n\n```markdown\n# {Domain} Knowledge\n\n## {Topic 1}\n{知识内容}\n\n## {Topic 2}\n{知识内容}\n```\n\n### best-practices.md 模板\n\n```markdown\n# Best Practices\n\n## {Practice 1}\n{内容 + 为什么}\n\n## {Practice 2}\n{内容 + 为什么}\n```\n\n### gotchas.md 模板（首次骨架）\n\n```markdown\n# Gotchas / Footguns\n\n> 上线后根据实际 failure case 填充。\n\n## 常见失败点\n- TODO: {占位 — 替换为实际失败模式}\n\n## 字段/命名歧义\n- TODO: {占位}\n\n## 边界条件\n- TODO: {占位}\n```\n\n---\n\n## Step 4.3 — Workflows 生成（workflow/multi-agent only）\n\n对 Pass 3 的 `workflow_steps` 生成 YAML：\n\n```yaml\nname: {skill-name}-{workflow-name}\ndescription: {工作流描述}\n\ninput:\n  type: object\n  required: [{必需字段}]\n  properties:\n    {field}: { type: string }\n\nsteps:\n  - id: {step-id}\n    agent: {agent-name}\n    description: {步骤描述}\n    input:\n      {field}: \"{{input.xxx}}\"\n    output: {output-var}\n    when: [{条件表达式，可选}]\n```\n\n---\n\n## Step 4.4 — Templates 生成\n\n对 Pass 3 的 `module_decomposition.templates`：\n\n```markdown\n# {Template Name}\n\n## 变量\n| 变量 | 说明 | 必填 |\n|------|------|------|\n| {var} | {描述} | yes/no |\n\n## 模板\n---\n{模板内容，用 {{var}} 标记变量}\n---\n```\n\n---\n\n## Step 4.5 — Checklists 生成\n\n```markdown\n# {Checklist Name}\n\n## 检查项\n\n| # | 检查项 | 如何检查 | PASS 标准 |\n|---|--------|---------|-----------|\n| 1 | {检查内容} | {方法} | {标准} |\n```\n\n---\n\n## Step 4.6 — Rubrics 生成（当有 standards 时）\n\n```markdown\n# {Rubric Name}\n\n## 评分维度\n\n| 维度 | 权重 | 评分标准 |\n|------|------|---------|\n| {维度} | {X}% | {1-5 分的描述} |\n\n## 风险矩阵\n| 风险 | 概率 | 影响 | 等级 |\n|------|------|------|------|\n\n## 成熟度模型\n| 级别 | 特征 |\n|------|------|\n| L1 | {描述} |\n| L2 | {描述} |\n| L3 | {描述} |\n```\n\n---\n\n## Step 4.7 — Config 生成（当有参数化时）\n\n```yaml\n# config/settings.yaml\nskill_name: {name}\nversion: 1.0.0\n{参数}: {默认值}\n```\n\n---\n\n## Step 4.8 — Schemas 生成（当有结构化输出时）\n\n```json\n{\n  \"$schema\": \"http://json-schema.org/draft-07/schema#\",\n  \"title\": \"{Skill} Output\",\n  \"type\": \"object\",\n  \"required\": [\"field1\"],\n  \"properties\": {\n    \"field1\": { \"type\": \"string\", \"description\": \"...\" }\n  }\n}\n```\n\n---\n\n## Step 4.9 — Self-Check（生成后立即执行）\n\n| # | 检查项 | FAIL 处理 |\n|---|--------|----------|\n| 1 | frontmatter 符合目标平台 profile 规范 | 按 profile 重写 |\n| 2 | description 触发导向（Use when + 3+ 触发词） | 重写 description |\n| 3 | SKILL.md < 300 行 | 拆分到 references |\n| 4 | 所有 📍 标记的文件存在 | 创建缺失文件 |\n| 5 | 无 TODO/TBD/placeholder（gotchas.md 骨架除外） | 填充或移除 |\n| 6 | 每个文件被至少一个其他文件引用 | 移除孤立文件或添加引用 |\n| 7 | 未生成目标平台不支持的目录 | 移入 references/ |\n| 8 | 已设置 `meta.platform_profile_applied = true` | 设置标记 |\n\n任一 FAIL → 修复后重新检查，全部 PASS → 进入 Pass 5/6。\n\nArchive v1.2.1: 23 files, 68267 bytes\n\nFiles: profiles/claude.md (2694b), profiles/generic.md (2417b), profiles/trae.md (2783b), references/anti-patterns.md (2498b), references/evidence-grading.md (6419b), references/example-generation.md (1283b), references/honest-boundaries.md (5099b), references/meta-reflection.md (8544b), references/parallel-extractors.md (8971b), references/pass-1-analyze.md (4820b), references/pass-2-extract.md (6951b), references/pass-3-design.md (12798b), references/pass-4-generate.md (7107b), references/pass-5-optimize.md (4743b), references/pass-6-validate.md (16498b), references/pass-ingestion.md (13228b), references/plugin-discovery.md (1377b), schemas/ir-schema.json (16440b), skill-card.md (2625b), SKILL.md (13891b), templates/ir-schema.md (5293b), templates/skill-md-template.md (1615b), _meta.json (132b)\n\nFile v1.2.1:SKILL.md\n\n---\nname: skill-compiler\ndescription: \"Use when you need to compile any prompt OR multi-source content (PDF/video/URL/image/doc) into a production-grade, reusable AI Skill. Triggers on: 'prompt to skill', 'compile prompt', '把 prompt 变成 skill', '提示词编译', 'PDF转skill', '视频转skill', '网页转skill', 'skill from prompt', 'skill from document'. Outputs a complete skill package with evidence grading, honest boundaries, and modular architecture. Not for: prompt wording optimization, one-shot Q&A, translation, or authoring skills from scratch.\"\nversion: 2.0.0\n---\n\n# Skill Compiler\n\n**任意来源 → Skill IR → Optimized Skill Package**\n\n你不是 Prompt Engineer。你是一位 AI Skill Architect + Compiler Engineer。你的任务不是优化 Prompt，而是把任意来源（文本 Prompt、PDF、视频、网页、图片、文档）**编译** 成一个可复用、可维护、可扩展、可持续演化的 AI Skill。\n\n---\n\n## Optimization Goals\n\n整个编译过程中持续优化，而非机械转换。对每个设计决策回答：能否降低 Prompt 长度 / 提高复用性 / 模块化 / 参数化 / 插件化 / 拆分 Reference / 减少重复 / 提高可维护性 / 支持多 Agent / 支持版本演进？答案为\"是\"时自动重构。\n\n---\n\n## Core Principles\n\n| # | 原则 | 含义 |\n|---|------|------|\n| P1 | Prompt 不是 Skill | Skill = Role + Workflow + Knowledge + Decision Logic + Checklist + Rubric + Templates + Examples + Config + References + Output Schema |\n| P2 | 重复内容外置 | 超过一次使用的内容 → `references/` |\n| P3 | Prompt 最小化 | 知识外置，Workflow 独立，配置参数化 |\n| P4 | 不照搬 Prompt | 以 Skill 为中心重新设计，保留\"能力\"而非\"文字\" |\n| P5 | 元反思审计 | 在关键决策后自省：问题定义 / 假设 / 推理 / 证据 / 替代解释 / 边界 / 目标 / 不确定性 — 8 维度二次审视 |\n\n📍 [references/meta-reflection.md](references/meta-reflection.md)\n\n---\n\n## Compiler Pipeline\n\n```\nSource (Prompt / PDF / Video / URL / Image / Doc)\n  → [Pass I: Ingestion?] → [Pass 0: Triage] → [Pass 1: Analyze] → [Pass 2: Extract]\n  → [Pass 3: Design] → [Pass 4: Generate] → [Pass 5: Optimize?]\n  → [Pass 6: Validate] → Skill Package\n```\n\n| Pass | 执行 | 职责 | 详情 |\n|------|------|------|------|\n| **I Ingestion** | ⚠️ 条件 | 多源摄取：PDF/视频/网页/图片/文档 → 标准化结构化内容 + 来源溯源 | 📍 [references/pass-ingestion.md](references/pass-ingestion.md) |\n| **0 Triage** | ✅ 总是 | 判断是否值得编译 | 内联（决策表见下） |\n| **1 Analyze** | ✅ 总是 | 理解内容：目标/输入输出/边界/假设 | 📍 [references/pass-1-analyze.md](references/pass-1-analyze.md) |\n| **2 Extract** | ✅ 总是 | 能力图谱 + 知识清单（含证据分级）+ 角色矩阵 | 📍 [references/pass-2-extract.md](references/pass-2-extract.md) |\n| **3 Design** | ✅ 总是 | 架构类型 + 模块拆分（含诚实边界）+ Workflow + 目录结构 + 自测用例 + Skill 链接图 | 📍 [references/pass-3-design.md](references/pass-3-design.md) |\n| **4 Generate** | ✅ 总是 | 生成完整 Skill 文件包 | 📍 [references/pass-4-generate.md](references/pass-4-generate.md) |\n| **5 Optimize** | ⚠️ 条件 | 内容 > 500字 / 重复 / multi-agent 时执行 | 📍 [references/pass-5-optimize.md](references/pass-5-optimize.md) |\n| **6 Validate** | ✅ 总是 | 四层评估：结构完整性（A）+ IR 一致性（B）+ 触发质量（C，含压力测试）+ 平台合规（D） | 📍 [references/pass-6-validate.md](references/pass-6-validate.md) |\n\n**条件 Pass：**\n\n| Pass | 触发条件 | 详情 |\n|------|---------|------|\n| Plugin Discovery | Prompt 涉及外部能力（搜索/GitHub/DB/浏览器/MCP） | 📍 [references/plugin-discovery.md](references/plugin-discovery.md) |\n| Example Generation | Skill 涉及复杂流程/规则/评分体系 | 📍 [references/example-generation.md](references/example-generation.md) |\n\n**v2.0 核心知识资源（被各 Pass 按需引用）：**\n\n| 资源 | 职责 | 引用方 |\n|------|------|--------|\n| Evidence Grading | 三级证据体系（primary/secondary/inferred）+ 冲突保留 | Pass 2, Pass 6 Layer B |\n| Honest Boundaries | 诚实边界规范（局限性/失败模式/适用前提） | Pass 3, Pass 6 Layer A |\n| Parallel Extractors | 五并行提取器 + 三重验证 | Pass 2（多源/长内容时） |\n| Meta Reflection | 8 维度编译自省框架（问题/假设/推理/证据/替代/边界/目标/不确定性） | Pass 1, Pass 2, Pass 3, Pass 6 Decision Gates |\n\n📍 [references/evidence-grading.md](references/evidence-grading.md) · [references/honest-boundaries.md](references/honest-boundaries.md) · [references/parallel-extractors.md](references/parallel-extractors.md) · [references/meta-reflection.md](references/meta-reflection.md)\n\n---\n\n## Pass 0 — Triage（内联决策）\n\n**输入：** 若 Pass I Ingestion 执行过，此处输入为其产出的 `structured_content`（已标准化的多源内容）。否则为用户原始 Prompt。\n\n### Step 0.1 — 判断输入是否值得编译\n\n| 输入类型 | 判定 | Action |\n|---------|------|--------|\n| 一次性问答，无复用价值 | 不是 Skill | REJECT — 直接回答 |\n| 纯翻译/摘要/解释 | 不是 Skill | REJECT — 直接执行 |\n| 会反复使用 + 有可复用输出契约 | 是 Skill | → Step 0.2 |\n| 容易路由错误的复杂工作流 | 是 Skill | → Step 0.2 |\n\nREJECT 时告知\"这不建议做成 skill，因为 X\"，并直接完成请求。\n\n### Step 0.2 — 确定目标平台\n\n选择生成的 Skill 将在哪个平台运行。平台选择影响 frontmatter 格式、description 渲染风格、触发词策略和文件结构约束。\n\n| 平台 | 适用场景 | 特性 |\n|------|---------|------|\n| `trae` | TRAE IDE Skill | description 单行、触发词关键词匹配、references/ 懒加载 |\n| `claude` | Claude.ai / Claude Code | description 可多行、语义匹配、agents/ 目录支持 |\n| `generic` | 未知平台/未来平台 | 最保守的规范，最大兼容性 |\n\n**用户未指定时**，默认为 `generic`。高级用户可在编译过程中的 `unknowns` 阶段被询问。\n\n📍 平台规范文件: [profiles/trae.md](profiles/trae.md), [profiles/claude.md](profiles/claude.md), [profiles/generic.md](profiles/generic.md)\n\n### Step 0.3 — 选择编译模式\n\n根据源 Prompt 的复杂度和用户对成本/质量的权衡选择模式：\n\n| 模式 | Token 开销 | 执行 Pass | 适用场景 |\n|------|-----------|-----------|---------|\n| `quick` | 低（~3 次调用） | 0 → 1 → 3(轻) → 4 → 6(A层) | Prompt < 200 字，已熟悉 Skill 结构 |\n| `full` | 高（~6+ 次调用） | 0 → 1 → 2 → 3 → 4 → 5?(条件) → 6(全部三层) | Prompt 复杂，需要完整能力提取与验证 |\n| `audit` | 中（~2 次调用） | 6(全部四层) | 评估已有 Skill，不生成新文件 |\n\n**默认模式：** `full`。Token 敏感时建议手动选 `quick`。\n\n### Step 0.4 — 设定 Token 预算（可选）\n\n用户可设定本次编译的 token 总预算上限：\n\n- `total_budget` — 硬上限。0 表示无限制（默认）\n- `mode_change_at_pct` — 消耗达到预算 N% 时自动降级模式（默认 80%）\n- 超预算时编译器自动降级（`full` → `quick`）并记录到 trace\n\n**未设定预算时**，使用模式默认的调用次数估算。\n\n### Step 0.5 — 写入 IR\n\n```\nmeta.target_platform       = 用户选择或默认\nmeta.compilation_mode      = 用户选择或默认\nmeta.token_budget          = 用户设定或默认值\n```\n\n---\n\n## Execution Rules\n\n1. **Pass I Ingestion 优先（v2.0）** — 若输入为 URL/文件/图片/视频等非纯文本，先执行 Ingestion 标准化为结构化内容 + 来源溯源，再进 Pass 0。纯文本 Prompt 时跳过 Ingestion。\n2. **Pass 1-3 产出 Skill IR**（中间表示），不生成文件。📍 IR schema 见 [templates/ir-schema.md](templates/ir-schema.md)\n3. **Pass 4 基于 IR + 目标平台 profile 生成文件。** 按平台规范渲染 frontmatter、description 和文件结构。📍 生成模板见 [templates/skill-md-template.md](templates/skill-md-template.md)\n4. **每个 Pass 通过 IR 通信**，不直接传递未结构化文本\n5. **Decision Gate：** 每个 Pass 末尾有通过条件（详见各 pass 文件），不满足时向用户澄清\n6. **条件 Pass 由编译器自主判断**，不强制执行全部\n7. **平台 profile 应用时机：** Pass 4 生成时同时加载目标 platform profile，按 profile 规范渲染输出。Pass 6 Layer D 反向验证。\n8. **Token 估计门槛：** 每次 Pass 完成后在 IR 中更新 `token_budget.current_estimate`。若 `current_estimate > total_budget × mode_change_at_pct / 100`，自动降级编译模式。\n9. **诚实边界强制（v2.0）** — 生成的 skill 必须包含 honest-boundaries 声明。Pass 3 规划模块，Pass 6 Layer A 验证存在性。\n10. **证据可溯源（v2.0）** — 多源输入时，每条知识携带 evidence 等级。Pass 2 标注，Pass 6 Layer B 验证完整性。冲突不静默丢弃。\n11. **元反思自省（v2.1）** — 关键 Pass（1/2/3/6）Decision Gate 处执行 8 维度自检。Quick 模式跳过。自省结果写入 trace，不阻塞编译流程。📍 [references/meta-reflection.md](references/meta-reflection.md)\n\n---\n\n## Final Output\n\n编译完成后输出 Compilation Report：\n\n- **Skill Summary** — 名称 + 一句话描述\n- **Folder Tree** — 生成的目录结构\n- **Passes Executed** — 实际执行的 Pass 列表\n- **Module Dependency Graph** — 核心模块依赖关系\n- **Evaluation Report** — Pass 6 四层评估结果：\n  - Layer A 结构完整性 pass_rate\n  - Layer B IR 一致性 pass_rate（IR 作为 test oracle 验证产出）\n  - Layer C 触发质量 trigger_precision（self_test_cases 静态匹配）\n  - Layer D 平台合规 pass_rate（按 target platform profile 验证）\n  - 综合评分 `skill_quality_score`（0-100，含 Layer D）\n- **Cost Summary** — 编译成本汇总：\n  - 总 token 消耗（输入 + 输出）\n  - 执行的 Pass 列表 / 跳过的 Pass 列表\n  - Token 预算消费百分比（如设定了预算）\n- **Validation Result** — Pass 6 verdict + issues\n- **Technical Debt** — 已知技术债务\n- **Extension Roadmap** — 未来可扩展方向\n\n---\n\n## Gotchas / Footguns\n\n> 以下为已知的编译失败模式和风险点。\n\n1. **AP-11 风险（单轨迹过拟合）** — 不要基于单次编译经验调整哪些 Pass 该执行/跳过。Pass 的触发/跳过条件应基于显式规则（本 SKILL.md 定义的条件），而非\"上次编译时我跳过了这个 Pass 所以这次也跳\"。批量编译经验归纳后才可调整 Pass 触发策略。\n2. **IR 字段缺失是最常见的失败原因** — LLM 产出 IR 时常遗漏 `capability_graph.primary` 或 `folder_structure`。Pass 3→4 门控必须校验全部必填字段（见 [schemas/ir-schema.json](schemas/ir-schema.json)），缺失时回退而非硬闯 Pass 4。\n3. **Pass 5 条件判断不能只看输入长度** — 即使 Source Prompt < 500 字，生成的文件包中也可能出现重复知识（>= 3 处相同内容）。Pass 5 的触发条件应同时检查\"输入长度\"和\"输出重复度\"。\n4. **trace 产出不能省略** — trace-schema.json 定义的执行 trace 是下游消费者（如 SkillForge L4/L5）的契约输入。每次编译必须在 Final Output 中产出 trace。\n5. **平台 profile 必须显式指定才生效** — 默认 `generic` profile 生成最保守的输出。若要利用特定平台特性（如 TRAE 的触发词策略、Claude 的多行 description），需在 Pass 0 显式选择目标平台。先编译后改 description 会丢失 Pass 6 Layer D 的验证闭环。\n6. **Token 预算不能设得过于紧张** — `quick` 模式 ≈ 3 次 LLM 调用。如果 `total_budget` 设得低于 3 次调用的估算量，编译器可能在 Pass 0 就触发降级，实际执行与预期不符。建议 `quick` 预算 ≥ 5K tokens，`full` 预算 ≥ 15K tokens（估算值，因模型而异）。\n7. **不同平台间迁移需要重新编译** — 同一个 prompt 编译为 TRAE 和 Claude 的 skill 是两个不同的输出。平台 profile 不同，frontmatter、description 格式、触发词策略、文件结构都可能不同。直接复制文件到另一个平台大概率不可用。\n8. **Ingestion 不做内容理解（v2.0）** — Pass I 只负责\"格式转换 + 来源标注\"，不提取能力边界或知识。越界做内容理解会导致 IR 过早膨胀，且与 Pass 1/2 职责重叠。\n9. **OCR/转写结果必须保留置信度（v2.0）** — Ingestion 阶段的提取置信度是 Pass 2 证据分级（primary/secondary/inferred）的判定依据。丢弃置信度等于丢弃证据等级的根基。\n10. **冲突不要在编译过程中静默消除（v2.0）** — 多源输入时，不同来源对同一事实的矛盾表述必须保留并标注（写入 conflicts.md）。强行统一会丢失真实信号，让用户误以为 skill 比实际更可靠。\n11. **Pass I 外部命令执行需遵守安全边界（v2.0）** — Ingestion 涉及在用户提供的文件/URL 上执行 pdftotext/ffmpeg/tesseract/git clone 等命令。用户输入的路径和 URL 必须视为不可信输入，遵守路径限制、不拼接 shell、不执行嵌入代码等约束。📍 详见 [references/pass-ingestion.md](references/pass-ingestion.md) 的 Security Boundaries 章节。\n\n---\n\n## Provenance\n\n- **Built with:** SkillForge (Full mode)\n- **Source:** User-provided \"Prompt → Skill Compiler v1.0\" spec, refactored from 16 fixed phases to 6 core + 3 conditional compiler passes\n- **Design decision:** Phase → Compiler Pass model (conditional execution, IR-based)\n\nFile v1.2.1:_meta.json\n\n{\n  \"ownerId\": \"kn72r3ww47r1qyfaf233sf7q1982rh5f\",\n  \"slug\": \"skillcompiler\",\n  \"version\": \"1.2.1\",\n  \"publishedAt\": 1783657944397\n}\n\nFile v1.2.1:references/anti-patterns.md\n\n# Anti-Patterns — Skill 设计反模式\n\n**加载时机：** 📍 Pass 5 Optimize 执行 O1-O8 检查时加载。\n\n> 本文件定义 Skill Compiler 优化阶段（Pass 5）引用的反模式编号。\n> 完整 13 反模式库见 SkillForge [rubrics/anti-patterns.md](../../skillforge/rubrics/anti-patterns.md)。\n\n---\n\n## AP-02: Prompt Black Hole（Prompt 黑洞）\n\n**症状：** 把所有逻辑、规则、领域知识塞进一个巨大的 SKILL.md。token 爆炸，模型注意力分散。\n\n| 维度 | 详情 |\n|------|------|\n| 检测方法 | SKILL.md 超过 300 行 |\n| 修正 | 拆分为多 agent 或 reference 文件，SKILL.md 只做路由 manifest |\n| 严重度 | 🟠 High |\n| Pass 5 检查项 | O1（Prompt 长度优化） |\n\n## AP-04: Verification Theater（验证表演）\n\n**症状：** 声称有质量验证，但验证者和产出者是同一个 agent（或同一段 prompt）。\n\n| 维度 | 详情 |\n|------|------|\n| 检测方法 | 检查 verifier 是否独立于 producer |\n| 修正 | 使用独立的 Verifier Agent（干验分离原则） |\n| 严重度 | 🟠 High |\n| Pass 5 检查项 | O6（拆分检查） |\n\n## AP-06: Infinite Loop Without Guard（无界循环）\n\n**症状：** 工作流中有循环/迭代逻辑，但没有设置最大轮次上限。\n\n| 维度 | 详情 |\n|------|------|\n| 检测方法 | 检查 loop/feedback 步骤是否有 max_iterations |\n| 修正 | 设置硬性上限（推荐最多 3 轮） |\n| 严重度 | 🟠 High |\n| Pass 5 检查项 | O6（拆分检查） |\n\n## AP-07: God Agent（上帝 Agent）\n\n**症状：** 单个 agent 负责太多职责，prompt 中有 5+ 个不相关的\"功能\"。\n\n| 维度 | 详情 |\n|------|------|\n| 检测方法 | 读 agent 的 Capabilities/功能列表，检查是否有 >= 5 个不相关功能 |\n| 修正 | 按职责拆分为多个 agent，每个 agent 只负责一件事 |\n| 严重度 | 🟠 High |\n| Pass 5 检查项 | O5（模块化检查） |\n\n## AP-12: Trust-Domain Conflation（信任域混淆）\n\n**症状：** 同一逻辑概念被同一个文件承载，但该文件同时被\"隔离验证者\"和\"知情决策者\"读取。知情数据泄漏到隔离通道，导致隔离失效。\n\n| 维度 | 详情 |\n|------|------|\n| 检测方法 | ① 检查是否有 blind/isolated verifier；② 追踪其输入来源；③ 检查白名单文件是否包含知情数据 |\n| 修正 | 按信任域拆分文件（clean file vs dirty file） |\n| 严重度 | 🟠 High |\n| Pass 5 检查项 | O4（知识耦合检测） |\n\nFile v1.2.1:references/evidence-grading.md\n\n# Evidence Grading — 证据分级体系\n\n**加载时机：** 📍 Pass 2 Extract 执行知识提取时加载；Pass 6 Layer B 契约验证时加载。\n\n---\n\n## 设计哲学\n\n从多源内容（PDF/视频/网页/图片）提取的知识，可信度并不相同。原文直引、模型转述、编译器推断——这三类知识如果在 skill 中被同等对待，会导致用户把\"推测\"当成\"事实\"使用。\n\n本体系为每条知识打上证据等级，让 skill 的消费者（AI agent + 人类用户）知道\"这条结论多可靠\"。核心原则：**矛盾的信息不强行统一，而是保留并标注**——人本来就前后不一致，强制洗白会丢失真实信号。\n\n---\n\n## 三级证据体系\n\n| 等级 | 标签 | 含义 | 典型来源 |\n|------|------|------|---------|\n| **L1** | `primary` | 原文直引，可直接溯源到原始载体 | PDF 文本层、字幕原文、网页正文、代码注释 |\n| **L2** | `secondary` | 经过一次模型转述，存在转述损失 | OCR 结果、whisper 转写、视觉理解描述、摘要 |\n| **L3** | `inferred` | 编译器从上下文推断，原始载体未直接陈述 | 隐含假设、跨段推理、模式归纳 |\n\n### 判定规则\n\n| 内容形态 | 等级 | 理由 |\n|---------|------|------|\n| 引号内的原文 | `primary` | 可逐字核对 |\n| 代码块 | `primary` | 机器可验证 |\n| 表格数据 | `primary` | 结构化事实 |\n| OCR 提取的文字 | `secondary` | 可能有字符错误 |\n| 语音转写 | `secondary` | 可能有同音错误 |\n| \"这意味着...\" 的解读 | `inferred` | 推断而非原文 |\n| 从多个案例归纳的规律 | `inferred` | 归纳推理 |\n| 图表的结构化描述 | `secondary` | 视觉理解转述 |\n\n---\n\n## 在 Pass 2 中的应用\n\n### 提取时标注\n\nPass 2 Extract 从 `structured_content`（Pass I 产出）提取知识时，**每条知识必须带 `evidence` 字段**：\n\n```json\n{\n  \"content\": \"所有 API 响应必须包含 request_id 字段\",\n  \"source\": \"spec.pdf:p47\",\n  \"evidence\": \"primary\",\n  \"confidence\": 0.98\n}\n```\n\n### 默认值继承\n\n- 若 Pass I 为整份内容设定了默认 `evidence_grade`，Pass 2 提取的单条知识默认继承此等级\n- 但 Pass 2 可**逐条覆盖**：如从 `secondary` 内容中识别出一段原文直引，可升级为 `primary`\n\n### confidence 字段\n\n`confidence`（0-1）补充 `evidence` 的细粒度：\n- `primary` + `confidence: 0.95` = 高可信原文\n- `secondary` + `confidence: 0.6` = 低质量转写，需人工复核\n- `inferred` + `confidence: 0.7` = 中等把握的推断\n\n来源：OCR 置信度、whisper 置信度、或编译器对推断的自评。\n\n---\n\n## 冲突保留规则\n\n**核心原则：** 当多个来源对同一事实给出矛盾表述时，**不强行统一，保留所有版本并标注冲突**。\n\n### 冲突检测\n\nPass 2 提取时，若两条知识描述同一实体但内容矛盾：\n\n```json\n{\n  \"conflicts\": [\n    {\n      \"id\": \"C-001\",\n      \"topic\": \"API 限流策略\",\n      \"status\": \"open\",\n      \"versions\": [\n        { \"content\": \"每分钟 100 次\", \"source\": \"doc-v1.md\", \"evidence\": \"primary\", \"confidence\": 0.95 },\n        { \"content\": \"每分钟 1000 次\", \"source\": \"doc-v2.md\", \"evidence\": \"primary\", \"confidence\": 0.95 }\n      ],\n      \"resolution\": null,\n      \"resolved_by\": null,\n      \"resolved_at\": null,\n      \"note\": \"两个版本表述不一致，保留待用户裁决\"\n    }\n  ]\n}\n```\n\n### 冲突状态机\n\n```\nopen ──────────────────────────────► resolved\n  │                                     │\n  ├──► wontfix（不影响核心功能）         ├── resolution: prefer_higher_evidence\n  │                                     ├── resolution: prefer_newer\n  └──► deprecated（源已过期）            ├── resolution: merged\n                                        ├── resolution: user_override\n                                        └── resolved_by: user | compiler | cross_reference\n```\n\n| 状态 | 含义 | 终态？ |\n|------|------|--------|\n| `open` | 新发现冲突，待处理 | 否 |\n| `resolved` | 已裁决，标注了 resolution 和 resolved_by | 是 |\n| `wontfix` | 不影响核心功能，保留但不处理 | 是 |\n| `deprecated` | 冲突源已不再适用 | 是 |\n\n### 冲突处理策略\n\n| 策略 | 适用场景 |\n|------|---------|\n| `prefer_higher_evidence` | 一方 primary 一方 inferred，采用 primary |\n| `prefer_newer` | 来源有时间戳且差异显著，采用较新版本（需标注理由） |\n| `flag_for_user` | 矛盾影响 skill 核心功能，必须用户裁决 |\n| `merged` | 两版本可合并为更完整的表述 |\n| `user_override` | 用户明确选择了某一版本 |\n\n**禁止操作：** 静默丢弃任一版本、强行取平均值、随机选择一方。\n\n### 冲突在生成 skill 中的呈现\n\n冲突不隐藏，写入生成的 skill 的 `references/gotchas.md` 或 `references/conflicts.md`：\n\n```markdown\n## 已知冲突\n\n### API 限流策略\n- 来源 A（doc-v1.md）称\"每分钟 100 次\"\n- 来源 B（doc-v2.md）称\"每分钟 1000 次\"\n- 状态：未裁决。使用前请核实当前版本。\n```\n\n---\n\n## 在 Pass 6 中的应用\n\n### Layer B 契约验证新增检查\n\n| # | 检查项 | PASS 标准 | 严重度 |\n|---|--------|-----------|--------|\n| B9 | evidence 字段完整性 | 所有 knowledge_inventory 条目都有 evidence 字段 | 🟠 High |\n| B10 | inferred 条目有标注 | evidence=inferred 的条目在生成文件中明确标注为\"推断\" | 🟡 Medium |\n| B11 | 冲突未被静默丢弃 | IR 中 conflicts 数组的每个条目在生成文件中都有对应呈现 | 🟠 High |\n\n### 诚实性原则\n\n生成的 skill 不应把 `inferred` 知识当作 `primary` 事实陈述。Pass 6 Layer A 检查：\n\n> reference 文件中，推断性结论是否使用了\"可能\"、\"推测\"、\"建议核实\"等限定词，而非确定性表述。\n\n---\n\n## 与 Ingestion 阶段的衔接\n\n| Pass I 产出 | Pass 2 继承 |\n|------------|-------------|\n| `evidence_grade: primary`（默认） | 单条知识默认 primary，可被覆盖 |\n| `evidence_grade: secondary`（OCR/转写） | 单条知识默认 secondary |\n| `extraction_warnings: [OCR 置信度低]` | 相关段落 confidence 降至 0.6 以下 |\n| `provenance: [{source, extractor, confidence}]` | 每条知识的 source 字段溯源到此 |\n\nFile v1.2.1:references/example-generation.md\n\n# Conditional Pass: Example Generation\n\n**加载时机：** 📍 仅当 Skill 涉及复杂流程/规则/评分体系时加载。\n\n---\n\n## 触发条件\n\n满足任一：\n- architecture_type = workflow 或 multi-agent\n- 有 rubrics（评分体系）\n- 有 5+ 条 rules\n- 用户显式要求\n\n---\n\n## 生成规则\n\n### 示例类型\n\n| 类型 | 用途 | 何时生成 |\n|------|------|---------|\n| Minimal | 最简输入输出，验证基本流程 | 总是 |\n| Normal | 典型使用场景 | 总是 |\n| Complex | 边界条件或复杂输入 | 当有复杂规则时 |\n| Edge Case | 极端输入 | 当有数值阈值时 |\n| Failure Case | 应该失败的输入 | 当有输入验证时 |\n| Anti-pattern | 不应该这样用 | 当有常见误用时 |\n\n### 示例格式\n\n```markdown\n# Example: {Title}\n\n**Type:** minimal | normal | complex | edge-case | failure | anti-pattern\n\n## Input\n{输入内容}\n\n## Expected Output\n{期望输出}\n\n## Notes\n{为什么是这个输出，关键决策点}\n```\n\n### 生成原则\n\n1. **从 Prompt 中提取** — 如果 Prompt 自带示例，优先用\n2. **覆盖关键路径** — 每个主要 workflow 步骤至少有一个示例\n3. **不过度生成** — 3-5 个高质量示例 > 10 个低质量示例\n4. **可扩展** — examples/ 目录设计为可追加\n\nFile v1.2.1:references/honest-boundaries.md\n\n# Honest Boundaries — 诚实边界规范\n\n**加载时机：** 📍 Pass 3 Design 规划模块时加载；Pass 6 Layer A 结构审查时加载。\n\n---\n\n## 设计哲学\n\n一个不告诉你\"它做不到什么\"的 skill，不值得信任。\n\n大多数 skill 只描述自己的能力，却不声明局限。这导致用户在边界外使用时得到错误结果，却以为是 skill 质量问题。诚实边界的核心是：**每个 skill 必须显式声明自己的能力边界、失败模式、和适用前提**，让用户在使用前就知道风险。\n\n这不是\"谦虚\"，是工程契约——类似 API 文档里的 `throws` 声明。\n\n---\n\n## 三类边界声明\n\n每个生成的 skill 必须包含以下三类边界声明：\n\n### 1. 能力边界（Cannot Do）\n\n明确列出 skill **做不到**的事。来源：\n\n- Pass 1 的 `boundary.out_of_scope`\n- Pass I 的 `extraction_warnings`（如内容不完整）\n- 领域知识中隐含的适用限制\n\n**示例：**\n\n```markdown\n## 局限性\n\n本 skill **不能**：\n- 处理实时数据流（设计为批处理模式）\n- 识别 0-day 漏洞（规则库更新周期为周级）\n- 保证 100% 准确率（基于启发式规则，误报率约 5%）\n```\n\n### 2. 失败模式（Failure Modes）\n\n描述 skill 在什么情况下会**给出低质量或错误结果**：\n\n```markdown\n## 已知失败模式\n\n- 输入代码超过 2000 行时，审查质量下降（注意力分散）\n- 混合语言的代码块（如 SQL 内嵌在 Python）可能漏报\n- 高度抽象的设计模式代码，规则匹配可能误报\n```\n\n来源：Pass 6 审查中发现的弱点、Pass 2 的 `inferred` 知识、领域经验。\n\n### 3. 适用前提（Prerequisites）\n\n使用 skill 前必须满足的条件：\n\n```markdown\n## 适用前提\n\n- 输入必须是可编译的源码（不支持伪代码）\n- 项目需有基本的测试覆盖（否则\"未覆盖\"警告无意义）\n- 单次审查文件数 ≤ 50（超过需分批）\n```\n\n---\n\n## 在 Pass 3 中的应用\n\n### 模块规划\n\nPass 3 Design 必须在 `module_decomposition` 中规划边界声明模块：\n\n```json\n{\n  \"module_decomposition\": {\n    \"references\": [\n      \"references/honest-boundaries.md — 局限性、失败模式、适用前提\"\n    ]\n  }\n}\n```\n\n### 边界声明来源映射\n\n| 边界类型 | 数据来源 | IR 字段 |\n|---------|---------|---------|\n| Cannot Do | 显式排除项 | `pass_1.boundary.out_of_scope` |\n| Cannot Do | 提取警告 | `pass_ingestion.extraction_warnings` |\n| Failure Modes | 推断性知识的弱点 | `pass_2` 中 evidence=inferred 的条目 |\n| Failure Modes | 架构固有限制 | `pass_3.architecture_type` 的已知弱点 |\n| Prerequisites | 输入要求 | `pass_1.input_spec` |\n\n### 生成模板（Pass 4 使用）\n\n```markdown\n# Honest Boundaries\n\n## 局限性（Cannot Do）\n{从 boundary.out_of_scope 逐条生成}\n\n## 已知失败模式\n{从 inferred 知识 + 架构弱点生成}\n\n## 适用前提\n{从 input_spec + 架构约束生成}\n\n## 证据强度提示\n{当 skill 包含 secondary/inferred 知识时，声明\"部分结论基于转述/推断，建议核对原文\"}\n```\n\n---\n\n## 在 Pass 6 中的应用\n\n### Layer A 结构审查新增角色检查\n\n**Role 2 — Knowledge Engineer** 新增检查项：\n\n| 检查项 | 问题信号 | 严重度 |\n|--------|---------|--------|\n| 边界声明存在 | 生成的 skill 是否有 honest-boundaries / gotchas / limitations 章节 | 🟠 High |\n| 边界完整性 | out_of_scope 项是否都在生成文件中有对应声明 | 🔴 Critical |\n| 推断标注 | inferred 知识是否被标注为\"推断/可能\"而非\"事实\" | 🟠 High |\n| 失败模式诚实 | 是否声明了至少 1 个已知失败模式（非空壳） | 🟡 Medium |\n\n### 空壳检测\n\n若生成的 `references/honest-boundaries.md` 只有骨架无实质内容（全是 TODO/占位符），标记为：\n\n> 🟡 Medium — 边界声明为空壳。建议基于 Pass 6 审查发现补充实际失败模式。\n\n### 评分影响\n\n- 缺失边界声明章节：Layer A pass_rate 扣减\n- out_of_scope 项未在生成文件中体现：Layer B B2 直接 FAIL（Critical）\n- inferred 知识未标注：Layer B B10 FAIL（Medium）\n\n---\n\n## 与 Gotchas 的区别\n\n| 文档 | 职责 | 时态 |\n|------|------|------|\n| `honest-boundaries.md` | 系统性的能力边界声明 | 设计时已知 |\n| `gotchas.md` | 上线后发现的踩坑记录 | 运行时发现 |\n\n两者互补：honest-boundaries 是\"出生时就知道的局限\"，gotchas 是\"踩坑后补的\"。新生成的 skill 优先填充 honest-boundaries，gotchas 留骨架待运行时填充。\n\n---\n\n## 反模式\n\n| 反模式 | 说明 | 检测 |\n|--------|------|------|\n| **全能声明** | description 声称能做所有事，无任何局限 | Layer C 触发质量检查：negative case 未被排斥 |\n| **空壳边界** | 有 honest-boundaries 章节但全是占位符 | Pass 6 空壳检测 |\n| **隐藏推断** | inferred 知识用确定性语气陈述 | Layer B B10 检查 |\n| **静默丢弃冲突** | 多源矛盾信息只保留一方 | evidence-grading.md 冲突保留规则 + Layer B B11 |\n\nFile v1.2.1:references/meta-reflection.md\n\n# Meta-Reflection — 编译过程自省框架\n\n**加载时机：** 在各 Pass 的 Decision Gate 处按需引用。编译器在执行关键决策后，用此框架对自己的判断进行二次审视。\n\n---\n\n## 设计哲学\n\n编译 Skill 不仅是机械的\"输入→分析→设计→生成\"。编译器在高模糊性的决策点（如\"这个能力是 primary 还是 secondary？\"\"这个架构选 workflow 还是 multi-agent？\"）容易陷入经验惯性或盲区。\n\n**元反思是编译器的\"自我审计\"机制**——在关键决策后，暂停片刻，用结构化维度审视刚才的判断是否经得起推敲。\n\n---\n\n## 八维度框架\n\n| # | 维度 | 核心问题 | 适用阶段 |\n|---|------|---------|---------|\n| D1 | **问题定义** | 我是否理解了真正的问题？有没有更好的问题表述？ | Pass 1 Analysis |\n| D2 | **假设** | 我的关键假设是什么？哪些未经验证？ | Pass 1 Analysis |\n| D3 | **推理** | 推理链是否存在跳跃、循环或逻辑漏洞？ | Pass 3 Design |\n| D4 | **证据** | 哪些观点有证据支持？哪些只是推测？ | Pass 2 Extract, Pass 6 Validate |\n| D5 | **替代解释** | 是否存在其他同样合理甚至更好的解释？ | Pass 3 Design |\n| D6 | **边界条件** | 结论适用于哪些场景？什么时候会失效？ | Pass 3 Design |\n| D7 | **目标** | 当前优化目标是否正确？是否应该优化更高层目标？ | Pass 1 Analysis, Pass 6 Validate |\n| D8 | **不确定性** | 我最没有把握的部分是什么？还需要哪些信息才能提高可信度？ | Pass 1 Analysis, Pass 6 Validate |\n\n---\n\n## 各维度详解\n\n### D1 — 问题定义（Problem Definition）\n\n**核心问题：** 我是否理解了真正的问题？有没有更好的问题表述？\n\n**在编译上下文中的含义：**\n- 用户给的 Prompt 字面含义 vs 真实需求是否一致？\n- `prompt_goal.stated` 和 `prompt_goal.actual` 的差距有多大？\n- 有没有更精确的方式描述这个 Skill 要解决的问题？\n\n**触发时刻：** Pass 1 Step 1.2 Goal Extraction 完成后\n\n**自检清单：**\n- [ ] stated goal 是否只是 actual goal 的表面表述？\n- [ ] 如果换一种方式定义这个问题，skill 的设计会完全改变吗？\n- [ ] 用户可能没有说出来的深层需求是什么？\n\n---\n\n### D2 — 假设（Assumptions）\n\n**核心问题：** 我的关键假设是什么？哪些未经验证？\n\n**在编译上下文中的含义：**\n- `hidden_assumptions` 列表中的每一项——有没有办法在编译过程中验证而非假设？\n- 假设用户\"熟悉 Skill 结构\"是否导致跳过了必要的解释？\n- 假设\"输入格式稳定\"是否忽略了格式退化场景？\n\n**触发时刻：** Pass 1 Step 1.6 Hidden Assumptions 完成后\n\n**自检清单：**\n- [ ] 每个 hidden_assumption 是否标注了\"可验证\"还是\"不可在编译期内验证\"？\n- [ ] 是否存在\"假设用户会正确使用\"这一隐含假设？\n- [ ] 最脆弱的一个假设如果错了，哪些设计决策会崩塌？\n\n---\n\n### D3 — 推理（Reasoning）\n\n**核心问题：** 推理链是否存在跳跃、循环或逻辑漏洞？\n\n**在编译上下文中的含义：**\n- architecture_type 的决策链是否有跳跃？(\"因为有多个步骤 → 所以选 workflow\"——但步骤间是否需要不同专业角色？)\n- workflow pattern 的选择是否自洽？(classify-and-act + pipeline 的组合是否合理？)\n- 模块拆分的依据是否一致？(为什么规则 A 独立成文件而规则 B 内联？)\n\n**触发时刻：** Pass 3 Step 3.1 Architecture Type 决策后、Step 3.4 Module Decomposition 后\n\n**自检清单：**\n- [ ] 每个\"因为 X 所以 Y\"的推理步骤是否可以回溯到明确的条件？\n- [ ] 是否存在循环推理——\"选 A 是因为 B，而 B 的定义来自 A\"？\n- [ ] 模块拆分标准是否前后一致？\n\n---\n\n### D4 — 证据（Evidence）\n\n**核心问题：** 哪些观点有证据支持？哪些只是推测？\n\n**在编译上下文中的含义：**\n- 每条知识的 `evidence` 字段：primary / secondary / inferred 的分布是否健康？\n- inferred 条目是否标注了推断依据？\n- 是否存在大量 inferred 知识被当作 primary 使用？\n\n**触发时刻：** Pass 2 Step 2.2 Knowledge Inventory 后、Pass 6 Layer B 验证时\n\n**自检清单：**\n- [ ] inferred 条目占比是否 > 30%？如果是，skill 的可信度是否足够？\n- [ ] 是否存在\"所有人都知道\"但其实只是推断的知识？\n- [ ] 冲突条目（conflicts）是否都有来源标注？\n\n---\n\n### D5 — 替代解释（Alternative Explanations）\n\n**核心问题：** 是否存在其他同样合理甚至更好的解释？\n\n**在编译上下文中的含义：**\n- 能力图谱的 primary/secondary 划分是否有替代方案？\n- 架构类型的选择是否有同等级有力的替代方案？\n- 当前选定的 workflow pattern 之外，是否存在另一个 pattern 同样合理？\n\n**触发时刻：** Pass 3 Step 3.1-3.2 架构与 workflow 决策后\n\n**自检清单：**\n- [ ] 至少考虑过 1 个替代的 architecture_type 并给出淘汰理由\n- [ ] 至少考虑过 1 个替代的 workflow pattern 并给出淘汰理由\n- [ ] 替代方案的优势是否被诚实评估？（而非刻意贬低以证明当前选择正确）\n\n---\n\n### D6 — 边界条件（Boundary Conditions）\n\n**核心问题：** 结论适用于哪些场景？什么时候会失效？\n\n**在编译上下文中的含义：**\n- boundary.out_of_scope 是否足够具体？还是泛泛的\"不处理无关请求\"？\n- 当前设计的 architecture 在什么条件下会变成错误选择？\n- 生成的 skill 在什么使用场景下会表现不佳？\n\n**触发时刻：** Pass 3 Step 3.4-3.8 模块设计与目录规划后\n\n**自检清单：**\n- [ ] out_of_scope 条目是否都足够具体，可被 Pass 6 Layer C 的压力测试验证？\n- [ ] 设计的架构在以下极端条件下是否仍适用：输入为空 / 输入极长 / 输入格式退化？\n- [ ] skill 的失效模式是否在 honest-boundaries 中声明？\n\n---\n\n### D7 — 目标（Goals）\n\n**核心问题：** 当前优化目标是否正确？是否应该优化更高层目标？\n\n**在编译上下文中的含义：**\n- 当前在优化\"Prompt 长度\"还是\"Skill 可维护性\"——这两个目标冲突时优先级是什么？\n- 是不是在过度优化某个指标而牺牲了更重要的指标？\n- 编译的最终目标是\"产出高质量 skill\"还是\"通过所有 Pass\"？\n\n**触发时刻：** Pass 1 完成后、Pass 6 综合评分前\n\n**自检清单：**\n- [ ] \"降低 token 消耗\"是否导致关键知识被移除？\n- [ ] \"提高评分\"是否导致过度设计——加了不必要但能加分的模块？\n- [ ] 最终产出对用户而言真的可用吗？（而非只是在 IR 中看起来好）\n\n---\n\n### D8 — 不确定性（Uncertainty）\n\n**核心问题：** 我最没有把握的部分是什么？还需要哪些信息才能提高可信度？\n\n**在编译上下文中的含义：**\n- unknowns 列表中是否遗漏了关键的不确定信息？\n- 编译过程中哪些决策是\"猜测\"而非\"推理\"？\n- 哪些推断如果能向用户确认，会显著提高 skill 质量？\n\n**触发时刻：** Pass 1 Step 1.7 Unknowns 后、Pass 6 最终审查时\n\n**自检清单：**\n- [ ] 是否有超过 3 个未被询问的 unknowns？（如果是，选最重要的 3 个问用户）\n- [ ] 最终的 skill 中哪些部分是\"我们猜的\"而非\"确定的\"？\n- [ ] 如果只能向用户确认一件事来提高 skill 质量，那件事是什么？\n\n---\n\n## 检查点放置\n\n| 阶段 | 检查点 | 覆盖维度 | 位置 |\n|------|--------|---------|------|\n| Pass 1 收尾 | 分析后自省 | D1, D2, D7, D8 | pass-1-analyze.md Step 1.8 |\n| Pass 2 收尾 | 知识提取后自省 | D4 | pass-2-extract.md Step 2.4 |\n| Pass 3 收尾 | 设计后自省 | D3, D5, D6 | pass-3-design.md Step 3.11 |\n| Pass 6 评前 | 验证前自省 | D4, D7, D8 | pass-6-validate.md Step 6.0 |\n\n---\n\n## 使用约束\n\n1. **每个检查点不超过 3 个维度**——不是所有维度都要在每处应用\n2. **只问能改变决策的问题**——如果某个维度的回答不会改变任何设计，跳过它\n3. **记录但不阻塞**——meta-reflection 的输出写入 trace 或日志，但不应成为 Decision Gate 的硬阻塞条件。它是编译器自我校准的机制，而非额外的审批门槛\n4. **快速模式跳过**——compilation_mode 为 `quick` 时，meta-reflection 检查点全部跳过（token 成本优先）\n\nFile v1.2.1:references/parallel-extractors.md\n\n# Parallel Extractors — 并行知识提取器\n\n**加载时机：** 📍 Pass 2 Extract 执行知识提取时加载（当 source 来自多源摄取或内容复杂时）。\n\n---\n\n## 设计哲学\n\n从长内容（整份 PDF、视频转写、网页文档）提取知识时，单线程逐句扫描效率低且容易遗漏。并行提取器的核心：**派多个专项提取器同时扫描同一份内容，每个只关注一类知识，最后合并去重**。\n\n类比编译器的并行优化 pass：每个 pass 只做一个具体的优化（常量折叠、死代码消除），但它们可以并行跑，最后合并 IR。\n\n---\n\n## 五个专项提取器\n\n| 提取器 | 关注的知识类型 | 输出 |\n|--------|--------------|------|\n| **F1 框架提取器** | 方法论、流程、步骤模型、决策树 | 结构化的流程描述 |\n| **F2 原则提取器** | 规则、约束、最佳实践、戒律 | 规则清单 |\n| **F3 案例提取器** | 具体实例、应用场景、成功案例 | 带上下文的案例 |\n| **F4 反例提取器** | 失败案例、常见错误、反模式、边界外的行为 | 负面清单 |\n| **F5 术语提取器** | 领域概念、专有名词、定义、术语表 | 术语词典 |\n\n### 为什么是这五类\n\n这五类覆盖了 skill 所需知识的完整光谱：\n\n- **F1 框架** 回答\"怎么做\"（Workflow）\n- **F2 原则** 回答\"必须遵守什么\"（Rules）\n- **F3 案例** 回答\"什么时候用\"（Examples）\n- **F4 反例** 回答\"什么时候不该用\"（Boundary）\n- **F5 术语** 回答\"关键词什么意思\"（Domain Knowledge）\n\n对应 skill 架构：F1→workflows，F2→references/rules，F3→examples，F4→honest-boundaries/gotchas，F5→references/domain。\n\n---\n\n## 执行机制\n\n### 并行触发条件\n\n当满足任一条件时，启用并行提取器（而非 Pass 2 的默认单线程提取）：\n\n| 条件 | 理由 |\n|------|------|\n| Pass I 执行了（多源摄取） | 摄取后的内容通常量大且杂 |\n| `structured_content` > 3000 字 | 单线程扫描长内容易遗漏 |\n| 内容含 3+ 个独立主题 | 需要多维度并行覆盖 |\n| 用户显式要求深度提取 | 质量优先 |\n\n### 并行执行模型\n\n五个提取器**逻辑并行**（在同一轮中分别扫描全文），每个独立产出候选知识列表：\n\n```\nstructured_content\n      │\n  ┌───┼───┬───┬───┬───┐\n  F1  F2  F3  F4  F5\n  │   │   │   │   │\n  ▼   ▼   ▼   ▼   ▼\n 候选  候选  候选  候选  候选\n  │   │   │   │   │\n  └───┴───┴───┴───┴───┘\n      │\n  合并去重 + 三重验证\n      │\n      ▼\n  validated knowledge_inventory\n```\n\n---\n\n## 各提取器规格\n\n### F1 — 框架提取器\n\n**扫描目标：** 方法论、流程、步骤性内容。\n\n**识别信号：**\n- 编号步骤（\"第一步...第二步...\"）\n- 流程图/决策树的文字描述\n- \"流程是\"、\"按以下步骤\"、\"方法论包括\"\n- 时序性叙述（先...再...最后...）\n\n**产出格式：**\n```json\n{\n  \"extractor\": \"F1-framework\",\n  \"candidates\": [\n    {\n      \"content\": \"代码审查三阶段：自动检查 → 人工审查 → 安全审计\",\n      \"source\": \"SEG-014\",\n      \"evidence\": \"primary\",\n      \"framework_steps\": [\"自动检查\", \"人工审查\", \"安全审计\"]\n    }\n  ]\n}\n```\n\n### F2 — 原则提取器\n\n**扫描目标：** 规则、约束、强制要求。\n\n**识别信号：**\n- 强制词：\"必须\"、\"禁止\"、\"不要\"、\"always\"、\"never\"、\"强制\"\n- 建议词：\"应该\"、\"建议\"、\"推荐\"、\"避免\"\n- 约束词：\"不得超过\"、\"至少需要\"、\"限定为\"\n\n**产出格式：**\n```json\n{\n  \"extractor\": \"F2-principle\",\n  \"candidates\": [\n    {\n      \"content\": \"禁止硬编码 API key 在源码中\",\n      \"source\": \"SEG-022\",\n      \"evidence\": \"primary\",\n      \"rule_type\": \"prohibition\"\n    }\n  ]\n}\n```\n\n### F3 — 案例提取器\n\n**扫描目标：** 具体实例、应用场景。\n\n**识别信号：**\n- \"例如\"、\"示例\"、\"case\"、\"场景\"\n- 具体的输入输出对\n- \"当...时，应该...\"\n\n**产出格式：**\n```json\n{\n  \"extractor\": \"F3-case\",\n  \"candidates\": [\n    {\n      \"content\": \"处理用户登录时，先验证 CSRF token 再查数据库\",\n      \"source\": \"SEG-031\",\n      \"evidence\": \"primary\",\n      \"case_type\": \"application\"\n    }\n  ]\n}\n```\n\n### F4 — 反例提取器\n\n**扫描目标：** 失败案例、反模式、常见错误。\n\n**识别信号：**\n- \"不要\"、\"错误\"、\"避免\"、\"反模式\"、\"常见错误\"\n- \"踩坑\"、\"教训\"、\"失败的\"\n- 负面表述（\"这样会导致...\"）\n\n**产出格式：**\n```json\n{\n  \"extractor\": \"F4-antipattern\",\n  \"candidates\": [\n    {\n      \"content\": \"不要在循环中创建数据库连接，会导致连接池耗尽\",\n      \"source\": \"SEG-040\",\n      \"evidence\": \"primary\",\n      \"antipattern_type\": \"performance\"\n    }\n  ]\n}\n```\n\n**重要：** F4 的产出直接喂给 [honest-boundaries.md](honest-boundaries.md) 的失败模式章节。\n\n### F5 — 术语提取器\n\n**扫描目标：** 领域概念、专有名词。\n\n**识别信号：**\n- 定义句（\"X 是指...\"、\"X 定义为...\"）\n- 首字母缩写（CSRF、SSRF、XSS）\n- 反复出现的领域名词\n- 中英文对照术语\n\n**产出格式：**\n```json\n{\n  \"extractor\": \"F5-term\",\n  \"candidates\": [\n    {\n      \"content\": \"CSRF（Cross-Site Request Forgery）：跨站请求伪造\",\n      \"source\": \"SEG-005\",\n      \"evidence\": \"primary\",\n      \"term\": \"CSRF\"\n    }\n  ]\n}\n```\n\n---\n\n## 合并去重\n\n五个提取器产出后，合并为统一候选池：\n\n### 去重规则\n\n| 情况 | 处理 |\n|------|------|\n| 同一内容被多个提取器命中 | 保留证据等级最高的版本，合并 source 标注 |\n| 语义相同表述不同 | 保留表述最清晰的版本，记录变体 |\n| 矛盾内容（F2 说\"必须\" vs 另一来源说\"可选\"） | 不去重，触发 [evidence-grading.md](evidence-grading.md) 冲突保留规则 |\n\n### 去重后\n\n候选池进入**三重验证**。\n\n---\n\n## 三重验证\n\n**核心原则：** 不是所有候选都值得变成 skill 知识。每个候选必须通过三项检验才能进入 `knowledge_inventory`。\n\n### V1 — 独立佐证（Corroboration）\n\n候选知识必须在原始内容中有 **≥ 2 处独立佐证**，或来自 `primary` 证据且表述明确。\n\n| 通过条件 | 说明 |\n|---------|------|\n| 同一观点出现 2+ 次（不同段落） | 强佐证 |\n| 1 次 primary + 1 次 secondary | 中佐证，通过 |\n| 仅 1 次 inferred | **不通过**（孤立推断不可靠） |\n\n### V2 — 预测力（Predictive Power）\n\n候选知识必须能回答原始内容中**未明说的新问题**。\n\n**测试方法：** 构造一个原始内容未直接讨论的场景，看这条知识是否能给出指导。若不能（即只是重复原文事实），则预测力不足。\n\n| 通过条件 | 说明 |\n|---------|------|\n| 能指导原文未覆盖的新场景 | 通过 |\n| 仅在原文特定上下文成立 | 降级为 example（而非 rule） |\n| 纯事实陈述无泛化能力 | **不通过**（不是可复用知识） |\n\n### V3 — 非常识性（Non-triviality）\n\n候选知识不应是\"所有从业者都知道\"的常识。\n\n| 通过条件 | 说明 |\n|---------|------|\n| 包含领域特定的非显而易见洞察 | 通过 |\n| 是通用编程/写作常识（如\"变量要命名清晰\"） | **不通过**（无增值） |\n| 是原始内容的独特观点 | 通过 |\n\n### 验证结果\n\n| 通过几项 | 处理 |\n|---------|------|\n| V1 + V2 + V3 全通过 | 进入 `knowledge_inventory` |\n| 通过 2 项 | 降级为 `examples`（参考用，非规则） |\n| 通过 ≤ 1 项 | 淘汰 |\n\n**典型通过率：** 经验上，候选池中只有 25-50% 能通过三重验证。这是正常的——高门槛保证 skill 质量不注水。\n\n---\n\n## Output\n\n并行提取器的产出合并进 Pass 2 的标准 `knowledge_inventory` 结构，每条知识额外携带：\n\n```json\n{\n  \"extractor\": \"F1-framework\",\n  \"verification\": {\n    \"v1_corroboration\": true,\n    \"v2_predictive\": true,\n    \"v3_non_trivial\": true,\n    \"passed\": true\n  }\n}\n```\n\n---\n\n## Gotchas\n\n1. **并行提取器不是必须的** — 纯文本短 Prompt 直接用 Pass 2 默认单线程提取即可。强制对 200 字 Prompt 跑 5 个提取器是过度设计。\n2. **F4 反例提取器最易被忽略但最有价值** — 反例直接喂给诚实边界，是 skill 可信度的关键。不要因为\"负面内容少\"就跳过 F4。\n3. **三重验证的 V2 最难判定** — \"预测力\"需要构造假设场景测试，容易被跳过。但跳过 V2 会导致 skill 充满不可复用的碎片事实。\n4. **去重不要在提取器内部做** — 每个提取器只管自己那类，跨类去重在合并阶段统一做。提取器内部去重会丢失跨类关联。\n5. **通过率低是好事** — 若通过率 > 70%，说明验证门槛太松，skill 会注水。调整验证标准而非降低门槛。\n\nFile v1.2.1:references/pass-1-analyze.md\n\n# Pass 1: Analyze — 理解 Prompt\n\n**加载时机：** 📍 执行到 Pass 1 时加载。\n**输入来源：** 若 Pass I Ingestion 执行过，本 Pass 的输入是其产出的 `structured_content`（标准化文本），需额外关注来源溯源与证据等级。若未执行 Ingestion，输入为用户原始 Prompt。\n\n---\n\n## 执行步骤\n\n### Step 1.1 — Prompt Summary\n\n用一句话概括 Prompt 的核心功能。不照搬原文，用自己的话重述。\n\n### Step 1.2 — Goal Extraction\n\n区分 Prompt\"说的\"和\"真正需要的\"：\n- **说的：** Prompt 字面要求做什么\n- **真正需要的：** 这个能力长期来看应该解决什么问题\n\n### Step 1.3 — Input/Output Spec\n\n| 字段 | 如何确定 |\n|------|---------|\n| input | Prompt 接收什么？用户输入？文件？API 响应？结构化内容？ |\n| output | Prompt 产出什么？文本？JSON？文件？结构化报告？ |\n\n如果 Prompt 没有明确说明，从上下文推断并标注为 `inferred`。\n\n**多源输入识别（v2.0）：** 若 Pass I 执行过（IR 含 `pass_ingestion` 字段），`input_spec.type` 设为 `structured_content`，并在 description 中注明原始来源类型（如\"来自 PDF 规范文档的结构化内容\"）。同时检查 `pass_ingestion.extraction_warnings`，若存在 critical 警告，在 `hidden_assumptions` 中记录\"输入内容可能不完整\"。\n\n### Step 1.4 — Capability Hints\n\n快速扫描 Prompt 中暗示的能力关键词：\n\n```\n决策类：decision, choose, recommend, 判断, 推荐, 决策\n规划类：plan, strategy, roadmap, 规划, 策略, 路线图\n写作类：write, draft, compose, 写, 起草, 撰写\n审查类：review, audit, check, 审查, 检查, 审核\n研究类：research, investigate, search, 调研, 搜索, 调查\n分析类：analyze, assess, evaluate, 分析, 评估\n编码类：code, implement, debug, 编码, 实现, 调试\n推理类：reason, infer, deduce, 推理, 推断\n模拟类：simulate, model, predict, 模拟, 建模, 预测\n评估类：score, rate, benchmark, 评分, 打分, 基准\n分类类：classify, categorize, sort, 分类, 归类\n排名类：rank, prioritize, 排序, 优先级\n```\n\n记录命中的关键词，传给 Pass 2 做深度抽取。\n\n### Step 1.5 — Boundary Definition\n\n明确 Skill 的边界——**不处理什么**：\n\n1. Prompt 中暗示但不应包含的场景\n2. 与其他 Skill 的职责划分\n3. 用户可能误用的方向\n\n### Step 1.6 — Hidden Assumptions\n\nPrompt 中隐含但未明说的前提：\n\n- 隐含的角色假设（\"你是专家\" → 需要领域知识）\n- 隐含的格式假设（\"输出报告\" → 需要模板）\n- 隐含的质量假设（\"高质量\" → 需要评分标准）\n\n### Step 1.7 — Unknowns\n\n需要向用户澄清的问题。**最多问 3 个**，只问能改变架构设计的：\n\n- 不确定的核心目标？\n- 不确定的使用频率（影响 archetype）？\n- 不确定的输出消费者（影响输出格式）？\n\n### Step 1.8 — Meta-Reflection Checkpoint（v2.1）\n\n在进入 Pass 2 之前，用以下 4 个维度二次审视刚才的分析结论。Quick 模式跳过此步。\n\n📍 完整框架见 [meta-reflection.md](meta-reflection.md)\n\n| 维度 | 自检问题 | 触发条件 |\n|------|---------|---------|\n| D1 问题定义 | `prompt_goal.actual` 是否比 `stated` 更深一层？有没有更好的问题表述？ | 总是 |\n| D2 假设 | `hidden_assumptions` 中是否有\"假设用户会正确使用\"？最脆弱的假设如果错了，哪些结论崩塌？ | hidden_assumptions 非空 |\n| D7 目标 | 是否为了降低 token 消耗而在牺牲 skill 的准确度？最终产出对用户真的可用吗？ | 总是 |\n| D8 不确定性 | `unknowns` 之外是否还有未记录的不确定点？如果只能向用户确认一件事，是什么？ | 总是 |\n\n**输出：** 将自省结果追加到 `unknowns`（如有新发现的不确定点）或写入 trace。不阻塞 Decision Gate。\n\n---\n\n## Output Schema\n\n```json\n{\n  \"prompt_summary\": \"一句话，不照搬原文\",\n  \"prompt_goal\": {\n    \"stated\": \"字面目标\",\n    \"actual\": \"真正需要的能力\"\n  },\n  \"input_spec\": {\n    \"type\": \"string | structured_content | file | api | mixed\",\n    \"description\": \"输入描述\",\n    \"inferred\": false\n  },\n  \"output_spec\": {\n    \"type\": \"string | json | file | report\",\n    \"description\": \"输出描述\",\n    \"inferred\": false\n  },\n  \"capability_hints\": [\"命中的能力关键词\"],\n  \"boundary\": {\n    \"in_scope\": [\"处理的场景\"],\n    \"out_of_scope\": [\"不处理的场景\"]\n  },\n  \"hidden_assumptions\": [\"隐含前提\"],\n  \"unknowns\": [\"需要澄清的问题（<= 3 个）\"]\n}\n```\n\n## Decision Gate\n\n| 条件 | 动作 |\n|------|------|\n| unknowns 为空 | → Pass 2 |\n| unknowns 非空 | 向用户提问，收到回答后更新 IR → Pass 2 |\n\nFile v1.2.1:references/pass-2-extract.md\n\n# Pass 2: Extract — 能力/知识/角色抽取\n\n**加载时机：** 📍 执行到 Pass 2 时加载。\n\n---\n\n## 三合一抽取\n\n原 16-phase 设计把 Capability Extraction、Knowledge Extraction、Role Extraction 拆成三步。但它们本质都是\"分析 Prompt 的组成要素\"，强关联且无独立决策门。合并为一次扫描，产出三个 IR 字段。\n\n---\n\n## Step 2.1 — Capability Graph 构建\n\n### 能力识别\n\n从 Pass 1 的 `capability_hints` 出发，构建能力依赖图：\n\n```\nPrimary Capability（核心能力，1-3 个）\n  ├── Sub-capability（子能力）\n  └── Supporting Capability（支撑能力）\n```\n\n### 能力分类参考\n\n| 类别 | 能力 |\n|------|------|\n| 认知 | Decision Making, Reasoning, Analysis, Prediction |\n| 创造 | Writing, Brainstorming, Coding, Mapping |\n| 评估 | Review, Evaluation, Scoring, Ranking, Classification |\n| 执行 | Planning, Workflow, Research, Knowledge Retrieval |\n| 交互 | Role Playing, Simulation |\n\n### Graph 构建规则\n\n1. **Primary** = Prompt 的核心功能对应的能力（1-3 个）\n2. **Secondary** = 支撑核心能力的能力\n3. **Graph edges** = 能力间的依赖关系（A 需要 B 先完成）\n\n---\n\n## Step 2.2 — Knowledge Inventory 提取\n\n扫描内容，逐句分类：\n\n| 知识类型 | 识别信号 | 去向 |\n|---------|---------|------|\n| **Rules** | \"必须\"、\"禁止\"、\"不要\"、\"always\"、\"never\" | `references/rules.md` |\n| **Templates** | 有结构化输出格式、固定 section | `templates/*.md` |\n| **Domain Knowledge** | 行业术语、专业概念、法规 | `references/domain-*.md` |\n| **Examples** | \"例如\"、\"示例\"、\"case\" | `examples/*.md` |\n| **Standards** | 评分标准、质量标准、验收标准 | `rubrics/*.md` |\n| **Roles** | \"你是...\"、\"作为...\"、persona 定义 | Pass 2.3 处理 |\n| **Processes** | 步骤、流程、phase | Pass 3 Design 处理 |\n| **Experience** | 经验法则、最佳实践、教训 | `references/best-practices.md` |\n\n### 并行提取（v2.0）\n\n当输入来自 Pass I 多源摄取，或内容较长（> 3000 字）时，启用并行提取器代替单线程扫描。五个专项提取器（框架/原则/案例/反例/术语）并行扫描，合并后经三重验证筛入知识库。\n\n📍 并行提取器与三重验证详见 [parallel-extractors.md](parallel-extractors.md)\n\n### 提取规则\n\n- **去重：** 相同规则出现多次，只保留一次\n- **去噪：** 过渡句、寒暄语不提取\n- **标注来源：** 每条知识标注 `[from source prompt]` 或 `[inferred by compiler]`\n\n### 证据分级标注（v2.0）\n\n每条提取的知识**必须携带 `evidence` 字段**，表示其可信度等级：\n\n| 等级 | 含义 | 典型场景 |\n|------|------|---------|\n| `primary` | 原文直引，可溯源 | PDF 文本层、字幕原文、代码注释 |\n| `secondary` | 经过一次模型转述 | OCR 结果、语音转写、视觉理解 |\n| `inferred` | 编译器从上下文推断 | 隐含假设、跨段推理 |\n\n默认值继承自 `pass_ingestion.evidence_grade`（若存在），但可逐条覆盖。\n\n📍 完整证据分级体系与 confidence 字段定义见 [evidence-grading.md](evidence-grading.md)\n\n### 冲突保留（v2.0）\n\n当多条知识描述同一事实但内容矛盾时，**不强行统一，保留所有版本**并记录到 IR 的 `conflicts` 字段。冲突处理策略（unresolved / prefer_higher_evidence / prefer_newer / flag_for_user）见 [evidence-grading.md](evidence-grading.md) 的\"冲突保留规则\"章节。\n\n**禁止：** 静默丢弃任一版本、强行取平均值、随机选择一方。\n\n---\n\n## Step 2.3 — Role Matrix 构建\n\n### 识别现有角色\n\n扫描 Prompt 中的 persona 定义：\n\n| 信号 | 示例 |\n|------|------|\n| 显式角色声明 | \"你是世界级 AI Skill Architect\" |\n| 隐式角色 | \"审查代码质量\"（隐含 Reviewer 角色） |\n| 多角色切换 | Prompt 中有多个\"你是...\" |\n\n### 角色分析\n\n对每个识别到的角色：\n\n| 字段 | 说明 |\n|------|------|\n| name | 角色名 |\n| responsibility | 职责描述 |\n| capabilities | 需要的能力（关联 Capability Graph） |\n| should_split | 是否应该拆分为独立 agent |\n| split_reason | 拆分理由（如果 should_split=true） |\n\n### 拆分判断\n\n| 条件 | should_split |\n|------|-------------|\n| 单一角色，职责清晰 | false |\n| 角色有 3+ 不相关职责 | true |\n| 角色同时负责\"产出\"和\"验证\" | true（干验分离原则） |\n| 角色需要不同的知识域 | true |\n\n### 建议新增角色\n\n分析 Prompt 缺失但 Skill 需要的角色：\n- 缺少 Verifier？（产出后需要独立验证）\n- 缺少 Router？（多种输入类型需要路由）\n- 缺少 Formatter？（需要统一输出格式）\n\n### Step 2.4 — Meta-Reflection Checkpoint（v2.1）\n\n在进入 Pass 3 之前，用证据维度审视知识提取质量。Quick 模式跳过此步。\n\n📍 完整框架见 [meta-reflection.md](meta-reflection.md)\n\n| 维度 | 自检问题 |\n|------|---------|\n| D4 证据 | 所有知识条目是否都携带 `evidence` 字段？inferred 条目占比是否 > 30%？是否存在\"公认事实\"其实只是推断的知识？ |\n\n**输出：** 如发现大量 inferred 条目缺少推断依据标注，补充标注后写入 IR。不阻塞 Decision Gate。\n\n---\n\n## Output Schema\n\n```json\n{\n  \"capability_graph\": {\n    \"primary\": [\"能力1\", \"能力2\"],\n    \"secondary\": [\"能力3\"],\n    \"graph\": {\n      \"能力1\": [\"子能力A\", \"子能力B\"],\n      \"能力2\": [\"子能力C\"]\n    }\n  },\n  \"knowledge_inventory\": {\n    \"rules\": [\n      { \"content\": \"规则内容\", \"source\": \"from source prompt | inferred\", \"target_file\": \"references/rules.md\" }\n    ],\n    \"templates\": [\n      { \"name\": \"模板名\", \"structure\": \"结构描述\", \"target_file\": \"templates/xxx.md\" }\n    ],\n    \"domain_knowledge\": [\n      { \"content\": \"知识内容\", \"domain\": \"领域\", \"target_file\": \"references/domain-xxx.md\" }\n    ],\n    \"examples\": [\n      { \"type\": \"minimal | normal | complex\", \"content\": \"示例内容\", \"target_file\": \"examples/xxx.md\" }\n    ],\n    \"standards\": [\n      { \"type\": \"scoring | quality | acceptance\", \"content\": \"标准内容\", \"target_file\": \"rubrics/xxx.md\" }\n    ],\n    \"best_practices\": [\n      { \"content\": \"实践内容\", \"target_file\": \"references/best-practices.md\" }\n    ]\n  },\n  \"role_matrix\": {\n    \"existing\": [\n      {\n        \"name\": \"角色名\",\n        \"responsibility\": \"职责\",\n        \"capabilities\": [\"关联能力\"],\n        \"should_split\": false,\n        \"split_reason\": \"\"\n      }\n    ],\n    \"to_add\": [\n      {\n        \"name\": \"建议角色名\",\n        \"reason\": \"为什么需要这个角色\",\n        \"responsibility\": \"职责\"\n      }\n    ]\n  }\n}\n```\n\n## Decision Gate\n\n| 条件 | 动作 |\n|------|------|\n| capability_graph.primary 非空 | → Pass 3 |\n| capability_graph 为空 | REJECT — Prompt 没有可提取的能力，不适合做 Skill |\n\nFile v1.2.1:references/pass-3-design.md\n\n# Pass 3: Design — Skill 架构设计\n\n**加载时机：** 📍 执行到 Pass 3 时加载。\n\n---\n\n## 设计原则\n\n**先设计系统，再设计 Prompt。绝不反过来。**\n\n原 16-phase 把 Workflow / References / Templates / Rubrics / Checklists / Config 拆成六步。但它们强关联——Workflow 决定需要什么 Checklist，Checklist 决定需要什么 Rubric。合并为一次架构设计。\n\n---\n\n## Step 3.1 — Architecture Type 决策\n\n| 条件 | architecture_type |\n|------|------------------|\n| 单次 LLM 调用，无状态 | `single-prompt` |\n| 多步骤顺序执行，有中间产出 | `workflow` |\n| 多角色并行或专业化 | `multi-agent` |\n\n### 决策树\n\n```\nPrompt 有多个步骤？\n  ├─ No → single-prompt\n  └─ Yes → 步骤间有并行或需要不同专业角色？\n            ├─ No → workflow\n            └─ Yes → multi-agent\n```\n\n---\n\n## Step 3.2 — Workflow Pattern 选择\n\n**仅 workflow / multi-agent 执行。** single-prompt 跳过。\n\n| 需求 | Pattern | 核心机制 |\n|------|---------|---------|\n| 输入类型多样，先判路再执行 | classify-and-act | 分类器路由 |\n| 多个独立子任务可并行 | fan-out-synthesize | 扇出+综合 |\n| 质量关键，需独立验证 | adversarial-verify | 对抗验证 |\n| 需要创意多样性，筛选最优 | generate-filter | 生成+过滤 |\n| 多方案成对比较选优 | tournament | 锦标赛 |\n| 需要迭代优化直到达标 | loop-until-done | 循环（上限3轮） |\n| 强制顺序，不能跳步 | pipeline | 管道+检查点 |\n\n可组合：如 classify-and-act 路由 → 每条路径内部用 pipeline。\n\n---\n\n## Step 3.3 — Single-Skill Pattern 选择\n\n**所有 Skill 必须选一个。** 与 workflow pattern 正交。\n\n| 需要什么？ | Pattern | 核心机制 |\n|------------|---------|---------|\n| 特定技术栈的专家知识 | tool-wrapper | SKILL.md 指向 references/ |\n| 一致的结构化输出 | generator | 模板 + 风格指南 |\n| 自动化代码/内容审查 | reviewer | 分离\"检查什么\"与\"怎么查\" |\n| 需求不明确，需先收集 | inversion | Agent 先采访用户 |\n| 复杂的多步骤任务 | pipeline | 强制顺序 + 检查点门控 |\n| 不确定？ | tool-wrapper | 最通用，可演进 |\n\n---\n\n## Step 3.4 — Module Decomposition\n\n基于 Pass 2 的 knowledge_inventory，决定模块拆分：\n\n| IR 字段 | 去向 | 拆分条件 |\n|---------|------|---------|\n| rules（> 5 条） | `references/rules.md` | 规则数 > 5 或总字数 > 200 |\n| rules（<= 5 条） | 内联 SKILL.md | 规则少且短 |\n| templates | `templates/*.md` | 有结构化输出 |\n| domain_knowledge | `references/domain-*.md` | 有领域知识 |\n| standards | `rubrics/*.md` | 有评分/质量标准 |\n| examples | `examples/*.md` | 有示例（或触发 Example Generation pass） |\n| honest-boundaries（v2.0） | `references/honest-boundaries.md` | **强制**：有 out_of_scope 或失败模式时必生成 |\n| conflicts（v2.0） | `references/conflicts.md` | Pass 2 检测到未裁决冲突时生成 |\n\n### 拆分原则\n\n1. **SKILL.md 最小化** — 只含路由 + 流程概览，< 300 行\n2. **知识外置** — 任何 > 200 字的知识块 → references/\n3. **配置参数化** — 可变的参数 → config/\n4. **模板独立** — 固定格式的输出 → templates/\n5. **诚实边界强制（v2.0）** — 每个 skill 必须规划 honest-boundaries 模块，即使初版为骨架。📍 详见 [honest-boundaries.md](honest-boundaries.md)\n\n---\n\n## Step 3.5 — Workflow Reconstruction\n\n**不要沿用 Prompt 顺序。** 以 Skill 为中心重新设计。\n\n### 每步定义\n\n| 字段 | 说明 |\n|------|------|\n| purpose | 这一步为什么存在 |\n| input | 输入是什么（来自上游或用户） |\n| output | 输出是什么（传给下游） |\n| decision_gate | 什么条件下继续/停止/重试 |\n| exit_criteria | 这一步完成的标志 |\n| retry_strategy | 失败时怎么办（最多 3 次） |\n| rollback_strategy | 无法完成时怎么办 |\n\n### Workflow 设计原则\n\n- **阶段化** — 每步有明确的进入/退出条件\n- **可恢复** — 任何一步失败不丢失上游产出\n- **可重试** — 失败后带反馈重试，有上限\n- **可扩展** — 新步骤可以插入，不破坏现有流程\n\n---\n\n## Step 3.6 — Reference Tree 设计\n\n规划 references/ 目录结构：\n\n```\nreferences/\n  ├── rules.md          # 规则集合\n  ├── domain-xxx.md     # 领域知识\n  ├── best-practices.md # 最佳实践\n  └── gotchas.md        # 常见陷阱（首次留骨架）\n```\n\n### 设计原则\n\n- 按主题分文件，不按 Prompt 顺序\n- 每个文件独立可读\n- 引用深度 = 1 层（SKILL.md → references/file.md，不嵌套）\n\n---\n\n## Step 3.7 — Checklist / Rubric / Config 设计\n\n### Checklist（检查清单）\n\n根据 architecture_type 生成：\n\n| 清单 | 内容 |\n|------|------|\n| Architecture Checklist | 模块边界、依赖方向、扩展点 |\n| Quality Checklist | 无 TODO、无 placeholder、< 300 行 |\n| Skill Checklist | frontmatter 合规、触发词、懒加载标记 |\n\n### Rubric（评分体系）\n\n当 Pass 2 有 standards 时生成。包含：\n\n| 组件 | 用途 |\n|------|------|\n| Scoring Rubric | 评分维度 + 权重 |\n| Risk Matrix | 风险等级矩阵 |\n| Priority Matrix | 优先级排序 |\n| Maturity Model | 成熟度分级 |\n\n### Config（配置）\n\n找出应该参数化的内容：\n\n```yaml\n# config/settings.yaml\nskill_name: string\nversion: string\nmax_iterations: 3  # 循环上限\noutput_format: markdown | json\n```\n\n---\n\n## Step 3.8 — Folder Structure 规划\n\n基于以上设计，输出目标目录树：\n\n```\nskill-name/\n  SKILL.md              # 入口 + 路由\n  references/           # 外置知识（按需加载）\n  workflows/            # 工作流定义（workflow/multi-agent）\n  templates/            # 输出模板\n  checklists/           # 检查清单\n  rubrics/              # 评分体系\n  config/               # 参数化配置\n  examples/             # 示例\n  schemas/              # JSON schema\n```\n\n**最小化原则：** 只创建需要的目录。single-prompt skill 不需要 workflows/。\n\n---\n\n## Step 3.9 — Self-Test Cases 派生\n\n**Pass 3 收尾必做。** 从 Pass 1 的 boundary 和 Pass 2 的 capability_graph 派生静态自测用例，供 Pass 6 Layer B/C 消费。\n\n**这是 IR 作为 test oracle 的关键步骤——不派生用例，Pass 6 就无 oracle 可用。**\n\n### 派生规则\n\n| 用例集 | 来源 | 说明 |\n|--------|------|------|\n| `positive` | `pass_1.boundary.in_scope` × `pass_2.capability_graph.primary` | 应触发 skill 的用户输入（组合场景 × 主能力） |\n| `negative` | `pass_1.boundary.out_of_scope` | 不应触发的用户输入（显式排除项） |\n| `near_miss` | `pass_2.capability_graph.secondary` − `pass_2.capability_graph.primary` | 语义近邻、容易误触发但不在主职责内的输入 |\n\n### 派生要求\n\n1. **positive 至少 3 条** — 覆盖主能力的典型用户表述\n2. **negative 至少 1 条** — 来自 boundary.out_of_scope（若为空，标注 `inferred: \"无显式排除项\"`）\n3. **near_miss 至少 0 条** — 若 secondary 为空则空数组（无近邻误触发风险）\n4. **用用户视角表述** — 写用户会怎么问，不写内部能力名（如\"帮我审一下这段 Python 代码\"而非\"调用 code-reviewer skill\"）\n\n### 示例\n\n```json\n{\n  \"self_test_cases\": {\n    \"positive\": [\n      \"审查这段 Python 代码的安全问题\",\n      \"检查这个函数有没有 bug\",\n      \"帮我 review 一下这个 PR\"\n    ],\n    \"negative\": [\n      \"帮我写一段 Python 代码\",\n      \"翻译这段技术文档\"\n    ],\n    \"near_miss\": [\n      \"审查这段 JavaScript 代码\"\n    ]\n  }\n}\n```\n\n### 派生完成后\n\n`self_test_cases` 写入 IR 的 `pass_3_design.self_test_cases`。Pass 6 Layer B/C 直接读取此字段，无需重新生成用例。\n\n---\n\n## Step 3.10 — Skill Interlinking（v2.0 可选）\n\n**仅当一次编译产出多个相关 skill 时执行**（如从一份长文档蒸馏出多个方法论 skill）。单 skill 编译跳过此步。\n\n当输出包含多个 skill 模块时，规划它们之间的关系图谱，生成 `INDEX.md` 作为技能地图：\n\n### 关系类型\n\n| 关系 | 含义 | 示例 |\n|------|------|------|\n| `depends_on` | A 的执行依赖 B 先完成 | \"代码审查\" depends_on \"静态分析\" |\n| `complements` | A 与 B 互补，组合使用效果更好 | \"PEP8 检查\" complements \"安全审计\" |\n| `contradicts` | A 与 B 在某些场景给出冲突建议 | 记录冲突，指向 conflicts.md |\n| `alternative` | A 与 B 是同一问题的不同方案 | 标注各自适用场景 |\n\n### INDEX.md 模板\n\n```markdown\n# Skill Index — 技能地图\n\n## 包含的 Skills\n| Skill | 职责 | 触发场景 |\n|-------|------|---------|\n| {name} | {一句话} | {when} |\n\n## 关系图\n- {SkillA} → depends_on → {SkillB}\n- {SkillC} → complements → {SkillD}\n\n## 推荐组合\n{哪些 skill 适合串联使用}\n```\n\n### 设计原则\n\n- INDEX.md 是**可选输出**，只在多 skill 产出时生成\n- 关系图帮助用户理解 skill 间的协作方式，而非孤立使用\n- `contradicts` 关系必须指向 `references/conflicts.md` 的具体条目\n\n### Step 3.11 — Meta-Reflection Checkpoint（v2.1）\n\n在设计产出 IR 之前，用以下 3 个维度二次审视设计决策。Quick 模式跳过此步。\n\n📍 完整框架见 [meta-reflection.md](meta-reflection.md)\n\n| 维度 | 自检问题 | 触发条件 |\n|------|---------|---------|\n| D3 推理 | architecture_type 的决策链是否有跳跃？模块拆分标准是否前后一致？ | 总是 |\n| D5 替代解释 | 是否考虑过至少 1 个替代架构并给出诚实的淘汰理由？替代方案的优势是否被如实评估？ | architecture_type 非 single-prompt |\n| D6 边界条件 | out_of_scope 条目是否足够具体？当前设计在输入为空/极长/格式退化时是否仍适用？ | 总是 |\n\n**输出：** 自省结果写入 trace。如果发现设计漏洞，在进入 Pass 4 前修正 IR。\n\n---\n\n## Output Schema\n\n```json\n{\n  \"architecture_type\": \"single-prompt | workflow | multi-agent\",\n  \"workflow_pattern\": \"pattern name | null\",\n  \"single_skill_pattern\": \"tool-wrapper | generator | reviewer | inversion | pipeline\",\n  \"self_test_cases\": {\n    \"positive\": [\"应触发的用户输入\"],\n    \"negative\": [\"不应触发的用户输入\"],\n    \"near_miss\": [\"易误触发的近邻输入\"]\n  },\n  \"module_decomposition\": {\n    \"core_prompt\": \"SKILL.md 核心职责描述\",\n    \"workflows\": [\"workflow 文件列表\"],\n    \"references\": [\"reference 文件列表 + 内容概述\"],\n    \"checklists\": [\"checklist 列表\"],\n    \"rubrics\": [\"rubric 列表\"],\n    \"templates\": [\"template 列表\"],\n    \"configs\": [\"config 参数列表\"]\n  },\n  \"workflow_steps\": [\n    {\n      \"id\": \"step-1\",\n      \"purpose\": \"为什么存在\",\n      \"input\": \"输入\",\n      \"output\": \"输出\",\n      \"decision_gate\": \"继续条件\",\n      \"exit_criteria\": \"完成标志\",\n      \"retry_strategy\": \"重试策略\",\n      \"rollback_strategy\": \"回滚策略\"\n    }\n  ],\n  \"reference_tree\": [\"references/xxx.md\"],\n  \"folder_structure\": \"目录树字符串\"\n}\n```\n\n## IR 合并\n\nPass 3 完成后，将 pass_1_analyze、pass_2_extract、pass_3_design 三个字段合并为完整 Skill IR。合并后必须通过 schema 校验才能进入 Pass 4。\n\n## Decision Gate\n\n| 条件 | 动作 |\n|------|------|\n| architecture_type 确定 + folder_structure 非空 + IR 通过 schema 校验 | → Pass 4 |\n| IR 校验失败（字段缺失/类型错误） | 修复 IR 缺失字段后重新校验 |\n| 无法确定 architecture_type | 向用户澄清使用场景 |\n\n### IR 校验\n\n📍 IR schema 定义见 [schemas/ir-schema.json](../schemas/ir-schema.json)\n\nPass 3→4 门控时，对合并后的 IR 执行以下校验：\n\n| # | 校验项 | FAIL 处理 |\n|---|--------|----------|\n| 1 | `meta`、`pass_1_analyze`、`pass_2_extract`、`pass_3_design` 四个顶层字段齐全 | 补齐缺失 Pass 的 IR |\n| 2 | `pass_2_extract.capability_graph.primary` 非空（≥1 个） | 回退 Pass 2 补充能力图谱 |\n| 3 | `pass_3_design.architecture_type` 为 single-prompt / workflow / multi-agent 之一 | 回退 Pass 3 确定架构类型 |\n| 4 | `pass_3_design.single_skill_pattern` 已选择 | 回退 Pass 3 选择 single-skill pattern |\n| 5 | `pass_3_design.folder_structure` 非空 | 回退 Pass 3 规划目录结构 |\n| 6 | `pass_3_design.self_test_cases.positive` ≥ 3 条 | 回退 Pass 3 Step 3.9 补充 positive 用例 |\n| 7 | `pass_3_design.self_test_cases.negative` ≥ 1 条（或标注 inferred） | 回退 Pass 3 Step 3.9 补充 negative 用例 |\n\n全部 PASS → 进入 Pass 4。\n\nFile v1.2.1:references/pass-4-generate.md\n\n# Pass 4: Generate — 生成 Skill 包\n\n**加载时机：** 📍 执行到 Pass 4 时加载。\n\n---\n\n## 生成原则\n\n1. **IR 驱动** — 所有文件内容来自 Pass 1-3 的 IR，不凭空创造\n2. **三层加载** — L1 frontmatter / L2 SKILL.md 路由 / L3 references 懒加载\n3. **平台感知渲染** — frontmatter、description、文件结构按 `target_platform` 对应的 profile 规范渲染\n4. **frontmatter 卫生** — 只含目标平台要求的字段（generic/trae 仅 name + description）\n5. **无占位符** — 不留 TODO/TBD/placeholder\n6. **文件最小化** — 只生成 IR 要求的文件，不多创建\n\n---\n\n## Step 4.1 — SKILL.md 生成\n\n### Step 4.0 — 加载目标平台 Profile\n\n读取 `meta.target_platform` 并加载对应 profile：\n\n| target_platform | Profile 文件 |\n|----------------|-------------|\n| `trae`         | 📍 [profiles/trae.md](../profiles/trae.md) |\n| `claude`       | 📍 [profiles/claude.md](../profiles/claude.md) |\n| `generic`      | 📍 [profiles/generic.md](../profiles/generic.md) |\n\n后续渲染步骤全部参考 profile 中定义的约束（description 格式、触发词策略、文件结构支持列表）。\n\n### Frontmatter — 按平台渲染\n\n#### TRAE 平台\n\n```yaml\n---\nname: {kebab-case-name}\ndescription: \"Use when {触发场景}. Triggers on: {触发词1}, {触发词2}, {触发词3}. {核心功能一句话}\"\n---\n```\n\n**约束：**\n- description 必须为**严格单行 YAML 字符串**，不支持多行 block scalar\n- ≤ 500 字符\n- 触发词用「逗号 + 空格」分隔\n- 不包含 `version` 等额外 frontmatter 字段\n\n#### Claude 平台\n\n```yaml\n---\nname: {kebab-case-name}\ndescription: >\n  Use when {触发场景}.\n\n  Triggers on:\n  - {触发词1}\n  - {触发词2}\n  - {触发词3}\n\n  {核心功能一句话描述}\nversion: 1.0.0\n---\n```\n\n**约束：**\n- description 支持多行 block scalar（`>` 或 `|`）\n- ≤ 500 字符\n- 触发词支持列表格式（每行一个）\n- 可包含 `version` 等额外字段\n\n#### Generic 平台（默认）\n\n```yaml\n---\nname: {kebab-case-name}\ndescription: \"Use when {触发场景}. Triggers on: {触发词1}, {触发词2}, {触发词3}. {核心功能一句话}\"\n---\n```\n\n**约束：**\n- description 严格单行（兼容所有 YAML 解析器）\n- ≤ 300 字符（最严格限制）\n- frontmatter 只保留 name + description\n\n---\n\n**description 通用规则（所有平台）：**\n- 以 \"Use when\" / \"Use for\" 开头\n- 包含 3+ 用户可能输入的触发词\n- 聚焦用户意图，不描述内部机制\n\n### Body 结构\n\n```markdown\n# {Skill Name}\n\n{一句话定位}\n\n## 核心流程\n{3-5 步流程概览，每步一句话}\n\n## 执行步骤\n### Step 1 — {名称}\n📍 加载文件: references/xxx.md\n{简要说明 + 输入输出}\n\n### Step 2 — {名称}\n...\n\n## 输出格式\n{输出 schema 或模板引用}\n\n## Gotchas\n{常见陷阱，首次留骨架}\n```\n\n### 行数控制\n\n- **< 150 行：** 理想\n- **150-300 行：** 可接受\n- **> 300 行：** 必须拆分（AP-02 Prompt Black Hole）\n\n### 平台感知的文件结构约束\n\n生成 `references/` 和可能的工作流/agent 目录时，参考目标平台的 profile：\n\n| 目录 | generic | trae | claude |\n|------|---------|------|--------|\n| `references/` | ✅ | ✅ | ✅ |\n| `templates/` | ✅ | ✅ (放 references/ 更安全) | ✅ |\n| `workflows/` | ❌ | ❌ | ✅ |\n| `agents/` | ❌ | ❌ | ✅ |\n| `rubrics/` | ❌ | 放 references/ 内 | ✅ |\n| `checklists/` | ❌ | 放 references/ 内 | ✅ |\n\n**规则：** 不生成目标平台不支持的目录。必须生成的 reference 文件全部放在 `references/` 或模板所在平台允许的位置。\n\n---\n\n## Step 4.2 — References 生成\n\n对 Pass 3 的 `reference_tree` 中每个文件：\n\n### rules.md 模板\n\n```markdown\n# Rules\n\n{从 knowledge_inventory.rules 逐条列出}\n\n## 规则列表\n\n| # | 规则 | 来源 |\n|---|------|------|\n| 1 | {规则内容} | source / inferred |\n```\n\n### domain-xxx.md 模板\n\n```markdown\n# {Domain} Knowledge\n\n## {Topic 1}\n{知识内容}\n\n## {Topic 2}\n{知识内容}\n```\n\n### best-practices.md 模板\n\n```markdown\n# Best Practices\n\n## {Practice 1}\n{内容 + 为什么}\n\n## {Practice 2}\n{内容 + 为什么}\n```\n\n### gotchas.md 模板（首次骨架）\n\n```markdown\n# Gotchas / Footguns\n\n> 上线后根据实际 failure case 填充。\n\n## 常见失败点\n- TODO: {占位 — 替换为实际失败模式}\n\n## 字段/命名歧义\n- TODO: {占位}\n\n## 边界条件\n- TODO: {占位}\n```\n\n---\n\n## Step 4.3 — Workflows 生成（workflow/multi-agent only）\n\n对 Pass 3 的 `workflow_steps` 生成 YAML：\n\n```yaml\nname: {skill-name}-{workflow-name}\ndescription: {工作流描述}\n\ninput:\n  type: object\n  required: [{必需字段}]\n  properties:\n    {field}: { type: string }\n\nsteps:\n  - id: {step-id}\n    agent: {agent-name}\n    description: {步骤描述}\n    input:\n      {field}: \"{{input.xxx}}\"\n    output: {output-var}\n    when: [{条件表达式，可选}]\n```\n\n---\n\n## Step 4.4 — Templates 生成\n\n对 Pass 3 的 `module_decomposition.templates`：\n\n```markdown\n# {Template Name}\n\n## 变量\n| 变量 | 说明 | 必填 |\n|------|------|------|\n| {var} | {描述} | yes/no |\n\n## 模板\n---\n{模板内容，用 {{var}} 标记变量}\n---\n```\n\n---\n\n## Step 4.5 — Checklists 生成\n\n```markdown\n# {Checklist Name}\n\n## 检查项\n\n| # | 检查项 | 如何检查 | PASS 标准 |\n|---|--------|---------|-----------|\n| 1 | {检查内容} | {方法} | {标准} |\n```\n\n---\n\n## Step 4.6 — Rubrics 生成（当有 standards 时）\n\n```markdown\n# {Rubric Name}\n\n## 评分维度\n\n| 维度 | 权重 | 评分标准 |\n|------|------|---------|\n| {维度} | {X}% | {1-5 分的描述} |\n\n## 风险矩阵\n| 风险 | 概率 | 影响 | 等级 |\n|------|------|------|------|\n\n## 成熟度模型\n| 级别 | 特征 |\n|------|------|\n| L1 | {描述} |\n| L2 | {描述} |\n| L3 | {描述} |\n```\n\n---\n\n## Step 4.7 — Config 生成（当有参数化时）\n\n```yaml\n# config/settings.yaml\nskill_name: {name}\nversion: 1.0.0\n{参数}: {默认值}\n```\n\n---\n\n## Step 4.8 — Schemas 生成（当有结构化输出时）\n\n```json\n{\n  \"$schema\": \"http://json-schema.org/draft-07/schema#\",\n  \"title\": \"{Skill} Output\",\n  \"type\": \"object\",\n  \"required\": [\"field1\"],\n  \"properties\": {\n    \"field1\": { \"type\": \"string\", \"description\": \"...\" }\n  }\n}\n```\n\n---\n\n## Step 4.9 — Self-Check（生成后立即执行）\n\n| # | 检查项 | FAIL 处理 |\n|---|--------|----------|\n| 1 | frontmatter 符合目标平台 profile 规范 | 按 profile 重写 |\n| 2 | description 触发导向（Use when + 3+ 触发词） | 重写 description |\n| 3 | SKILL.md < 300 行 | 拆分到 references |\n| 4 | 所有 📍 标记的文件存在 | 创建缺失文件 |\n| 5 | 无 TODO/TBD/placeholder（gotchas.md 骨架除外） | 填充或移除 |\n| 6 | 每个文件被至少一个其他文件引用 | 移除孤立文件或添加引用 |\n| 7 | 未生成目标平台不支持的目录 | 移入 references/ |\n| 8 | 已设置 `meta.platform_profile_applied = true` | 设置标记 |\n\n任一 FAIL → 修复后重新检查，全部 PASS → 进入 Pass 5/6。\n\nArchive v1.2.0: 23 files, 55271 bytes\n\nFiles: docs/self-compilation-audit.md (5798b), examples/example-compilation.md (5839b), examples/example-workflow-compilation.md (10163b), profiles/claude.md (2182b), profiles/generic.md (1780b), profiles/trae.md (2306b), README.md (11086b), references/anti-patterns.md (2498b), references/example-generation.md (1283b), references/pass-1-analyze.md (3171b), references/pass-2-extract.md (5009b), references/pass-3-design.md (10229b), references/pass-4-generate.md (7107b), references/pass-5-optimize.md (4743b), references/pass-6-validate.md (12827b), references/plugin-discovery.md (1377b), schemas/ir-schema.json (11900b), schemas/trace-schema.json (6422b), skill-card.md (2244b), SKILL.md (10213b), templates/ir-schema.md (4418b), templates/skill-md-template.md (1615b), _meta.json (132b)\n\nFile v1.2.0:SKILL.md\n\n---\nname: skill-compiler\ndescription: \"Use when you need to compile, convert, transform, or refactor any existing prompt into a production-grade, reusable AI Skill. Triggers on: 'prompt to skill', 'compile prompt', '把 prompt 变成 skill', '提示词编译', '提示词转技能', 'skill from prompt'. Outputs a complete skill package with modular architecture. Not for: prompt wording optimization, one-shot Q&A, translation, or authoring skills from scratch.\"\nversion: 1.2.0\n---\n\n# Skill Compiler\n\n**Prompt → Skill IR → Optimized Skill Package**\n\n你不是 Prompt Engineer。你是一位 AI Skill Architect + Compiler Engineer。你的任务不是优化 Prompt，而是把任意 Prompt **编译** 成一个可复用、可维护、可扩展、可持续演化的 AI Skill。\n\n---\n\n## Optimization Goals\n\n整个编译过程中持续优化，而非机械转换。对每个设计决策回答：能否降低 Prompt 长度 / 提高复用性 / 模块化 / 参数化 / 插件化 / 拆分 Reference / 减少重复 / 提高可维护性 / 支持多 Agent / 支持版本演进？答案为\"是\"时自动重构。\n\n---\n\n## Core Principles\n\n| # | 原则 | 含义 |\n|---|------|------|\n| P1 | Prompt 不是 Skill | Skill = Role + Workflow + Knowledge + Decision Logic + Checklist + Rubric + Templates + Examples + Config + References + Output Schema |\n| P2 | 重复内容外置 | 超过一次使用的内容 → `references/` |\n| P3 | Prompt 最小化 | 知识外置，Workflow 独立，配置参数化 |\n| P4 | 不照搬 Prompt | 以 Skill 为中心重新设计，保留\"能力\"而非\"文字\" |\n\n---\n\n## Compiler Pipeline\n\n```\nSource Prompt → [Pass 0: Triage] → [Pass 1: Analyze] → [Pass 2: Extract]\n  → [Pass 3: Design] → [Pass 4: Generate] → [Pass 5: Optimize?]\n  → [Pass 6: Validate] → Skill Package\n```\n\n| Pass | 执行 | 职责 | 详情 |\n|------|------|------|------|\n| **0 Triage** | ✅ 总是 | 判断是否值得编译 | 内联（决策表见下） |\n| **1 Analyze** | ✅ 总是 | 理解 Prompt：目标/输入输出/边界/假设 | 📍 [references/pass-1-analyze.md](references/pass-1-analyze.md) |\n| **2 Extract** | ✅ 总是 | 能力图谱 + 知识清单 + 角色矩阵 | 📍 [references/pass-2-extract.md](references/pass-2-extract.md) |\n| **3 Design** | ✅ 总是 | 架构类型 + 模块拆分 + Workflow + 目录结构 + 自测用例派生 | 📍 [references/pass-3-design.md](references/pass-3-design.md) |\n| **4 Generate** | ✅ 总是 | 生成完整 Skill 文件包 | 📍 [references/pass-4-generate.md](references/pass-4-generate.md) |\n| **5 Optimize** | ⚠️ 条件 | Prompt > 500字 / 重复 / multi-agent 时执行 | 📍 [references/pass-5-optimize.md](references/pass-5-optimize.md) |\n| **6 Validate** | ✅ 总是 | 三层评估：结构完整性（A）+ IR 一致性（B）+ 触发质量（C） | 📍 [references/pass-6-validate.md](references/pass-6-validate.md) |\n\n**条件 Pass：**\n\n| Pass | 触发条件 | 详情 |\n|------|---------|------|\n| Plugin Discovery | Prompt 涉及外部能力（搜索/GitHub/DB/浏览器/MCP） | 📍 [references/plugin-discovery.md](references/plugin-discovery.md) |\n| Example Generation | Skill 涉及复杂流程/规则/评分体系 | 📍 [references/example-generation.md](references/example-generation.md) |\n\n---\n\n## Pass 0 — Triage（内联决策）\n\n### Step 0.1 — 判断输入是否值得编译\n\n| 输入类型 | 判定 | Action |\n|---------|------|--------|\n| 一次性问答，无复用价值 | 不是 Skill | REJECT — 直接回答 |\n| 纯翻译/摘要/解释 | 不是 Skill | REJECT — 直接执行 |\n| 会反复使用 + 有可复用输出契约 | 是 Skill | → Step 0.2 |\n| 容易路由错误的复杂工作流 | 是 Skill | → Step 0.2 |\n\nREJECT 时告知\"这不建议做成 skill，因为 X\"，并直接完成请求。\n\n### Step 0.2 — 确定目标平台\n\n选择生成的 Skill 将在哪个平台运行。平台选择影响 frontmatter 格式、description 渲染风格、触发词策略和文件结构约束。\n\n| 平台 | 适用场景 | 特性 |\n|------|---------|------|\n| `trae` | TRAE IDE Skill | description 单行、触发词关键词匹配、references/ 懒加载 |\n| `claude` | Claude.ai / Claude Code | description 可多行、语义匹配、agents/ 目录支持 |\n| `generic` | 未知平台/未来平台 | 最保守的规范，最大兼容性 |\n\n**用户未指定时**，默认为 `generic`。高级用户可在编译过程中的 `unknowns` 阶段被询问。\n\n📍 平台规范文件: [profiles/trae.md](profiles/trae.md), [profiles/claude.md](profiles/claude.md), [profiles/generic.md](profiles/generic.md)\n\n### Step 0.3 — 选择编译模式\n\n根据源 Prompt 的复杂度和用户对成本/质量的权衡选择模式：\n\n| 模式 | Token 开销 | 执行 Pass | 适用场景 |\n|------|-----------|-----------|---------|\n| `quick` | 低（~3 次调用） | 0 → 1 → 3(轻) → 4 → 6(A层) | Prompt < 200 字，已熟悉 Skill 结构 |\n| `full` | 高（~6+ 次调用） | 0 → 1 → 2 → 3 → 4 → 5?(条件) → 6(全部三层) | Prompt 复杂，需要完整能力提取与验证 |\n| `audit` | 中（~2 次调用） | 6(全部四层) | 评估已有 Skill，不生成新文件 |\n\n**默认模式：** `full`。Token 敏感时建议手动选 `quick`。\n\n### Step 0.4 — 设定 Token 预算（可选）\n\n用户可设定本次编译的 token 总预算上限：\n\n- `total_budget` — 硬上限。0 表示无限制（默认）\n- `mode_change_at_pct` — 消耗达到预算 N% 时自动降级模式（默认 80%）\n- 超预算时编译器自动降级（`full` → `quick`）并记录到 trace\n\n**未设定预算时**，使用模式默认的调用次数估算。\n\n### Step 0.5 — 写入 IR\n\n```\nmeta.target_platform       = 用户选择或默认\nmeta.compilation_mode      = 用户选择或默认\nmeta.token_budget          = 用户设定或默认值\n```\n\n---\n\n## Execution Rules\n\n1. **Pass 1-3 产出 Skill IR**（中间表示），不生成文件。📍 IR schema 见 [templates/ir-schema.md](templates/ir-schema.md)\n2. **Pass 4 基于 IR + 目标平台 profile 生成文件。** 按平台规范渲染 frontmatter、description 和文件结构。📍 生成模板见 [templates/skill-md-template.md](templates/skill-md-template.md)\n3. **每个 Pass 通过 IR 通信**，不直接传递未结构化文本\n4. **Decision Gate：** 每个 Pass 末尾有通过条件（详见各 pass 文件），不满足时向用户澄清\n5. **条件 Pass 由编译器自主判断**，不强制执行全部\n6. **平台 profile 应用时机：** Pass 4 生成时同时加载目标 platform profile，按 profile 规范渲染输出。Pass 6 Layer D 反向验证。\n7. **Token 估计门槛：** 每次 Pass 完成后在 IR 中更新 `token_budget.current_estimate`。若 `current_estimate > total_budget × mode_change_at_pct / 100`，自动降级编译模式。\n\n---\n\n## Final Output\n\n编译完成后输出 Compilation Report：\n\n- **Skill Summary** — 名称 + 一句话描述\n- **Folder Tree** — 生成的目录结构\n- **Passes Executed** — 实际执行的 Pass 列表\n- **Module Dependency Graph** — 核心模块依赖关系\n- **Evaluation Report** — Pass 6 四层评估结果：\n  - Layer A 结构完整性 pass_rate\n  - Layer B IR 一致性 pass_rate（IR 作为 test oracle 验证产出）\n  - Layer C 触发质量 trigger_precision（self_test_cases 静态匹配）\n  - Layer D 平台合规 pass_rate（按 target platform profile 验证）\n  - 综合评分 `skill_quality_score`（0-100，含 Layer D）\n- **Cost Summary** — 编译成本汇总：\n  - 总 token 消耗（输入 + 输出）\n  - 执行的 Pass 列表 / 跳过的 Pass 列表\n  - Token 预算消费百分比（如设定了预算）\n- **Validation Result** — Pass 6 verdict + issues\n- **Technical Debt** — 已知技术债务\n- **Extension Roadmap** — 未来可扩展方向\n\n---\n\n## Gotchas / Footguns\n\n> 以下为已知的编译失败模式和风险点。\n\n1. **AP-11 风险（单轨迹过拟合）** — 不要基于单次编译经验调整哪些 Pass 该执行/跳过。Pass 的触发/跳过条件应基于显式规则（本 SKILL.md 定义的条件），而非\"上次编译时我跳过了这个 Pass 所以这次也跳\"。批量编译经验归纳后才可调整 Pass 触发策略。\n2. **IR 字段缺失是最常见的失败原因** — LLM 产出 IR 时常遗漏 `capability_graph.primary` 或 `folder_structure`。Pass 3→4 门控必须校验全部必填字段（见 [schemas/ir-schema.json](schemas/ir-schema.json)），缺失时回退而非硬闯 Pass 4。\n3. **Pass 5 条件判断不能只看输入长度** — 即使 Source Prompt < 500 字，生成的文件包中也可能出现重复知识（>= 3 处相同内容）。Pass 5 的触发条件应同时检查\"输入长度\"和\"输出重复度\"。\n4. **trace 产出不能省略** — trace-schema.json 定义的执行 trace 是下游消费者（如 SkillForge L4/L5）的契约输入。每次编译必须在 Final Output 中产出 trace。\n5. **平台 profile 必须显式指定才生效** — 默认 `generic` profile 生成最保守的输出。若要利用特定平台特性（如 TRAE 的触发词策略、Claude 的多行 description），需在 Pass 0 显式选择目标平台。先编译后改 description 会丢失 Pass 6 Layer D 的验证闭环。\n6. **Token 预算不能设得过于紧张** — `quick` 模式 ≈ 3 次 LLM 调用。如果 `total_budget` 设得低于 3 次调用的估算量，编译器可能在 Pass 0 就触发降级，实际执行与预期不符。建议 `quick` 预算 ≥ 5K tokens，`full` 预算 ≥ 15K tokens（估算值，因模型而异）。\n7. **不同平台间迁移需要重新编译** — 同一个 prompt 编译为 TRAE 和 Claude 的 skill 是两个不同的输出。平台 profile 不同，frontmatter、description 格式、触发词策略、文件结构都可能不同。直接复制文件到另一个平台大概率不可用。\n\n---\n\n## Provenance\n\n- **Built with:** SkillForge (Full mode)\n- **Source:** User-provided \"Prompt → Skill Compiler v1.0\" spec, refactored from 16 fixed phases to 6 core + 3 conditional compiler passes\n- **Design decision:** Phase → Compiler Pass model (conditional execution, IR-based)\n\nFile v1.2.0:README.md\n\n<div align=\"center\">\n\n# Skill Compiler\n\n**Prompt → Skill IR → Optimized Skill Package**\n\n把任意 Prompt 编译成可复用、可维护、可持续演化的 AI Skill\n\n[![Author](https://img.shields.io/badge/Author-qomob.ai-blue)](https://qomob.ai)\n[![Version](https://img.shields.io/badge/Version-v1.2.0-green.svg)](https://github.com/qomob/SkillCompiler)\n[![Language](https://img.shields.io/badge/Language-%E4%B8%AD%E6%96%87-red.svg)](https://github.com/qomob/SkillCompiler)\n[![License](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)\n[![Built with](https://img.shields.io/badge/Built_with-SkillForge-violet.svg)](https://github.com/qomob/skillforge)\n\n</div>\n\n---\n\n## 这是什么\n\nSkill Compiler 是一个 **Meta Skill（元技能）**——它的输入是任意 Prompt，输出是一个完整的、结构化的 AI Skill 文件包。\n\n它不是\"Prompt 优化器\"。它是一个 **Prompt 编译器**：保留 Prompt 背后的\"能力（Capability）\"，而非 Prompt 本身的文字。\n\n```\nSource Prompt\n      │\n      ▼\n  Analyze → Extract → Design → Generate → Optimize → Validate\n      │\n      ▼\n  Complete Skill Package\n```\n\n---\n\n## 核心特性\n\n- **编译器架构** — 6 个核心 Pass + 3 个条件 Pass，编译器自主判断需要执行哪些\n- **Skill IR 中间表示** — Pass 1-3 产出 IR，Pass 4 基于 IR 生成文件，Pass 间通过 IR 通信\n- **条件执行** — 简单 Prompt 跳过 Optimize，不涉及外部能力时跳过 Plugin Discovery\n- **三层评估闭环（v1.1 新增）** — Pass 6 从单一结构审查升级为三层评估：\n  - **Layer A 结构完整性** — 五角色架构审查（Skill Architect / Knowledge Engineer / Workflow Designer / Prompt Engineer / Software Architect）\n  - **Layer B IR 一致性** — IR 作为 test oracle，逐字段验证生成文件是否忠实于 IR 契约（B1-B8 共 8 项）\n  - **Layer C 触发质量** — Pass 3 从 boundary + capability_graph 派生 self_test_cases，静态匹配 description 计算触发精度，零运行时依赖\n- **编译模式选择（v1.2 新增）** — `quick` / `full` / `audit` 三种模式，在不同 token 成本与编译质量间做权衡\n- **平台适配（v1.2 新增）** — 支持 TRAE / Claude / Generic 三类宿主平台，自动按平台规范渲染 frontmatter 与文件结构\n- **Token 预算控制（v1.2 新增）** — 设定编译预算上限，超限时自动降级模式\n- **四层评估闭环（v1.2 新增）** — Pass 6 新增 **Layer D 平台合规**检查，验证生成文件是否符合目标平台 profile 约束\n- **三层渐进加载** — 生成的 Skill 遵循 L1 触发 / L2 路由 / L3 懒加载分层\n- **自编译验证** — Skill Compiler 用自己的 Pass 6 评估了自己，首轮 85.5 分检出 5 个 issue，修复后 100 分通过。审查记录见 [docs/self-compilation-audit.md](docs/self-compilation-audit.md)\n\n---\n\n## Compiler Pipeline\n\n| Pass | 执行 | 职责 |\n|------|------|------|\n| **0 Triage** | ✅ 总是 | 判断输入是否值得编译为 Skill + 选择目标平台 + 选择编译模式 + 设定 Token 预算 |\n| **1 Analyze** | ✅ 总是 | 理解 Prompt：目标 / 输入输出 / 边界 / 假设 |\n| **2 Extract** | ✅ 总是 | 能力图谱 + 知识清单 + 角色矩阵 |\n| **3 Design** | ✅ 总是 | 架构类型 + 模块拆分 + Workflow + 目录结构 + 自测用例派生 |\n| **4 Generate** | ✅ 总是 | 基于 IR + 目标平台 profile 生成符合平台规范的完整 Skill 文件包 |\n| **5 Optimize** | ⚠️ 条件 | Prompt > 500字 / 重复 / multi-agent 时执行；含 O9 编译去重 + O10 IR 瘦身（v1.2） |\n| **6 Validate** | ✅ 总是 | 四层评估：结构完整性（A）+ IR 一致性（B）+ 触发质量（C）+ 平台合规（D） |\n| Plugin Discovery | ❌ 条件 | 涉及外部能力（搜索/GitHub/DB/MCP）时执行 |\n| Example Generation | ❌ 条件 | 涉及复杂流程/规则/评分体系时执行 |\n\n---\n\n## 文件结构\n\n```\nskill-compiler/\n├── SKILL.md                        # 入口 + 路由 manifest（< 150 行）\n├── README.md                       # 本文件\n├── profiles/                       # 目标平台规范（v1.2 新增）\n│   ├── trae.md                     #   TRAE IDE Skill 规范\n│   ├── claude.md                   #   Claude.ai / Claude Code 规范\n│   └── generic.md                  #   默认通用规范\n├── references/\n│   ├── pass-1-analyze.md           # Pass 1: 理解 Prompt\n│   ├── pass-2-extract.md           # Pass 2: 能力/知识/角色抽取\n│   ├── pass-3-design.md            # Pass 3: 架构设计 + 自测用例派生\n│   ├── pass-4-generate.md          # Pass 4: 生成文件包\n│   ├── pass-5-optimize.md          # Pass 5: 条件优化 + O9/O10（v1.2）\n│   ├── pass-6-validate.md          # Pass 6: 四层评估（A 结构 / B IR 一致性 / C 触发质量 / D 平台合规）\n│   ├── anti-patterns.md            # 反模式定义（AP-02/04/06/07/12）\n│   ├── plugin-discovery.md         # 条件 Pass: 插件识别\n│   └── example-generation.md       # 条件 Pass: 示例生成\n├── templates/\n│   ├── skill-md-template.md        # SKILL.md 输出模板\n│   └── ir-schema.md                # Skill IR 中间表示 schema\n├── examples/\n│   ├── example-compilation.md      # 完整编译示例（Python 代码审查）\n│   └── example-workflow-compilation.md  # Workflow 类型编译示例\n├── schemas/\n│   ├── ir-schema.json              # Skill IR JSON Schema（含 target_platform / compilation_mode）\n│   └── trace-schema.json           # 执行 trace 契约（含 cost_summary + Layer D）\n└── docs/\n    └── self-compilation-audit.md   # 自编译审计记录\n```\n\n---\n\n## 快速开始\n\n给 Skill Compiler 一个 Prompt，它会：\n\n1. **Pass 0** — 判断是否值得编译 + 选择目标平台 + 选择编译模式 + 设定 Token 预算\n2. **Pass 1-3** — 分析 → 抽取 → 设计，产出 Skill IR（含自测用例）\n3. **Pass 4** — 基于 IR + 目标平台 profile 生成平台适配的文件包\n4. **Pass 5** — 条件触发优化（含 O9 编译去重 + O10 IR 瘦身）\n5. **Pass 6** — 四层评估（A 结构 / B IR 一致性 / C 触发质量 / D 平台合规），输出评分 + GO/NO-GO\n6. 输出 **Compilation Report** + 完整 Skill 包（含 Cost Summary）\n\n### Pass 6 评分公式（v1.2）\n\n```\nskill_quality_score = structural_pass_rate     × 0.2    (Layer A)\n                    + ir_consistency_rate      × 0.3    (Layer B)\n                    + trigger_precision        × 0.25   (Layer C)\n                    + platform_compliance_rate × 0.25   (Layer D)\n```\n\n| 分数 | Verdict |\n|------|---------|\n| ≥ 85 且 0 Critical | **GO** |\n| 60-84 或有 Critical 但可修复 | **CONDITIONAL** |\n| < 60 | **NO-GO** |\n\n### 示例输入\n\n```\n你是一个 Python 代码审查专家。用户会给你一段 Python 代码，你需要：\n1. 检查代码风格（PEP 8）\n2. 检查常见 bug\n3. 检查安全问题\n4. 给出改进建议\n5. 按严重程度分级：Critical / Warning / Info\n```\n\n### 示例输出\n\n```\ncode-reviewer/\n  SKILL.md                  # 80 行路由\n  references/\n    pep8-rules.md           # PEP 8 规则\n    bug-patterns.md         # 常见 bug 模式\n    security-checks.md      # 安全检查项\n  templates/\n    review-report.md        # 报告模板\n  rubrics/\n    severity-rubric.md      # 严重度分级\n```\n\n详见 [examples/example-compilation.md](examples/example-compilation.md)。\n\n---\n\n## 设计原则\n\n| 原则 | 含义 |\n|------|------|\n| Prompt 不是 Skill | Skill = Role + Workflow + Knowledge + Decision Logic + Checklist + Rubric + Templates + Examples + Config + References + Output Schema |\n| 重复内容外置 | 超过一次使用的内容 → `references/` |\n| Prompt 最小化 | 知识外置，Workflow 独立，配置参数化 |\n| 不照搬 Prompt | 以 Skill 为中心重新设计，保留\"能力\"而非\"文字\" |\n\n---\n\n## 与 SkillForge 的关系\n\nSkill Compiler 由 [SkillForge](https://github.com/qomob/skillforge) Full 模式构建，通过了完整的 5 层验证（Triage → Create → Validate → Audit → Deploy Decision），Compliance Score 100%，Gaming Gate PASS。\n\n---\n\n## Changelog\n\n### v1.2.0 — 平台适配与成本控制\n\n**核心变更：** 引入目标平台适配层和编译成本控制，解决了\"编译出的 skill 在哪些平台能跑\"和\"编译一次要花多少钱\"两个架构级盲区。\n\n| 变更 | 说明 |\n|------|------|\n| **平台适配层** | 新增 `profiles/` 目录（trae/claude/generic），Pass 0 选择平台，Pass 4 按 profile 渲染 frontmatter 与文件结构，Pass 6 Layer D 反向验证 |\n| **编译模式** | 新增 `quick` / `full` / `audit` 三种模式，不同 token 开销与质量等级。默认 full |\n| **Token 预算** | IR meta 新增 `token_budget` 字段，超预算时自动降级模式 |\n| **Pass 6 Layer D** | 新增平台合规检查（D1-D8），验证 frontmatter 格式、description 规范、目录白名单等 |\n| **评分公式调整** | 四层评估：structural×0.2 + ir_consistency×0.3 + trigger_precision×0.25 + platform_compliance×0.25 |\n| **Pass 5 O9/O10** | 新增编译过程去重（O9）和 IR 瘦身（O10），降低编译环节的 token 消耗 |\n| **Trace 补充** | trace-schema.json 新增 `compilation_config` 和 `cost_summary` 字段 |\n| **Profile 自定义** | 高级用户可参考 profiles/ 格式编写自定义平台 profile |\n\n**核心洞察：** Skill 编译器的输出应该是对目标平台\"开箱即用\"的，而不是需要用户手动适配。平台 profile 作为 oracle，从生成到验证形成闭环。\n\n### v1.1.0 — 评估闭环补全\n\n**核心变更：** Pass 6 从单一结构审查升级为三层评估，解决了\"会生不会评\"的问题。\n\n| 变更 | 说明 |\n|------|------|\n| **Pass 6 三层评估** | Layer A 结构（五角色）+ Layer B IR 一致性（B1-B8）+ Layer C 触发质量（C1-C3） |\n| **IR 新增 self_test_cases** | Pass 3 Step 3.9 从 boundary + capability_graph 派生三类测试用例（positive/negative/near_miss） |\n| **评分公式** | `skill_quality_score = structural×0.3 + ir_consistency×0.4 + trigger_precision×0.3` |\n| **trace schema** | 新增 evaluation 块（三层分数 + 综合评分） |\n| **自编译验证** | 首轮 85.5 分检出 5 个 issue，修复后 100 分通过 |\n\n**核心洞察：** IR 既是生成的输入，也是验证的 oracle。不需要外部裁判——Pass 1-3 已经写完了\"这个 skill 该长什么样\"，Pass 6 回头拿 IR 验产出即可闭环。\n\n### v1.0.0 — 初始版本\n\n6 核心 Pass + 3 条件 Pass 的编译器架构，Skill IR 中间表示，五角色架构审查。\n\n---\n\n## 加入群聊\n\n<div align=\"center\">\n  <img src=\"https://qomob.ai/xskill.jpg\" width=\"600\" alt=\"XSkill\">\n</div>\n\n---\n\n## License\n\n[MIT](https://opensource.org/licenses/MIT)\n\nFile v1.2.0:_meta.json\n\n{\n  \"ownerId\": \"kn72r3ww47r1qyfaf233sf7q1982rh5f\",\n  \"slug\": \"skillcompiler\",\n  \"version\": \"1.2.0\",\n  \"publishedAt\": 1782692658602\n}\n\nFile v1.2.0:references/anti-patterns.md\n\n# Anti-Patterns — Skill 设计反模式\n\n**加载时机：** 📍 Pass 5 Optimize 执行 O1-O8 检查时加载。\n\n> 本文件定义 Skill Compiler 优化阶段（Pass 5）引用的反模式编号。\n> 完整 13 反模式库见 SkillForge [rubrics/anti-patterns.md](../../skillforge/rubrics/anti-patterns.md)。\n\n---\n\n## AP-02: Prompt Black Hole（Prompt 黑洞）\n\n**症状：** 把所有逻辑、规则、领域知识塞进一个巨大的 SKILL.md。token 爆炸，模型注意力分散。\n\n| 维度 | 详情 |\n|------|------|\n| 检测方法 | SKILL.md 超过 300 行 |\n| 修正 | 拆分为多 agent 或 reference 文件，SKILL.md 只做路由 manifest |\n| 严重度 | 🟠 High |\n| Pass 5 检查项 | O1（Prompt 长度优化） |\n\n## AP-04: Verification Theater（验证表演）\n\n**症状：** 声称有质量验证，但验证者和产出者是同一个 agent（或同一段 prompt）。\n\n| 维度 | 详情 |\n|------|------|\n| 检测方法 | 检查 verifier 是否独立于 producer |\n| 修正 | 使用独立的 Verifier Agent（干验分离原则） |\n| 严重度 | 🟠 High |\n| Pass 5 检查项 | O6（拆分检查） |\n\n## AP-06: Infinite Loop Without Guard（无界循环）\n\n**症状：** 工作流中有循环/迭代逻辑，但没有设置最大轮次上限。\n\n| 维度 | 详情 |\n|------|------|\n| 检测方法 | 检查 loop/feedback 步骤是否有 max_iterations |\n| 修正 | 设置硬性上限（推荐最多 3 轮） |\n| 严重度 | 🟠 High |\n| Pass 5 检查项 | O6（拆分检查） |\n\n## AP-07: God Agent（上帝 Agent）\n\n**症状：** 单个 agent 负责太多职责，prompt 中有 5+ 个不相关的\"功能\"。\n\n| 维度 | 详情 |\n|------|------|\n| 检测方法 | 读 agent 的 Capabilities/功能列表，检查是否有 >= 5 个不相关功能 |\n| 修正 | 按职责拆分为多个 agent，每个 agent 只负责一件事 |\n| 严重度 | 🟠 High |\n| Pass 5 检查项 | O5（模块化检查） |\n\n## AP-12: Trust-Domain Conflation（信任域混淆）\n\n**症状：** 同一逻辑概念被同一个文件承载，但该文件同时被\"隔离验证者\"和\"知情决策者\"读取。知情数据泄漏到隔离通道，导致隔离失效。\n\n| 维度 | 详情 |\n|------|------|\n| 检测方法 | ① 检查是否有 blind/isolated verifier；② 追踪其输入来源；③ 检查白名单文件是否包含知情数据 |\n| 修正 | 按信任域拆分文件（clean file vs dirty file） |\n| 严重度 | 🟠 High |\n| Pass 5 检查项 | O4（知识耦合检测） |\n\nFile v1.2.0:references/example-generation.md\n\n# Conditional Pass: Example Generation\n\n**加载时机：** 📍 仅当 Skill 涉及复杂流程/规则/评分体系时加载。\n\n---\n\n## 触发条件\n\n满足任一：\n- architecture_type = workflow 或 multi-agent\n- 有 rubrics（评分体系）\n- 有 5+ 条 rules\n- 用户显式要求\n\n---\n\n## 生成规则\n\n### 示例类型\n\n| 类型 | 用途 | 何时生成 |\n|------|------|---------|\n| Minimal | 最简输入输出，验证基本流程 | 总是 |\n| Normal | 典型使用场景 | 总是 |\n| Complex | 边界条件或复杂输入 | 当有复杂规则时 |\n| Edge Case | 极端输入 | 当有数值阈值时 |\n| Failure Case | 应该失败的输入 | 当有输入验证时 |\n| Anti-pattern | 不应该这样用 | 当有常见误用时 |\n\n### 示例格式\n\n```markdown\n# Example: {Title}\n\n**Type:** minimal | normal | complex | edge-case | failure | anti-pattern\n\n## Input\n{输入内容}\n\n## Expected Output\n{期望输出}\n\n## Notes\n{为什么是这个输出，关键决策点}\n```\n\n### 生成原则\n\n1. **从 Prompt 中提取** — 如果 Prompt 自带示例，优先用\n2. **覆盖关键路径** — 每个主要 workflow 步骤至少有一个示例\n3. **不过度生成** — 3-5 个高质量示例 > 10 个低质量示例\n4. **可扩展** — examples/ 目录设计为可追加\n\nFile v1.2.0:references/pass-1-analyze.md\n\n# Pass 1: Analyze — 理解 Prompt\n\n**加载时机：** 📍 执行到 Pass 1 时加载。\n\n---\n\n## 执行步骤\n\n### Step 1.1 — Prompt Summary\n\n用一句话概括 Prompt 的核心功能。不照搬原文，用自己的话重述。\n\n### Step 1.2 — Goal Extraction\n\n区分 Prompt\"说的\"和\"真正需要的\"：\n- **说的：** Prompt 字面要求做什么\n- **真正需要的：** 这个能力长期来看应该解决什么问题\n\n### Step 1.3 — Input/Output Spec\n\n| 字段 | 如何确定 |\n|------|---------|\n| input | Prompt 接收什么？用户输入？文件？API 响应？ |\n| output | Prompt 产出什么？文本？JSON？文件？结构化报告？ |\n\n如果 Prompt 没有明确说明，从上下文推断并标注为 `inferred`。\n\n### Step 1.4 — Capability Hints\n\n快速扫描 Prompt 中暗示的能力关键词：\n\n```\n决策类：decision, choose, recommend, 判断, 推荐, 决策\n规划类：plan, strategy, roadmap, 规划, 策略, 路线图\n写作类：write, draft, compose, 写, 起草, 撰写\n审查类：review, audit, check, 审查, 检查, 审核\n研究类：research, investigate, search, 调研, 搜索, 调查\n分析类：analyze, assess, evaluate, 分析, 评估\n编码类：code, implement, debug, 编码, 实现, 调试\n推理类：reason, infer, deduce, 推理, 推断\n模拟类：simulate, model, predict, 模拟, 建模, 预测\n评估类：score, rate, benchmark, 评分, 打分, 基准\n分类类：classify, categorize, sort, 分类, 归类\n排名类：rank, prioritize, 排序, 优先级\n```\n\n记录命中的关键词，传给 Pass 2 做深度抽取。\n\n### Step 1.5 — Boundary Definition\n\n明确 Skill 的边界——**不处理什么**：\n\n1. Prompt 中暗示但不应包含的场景\n2. 与其他 Skill 的职责划分\n3. 用户可能误用的方向\n\n### Step 1.6 — Hidden Assumptions\n\nPrompt 中隐含但未明说的前提：\n\n- 隐含的角色假设（\"你是专家\" → 需要领域知识）\n- 隐含的格式假设（\"输出报告\" → 需要模板）\n- 隐含的质量假设（\"高质量\" → 需要评分标准）\n\n### Step 1.7 — Unknowns\n\n需要向用户澄清的问题。**最多问 3 个**，只问能改变架构设计的：\n\n- 不确定的核心目标？\n- 不确定的使用频率（影响 archetype）？\n- 不确定的输出消费者（影响输出格式）？\n\n---\n\n## Output Schema\n\n```json\n{\n  \"prompt_summary\": \"一句话，不照搬原文\",\n  \"prompt_goal\": {\n    \"stated\": \"字面目标\",\n    \"actual\": \"真正需要的能力\"\n  },\n  \"input_spec\": {\n    \"type\": \"string | file | api | mixed\",\n    \"description\": \"输入描述\",\n    \"inferred\": false\n  },\n  \"output_spec\": {\n    \"type\": \"string | json | file | report\",\n    \"description\": \"输出描述\",\n    \"inferred\": false\n  },\n  \"capability_hints\": [\"命中的能力关键词\"],\n  \"boundary\": {\n    \"in_scope\": [\"处理的场景\"],\n    \"out_of_scope\": [\"不处理的场景\"]\n  },\n  \"hidden_assumptions\": [\"隐含前提\"],\n  \"unknowns\": [\"需要澄清的问题（<= 3 个）\"]\n}\n```\n\n## Decision Gate\n\n| 条件 | 动作 |\n|------|------|\n| unknowns 为空 | → Pass 2 |\n| unknowns 非空 | 向用户提问，收到回答后更新 IR → Pass 2 |\n\nFile v1.2.0:references/pass-2-extract.md\n\n# Pass 2: Extract — 能力/知识/角色抽取\n\n**加载时机：** 📍 执行到 Pass 2 时加载。\n\n---\n\n## 三合一抽取\n\n原 16-phase 设计把 Capability Extraction、Knowledge Extraction、Role Extraction 拆成三步。但它们本质都是\"分析 Prompt 的组成要素\"，强关联且无独立决策门。合并为一次扫描，产出三个 IR 字段。\n\n---\n\n## Step 2.1 — Capability Graph 构建\n\n### 能力识别\n\n从 Pass 1 的 `capability_hints` 出发，构建能力依赖图：\n\n```\nPrimary Capability（核心能力，1-3 个）\n  ├── Sub-capability（子能力）\n  └── Supporting Capability（支撑能力）\n```\n\n### 能力分类参考\n\n| 类别 | 能力 |\n|------|------|\n| 认知 | Decision Making, Reasoning, Analysis, Prediction |\n| 创造 | Writing, Brainstorming, Coding, Mapping |\n| 评估 | Review, Evaluation, Scoring, Ranking, Classification |\n| 执行 | Planning, Workflow, Research, Knowledge Retrieval |\n| 交互 | Role Playing, Simulation |\n\n### Graph 构建规则\n\n1. **Primary** = Prompt 的核心功能对应的能力（1-3 个）\n2. **Secondary** = 支撑核心能力的能力\n3. **Graph edges** = 能力间的依赖关系（A 需要 B 先完成）\n\n---\n\n## Step 2.2 — Knowledge Inventory 提取\n\n扫描 Prompt，逐句分类：\n\n| 知识类型 | 识别信号 | 去向 |\n|---------|---------|------|\n| **Rules** | \"必须\"、\"禁止\"、\"不要\"、\"always\"、\"never\" | `references/rules.md` |\n| **Templates** | 有结构化输出格式、固定 section | `templates/*.md` |\n| **Domain Knowledge** | 行业术语、专业概念、法规 | `references/domain-*.md` |\n| **Examples** | \"例如\"、\"示例\"、\"case\" | `examples/*.md` |\n| **Standards** | 评分标准、质量标准、验收标准 | `rubrics/*.md` |\n| **Roles** | \"你是...\"、\"作为...\"、persona 定义 | Pass 2.3 处理 |\n| **Processes** | 步骤、流程、phase | Pass 3 Design 处理 |\n| **Experience** | 经验法则、最佳实践、教训 | `references/best-practices.md` |\n\n### 提取规则\n\n- **去重：** 相同规则出现多次，只保留一次\n- **去噪：** Prompt 中的过渡句、寒暄语不提取\n- **标注来源：** 每条知识标注 `[from source prompt]` 或 `[inferred by compiler]`\n\n---\n\n## Step 2.3 — Role Matrix 构建\n\n### 识别现有角色\n\n扫描 Prompt 中的 persona 定义：\n\n| 信号 | 示例 |\n|------|------|\n| 显式角色声明 | \"你是世界级 AI Skill Architect\" |\n| 隐式角色 | \"审查代码质量\"（隐含 Reviewer 角色） |\n| 多角色切换 | Prompt 中有多个\"你是...\" |\n\n### 角色分析\n\n对每个识别到的角色：\n\n| 字段 | 说明 |\n|------|------|\n| name | 角色名 |\n| responsibility | 职责描述 |\n| capabilities | 需要的能力（关联 Capability Graph） |\n| should_split | 是否应该拆分为独立 agent |\n| split_reason | 拆分理由（如果 should_split=true） |\n\n### 拆分判断\n\n| 条件 | should_split |\n|------|-------------|\n| 单一角色，职责清晰 | false |\n| 角色有 3+ 不相关职责 | true |\n| 角色同时负责\"产出\"和\"验证\" | true（干验分离原则） |\n| 角色需要不同的知识域 | true |\n\n### 建议新增角色\n\n分析 Prompt 缺失但 Skill 需要的角色：\n- 缺少 Verifier？（产出后需要独立验证）\n- 缺少 Router？（多种输入类型需要路由）\n- 缺少 Formatter？（需要统一输出格式）\n\n---\n\n## Output Schema\n\n```json\n{\n  \"capability_graph\": {\n    \"primary\": [\"能力1\", \"能力2\"],\n    \"secondary\": [\"能力3\"],\n    \"graph\": {\n      \"能力1\": [\"子能力A\", \"子能力B\"],\n      \"能力2\": [\"子能力C\"]\n    }\n  },\n  \"knowledge_inventory\": {\n    \"rules\": [\n      { \"content\": \"规则内容\", \"source\": \"from source prompt | inferred\", \"target_file\": \"references/rules.md\" }\n    ],\n    \"templates\": [\n      { \"name\": \"模板名\", \"structure\": \"结构描述\", \"target_file\": \"templates/xxx.md\" }\n    ],\n    \"domain_knowledge\": [\n      { \"content\": \"知识内容\", \"domain\": \"领域\", \"target_file\": \"references/domain-xxx.md\" }\n    ],\n    \"examples\": [\n      { \"type\": \"minimal | normal | complex\", \"content\": \"示例内容\", \"target_file\": \"examples/xxx.md\" }\n    ],\n    \"standards\": [\n      { \"type\": \"scoring | quality | acceptance\", \"content\": \"标准内容\", \"target_file\": \"rubrics/xxx.md\" }\n    ],\n    \"best_practices\": [\n      { \"content\": \"实践内容\", \"target_file\": \"references/best-practices.md\" }\n    ]\n  },\n  \"role_matrix\": {\n    \"existing\": [\n      {\n        \"name\": \"角色名\",\n        \"responsibility\": \"职责\",\n        \"capabilities\": [\"关联能力\"],\n        \"should_split\": false,\n        \"split_reason\": \"\"\n      }\n    ],\n    \"to_add\": [\n      {\n        \"name\": \"建议角色名\",\n        \"reason\": \"为什么需要这个角色\",\n        \"responsibility\": \"职责\"\n      }\n    ]\n  }\n}\n```\n\n## Decision Gate\n\n| 条件 | 动作 |\n|------|------|\n| capability_graph.primary 非空 | → Pass 3 |\n| capability_graph 为空 | REJECT — Prompt 没有可提取的能力，不适合做 Skill |\n\nFile v1.2.0:references/pass-3-design.md\n\n# Pass 3: Design — Skill 架构设计\n\n**加载时机：** 📍 执行到 Pass 3 时加载。\n\n---\n\n## 设计原则\n\n**先设计系统，再设计 Prompt。绝不反过来。**\n\n原 16-phase 把 Workflow / References / Templates / Rubrics / Checklists / Config 拆成六步。但它们强关联——Workflow 决定需要什么 Checklist，Checklist 决定需要什么 Rubric。合并为一次架构设计。\n\n---\n\n## Step 3.1 — Architecture Type 决策\n\n| 条件 | architecture_type |\n|------|------------------|\n| 单次 LLM 调用，无状态 | `single-prompt` |\n| 多步骤顺序执行，有中间产出 | `workflow` |\n| 多角色并行或专业化 | `multi-agent` |\n\n### 决策树\n\n```\nPrompt 有多个步骤？\n  ├─ No → single-prompt\n  └─ Yes → 步骤间有并行或需要不同专业角色？\n            ├─ No → workflow\n            └─ Yes → multi-agent\n```\n\n---\n\n## Step 3.2 — Workflow Pattern 选择\n\n**仅 workflow / multi-agent 执行。** single-prompt 跳过。\n\n| 需求 | Pattern | 核心机制 |\n|------|---------|---------|\n| 输入类型多样，先判路再执行 | classify-and-act | 分类器路由 |\n| 多个独立子任务可并行 | fan-out-synthesize | 扇出+综合 |\n| 质量关键，需独立验证 | adversarial-verify | 对抗验证 |\n| 需要创意多样性，筛选最优 | generate-filter | 生成+过滤 |\n| 多方案成对比较选优 | tournament | 锦标赛 |\n| 需要迭代优化直到达标 | loop-until-done | 循环（上限3轮） |\n| 强制顺序，不能跳步 | pipeline | 管道+检查点 |\n\n可组合：如 classify-and-act 路由 → 每条路径内部用 pipeline。\n\n---\n\n## Step 3.3 — Single-Skill Pattern 选择\n\n**所有 Skill 必须选一个。** 与 workflow pattern 正交。\n\n| 需要什么？ | Pattern | 核心机制 |\n|------------|---------|---------|\n| 特定技术栈的专家知识 | tool-wrapper | SKILL.md 指向 references/ |\n| 一致的结构化输出 | generator | 模板 + 风格指南 |\n| 自动化代码/内容审查 | reviewer | 分离\"检查什么\"与\"怎么查\" |\n| 需求不明确，需先收集 | inversion | Agent 先采访用户 |\n| 复杂的多步骤任务 | pipeline | 强制顺序 + 检查点门控 |\n| 不确定？ | tool-wrapper | 最通用，可演进 |\n\n---\n\n## Step 3.4 — Module Decomposition\n\n基于 Pass 2 的 knowledge_inventory，决定模块拆分：\n\n| IR 字段 | 去向 | 拆分条件 |\n|---------|------|---------|\n| rules（> 5 条） | `references/rules.md` | 规则数 > 5 或总字数 > 200 |\n| rules（<= 5 条） | 内联 SKILL.md | 规则少且短 |\n| templates | `templates/*.md` | 有结构化输出 |\n| domain_knowledge | `references/domain-*.md` | 有领域知识 |\n| standards | `rubrics/*.md` | 有评分/质量标准 |\n| examples | `examples/*.md` | 有示例（或触发 Example Generation pass） |\n\n### 拆分原则\n\n1. **SKILL.md 最小化** — 只含路由 + 流程概览，< 300 行\n2. **知识外置** — 任何 > 200 字的知识块 → references/\n3. **配置参数化** — 可变的参数 → config/\n4. **模板独立** — 固定格式的输出 → templates/\n\n---\n\n## Step 3.5 — Workflow Reconstruction\n\n**不要沿用 Prompt 顺序。** 以 Skill 为中心重新设计。\n\n### 每步定义\n\n| 字段 | 说明 |\n|------|------|\n| purpose | 这一步为什么存在 |\n| input | 输入是什么（来自上游或用户） |\n| output | 输出是什么（传给下游） |\n| decision_gate | 什么条件下继续/停止/重试 |\n| exit_criteria | 这一步完成的标志 |\n| retry_strategy | 失败时怎么办（最多 3 次） |\n| rollback_strategy | 无法完成时怎么办 |\n\n### Workflow 设计原则\n\n- **阶段化** — 每步有明确的进入/退出条件\n- **可恢复** — 任何一步失败不丢失上游产出\n- **可重试** — 失败后带反馈重试，有上限\n- **可扩展** — 新步骤可以插入，不破坏现有流程\n\n---\n\n## Step 3.6 — Reference Tree 设计\n\n规划 references/ 目录结构：\n\n```\nreferences/\n  ├── rules.md          # 规则集合\n  ├── domain-xxx.md     # 领域知识\n  ├── best-practices.md # 最佳实践\n  └── gotchas.md        # 常见陷阱（首次留骨架）\n```\n\n### 设计原则\n\n- 按主题分文件，不按 Prompt 顺序\n- 每个文件独立可读\n- 引用深度 = 1 层（SKILL.md → references/file.md，不嵌套）\n\n---\n\n## Step 3.7 — Checklist / Rubric / Config 设计\n\n### Checklist（检查清单）\n\n根据 architecture_type 生成：\n\n| 清单 | 内容 |\n|------|------|\n| Architecture Checklist | 模块边界、依赖方向、扩展点 |\n| Quality Checklist | 无 TODO、无 placeholder、< 300 行 |\n| Skill Checklist | frontmatter 合规、触发词、懒加载标记 |\n\n### Rubric（评分体系）\n\n当 Pass 2 有 standards 时生成。包含：\n\n| 组件 | 用途 |\n|------|------|\n| Scoring Rubric | 评分维度 + 权重 |\n| Risk Matrix | 风险等级矩阵 |\n| Priority Matrix | 优先级排序 |\n| Maturity Model | 成熟度分级 |\n\n### Config（配置）\n\n找出应该参数化的内容：\n\n```yaml\n# config/settings.yaml\nskill_name: string\nversion: string\nmax_iterations: 3  # 循环上限\noutput_format: markdown | json\n```\n\n---\n\n## Step 3.8 — Folder Structure 规划\n\n基于以上设计，输出目标目录树：\n\n```\nskill-name/\n  SKILL.md              # 入口 + 路由\n  references/           # 外置知识（按需加载）\n  workflows/            # 工作流定义（workflow/multi-agent）\n  templates/            # 输出模板\n  checklists/           # 检查清单\n  rubrics/              # 评分体系\n  config/               # 参数化配置\n  examples/             # 示例\n  schemas/              # JSON schema\n```\n\n**最小化原则：** 只创建需要的目录。single-prompt skill 不需要 workflows/。\n\n---\n\n## Step 3.9 — Self-Test Cases 派生\n\n**Pass 3 收尾必做。** 从 Pass 1 的 boundary 和 Pass 2 的 capability_graph 派生静态自测用例，供 Pass 6 Layer B/C 消费。\n\n**这是 IR 作为 test oracle 的关键步骤——不派生用例，Pass 6 就无 oracle 可用。**\n\n### 派生规则\n\n| 用例集 | 来源 | 说明 |\n|--------|------|------|\n| `positive` | `pass_1.boundary.in_scope` × `pass_2.capability_graph.primary` | 应触发 skill 的用户输入（组合场景 × 主能力） |\n| `negative` | `pass_1.boundary.out_of_scope` | 不应触发的用户输入（显式排除项） |\n| `near_miss` | `pass_2.capability_graph.secondary` − `pass_2.capability_graph.primary` | 语义近邻、容易误触发但不在主职责内的输入 |\n\n### 派生要求\n\n1. **positive 至少 3 条** — 覆盖主能力的典型用户表述\n2. **negative 至少 1 条** — 来自 boundary.out_of_scope（若为空，标注 `inferred: \"无显式排除项\"`）\n3. **near_miss 至少 0 条** — 若 secondary 为空则空数组（无近邻误触发风险）\n4. **用用户视角表述** — 写用户会怎么问，不写内部能力名（如\"帮我审一下这段 Python 代码\"而非\"调用 code-reviewer skill\"）\n\n### 示例\n\n```json\n{\n  \"self_test_cases\": {\n    \"positive\": [\n      \"审查这段 Python 代码的安全问题\",\n      \"检查这个函数有没有 bug\",\n      \"帮我 review 一下这个 PR\"\n    ],\n    \"negative\": [\n      \"帮我写一段 Python 代码\",\n      \"翻译这段技术文档\"\n    ],\n    \"near_miss\": [\n      \"审查这段 JavaScript 代码\"\n    ]\n  }\n}\n```\n\n### 派生完成后\n\n`self_test_cases` 写入 IR 的 `pass_3_design.self_test_cases`。Pass 6 Layer B/C 直接读取此字段，无需重新生成用例。\n\n---\n\n## Output Schema\n\n```json\n{\n  \"architecture_type\": \"single-prompt | workflow | multi-agent\",\n  \"workflow_pattern\": \"pattern name | null\",\n  \"single_skill_pattern\": \"tool-wrapper | generator | reviewer | inversion | pipeline\",\n  \"self_test_cases\": {\n    \"positive\": [\"应触发的用户输入\"],\n    \"negative\": [\"不应触发的用户输入\"],\n    \"near_miss\": [\"易误触发的近邻输入\"]\n  },\n  \"module_decomposition\": {\n    \"core_prompt\": \"SKILL.md 核心职责描述\",\n    \"workflows\": [\"workflow 文件列表\"],\n    \"references\": [\"reference 文件列表 + 内容概述\"],\n    \"checklists\": [\"checklist 列表\"],\n    \"rubrics\": [\"rubric 列表\"],\n    \"templates\": [\"template 列表\"],\n    \"configs\": [\"config 参数列表\"]\n  },\n  \"workflow_steps\": [\n    {\n      \"id\": \"step-1\",\n      \"purpose\": \"为什么存在\",\n      \"input\": \"输入\",\n      \"output\": \"输出\",\n      \"decision_gate\": \"继续条件\",\n      \"exit_criteria\": \"完成标志\",\n      \"retry_strategy\": \"重试策略\",\n      \"rollback_strategy\": \"回滚策略\"\n    }\n  ],\n  \"reference_tree\": [\"references/xxx.md\"],\n  \"folder_structure\": \"目录树字符串\"\n}\n```\n\n## IR 合并\n\nPass 3 完成后，将 pass_1_analyze、pass_2_extract、pass_3_design 三个字段合并为完整 Skill IR。合并后必须通过 schema 校验才能进入 Pass 4。\n\n## Decision Gate\n\n| 条件 | 动作 |\n|------|------|\n| architecture_type 确定 + folder_structure 非空 + IR 通过 schema 校验 | → Pass 4 |\n| IR 校验失败（字段缺失/类型错误） | 修复 IR 缺失字段后重新校验 |\n| 无法确定 architecture_type | 向用户澄清使用场景 |\n\n### IR 校验\n\n📍 IR schema 定义见 [schemas/ir-schema.json](../schemas/ir-schema.json)\n\nPass 3→4 门控时，对合并后的 IR 执行以下校验：\n\n| # | 校验项 | FAIL 处理 |\n|---|--------|----------|\n| 1 | `meta`、`pass_1_analyze`、`pass_2_extract`、`pass_3_design` 四个顶层字段齐全 | 补齐缺失 Pass 的 IR |\n| 2 | `pass_2_extract.capability_graph.primary` 非空（≥1 个） | 回退 Pass 2 补充能力图谱 |\n| 3 | `pass_3_design.architecture_type` 为 single-prompt / workflow / multi-agent 之一 | 回退 Pass 3 确定架构类型 |\n| 4 | `pass_3_design.single_skill_pattern` 已选择 | 回退 Pass 3 选择 single-skill pattern |\n| 5 | `pass_3_design.folder_structure` 非空 | 回退 Pass 3 规划目录结构 |\n| 6 | `pass_3_design.self_test_cases.positive` ≥ 3 条 | 回退 Pass 3 Step 3.9 补充 positive 用例 |\n| 7 | `pass_3_design.self_test_cases.negative` ≥ 1 条（或标注 inferred） | 回退 Pass 3 Step 3.9 补充 negative 用例 |\n\n全部 PASS → 进入 Pass 4。\n\nFile v1.2.0:references/pass-4-generate.md\n\n# Pass 4: Generate — 生成 Skill 包\n\n**加载时机：** 📍 执行到 Pass 4 时加载。\n\n---\n\n## 生成原则\n\n1. **IR 驱动** — 所有文件内容来自 Pass 1-3 的 IR，不凭空创造\n2. **三层加载** — L1 frontmatter / L2 SKILL.md 路由 / L3 references 懒加载\n3. **平台感知渲染** — frontmatter、description、文件结构按 `target_platform` 对应的 profile 规范渲染\n4. **frontmatter 卫生** — 只含目标平台要求的字段（generic/trae 仅 name + description）\n5. **无占位符** — 不留 TODO/TBD/placeholder\n6. **文件最小化** — 只生成 IR 要求的文件，不多创建\n\n---\n\n## Step 4.1 — SKILL.md 生成\n\n### Step 4.0 — 加载目标平台 Profile\n\n读取 `meta.target_platform` 并加载对应 profile：\n\n| target_platform | Profile 文件 |\n|----------------|-------------|\n| `trae`         | 📍 [profiles/trae.md](../profiles/trae.md) |\n| `claude`       | 📍 [profiles/claude.md](../profiles/claude.md) |\n| `generic`      | 📍 [profiles/generic.md](../profiles/generic.md) |\n\n后续渲染步骤全部参考 profile 中定义的约束（description 格式、触发词策略、文件结构支持列表）。\n\n### Frontmatter — 按平台渲染\n\n#### TRAE 平台\n\n```yaml\n---\nname: {kebab-case-name}\ndescription: \"Use when {触发场景}. Triggers on: {触发词1}, {触发词2}, {触发词3}. {核心功能一句话}\"\n---\n```\n\n**约束：**\n- description 必须为**严格单行 YAML 字符串**，不支持多行 block scalar\n- ≤ 500 字符\n- 触发词用「逗号 + 空格」分隔\n- 不包含 `version` 等额外 frontmatter 字段\n\n#### Claude 平台\n\n```yaml\n---\nname: {kebab-case-name}\ndescription: >\n  Use when {触发场景}.\n\n  Triggers on:\n  - {触发词1}\n  - {触发词2}\n  - {触发词3}\n\n  {核心功能一句话描述}\nversion: 1.0.0\n---\n```\n\n**约束：**\n- description 支持多行 block scalar（`>` 或 `|`）\n- ≤ 500 字符\n- 触发词支持列表格式（每行一个）\n- 可包含 `version` 等额外字段\n\n#### Generic 平台（默认）\n\n```yaml\n---\nname: {kebab-case-name}\ndescription: \"Use when {触发场景}. Triggers on: {触发词1}, {触发词2}, {触发词3}. {核心功能一句话}\"\n---\n```\n\n**约束：**\n- description 严格单行（兼容所有 YAML 解析器）\n- ≤ 300 字符（最严格限制）\n- frontmatter 只保留 name + description\n\n---\n\n**description 通用规则（所有平台）：**\n- 以 \"Use when\" / \"Use for\" 开头\n- 包含 3+ 用户可能输入的触发词\n- 聚焦用户意图，不描述内部机制\n\n### Body 结构\n\n```markdown\n# {Skill Name}\n\n{一句话定位}\n\n## 核心流程\n{3-5 步流程概览，每步一句话}\n\n## 执行步骤\n### Step 1 — {名称}\n📍 加载文件: references/xxx.md\n{简要说明 + 输入输出}\n\n### Step 2 — {名称}\n...\n\n## 输出格式\n{输出 schema 或模板引用}\n\n## Gotchas\n{常见陷阱，首次留骨架}\n```\n\n### 行数控制\n\n- **< 150 行：** 理想\n- **150-300 行：** 可接受\n- **> 300 行：** 必须拆分（AP-02 Prompt Black Hole）\n\n### 平台感知的文件结构约束\n\n生成 `references/` 和可能的工作流/agent 目录时，参考目标平台的 profile：\n\n| 目录 | generic | trae | claude |\n|------|---------|------|--------|\n| `references/` | ✅ | ✅ | ✅ |\n| `templates/` | ✅ | ✅ (放 references/ 更安全) | ✅ |\n| `workflows/` | ❌ | ❌ | ✅ |\n| `agents/` | ❌ | ❌ | ✅ |\n| `rubrics/` | ❌ | 放 references/ 内 | ✅ |\n| `checklists/` | ❌ | 放 references/ 内 | ✅ |\n\n**规则：** 不生成目标平台不支持的目录。必须生成的 reference 文件全部放在 `references/` 或模板所在平台允许的位置。\n\n---\n\n## Step 4.2 — References 生成\n\n对 Pass 3 的 `reference_tree` 中每个文件：\n\n### rules.md 模板\n\n```markdown\n# Rules\n\n{从 knowledge_inventory.rules 逐条列出}\n\n## 规则列表\n\n| # | 规则 | 来源 |\n|---|------|------|\n| 1 | {规则内容} | source / inferred |\n```\n\n### domain-xxx.md 模板\n\n```markdown\n# {Domain} Knowledge\n\n## {Topic 1}\n{知识内容}\n\n## {Topic 2}\n{知识内容}\n```\n\n### best-practices.md 模板\n\n```markdown\n# Best Practices\n\n## {Practice 1}\n{内容 + 为什么}\n\n## {Practice 2}\n{内容 + 为什么}\n```\n\n### gotchas.md 模板（首次骨架）\n\n```markdown\n# Gotchas / Footguns\n\n> 上线后根据实际 failure case 填充。\n\n## 常见失败点\n- TODO: {占位 — 替换为实际失败模式}\n\n## 字段/命名歧义\n- TODO: {占位}\n\n## 边界条件\n- TODO: {占位}\n```\n\n---\n\n## Step 4.3 — Workflows 生成（workflow/multi-agent only）\n\n对 Pass 3 的 `workflow_steps` 生成 YAML：\n\n```yaml\nname: {skill-name}-{workflow-name}\ndescription: {工作流描述}\n\ninput:\n  type: object\n  required: [{必需字段}]\n  properties:\n    {field}: { type: string }\n\nsteps:\n  - id: {step-id}\n    agent: {agent-name}\n    description: {步骤描述}\n    input:\n      {field}: \"{{input.xxx}}\"\n    output: {output-var}\n    when: [{条件表达式，可选}]\n```\n\n---\n\n## Step 4.4 — Templates 生成\n\n对 Pass 3 的 `module_decomposition.templates`：\n\n```markdown\n# {Template Name}\n\n## 变量\n| 变量 | 说明 | 必填 |\n|------|------|------|\n| {var} | {描述} | yes/no |\n\n## 模板\n---\n{模板内容，用 {{var}} 标记变量}\n---\n```\n\n---\n\n## Step 4.5 — Checklists 生成\n\n```markdown\n# {Checklist Name}\n\n## 检查项\n\n| # | 检查项 | 如何检查 | PASS 标准 |\n|---|--------|---------|-----------|\n| 1 | {检查内容} | {方法} | {标准} |\n```\n\n---\n\n## Step 4.6 — Rubrics 生成（当有 standards 时）\n\n```markdown\n# {Rubric Name}\n\n## 评分维度\n\n| 维度 | 权重 | 评分标准 |\n|------|------|---------|\n| {维度} | {X}% | {1-5 分的描述} |\n\n## 风险矩阵\n| 风险 | 概率 | 影响 | 等级 |\n|------|------|------|------|\n\n## 成熟度模型\n| 级别 | 特征 |\n|------|------|\n| L1 | {描述} |\n| L2 | {描述} |\n| L3 | {描述} |\n```\n\n---\n\n## Step 4.7 — Config 生成（当有参数化时）\n\n```yaml\n# config/settings.yaml\nskill_name: {name}\nversion: 1.0.0\n{参数}: {默认值}\n```\n\n---\n\n## Step 4.8 — Schemas 生成（当有结构化输出时）\n\n```json\n{\n  \"$schema\": \"http://json-schema.org/draft-07/schema#\",\n  \"title\": \"{Skill} Output\",\n  \"type\": \"object\",\n  \"required\": [\"field1\"],\n  \"properties\": {\n    \"field1\": { \"type\": \"string\", \"description\": \"...\" }\n  }\n}\n```\n\n---\n\n## Step 4.9 — Self-Check（生成后立即执行）\n\n| # | 检查项 | FAIL 处理 |\n|---|--------|----------|\n| 1 | frontmatter 符合目标平台 profile 规范 | 按 profile 重写 |\n| 2 | description 触发导向（Use when + 3+ 触发词） | 重写 description |\n| 3 | SKILL.md < 300 行 | 拆分到 references |\n| 4 | 所有 📍 标记的文件存在 | 创建缺失文件 |\n| 5 | 无 TODO/TBD/placeholder（gotchas.md 骨架除外） | 填充或移除 |\n| 6 | 每个文件被至少一个其他文件引用 | 移除孤立文件或添加引用 |\n| 7 | 未生成目标平台不支持的目录 | 移入 references/ |\n| 8 | 已设置 `meta.platform_profile_applied = true` | 设置标记 |\n\n任一 FAIL → 修复后重新检查，全部 PASS → 进入 Pass 5/6。\n\nFile v1.2.0:references/pass-5-optimize.md\n\n# Pass 5: Optimize — 编译优化\n\n**加载时机：** 📍 执行到 Pass 5 时加载（条件触发）。\n**反模式引用：** AP-02/04/06/07/12 定义见 [anti-patterns.md](anti-patterns.md)\n\n---\n\n## 触发条件\n\n满足任一即执行：\n- Source Prompt > 500 字\n- Pass 4 生成的文件中有重复知识（>= 3 处相同内容）\n- architecture_type = multi-agent\n- 用户显式要求\n\n---\n\n## 优化检查清单\n\n### O1 — Prompt 长度优化\n\n| 检查 | 动作 |\n|------|------|\n| SKILL.md > 300 行 | 拆分：执行逻辑 → agents/，领域知识 → references/，规则 → checklists/ |\n| 单个 agent prompt > 1500 tokens | 精简：移除示例到 examples/，移除规则到 references/ |\n| 单个 reference > 2000 tokens | 拆分为多个小文件 |\n\n### O2 — Workflow 去重\n\n| 检查 | 动作 |\n|------|------|\n| 两个步骤做相似的事 | 合并为一个步骤 + 参数化差异 |\n| 步骤间传递冗余数据 | 精简 inter-agent 数据契约 |\n| 有步骤从不被触发 | 移除死步骤 |\n\n### O3 — Reference 去重\n\n| 检查 | 动作 |\n|------|------|\n| 同一规则出现在多个文件 | 合并为单一来源（DRY） |\n| 两个 reference 文件内容重叠 > 40% | 合并 |\n| reference 间有循环引用 | 打破循环，提取公共部分 |\n\n### O4 — 知识耦合检测\n\n| 检查 | 动作 |\n|------|------|\n| 一个 reference 文件同时被\"产出者\"和\"验证者\"读取 | 按信任域拆分 → 见 [anti-patterns.md](anti-patterns.md) **AP-12** |\n| 领域知识与执行逻辑混在同一文件 | 分离：知识 → references/，逻辑 → SKILL.md |\n| 配置硬编码在 prompt 中 | 参数化 → config/ |\n\n### O5 — 模块化检查\n\n| 检查 | 动作 |\n|------|------|\n| 单个文件承担 3+ 不相关职责 | 按职责拆分 |\n| 修改一个功能需要改 3+ 文件 | 重新划界，高内聚低耦合 |\n| God Agent（>= 5 不相关功能） | 拆分为多个 agent → 见 [anti-patterns.md](anti-patterns.md) **AP-07** |\n\n### O6 — 拆分检查\n\n| 检查 | 动作 |\n|------|------|\n| agent 同时负责产出和验证 | 拆分为 Producer + Verifier → 见 [anti-patterns.md](anti-patterns.md) **AP-04** |\n| workflow 无上限循环 | 添加 max_iterations → 见 [anti-patterns.md](anti-patterns.md) **AP-06** |\n| 所有文件都在根目录 | 按类型分目录 |\n\n### O7 — 参数化检查\n\n| 检查 | 动作 |\n|------|------|\n| prompt 中有硬编码的阈值 | → config/ 参数化 |\n| prompt 中有硬编码的角色名 | → config/roles.yaml |\n| prompt 中有硬编码的输出格式 | → templates/ |\n\n### O8 — 插件化检查\n\n| 检查 | 动作 |\n|------|------|\n| Skill 涉及搜索/API/数据库 | → references/plugins.md 记录 |\n| Skill 涉及外部服务（GitHub/Notion） | → references/plugins.md 记录 |\n| Skill 涉及 MCP 工具 | → references/plugins.md 记录 |\n\n### O9 — 编译过程去重（v1.2 新增）\n\n> 优化的是**编译过程本身**的 token 消耗，而非产物。\n\n| 检查 | 动作 |\n|------|------|\n| 多个 Pass 加载了相同的 reference 文件 | 将公共内容提取为单次加载，Pass 间共享 |\n| 某个 Pass 的 reference 文件 > 2000 tokens 且仅使用其中 < 50% 的内容 | 精简 reference 文件为当前 Pass 需要的部分 |\n| Pass 4 读取的 IR 字段中有 Pass 6 用不到的字段 | 在 Pass 4→6 间传递精简版 IR（仅含必检字段） |\n\n### O10 — IR 瘦身（v1.2 新增）\n\n> IR 是编译器核心数据，但 full compilation 中 IR 会积累大量字段。部分字段仅被单个 Pass 使用一次，不值得保留在完整 IR 中。\n\n| 检查 | 动作 |\n|------|------|\n| IR 中单次使用（仅被一个 Pass 读取）的字段 | 移除出核心 IR，转为该 Pass 本地变量 |\n| `conditional_passes` 中未执行的 block | 从 trace 中移除（仅记录 skip reason），不写入 IR |\n| IR 中的示例/知识内容长度 > 500 tokens 且仅用于 Pass 4 的模板填充 | 压缩为摘要引用（\"参见 source prompt 原始内容\"）\n\n---\n\n## 优化执行规则\n\n1. **每次只改一处** — 不批量修改，每次优化后验证不破坏结构\n2. **更新 IR** — 每次优化后同步更新 Skill IR，保持一致性\n3. **记录变更** — 优化记录写入 Compilation Report 的 `optimization_log`\n4. **不过度优化** — 如果某项检查 PASS，不要为了优化而优化\n\n## Output\n\n```json\n{\n  \"optimizations_applied\": [\n    {\n      \"check\": \"O1\",\n      \"issue\": \"SKILL.md 有 350 行\",\n      \"action\": \"将领域知识移入 references/domain.md，SKILL.md 降至 180 行\",\n      \"impact\": \"SKILL.md 行数 -170\"\n    }\n  ],\n  \"optimizations_skipped\": [\n    {\n      \"check\": \"O8\",\n      \"reason\": \"Skill 不涉及外部能力\"\n    }\n  ]\n}\n```\n\nFile v1.2.0:references/pass-6-validate.md\n\n# Pass 6: Validate — 三层评估\n\n**加载时机：** 📍 执行到 Pass 6 时加载。\n\n---\n\n## 设计哲学\n\n**IR 是 spec，产出是 implementation，拿 spec 验 implementation。**\n\nPass 1-3 产出的 Skill IR 已经包含评估所需的全部信号：边界、能力、标准、失败用例。Pass 6 的职责是回头拿 IR 验证 Pass 4 生成的文件——这是编译器的语义闭环，和编译器做类型检查同理。\n\n四层评估全部静态，零运行时依赖：\n\n| Layer | 检查对象 | Oracle | 产出 |\n|-------|---------|--------|------|\n| **A 结构完整性** | 文件结构、模块边界 | 五角色审查清单 | issues 列表 |\n| **B IR 一致性** | 生成文件 vs IR 契约 | Skill IR（Pass 1-3） | 契约违反项 |\n| **C 触发质量** | description 触发准确性 | `self_test_cases`（Pass 3 派生） | 触发精度分数 |\n| **D 平台合规** | 生成文件 vs 平台 profile | `profiles/{platform}.md` | 合规违反项 |\n\n---\n\n## Layer A — 结构完整性（五角色审查）\n\n### Role 1 — Skill Architect（模块边界）\n\n| 检查项 | 问题信号 | 严重度 |\n|--------|---------|--------|\n| 模块边界清晰 | 一个模块的修改不影响其他模块 | 🟠 High |\n| 耦合度 | 模块间是否有不必要的依赖 | 🟠 High |\n| 扩展风险 | 新增功能是否需要改动核心架构 | 🟡 Medium |\n| 单一职责 | 每个模块只做一件事 | 🟠 High |\n\n### Role 2 — Knowledge Engineer（知识管理）\n\n| 检查项 | 问题信号 | 严重度 |\n|--------|---------|--------|\n| 知识污染 | 不同来源的知识混在同一文件 | 🟠 High |\n| 知识重复 | 同一规则出现在多处 | 🟡 Medium |\n| 可维护性 | 知识更新是否只改一处 | 🟠 High |\n| 信任域 | 产出者和验证者是否读同一文件 | 🟠 High |\n\n### Role 3 — Workflow Designer（流程设计）\n\n| 检查项 | 问题信号 | 严重度 |\n|--------|---------|--------|\n| 流程合理 | 步骤顺序是否最优 | 🟡 Medium |\n| 可恢复 | 步骤失败后是否能恢复 | 🟠 High |\n| 死步骤 | 是否有从不执行的步骤 | 🟡 Medium |\n| 循环上限 | 迭代步骤是否有 max_iterations | 🟠 High |\n\n### Role 4 — Prompt Engineer（Prompt 质量）\n\n| 检查项 | 问题信号 | 严重度 |\n|--------|---------|--------|\n| Prompt 膨胀 | SKILL.md > 300 行 | 🟠 High |\n| 触发词 | description 是否含 3+ 触发词 | 🔴 Critical |\n| 懒加载 | 是否有 📍 标记 | 🟡 Medium |\n| frontmatter 卫生 | 是否只有 name + description | 🟠 High |\n\n### Role 5 — Software Architect（架构债务）\n\n| 检查项 | 问题信号 | 严重度 |\n|--------|---------|--------|\n| 技术债务 | 是否有明显的短期 hack | 🟡 Medium |\n| 版本演进 | 是否支持未来扩展 | 🟡 Medium |\n| 过度设计 | \n\nArchive v0.1.0: 13 files, 23231 bytes\n\nFiles: references/example-generation.md (1283b), references/pass-1-analyze.md (3171b), references/pass-2-extract.md (5009b), references/pass-3-design.md (6970b), references/pass-4-generate.md (4655b), references/pass-5-optimize.md (3329b), references/pass-6-validate.md (3918b), references/plugin-discovery.md (1377b), skill-card.md (2674b), SKILL.md (5534b), templates/ir-schema.md (3868b), templates/skill-md-template.md (1636b), _meta.json (132b)","readmeExcerpt":"Skill: Skill Compiler Owner: qomob Summary: Use when you need to compile any prompt OR multi-source content (PDF/video/URL/image/doc) into a production-grade, reusable AI Skill. Triggers on: 'prompt to... Tags: latest:1.2.2 Version history: v1.2.2 | 2026-07-12T08:14:32.951Z | auto - Removed redundant documentation file: skill-card.md. - No changes to functionality, logic, or features. - Internal documentation houseke","codeSnippets":[],"executableExamples":[{"language":"text","snippet":"Source (Prompt / PDF / Video / URL / Image / Doc)\n  → [Pass I: Ingestion?] → [Pass 0: Triage] → [Pass 1: Analyze] → [Pass 2: Extract]\n  → [Pass 3: Design] → [Pass 4: Generate] → [Pass 5: Optimize?]\n  → [Pass 6: Validate] → Skill Package"},{"language":"text","snippet":"meta.target_platform       = 用户选择或默认\nmeta.compilation_mode      = 用户选择或默认\nmeta.token_budget          = 用户设定或默认值"},{"language":"json","snippet":"{\n  \"content\": \"所有 API 响应必须包含 request_id 字段\",\n  \"source\": \"spec.pdf:p47\",\n  \"evidence\": \"primary\",\n  \"confidence\": 0.98\n}"},{"language":"json","snippet":"{\n  \"conflicts\": [\n    {\n      \"id\": \"C-001\",\n      \"topic\": \"API 限流策略\",\n      \"status\": \"open\",\n      \"versions\": [\n        { \"content\": \"每分钟 100 次\", \"source\": \"doc-v1.md\", \"evidence\": \"primary\", \"confidence\": 0.95 },\n        { \"content\": \"每分钟 1000 次\", \"source\": \"doc-v2.md\", \"evidence\": \"primary\", \"confidence\": 0.95 }\n      ],\n      \"resolution\": null,\n      \"resolved_by\": null,\n      \"resolved_at\": null,\n      \"note\": \"两个版本表述不一致，保留待用户裁决\"\n    }\n  ]\n}"},{"language":"text","snippet":"open ──────────────────────────────► resolved\n  │                                     │\n  ├──► wontfix（不影响核心功能）         ├── resolution: prefer_higher_evidence\n  │                                     ├── resolution: prefer_newer\n  └──► deprecated（源已过期）            ├── resolution: merged\n                                        ├── resolution: user_override\n                                        └── resolved_by: user | compiler | cross_reference"},{"language":"markdown","snippet":"## 已知冲突\n\n### API 限流策略\n- 来源 A（doc-v1.md）称\"每分钟 100 次\"\n- 来源 B（doc-v2.md）称\"每分钟 1000 次\"\n- 状态：未裁决。使用前请核实当前版本。"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: skill-compiler\ndescription: \"Use when you need to compile any prompt OR multi-source content (PDF/video/URL/image/doc) into a production-grade, reusable AI Skill. Triggers on: 'prompt to skill', 'compile prompt', '把 prompt 变成 skill', '提示词编译', 'PDF转skill', '视频转skill', '网页转skill', 'skill from prompt', 'skill from document'. Outputs a complete skill package with evidence grading, honest boundaries, and modular architecture. Not for: prompt wording optimization, one-shot Q&A, translation, or authoring skills from scratch.\"\nversion: 2.0.0\n---\n\n# Skill Compiler\n\n**任意来源 → Skill IR → Optimized Skill Package**\n\n你不是 Prompt Engineer。你是一位 AI Skill Architect + Compiler Engineer。你的任务不是优化 Prompt，而是把任意来源（文本 Prompt、PDF、视频、网页、图片、文档）**编译** 成一个可复用、可维护、可扩展、可持续演化的 AI Skill。\n\n---\n\n## Optimization Goals\n\n整个编译过程中持续优化，而非机械转换。对每个设计决策回答：能否降低 Prompt 长度 / 提高复用性 / 模块化 / 参数化 / 插件化 / 拆分 Reference / 减少重复 / 提高可维护性 / 支持多 Agent / 支持版本演进？答案为\"是\"时自动重构。\n\n---\n\n## Core Principles\n\n| # | 原则 | 含义 |\n|---|------|------|\n| P1 | Prompt 不是 Skill | Skill = Role + Workflow + Knowledge + Decision Logic + Checklist + Rubric + Templates + Examples + Config + References + Output Schema |\n| P2 | 重复内容外置 | 超过一次使用的内容 → `references/` |\n| P3 | Prompt 最小化 | 知识外置，Workflow 独立，配置参数化 |\n| P4 | 不照搬 Prompt | 以 Skill 为中心重新设计，保留\"能力\"而非\"文字\" |\n| P5 | 元反思审计 | 在关键决策后自省：问题定义 / 假设 / 推理 / 证据 / 替代解释 / 边界 / 目标 / 不确定性 — 8 维度二次审视 |\n\n📍 [references/meta-reflection.md](references/meta-reflection.md)\n\n---\n\n## Compiler Pipeline\n\n```\nSource (Prompt / PDF / Video / URL / Image / Doc)\n  → [Pass I: Ingestion?] → [Pass 0: Triage] → [Pass 1: Analyze] → [Pass 2: Extract]\n  → [Pass 3: Design] → [Pass 4: Generate] → [Pass 5: Optimize?]\n  → [Pass 6: Validate] → Skill Package\n```\n\n| Pass | 执行 | 职责 | 详情 |\n|------|------|------|------|\n| **I Ingestion** | ⚠️ 条件 | 多源摄取：PDF/视频/网页/图片/文档 → 标准化结构化内容 + 来源溯源 | 📍 [references/pass-ingestion.md](references/pass-ingestion.md) |\n| **0 Triage** | ✅ 总是 | 判断是否值得编译 | 内联（决策表见下） |\n| **1 Analyze** | ✅ 总是 | 理解内容：目标/输入输出/边界/假设 | 📍 [references/pass-1-analyze.md](references/pass-1-analyze.md) |\n| **2 Extract** | ✅ 总是 | 能力图谱 + 知识清单（含证据分级）+ 角色矩阵 | 📍 [references/pass-2-extract.md](references/pass-2-extract.md) |\n| **3 Design** | ✅ 总是 | 架构类型 + 模块拆分（含诚实边界）+ Workflow + 目录结构 + 自测用例 + Skill 链接图 | 📍 [references/pass-3-design.md](references/pass-3-design.md) |\n| **4 Generate** | ✅ 总是 | 生成完整 Skill 文件包 | 📍 [references/pass-4-generate.md](references/pass-4-generate.md) |\n| **5 Optimize** | ⚠️ 条件 | 内容 > 500字 / 重复 / multi-agent 时执行 | 📍 [references/pass-5-optimize.md](references/pass-5-optimize.md) |\n| **6 Validate** | ✅ 总是 | 四层评估：结构完整性（A）+ IR 一致性（B）+ 触发质量（C，含压力测试）+ 平台合规（D） | 📍 [references/pass-6-validate.md](references/pass-6-validate.md) |\n\n**条件 Pass：**\n\n| Pass | 触发条件 | 详情 |\n|------|---------|------|\n| Plugin Discovery | Prompt 涉及外部能力（搜索/GitHub/DB/浏览器/MCP） | 📍 [references/plugin-discovery.md](references/plugin-discovery.md) |\n| Example Generation | Skill 涉及复杂流程/规则/评分体系 | 📍 [references/example-generation.md](refer"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn72r3ww47r1qyfaf233sf7q1982rh5f\",\n  \"slug\": \"skillcompiler\",\n  \"version\": \"1.2.2\",\n  \"publishedAt\": 1783844072951\n}"},{"path":"references/anti-patterns.md","content":"# Anti-Patterns — Skill 设计反模式\n\n**加载时机：** 📍 Pass 5 Optimize 执行 O1-O8 检查时加载。\n\n> 本文件定义 Skill Compiler 优化阶段（Pass 5）引用的反模式编号。\n> 完整 13 反模式库见 SkillForge [rubrics/anti-patterns.md](../../skillforge/rubrics/anti-patterns.md)。\n\n---\n\n## AP-02: Prompt Black Hole（Prompt 黑洞）\n\n**症状：** 把所有逻辑、规则、领域知识塞进一个巨大的 SKILL.md。token 爆炸，模型注意力分散。\n\n| 维度 | 详情 |\n|------|------|\n| 检测方法 | SKILL.md 超过 300 行 |\n| 修正 | 拆分为多 agent 或 reference 文件，SKILL.md 只做路由 manifest |\n| 严重度 | 🟠 High |\n| Pass 5 检查项 | O1（Prompt 长度优化） |\n\n## AP-04: Verification Theater（验证表演）\n\n**症状：** 声称有质量验证，但验证者和产出者是同一个 agent（或同一段 prompt）。\n\n| 维度 | 详情 |\n|------|------|\n| 检测方法 | 检查 verifier 是否独立于 producer |\n| 修正 | 使用独立的 Verifier Agent（干验分离原则） |\n| 严重度 | 🟠 High |\n| Pass 5 检查项 | O6（拆分检查） |\n\n## AP-06: Infinite Loop Without Guard（无界循环）\n\n**症状：** 工作流中有循环/迭代逻辑，但没有设置最大轮次上限。\n\n| 维度 | 详情 |\n|------|------|\n| 检测方法 | 检查 loop/feedback 步骤是否有 max_iterations |\n| 修正 | 设置硬性上限（推荐最多 3 轮） |\n| 严重度 | 🟠 High |\n| Pass 5 检查项 | O6（拆分检查） |\n\n## AP-07: God Agent（上帝 Agent）\n\n**症状：** 单个 agent 负责太多职责，prompt 中有 5+ 个不相关的\"功能\"。\n\n| 维度 | 详情 |\n|------|------|\n| 检测方法 | 读 agent 的 Capabilities/功能列表，检查是否有 >= 5 个不相关功能 |\n| 修正 | 按职责拆分为多个 agent，每个 agent 只负责一件事 |\n| 严重度 | 🟠 High |\n| Pass 5 检查项 | O5（模块化检查） |\n\n## AP-12: Trust-Domain Conflation（信任域混淆）\n\n**症状：** 同一逻辑概念被同一个文件承载，但该文件同时被\"隔离验证者\"和\"知情决策者\"读取。知情数据泄漏到隔离通道，导致隔离失效。\n\n| 维度 | 详情 |\n|------|------|\n| 检测方法 | ① 检查是否有 blind/isolated verifier；② 追踪其输入来源；③ 检查白名单文件是否包含知情数据 |\n| 修正 | 按信任域拆分文件（clean file vs dirty file） |\n| 严重度 | 🟠 High |\n| Pass 5 检查项 | O4（知识耦合检测） |"},{"path":"references/evidence-grading.md","content":"# Evidence Grading — 证据分级体系\n\n**加载时机：** 📍 Pass 2 Extract 执行知识提取时加载；Pass 6 Layer B 契约验证时加载。\n\n---\n\n## 设计哲学\n\n从多源内容（PDF/视频/网页/图片）提取的知识，可信度并不相同。原文直引、模型转述、编译器推断——这三类知识如果在 skill 中被同等对待，会导致用户把\"推测\"当成\"事实\"使用。\n\n本体系为每条知识打上证据等级，让 skill 的消费者（AI agent + 人类用户）知道\"这条结论多可靠\"。核心原则：**矛盾的信息不强行统一，而是保留并标注**——人本来就前后不一致，强制洗白会丢失真实信号。\n\n---\n\n## 三级证据体系\n\n| 等级 | 标签 | 含义 | 典型来源 |\n|------|------|------|---------|\n| **L1** | `primary` | 原文直引，可直接溯源到原始载体 | PDF 文本层、字幕原文、网页正文、代码注释 |\n| **L2** | `secondary` | 经过一次模型转述，存在转述损失 | OCR 结果、whisper 转写、视觉理解描述、摘要 |\n| **L3** | `inferred` | 编译器从上下文推断，原始载体未直接陈述 | 隐含假设、跨段推理、模式归纳 |\n\n### 判定规则\n\n| 内容形态 | 等级 | 理由 |\n|---------|------|------|\n| 引号内的原文 | `primary` | 可逐字核对 |\n| 代码块 | `primary` | 机器可验证 |\n| 表格数据 | `primary` | 结构化事实 |\n| OCR 提取的文字 | `secondary` | 可能有字符错误 |\n| 语音转写 | `secondary` | 可能有同音错误 |\n| \"这意味着...\" 的解读 | `inferred` | 推断而非原文 |\n| 从多个案例归纳的规律 | `inferred` | 归纳推理 |\n| 图表的结构化描述 | `secondary` | 视觉理解转述 |\n\n---\n\n## 在 Pass 2 中的应用\n\n### 提取时标注\n\nPass 2 Extract 从 `structured_content`（Pass I 产出）提取知识时，**每条知识必须带 `evidence` 字段**：\n\n```json\n{\n  \"content\": \"所有 API 响应必须包含 request_id 字段\",\n  \"source\": \"spec.pdf:p47\",\n  \"evidence\": \"primary\",\n  \"confidence\": 0.98\n}\n```\n\n### 默认值继承\n\n- 若 Pass I 为整份内容设定了默认 `evidence_grade`，Pass 2 提取的单条知识默认继承此等级\n- 但 Pass 2 可**逐条覆盖**：如从 `secondary` 内容中识别出一段原文直引，可升级为 `primary`\n\n### confidence 字段\n\n`confidence`（0-1）补充 `evidence` 的细粒度：\n- `primary` + `confidence: 0.95` = 高可信原文\n- `secondary` + `confidence: 0.6` = 低质量转写，需人工复核\n- `inferred` + `confidence: 0.7` = 中等把握的推断\n\n来源：OCR 置信度、whisper 置信度、或编译器对推断的自评。\n\n---\n\n## 冲突保留规则\n\n**核心原则：** 当多个来源对同一事实给出矛盾表述时，**不强行统一，保留所有版本并标注冲突**。\n\n### 冲突检测\n\nPass 2 提取时，若两条知识描述同一实体但内容矛盾：\n\n```json\n{\n  \"conflicts\": [\n    {\n      \"id\": \"C-001\",\n      \"topic\": \"API 限流策略\",\n      \"status\": \"open\",\n      \"versions\": [\n        { \"content\": \"每分钟 100 次\", \"source\": \"doc-v1.md\", \"evidence\": \"primary\", \"confidence\": 0.95 },\n        { \"content\": \"每分钟 1000 次\", \"source\": \"doc-v2.md\", \"evidence\": \"primary\", \"confidence\": 0.95 }\n      ],\n      \"resolution\": null,\n      \"resolved_by\": null,\n      \"resolved_at\": null,\n      \"note\": \"两个版本表述不一致，保留待用户裁决\"\n    }\n  ]\n}\n```\n\n### 冲突状态机\n\n```\nopen ──────────────────────────────► resolved\n  │                                     │\n  ├──► wontfix（不影响核心功能）         ├── resolution: prefer_higher_evidence\n  │                                     ├── resolution: prefer_newer\n  └──► deprecated（源已过期）            ├── resolution: merged\n                                        ├── resolution: user_override\n                                        └── resolved_by: user | compiler | cross_reference\n```\n\n| 状态 | 含义 | 终态？ |\n|------|------|--------|\n| `open` | 新发现冲突，待处理 | 否 |\n| `resolved` | 已裁决，标注了 resolution 和 resolved_by | 是 |\n| `wontfix` | 不影响核心功能，保留但不处理 | 是 |\n| `deprecated` | 冲突源已不再适用 | 是 |\n\n### 冲突处理策略\n\n| 策略 | 适用场景 |\n|------|---------|\n| `prefer_higher_evidence` | 一方 primary 一方 inferred，采用 primary |\n| `prefer_newer` | 来源有时间戳且差异显著，采用较新版本（需标注理由） |\n| `flag_for_user` | 矛盾影响 skill 核心功能，必须用户裁决 |\n| `merged` | 两版本可合并为更完整的表述 |\n| `user_ov"},{"path":"references/example-generation.md","content":"# Conditional Pass: Example Generation\n\n**加载时机：** 📍 仅当 Skill 涉及复杂流程/规则/评分体系时加载。\n\n---\n\n## 触发条件\n\n满足任一：\n- architecture_type = workflow 或 multi-agent\n- 有 rubrics（评分体系）\n- 有 5+ 条 rules\n- 用户显式要求\n\n---\n\n## 生成规则\n\n### 示例类型\n\n| 类型 | 用途 | 何时生成 |\n|------|------|---------|\n| Minimal | 最简输入输出，验证基本流程 | 总是 |\n| Normal | 典型使用场景 | 总是 |\n| Complex | 边界条件或复杂输入 | 当有复杂规则时 |\n| Edge Case | 极端输入 | 当有数值阈值时 |\n| Failure Case | 应该失败的输入 | 当有输入验证时 |\n| Anti-pattern | 不应该这样用 | 当有常见误用时 |\n\n### 示例格式\n\n```markdown\n# Example: {Title}\n\n**Type:** minimal | normal | complex | edge-case | failure | anti-pattern\n\n## Input\n{输入内容}\n\n## Expected Output\n{期望输出}\n\n## Notes\n{为什么是这个输出，关键决策点}\n```\n\n### 生成原则\n\n1. **从 Prompt 中提取** — 如果 Prompt 自带示例，优先用\n2. **覆盖关键路径** — 每个主要 workflow 步骤至少有一个示例\n3. **不过度生成** — 3-5 个高质量示例 > 10 个低质量示例\n4. **可扩展** — examples/ 目录设计为可追加"}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"Use when you need to compile any prompt OR multi-source content (PDF/video/URL/image/doc) into a production-grade, reusable AI Skill. Triggers on: 'prompt to... Skill: Skill Compiler Owner: qomob Summary: Use when you need to compile any prompt OR multi-source content (PDF/video/URL/image/doc) into a production-grade, reusable AI Skill. Triggers on: 'prompt to... Tags: latest:1.2.2 Version history: v1.2.2 | 2026-07-12T08:14:32.951Z | auto - Removed redundant documentation file: skill-card.md. - No changes to functionality, logic, or features. - Internal documentation houseke","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1032,"uniquenessScore":52,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T23:50:08.587Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-11T23:50:08.587Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-14T17:01:18.233Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}