{"id":"90ee3181-e744-4cd2-84ec-41fb152429d6","entityType":"agent","slug":"clawhub-wangjiaocheng-domain-payload-generator","name":"Domain Payload Generator","canonicalUrl":"https://www.xpersona.co/agent/clawhub-wangjiaocheng-domain-payload-generator","canonicalPath":"/agent/clawhub-wangjiaocheng-domain-payload-generator","generatedAt":"2026-10-11T07:41:46.804Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-11T04:06:21.189Z","emptyReason":null},"description":"领域负载物技能制作器（Meta-Skill）——Universal Task OS的技能工厂。独立创建与UTOS完全兼容的领域负载物技能，不依赖任何被创建的目标技能。提供领域分析框架（R1-R5分类定位/价值链拆解/任务枚举/UTOS映射推导）、三层结构模板（SKILL.md+catalog+requiremen... Skill: Domain Payload Generator Owner: wangjiaocheng Summary: 领域负载物技能制作器（Meta-Skill）——Universal Task OS的技能工厂。独立创建与UTOS完全兼容的领域负载物技能，不依赖任何被创建的目标技能。提供领域分析框架（R1-R5分类定位/价值链拆解/任务枚举/UTOS映射推导）、三层结构模板（SKILL.md+catalog+requiremen... Tags: latest:1.0.3 Version history: v1.0.3 | 2026-06-16T06:17:21.990Z | user - 增加UTOS接口校验清单项目数：从20项提升至21项，增强兼容性保障 - 「参考文件索引」和相关说明同步更新为21项校验 - 其余结构与功能保持一致 v1.0.2 | 2026-05-27T10:38:37.300Z | user -","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.2K downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s175zq13kt63ypfry5rgxh1pv18440m2:domain-payload-generator","sourceUrl":"https://clawhub.ai/wangjiaocheng/domain-payload-generator","homepage":"https://clawhub.ai/wangjiaocheng/skills/domain-payload-generator","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/wangjiaocheng/domain-payload-generator","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/wangjiaocheng/skills/domain-payload-generator","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":61,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"领域负载物技能制作器（Meta-Skill）——Universal Task OS的技能工厂。独立创建与UTOS完全兼容的领域负载物技能，不依赖任何被创建的目标技能。提供领域分析框架（R1-R5分类定位/价值链拆解/任务枚举/UTOS映射推导）、三层结构模板（SKILL.md+catalog+requiremen..."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T04:06:21.189Z","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-11T04:06:21.189Z","emptyReason":null},"stars":null,"forks":null,"downloads":1165,"packageName":null,"latestVersion":"1.0.3","tractionLabel":"1.2K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T04:06:21.173Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T04:06:21.189Z","lastCrawledAt":"2026-10-11T04:06:21.173Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T04:06:21.173Z","lastVerifiedAt":null,"highlights":[{"version":"1.0.3","createdAt":"2026-06-16T06:17:21.990Z","changelog":"- 增加UTOS接口校验清单项目数：从20项提升至21项，增强兼容性保障 - 「参考文件索引」和相关说明同步更新为21项校验 - 其余结构与功能保持一致","fileCount":7,"zipByteSize":20567},{"version":"1.0.2","createdAt":"2026-05-27T10:38:37.300Z","changelog":"- 增加了对 Workflow Refactor 的集成与推荐：复杂领域建议先用 Workflow Refactor 重构工作流，再生成领域负载物技能。 - 明确了与 Workflow Refactor 和 Universal Task OS 的分工及价值链关系，新增比较表和三者配合流程说明。 - 精化了生成前置判断，强调先重构可降低负载物复杂度，提高产出精准度。 - 对技能描述与使用规则进行调整，突出独立性保证基础上强化与流程重构的协同。 - 丰富了文档结构，细化“与其他技能的关系”及相关职责分工、三层价值属性等说明。","fileCount":7,"zipByteSize":20549},{"version":"1.0.1","createdAt":"2026-05-19T01:09:43.844Z","changelog":"- 优化说明和案例：已验证领域覆盖更新为智能硬件、单文件产出、网文创作者、医药合规等多类型领域。 - 案例展示细化：生成案例表格调整为突出领域特征和特殊维度，去除了具体域数/任务数（以各技能现有目录为准）。 - 案例排列顺序调整：按“硬件→软件→文本→文档”逻辑重新排序，展示从具象到抽象的能力。 - 说明文本简化和修正，使描述更精准、便于理解。","fileCount":6,"zipByteSize":16465},{"version":"1.0.0","createdAt":"2026-05-18T12:49:56.988Z","changelog":"Initial release: Domain Payload Skill Generator for Universal Task OS. - Create fully UTOS-compatible domain payload skills from scratch, independently of existing skills. - Provides a domain analysis framework, three-layer structure templates, a 20-point UTOS compatibility checklist, and a standardized skill generation workflow. - Includes practical validation with cases in pharma, web novels, smart hardware, and code output domains. - Outputs include SKILL.md and structured reference files, with full UTOS interface and workflow documentation.","fileCount":6,"zipByteSize":16356}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s175zq13kt63ypfry5rgxh1pv18440m2:domain-payload-generator","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-wangjiaocheng-domain-payload-generator/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-wangjiaocheng-domain-payload-generator/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-wangjiaocheng-domain-payload-generator/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-wangjiaocheng-domain-payload-generator/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-wangjiaocheng-domain-payload-generator/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-wangjiaocheng-domain-payload-generator/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-11T07:41:46.802Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-wangjiaocheng-domain-payload-generator/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-wangjiaocheng-domain-payload-generator/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-wangjiaocheng-domain-payload-generator/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-wangjiaocheng-domain-payload-generator/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-11T04:06:21.189Z","emptyReason":null},"readme":"Skill: Domain Payload Generator\n\nOwner: wangjiaocheng\n\nSummary: 领域负载物技能制作器（Meta-Skill）——Universal Task OS的技能工厂。独立创建与UTOS完全兼容的领域负载物技能，不依赖任何被创建的目标技能。提供领域分析框架（R1-R5分类定位/价值链拆解/任务枚举/UTOS映射推导）、三层结构模板（SKILL.md+catalog+requiremen...\n\nTags: latest:1.0.3\n\nVersion history:\n\nv1.0.3 | 2026-06-16T06:17:21.990Z | user\n\n- 增加UTOS接口校验清单项目数：从20项提升至21项，增强兼容性保障\n- 「参考文件索引」和相关说明同步更新为21项校验\n- 其余结构与功能保持一致\n\nv1.0.2 | 2026-05-27T10:38:37.300Z | user\n\n- 增加了对 Workflow Refactor 的集成与推荐：复杂领域建议先用 Workflow Refactor 重构工作流，再生成领域负载物技能。\n- 明确了与 Workflow Refactor 和 Universal Task OS 的分工及价值链关系，新增比较表和三者配合流程说明。\n- 精化了生成前置判断，强调先重构可降低负载物复杂度，提高产出精准度。\n- 对技能描述与使用规则进行调整，突出独立性保证基础上强化与流程重构的协同。\n- 丰富了文档结构，细化“与其他技能的关系”及相关职责分工、三层价值属性等说明。\n\nv1.0.1 | 2026-05-19T01:09:43.844Z | user\n\n- 优化说明和案例：已验证领域覆盖更新为智能硬件、单文件产出、网文创作者、医药合规等多类型领域。\n- 案例展示细化：生成案例表格调整为突出领域特征和特殊维度，去除了具体域数/任务数（以各技能现有目录为准）。\n- 案例排列顺序调整：按“硬件→软件→文本→文档”逻辑重新排序，展示从具象到抽象的能力。\n- 说明文本简化和修正，使描述更精准、便于理解。\n\nv1.0.0 | 2026-05-18T12:49:56.988Z | user\n\nInitial release: Domain Payload Skill Generator for Universal Task OS.\n\n- Create fully UTOS-compatible domain payload skills from scratch, independently of existing skills.\n- Provides a domain analysis framework, three-layer structure templates, a 20-point UTOS compatibility checklist, and a standardized skill generation workflow.\n- Includes practical validation with cases in pharma, web novels, smart hardware, and code output domains.\n- Outputs include SKILL.md and structured reference files, with full UTOS interface and workflow documentation.\n\nArchive index:\n\nArchive v1.0.3: 7 files, 20567 bytes\n\nFiles: references/domain-analysis-framework.md (8485b), references/generator-workflow.md (8573b), references/structure-template.md (10278b), references/utos-interface-checklist.md (6267b), skill-card.md (2350b), SKILL.md (7906b), _meta.json (143b)\n\nFile v1.0.3:SKILL.md\n\n---\nname: domain-payload-generator\nauthor: 王教成 Wang Jiaocheng (波动几何)\ndescription: 领域负载物技能制作器（Meta-Skill）——Universal Task OS的技能工厂。独立创建与UTOS完全兼容的领域负载物技能，不依赖任何被创建的目标技能。提供领域分析框架（R1-R5分类定位/价值链拆解/任务枚举/UTOS映射推导）、三层结构模板（SKILL.md+catalog+requirements+exemplars）、UTOS接口校验清单（21项逐条检查零冲突保障）、标准化生成工作流。复杂领域建议先用 Workflow Refactor 重构工作流再生成。触发词：领域负载物、技能制作、技能生成、知识参考库、新领域技能、domain payload、skill generator、meta-skill。\n---\n\n# 领域负载物技能制作器\n\n## 定位\n\n本技能是一个 **元技能（Meta-Skill）**——它的产出不是领域知识本身，而是**领域负载物技能**。当用户说\"帮我做一个XX领域的知识参考库\"时，本技能负责从零创建完整的、与UTOS完全兼容的领域负载物技能。\n\n| 本技能提供 | 消费方式 |\n|-----------|---------|\n| 领域分析框架 | 分析新领域并确定域划分和任务类型 |\n| 三层结构模板 | 自动生成SKILL.md + references/三层文件 |\n| UTOS接口校验清单 | 确保生成的技能与UTOS无冲突 |\n| 生成工作流 | 从用户输入到完整技能的标准化流程 |\n\n## 核心能力\n\n```\n用户输入：\"帮我做一个XX领域的知识参考库\"\n ↓\n ┌─────────────────────┐\n │ Step 1: 领域分析 │ ← 用领域分析框架拆解新领域\n │ 确定域数/任务数 │\n ├─────────────────────┤\n │ Step 2: 结构生成 │ ← 用三层结构模板填充内容\n │ SKILL.md │\n │ + catalog │\n │ + requirements │\n │ + exemplars │\n ├─────────────────────┤\n │ Step 3: UTOS校验 │ ← 用接口校验清单检查一致性\n │ 无冲突 → 输出 │\n │ 有冲突 → 修正 │\n └─────────────────────┘\n ↓\n 完整的XX领域知识参考库技能（可直接使用）\n```\n\n## 与其他技能的关系\n\n### 独立性保证\n\n> **关键设计约束**：本技能**不依赖任何被它创建的领域技能**。它在创建时是自包含的，仅依赖：\n> - Universal Task OS（用于理解目标接口）\n> - Workflow Refactor（复杂领域先重构工作流，再生成技能）\n> - 自身的references文件（框架+模板+校验清单）\n\n这意味着：\n- ✅ 创建任何领域技能时，不需要该领域技能已存在\n- ✅ 本技能可以独立运行，输出产物后才被其他流程消费\n\n### 职责分工\n\n| 技能 | 管什么 | 不管什么 |\n|------|--------|---------|\n| **Workflow Refactor** | 流程结构——哪些环节保留、消除、校准 | 领域知识内容（清单/样本） |\n| **Domain Payload Generator** | 领域知识内容——catalog(清单)、requirements(要求)、exemplars(范本) | 流程结构 |\n| **Universal Task OS** | 三轴执行框架——执行轴编排、内容轴消费清单/样本、创新轴突破 | 具体领域内容 |\n\n### 价值链\n\n```\n传统工作流 ──[Workflow Refactor]──→ 重构后IPO基元链\n │\n ▼\n [Domain Payload Generator]\n │\n ▼\n 领域负载物（简化版）\n │\n ▼\n [Universal Task OS] 持续执行\n```\n\n转化→创建→执行，是一条价值链，不是替代关系。\n\n### 三条路径对比\n\n| 路径 | 清单/样本来源 | 优势 | 劣势 |\n|------|-------------|------|------|\n| **Workflow Refactor 单独用** | 无，用户临时提供 | 流程极简 | 内容质量靠用户自身积累 |\n| **重构 + Domain Payload + UTOS** | 领域负载物结构化提供 | 流程+内容双保险，系统化 | 首次生成有成本 |\n| **重构 + UTOS（无领域负载物）** | 用户手动输入到 IPO 的 I | 灵活 | 每次都要手动准备，覆盖度不稳定 |\n\n### 重构如何简化负载物\n\n领域负载物的复杂度 = 领域本身的复杂度 + 传统工作流遗留的冗余任务类型。\n\n| 场景 | catalog 任务数 | requirements 复杂度 | exemplars 数量 |\n|------|---------------|-------------------|---------------|\n| 未重构直接生成 | 包含传递/协调/格式环节对应的任务类型 | 大量\"人的局限补偿\"相关要求 | 范本里嵌套冗余中间产物 |\n| 先重构再生成 | 只保留✅核心+🔶校准+⚡关键校验对应的类型 | 要求聚焦事情本身 | 范本干净，无冗余传递物 |\n\n先重构再生成，负载物体积和认知负荷都大幅降低。\n\n### 三层价值属性\n\n| 技能 | 价值类型 | 使用频率 |\n|------|---------|---------|\n| **Workflow Refactor** | 转化价值——解决\"从旧到新\"的转化问题 | 低频、脉冲式 |\n| **Domain Payload Generator** | 创建价值——解决\"从无到有\"的创建问题 | 中频、按需 |\n| **Universal Task OS** | 运行时价值——解决\"执行任务\"的运行问题 | 高频、持续 |\n\nWorkflow Refactor 的价值不会归零（新领域不断出现、已重构领域会过时需要重新审视、AI能力跃升时重构本身可以被重构），但会随成熟领域完成重构而衰减为低频触发。\n\n## 与UTOS的关系\n\n本技能生成的所有产物都遵循以下UTOS兼容性契约：\n\n| 兼容性维度 | 要求 |\n|-----------|------|\n| **三层结构一致** | 必须为：第一层(清单+拓扑) + 第二层(要求) + 第三层(范本) |\n| **依赖声明格式** | 必须含强依赖UTOS声明 + 加载检查流程 + 降级模式 |\n| **元操作映射** | 每个任务必须标注S/C/A/O/I/G映射提示 |\n| **五字段Schema** | 每个任务组件必选：ID/名称/说明/依赖/UTOS映射 |\n| **域间逻辑流** | 域间必须有明确的价值链逻辑顺序 |\n| **依赖拓扑摘要** | 必须有跨域管线链路描述 |\n| **Step 0-4接口** | SKILL.md必须含\"与UTOS的接口\"章节（Step 0~4各条目） |\n\n## 使用规则\n\n1. **生成前置判断**：复杂领域建议先用 Workflow Refactor 重构工作流，再基于重构结果生成技能——这样产出的技能更精准，不会把人的局限补偿层编码进领域知识。简单或标准化领域可直接生成，跳过重构。\n2. **触发条件**：用户请求创建新的领域知识参考库/领域负载物技能时激活\n3. **首次加载**：读取 `references/domain-analysis-framework.md` 获取领域分析方法\n4. **按需深入**：确认领域后，读取 `references/structure-template.md` 获取三层结构模板；读取 `references/utos-interface-checklist.md` 获取校验规则\n5. **执行生成**：按 `references/generator-workflow.md` 的步骤逐一执行\n6. **输出交付**：将生成的技能写入指定目录\n\n## 参考文件索引\n\n| 文件 | 用途 |\n|------|------|\n| `references/domain-analysis-framework.md` | 新领域分析方法论——如何从一个领域名推导出域划分、任务类型、依赖关系 |\n| `references/structure-template.md` | 三层结构模板——SKILL.md/catalog/requirements/exemplars的标准模板及变量替换规则 |\n| `references/utos-interface-checklist.md` | UTOS兼容性校验清单——21项逐条检查，确保生成的技能与UTOS零冲突 |\n| `references/generator-workflow.md` | 完整生成工作流——从用户输入到技能产出的每一步操作指南 |\n\nFile v1.0.3:_meta.json\n\n{\n \"ownerId\": \"kn75v65h3zezxajen2xf64b2v1845d98\",\n \"slug\": \"domain-payload-generator\",\n \"version\": \"1.0.3\",\n \"publishedAt\": 1781590641990\n}\n\nFile v1.0.3:references/domain-analysis-framework.md\n\n# 领域分析框架\n\n当用户提出\"帮我做一个XX领域知识参考库\"时，用此框架从零分析新领域并推导出完整的域划分和任务类型。\n\n---\n\n## Step A：领域定义\n\n### A-1 领域名称规范化\n\n| 输入 | 处理 | 输出 |\n|------|------|------|\n| 用户原始描述 | 提取核心领域关键词 + 确定边界 | 标准化的领域英文名 + 中文名 |\n\n**示例映射**：\n\n| 用户输入 | 规范化领域名 | 域代号前缀 |\n|---------|------------|-----------|\n| \"写小说的\" | Novel Writing (小说创作) | N |\n| \"做智能硬件的\" | Smart Hardware (智能硬件) | H |\n| \"写HTML/Python/Shell/SQL单文件工具的\" | Single-File Output (单文件产出) | S |\n| \"做会计代账的\" | Bookkeeping Agency (代理记账) | B |\n| \"教人减肥健身的\" | Metabolic Healing (代谢慢病) | M |\n\n### A-2 领域分类定位\n\n将目标领域在以下坐标系中定位，决定后续生成的参数倾向：\n\n| 维度 | 低 | 高 | 影响什么 |\n|------|----------|----------|---------|\n| **R1 信息密度(S/C权重)** | 操作类/手工类 → S轻 | 数据类/研究类 → S重C深 | 感知和认知单元占比 |\n| **R2 创造性(A权重)** | 流程类/合规类 → A标准 | 艺术类/研发类 → A极高 | 内容轴创新轴激活频率 |\n| **R3 交互性(I权重)** | 独立产出类 → I少 | 服务类/协作类 → I多 | 交互单元数量 |\n| **R4 规范性(G权重)** | 创作类/设计类 → G偏松 | 法规类/工程类 → G偏严 | 守护单元密度、合规约束数量 |\n| **R5 迭代性(循环)** | 一次性交付→循环少 | 持续运营/连载→循环多 | 管线中↻模式的使用 |\n\n**快速判定表**：\n\n| 典型领域 | R1信息密度 | R2创造 | R3交互 | R4规范 | R5迭代 | 推导结果 |\n|---------|-----------|--------|--------|--------|--------|---------|\n| 医药文档 | 高 | 中 | 高 | 高 | 中 | S重C深I高G高A标准 |\n| 网络小说 | 中 | 极高 | 中 | 低 | 极高 | A极高G松循环多 |\n| 智能硬件 | 高 | 高 | 高 | 高 | 高 | 全维度高+G极高 |\n| 单文件代码 | 中 | 中 | 低 | 高 | 中 | G高A标准结构清晰 |\n| 代账记账 | 高 | 低 | 中 | 高 | 周期性 | G高A低C深O强 |\n| 教学培训 | 中 | 中 | 高 | 中 | 低 | I高A中G中 |\n\n### A-3 R评分到UTOS参数映射\n\n将A-2的R1-R5评分映射为具体的UTOS执行参数：\n\n| R评分 | 元操作权重调整 | AI自治度偏好 | 守护(G)密度 | 管线模式倾向 |\n|-------|--------------|-------------|------------|-------------|\n| **R1信息密度=高** | S↑C↑（感知和认知占比高） | 🟨半自动偏多（需人确认数据源） | 数据准确性校验 | P3并行汇聚（多源数据） |\n| **R1信息密度=低** | S↓C↓（轻感知轻认知） | ⬛全自动偏多 | 低 | P1基础闭环 |\n| **R2创造性=高** | A↑（行动/产出占比高） | ⬜辅助偏多（人定方向） | 风格一致性校验 | P7发散收敛 |\n| **R2创造性=低** | A标准 | ⬛全自动偏多 | 低 | P1基础闭环 |\n| **R3交互性=高** | I↑（交互占比高） | ⬜辅助偏多（人对外沟通） | 沟通合规校验 | P5交互驱动 |\n| **R3交互性=低** | I↓ | ⬛全自动偏多 | 低 | P1基础闭环 |\n| **R4规范性=高** | G↑O↑（守护和组织占比高） | 🟨/⬜（合规节点必须人工） | 高密度，每阶段嵌入G | P6全守护 |\n| **R4规范性=低** | G↓ | ⬛全自动偏多 | 低 | P1基础闭环 |\n| **R5迭代性=高** | 循环↑（短链高频） | 🟨半自动（每轮需确认） | 每轮迭代末尾G | P2迭代精炼 |\n| **R5迭代性=低** | 循环↓（长链低频） | ⬛/🟨 | 终末校验 | P1基础闭环 |\n\n**使用方式**：对每个R维度取评分后，叠加各维度的参数调整。多个维度同时为高时，参数叠加（如R1高+R4高 = S↑C↑G↑O↑ + 高密度守护）。\n\n---\n\n## Step B：域划分（Domain Partitioning）\n\n### B-1 价值链拆解法\n\n**核心方法**：沿领域的**价值链或生命周期**拆分域。每个域代表价值链上的一个阶段。\n\n**通用模板——按生命周期型**（适用于产品/项目/创作类领域）：\n\n```\n阶段0：输入/素材阶段 → 需求/调研/灵感/原料\n阶段1：规划/架构阶段 → 设计/架构/大纲/方案\n阶段2：执行/生产阶段 → 开发/写作/制造/编码（可能有多条并行线）\n阶段3：验证/测试阶段 → 测试/审查/校验/评审\n阶段4：交付/发布阶段 → 发布/部署/上线/出版\n阶段5：运营/维护阶段 → 运营/迭代/客服/优化\n```\n\n**通用模板——按职能分工型**（适用于组织/流程类领域）：\n\n```\n职能1：前端/面向用户 → 销售/服务/展示/内容\n职能2：中台/核心能力 → 产品/技术/专业服务\n职能3：后台/支撑保障 → 合规/财务/人力/IT\n职能4：横向/协同管理 → 项目/质量/战略/风险\n```\n\n### B-2 域数量确定原则\n\n| 因素 | 少域(5-7) | 中等域(8-10) | 多域(11+) |\n|------|----------|-------------|----------|\n| 领域复杂度 | 低 | 中 | 高 |\n| 任务同质化程度 | 高（任务类型相似） | 中 | 低（各域差异大） |\n| 依赖链长度 | 短(<3层) | 中(3-5层) | 长(>5层) |\n| 参考案例 | — | 单文件产出、网文、硬件 | 医药 |\n\n**经验公式**：域数 = ⌈ln(预估总任务数) × 2⌉，取值范围[5, 15]\n\n### B-3 域命名规范\n\n每个域必须包含：\n- **域代号**：单个大写字母 + 数字编号（如 N1, H3, S5）\n- **域名称**：2-6个中文词，准确描述域的范围\n- **对标说明**（可选）：如果是从已有技能迁移，标注对应关系\n\n**命名禁忌**：\n- ❌ 域名之间有包含关系（如\"开发\"和\"软件开发\"）\n- ❌ 域名过于抽象（如\"管理\"、\"支持\"）\n- ✅ 域名具体且互斥（如\"原型验证\" vs \"量产制造\"，不重叠）\n\n---\n\n## Step C：任务类型推导\n\n### C-1 任务枚举法\n\n对每个域，使用以下问题清单枚举任务类型：\n\n```\n1. 这个域要\"产生\"什么？ → 产出的文档/制品/代码是什么？\n2. 产出之前需要\"准备\"什么？ → 依赖哪些前置输入？\n3. 产出之后需要\"检查\"什么？ → 有哪些质量/合规要求？\n4. 这个域能\"帮助\"其他域做什么？ → 输出被谁消费？\n5. 这个域内是否有\"子流程\"？ → 是否需要进一步拆分为多个任务？\n```\n\n### C-2 任务ID命名规范\n\n```\n{域代号}-{两位序号} 如: N1-01, H4-05, S7-03\n```\n\n### C-3 每个任务的必填字段\n\n| 字段 | 说明 | 示例 |\n|------|------|------|\n| ID | 任务ID | D5-03 |\n| 名称 | 任务类型的简短名称 | DA故事线文档 |\n| 说明 | 一句话描述这个任务产出什么 | 页序、每页核心信息、视觉建议 |\n| 依赖 | 前置任务ID列表，无依赖写\"无（入口）\" | D5-01 |\n| UTOS映射提示 | S/C/A/O/I/G + 组合符号 | C→A（先认知后行动） |\n\n### C-4 UTOS映射提示的推导规则\n\n| 任务特征 | 映射提示 |\n|---------|---------|\n| 收集信息/调研/扫描 | S (感知) |\n| 分析/评估/推理/决策 | C (认知) |\n| 产出/创建/编写/制作 | A (行动) |\n| 存储/归档/索引/分类 | O (组织) |\n| 协调/沟通/确认 | I (交互) |\n| 校验/审核/合规/约束 | G (守护) |\n| 先收集再分析 | S→C |\n| 先分析再产出 | C→A |\n| 分析+产出+需审核 | C→A→G |\n| 采集后直接产出 | S→A |\n\n---\n\n## Step D：依赖拓扑构建\n\n### D-1 域间逻辑流\n\n域间按价值链顺序排列，形成主线流：\n\n```\nD1 → D2 → D3 → ... → Dn\n```\n\n同时标注**并行分支**和**反馈回路**。\n\n### D-2 跨域管线链路\n\n识别3-8条关键跨域管线，每条格式为：\n\n```\n[链路名]: 任务A → 任务B → 任务C → ...\n [对应已有技能的某条链路（如为迁移）]\n```\n\n**管线发现启发式**：\n1. **主链路**：从入口到最终交付的最短路径\n2. **数据链路**：数据/信息的流转路径\n3. **质量链路**：从生产到检验到修正的闭环\n4. **资源链路**：物料/供应链的依赖路径\n5. **加速链路**：MVP/快速版本的特殊路径\n\n### D-3 依赖拓扑摘要格式\n\n```markdown\n## 依赖拓扑摘要\n\n**[链路名1]**: X-01 → X-02 → X-03 → ...\n**[链路名2]**: Y-01 → Y-02 ‖ Y-03 → Y-04 （并行）\n**[闭环链]**: Z-01 → Z-02 → Z-03 → [回到Z-01]\n\n更多组合由UTOS根据具体任务动态推导。\n```\n\nFile v1.0.3:references/generator-workflow.md\n\n# 生成工作流\n\n从用户输入\"帮我做一个XX领域知识参考库\"到完整技能产出的标准化操作流程。\n\n---\n\n## 总览\n\n```\n输入: 用户描述的领域名称\n │\n ├─ Step 1: 领域分析（30-40%时间）\n │ ├─ 1A: 领域定义与分类定位\n │ ├─ 1B: 域划分\n │ └─ 1C: 任务类型枚举 + 依赖推导\n │\n ├─ Step 2: 文件生成（40-50%时间）\n │ ├─ 2A: SKILL.md（用模板填充）\n │ ├─ 2B: references/catalog.md（任务清单+拓扑）\n │ ├─ 2C: references/requirements.md（槽位定义）\n │ └─ 2D: references/exemplars.md（范本框架）\n │\n ├─ Step 3: UTOS校验（10-15%时间）\n │ └─ 21项逐条检查 → 修正FAIL项\n │\n └─ 输出: 完整可用的领域负载物技能目录\n```\n\n---\n\n## Step 1：领域分析\n\n### 1A：领域定义与分类定位\n\n**操作**：\n1. 请用户描述目标领域的核心工作内容\n2. 使用 `domain-analysis-framework.md` 的 **Step A** 进行规范化\n3. 输出：领域英文名、域名代号前缀、R1-R5定位结果\n\n**输出物**：\n\n```\n领域名: {English Name}\n代号前缀: {X}\nR1(信息密度): 高/中/低 → S/C权重: ...\nR2(创造性): 高/中/低 → A权重: ...\nR3(交互性): ... → I权重: ...\nR4(规范性): ... → G权重: ...\nR5(迭代性): ... → 循环模式使用频率: ...\n```\n\n### 1B：域划分\n\n**操作**：\n1. 根据领域特征选择拆解方法（价值链型 vs 职能分工型 vs 混合型）\n2. 使用 `domain-analysis-framework.md` 的 **Step B** 进行域划分\n3. 确定域数量和每个域的范围边界\n\n**输出物**：\n\n```\n共 N 个域:\n{X}1 {域名1} — {一句话说明范围}\n{X}2 {域名2}\n...\n{X}N {域名N}\n\n域间逻辑流: {X}1 → {X}2 → ... → {X}N\n```\n\n### 1C：任务类型枚举与依赖推导\n\n**操作**：\n1. 对每个域，使用 **Step C** 的问题清单枚举任务\n2. 为每个任务分配ID（{X}{域号}-{序号}）和UTOS映射提示\n3. 使用 **Step D** 构建依赖拓扑\n\n**输出物**：\n\n```\n总任务数: M 种\n各域任务分布: {X}1(n1种) / {X}2(n2种) / ...\n\n关键跨域管线:\n- {管线名1}: {ID}→{ID}→{ID}\n- {管线名2}: ...\n（共 K 条）\n```\n\n---\n\n## Step 2：文件生成\n\n### 2A：SKILL.md\n\n**操作**：\n1. 打开 `structure-template.md` 中的 SKILL.md 模板\n2. 逐一替换所有 `{变量}` 为 Step 1 的分析结果\n3. 特别注意以下字段必须**定制化**而非照搬模板：\n - \"领域特有维度\"章节 —— 必须是该领域独有的\n - \"与UTOS的接口\" Step 1 领域校准 —— 必须有具体参数\n - \"域概览\"表格 —— 必须是实际划分的结果\n\n### 2B：Catalog文件\n\n**操作**：\n1. 按1C的枚举结果，为每个域创建表格\n2. 每个任务一行，格式严格遵循模板\n3. 文件末尾追加\"依赖拓扑摘要\"章节\n4. 至少列出3条跨域管线链路\n\n**质量检查**：\n- [ ] 所有任务ID格式正确\n- [ ] 所有依赖引用有效\n- [ ] UTOS映射提示使用了正确代号\n- [ ] 域间逻辑流声明清晰\n\n### 2C：Requirements文件\n\n**操作**：\n1. 对每个任务创建槽位定义\n2. **必填**：必选组件 + 组装顺序 + 格式\n3. **推荐填写**：可选组件 + 约束字段\n4. 当任务数>30时，可将部分域的要求迁移至 `references/structure-requirements-{domain}.md` 子文件\n\n**槽位编写原则**：\n- 必选组件回答\"这个产出物的最小必要元素是什么？\"\n- 组装顺序回答\"按什么逻辑顺序填充这些元素？\"\n- 约束回答\"这个领域对这个产出的特殊限制是什么？\"\n\n### 2D：Exemplars文件\n\n**操作**：\n1. 创建范本清单主文件（按域分组，每个任务一行，用任务ID索引）\n2. 创建范本标准格式模板（子文件模板）\n3. 如果有现成可用范本，存入 `references/exemplars/` 子目录并在主文件注册\n4. 否则创建 `[待填充]` 占位符框架\n\n**范本策略选择**：\n\n| 领域类型 | 范本策略 | 说明 |\n|---------|---------|------|\n| 代码产出类 | 范本=可运行代码 | 如单文件技能，嵌入完整.html/.py/.sh/.sql |\n| 文档产出类 | 范本=结构化文档模板 | 如医药/代账，嵌入脱敏范例 |\n| 创作产出类 | 范本=技法标注片段 | 如网文，嵌入经典片段+拆解 |\n| 流程产出类 | 范本=流程示例 | 如硬件，嵌入脱敏项目案例 |\n\n---\n\n## Step 3：UTOS校验\n\n### 执行校验\n\n1. 打开 `utos-interface-checklist.md`\n2. 逐项执行 A→B→C→D→E 五类检查\n3. 记录每项结果（PASS/FAIL/N/A）\n\n### 处理FAIL项\n\n| FAIL类别 | 处理策略 |\n|---------|---------|\n| A类(结构) | 通常是因为模板复制遗漏——全局搜索替换修正 |\n| B类(Schema) | 缺失字段或无效值——补充/修正 |\n| C类(槽位) | 覆盖率不足——至少为核心域补全 |\n| D类(接口) | 照搬无定制——重写该领域特定内容 |\n| E类(范本) | 未创建——建立空框架 |\n\n### 校验通过标志\n\n当满足以下条件时，校验通过：\n- A类: 6/6 PASS\n- B类: 5/5 PASS\n- C类: ≥3/4 PASS\n- D类: 3/3 PASS\n- E类: ≥2/3 PASS\n\n### 内容质量评估（结构校验通过后）\n\n结构校验只验证\"有没有\"，以下维度评估\"好不好\"：\n\n| 维度 | 评估方法 | 合格标准 |\n|------|---------|---------|\n| **任务覆盖度** | 核对领域核心工作流是否都被catalog中的任务覆盖 | 核心工作流无遗漏，可接受少量边缘任务缺失 |\n| **域间边界清晰度** | 检查各域的任务是否有重叠或归属模糊 | 无同一任务出现在两个域中，域间边界互斥 |\n| **依赖拓扑连通性** | 从入口任务出发，能否沿依赖链到达所有非入口任务 | 无孤立子图，无循环依赖 |\n| **要求可操作性** | requirements中的必选组件和组装顺序是否具体到可直接执行 | 不出现\"待定\"\"其他\"等模糊项 |\n| **范本可用性** | 状态为\"可用\"的范本是否确实可作为样本法参考 | 范本内容完整，四维特征摘要存在 |\n\n---\n\n## Step 4：输出与交付\n\n### 目录结构\n\n生成的技能应具有以下目录结构：\n\n```\n{skill-name}/\n├── SKILL.md # 技能定义\n└── references/\n ├── {catalog-filename}.md # 第一层：清单+拓扑\n ├── {requirements-filename}.md # 第二层：槽位定义\n ├── exemplars.md # 第三层：范本清单主文件\n └── exemplars/ # 第三层：具体范本子文件\n ├── {X}-01-{task-name}.md\n ├── {X}-01-{task-name}.summary.md\n └── ...\n```\n\n### 交付检查\n\n在交付给用户前，最终确认：\n\n- [ ] 所有文件存在且非空（SKILL.md + references/ 下的 catalog、requirements、exemplars 主文件）\n- [ ] SKILL.md可在WorkBuddy中被识别和加载\n- [ ] references/下的文件路径在SKILL.md中引用正确\n- [ ] 无遗留的 `{变量}` 占位符\n- [ ] 通过UTOS接口21项校验\n\n### 后续维护与迭代\n\n**首次交付后**：\n1. 范本库(exemplars.md)中的`[待填充]`占位符需要后续补充真实范本才能发挥样本法的完整能力\n2. 结构要求(requirements.md)中的`[待补充]`约束字段需要根据实际需求定义\n3. 技能生成后可通过实际使用持续迭代完善\n\n**领域演进时的增量更新**：\n1. 重新跑 `domain-analysis-framework.md` 的 Step A-B，确认域划分是否需要调整\n2. 对比新旧 catalog 的 diff：哪些任务新增、删除、合并、拆分\n3. 仅更新变化的域和任务，不全量重建——保持已有范本和要求不丢失\n4. 更新后重新跑 UTOS 接口校验（21项）\n5. 版本记录：在 SKILL.md 末尾记录变更摘要\n\n**范本扩充流程**：\n1. 从实际使用中收集高质量产出作为候选范本\n2. 脱敏后存入 `references/exemplars/` 目录\n3. 在 exemplars.md 主文件中更新状态（空→可用）\n4. 为每个新范本撰写四维特征摘要（结构/风格/逻辑/格式）\n\n---\n\n## 快速生成速查卡\n\n对于熟练用户，以下是快速生成的心智模型：\n\n```\n听到新领域 → \n ① 它的价值链是什么？（拆成5-12个域）→ \n ② 每个域要产出什么？（列成3-8个任务/域）→ \n ③ 任务间谁先谁后？（画依赖箭头）→ \n ④ 每个任务的\"零件清单\"是什么？（写必选组件+顺序）→ \n ⑤ 有没有好的例子可以放进去？（收集或标记待填充）→ \n ⑥ 和UTOS对得上吗？（跑21项校验清单）\n```\n\nFile v1.0.3:references/structure-template.md\n\n# 三层结构模板\n\n本文件定义了领域负载物技能的标准三层结构模板。生成新技能时，将 `{变量}` 替换为实际内容。\n\n---\n\n## SKILL.md 模板\n\n```markdown\n# {技能中文名}知识参考库\n\n## 定位\n\n本技能是 **Universal Task OS 的领域负载物仓库**，不包含任何执行框架。只提供{领域名}的\"是什么\"和\"长什么样\"——执行全部委托UTOS。\n\n| 本技能提供 | UTOS消费方式 |\n|-----------|-------------|\n| {领域名}任务清单+依赖拓扑 | 内容轴·清单法的任务目录 + 执行轴·管线编排的依赖输入 |\n| {任务类型}要求 | 内容轴·清单法的组件清单 |\n| 优秀范本（待填充） | 内容轴·样本法的样本 |\n\n## 三层结构\n\n```\n第一层：{清单名称} + 依赖拓扑 → references/{catalog-filename}.md\n第二层：{第二层名称} → references/{requirements-filename}.md\n第三层：{第三层名称} → references/exemplars.md\n```\n\n## 依赖声明\n\n本技能**强依赖** Universal Task OS (universal-task-os)。没有UTOS，本技能只有参考查阅能力，无法执行任何{任务类型}任务。\n\n**加载检查流程**（每次激活时执行）：\n\n1. 检测 `universal-task-os` 技能是否已安装\n2. **未安装** → 自动安装 `universal-task-os` 技能\n3. **安装成功** → 同时加载UTOS，按本技能\"使用规则\"执行\n4. **安装失败** → 降级为**只读参考模式**：\n - ✅ 允许：查阅{清单名称}、{第二层简称}、范本索引\n - ❌ 拒绝：任何涉及{任务类型}产出、管线编排、内容生成的任务，并提示\"需先安装 Universal Task OS\"\n\n**任务模式判定**：\n\n| 任务类型 | 无UTOS | 有UTOS |\n|---------|--------|--------|\n| 查阅{清单名称}/要求/范本 | ✅ 只读参考 | ✅ 完整 |\n| 按{方法论}产出{成品类型} | ❌ 拒绝 | ✅ UTOS编排执行 |\n| 依赖拓扑推导{管线名称} | ❌ 拒绝 | ✅ UTOS执行轴 |\n| {合规/质量}检查点插入 | ❌ 拒绝 | ✅ UTOS守护单元 |\n\n## 使用规则\n\n1. **依赖检查**：激活时按上述流程检测并安装UTOS\n2. **首次加载**：读取 `references/{catalog-filename}.md`，获取域分类、依赖拓扑、UTOS元操作映射提示\n3. **按需深入**：确认目标{任务}类型后，读取 `references/{requirements-filename}.md` 获取组件清单；如需样本法，读取 `references/exemplars.md` 获取范本\n4. **委托UTOS**：将{清单名称}作为清单法输入、范本作为样本法输入、依赖拓扑作为管线编排输入，交给UTOS执行轴+内容轴处理\n5. **{用户填充说明}**\n\n## 与UTOS的接口\n\n当UTOS处理{领域名}领域任务时：\n\n- **Step 0 三轴判定**：{领域}任务通常为{复杂度判定}+{内容类型判定} → {激活的轴}\n- **Step 1 领域校准**：{领域}的R1(信息密度)={描述}+R2(创造性)={描述}+R3(交互性)={描述}+R4(规范性)={描述}+R5(迭代性)={描述} → {权重推导结论}\n- **Step 2 内容轴**：清单法用本技能的{requirements-filename}；样本法用本技能的exemplars\n- **Step 3 执行轴**：管线编排基于本技能的依赖拓扑自动推导元操作序列\n- **Step 4 交付**：G类守护单元自动插入{质量检查点类型}\n\n## {领域特有维度标题}\n\n{特有维度的表格或列表说明}\n\n## {域概览标题}\n\n按{组织原则}组织，共{域数}域{总任务数}种{任务类型}：\n\n| 域 | 任务数 | 典型任务 |\n|----|--------|---------|\n{域概览表格行}\n\n完整清单见 `references/{catalog-filename}.md`。\n```\n\n### SKILL.md 变量替换表\n\n| 变量 | 说明 | 示例值 |\n|------|------|--------|\n| `{技能中文名}` | 技能的中文名称 | 医药行业文档 / 网络小说创作 |\n| `{领域名}` | 领域的简称 | 医药 / 网络小说 / 智能硬件 |\n| `{任务类型}` | 领域中的工作单元 | 文档 / 写作任务 / 开发任务 |\n| `{catalog-filename}` | 第一层文件名 | document-catalog / writing-catalog |\n| `{第二层名称}` | 三层结构第二层的显示名称 | 内容要求清单 / 结构要求清单 |\n| `{第三层名称}` | 三层结构第三层的显示名称 | 优秀范本库 / 经典范本库 |\n| `{第二层简称}` | 第二层在只读模式等处的简写（不含\"清单\"后缀） | 内容要求 / 结构要求 |\n| `{requirements-filename}` | 第二层文件名 | content-requirements / structure-requirements |\n| `{成品类型}` | 最终交付物 | 文档 / 章节 / 产品 |\n| `{方法论}` | 内容轴方法 | 清单法 / 样本法 |\n| `{合规/质量}` | 领域的质量约束 | 合规 / 风格一致性 / 功能测试 |\n| `{复杂度判定}` | Step 0 判定结果 | 中等+结构化 / 复杂+结构化 |\n| `{R1-R5描述}` | Step 1 领域校准各规则描述 | 见分析框架A-2 |\n| `{质量检查点}` | G类守护单元插入点 | 平台合规 / 安规认证 / 语法验证 |\n| `{组织原则}` | 域划分依据 | 价值链 / 生命周期 / 职能分工 |\n| `{域概览标题}` | 域概览章节的标题（含前缀） | 域概览 / 文档域概览 / 产出域概览 |\n\n---\n\n## 第一层：Catalog 文件模板\n\n```markdown\n# {清单名称}与依赖拓扑\n\n{领域名}按{组织原则}组织的{任务类型}清单，附{任务间关系}和UTOS元操作映射提示。\n\n**域间逻辑流**：{D1} → {D2} → ... → {Dn}\n\n---\n\n## {第一个域名}\n\n| ID | 任务类型 | 说明 | 依赖 | UTOS映射提示 |\n|----|---------|------|------|-------------|\n| {X}-01 | {任务名} | {一句话说明} | 无（入口） | S→C |\n| {X}-02 | {任务名} | {一句话说明} | {X}-01 | C→A |\n...\n\n## {第二个域名}\n\n...\n\n---\n\n## 依赖拓扑摘要\n\n以下为{任务间关系}的主要{依赖链路}，UTOS执行轴可据此自动编排管线：\n\n**{链路名1}**: {X-01} → {X-02} → ...\n**{链路名2}**: ...\n...\n\n更多组合由UTOS根据具体任务动态推导。\n```\n\n### Catalog 行格式模板\n\n每行遵循固定格式：\n\n```\n| {ID} | {任务名} | {说明} | {依赖(无则写\"无（入口）\")} | {S/C/A/O/I/G映射} |\n```\n\n---\n\n## 第二层：Requirements 文件模板\n\n> **边界说明**：以下五字段是内容轴**清单法的组件清单**，定义每个任务产出物的构成要素。它们**不替代** UTOS 能力单元Schema（单元ID/名称/元操作/输入/输出/依赖/AI自治度/组合接口等）。两者是不同层面的描述——requirements 管\"产出物由什么组成\"，UTOS Schema 管\"任务怎么执行\"。\n\n### 每个任务的槽位定义模板\n\n```markdown\n### {ID} {任务名}\n- **必选组件**: {核心要素1}、{核心要素2}、{核心要素3}...\n- **可选组件**: {可选要素1}、{可选要素2}...\n- **组装顺序**: {步骤1}→{步骤2}→{步骤3}→...\n- **{约束类型}约束**: [待补充] 或具体约束描述\n- **格式**: {输出格式}\n```\n\n### 五字段标准（每个任务的组件必须覆盖）\n\n| 字段 | 是否必填 | 说明 |\n|------|:-------:|------|\n| 必选组件 | ✅ | 产出的最小必要元素集合 |\n| 可选组件 | ❌ | 增强但不影响基本功能的元素 |\n| 组装顺序 | ✅ | 组件填充的逻辑顺序 |\n| 约束 | ⚠️ | 领域特定的质量/合规/风格限制 |\n| 格式 | ✅ | 输出物格式（Markdown/Word/Excel/代码等）|\n\n---\n\n## 第三层：Exemplars 文件模板\n\n### 结构说明\n\n第三层采用**清单主文件 + 子文件**结构：\n\n- `references/exemplars.md` — 范本清单主文件（按域分组的索引 + 公开标准索引 + 填充指南）\n- `references/exemplars/{ID}-{name}.md` — 具体范本文件（每个范本独立一个文件）\n\n主文件只做索引，具体范本内容存子文件。这样主文件不会因任务数多而膨胀，AI 也能按需加载单个范本。\n\n### 主文件模板\n\n```markdown\n# {优秀范本库名称}\n\n{领域名}的范本清单与索引。用于UTOS内容轴**样本法**。\n\nUTOS内容轴样本法执行流程：\n1. 获取样本（本文件索引指向的子文件或用户提供）\n2. 分析样本四维度：结构、风格、逻辑、格式\n3. 整理为「样本特征摘要」\n4. 模仿产出（保持结构框架和风格，替换内容）\n\n> **使用说明**：标注 `[待填充]` 的条目需用户补充范本后方可使用样本法。\n\n---\n\n## {第一个域名}\n\n| 任务ID | 任务类型 | 范本 | 状态 |\n|--------|---------|------|------|\n| {X}-01 | {任务名} | [待填充] {范本描述} | 空 |\n| {X}-02 | {任务名} | {公开标准名}（公开标准） | 可用 |\n...\n\n## {第二个域名}\n\n| 任务ID | 任务类型 | 范本 | 状态 |\n|--------|---------|------|------|\n...\n\n---\n\n## 公开标准范本索引（可选）\n\n> 适用于有行业公开标准的领域（如医药ICH/EMA标准、工程ISO标准等）。无公开标准的领域可省略此章节。\n\n以下为行业公开标准模板，无需用户脱敏即可直接作为样本法参考：\n\n| 标准 | 适用任务 | 来源 |\n|------|---------|------|\n| {标准名} | {任务ID} | {来源机构} |\n...\n\n---\n\n## 用户填充指南\n\n用户向本技能添加范本时：\n\n1. **脱敏**：移除所有敏感信息（产品名、个人信息、商业机密），用占位符替换\n2. **存放**：将范本文件放入 `references/exemplars/` 目录，按任务ID命名（如 `{X}-01-{task-name}.md`）\n3. **注册**：在本文件对应条目中更新范本路径和状态（空→可用）\n4. **特征摘要**：为每个范本撰写四维分析（结构、风格、逻辑、格式），存入同目录 `{ID}.summary.md` 文件\n```\n\n### 子文件模板\n\n每个具体范本独立存放在 `references/exemplars/` 目录下：\n\n```markdown\n### {任务ID} {范本名称}\n\n**对应任务**: {任务ID}\n\n**来源**: [来源说明]\n\n**适用场景**: [什么情况下参考此范本]\n\n**{范本正文标题}**:\n> （范本内容——对于代码类领域此处为可运行代码）\n\n**关键设计决策**:\n- **决策1**: [为什么这样设计]\n- ...\n\n**可复用要素**:\n- [哪些部分可以抽象为通用模式]\n```\n\n### 范本数量建议\n\n| 领域规模 | 最少范本数 | 推荐范围 |\n|---------|----------|---------|\n| 小型(<30任务) | 6 | 8-12 |\n| 中型(30-60任务) | 8 | 10-15 |\n| 大型(>60任务) | 10 | 15-20 |\n\n每个主要域至少应有1-2个范本。\n\nFile v1.0.3:references/utos-interface-checklist.md\n\n# UTOS接口校验清单\n\n生成的领域负载物技能必须通过以下21项逐条检查，确保与UTOS零冲突。每项标注 **PASS** / **FAIL** / **N/A**。\n\n---\n\n## A类：结构一致性（6项，全部必须PASS）\n\n| # | 检查项 | 检查方法 | 通过标准 |\n|---|--------|---------|---------|\n| A1 | 三层结构存在 | 检查references/目录下是否有3个文件 + exemplars/子目录 | 必须有：catalog + requirements + exemplars主文件 + exemplars/子目录 |\n| A2 | SKILL.md含依赖声明 | 检查SKILL.md是否含\"依赖声明\"章节 | 必须声明强依赖universal-task-os |\n| A3 | 加载检查流程完整 | 检查是否有4步流程(检测→安装→加载→降级) | 4步缺一不可 |\n| A4 | 降级模式定义 | 检查是否有只读模式的✅❌权限表 | 必须区分有UTOS和无UTOS两种模式 |\n| A5 | 域间逻辑流声明 | catalog文件头部是否有域间逻辑流描述 | 必须→连接各域 |\n| A6 | 依赖拓扑摘要 | catalog文件末尾是否有\"依赖拓扑摘要\"章节 | 必须有至少3条跨域管线链路 |\n\n## B类：任务Schema完整性（5项，全部必须PASS）\n\n| # | 检查项 | 检查方法 | 通过标准 |\n|---|--------|---------|---------|\n| B1 | 每个任务含5字段 | 随机抽查3-5个任务 | ID/名称/说明/依赖/UTOS映射提示 全部存在 |\n| B2 | 依赖格式正确 | 检查所有任务的\"依赖\"列 | 格式为：\"无（入口）\" 或 \"X-XX\"(有效ID) 或 \"X-XX, Y-YY\"(多依赖) |\n| B3 | UTOS映射提示有效 | 检查映射提示值 | 仅允许：S/C/A/O/I/G 及其组合(→/‖) + 可选的A/G后缀 |\n| B4 | 无孤立任务 | 检查每个非入口任务的前置依赖是否在catalog中存在 | 依赖ID必须指向已定义的任务 |\n| B5 | 入口任务标识正确 | 标注\"无（入口）\"的任务确实是起始点 | 入口任务数应≥1且≤总任务数的30% |\n\n## C类：结构要求槽位规范（4项，至少3项PASS）\n\n| # | 检查项 | 检查方法 | 通过标准 |\n|---|--------|---------|---------|\n| C1 | 必选组件存在 | 每个任务必须有\"必选组件\"字段 | 100%覆盖率 |\n| C2 | 组装顺序存在 | 每个任务必须有\"组装顺序\"字段 | ≥90%覆盖率（极简任务可省略） |\n| C3 | 约束字段存在 | 每个任务必须有约束相关字段 | 命名为\"合规约束\"/\"风格约束\"/\"质量约束\"/\"平台约束\"等均可 |\n| C4 | 格式字段存在 | 每个任务必须指定输出格式 | Markdown/Word/Excel/HTML/PDF/代码等 |\n\n## D类：UTOS接口章节（3项，全部必须PASS）\n\n| # | 检查项 | 检查方法 | 通过标准 |\n|---|--------|---------|---------|\n| D1 | \"与UTOS的接口\"章节 | SKILL.md中是否存在此章节 | 必须存在 |\n| D2 | Step 0-4覆盖 | 该章节是否覆盖Step 0到Step 4 | Step 0/1/2/3/4 全部有内容 |\n| D3 | Step 1领域校准具体化 | Step 1是否包含R1-R5规则的领域特定推导 | 不能照抄通用模板，必须有该领域的具体参数 |\n\n## E类：范本库规范（3项，至少2项PASS）\n\n| # | 检查项 | 检查方法 | 通过标准 |\n|---|--------|---------|---------|\n| E1 | 范本清单表存在 | exemplars.md中是否有按域分组的范本清单表格 | 必须有按任务ID索引的范本表 |\n| E2 | 范本子文件存在 | references/exemplars/目录下是否有.md文件 | 状态为\"可用\"的条目必须有对应子文件 |\n| E3 | 范本模板格式存在 | 是否提供了子文件的标准化模板格式 | 供后续填充的结构模板 |\n\n---\n\n## 校验执行流程\n\n```\n生成技能文件\n ↓\n┌─────────────┐\n│ A类检查(6项)│ ← 结构一致性\n│ 全部PASS? │\n└──────┬──────┘\n │ FAIL → 修正后重新检查\n │ PASS ↓\n┌─────────────┐\n│ B类检查(5项)│ ← 任务Schema\n│ 全部PASS? │\n└──────┬──────┘\n │ FAIL → 补充缺失字段\n │ PASS ↓\n┌─────────────┐\n│ C类检查(4项)│ ← 槽位规范\n│ ≥3 PASS? │\n└──────┬──────┘\n │ 不足 → 补充关键槽位\n │ OK ↓\n┌─────────────┐\n│ D类检查(3项)│ ← UTOS接口\n│ 全部PASS? │\n└──────┬──────┘\n │ FAIL → 重写接口章节\n │ PASS ↓\n┌─────────────┐\n│ E类检查(3项)│ ← 范本库\n│ ≥2 PASS? │\n└──────┬──────┘\n │ 不足 → 创建空范本框架\n │ OK ↓\n ✅ 校验通过，技能可用\n```\n\n## 常见FAIL原因与修正\n\n| FAIL项 | 常见原因 | 修正方法 |\n|--------|---------|---------|\n| A2/A3 | SKILL.md直接复制了其他技能但忘了改领域名 | 全局搜索替换旧领域名为新域名 |\n| B3 | UTOS映射写了中文而非S/C/A代码 | 统一为字母代号 |\n| B4 | 引用了不存在的依赖任务ID | 检查catalog中是否有该ID，或删除无效引用 |\n| D3 | Step 1照抄通用模板无领域特定内容 | 根据分析框架A-2的结果填充具体的R1-R5推导 |\n| C1/C2 | requirements文件是空的或只有标题 | 至少为每个域的代表性任务填写一个完整槽位 |\n| E2 | exemplars.md索引指向的子文件不存在 | 在references/exemplars/下创建对应文件，或在主文件中将状态改为\"空\" |\n\n## 自动化校验提示\n\n此校验清单可以转化为简单的脚本自动化：\n\n```python\n# 伪代码 - 校验逻辑示意\ndef validate_skill(skill_path):\n results = []\n # A类: 文件存在性 + 关键章节检测（含exemplars/子目录）\n results.append(check_A_files_exist(skill_path))\n results.append(check_A_dependency_section(skill_path))\n results.append(check_A_domain_flow(skill_path))\n # B类: Catalog表格解析 + Schema验证\n results.append(check_B_task_schema(skill_path))\n results.append(check_B_dependency_validity(skill_path))\n # C-E类: Requirements和Exemplars抽查\n results.append(check_C_requirements_coverage(skill_path))\n results.append(check_D_utos_interface(skill_path))\n results.append(check_E_exemplar_subfiles(skill_path))\n return generate_report(results)\n```\n\nFile v1.0.3:skill-card.md\n\n## Description:
\nDomain Payload Generator is a Chinese-language meta-skill that creates UTOS-compatible domain payload skill scaffolds from a requested knowledge domain.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[wangjiaocheng](https://clawhub.ai/user/wangjiaocheng)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nDevelopers and skill authors use this skill to generate UTOS-compatible domain knowledge reference skills, including domain analysis, scaffolded Markdown files, requirements, exemplars, and interface checks.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: The skill can guide an agent to create or modify a skill directory.
\nMitigation: Confirm the requested output path is an intended workspace location and review generated files before installing or publishing them.
\nRisk: Generated domain payload skills may contain incomplete domain analysis, placeholders, or unreviewed exemplars.
\nMitigation: Run the included 21-item UTOS interface checklist and complete catalog, requirements, and exemplar review before deployment.
\n\n\n## Reference(s):
\n- [Domain Payload Generator on ClawHub](https://clawhub.ai/wangjiaocheng/domain-payload-generator)
\n- [Domain Analysis Framework](artifact/references/domain-analysis-framework.md)
\n- [Generator Workflow](artifact/references/generator-workflow.md)
\n- [Structure Template](artifact/references/structure-template.md)
\n- [UTOS Interface Checklist](artifact/references/utos-interface-checklist.md)
\n\n\n## Skill Output:
\n**Output Type(s):** [text, markdown, code, configuration, guidance]
\n**Output Format:** [Markdown skill files and reference documents in a directory scaffold]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [Produces a UTOS-compatible SKILL.md plus catalog, requirements, exemplars, and checklist-guided review content.]
\n\n## Skill Version(s):
\n1.0.3 (source: ClawHub release evidence)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.0.2: 7 files, 20549 bytes\n\nFiles: references/domain-analysis-framework.md (8485b), references/generator-workflow.md (8573b), references/structure-template.md (10278b), references/utos-interface-checklist.md (6267b), skill-card.md (2105b), SKILL.md (7906b), _meta.json (143b)\n\nFile v1.0.2:SKILL.md\n\n---\nname: domain-payload-generator\nauthor: 王教成 Wang Jiaocheng (波动几何)\ndescription: 领域负载物技能制作器（Meta-Skill）——Universal Task OS的技能工厂。独立创建与UTOS完全兼容的领域负载物技能，不依赖任何被创建的目标技能。提供领域分析框架（R1-R5分类定位/价值链拆解/任务枚举/UTOS映射推导）、三层结构模板（SKILL.md+catalog+requirements+exemplars）、UTOS接口校验清单（20项逐条检查零冲突保障）、标准化生成工作流。复杂领域建议先用 Workflow Refactor 重构工作流再生成。触发词：领域负载物、技能制作、技能生成、知识参考库、新领域技能、domain payload、skill generator、meta-skill。\n---\n\n# 领域负载物技能制作器\n\n## 定位\n\n本技能是一个 **元技能（Meta-Skill）**——它的产出不是领域知识本身，而是**领域负载物技能**。当用户说\"帮我做一个XX领域的知识参考库\"时，本技能负责从零创建完整的、与UTOS完全兼容的领域负载物技能。\n\n| 本技能提供 | 消费方式 |\n|-----------|---------|\n| 领域分析框架 | 分析新领域并确定域划分和任务类型 |\n| 三层结构模板 | 自动生成SKILL.md + references/三层文件 |\n| UTOS接口校验清单 | 确保生成的技能与UTOS无冲突 |\n| 生成工作流 | 从用户输入到完整技能的标准化流程 |\n\n## 核心能力\n\n```\n用户输入：\"帮我做一个XX领域的知识参考库\"\n ↓\n ┌─────────────────────┐\n │ Step 1: 领域分析 │ ← 用领域分析框架拆解新领域\n │ 确定域数/任务数 │\n ├─────────────────────┤\n │ Step 2: 结构生成 │ ← 用三层结构模板填充内容\n │ SKILL.md │\n │ + catalog │\n │ + requirements │\n │ + exemplars │\n ├─────────────────────┤\n │ Step 3: UTOS校验 │ ← 用接口校验清单检查一致性\n │ 无冲突 → 输出 │\n │ 有冲突 → 修正 │\n └─────────────────────┘\n ↓\n 完整的XX领域知识参考库技能（可直接使用）\n```\n\n## 与其他技能的关系\n\n### 独立性保证\n\n> **关键设计约束**：本技能**不依赖任何被它创建的领域技能**。它在创建时是自包含的，仅依赖：\n> - Universal Task OS（用于理解目标接口）\n> - Workflow Refactor（复杂领域先重构工作流，再生成技能）\n> - 自身的references文件（框架+模板+校验清单）\n\n这意味着：\n- ✅ 创建任何领域技能时，不需要该领域技能已存在\n- ✅ 本技能可以独立运行，输出产物后才被其他流程消费\n\n### 职责分工\n\n| 技能 | 管什么 | 不管什么 |\n|------|--------|---------|\n| **Workflow Refactor** | 流程结构——哪些环节保留、消除、校准 | 领域知识内容（清单/样本） |\n| **Domain Payload Generator** | 领域知识内容——catalog(清单)、requirements(要求)、exemplars(范本) | 流程结构 |\n| **Universal Task OS** | 三轴执行框架——执行轴编排、内容轴消费清单/样本、创新轴突破 | 具体领域内容 |\n\n### 价值链\n\n```\n传统工作流 ──[Workflow Refactor]──→ 重构后IPO基元链\n │\n ▼\n [Domain Payload Generator]\n │\n ▼\n 领域负载物（简化版）\n │\n ▼\n [Universal Task OS] 持续执行\n```\n\n转化→创建→执行，是一条价值链，不是替代关系。\n\n### 三条路径对比\n\n| 路径 | 清单/样本来源 | 优势 | 劣势 |\n|------|-------------|------|------|\n| **Workflow Refactor 单独用** | 无，用户临时提供 | 流程极简 | 内容质量靠用户自身积累 |\n| **重构 + Domain Payload + UTOS** | 领域负载物结构化提供 | 流程+内容双保险，系统化 | 首次生成有成本 |\n| **重构 + UTOS（无领域负载物）** | 用户手动输入到 IPO 的 I | 灵活 | 每次都要手动准备，覆盖度不稳定 |\n\n### 重构如何简化负载物\n\n领域负载物的复杂度 = 领域本身的复杂度 + 传统工作流遗留的冗余任务类型。\n\n| 场景 | catalog 任务数 | requirements 复杂度 | exemplars 数量 |\n|------|---------------|-------------------|---------------|\n| 未重构直接生成 | 包含传递/协调/格式环节对应的任务类型 | 大量\"人的局限补偿\"相关要求 | 范本里嵌套冗余中间产物 |\n| 先重构再生成 | 只保留✅核心+🔶校准+⚡关键校验对应的类型 | 要求聚焦事情本身 | 范本干净，无冗余传递物 |\n\n先重构再生成，负载物体积和认知负荷都大幅降低。\n\n### 三层价值属性\n\n| 技能 | 价值类型 | 使用频率 |\n|------|---------|---------|\n| **Workflow Refactor** | 转化价值——解决\"从旧到新\"的转化问题 | 低频、脉冲式 |\n| **Domain Payload Generator** | 创建价值——解决\"从无到有\"的创建问题 | 中频、按需 |\n| **Universal Task OS** | 运行时价值——解决\"执行任务\"的运行问题 | 高频、持续 |\n\nWorkflow Refactor 的价值不会归零（新领域不断出现、已重构领域会过时需要重新审视、AI能力跃升时重构本身可以被重构），但会随成熟领域完成重构而衰减为低频触发。\n\n## 与UTOS的关系\n\n本技能生成的所有产物都遵循以下UTOS兼容性契约：\n\n| 兼容性维度 | 要求 |\n|-----------|------|\n| **三层结构一致** | 必须为：第一层(清单+拓扑) + 第二层(要求) + 第三层(范本) |\n| **依赖声明格式** | 必须含强依赖UTOS声明 + 加载检查流程 + 降级模式 |\n| **元操作映射** | 每个任务必须标注S/C/A/O/I/G映射提示 |\n| **五字段Schema** | 每个任务组件必选：ID/名称/说明/依赖/UTOS映射 |\n| **域间逻辑流** | 域间必须有明确的价值链逻辑顺序 |\n| **依赖拓扑摘要** | 必须有跨域管线链路描述 |\n| **Step 0-4接口** | SKILL.md必须含\"与UTOS的接口\"章节（Step 0~4各条目） |\n\n## 使用规则\n\n1. **生成前置判断**：复杂领域建议先用 Workflow Refactor 重构工作流，再基于重构结果生成技能——这样产出的技能更精准，不会把人的局限补偿层编码进领域知识。简单或标准化领域可直接生成，跳过重构。\n2. **触发条件**：用户请求创建新的领域知识参考库/领域负载物技能时激活\n3. **首次加载**：读取 `references/domain-analysis-framework.md` 获取领域分析方法\n4. **按需深入**：确认领域后，读取 `references/structure-template.md` 获取三层结构模板；读取 `references/utos-interface-checklist.md` 获取校验规则\n5. **执行生成**：按 `references/generator-workflow.md` 的步骤逐一执行\n6. **输出交付**：将生成的技能写入指定目录\n\n## 参考文件索引\n\n| 文件 | 用途 |\n|------|------|\n| `references/domain-analysis-framework.md` | 新领域分析方法论——如何从一个领域名推导出域划分、任务类型、依赖关系 |\n| `references/structure-template.md` | 三层结构模板——SKILL.md/catalog/requirements/exemplars的标准模板及变量替换规则 |\n| `references/utos-interface-checklist.md` | UTOS兼容性校验清单——20项逐条检查，确保生成的技能与UTOS零冲突 |\n| `references/generator-workflow.md` | 完整生成工作流——从用户输入到技能产出的每一步操作指南 |\n\nFile v1.0.2:_meta.json\n\n{\n \"ownerId\": \"kn75v65h3zezxajen2xf64b2v1845d98\",\n \"slug\": \"domain-payload-generator\",\n \"version\": \"1.0.2\",\n \"publishedAt\": 1779878317300\n}\n\nFile v1.0.2:references/domain-analysis-framework.md\n\n# 领域分析框架\n\n当用户提出\"帮我做一个XX领域知识参考库\"时，用此框架从零分析新领域并推导出完整的域划分和任务类型。\n\n---\n\n## Step A：领域定义\n\n### A-1 领域名称规范化\n\n| 输入 | 处理 | 输出 |\n|------|------|------|\n| 用户原始描述 | 提取核心领域关键词 + 确定边界 | 标准化的领域英文名 + 中文名 |\n\n**示例映射**：\n\n| 用户输入 | 规范化领域名 | 域代号前缀 |\n|---------|------------|-----------|\n| \"写小说的\" | Novel Writing (小说创作) | N |\n| \"做智能硬件的\" | Smart Hardware (智能硬件) | H |\n| \"写HTML/Python/Shell/SQL单文件工具的\" | Single-File Output (单文件产出) | S |\n| \"做会计代账的\" | Bookkeeping Agency (代理记账) | B |\n| \"教人减肥健身的\" | Metabolic Healing (代谢慢病) | M |\n\n### A-2 领域分类定位\n\n将目标领域在以下坐标系中定位，决定后续生成的参数倾向：\n\n| 维度 | 低 | 高 | 影响什么 |\n|------|----------|----------|---------|\n| **R1 信息密度(S/C权重)** | 操作类/手工类 → S轻 | 数据类/研究类 → S重C深 | 感知和认知单元占比 |\n| **R2 创造性(A权重)** | 流程类/合规类 → A标准 | 艺术类/研发类 → A极高 | 内容轴创新轴激活频率 |\n| **R3 交互性(I权重)** | 独立产出类 → I少 | 服务类/协作类 → I多 | 交互单元数量 |\n| **R4 规范性(G权重)** | 创作类/设计类 → G偏松 | 法规类/工程类 → G偏严 | 守护单元密度、合规约束数量 |\n| **R5 迭代性(循环)** | 一次性交付→循环少 | 持续运营/连载→循环多 | 管线中↻模式的使用 |\n\n**快速判定表**：\n\n| 典型领域 | R1信息密度 | R2创造 | R3交互 | R4规范 | R5迭代 | 推导结果 |\n|---------|-----------|--------|--------|--------|--------|---------|\n| 医药文档 | 高 | 中 | 高 | 高 | 中 | S重C深I高G高A标准 |\n| 网络小说 | 中 | 极高 | 中 | 低 | 极高 | A极高G松循环多 |\n| 智能硬件 | 高 | 高 | 高 | 高 | 高 | 全维度高+G极高 |\n| 单文件代码 | 中 | 中 | 低 | 高 | 中 | G高A标准结构清晰 |\n| 代账记账 | 高 | 低 | 中 | 高 | 周期性 | G高A低C深O强 |\n| 教学培训 | 中 | 中 | 高 | 中 | 低 | I高A中G中 |\n\n### A-3 R评分到UTOS参数映射\n\n将A-2的R1-R5评分映射为具体的UTOS执行参数：\n\n| R评分 | 元操作权重调整 | AI自治度偏好 | 守护(G)密度 | 管线模式倾向 |\n|-------|--------------|-------------|------------|-------------|\n| **R1信息密度=高** | S↑C↑（感知和认知占比高） | 🟨半自动偏多（需人确认数据源） | 数据准确性校验 | P3并行汇聚（多源数据） |\n| **R1信息密度=低** | S↓C↓（轻感知轻认知） | ⬛全自动偏多 | 低 | P1基础闭环 |\n| **R2创造性=高** | A↑（行动/产出占比高） | ⬜辅助偏多（人定方向） | 风格一致性校验 | P7发散收敛 |\n| **R2创造性=低** | A标准 | ⬛全自动偏多 | 低 | P1基础闭环 |\n| **R3交互性=高** | I↑（交互占比高） | ⬜辅助偏多（人对外沟通） | 沟通合规校验 | P5交互驱动 |\n| **R3交互性=低** | I↓ | ⬛全自动偏多 | 低 | P1基础闭环 |\n| **R4规范性=高** | G↑O↑（守护和组织占比高） | 🟨/⬜（合规节点必须人工） | 高密度，每阶段嵌入G | P6全守护 |\n| **R4规范性=低** | G↓ | ⬛全自动偏多 | 低 | P1基础闭环 |\n| **R5迭代性=高** | 循环↑（短链高频） | 🟨半自动（每轮需确认） | 每轮迭代末尾G | P2迭代精炼 |\n| **R5迭代性=低** | 循环↓（长链低频） | ⬛/🟨 | 终末校验 | P1基础闭环 |\n\n**使用方式**：对每个R维度取评分后，叠加各维度的参数调整。多个维度同时为高时，参数叠加（如R1高+R4高 = S↑C↑G↑O↑ + 高密度守护）。\n\n---\n\n## Step B：域划分（Domain Partitioning）\n\n### B-1 价值链拆解法\n\n**核心方法**：沿领域的**价值链或生命周期**拆分域。每个域代表价值链上的一个阶段。\n\n**通用模板——按生命周期型**（适用于产品/项目/创作类领域）：\n\n```\n阶段0：输入/素材阶段 → 需求/调研/灵感/原料\n阶段1：规划/架构阶段 → 设计/架构/大纲/方案\n阶段2：执行/生产阶段 → 开发/写作/制造/编码（可能有多条并行线）\n阶段3：验证/测试阶段 → 测试/审查/校验/评审\n阶段4：交付/发布阶段 → 发布/部署/上线/出版\n阶段5：运营/维护阶段 → 运营/迭代/客服/优化\n```\n\n**通用模板——按职能分工型**（适用于组织/流程类领域）：\n\n```\n职能1：前端/面向用户 → 销售/服务/展示/内容\n职能2：中台/核心能力 → 产品/技术/专业服务\n职能3：后台/支撑保障 → 合规/财务/人力/IT\n职能4：横向/协同管理 → 项目/质量/战略/风险\n```\n\n### B-2 域数量确定原则\n\n| 因素 | 少域(5-7) | 中等域(8-10) | 多域(11+) |\n|------|----------|-------------|----------|\n| 领域复杂度 | 低 | 中 | 高 |\n| 任务同质化程度 | 高（任务类型相似） | 中 | 低（各域差异大） |\n| 依赖链长度 | 短(<3层) | 中(3-5层) | 长(>5层) |\n| 参考案例 | — | 单文件产出、网文、硬件 | 医药 |\n\n**经验公式**：域数 = ⌈ln(预估总任务数) × 2⌉，取值范围[5, 15]\n\n### B-3 域命名规范\n\n每个域必须包含：\n- **域代号**：单个大写字母 + 数字编号（如 N1, H3, S5）\n- **域名称**：2-6个中文词，准确描述域的范围\n- **对标说明**（可选）：如果是从已有技能迁移，标注对应关系\n\n**命名禁忌**：\n- ❌ 域名之间有包含关系（如\"开发\"和\"软件开发\"）\n- ❌ 域名过于抽象（如\"管理\"、\"支持\"）\n- ✅ 域名具体且互斥（如\"原型验证\" vs \"量产制造\"，不重叠）\n\n---\n\n## Step C：任务类型推导\n\n### C-1 任务枚举法\n\n对每个域，使用以下问题清单枚举任务类型：\n\n```\n1. 这个域要\"产生\"什么？ → 产出的文档/制品/代码是什么？\n2. 产出之前需要\"准备\"什么？ → 依赖哪些前置输入？\n3. 产出之后需要\"检查\"什么？ → 有哪些质量/合规要求？\n4. 这个域能\"帮助\"其他域做什么？ → 输出被谁消费？\n5. 这个域内是否有\"子流程\"？ → 是否需要进一步拆分为多个任务？\n```\n\n### C-2 任务ID命名规范\n\n```\n{域代号}-{两位序号} 如: N1-01, H4-05, S7-03\n```\n\n### C-3 每个任务的必填字段\n\n| 字段 | 说明 | 示例 |\n|------|------|------|\n| ID | 任务ID | D5-03 |\n| 名称 | 任务类型的简短名称 | DA故事线文档 |\n| 说明 | 一句话描述这个任务产出什么 | 页序、每页核心信息、视觉建议 |\n| 依赖 | 前置任务ID列表，无依赖写\"无（入口）\" | D5-01 |\n| UTOS映射提示 | S/C/A/O/I/G + 组合符号 | C→A（先认知后行动） |\n\n### C-4 UTOS映射提示的推导规则\n\n| 任务特征 | 映射提示 |\n|---------|---------|\n| 收集信息/调研/扫描 | S (感知) |\n| 分析/评估/推理/决策 | C (认知) |\n| 产出/创建/编写/制作 | A (行动) |\n| 存储/归档/索引/分类 | O (组织) |\n| 协调/沟通/确认 | I (交互) |\n| 校验/审核/合规/约束 | G (守护) |\n| 先收集再分析 | S→C |\n| 先分析再产出 | C→A |\n| 分析+产出+需审核 | C→A→G |\n| 采集后直接产出 | S→A |\n\n---\n\n## Step D：依赖拓扑构建\n\n### D-1 域间逻辑流\n\n域间按价值链顺序排列，形成主线流：\n\n```\nD1 → D2 → D3 → ... → Dn\n```\n\n同时标注**并行分支**和**反馈回路**。\n\n### D-2 跨域管线链路\n\n识别3-8条关键跨域管线，每条格式为：\n\n```\n[链路名]: 任务A → 任务B → 任务C → ...\n [对应已有技能的某条链路（如为迁移）]\n```\n\n**管线发现启发式**：\n1. **主链路**：从入口到最终交付的最短路径\n2. **数据链路**：数据/信息的流转路径\n3. **质量链路**：从生产到检验到修正的闭环\n4. **资源链路**：物料/供应链的依赖路径\n5. **加速链路**：MVP/快速版本的特殊路径\n\n### D-3 依赖拓扑摘要格式\n\n```markdown\n## 依赖拓扑摘要\n\n**[链路名1]**: X-01 → X-02 → X-03 → ...\n**[链路名2]**: Y-01 → Y-02 ‖ Y-03 → Y-04 （并行）\n**[闭环链]**: Z-01 → Z-02 → Z-03 → [回到Z-01]\n\n更多组合由UTOS根据具体任务动态推导。\n```\n\nFile v1.0.2:references/generator-workflow.md\n\n# 生成工作流\n\n从用户输入\"帮我做一个XX领域知识参考库\"到完整技能产出的标准化操作流程。\n\n---\n\n## 总览\n\n```\n输入: 用户描述的领域名称\n │\n ├─ Step 1: 领域分析（30-40%时间）\n │ ├─ 1A: 领域定义与分类定位\n │ ├─ 1B: 域划分\n │ └─ 1C: 任务类型枚举 + 依赖推导\n │\n ├─ Step 2: 文件生成（40-50%时间）\n │ ├─ 2A: SKILL.md（用模板填充）\n │ ├─ 2B: references/catalog.md（任务清单+拓扑）\n │ ├─ 2C: references/requirements.md（槽位定义）\n │ └─ 2D: references/exemplars.md（范本框架）\n │\n ├─ Step 3: UTOS校验（10-15%时间）\n │ └─ 20项逐条检查 → 修正FAIL项\n │\n └─ 输出: 完整可用的领域负载物技能目录\n```\n\n---\n\n## Step 1：领域分析\n\n### 1A：领域定义与分类定位\n\n**操作**：\n1. 请用户描述目标领域的核心工作内容\n2. 使用 `domain-analysis-framework.md` 的 **Step A** 进行规范化\n3. 输出：领域英文名、域名代号前缀、R1-R5定位结果\n\n**输出物**：\n\n```\n领域名: {English Name}\n代号前缀: {X}\nR1(信息密度): 高/中/低 → S/C权重: ...\nR2(创造性): 高/中/低 → A权重: ...\nR3(交互性): ... → I权重: ...\nR4(规范性): ... → G权重: ...\nR5(迭代性): ... → 循环模式使用频率: ...\n```\n\n### 1B：域划分\n\n**操作**：\n1. 根据领域特征选择拆解方法（价值链型 vs 职能分工型 vs 混合型）\n2. 使用 `domain-analysis-framework.md` 的 **Step B** 进行域划分\n3. 确定域数量和每个域的范围边界\n\n**输出物**：\n\n```\n共 N 个域:\n{X}1 {域名1} — {一句话说明范围}\n{X}2 {域名2}\n...\n{X}N {域名N}\n\n域间逻辑流: {X}1 → {X}2 → ... → {X}N\n```\n\n### 1C：任务类型枚举与依赖推导\n\n**操作**：\n1. 对每个域，使用 **Step C** 的问题清单枚举任务\n2. 为每个任务分配ID（{X}{域号}-{序号}）和UTOS映射提示\n3. 使用 **Step D** 构建依赖拓扑\n\n**输出物**：\n\n```\n总任务数: M 种\n各域任务分布: {X}1(n1种) / {X}2(n2种) / ...\n\n关键跨域管线:\n- {管线名1}: {ID}→{ID}→{ID}\n- {管线名2}: ...\n（共 K 条）\n```\n\n---\n\n## Step 2：文件生成\n\n### 2A：SKILL.md\n\n**操作**：\n1. 打开 `structure-template.md` 中的 SKILL.md 模板\n2. 逐一替换所有 `{变量}` 为 Step 1 的分析结果\n3. 特别注意以下字段必须**定制化**而非照搬模板：\n - \"领域特有维度\"章节 —— 必须是该领域独有的\n - \"与UTOS的接口\" Step 1 领域校准 —— 必须有具体参数\n - \"域概览\"表格 —— 必须是实际划分的结果\n\n### 2B：Catalog文件\n\n**操作**：\n1. 按1C的枚举结果，为每个域创建表格\n2. 每个任务一行，格式严格遵循模板\n3. 文件末尾追加\"依赖拓扑摘要\"章节\n4. 至少列出3条跨域管线链路\n\n**质量检查**：\n- [ ] 所有任务ID格式正确\n- [ ] 所有依赖引用有效\n- [ ] UTOS映射提示使用了正确代号\n- [ ] 域间逻辑流声明清晰\n\n### 2C：Requirements文件\n\n**操作**：\n1. 对每个任务创建槽位定义\n2. **必填**：必选组件 + 组装顺序 + 格式\n3. **推荐填写**：可选组件 + 约束字段\n4. 当任务数>30时，可将部分域的要求迁移至 `references/structure-requirements-{domain}.md` 子文件\n\n**槽位编写原则**：\n- 必选组件回答\"这个产出物的最小必要元素是什么？\"\n- 组装顺序回答\"按什么逻辑顺序填充这些元素？\"\n- 约束回答\"这个领域对这个产出的特殊限制是什么？\"\n\n### 2D：Exemplars文件\n\n**操作**：\n1. 创建范本清单主文件（按域分组，每个任务一行，用任务ID索引）\n2. 创建范本标准格式模板（子文件模板）\n3. 如果有现成可用范本，存入 `references/exemplars/` 子目录并在主文件注册\n4. 否则创建 `[待填充]` 占位符框架\n\n**范本策略选择**：\n\n| 领域类型 | 范本策略 | 说明 |\n|---------|---------|------|\n| 代码产出类 | 范本=可运行代码 | 如单文件技能，嵌入完整.html/.py/.sh/.sql |\n| 文档产出类 | 范本=结构化文档模板 | 如医药/代账，嵌入脱敏范例 |\n| 创作产出类 | 范本=技法标注片段 | 如网文，嵌入经典片段+拆解 |\n| 流程产出类 | 范本=流程示例 | 如硬件，嵌入脱敏项目案例 |\n\n---\n\n## Step 3：UTOS校验\n\n### 执行校验\n\n1. 打开 `utos-interface-checklist.md`\n2. 逐项执行 A→B→C→D→E 五类检查\n3. 记录每项结果（PASS/FAIL/N/A）\n\n### 处理FAIL项\n\n| FAIL类别 | 处理策略 |\n|---------|---------|\n| A类(结构) | 通常是因为模板复制遗漏——全局搜索替换修正 |\n| B类(Schema) | 缺失字段或无效值——补充/修正 |\n| C类(槽位) | 覆盖率不足——至少为核心域补全 |\n| D类(接口) | 照搬无定制——重写该领域特定内容 |\n| E类(范本) | 未创建——建立空框架 |\n\n### 校验通过标志\n\n当满足以下条件时，校验通过：\n- A类: 6/6 PASS\n- B类: 5/5 PASS\n- C类: ≥3/4 PASS\n- D类: 3/3 PASS\n- E类: ≥2/3 PASS\n\n### 内容质量评估（结构校验通过后）\n\n结构校验只验证\"有没有\"，以下维度评估\"好不好\"：\n\n| 维度 | 评估方法 | 合格标准 |\n|------|---------|---------|\n| **任务覆盖度** | 核对领域核心工作流是否都被catalog中的任务覆盖 | 核心工作流无遗漏，可接受少量边缘任务缺失 |\n| **域间边界清晰度** | 检查各域的任务是否有重叠或归属模糊 | 无同一任务出现在两个域中，域间边界互斥 |\n| **依赖拓扑连通性** | 从入口任务出发，能否沿依赖链到达所有非入口任务 | 无孤立子图，无循环依赖 |\n| **要求可操作性** | requirements中的必选组件和组装顺序是否具体到可直接执行 | 不出现\"待定\"\"其他\"等模糊项 |\n| **范本可用性** | 状态为\"可用\"的范本是否确实可作为样本法参考 | 范本内容完整，四维特征摘要存在 |\n\n---\n\n## Step 4：输出与交付\n\n### 目录结构\n\n生成的技能应具有以下目录结构：\n\n```\n{skill-name}/\n├── SKILL.md # 技能定义\n└── references/\n ├── {catalog-filename}.md # 第一层：清单+拓扑\n ├── {requirements-filename}.md # 第二层：槽位定义\n ├── exemplars.md # 第三层：范本清单主文件\n └── exemplars/ # 第三层：具体范本子文件\n ├── {X}-01-{task-name}.md\n ├── {X}-01-{task-name}.summary.md\n └── ...\n```\n\n### 交付检查\n\n在交付给用户前，最终确认：\n\n- [ ] 所有文件存在且非空（SKILL.md + references/ 下的 catalog、requirements、exemplars 主文件）\n- [ ] SKILL.md可在WorkBuddy中被识别和加载\n- [ ] references/下的文件路径在SKILL.md中引用正确\n- [ ] 无遗留的 `{变量}` 占位符\n- [ ] 通过UTOS接口20项校验\n\n### 后续维护与迭代\n\n**首次交付后**：\n1. 范本库(exemplars.md)中的`[待填充]`占位符需要后续补充真实范本才能发挥样本法的完整能力\n2. 结构要求(requirements.md)中的`[待补充]`约束字段需要根据实际需求定义\n3. 技能生成后可通过实际使用持续迭代完善\n\n**领域演进时的增量更新**：\n1. 重新跑 `domain-analysis-framework.md` 的 Step A-B，确认域划分是否需要调整\n2. 对比新旧 catalog 的 diff：哪些任务新增、删除、合并、拆分\n3. 仅更新变化的域和任务，不全量重建——保持已有范本和要求不丢失\n4. 更新后重新跑 UTOS 接口校验（20项）\n5. 版本记录：在 SKILL.md 末尾记录变更摘要\n\n**范本扩充流程**：\n1. 从实际使用中收集高质量产出作为候选范本\n2. 脱敏后存入 `references/exemplars/` 目录\n3. 在 exemplars.md 主文件中更新状态（空→可用）\n4. 为每个新范本撰写四维特征摘要（结构/风格/逻辑/格式）\n\n---\n\n## 快速生成速查卡\n\n对于熟练用户，以下是快速生成的心智模型：\n\n```\n听到新领域 → \n ① 它的价值链是什么？（拆成5-12个域）→ \n ② 每个域要产出什么？（列成3-8个任务/域）→ \n ③ 任务间谁先谁后？（画依赖箭头）→ \n ④ 每个任务的\"零件清单\"是什么？（写必选组件+顺序）→ \n ⑤ 有没有好的例子可以放进去？（收集或标记待填充）→ \n ⑥ 和UTOS对得上吗？（跑20项校验清单）\n```\n\nFile v1.0.2:references/structure-template.md\n\n# 三层结构模板\n\n本文件定义了领域负载物技能的标准三层结构模板。生成新技能时，将 `{变量}` 替换为实际内容。\n\n---\n\n## SKILL.md 模板\n\n```markdown\n# {技能中文名}知识参考库\n\n## 定位\n\n本技能是 **Universal Task OS 的领域负载物仓库**，不包含任何执行框架。只提供{领域名}的\"是什么\"和\"长什么样\"——执行全部委托UTOS。\n\n| 本技能提供 | UTOS消费方式 |\n|-----------|-------------|\n| {领域名}任务清单+依赖拓扑 | 内容轴·清单法的任务目录 + 执行轴·管线编排的依赖输入 |\n| {任务类型}要求 | 内容轴·清单法的组件清单 |\n| 优秀范本（待填充） | 内容轴·样本法的样本 |\n\n## 三层结构\n\n```\n第一层：{清单名称} + 依赖拓扑 → references/{catalog-filename}.md\n第二层：{第二层名称} → references/{requirements-filename}.md\n第三层：{第三层名称} → references/exemplars.md\n```\n\n## 依赖声明\n\n本技能**强依赖** Universal Task OS (universal-task-os)。没有UTOS，本技能只有参考查阅能力，无法执行任何{任务类型}任务。\n\n**加载检查流程**（每次激活时执行）：\n\n1. 检测 `universal-task-os` 技能是否已安装\n2. **未安装** → 自动安装 `universal-task-os` 技能\n3. **安装成功** → 同时加载UTOS，按本技能\"使用规则\"执行\n4. **安装失败** → 降级为**只读参考模式**：\n - ✅ 允许：查阅{清单名称}、{第二层简称}、范本索引\n - ❌ 拒绝：任何涉及{任务类型}产出、管线编排、内容生成的任务，并提示\"需先安装 Universal Task OS\"\n\n**任务模式判定**：\n\n| 任务类型 | 无UTOS | 有UTOS |\n|---------|--------|--------|\n| 查阅{清单名称}/要求/范本 | ✅ 只读参考 | ✅ 完整 |\n| 按{方法论}产出{成品类型} | ❌ 拒绝 | ✅ UTOS编排执行 |\n| 依赖拓扑推导{管线名称} | ❌ 拒绝 | ✅ UTOS执行轴 |\n| {合规/质量}检查点插入 | ❌ 拒绝 | ✅ UTOS守护单元 |\n\n## 使用规则\n\n1. **依赖检查**：激活时按上述流程检测并安装UTOS\n2. **首次加载**：读取 `references/{catalog-filename}.md`，获取域分类、依赖拓扑、UTOS元操作映射提示\n3. **按需深入**：确认目标{任务}类型后，读取 `references/{requirements-filename}.md` 获取组件清单；如需样本法，读取 `references/exemplars.md` 获取范本\n4. **委托UTOS**：将{清单名称}作为清单法输入、范本作为样本法输入、依赖拓扑作为管线编排输入，交给UTOS执行轴+内容轴处理\n5. **{用户填充说明}**\n\n## 与UTOS的接口\n\n当UTOS处理{领域名}领域任务时：\n\n- **Step 0 三轴判定**：{领域}任务通常为{复杂度判定}+{内容类型判定} → {激活的轴}\n- **Step 1 领域校准**：{领域}的R1(信息密度)={描述}+R2(创造性)={描述}+R3(交互性)={描述}+R4(规范性)={描述}+R5(迭代性)={描述} → {权重推导结论}\n- **Step 2 内容轴**：清单法用本技能的{requirements-filename}；样本法用本技能的exemplars\n- **Step 3 执行轴**：管线编排基于本技能的依赖拓扑自动推导元操作序列\n- **Step 4 交付**：G类守护单元自动插入{质量检查点类型}\n\n## {领域特有维度标题}\n\n{特有维度的表格或列表说明}\n\n## {域概览标题}\n\n按{组织原则}组织，共{域数}域{总任务数}种{任务类型}：\n\n| 域 | 任务数 | 典型任务 |\n|----|--------|---------|\n{域概览表格行}\n\n完整清单见 `references/{catalog-filename}.md`。\n```\n\n### SKILL.md 变量替换表\n\n| 变量 | 说明 | 示例值 |\n|------|------|--------|\n| `{技能中文名}` | 技能的中文名称 | 医药行业文档 / 网络小说创作 |\n| `{领域名}` | 领域的简称 | 医药 / 网络小说 / 智能硬件 |\n| `{任务类型}` | 领域中的工作单元 | 文档 / 写作任务 / 开发任务 |\n| `{catalog-filename}` | 第一层文件名 | document-catalog / writing-catalog |\n| `{第二层名称}` | 三层结构第二层的显示名称 | 内容要求清单 / 结构要求清单 |\n| `{第三层名称}` | 三层结构第三层的显示名称 | 优秀范本库 / 经典范本库 |\n| `{第二层简称}` | 第二层在只读模式等处的简写（不含\"清单\"后缀） | 内容要求 / 结构要求 |\n| `{requirements-filename}` | 第二层文件名 | content-requirements / structure-requirements |\n| `{成品类型}` | 最终交付物 | 文档 / 章节 / 产品 |\n| `{方法论}` | 内容轴方法 | 清单法 / 样本法 |\n| `{合规/质量}` | 领域的质量约束 | 合规 / 风格一致性 / 功能测试 |\n| `{复杂度判定}` | Step 0 判定结果 | 中等+结构化 / 复杂+结构化 |\n| `{R1-R5描述}` | Step 1 领域校准各规则描述 | 见分析框架A-2 |\n| `{质量检查点}` | G类守护单元插入点 | 平台合规 / 安规认证 / 语法验证 |\n| `{组织原则}` | 域划分依据 | 价值链 / 生命周期 / 职能分工 |\n| `{域概览标题}` | 域概览章节的标题（含前缀） | 域概览 / 文档域概览 / 产出域概览 |\n\n---\n\n## 第一层：Catalog 文件模板\n\n```markdown\n# {清单名称}与依赖拓扑\n\n{领域名}按{组织原则}组织的{任务类型}清单，附{任务间关系}和UTOS元操作映射提示。\n\n**域间逻辑流**：{D1} → {D2} → ... → {Dn}\n\n---\n\n## {第一个域名}\n\n| ID | 任务类型 | 说明 | 依赖 | UTOS映射提示 |\n|----|---------|------|------|-------------|\n| {X}-01 | {任务名} | {一句话说明} | 无（入口） | S→C |\n| {X}-02 | {任务名} | {一句话说明} | {X}-01 | C→A |\n...\n\n## {第二个域名}\n\n...\n\n---\n\n## 依赖拓扑摘要\n\n以下为{任务间关系}的主要{依赖链路}，UTOS执行轴可据此自动编排管线：\n\n**{链路名1}**: {X-01} → {X-02} → ...\n**{链路名2}**: ...\n...\n\n更多组合由UTOS根据具体任务动态推导。\n```\n\n### Catalog 行格式模板\n\n每行遵循固定格式：\n\n```\n| {ID} | {任务名} | {说明} | {依赖(无则写\"无（入口）\")} | {S/C/A/O/I/G映射} |\n```\n\n---\n\n## 第二层：Requirements 文件模板\n\n> **边界说明**：以下五字段是内容轴**清单法的组件清单**，定义每个任务产出物的构成要素。它们**不替代** UTOS 能力单元Schema（单元ID/名称/元操作/输入/输出/依赖/AI自治度/组合接口等）。两者是不同层面的描述——requirements 管\"产出物由什么组成\"，UTOS Schema 管\"任务怎么执行\"。\n\n### 每个任务的槽位定义模板\n\n```markdown\n### {ID} {任务名}\n- **必选组件**: {核心要素1}、{核心要素2}、{核心要素3}...\n- **可选组件**: {可选要素1}、{可选要素2}...\n- **组装顺序**: {步骤1}→{步骤2}→{步骤3}→...\n- **{约束类型}约束**: [待补充] 或具体约束描述\n- **格式**: {输出格式}\n```\n\n### 五字段标准（每个任务的组件必须覆盖）\n\n| 字段 | 是否必填 | 说明 |\n|------|:-------:|------|\n| 必选组件 | ✅ | 产出的最小必要元素集合 |\n| 可选组件 | ❌ | 增强但不影响基本功能的元素 |\n| 组装顺序 | ✅ | 组件填充的逻辑顺序 |\n| 约束 | ⚠️ | 领域特定的质量/合规/风格限制 |\n| 格式 | ✅ | 输出物格式（Markdown/Word/Excel/代码等）|\n\n---\n\n## 第三层：Exemplars 文件模板\n\n### 结构说明\n\n第三层采用**清单主文件 + 子文件**结构：\n\n- `references/exemplars.md` — 范本清单主文件（按域分组的索引 + 公开标准索引 + 填充指南）\n- `references/exemplars/{ID}-{name}.md` — 具体范本文件（每个范本独立一个文件）\n\n主文件只做索引，具体范本内容存子文件。这样主文件不会因任务数多而膨胀，AI 也能按需加载单个范本。\n\n### 主文件模板\n\n```markdown\n# {优秀范本库名称}\n\n{领域名}的范本清单与索引。用于UTOS内容轴**样本法**。\n\nUTOS内容轴样本法执行流程：\n1. 获取样本（本文件索引指向的子文件或用户提供）\n2. 分析样本四维度：结构、风格、逻辑、格式\n3. 整理为「样本特征摘要」\n4. 模仿产出（保持结构框架和风格，替换内容）\n\n> **使用说明**：标注 `[待填充]` 的条目需用户补充范本后方可使用样本法。\n\n---\n\n## {第一个域名}\n\n| 任务ID | 任务类型 | 范本 | 状态 |\n|--------|---------|------|------|\n| {X}-01 | {任务名} | [待填充] {范本描述} | 空 |\n| {X}-02 | {任务名} | {公开标准名}（公开标准） | 可用 |\n...\n\n## {第二个域名}\n\n| 任务ID | 任务类型 | 范本 | 状态 |\n|--------|---------|------|------|\n...\n\n---\n\n## 公开标准范本索引（可选）\n\n> 适用于有行业公开标准的领域（如医药ICH/EMA标准、工程ISO标准等）。无公开标准的领域可省略此章节。\n\n以下为行业公开标准模板，无需用户脱敏即可直接作为样本法参考：\n\n| 标准 | 适用任务 | 来源 |\n|------|---------|------|\n| {标准名} | {任务ID} | {来源机构} |\n...\n\n---\n\n## 用户填充指南\n\n用户向本技能添加范本时：\n\n1. **脱敏**：移除所有敏感信息（产品名、个人信息、商业机密），用占位符替换\n2. **存放**：将范本文件放入 `references/exemplars/` 目录，按任务ID命名（如 `{X}-01-{task-name}.md`）\n3. **注册**：在本文件对应条目中更新范本路径和状态（空→可用）\n4. **特征摘要**：为每个范本撰写四维分析（结构、风格、逻辑、格式），存入同目录 `{ID}.summary.md` 文件\n```\n\n### 子文件模板\n\n每个具体范本独立存放在 `references/exemplars/` 目录下：\n\n```markdown\n### {任务ID} {范本名称}\n\n**对应任务**: {任务ID}\n\n**来源**: [来源说明]\n\n**适用场景**: [什么情况下参考此范本]\n\n**{范本正文标题}**:\n> （范本内容——对于代码类领域此处为可运行代码）\n\n**关键设计决策**:\n- **决策1**: [为什么这样设计]\n- ...\n\n**可复用要素**:\n- [哪些部分可以抽象为通用模式]\n```\n\n### 范本数量建议\n\n| 领域规模 | 最少范本数 | 推荐范围 |\n|---------|----------|---------|\n| 小型(<30任务) | 6 | 8-12 |\n| 中型(30-60任务) | 8 | 10-15 |\n| 大型(>60任务) | 10 | 15-20 |\n\n每个主要域至少应有1-2个范本。\n\nFile v1.0.2:references/utos-interface-checklist.md\n\n# UTOS接口校验清单\n\n生成的领域负载物技能必须通过以下20项逐条检查，确保与UTOS零冲突。每项标注 **PASS** / **FAIL** / **N/A**。\n\n---\n\n## A类：结构一致性（6项，全部必须PASS）\n\n| # | 检查项 | 检查方法 | 通过标准 |\n|---|--------|---------|---------|\n| A1 | 三层结构存在 | 检查references/目录下是否有3个文件 + exemplars/子目录 | 必须有：catalog + requirements + exemplars主文件 + exemplars/子目录 |\n| A2 | SKILL.md含依赖声明 | 检查SKILL.md是否含\"依赖声明\"章节 | 必须声明强依赖universal-task-os |\n| A3 | 加载检查流程完整 | 检查是否有4步流程(检测→安装→加载→降级) | 4步缺一不可 |\n| A4 | 降级模式定义 | 检查是否有只读模式的✅❌权限表 | 必须区分有UTOS和无UTOS两种模式 |\n| A5 | 域间逻辑流声明 | catalog文件头部是否有域间逻辑流描述 | 必须→连接各域 |\n| A6 | 依赖拓扑摘要 | catalog文件末尾是否有\"依赖拓扑摘要\"章节 | 必须有至少3条跨域管线链路 |\n\n## B类：任务Schema完整性（5项，全部必须PASS）\n\n| # | 检查项 | 检查方法 | 通过标准 |\n|---|--------|---------|---------|\n| B1 | 每个任务含5字段 | 随机抽查3-5个任务 | ID/名称/说明/依赖/UTOS映射提示 全部存在 |\n| B2 | 依赖格式正确 | 检查所有任务的\"依赖\"列 | 格式为：\"无（入口）\" 或 \"X-XX\"(有效ID) 或 \"X-XX, Y-YY\"(多依赖) |\n| B3 | UTOS映射提示有效 | 检查映射提示值 | 仅允许：S/C/A/O/I/G 及其组合(→/‖) + 可选的A/G后缀 |\n| B4 | 无孤立任务 | 检查每个非入口任务的前置依赖是否在catalog中存在 | 依赖ID必须指向已定义的任务 |\n| B5 | 入口任务标识正确 | 标注\"无（入口）\"的任务确实是起始点 | 入口任务数应≥1且≤总任务数的30% |\n\n## C类：结构要求槽位规范（4项，至少3项PASS）\n\n| # | 检查项 | 检查方法 | 通过标准 |\n|---|--------|---------|---------|\n| C1 | 必选组件存在 | 每个任务必须有\"必选组件\"字段 | 100%覆盖率 |\n| C2 | 组装顺序存在 | 每个任务必须有\"组装顺序\"字段 | ≥90%覆盖率（极简任务可省略） |\n| C3 | 约束字段存在 | 每个任务必须有约束相关字段 | 命名为\"合规约束\"/\"风格约束\"/\"质量约束\"/\"平台约束\"等均可 |\n| C4 | 格式字段存在 | 每个任务必须指定输出格式 | Markdown/Word/Excel/HTML/PDF/代码等 |\n\n## D类：UTOS接口章节（3项，全部必须PASS）\n\n| # | 检查项 | 检查方法 | 通过标准 |\n|---|--------|---------|---------|\n| D1 | \"与UTOS的接口\"章节 | SKILL.md中是否存在此章节 | 必须存在 |\n| D2 | Step 0-4覆盖 | 该章节是否覆盖Step 0到Step 4 | Step 0/1/2/3/4 全部有内容 |\n| D3 | Step 1领域校准具体化 | Step 1是否包含R1-R5规则的领域特定推导 | 不能照抄通用模板，必须有该领域的具体参数 |\n\n## E类：范本库规范（3项，至少2项PASS）\n\n| # | 检查项 | 检查方法 | 通过标准 |\n|---|--------|---------|---------|\n| E1 | 范本清单表存在 | exemplars.md中是否有按域分组的范本清单表格 | 必须有按任务ID索引的范本表 |\n| E2 | 范本子文件存在 | references/exemplars/目录下是否有.md文件 | 状态为\"可用\"的条目必须有对应子文件 |\n| E3 | 范本模板格式存在 | 是否提供了子文件的标准化模板格式 | 供后续填充的结构模板 |\n\n---\n\n## 校验执行流程\n\n```\n生成技能文件\n ↓\n┌─────────────┐\n│ A类检查(6项)│ ← 结构一致性\n│ 全部PASS? │\n└──────┬──────┘\n │ FAIL → 修正后重新检查\n │ PASS ↓\n┌─────────────┐\n│ B类检查(5项)│ ← 任务Schema\n│ 全部PASS? │\n└──────┬──────┘\n │ FAIL → 补充缺失字段\n │ PASS ↓\n┌─────────────┐\n│ C类检查(4项)│ ← 槽位规范\n│ ≥3 PASS? │\n└──────┬──────┘\n │ 不足 → 补充关键槽位\n │ OK ↓\n┌─────────────┐\n│ D类检查(3项)│ ← UTOS接口\n│ 全部PASS? │\n└──────┬──────┘\n │ FAIL → 重写接口章节\n │ PASS ↓\n┌─────────────┐\n│ E类检查(3项)│ ← 范本库\n│ ≥2 PASS? │\n└──────┬──────┘\n │ 不足 → 创建空范本框架\n │ OK ↓\n ✅ 校验通过，技能可用\n```\n\n## 常见FAIL原因与修正\n\n| FAIL项 | 常见原因 | 修正方法 |\n|--------|---------|---------|\n| A2/A3 | SKILL.md直接复制了其他技能但忘了改领域名 | 全局搜索替换旧领域名为新域名 |\n| B3 | UTOS映射写了中文而非S/C/A代码 | 统一为字母代号 |\n| B4 | 引用了不存在的依赖任务ID | 检查catalog中是否有该ID，或删除无效引用 |\n| D3 | Step 1照抄通用模板无领域特定内容 | 根据分析框架A-2的结果填充具体的R1-R5推导 |\n| C1/C2 | requirements文件是空的或只有标题 | 至少为每个域的代表性任务填写一个完整槽位 |\n| E2 | exemplars.md索引指向的子文件不存在 | 在references/exemplars/下创建对应文件，或在主文件中将状态改为\"空\" |\n\n## 自动化校验提示\n\n此校验清单可以转化为简单的脚本自动化：\n\n```python\n# 伪代码 - 校验逻辑示意\ndef validate_skill(skill_path):\n results = []\n # A类: 文件存在性 + 关键章节检测（含exemplars/子目录）\n results.append(check_A_files_exist(skill_path))\n results.append(check_A_dependency_section(skill_path))\n results.append(check_A_domain_flow(skill_path))\n # B类: Catalog表格解析 + Schema验证\n results.append(check_B_task_schema(skill_path))\n results.append(check_B_dependency_validity(skill_path))\n # C-E类: Requirements和Exemplars抽查\n results.append(check_C_requirements_coverage(skill_path))\n results.append(check_D_utos_interface(skill_path))\n results.append(check_E_exemplar_subfiles(skill_path))\n return generate_report(results)\n```\n\nFile v1.0.2:skill-card.md\n\n## Description:
\nCreates UTOS-compatible domain payload skills from a target domain by guiding domain analysis, skill structure generation, interface checks, and delivery review.
\n\nThis skill is ready for commercial/non-commercial use.
\n\n## Publisher:
\n[wangjiaocheng](https://clawhub.ai/user/wangjiaocheng)
\n\n### License/Terms of Use:
\nMIT-0
\n\n\n## Use Case:
\nDevelopers and agent builders use this meta-skill to create a new domain knowledge reference skill from a described field, including catalog, requirements, exemplars, and UTOS compatibility checks.
\n\n### Deployment Geography for Use:
\nGlobal
\n\n## Known Risks and Mitigations:
\nRisk: Generated skill templates may write files and may propose installing another skill dependency without sufficient confirmation.
\nMitigation: Review generated files before activation, keep output paths inside a disposable or known workspace, and explicitly approve any proposed universal-task-os installation source.
\n\n\n## Reference(s):
\n- [ClawHub skill page](https://clawhub.ai/wangjiaocheng/domain-payload-generator)
\n- [Domain Analysis Framework](references/domain-analysis-framework.md)
\n- [Generator Workflow](references/generator-workflow.md)
\n- [Structure Template](references/structure-template.md)
\n- [UTOS Interface Checklist](references/utos-interface-checklist.md)
\n\n\n## Skill Output:
\n**Output Type(s):** [text, markdown, code, configuration, guidance]
\n**Output Format:** [Markdown skill files and structured implementation guidance]
\n**Output Parameters:** [1D]
\n**Other Properties Related to Output:** [Produces proposed skill directory content that should be reviewed before activation.]
\n\n## Skill Version(s):
\n1.0.2 (source: server-resolved release evidence)
\n\n## Ethical Considerations:
\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.
\n\nArchive v1.0.1: 6 files, 16465 bytes\n\nFiles: references/domain-analysis-framework.md (6818b), references/generator-workflow.md (6622b), references/structure-template.md (8142b), references/utos-interface-checklist.md (5846b), SKILL.md (5811b), _meta.json (143b)\n\nFile v1.0.1:SKILL.md\n\n---\nname: domain-payload-generator\nauthor: 王教成 Wang Jiaocheng (波动几何)\ndescription: 领域负载物技能制作器（Meta-Skill）——Universal Task OS的技能工厂。独立创建与UTOS完全兼容的领域负载物技能，不依赖任何被创建的目标技能。提供领域分析框架（R1-R5分类定位/价值链拆解/任务枚举/UTOS映射推导）、三层结构模板（SKILL.md+catalog+requirements+exemplars）、UTOS接口校验清单（20项逐条检查零冲突保障）、标准化生成工作流。已验证覆盖：智能硬件/单文件产出/网文创作者/医药合规等多类型领域。触发词：领域负载物、技能制作、技能生成、知识参考库、新领域技能、domain payload、skill generator、meta-skill。\n---\n\n# 领域负载物技能制作器\n\n## 定位\n\n本技能是一个 **元技能（Meta-Skill）**——它的产出不是领域知识本身，而是**领域负载物技能**。当用户说\"帮我做一个XX领域的知识参考库\"时，本技能负责从零创建完整的、与UTOS完全兼容的领域负载物技能。\n\n| 本技能提供 | 消费方式 |\n|-----------|---------|\n| 领域分析框架 | 分析新领域并确定域划分和任务类型 |\n| 三层结构模板 | 自动生成SKILL.md + references/三层文件 |\n| UTOS接口校验清单 | 确保生成的技能与UTOS无冲突 |\n| 生成工作流 | 从用户输入到完整技能的标准化流程 |\n\n## 核心能力\n\n```\n用户输入：\"帮我做一个XX领域的知识参考库\"\n ↓\n ┌─────────────────────┐\n │ Step 1: 领域分析 │ ← 用领域分析框架拆解新领域\n │ 确定域数/任务数 │\n ├─────────────────────┤\n │ Step 2: 结构生成 │ ← 用三层结构模板填充内容\n │ SKILL.md │\n │ + catalog │\n │ + requirements │\n │ + exemplars │\n ├─────────────────────┤\n │ Step 3: UTOS校验 │ ← 用接口校验清单检查一致性\n │ 无冲突 → 输出 │\n │ 有冲突 → 修正 │\n └─────────────────────┘\n ↓\n 完整的XX领域知识参考库技能（可直接使用）\n```\n\n## 独立性保证\n\n> **关键设计约束**：本技能**不依赖任何被它创建的领域技能**。它在创建时是自包含的，仅依赖：\n> - Universal Task OS（用于理解目标接口）\n> - 自身的references文件（框架+模板+校验清单）\n\n这意味着：\n- ✅ 创建\"医药文档参考库\"时，不需要医药技能已存在\n- ✅ 创建\"网络小说写作库\"时，不需要网文技能已存在\n- ✅ 本技能可以独立运行，输出产物后才被其他流程消费\n\n## 与UTOS的关系\n\n本技能生成的所有产物都遵循以下UTOS兼容性契约：\n\n| 兼容性维度 | 要求 |\n|-----------|------|\n| **三层结构一致** | 必须为：第一层(清单+拓扑) + 第二层(要求) + 第三层(范本) |\n| **依赖声明格式** | 必须含强依赖UTOS声明 + 加载检查流程 + 降级模式 |\n| **元操作映射** | 每个任务必须标注S/C/A/O/I/G映射提示 |\n| **五字段Schema** | 每个任务组件必选：ID/名称/说明/依赖/UTOS映射 |\n| **域间逻辑流** | 域间必须有明确的价值链逻辑顺序 |\n| **依赖拓扑摘要** | 必须有跨域管线链路描述 |\n| **Step 0-4接口** | SKILL.md必须含\"与UTOS的接口\"章节（Step 0~4各条目） |\n\n## 使用规则\n\n1. **触发条件**：用户请求创建新的领域知识参考库/领域负载物技能时激活\n2. **首次加载**：读取 `references/domain-analysis-framework.md` 获取领域分析方法\n3. **按需深入**：确认领域后，读取 `references/structure-template.md` 获取三层结构模板；读取 `references/utos-interface-checklist.md` 获取校验规则\n4. **执行生成**：按 `references/generator-workflow.md` 的步骤逐一执行\n5. **输出交付**：将生成的技能写入指定目录（默认 `~/.workbuddy/skills//`）\n\n## 已验证的生成案例\n\n本技能已成功用于生成以下领域负载物技能（作为已验证输出的参考样本）：\n\n| 生成的技能 | 领域特征 | 特殊维度 |\n|----------|---------|---------|\n| smart-hardware-reference | 工程化、制造约束 | 硬软一体(G极高)、EVT/DVT/PVT三阶段 |\n| singlefile-output-reference | 代码产出、四大家族体系 | 代码即范本、子分类体系 |\n| web-novel-writing-reference | 高创造性、平台生态 | 连载机制(A极高)、平台规则 |\n| pharma-doc-reference | 高度规范化、合规驱动 | 医药合规(G高)、多域价值链 |\n\n> **注意**：各技能的域数/任务数会随版本迭代变化，具体数字请查阅各技能自身的 `references/output-catalog.md`，此处不再硬编码。\n\n排列逻辑：硬件→软件→文本→文档，从具象到抽象。这些案例证明本技能可以处理：工程化领域(硬件)、代码产出领域(单文件)、高创造性领域(网文)、高度规范化领域(医药)。\n\n## 参考文件索引\n\n| 文件 | 用途 |\n|------|------|\n| `references/domain-analysis-framework.md` | 新领域分析方法论——如何从一个领域名推导出域划分、任务类型、依赖关系 |\n| `references/structure-template.md` | 三层结构模板——SKILL.md/catalog/requirements/exemplars的标准模板及变量替换规则 |\n| `references/utos-interface-checklist.md` | UTOS兼容性校验清单——20项逐条检查，确保生成的技能与UTOS零冲突 |\n| `references/generator-workflow.md` | 完整生成工作流——从用户输入到技能产出的每一步操作指南 |\n\nFile v1.0.1:_meta.json\n\n{\n \"ownerId\": \"kn75v65h3zezxajen2xf64b2v1845d98\",\n \"slug\": \"domain-payload-generator\",\n \"version\": \"1.0.1\",\n \"publishedAt\": 1779152983844\n}\n\nFile v1.0.1:references/domain-analysis-framework.md\n\n# 领域分析框架\n\n当用户提出\"帮我做一个XX领域知识参考库\"时，用此框架从零分析新领域并推导出完整的域划分和任务类型。\n\n---\n\n## Step A：领域定义\n\n### A-1 领域名称规范化\n\n| 输入 | 处理 | 输出 |\n|------|------|------|\n| 用户原始描述 | 提取核心领域关键词 + 确定边界 | 标准化的领域英文名 + 中文名 |\n\n**示例映射**：\n\n| 用户输入 | 规范化领域名 | 域代号前缀 |\n|---------|------------|-----------|\n| \"写小说的\" | Novel Writing (小说创作) | N |\n| \"做智能硬件的\" | Smart Hardware (智能硬件) | H |\n| \"写HTML/Python/Shell/SQL单文件工具的\" | Single-File Output (单文件产出) | S |\n| \"做会计代账的\" | Bookkeeping Agency (代理记账) | B |\n| \"教人减肥健身的\" | Metabolic Healing (代谢慢病) | M |\n\n### A-2 领域分类定位\n\n将目标领域在以下坐标系中定位，决定后续生成的参数倾向：\n\n| 维度 | 低(R1-R2) | 高(R3-R4) | 影响什么 |\n|------|----------|----------|---------|\n| **规范性(G权重)** | 创作类/设计类 → G偏松 | 法规类/工程类 → G偏严 | 守护单元密度、合规约束数量 |\n| **创造性(A权重)** | 流程类/合规类 → A标准 | 艺术类/研发类 → A极高 | 内容轴创新轴激活频率 |\n| **信息密度(S/C权重)** | 操作类/手工类 → S轻 | 数据类/研究类 → S重C深 | 感知和认知单元占比 |\n| **交互性(I权重)** | 独立产出类 → I少 | 服务类/协作类 → I多 | 交互单元数量 |\n| **迭代性(循环)** | 一次性交付→循环少 | 持续运营/连载→循环多 | 管线中↻模式的使用 |\n\n**快速判定表**：\n\n| 典型领域 | R1规范 | R2创造 | R3交互 | R4迭代 | 推导结果 |\n|---------|--------|--------|--------|--------|---------|\n| 医药文档 | 高 | 中 | 高 | 中 | G高I高A标准C深 |\n| 网络小说 | 低 | 极高 | 中 | 极高 | A极高G松循环多 |\n| 智能硬件 | 高 | 高 | 高 | 高 | 全维度高+G极高 |\n| 单文件代码 | 高 | 中 | 低 | 中 | G高A标准结构清晰 |\n| 代账记账 | 高 | 低 | 中 | 周期性 | G高A低C深O强 |\n| 教学培训 | 中 | 中 | 高 | 低 | I高A中G中 |\n\n---\n\n## Step B：域划分（Domain Partitioning）\n\n### B-1 价值链拆解法\n\n**核心方法**：沿领域的**价值链或生命周期**拆分域。每个域代表价值链上的一个阶段。\n\n**通用模板——按生命周期型**（适用于产品/项目/创作类领域）：\n\n```\n阶段0：输入/素材阶段 → 需求/调研/灵感/原料\n阶段1：规划/架构阶段 → 设计/架构/大纲/方案\n阶段2：执行/生产阶段 → 开发/写作/制造/编码（可能有多条并行线）\n阶段3：验证/测试阶段 → 测试/审查/校验/评审\n阶段4：交付/发布阶段 → 发布/部署/上线/出版\n阶段5：运营/维护阶段 → 运营/迭代/客服/优化\n```\n\n**通用模板——按职能分工型**（适用于组织/流程类领域）：\n\n```\n职能1：前端/面向用户 → 销售/服务/展示/内容\n职能2：中台/核心能力 → 产品/技术/专业服务\n职能3：后台/支撑保障 → 合规/财务/人力/IT\n职能4：横向/协同管理 → 项目/质量/战略/风险\n```\n\n### B-2 域数量确定原则\n\n| 因素 | 少域(5-7) | 中等域(8-10) | 多域(11+) |\n|------|----------|-------------|----------|\n| 领域复杂度 | 低 | 中 | 高 |\n| 任务同质化程度 | 高（任务类型相似） | 中 | 低（各域差异大） |\n| 依赖链长度 | 短(<3层) | 中(3-5层) | 长(>5层) |\n| 参考案例 | — | 单文件产出、网文、硬件 | 医药 |\n\n**经验公式**：域数 = ⌈ln(预估总任务数) × 2⌉，取值范围[5, 15]\n\n### B-3 域命名规范\n\n每个域必须包含：\n- **域代号**：单个大写字母 + 数字编号（如 N1, H3, S5）\n- **域名称**：2-6个中文词，准确描述域的范围\n- **对标说明**（可选）：如果是从已有技能迁移，标注对应关系\n\n**命名禁忌**：\n- ❌ 域名之间有包含关系（如\"开发\"和\"软件开发\"）\n- ❌ 域名过于抽象（如\"管理\"、\"支持\"）\n- ✅ 域名具体且互斥（如\"原型验证\" vs \"量产制造\"，不重叠）\n\n---\n\n## Step C：任务类型推导\n\n### C-1 任务枚举法\n\n对每个域，使用以下问题清单枚举任务类型：\n\n```\n1. 这个域要\"产生\"什么？ → 产出的文档/制品/代码是什么？\n2. 产出之前需要\"准备\"什么？ → 依赖哪些前置输入？\n3. 产出之后需要\"检查\"什么？ → 有哪些质量/合规要求？\n4. 这个域能\"帮助\"其他域做什么？ → 输出被谁消费？\n5. 这个域内是否有\"子流程\"？ → 是否需要进一步拆分为多个任务？\n```\n\n### C-2 任务ID命名规范\n\n```\n{域代号}-{两位序号} 如: N1-01, H4-05, S7-03\n```\n\n### C-3 每个任务的必填字段\n\n| 字段 | 说明 | 示例 |\n|------|------|------|\n| ID | 任务ID | D5-03 |\n| 名称 | 任务类型的简短名称 | DA故事线文档 |\n| 说明 | 一句话描述这个任务产出什么 | 页序、每页核心信息、视觉建议 |\n| 依赖 | 前置任务ID列表，无依赖写\"无（入口）\" | D5-01 |\n| UTOS映射提示 | S/C/A/O/I/G + 组合符号 | C→A（先认知后行动） |\n\n### C-4 UTOS映射提示的推导规则\n\n| 任务特征 | 映射提示 |\n|---------|---------|\n| 收集信息/调研/扫描 | S (感知) |\n| 分析/评估/推理/决策 | C (认知) |\n| 产出/创建/编写/制作 | A (行动) |\n| 存储/归档/索引/分类 | O (组织) |\n| 协调/沟通/确认 | I (交互) |\n| 校验/审核/合规/约束 | G (守护) |\n| 先收集再分析 | S→C |\n| 先分析再产出 | C→A |\n| 分析+产出+需审核 | C→A→G |\n| 采集后直接产出 | S→A |\n\n---\n\n## Step D：依赖拓扑构建\n\n### D-1 域间逻辑流\n\n域间按价值链顺序排列，形成主线流：\n\n```\nD1 → D2 → D3 → ... → Dn\n```\n\n同时标注**并行分支**和**反馈回路**。\n\n### D-2 跨域管线链路\n\n识别3-8条关键跨域管线，每条格式为：\n\n```\n[链路名]: 任务A → 任务B → 任务C → ...\n [对应已有技能的某条链路（如为迁移）]\n```\n\n**管线发现启发式**：\n1. **主链路**：从入口到最终交付的最短路径\n2. **数据链路**：数据/信息的流转路径\n3. **质量链路**：从生产到检验到修正的闭环\n4. **资源链路**：物料/供应链的依赖路径\n5. **加速链路**：MVP/快速版本的特殊路径\n\n### D-3 依赖拓扑摘要格式\n\n```markdown\n## 依赖拓扑摘要\n\n**[链路名1]**: X-01 → X-02 → X-03 → ...\n**[链路名2]**: Y-01 → Y-02 ‖ Y-03 → Y-04 （并行）\n**[闭环链]**: Z-01 → Z-02 → Z-03 → [回到Z-01]\n\n更多组合由UTOS根据具体任务动态推导。\n```\n\nFile v1.0.1:references/generator-workflow.md\n\n# 生成工作流\n\n从用户输入\"帮我做一个XX领域知识参考库\"到完整技能产出的标准化操作流程。\n\n---\n\n## 总览\n\n```\n输入: 用户描述的领域名称\n │\n ├─ Step 1: 领域分析（30-40%时间）\n │ ├─ 1A: 领域定义与分类定位\n │ ├─ 1B: 域划分\n │ └─ 1C: 任务类型枚举 + 依赖推导\n │\n ├─ Step 2: 文件生成（40-50%时间）\n │ ├─ 2A: SKILL.md（用模板填充）\n │ ├─ 2B: references/catalog.md（任务清单+拓扑）\n │ ├─ 2C: references/requirements.md（槽位定义）\n │ └─ 2D: references/exemplars.md（范本框架）\n │\n ├─ Step 3: UTOS校验（10-15%时间）\n │ └─ 20项逐条检查 → 修正FAIL项\n │\n └─ 输出: 完整可用的领域负载物技能目录\n```\n\n---\n\n## Step 1：领域分析\n\n### 1A：领域定义与分类定位\n\n**操作**：\n1. 请用户描述目标领域的核心工作内容\n2. 使用 `domain-analysis-framework.md` 的 **Step A** 进行规范化\n3. 输出：领域英文名、域名代号前缀、R1-R5定位结果\n\n**输出物**：\n\n```\n领域名: {English Name}\n代号前缀: {X}\nR1(规范性): 高/中/低 → G权重: 极高/高/中/低\nR2(创造性): 高/中/低 → A权重: ...\nR3(交互性): ... → I权重: ...\nR4(信息密度): ... → S/C权重: ...\nR5(迭代性): ... → 循环模式使用频率: ...\n```\n\n### 1B：域划分\n\n**操作**：\n1. 根据领域特征选择拆解方法（价值链型 vs 职能分工型 vs 混合型）\n2. 使用 `domain-analysis-framework.md` 的 **Step B** 进行域划分\n3. 确定域数量和每个域的范围边界\n\n**输出物**：\n\n```\n共 N 个域:\n{X}1 {域名1} — {一句话说明范围}\n{X}2 {域名2}\n...\n{X}N {域名N}\n\n域间逻辑流: {X}1 → {X}2 → ... → {X}N\n```\n\n### 1C：任务类型枚举与依赖推导\n\n**操作**：\n1. 对每个域，使用 **Step C** 的问题清单枚举任务\n2. 为每个任务分配ID（{X}{域号}-{序号}）和UTOS映射提示\n3. 使用 **Step D** 构建依赖拓扑\n\n**输出物**：\n\n```\n总任务数: M 种\n各域任务分布: {X}1(n1种) / {X}2(n2种) / ...\n\n关键跨域管线:\n- {管线名1}: {ID}→{ID}→{ID}\n- {管线名2}: ...\n（共 K 条）\n```\n\n---\n\n## Step 2：文件生成\n\n### 2A：SKILL.md\n\n**操作**：\n1. 打开 `structure-template.md` 中的 SKILL.md 模板\n2. 逐一替换所有 `{变量}` 为 Step 1 的分析结果\n3. 特别注意以下字段必须**定制化**而非照搬模板：\n - \"领域特有维度\"章节 —— 必须是该领域独有的\n - \"与UTOS的接口\" Step 1 领域校准 —— 必须有具体参数\n - \"域概览\"表格 —— 必须是实际划分的结果\n\n### 2B：Catalog文件\n\n**操作**：\n1. 按1C的枚举结果，为每个域创建表格\n2. 每个任务一行，格式严格遵循模板\n3. 文件末尾追加\"依赖拓扑摘要\"章节\n4. 至少列出3条跨域管线链路\n\n**质量检查**：\n- [ ] 所有任务ID格式正确\n- [ ] 所有依赖引用有效\n- [ ] UTOS映射提示使用了正确代号\n- [ ] 域间逻辑流声明清晰\n\n### 2C：Requirements文件\n\n**操作**：\n1. 对每个任务创建槽位定义\n2. **必填**：必选组件 + 组装顺序 + 格式\n3. **推荐填写**：可选组件 + 约束字段\n4. 当任务数>30时，可将部分域的要求迁移至 `references/structure-requirements-{domain}.md` 子文件\n\n**槽位编写原则**：\n- 必选组件回答\"这个产出物的最小必要元素是什么？\"\n- 组装顺序回答\"按什么逻辑顺序填充这些元素？\"\n- 约束回答\"这个领域对这个产出的特殊限制是什么？\"\n\n### 2D：Exemplars文件\n\n**操作**：\n1. 创建范本索引表（至少6条EX-01~EX-06）\n2. 创建范本标准格式模板\n3. 如果有现成可用代码/文档，直接嵌入作为初始范本\n4. 否则创建 `[待用户提供]` 占位符框架\n\n**范本策略选择**：\n\n| 领域类型 | 范本策略 | 说明 |\n|---------|---------|------|\n| 代码产出类 | 范本=可运行代码 | 如单文件技能，嵌入完整.html/.py/.sh/.sql |\n| 文档产出类 | 范本=结构化文档模板 | 如医药/代账，嵌入脱敏范例 |\n| 创作产出类 | 范本=技法标注片段 | 如网文，嵌入经典片段+拆解 |\n| 流程产出类 | 范本=流程示例 | 如硬件，嵌入脱敏项目案例 |\n\n---\n\n## Step 3：UTOS校验\n\n### 执行校验\n\n1. 打开 `utos-interface-checklist.md`\n2. 逐项执行 A→B→C→D→E 五类检查\n3. 记录每项结果（PASS/FAIL/N/A）\n\n### 处理FAIL项\n\n| FAIL类别 | 处理策略 |\n|---------|---------|\n| A类(结构) | 通常是因为模板复制遗漏——全局搜索替换修正 |\n| B类(Schema) | 缺失字段或无效值——补充/修正 |\n| C类(槽位) | 覆盖率不足——至少为核心域补全 |\n| D类(接口) | 照搬无定制——重写该领域特定内容 |\n| E类(范本) | 未创建——建立空框架 |\n\n### 校验通过标志\n\n当满足以下条件时，校验通过：\n- A类: 6/6 PASS\n- B类: 5/5 PASS\n- C类: ≥3/4 PASS\n- D类: 3/3 PASS\n- E类: ≥1/2 PASS\n\n---\n\n## Step 4：输出与交付\n\n### 目录结构\n\n生成的技能应具有以下目录结构：\n\n```\n~/.workbuddy/skills/{skill-name}/\n├── SKILL.md # 技能定义\n└── references/\n ├── {catalog-filename}.md # 第一层：清单+拓扑\n ├── {requirements-filename}.md # 第二层：槽位定义\n └── exemplars.md # 第三层：范本库\n```\n\n### 交付检查\n\n在交付给用户前，最终确认：\n\n- [ ] 所有4个文件存在且非空\n- [ ] SKILL.md可在WorkBuddy中被识别和加载\n- [ ] references/下的文件路径在SKILL.md中引用正确\n- [ ] 无遗留的 `{变量}` 占位符\n- [ ] 通过UTOS接口20项校验\n\n### 后续维护提示\n\n向用户说明：\n1. 范本库(exemplars.md)中的`[待提供]`占位符需要后续填充真实内容才能发挥样本法的完整能力\n2. 结构要求(requirements.md)中的`[待补充]`约束字段需要根据实际需求定义\n3. 技能生成后可通过实际使用持续迭代完善\n\n---\n\n## 快速生成速查卡\n\n对于熟练用户，以下是快速生成的心智模型：\n\n```\n听到新领域 → \n ① 它的价值链是什么？（拆成5-12个域）→ \n ② 每个域要产出什么？（列成3-8个任务/域）→ \n ③ 任务间谁先谁后？（画依赖箭头）→ \n ④ 每个任务的\"零件清单\"是什么？（写必选组件+顺序）→ \n ⑤ 有没有好的例子可以放进去？（收集或标记待填充）→ \n ⑥ 和UTOS对得上吗？（跑20项校验清单）\n```\n\nFile v1.0.1:references/structure-template.md\n\n# 三层结构模板\n\n本文件定义了领域负载物技能的标准三层结构模板。生成新技能时，将 `{变量}` 替换为实际内容。\n\n---\n\n## SKILL.md 模板\n\n```markdown\n# {技能中文名}知识参考库\n\n## 定位\n\n本技能是 **Universal Task OS 的领域负载物仓库**，不包含任何执行框架。只提供{领域名}的\"是什么\"和\"长什么样\"——执行全部委托UTOS。\n\n| 本技能提供 | UTOS消费方式 |\n|-----------|-------------|\n| {产出类型1}清单 | 内容轴·清单法的成品目录 |\n| {产出类型2}要求 | 内容轴·清单法的组件清单 |\n| 优秀范本（待填充） | 内容轴·样本法的样本 |\n| 依赖拓扑 | 执行轴·管线编排的依赖输入 |\n\n## 三层结构\n\n```\n第一层：{清单名称} + 依赖拓扑 → references/{catalog-filename}.md\n第二层：{第二层名称} → references/{requirements-filename}.md\n第三层：{第三层名称} → references/exemplars.md\n```\n\n## 依赖声明\n\n本技能**强依赖** Universal Task OS (universal-task-os)。没有UTOS，本技能只有参考查阅能力，无法执行任何{任务类型}任务。\n\n**加载检查流程**（每次激活时执行）：\n\n1. 检测 `universal-task-os` 技能是否已安装\n2. **未安装** → 自动安装 `universal-task-os` 技能\n3. **安装成功** → 同时加载UTOS，按本技能\"使用规则\"执行\n4. **安装失败** → 降级为**只读参考模式**：\n - ✅ 允许：查阅{清单名称}、{第二层简称}、范本索引\n - ❌ 拒绝：任何涉及{任务类型}产出、管线编排、内容生成的任务，并提示\"需先安装 Universal Task OS\"\n\n**任务模式判定**：\n\n| 任务类型 | 无UTOS | 有UTOS |\n|---------|--------|--------|\n| 查阅{清单名称}/要求/范本 | ✅ 只读参考 | ✅ 完整 |\n| 按{方法论}产出{成品类型} | ❌ 拒绝 | ✅ UTOS编排执行 |\n| 依赖拓扑推导{管线名称} | ❌ 拒绝 | ✅ UTOS执行轴 |\n| {合规/质量}检查点插入 | ❌ 拒绝 | ✅ UTOS守护单元 |\n\n## 使用规则\n\n1. **依赖检查**：激活时按上述流程检测并安装UTOS\n2. **首次加载**：读取 `references/{catalog-filename}.md`，获取域分类、依赖拓扑、UTOS元操作映射提示\n3. **按需深入**：确认目标{任务}类型后，读取 `references/{requirements-filename}.md` 获取组件清单；如需样本法，读取 `references/exemplars.md` 获取范本\n4. **委托UTOS**：将{清单名称}作为清单法输入、范本作为样本法输入、依赖拓扑作为管线编排输入，交给UTOS执行轴+内容轴处理\n5. **{用户填充说明}**\n\n## 与UTOS的接口\n\n当UTOS处理{领域名}领域任务时：\n\n- **Step 0 三轴判定**：{领域}任务通常为{复杂度判定}+{内容类型判定} → {激活的轴}\n- **Step 1 领域校准**：{领域}={R1描述}+{R2描述}+... → {权重推导结论}\n- **Step 2 内容轴**：清单法用本技能的{requirements-filename}；样本法用本技能的exemplars\n- **Step 3 执行轴**：管线编排基于本技能的依赖拓扑自动推导元操作序列\n- **Step 4 交付**：G类守护单元自动插入{质量检查点类型}\n\n## {领域特有维度标题}\n\n{特有维度的表格或列表说明}\n\n## {域概览标题}\n\n按{组织原则}组织，共{域数}域{总任务数}种{任务类型}：\n\n| 域 | 任务数 | 典型任务 |\n|----|--------|---------|\n{域概览表格行}\n\n完整清单见 `references/{catalog-filename}.md`。\n```\n\n### SKILL.md 变量替换表\n\n| 变量 | 说明 | 示例值 |\n|------|------|--------|\n| `{技能中文名}` | 技能的中文名称 | 医药行业文档 / 网络小说创作 |\n| `{领域名}` | 领域的简称 | 医药 / 网络小说 / 智能硬件 |\n| `{产出类型}` | 技能提供的内容类别 | 文档清单 / 写作任务 / 开发任务 |\n| `{catalog-filename}` | 第一层文件名 | document-catalog / writing-catalog |\n| `{第二层名称}` | 三层结构第二层的显示名称 | 内容要求清单 / 结构要求清单 |\n| `{第三层名称}` | 三层结构第三层的显示名称 | 优秀范本库 / 经典范本库 |\n| `{第二层简称}` | 第二层在只读模式等处的简写（不含\"清单\"后缀） | 内容要求 / 结构要求 |\n| `{requirements-filename}` | 第二层文件名 | content-requirements / structure-requirements |\n| `{任务类型}` | 领域中的工作单元 | 文档 / 写作任务 / 开发任务 |\n| `{成品类型}` | 最终交付物 | 文档 / 章节 / 产品 |\n| `{方法论}` | 内容轴方法 | 清单法 / 样本法 |\n| `{合规/质量}` | 领域的质量约束 | 合规 / 风格一致性 / 功能测试 |\n| `{复杂度判定}` | Step 0 判定结果 | 中等+结构化 / 复杂+结构化 |\n| `{R1-R5描述}` | Step 1 领域校准各规则描述 | 见分析框架A-2 |\n| `{质量检查点}` | G类守护单元插入点 | 平台合规 / 安规认证 / 语法验证 |\n| `{组织原则}` | 域划分依据 | 价值链 / 生命周期 / 职能分工 |\n| `{域概览标题}` | 域概览章节的标题（含前缀） | 域概览 / 文档域概览 / 产出域概览 |\n\n---\n\n## 第一层：Catalog 文件模板\n\n```markdown\n# {清单名称}与依赖拓扑\n\n{领域名}按{组织原则}组织的{任务类型}清单，附{任务间关系}和UTOS元操作映射提示。\n\n**域间逻辑流**：{D1} → {D2} → ... → {Dn}\n\n---\n\n## {第一个域名}\n\n| ID | 任务类型 | 说明 | 依赖 | UTOS映射提示 |\n|----|---------|------|------|-------------|\n| {X}-01 | {任务名} | {一句话说明} | 无（入口） | S→C |\n| {X}-02 | {任务名} | {一句话说明} | {X}-01 | C→A |\n...\n\n## {第二个域名}\n\n...\n\n---\n\n## 依赖拓扑摘要\n\n以下为{任务间关系}的主要{依赖链路}，UTOS执行轴可据此自动编排管线：\n\n**{链路名1}**: {X-01} → {X-02} → ...\n**{链路名2}**: ...\n...\n\n更多组合由UTOS根据具体任务动态推导。\n```\n\n### Catalog 行格式模板\n\n每行遵循固定格式：\n\n```\n| {ID} | {任务名} | {说明} | {依赖(无则写\"无（入口）\")} | {S/C/A/O/I/G映射} |\n```\n\n---\n\n## 第二层：Requirements 文件模板\n\n### 每个任务的槽位定义模板\n\n```markdown\n### {ID} {任务名}\n- **必选组件**: {核心要素1}、{核心要素2}、{核心要素3}...\n- **可选组件**: {可选要素1}、{可选要素2}...\n- **组装顺序**: {步骤1}→{步骤2}→{步骤3}→...\n- **{约束类型}约束**: [待补充] 或具体约束描述\n- **格式**: {输出格式}\n```\n\n### 五字段标准（每个任务的组件必须覆盖）\n\n| 字段 | 是否必填 | 说明 |\n|------|:-------:|------|\n| 必选组件 | ✅ | 产出的最小必要元素集合 |\n| 可选组件 | ❌ | 增强但不影响基本功能的元素 |\n| 组装顺序 | ✅ | 组件填充的逻辑顺序 |\n| 约束 | ⚠️ | 领域特定的质量/合规/风格限制 |\n| 格式 | ✅ | 输出物格式（Markdown/Word/Excel/代码等）|\n\n---\n\n## 第三层：Exemplars 文件模板\n\n```markdown\n# {优秀范本库名称}\n\n{领域名}创作的经典范本和技法标注。用于UTOS内容轴**样本法**。\n\n> **使用说明**：范本中标注 `[待用户提供]` 的条目需用户自行填充后才能使用样本法。\n\n---\n\n## 范本索引\n\n| 范本ID | 范本名称 | 对应任务 | 类型 | 来源 | 状态 |\n|--------|---------|---------|------|------|------|\n| EX-01 | {范本名} | {对应任务ID} | {分类} | [待提供] | 待填充 |\n...\n\n---\n\n## 范本模板格式\n\n每个范本按以下结构组织：\n\n\\```markdown\n### EX-XX [范本名称]\n\n**对应任务**: {XX-XX}\n\n**来源**: [来源说明]\n\n**适用场景**: [什么情况下参考此范本]\n\n**{范本正文标题}**:\n> （范本内容——对于代码类领域此处为可运行代码）\n\n**关键设计决策**:\n- **决策1**: [为什么这样设计]\n- ...\n\n**可复用要素**:\n- [哪些部分可以抽象为通用模式]\n\\```\n```\n\n### 范本数量建议\n\n| 领域规模 | 最少范本数 | 推荐范围 |\n|---------|----------|---------|\n| 小型(<30任务) | 6 | 8-12 |\n| 中型(30-60任务) | 8 | 10-15 |\n| 大型(>60任务) | 10 | 15-20 |\n\n每个主要域至少应有1-2个范本。\n\nFile v1.0.1:references/utos-interface-checklist.md\n\n# UTOS接口校验清单\n\n生成的领域负载物技能必须通过以下20项逐条检查，确保与UTOS零冲突。每项标注 **PASS** / **FAIL** / **N/A**。\n\n---\n\n## A类：结构一致性（6项，全部必须PASS）\n\n| # | 检查项 | 检查方法 | 通过标准 |\n|---|--------|---------|---------|\n| A1 | 三层结构存在 | 检查references/目录下是否有3个文件 | 必须有：catalog + requirements + exemplars（命名可自定义） |\n| A2 | SKILL.md含依赖声明 | 检查SKILL.md是否含\"依赖声明\"章节 | 必须声明强依赖universal-task-os |\n| A3 | 加载检查流程完整 | 检查是否有4步流程(检测→安装→加载→降级) | 4步缺一不可 |\n| A4 | 降级模式定义 | 检查是否有只读模式的✅❌权限表 | 必须区分有UTOS和无UTOS两种模式 |\n| A5 | 域间逻辑流声明 | catalog文件头部是否有域间逻辑流描述 | 必须→连接各域 |\n| A6 | 依赖拓扑摘要 | catalog文件末尾是否有\"依赖拓扑摘要\"章节 | 必须有至少3条跨域管线链路 |\n\n## B类：任务Schema完整性（5项，全部必须PASS）\n\n| # | 检查项 | 检查方法 | 通过标准 |\n|---|--------|---------|---------|\n| B1 | 每个任务含5字段 | 随机抽查3-5个任务 | ID/名称/说明/依赖/UTOS映射提示 全部存在 |\n| B2 | 依赖格式正确 | 检查所有任务的\"依赖\"列 | 格式为：\"无（入口）\" 或 \"X-XX\"(有效ID) 或 \"X-XX, Y-YY\"(多依赖) |\n| B3 | UTOS映射提示有效 | 检查映射提示值 | 仅允许：S/C/A/O/I/G 及其组合(→/‖) + 可选的A/G后缀 |\n| B4 | 无孤立任务 | 检查每个非入口任务的前置依赖是否在catalog中存在 | 依赖ID必须指向已定义的任务 |\n| B5 | 入口任务标识正确 | 标注\"无（入口）\"的任务确实是起始点 | 入口任务数应≥1且≤总任务数的30% |\n\n## C类：结构要求槽位规范（4项，至少3项PASS）\n\n| # | 检查项 | 检查方法 | 通过标准 |\n|---|--------|---------|---------|\n| C1 | 必选组件存在 | 每个任务必须有\"必选组件\"字段 | 100%覆盖率 |\n| C2 | 组装顺序存在 | 每个任务必须有\"组装顺序\"字段 | ≥90%覆盖率（极简任务可省略） |\n| C3 | 约束字段存在 | 每个任务必须有约束相关字段 | 命名为\"合规约束\"/\"风格约束\"/\"质量约束\"/\"平台约束\"等均可 |\n| C4 | 格式字段存在 | 每个任务必须指定输出格式 | Markdown/Word/Excel/HTML/PDF/代码等 |\n\n## D类：UTOS接口章节（3项，全部必须PASS）\n\n| # | 检查项 | 检查方法 | 通过标准 |\n|---|--------|---------|---------|\n| D1 | \"与UTOS的接口\"章节 | SKILL.md中是否存在此章节 | 必须存在 |\n| D2 | Step 0-4覆盖 | 该章节是否覆盖Step 0到Step 4 | Step 0/1/2/3/4 全部有内容 |\n| D3 | Step 1领域校准具体化 | Step 1是否包含R1-R5规则的领域特定推导 | 不能照抄通用模板，必须有该领域的具体参数 |\n\n## E类：范本库规范（2项，至少1项PASS）\n\n| # | 检查项 | 检查方法 | 通过标准 |\n|---|--------|---------|---------|\n| E1 | 范本索引表存在 | exemplars.md中是否有范本索引表格 | 必须有EX-01起的索引表 |\n| E2 | 范本模板格式存在 | 是否提供了范本的标准化模板格式 | 供后续填充的结构模板 |\n\n---\n\n## 校验执行流程\n\n```\n生成技能文件\n ↓\n┌─────────────┐\n│ A类检查(6项)│ ← 结构一致性\n│ 全部PASS? │\n└──────┬──────┘\n │ FAIL → 修正后重新检查\n │ PASS ↓\n┌─────────────┐\n│ B类检查(5项)│ ← 任务Schema\n│ 全部PASS? │\n└──────┬──────┘\n │ FAIL → 补充缺失字段\n │ PASS ↓\n┌─────────────┐\n│ C类检查(4项)│ ← 槽位规范\n│ ≥3 PASS? │\n└──────┬──────┘\n │ 不足 → 补充关键槽位\n │ OK ↓\n┌─────────────┐\n│ D类检查(3项)│ ← UTOS接口\n│ 全部PASS? │\n└──────┬──────┘\n │ FAIL → 重写接口章节\n │ PASS ↓\n┌─────────────┐\n│ E类检查(2项)│ ← 范本库\n│ ≥1 PASS? │\n└──────┬──────┘\n │ 不足 → 创建空范本框架\n │ OK ↓\n ✅ 校验通过，技能可用\n```\n\n## 常见FAIL原因与修正\n\n| FAIL项 | 常见原因 | 修正方法 |\n|--------|---------|---------|\n| A2/A3 | SKILL.md直接复制了其他技能但忘了改领域名 | 全局搜索替换旧领域名为新域名 |\n| B3 | UTOS映射写了中文而非S/C/A代码 | 统一为字母代号 |\n| B4 | 引用了不存在的依赖任务ID | 检查catalog中是否有该ID，或删除无效引用 |\n| D3 | Step 1照抄通用模板无领域特定内容 | 根据分析框架A-2的结果填充具体的R1-R5推导 |\n| C1/C2 | requirements文件是空的或只有标题 | 至少为每个域的代表性任务填写一个完整槽位 |\n\n## 自动化校验提示\n\n此校验清单可以转化为简单的脚本自动化：\n\n```python\n# 伪代码 - 校验逻辑示意\ndef validate_skill(skill_path):\n results = []\n # A类: 文件存在性 + 关键章节检测\n results.append(check_A_files_exist(skill_path))\n results.append(check_A_dependency_section(skill_path))\n results.append(check_A_domain_flow(skill_path))\n # B类: Catalog表格解析 + Schema验证\n results.append(check_B_task_schema(skill_path))\n results.append(check_B_dependency_validity(skill_path))\n # C-E类: Requirements和Exemplars抽查\n results.append(check_C_requirements_coverage(skill_path))\n results.append(check_D_utos_interface(skill_path))\n return generate_report(results)\n```\n\nArchive v1.0.0: 6 files, 16356 bytes\n\nFiles: references/domain-analysis-framework.md (6836b), references/generator-workflow.md (6613b), references/structure-template.md (8150b), references/utos-interface-checklist.md (5846b), SKILL.md (5551b), _meta.json (143b)\n\nFile v1.0.0:SKILL.md\n\n---\nname: domain-payload-generator\nauthor: 王教成 Wang Jiaocheng (波动几何)\ndescription: 领域负载物技能制作器（Meta-Skill）——Universal Task OS的技能工厂。独立创建与UTOS完全兼容的领域负载物技能，不依赖任何被创建的目标技能。提供领域分析框架（R1-R5分类定位/价值链拆解/任务枚举/UTOS映射推导）、三层结构模板（SKILL.md+catalog+requirements+exemplars）、UTOS接口校验清单（20项逐条检查零冲突保障）、标准化生成工作流。已验证案例：医药文档(11域93种)/网络小说(8域56种)/智能硬件(9域68种)/单文件产出(7域52种)。触发词：领域负载物、技能制作、技能生成、知识参考库、新领域技能、domain payload、skill generator、meta-skill。\n---\n\n# 领域负载物技能制作器\n\n## 定位\n\n本技能是一个 **元技能（Meta-Skill）**——它的产出不是领域知识本身，而是**领域负载物技能**。当用户说\"帮我做一个XX领域的知识参考库\"时，本技能负责从零创建完整的、与UTOS完全兼容的领域负载物技能。\n\n| 本技能提供 | 消费方式 |\n|-----------|---------|\n| 领域分析框架 | 分析新领域并确定域划分和任务类型 |\n| 三层结构模板 | 自动生成SKILL.md + references/三层文件 |\n| UTOS接口校验清单 | 确保生成的技能与UTOS无冲突 |\n| 生成工作流 | 从用户输入到完整技能的标准化流程 |\n\n## 核心能力\n\n```\n用户输入：\"帮我做一个XX领域的知识参考库\"\n ↓\n ┌─────────────────────┐\n │ Step 1: 领域分析 │ ← 用领域分析框架拆解新领域\n │ 确定域数/任务数 │\n ├─────────────────────┤\n │ Step 2: 结构生成 │ ← 用三层结构模板填充内容\n │ SKILL.md │\n │ + catalog │\n │ + requirements │\n │ + exemplars │\n ├─────────────────────┤\n │ Step 3: UTOS校验 │ ← 用接口校验清单检查一致性\n │ 无冲突 → 输出 │\n │ 有冲突 → 修正 │\n └─────────────────────┘\n ↓\n 完整的XX领域知识参考库技能（可直接使用）\n```\n\n## 独立性保证\n\n> **关键设计约束**：本技能**不依赖任何被它创建的领域技能**。它在创建时是自包含的，仅依赖：\n> - Universal Task OS（用于理解目标接口）\n> - 自身的references文件（框架+模板+校验清单）\n\n这意味着：\n- ✅ 创建\"医药文档参考库\"时，不需要医药技能已存在\n- ✅ 创建\"网络小说写作库\"时，不需要网文技能已存在\n- ✅ 本技能可以独立运行，输出产物后才被其他流程消费\n\n## 与UTOS的关系\n\n本技能生成的所有产物都遵循以下UTOS兼容性契约：\n\n| 兼容性维度 | 要求 |\n|-----------|------|\n| **三层结构一致** | 必须为：第一层(清单+拓扑) + 第二层(要求) + 第三层(范本) |\n| **依赖声明格式** | 必须含强依赖UTOS声明 + 加载检查流程 + 降级模式 |\n| **元操作映射** | 每个任务必须标注S/C/A/O/I/G映射提示 |\n| **五字段Schema** | 每个任务组件必选：ID/名称/说明/依赖/UTOS映射 |\n| **域间逻辑流** | 域间必须有明确的价值链逻辑顺序 |\n| **依赖拓扑摘要** | 必须有跨域管线链路描述 |\n| **Step 0-4接口** | SKILL.md必须含\"与UTOS的接口\"章节（Step 0~4各条目） |\n\n## 使用规则\n\n1. **触发条件**：用户请求创建新的领域知识参考库/领域负载物技能时激活\n2. **首次加载**：读取 `references/domain-analysis-framework.md` 获取领域分析方法\n3. **按需深入**：确认领域后，读取 `references/structure-template.md` 获取三层结构模板；读取 `references/utos-interface-checklist.md` 获取校验规则\n4. **执行生成**：按 `references/generator-workflow.md` 的步骤逐一执行\n5. **输出交付**：将生成的技能写入指定目录（默认 `~/.workbuddy/skills//`）\n\n## 已验证的生成案例\n\n本技能已成功用于生成以下领域负载物技能（作为已验证输出的参考样本）：\n\n| 生成的技能 | 域数 | 任务数 | 特殊维度 |\n|----------|------|--------|---------|\n| pharma-doc-reference | 11域 | 93种 | 医药合规(G高)、11域价值链 |\n| web-novel-writing-reference | 8域 | 56种 | 网文连载机制(A极高)、平台生态 |\n| smart-hardware-reference | 9域 | 68种 | 硬软一体(G极高)、EVT/DVT/PVT三阶段 |\n| singlefile-output-reference | 7域 | 52种 | 代码即范本、HTML+Python双家族 |\n\n这些案例证明本技能可以处理：高度规范化领域(医药)、高创造性领域(网文)、工程化领域(硬件)、代码产出领域(单文件)。\n\n## 参考文件索引\n\n| 文件 | 用途 |\n|------|------|\n| `references/domain-analysis-framework.md` | 新领域分析方法论——如何从一个领域名推导出域划分、任务类型、依赖关系 |\n| `references/structure-template.md` | 三层结构模板——SKILL.md/catalog/requirements/exemplars的标准模板及变量替换规则 |\n| `references/utos-interface-checklist.md` | UTOS兼容性校验清单——20项逐条检查，确保生成的技能与UTOS零冲突 |\n| `references/generator-workflow.md` | 完整生成工作流——从用户输入到技能产出的每一步操作指南 |\n\nFile v1.0.0:_meta.json\n\n{\n \"ownerId\": \"kn75v65h3zezxajen2xf64b2v1845d98\",\n \"slug\": \"domain-payload-generator\",\n \"version\": \"1.0.0\",\n \"publishedAt\": 1779108596988\n}\n\nFile v1.0.0:references/domain-analysis-framework.md\n\n# 领域分析框架\n\n当用户提出\"帮我做一个XX领域知识参考库\"时，用此框架从零分析新领域并推导出完整的域划分和任务类型。\n\n---\n\n## Step A：领域定义\n\n### A-1 领域名称规范化\n\n| 输入 | 处理 | 输出 |\n|------|------|------|\n| 用户原始描述 | 提取核心领域关键词 + 确定边界 | 标准化的领域英文名 + 中文名 |\n\n**示例映射**：\n\n| 用户输入 | 规范化领域名 | 域代号前缀 |\n|---------|------------|-----------|\n| \"写小说的\" | Novel Writing (小说创作) | N |\n| \"做智能硬件的\" | Smart Hardware (智能硬件) | H |\n| \"写HTML单文件工具的\" | Single-File Output (单文件产出) | S |\n| \"做会计代账的\" | Bookkeeping Agency (代理记账) | B |\n| \"教人减肥健身的\" | Metabolic Healing (代谢慢病) | M |\n\n### A-2 领域分类定位\n\n将目标领域在以下坐标系中定位，决定后续生成的参数倾向：\n\n| 维度 | 低(R1-R2) | 高(R3-R4) | 影响什么 |\n|------|----------|----------|---------|\n| **规范性(G权重)** | 创作类/设计类 → G偏松 | 法规类/工程类 → G偏严 | 守护单元密度、合规约束数量 |\n| **创造性(A权重)** | 流程类/合规类 → A标准 | 艺术类/研发类 → A极高 | 内容轴创新轴激活频率 |\n| **信息密度(S/C权重)** | 操作类/手工类 → S轻 | 数据类/研究类 → S重C深 | 感知和认知单元占比 |\n| **交互性(I权重)** | 独立产出类 → I少 | 服务类/协作类 → I多 | 交互单元数量 |\n| **迭代性(循环)** | 一次性交付→循环少 | 持续运营/连载→循环多 | 管线中↻模式的使用 |\n\n**快速判定表**：\n\n| 典型领域 | R1规范 | R2创造 | R3交互 | R4迭代 | 推导结果 |\n|---------|--------|--------|--------|--------|---------|\n| 医药文档 | 高 | 中 | 高 | 中 | G高I高A标准C深 |\n| 网络小说 | 低 | 极高 | 中 | 极高 | A极高G松循环多 |\n| 智能硬件 | 高 | 高 | 高 | 高 | 全维度高+G极高 |\n| 单文件代码 | 高 | 中 | 低 | 中 | G高A标准结构清晰 |\n| 代账记账 | 高 | 低 | 中 | 周期性 | G高A低C深O强 |\n| 教学培训 | 中 | 中 | 高 | 低 | I高A中G中 |\n\n---\n\n## Step B：域划分（Domain Partitioning）\n\n### B-1 价值链拆解法\n\n**核心方法**：沿领域的**价值链或生命周期**拆分域。每个域代表价值链上的一个阶段。\n\n**通用模板——按生命周期型**（适用于产品/项目/创作类领域）：\n\n```\n阶段0：输入/素材阶段 → 需求/调研/灵感/原料\n阶段1：规划/架构阶段 → 设计/架构/大纲/方案\n阶段2：执行/生产阶段 → 开发/写作/制造/编码（可能有多条并行线）\n阶段3：验证/测试阶段 → 测试/审查/校验/评审\n阶段4：交付/发布阶段 → 发布/部署/上线/出版\n阶段5：运营/维护阶段 → 运营/迭代/客服/优化\n```\n\n**通用模板——按职能分工型**（适用于组织/流程类领域）：\n\n```\n职能1：前端/面向用户 → 销售/服务/展示/内容\n职能2：中台/核心能力 → 产品/技术/专业服务\n职能3：后台/支撑保障 → 合规/财务/人力/IT\n职能4：横向/协同管理 → 项目/质量/战略/风险\n```\n\n### B-2 域数量确定原则\n\n| 因素 | 少域(5-7) | 中等域(8-10) | 多域(11+) |\n|------|----------|-------------|----------|\n| 领域复杂度 | 低 | 中 | 高 |\n| 任务同质化程度 | 高（任务类型相似） | 中 | 低（各域差异大） |\n| 依赖链长度 | 短(<3层) | 中(3-5层) | 长(>5层) |\n| 参考案例 | 单文件产出(7域) | 网文(8域)、硬件(9域) | 医药(11域)、代账(10簇) |\n\n**经验公式**：域数 = ⌈ln(预估总任务数) × 2⌉，取值范围[5, 15]\n\n### B-3 域命名规范\n\n每个域必须包含：\n- **域代号**：单个大写字母 + 数字编号（如 N1, H3, S5）\n- **域名称**：2-6个中文词，准确描述域的范围\n- **对标说明**（可选）：如果是从已有技能迁移，标注对应关系\n\n**命名禁忌**：\n- ❌ 域名之间有包含关系（如\"开发\"和\"软件开发\"）\n- ❌ 域名过于抽象（如\"管理\"、\"支持\"）\n- ✅ 域名具体且互斥（如\"原型验证\" vs \"量产制造\"，不重叠）\n\n---\n\n## Step C：任务类型推导\n\n### C-1 任务枚举法\n\n对每个域，使用以下问题清单枚举任务类型：\n\n```\n1. 这个域要\"产生\"什么？ → 产出的文档/制品/代码是什么？\n2. 产出之前需要\"准备\"什么？ → 依赖哪些前置输入？\n3. 产出之后需要\"检查\"什么？ → 有哪些质量/合规要求？\n4. 这个域能\"帮助\"其他域做什么？ → 输出被谁消费？\n5. 这个域内是否有\"子流程\"？ → 是否需要进一步拆分为多个任务？\n```\n\n### C-2 任务ID命名规范\n\n```\n{域代号}-{两位序号} 如: N1-01, H4-05, S7-03\n```\n\n### C-3 每个任务的必填字段\n\n| 字段 | 说明 | 示例 |\n|------|------|------|\n| ID | 任务ID | D5-03 |\n| 名称 | 任务类型的简短名称 | DA故事线文档 |\n| 说明 | 一句话描述这个任务产出什么 | 页序、每页核心信息、视觉建议 |\n| 依赖 | 前置任务ID列表，无依赖写\"无（入口）\" | D5-01 |\n| UTOS映射提示 | S/C/A/O/I/G + 组合符号 | C→A（先认知后行动） |\n\n### C-4 UTOS映射提示的推导规则\n\n| 任务特征 | 映射提示 |\n|---------|---------|\n| 收集信息/调研/扫描 | S (感知) |\n| 分析/评估/推理/决策 | C (认知) |\n| 产出/创建/编写/制作 | A (行动) |\n| 存储/归档/索引/分类 | O (组织) |\n| 协调/沟通/确认 | I (交互) |\n| 校验/审核/合规/约束 | G (守护) |\n| 先收集再分析 | S→C |\n| 先分析再产出 | C→A |\n| 分析+产出+需审核 | C→A→G |\n| 采集后直接产出 | S→A |\n\n---\n\n## Step D：依赖拓扑构建\n\n### D-1 域间逻辑流\n\n域间按价值链顺序排列，形成主线流：\n\n```\nD1 → D2 → D3 → ... → Dn\n```\n\n同时标注**并行分支**和**反馈回路**。\n\n### D-2 跨域管线链路\n\n识别3-8条关键跨域管线，每条格式为：\n\n```\n[链路名]: 任务A → 任务B → 任务C → ...\n [对应已有技能的某条链路（如为迁移）]\n```\n\n**管线发现启发式**：\n1. **主链路**：从入口到最终交付的最短路径\n2. **数据链路**：数据/信息的流转路径\n3. **质量链路**：从生产到检验到修正的闭环\n4. **资源链路**：物料/供应链的依赖路径\n5. **加速链路**：MVP/快速版本的特殊路径\n\n### D-3 依赖拓扑摘要格式\n\n```markdown\n## 依赖拓扑摘要\n\n**[链路名1]**: X-01 → X-02 → X-03 → ...\n**[链路名2]**: Y-01 → Y-02 ‖ Y-03 → Y-04 （并行）\n**[闭环链]**: Z-01 → Z-02 → Z-03 → [回到Z-01]\n\n更多组合由UTOS根据具体任务动态推导。\n```\n\nFile v1.0.0:references/generator-workflow.md\n\n# 生成工作流\n\n从用户输入\"帮我做一个XX领域知识参考库\"到完整技能产出的标准化操作流程。\n\n---\n\n## 总览\n\n```\n输入: 用户描述的领域名称\n │\n ├─ Step 1: 领域分析（30-40%时间）\n │ ├─ 1A: 领域定义与分类定位\n │ ├─ 1B: 域划分\n │ └─ 1C: 任务类型枚举 + 依赖推导\n │\n ├─ Step 2: 文件生成（40-50%时间）\n │ ├─ 2A: SKILL.md（用模板填充）\n │ ├─ 2B: references/catalog.md（任务清单+拓扑）\n │ ├─ 2C: references/requirements.md（槽位定义）\n │ └─ 2D: references/exemplars.md（范本框架）\n │\n ├─ Step 3: UTOS校验（10-15%时间）\n │ └─ 20项逐条检查 → 修正FAIL项\n │\n └─ 输出: 完整可用的领域负载物技能目录\n```\n\n---\n\n## Step 1：领域分析\n\n### 1A：领域定义与分类定位\n\n**操作**：\n1. 请用户描述目标领域的核心工作内容\n2. 使用 `domain-analysis-framework.md` 的 **Step A** 进行规范化\n3. 输出：领域英文名、域名代号前缀、R1-R5定位结果\n\n**输出物**：\n\n```\n领域名: {English Name}\n代号前缀: {X}\nR1(规范性): 高/中/低 → G权重: 极高/高/中/低\nR2(创造性): 高/中/低 → A权重: ...\nR3(交互性): ... → I权重: ...\nR4(信息密度): ... → S/C权重: ...\nR5(迭代性): ... → 循环模式使用频率: ...\n```\n\n### 1B：域划分\n\n**操作**：\n1. 根据领域特征选择拆解方法（价值链型 vs 职能分工型 vs 混合型）\n2. 使用 `domain-analysis-framework.md` 的 **Step B** 进行域划分\n3. 确定域数量和每个域的范围边界\n\n**输出物**：\n\n```\n共 N 个域:\n{X}1 {域名1} — {一句话说明范围}\n{X}2 {域名2}\n...\n{X}N {域名N}\n\n域间逻辑流: {X}1 → {X}2 → ... → {X}N\n```\n\n### 1C：任务类型枚举与依赖推导\n\n**操作**：\n1. 对每个域，使用 **Step C** 的问题清单枚举任务\n2. 为每个任务分配ID（{X}{域号}-{序号}）和UTOS映射提示\n3. 使用 **Step D** 构建依赖拓扑\n\n**输出物**：\n\n```\n总任务数: M 种\n各域任务分布: {X}1(n1种) / {X}2(n2种) / ...\n\n关键跨域管线:\n- {管线名1}: {ID}→{ID}→{ID}\n- {管线名2}: ...\n（共 K 条）\n```\n\n---\n\n## Step 2：文件生成\n\n### 2A：SKILL.md\n\n**操作**：\n1. 打开 `structure-template.md` 中的 SKILL.md 模板\n2. 逐一替换所有 `{变量}` 为 Step 1 的分析结果\n3. 特别注意以下字段必须**定制化**而非照搬模板：\n - \"领域特有维度\"章节 —— 必须是该领域独有的\n - \"与UTOS的接口\" Step 1 领域校准 —— 必须有具体参数\n - \"域概览\"表格 —— 必须是实际划分的结果\n\n### 2B：Catalog文件\n\n**操作**：\n1. 按1C的枚举结果，为每个域创建表格\n2. 每个任务一行，格式严格遵循模板\n3. 文件末尾追加\"依赖拓扑摘要\"章节\n4. 至少列出3条跨域管线链路\n\n**质量检查**：\n- [ ] 所有任务ID格式正确\n- [ ] 所有依赖引用有效\n- [ ] UTOS映射提示使用了正确代号\n- [ ] 域间逻辑流声明清晰\n\n### 2C：Requirements文件\n\n**操作**：\n1. 对每个任务创建槽位定义\n2. **必填**：必选组件 + 组装顺序 + 格式\n3. **推荐填写**：可选组件 + 约束字段\n4. 当任务数>30时，可将部分域的要求迁移至 `references/structure-requirements-{domain}.md` 子文件\n\n**槽位编写原则**：\n- 必选组件回答\"这个产出物的最小必要元素是什么？\"\n- 组装顺序回答\"按什么逻辑顺序填充这些元素？\"\n- 约束回答\"这个领域对这个产出的特殊限制是什么？\"\n\n### 2D：Exemplars文件\n\n**操作**：\n1. 创建范本索引表（至少6条EX-01~EX-06）\n2. 创建范本标准格式模板\n3. 如果有现成可用代码/文档，直接嵌入作为初始范本\n4. 否则创建 `[待用户提供]` 占位符框架\n\n**范本策略选择**：\n\n| 领域类型 | 范本策略 | 说明 |\n|---------|---------|------|\n| 代码产出类 | 范本=可运行代码 | 如单文件技能，嵌入完整.html/.py |\n| 文档产出类 | 茜本=结构化文档模板 | 如医药/代账，嵌入脱敏范例 |\n| 创作产出类 | 范本=技法标注片段 | 如网文，嵌入经典片段+拆解 |\n| 流程产出类 | 范本=流程示例 | 如硬件，嵌入脱敏项目案例 |\n\n---\n\n## Step 3：UTOS校验\n\n### 执行校验\n\n1. 打开 `utos-interface-checklist.md`\n2. 逐项执行 A→B→C→D→E 五类检查\n3. 记录每项结果（PASS/FAIL/N/A）\n\n### 处理FAIL项\n\n| FAIL类别 | 处理策略 |\n|---------|---------|\n| A类(结构) | 通常是因为模板复制遗漏——全局搜索替换修正 |\n| B类(Schema) | 缺失字段或无效值——补充/修正 |\n| C类(槽位) | 覆盖率不足——至少为核心域补全 |\n| D类(接口) | 照搬无定制——重写该领域特定内容 |\n| E类(范本) | 未创建——建立空框架 |\n\n### 校验通过标志\n\n当满足以下条件时，校验通过：\n- A类: 6/6 PASS\n- B类: 5/5 PASS\n- C类: ≥3/4 PASS\n- D类: 3/3 PASS\n- E类: ≥1/2 PASS\n\n---\n\n## Step 4：输出与交付\n\n### 目录结构\n\n生成的技能应具有以下目录结构：\n\n```\n~/.workbuddy/skills/{skill-name}/\n├── SKILL.md # 技能定义\n└── references/\n ├── {catalog-filename}.md # 第一层：清单+拓扑\n ├── {requirements-filename}.md # 第二层：槽位定义\n └── exemplars.md # 第三层：范本库\n```\n\n### 交付检查\n\n在交付给用户前，最终确认：\n\n- [ ] 所有4个文件存在且非空\n- [ ] SKILL.md可在WorkBuddy中被识别和加载\n- [ ] references/下的文件路径在SKILL.md中引用正确\n- [ ] 无遗留的 `{变量}` 占位符\n- [ ] 通过UTOS接口20项校验\n\n### 后续维护提示\n\n向用户说明：\n1. 范本库(exemplars.md)中的`[待提供]`占位符需要后续填充真实内容才能发挥样本法的完整能力\n2. 结构要求(requirements.md)中的`[待补充]`约束字段需要根据实际需求定义\n3. 技能生成后可通过实际使用持续迭代完善\n\n---\n\n## 快速生成速查卡\n\n对于熟练用户，以下是快速生成的心智模型：\n\n```\n听到新领域 → \n ① 它的价值链是什么？（拆成5-12个域）→ \n ② 每个域要产出什么？（列成3-8个任务/域）→ \n ③ 任务间谁先谁后？（画依赖箭头）→ \n ④ 每个任务的\"零件清单\"是什么？（写必选组件+顺序）→ \n ⑤ 有没有好的例子可以放进去？（收集或标记待填充）→ \n ⑥ 和UTOS对得上吗？（跑20项校验清单）\n```\n\nFile v1.0.0:references/structure-template.md\n\n# 三层结构模板\n\n本文件定义了领域负载物技能的标准三层结构模板。生成新技能时，将 `{变量}` 替换为实际内容。\n\n---\n\n## 第一层：SKILL.md 模板\n\n```markdown\n# {技能中文名}知识参考库\n\n## 定位\n\n本技能是 **Universal Task OS 的领域负载物仓库**，不包含任何执行框架。只提供{领域名}的\"是什么\"和\"长什么样\"——执行全部委托UTOS。\n\n| 本技能提供 | UTOS消费方式 |\n|-----------|-------------|\n| {产出类型1}清单 | 内容轴·清单法的成品目录 |\n| {产出类型2}要求 | 内容轴·清单法的组件清单 |\n| 优秀范本（待填充） | 内容轴·样本法的样本 |\n| 依赖拓扑 | 执行轴·管线编排的依赖输入 |\n\n## 三层结构\n\n```\n第一层：{清单名称} + 依赖拓扑 → references/{catalog-filename}.md\n第二层：{第二层名称} → references/{requirements-filename}.md\n第三层：{第三层名称} → references/exemplars.md\n```\n\n## 依赖声明\n\n本技能**强依赖** Universal Task OS (universal-task-os)。没有UTOS，本技能只有参考查阅能力，无法执行任何{任务类型}任务。\n\n**加载检查流程**（每次激活时执行）：\n\n1. 检测 `universal-task-os` 技能是否已安装\n2. **未安装** → 自动安装 `universal-task-os` 技能\n3. **安装成功** → 同时加载UTOS，按本技能\"使用规则\"执行\n4. **安装失败** → 降级为**只读参考模式**：\n - ✅ 允许：查阅{清单名称}、{第二层简称}、范本索引\n - ❌ 拒绝：任何涉及{任务类型}产出、管线编排、内容生成的任务，并提示\"需先安装 Universal Task OS\"\n\n**任务模式判定**：\n\n| 任务类型 | 无UTOS | 有UTOS |\n|---------|--------|--------|\n| 查阅{清单名称}/要求/范本 | ✅ 只读参考 | ✅ 完整 |\n| 按{方法论}产出{成品类型} | ❌ 拒绝 | ✅ UTOS编排执行 |\n| 依赖拓扑推导{管线名称} | ❌ 拒绝 | ✅ UTOS执行轴 |\n| {合规/质量}检查点插入 | ❌ 拒绝 | ✅ UTOS守护单元 |\n\n## 使用规则\n\n1. **依赖检查**：激活时按上述流程检测并安装UTOS\n2. **首次加载**：读取 `references/{catalog-filename}.md`，获取域分类、依赖拓扑、UTOS元操作映射提示\n3. **按需深入**：确认目标{任务}类型后，读取 `references/{requirements-filename}.md` 获取组件清单；如需样本法，读取 `references/exemplars.md` 获取范本\n4. **委托UTOS**：将{清单名称}作为清单法输入、范本作为样本法输入、依赖拓扑作为管线编排输入，交给UTOS执行轴+内容轴处理\n5. **{用户填充说明}**\n\n## 与UTOS的接口\n\n当UTOS处理{领域名}领域任务时：\n\n- **Step 0 三轴判定**：{领域}任务通常为{复杂度判定}+{内容类型判定} → {激活的轴}\n- **Step 1 领域校准**：{领域}={R1描述}+{R2描述}+... → {权重推导结论}\n- **Step 2 内容轴**：清单法用本技能的{requirements-filename}；样本法用本技能的exemplars\n- **Step 3 执行轴**：管线编排基于本技能的依赖拓扑自动推导元操作序列\n- **Step 4 交付**：G类守护单元自动插入{质量检查点类型}\n\n## {领域特有维度标题}\n\n{特有维度的表格或列表说明}\n\n## {域概览标题}\n\n按{组织原则}组织，共{域数}域{总任务数}种{任务类型}：\n\n| 域 | 任务数 | 典型任务 |\n|----|--------|---------|\n{域概览表格行}\n\n完整清单见 `references/{catalog-filename}.md`。\n```\n\n### SKILL.md 变量替换表\n\n| 变量 | 说明 | 示例值 |\n|------|------|--------|\n| `{技能中文名}` | 技能的中文名称 | 医药行业文档 / 网络小说创作 |\n| `{领域名}` | 领域的简称 | 医药 / 网络小说 / 智能硬件 |\n| `{产出类型}` | 技能提供的内容类别 | 文档清单 / 写作任务 / 开发任务 |\n| `{catalog-filename}` | 第一层文件名 | document-catalog / writing-catalog |\n| `{第二层名称}` | 三层结构第二层的显示名称 | 内容要求清单 / 结构要求清单 |\n| `{第三层名称}` | 三层结构第三层的显示名称 | 优秀范本库 / 经典范本库 |\n| `{第二层简称}` | 第二层在只读模式等处的简写（不含\"清单\"后缀） | 内容要求 / 结构要求 |\n| `{requirements-filename}` | 第二层文件名 | content-requirements / structure-requirements |\n| `{任务类型}` | 领域中的工作单元 | 文档 / 写作任务 / 开发任务 |\n| `{成品类型}` | 最终交付物 | 文档 / 章节 / 产品 |\n| `{方法论}` | 内容轴方法 | 清单法 / 样本法 |\n| `{合规/质量}` | 领域的质量约束 | 合规 / 风格一致性 / 功能测试 |\n| `{复杂度判定}` | Step 0 判定结果 | 中等+结构化 / 复杂+结构化 |\n| `{R1-R5描述}` | Step 1 领域校准各规则描述 | 见分析框架A-2 |\n| `{质量检查点}` | G类守护单元插入点 | 平台合规 / 安规认证 / 语法验证 |\n| `{组织原则}` | 域划分依据 | 价值链 / 生命周期 / 职能分工 |\n| `{域概览标题}` | 域概览章节的标题（含前缀） | 域概览 / 文档域概览 / 产出域概览 |\n\n---\n\n## 第二层：Catalog 文件模板\n\n```markdown\n# {清单名称}与依赖拓扑\n\n{领域名}按{组织原则}组织的{任务类型}清单，附{任务间关系}和UTOS元操作映射提示。\n\n**域间逻辑流**：{D1} → {D2} → ... → {Dn}\n\n---\n\n## {第一个域名}\n\n| ID | 任务类型 | 说明 | 依赖 | UTOS映射提示 |\n|----|---------|------|------|-------------|\n| {X}-01 | {任务名} | {一句话说明} | 无（入口） | S→C |\n| {X}-02 | {任务名} | {一句话说明} | {X}-01 | C→A |\n...\n\n## {第二个域名}\n\n...\n\n---\n\n## 依赖拓扑摘要\n\n以下为{任务间关系}的主要{依赖链路}，UTOS执行轴可据此自动编排管线：\n\n**{链路名1}**: {X-01} → {X-02} → ...\n**{链路名2}**: ...\n...\n\n更多组合由UTOS根据具体任务动态推导。\n```\n\n### Catalog 行格式模板\n\n每行遵循固定格式：\n\n```\n| {ID} | {任务名} | {说明} | {依赖(无则写\"无(入口)\")} | {S/C/A/O/I/G映射} |\n```\n\n---\n\n## 第三层：Requirements 文件模板\n\n### 每个任务的槽位定义模板\n\n```markdown\n### {ID} {任务名}\n- **必选组件**: {核心要素1}、{核心要素2}、{核心要素3}...\n- **可选组件**: {可选要素1}、{可选要素2}...\n- **组装顺序**: {步骤1}→{步骤2}→{步骤3}→...\n- **{约束类型}约束**: [待补充] 或具体约束描述\n- **格式**: {输出格式}\n```\n\n### 五字段标准（每个任务的组件必须覆盖）\n\n| 字段 | 是否必填 | 说明 |\n|------|:-------:|------|\n| 必选组件 | ✅ | 产出的最小必要元素集合 |\n| 可选组件 | ❌ | 增强但不影响基本功能的元素 |\n| 组装顺序 | ✅ | 组件填充的逻辑顺序 |\n| 约束 | ⚠️ | 领域特定的质量/合规/风格限制 |\n| 格式 | ✅ | 输出物格式（Markdown/Word/Excel/代码等）|\n\n---\n\n## 第四层：Exemplars 文件模板\n\n```markdown\n# {优秀范本库名称}\n\n{领域名}创作的经典范本和技法标注。用于UTOS内容轴**样本法**。\n\n> **使用说明**：范本中标注 `[待用户提供]` 的条目需用户自行填充后才能使用样本法。\n\n---\n\n## 范本索引\n\n| 范本ID | 范本名称 | 对应任务 | 类型 | 来源 | 状态 |\n|--------|---------|---------|------|------|------|\n| EX-01 | {范本名} | {对应任务ID} | {分类} | [待提供] | 待填充 |\n...\n\n---\n\n## 范本模板格式\n\n每个范本按以下结构组织：\n\n\\```markdown\n### EX-XX [范本名称]\n\n**对应任务**: {XX-XX}\n\n**来源**: [来源说明]\n\n**适用场景**: [什么情况下参考此范本]\n\n**{范本正文标题}**:\n> （范本内容——对于代码类领域此处为可运行代码）\n\n**关键设计决策**:\n- **决策1**: [为什么这样设计]\n- ...\n\n**可复用要素**:\n- [哪些部分可以抽象为通用模式]\n\\```\n```\n\n### 范本数量建议\n\n| 领域规模 | 最少范本数 | 推荐范围 |\n|---------|----------|---------|\n| 小型(<30任务) | 6 | 8-12 |\n| 中型(30-60任务) | 8 | 10-15 |\n| 大型(>60任务) | 10 | 15-20 |\n\n每个主要域至少应有1-2个范本。\n\nFile v1.0.0:references/utos-interface-checklist.md\n\n# UTOS接口校验清单\n\n生成的领域负载物技能必须通过以下20项逐条检查，确保与UTOS零冲突。每项标注 **PASS** / **FAIL** / **N/A**。\n\n---\n\n## A类：结构一致性（6项，全部必须PASS）\n\n| # | 检查项 | 检查方法 | 通过标准 |\n|---|--------|---------|---------|\n| A1 | 三层结构存在 | 检查references/目录下是否有3个文件 | 必须有：catalog + requirements + exemplars（命名可自定义） |\n| A2 | SKILL.md含依赖声明 | 检查SKILL.md是否含\"依赖声明\"章节 | 必须声明强依赖universal-task-os |\n| A3 | 加载检查流程完整 | 检查是否有4步流程(检测→安装→加载→降级) | 4步缺一不可 |\n| A4 | 降级模式定义 | 检查是否有只读模式的✅❌权限表 | 必须区分有UTOS和无UTOS两种模式 |\n| A5 | 域间逻辑流声明 | catalog文件头部是否有域间逻辑流描述 | 必须→连接各域 |\n| A6 | 依赖拓扑摘要 | catalog文件末尾是否有\"依赖拓扑摘要\"章节 | 必须有至少3条跨域管线链路 |\n\n## B类：任务Schema完整性（5项，全部必须PASS）\n\n| # | 检查项 | 检查方法 | 通过标准 |\n|---|--------|---------|---------|\n| B1 | 每个任务含5字段 | 随机抽查3-5个任务 | ID/名称/说明/依赖/UTOS映射提示 全部存在 |\n| B2 | 依赖格式正确 | 检查所有任务的\"依赖\"列 | 格式为：\"无（入口）\" 或 \"X-XX\"(有效ID) 或 \"X-XX, Y-YY\"(多依赖) |\n| B3 | UTOS映射提示有效 | 检查映射提示值 | 仅允许：S/C/A/O/I/G 及其组合(→/‖) + 可选的A/G后缀 |\n| B4 | 无孤立任务 | 检查每个非入口任务的前置依赖是否在catalog中存在 | 依赖ID必须指向已定义的任务 |\n| B5 | 入口任务标识正确 | 标注\"无（入口）\"的任务确实是起始点 | 入口任务数应≥1且≤总任务数的30% |\n\n## C类：结构要求槽位规范（4项，至少3项PASS）\n\n| # | 检查项 | 检查方法 | 通过标准 |\n|---|--------|---------|---------|\n| C1 | 必选组件存在 | 每个任务必须有\"必选组件\"字段 | 100%覆盖率 |\n| C2 | 组装顺序存在 | 每个任务必须有\"组装顺序\"字段 | ≥90%覆盖率（极简任务可省略） |\n| C3 | 约束字段存在 | 每个任务必须有约束相关字段 | 命名为\"合规约束\"/\"风格约束\"/\"质量约束\"/\"平台约束\"等均可 |\n| C4 | 格式字段存在 | 每个任务必须指定输出格式 | Markdown/Word/Excel/HTML/PDF/代码等 |\n\n## D类：UTOS接口章节（3项，全部必须PASS）\n\n| # | 检查项 | 检查方法 | 通过标准 |\n|---|--------|---------|---------|\n| D1 | \"与UTOS的接口\"章节 | SKILL.md中是否存在此章节 | 必须存在 |\n| D2 | Step 0-4覆盖 | 该章节是否覆盖Step 0到Step 4 | Step 0/1/2/3/4 全部有内容 |\n| D3 | Step 1领域校准具体化 | Step 1是否包含R1-R5规则的领域特定推导 | 不能照抄通用模板，必须有该领域的具体参数 |\n\n## E类：范本库规范（2项，至少1项PASS）\n\n| # | 检查项 | 检查方法 | 通过标准 |\n|---|--------|---------|---------|\n| E1 | 范本索引表存在 | exemplars.md中是否有范本索引表格 | 必须有EX-01起的索引表 |\n| E2 | 范本模板格式存在 | 是否提供了范本的标准化模板格式 | 供后续填充的结构模板 |\n\n---\n\n## 校验执行流程\n\n```\n生成技能文件\n ↓\n┌─────────────┐\n│ A类检查(6项)│ ← 结构一致性\n│ 全部PASS? │\n└──────┬──────┘\n │ FAIL → 修正后重新检查\n │ PASS ↓\n┌─────────────┐\n│ B类检查(5项)│ ← 任务Schema\n│ 全部PASS? │\n└──────┬──────┘\n │ FAIL → 补充缺失字段\n │ PASS ↓\n┌─────────────┐\n│ C类检查(4项)│ ← 槽位规范\n│ ≥3 PASS? │\n└──────┬──────┘\n │ 不足 → 补充关键槽位\n │ OK ↓\n┌─────────────┐\n│ D类检查(3项)│ ← UTOS接口\n│ 全部PASS? │\n└──────┬──────┘\n │ FAIL → 重写接口章节\n │ PASS ↓\n┌─────────────┐\n│ E类检查(2项)│ ← 范本库\n│ ≥1 PASS? │\n└──────┬──────┘\n │ 不足 → 创建空范本框架\n │ OK ↓\n ✅ 校验通过，技能可用\n```\n\n## 常见FAIL原因与修正\n\n| FAIL项 | 常见原因 | 修正方法 |\n|--------|---------|---------|\n| A2/A3 | SKILL.md直接复制了其他技能但忘了改领域名 | 全局搜索替换旧领域名为新域名 |\n| B3 | UTOS映射写了中文而非S/C/A代码 | 统一为字母代号 |\n| B4 | 引用了不存在的依赖任务ID | 检查catalog中是否有该ID，或删除无效引用 |\n| D3 | Step 1照抄通用模板无领域特定内容 | 根据分析框架A-2的结果填充具体的R1-R5推导 |\n| C1/C2 | requirements文件是空的或只有标题 | 至少为每个域的代表性任务填写一个完整槽位 |\n\n## 自动化校验提示\n\n此校验清单可以转化为简单的脚本自动化：\n\n```python\n# 伪代码 - 校验逻辑示意\ndef validate_skill(skill_path):\n results = []\n # A类: 文件存在性 + 关键章节检测\n results.append(check_A_files_exist(skill_path))\n results.append(check_A_dependency_section(skill_path))\n results.append(check_A_domain_flow(skill_path))\n # B类: Catalog表格解析 + Schema验证\n results.append(check_B_task_schema(skill_path))\n results.append(check_B_dependency_validity(skill_path))\n # C-E类: Requirements和Exemplars抽查\n results.append(check_C_requirements_coverage(skill_path))\n results.append(check_D_utos_interface(skill_path))\n return generate_report(results)\n```","readmeExcerpt":"Skill: Domain Payload Generator Owner: wangjiaocheng Summary: 领域负载物技能制作器（Meta-Skill）——Universal Task OS的技能工厂。独立创建与UTOS完全兼容的领域负载物技能，不依赖任何被创建的目标技能。提供领域分析框架（R1-R5分类定位/价值链拆解/任务枚举/UTOS映射推导）、三层结构模板（SKILL.md+catalog+requiremen... Tags: latest:1.0.3 Version history: v1.0.3 | 2026-06-16T06:17:21.990Z | user - 增加UTOS接口校验清单项目数：从20项提升至21项，增强兼容性保障 - 「参考文件索引」和相关说明同步更新为21项校验 - 其余结构与功能保持一致 v1.0.2 | 2026-05-27T10:38:37.300Z | user - ","codeSnippets":[],"executableExamples":[{"language":"text","snippet":"用户输入：\"帮我做一个XX领域的知识参考库\"\n ↓\n ┌─────────────────────┐\n │ Step 1: 领域分析 │ ← 用领域分析框架拆解新领域\n │ 确定域数/任务数 │\n ├─────────────────────┤\n │ Step 2: 结构生成 │ ← 用三层结构模板填充内容\n │ SKILL.md │\n │ + catalog │\n │ + requirements │\n │ + exemplars │\n ├─────────────────────┤\n │ Step 3: UTOS校验 │ ← 用接口校验清单检查一致性\n │ 无冲突 → 输出 │\n │ 有冲突 → 修正 │\n └─────────────────────┘\n ↓\n 完整的XX领域知识参考库技能（可直接使用）"},{"language":"text","snippet":"传统工作流 ──[Workflow Refactor]──→ 重构后IPO基元链\n │\n ▼\n [Domain Payload Generator]\n │\n ▼\n 领域负载物（简化版）\n │\n ▼\n [Universal Task OS] 持续执行"},{"language":"text","snippet":"阶段0：输入/素材阶段 → 需求/调研/灵感/原料\n阶段1：规划/架构阶段 → 设计/架构/大纲/方案\n阶段2：执行/生产阶段 → 开发/写作/制造/编码（可能有多条并行线）\n阶段3：验证/测试阶段 → 测试/审查/校验/评审\n阶段4：交付/发布阶段 → 发布/部署/上线/出版\n阶段5：运营/维护阶段 → 运营/迭代/客服/优化"},{"language":"text","snippet":"职能1：前端/面向用户 → 销售/服务/展示/内容\n职能2：中台/核心能力 → 产品/技术/专业服务\n职能3：后台/支撑保障 → 合规/财务/人力/IT\n职能4：横向/协同管理 → 项目/质量/战略/风险"},{"language":"text","snippet":"1. 这个域要\"产生\"什么？ → 产出的文档/制品/代码是什么？\n2. 产出之前需要\"准备\"什么？ → 依赖哪些前置输入？\n3. 产出之后需要\"检查\"什么？ → 有哪些质量/合规要求？\n4. 这个域能\"帮助\"其他域做什么？ → 输出被谁消费？\n5. 这个域内是否有\"子流程\"？ → 是否需要进一步拆分为多个任务？"},{"language":"text","snippet":"{域代号}-{两位序号} 如: N1-01, H4-05, S7-03"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: domain-payload-generator\nauthor: 王教成 Wang Jiaocheng (波动几何)\ndescription: 领域负载物技能制作器（Meta-Skill）——Universal Task OS的技能工厂。独立创建与UTOS完全兼容的领域负载物技能，不依赖任何被创建的目标技能。提供领域分析框架（R1-R5分类定位/价值链拆解/任务枚举/UTOS映射推导）、三层结构模板（SKILL.md+catalog+requirements+exemplars）、UTOS接口校验清单（21项逐条检查零冲突保障）、标准化生成工作流。复杂领域建议先用 Workflow Refactor 重构工作流再生成。触发词：领域负载物、技能制作、技能生成、知识参考库、新领域技能、domain payload、skill generator、meta-skill。\n---\n\n# 领域负载物技能制作器\n\n## 定位\n\n本技能是一个 **元技能（Meta-Skill）**——它的产出不是领域知识本身，而是**领域负载物技能**。当用户说\"帮我做一个XX领域的知识参考库\"时，本技能负责从零创建完整的、与UTOS完全兼容的领域负载物技能。\n\n| 本技能提供 | 消费方式 |\n|-----------|---------|\n| 领域分析框架 | 分析新领域并确定域划分和任务类型 |\n| 三层结构模板 | 自动生成SKILL.md + references/三层文件 |\n| UTOS接口校验清单 | 确保生成的技能与UTOS无冲突 |\n| 生成工作流 | 从用户输入到完整技能的标准化流程 |\n\n## 核心能力\n\n```\n用户输入：\"帮我做一个XX领域的知识参考库\"\n ↓\n ┌─────────────────────┐\n │ Step 1: 领域分析 │ ← 用领域分析框架拆解新领域\n │ 确定域数/任务数 │\n ├─────────────────────┤\n │ Step 2: 结构生成 │ ← 用三层结构模板填充内容\n │ SKILL.md │\n │ + catalog │\n │ + requirements │\n │ + exemplars │\n ├─────────────────────┤\n │ Step 3: UTOS校验 │ ← 用接口校验清单检查一致性\n │ 无冲突 → 输出 │\n │ 有冲突 → 修正 │\n └─────────────────────┘\n ↓\n 完整的XX领域知识参考库技能（可直接使用）\n```\n\n## 与其他技能的关系\n\n### 独立性保证\n\n> **关键设计约束**：本技能**不依赖任何被它创建的领域技能**。它在创建时是自包含的，仅依赖：\n> - Universal Task OS（用于理解目标接口）\n> - Workflow Refactor（复杂领域先重构工作流，再生成技能）\n> - 自身的references文件（框架+模板+校验清单）\n\n这意味着：\n- ✅ 创建任何领域技能时，不需要该领域技能已存在\n- ✅ 本技能可以独立运行，输出产物后才被其他流程消费\n\n### 职责分工\n\n| 技能 | 管什么 | 不管什么 |\n|------|--------|---------|\n| **Workflow Refactor** | 流程结构——哪些环节保留、消除、校准 | 领域知识内容（清单/样本） |\n| **Domain Payload Generator** | 领域知识内容——catalog(清单)、requirements(要求)、exemplars(范本) | 流程结构 |\n| **Universal Task OS** | 三轴执行框架——执行轴编排、内容轴消费清单/样本、创新轴突破 | 具体领域内容 |\n\n### 价值链\n\n```\n传统工作流 ──[Workflow Refactor]──→ 重构后IPO基元链\n │\n ▼\n [Domain Payload Generator]\n │\n ▼\n 领域负载物（简化版）\n │\n ▼\n [Universal Task OS] 持续执行\n```\n\n转化→创建→执行，是一条价值链，不是替代关系。\n\n### 三条路径对比\n\n| 路径 | 清单/样本来源 | 优势 | 劣势 |\n|------|-------------|------|------|\n| **Workflow Refactor 单独用** | 无，用户临时提供 | 流程极简 | 内容质量靠用户自身积累 |\n| **重构 + Domain Payload + UTOS** | 领域负载物结构化提供 | 流程+内容双保险，系统化 | 首次生成有成本 |\n| **重构 + UTOS（无领域负载物）** | 用户手动输入到 IPO 的 I | 灵活 | 每次都要手动准备，覆盖度不稳定 |\n\n### 重构如何简化负载物\n\n领域负载物的复杂度 = 领域本身的复杂度 + 传统工作流遗留的冗余任务类型。\n\n| 场景 | catalog 任务数 | requirements 复杂度 | exemplars 数量 |\n|------|---------------|-------------------|---------------|\n| 未重构直接生成 | 包含传递/协调/格式环节对应的任务类型 | 大量\"人的局限补偿\"相关要求 | 范本里嵌套冗余中间产物 |\n| 先重构再生成 | 只保留✅核心+🔶校准+⚡关键校验对应的类型 | 要求聚焦事情本身 | 范本干净，无冗余传递物 |\n\n先重构再生成，负载物体积和认知负荷都大幅降低。\n\n### 三层价值属性\n\n| 技能 | 价值类型 | 使用频率 |\n|------|---------|---------|\n| **Workflow Refactor** | 转化价值——解决\"从旧到新\"的转化问题 | 低频、脉冲式 |\n| **Domain Payload Generator** | 创建价值——解决\"从无到有\"的创建问题 | 中频、按需"},{"path":"_meta.json","content":"{\n \"ownerId\": \"kn75v65h3zezxajen2xf64b2v1845d98\",\n \"slug\": \"domain-payload-generator\",\n \"version\": \"1.0.3\",\n \"publishedAt\": 1781590641990\n}"},{"path":"references/domain-analysis-framework.md","content":"# 领域分析框架\n\n当用户提出\"帮我做一个XX领域知识参考库\"时，用此框架从零分析新领域并推导出完整的域划分和任务类型。\n\n---\n\n## Step A：领域定义\n\n### A-1 领域名称规范化\n\n| 输入 | 处理 | 输出 |\n|------|------|------|\n| 用户原始描述 | 提取核心领域关键词 + 确定边界 | 标准化的领域英文名 + 中文名 |\n\n**示例映射**：\n\n| 用户输入 | 规范化领域名 | 域代号前缀 |\n|---------|------------|-----------|\n| \"写小说的\" | Novel Writing (小说创作) | N |\n| \"做智能硬件的\" | Smart Hardware (智能硬件) | H |\n| \"写HTML/Python/Shell/SQL单文件工具的\" | Single-File Output (单文件产出) | S |\n| \"做会计代账的\" | Bookkeeping Agency (代理记账) | B |\n| \"教人减肥健身的\" | Metabolic Healing (代谢慢病) | M |\n\n### A-2 领域分类定位\n\n将目标领域在以下坐标系中定位，决定后续生成的参数倾向：\n\n| 维度 | 低 | 高 | 影响什么 |\n|------|----------|----------|---------|\n| **R1 信息密度(S/C权重)** | 操作类/手工类 → S轻 | 数据类/研究类 → S重C深 | 感知和认知单元占比 |\n| **R2 创造性(A权重)** | 流程类/合规类 → A标准 | 艺术类/研发类 → A极高 | 内容轴创新轴激活频率 |\n| **R3 交互性(I权重)** | 独立产出类 → I少 | 服务类/协作类 → I多 | 交互单元数量 |\n| **R4 规范性(G权重)** | 创作类/设计类 → G偏松 | 法规类/工程类 → G偏严 | 守护单元密度、合规约束数量 |\n| **R5 迭代性(循环)** | 一次性交付→循环少 | 持续运营/连载→循环多 | 管线中↻模式的使用 |\n\n**快速判定表**：\n\n| 典型领域 | R1信息密度 | R2创造 | R3交互 | R4规范 | R5迭代 | 推导结果 |\n|---------|-----------|--------|--------|--------|--------|---------|\n| 医药文档 | 高 | 中 | 高 | 高 | 中 | S重C深I高G高A标准 |\n| 网络小说 | 中 | 极高 | 中 | 低 | 极高 | A极高G松循环多 |\n| 智能硬件 | 高 | 高 | 高 | 高 | 高 | 全维度高+G极高 |\n| 单文件代码 | 中 | 中 | 低 | 高 | 中 | G高A标准结构清晰 |\n| 代账记账 | 高 | 低 | 中 | 高 | 周期性 | G高A低C深O强 |\n| 教学培训 | 中 | 中 | 高 | 中 | 低 | I高A中G中 |\n\n### A-3 R评分到UTOS参数映射\n\n将A-2的R1-R5评分映射为具体的UTOS执行参数：\n\n| R评分 | 元操作权重调整 | AI自治度偏好 | 守护(G)密度 | 管线模式倾向 |\n|-------|--------------|-------------|------------|-------------|\n| **R1信息密度=高** | S↑C↑（感知和认知占比高） | 🟨半自动偏多（需人确认数据源） | 数据准确性校验 | P3并行汇聚（多源数据） |\n| **R1信息密度=低** | S↓C↓（轻感知轻认知） | ⬛全自动偏多 | 低 | P1基础闭环 |\n| **R2创造性=高** | A↑（行动/产出占比高） | ⬜辅助偏多（人定方向） | 风格一致性校验 | P7发散收敛 |\n| **R2创造性=低** | A标准 | ⬛全自动偏多 | 低 | P1基础闭环 |\n| **R3交互性=高** | I↑（交互占比高） | ⬜辅助偏多（人对外沟通） | 沟通合规校验 | P5交互驱动 |\n| **R3交互性=低** | I↓ | ⬛全自动偏多 | 低 | P1基础闭环 |\n| **R4规范性=高** | G↑O↑（守护和组织占比高） | 🟨/⬜（合规节点必须人工） | 高密度，每阶段嵌入G | P6全守护 |\n| **R4规范性=低** | G↓ | ⬛全自动偏多 | 低 | P1基础闭环 |\n| **R5迭代性=高** | 循环↑（短链高频） | 🟨半自动（每轮需确认） | 每轮迭代末尾G | P2迭代精炼 |\n| **R5迭代性=低** | 循环↓（长链低频） | ⬛/🟨 | 终末校验 | P1基础闭环 |\n\n**使用方式**：对每个R维度取评分后，叠加各维度的参数调整。多个维度同时为高时，参数叠加（如R1高+R4高 = S↑C↑G↑O↑ + 高密度守护）。\n\n---\n\n## Step B：域划分（Domain Partitioning）\n\n### B-1 价值链拆解法\n\n**核心方法**：沿领域的**价值链或生命周期**拆分域。每个域代表价值链上的一个阶段。\n\n**通用模板——按生命周期型**（适用于产品/项目/创作类领域）：\n\n```\n阶段0：输入/素材阶段 → 需求/调研/灵感/原料\n阶段1：规划/架构阶段 → 设计/架构/大纲/方案\n阶段2：执行/生产阶段 → 开发/写作/制造/编码（可能有多条并行线）\n阶段3：验证/测试阶段 → 测试/审查/校验/评审\n阶段4：交付/发布阶段 → 发布/部署/上线/出版\n阶段5：运营/维护阶段 → 运营/迭代/客服/优化\n```\n\n**通用模板——按职能分工型**（适用于组织/流程类领域）：\n\n```\n职能1：前端/面向用户 → 销售/服务/展示/内容\n职能2：中台/核心能力 → 产品/技术/专业服务\n职能3：后台/支撑保障 → 合规/财务/人力/IT\n职能4：横向/协同管理 → 项目/质量/战略/风险\n```\n\n### B-2 域数量确定原则\n\n| 因素 | 少域(5-7) | 中等域(8-10) | 多域(11+) |\n|------|----------|-------------|----------|\n| 领域复杂度 | 低 | 中 | 高 |\n| 任务同质化程度 | 高（任务类型相似） | 中 | 低（各域差异大） |\n| 依赖链长度 | 短(<3层) | 中(3-5层) | 长(>5层) |\n| 参考案例 | — | 单文件产出、网文、硬件 | 医药 |\n\n**经验公式**：域数 = ⌈ln(预估总任务数) × 2⌉，取值范围[5, 15]\n\n### B-3 域命名规范\n\n每个域必须包含：\n- **域代号**：单个大写字母 + 数字编号（如 N1, H3, S5）\n- **域名称**：2-6个中文词，准确描述域的范围\n- **对标说明**（可选）：如果是从已有技能"},{"path":"references/generator-workflow.md","content":"# 生成工作流\n\n从用户输入\"帮我做一个XX领域知识参考库\"到完整技能产出的标准化操作流程。\n\n---\n\n## 总览\n\n```\n输入: 用户描述的领域名称\n │\n ├─ Step 1: 领域分析（30-40%时间）\n │ ├─ 1A: 领域定义与分类定位\n │ ├─ 1B: 域划分\n │ └─ 1C: 任务类型枚举 + 依赖推导\n │\n ├─ Step 2: 文件生成（40-50%时间）\n │ ├─ 2A: SKILL.md（用模板填充）\n │ ├─ 2B: references/catalog.md（任务清单+拓扑）\n │ ├─ 2C: references/requirements.md（槽位定义）\n │ └─ 2D: references/exemplars.md（范本框架）\n │\n ├─ Step 3: UTOS校验（10-15%时间）\n │ └─ 21项逐条检查 → 修正FAIL项\n │\n └─ 输出: 完整可用的领域负载物技能目录\n```\n\n---\n\n## Step 1：领域分析\n\n### 1A：领域定义与分类定位\n\n**操作**：\n1. 请用户描述目标领域的核心工作内容\n2. 使用 `domain-analysis-framework.md` 的 **Step A** 进行规范化\n3. 输出：领域英文名、域名代号前缀、R1-R5定位结果\n\n**输出物**：\n\n```\n领域名: {English Name}\n代号前缀: {X}\nR1(信息密度): 高/中/低 → S/C权重: ...\nR2(创造性): 高/中/低 → A权重: ...\nR3(交互性): ... → I权重: ...\nR4(规范性): ... → G权重: ...\nR5(迭代性): ... → 循环模式使用频率: ...\n```\n\n### 1B：域划分\n\n**操作**：\n1. 根据领域特征选择拆解方法（价值链型 vs 职能分工型 vs 混合型）\n2. 使用 `domain-analysis-framework.md` 的 **Step B** 进行域划分\n3. 确定域数量和每个域的范围边界\n\n**输出物**：\n\n```\n共 N 个域:\n{X}1 {域名1} — {一句话说明范围}\n{X}2 {域名2}\n...\n{X}N {域名N}\n\n域间逻辑流: {X}1 → {X}2 → ... → {X}N\n```\n\n### 1C：任务类型枚举与依赖推导\n\n**操作**：\n1. 对每个域，使用 **Step C** 的问题清单枚举任务\n2. 为每个任务分配ID（{X}{域号}-{序号}）和UTOS映射提示\n3. 使用 **Step D** 构建依赖拓扑\n\n**输出物**：\n\n```\n总任务数: M 种\n各域任务分布: {X}1(n1种) / {X}2(n2种) / ...\n\n关键跨域管线:\n- {管线名1}: {ID}→{ID}→{ID}\n- {管线名2}: ...\n（共 K 条）\n```\n\n---\n\n## Step 2：文件生成\n\n### 2A：SKILL.md\n\n**操作**：\n1. 打开 `structure-template.md` 中的 SKILL.md 模板\n2. 逐一替换所有 `{变量}` 为 Step 1 的分析结果\n3. 特别注意以下字段必须**定制化**而非照搬模板：\n - \"领域特有维度\"章节 —— 必须是该领域独有的\n - \"与UTOS的接口\" Step 1 领域校准 —— 必须有具体参数\n - \"域概览\"表格 —— 必须是实际划分的结果\n\n### 2B：Catalog文件\n\n**操作**：\n1. 按1C的枚举结果，为每个域创建表格\n2. 每个任务一行，格式严格遵循模板\n3. 文件末尾追加\"依赖拓扑摘要\"章节\n4. 至少列出3条跨域管线链路\n\n**质量检查**：\n- [ ] 所有任务ID格式正确\n- [ ] 所有依赖引用有效\n- [ ] UTOS映射提示使用了正确代号\n- [ ] 域间逻辑流声明清晰\n\n### 2C：Requirements文件\n\n**操作**：\n1. 对每个任务创建槽位定义\n2. **必填**：必选组件 + 组装顺序 + 格式\n3. **推荐填写**：可选组件 + 约束字段\n4. 当任务数>30时，可将部分域的要求迁移至 `references/structure-requirements-{domain}.md` 子文件\n\n**槽位编写原则**：\n- 必选组件回答\"这个产出物的最小必要元素是什么？\"\n- 组装顺序回答\"按什么逻辑顺序填充这些元素？\"\n- 约束回答\"这个领域对这个产出的特殊限制是什么？\"\n\n### 2D：Exemplars文件\n\n**操作**：\n1. 创建范本清单主文件（按域分组，每个任务一行，用任务ID索引）\n2. 创建范本标准格式模板（子文件模板）\n3. 如果有现成可用范本，存入 `references/exemplars/` 子目录并在主文件注册\n4. 否则创建 `[待填充]` 占位符框架\n\n**范本策略选择**：\n\n| 领域类型 | 范本策略 | 说明 |\n|---------|---------|------|\n| 代码产出类 | 范本=可运行代码 | 如单文件技能，嵌入完整.html/.py/.sh/.sql |\n| 文档产出类 | 范本=结构化文档模板 | 如医药/代账，嵌入脱敏范例 |\n| 创作产出类 | 范本=技法标注片段 | 如网文，嵌入经典片段+拆解 |\n| 流程产出类 | 范本=流程示例 | 如硬件，嵌入脱敏项目案例 |\n\n---\n\n## Step 3：UTOS校验\n\n### 执行校验\n\n1. 打开 `utos-interface-checklist.md`\n2. 逐项执行 A→B→C→D→E 五类检查\n3. 记录每项结果（PASS/FAIL/N/A）\n\n### 处理FAIL项\n\n| FAIL类别 | 处理策略 |\n|---------|---------|\n| A类(结构) | 通常是因为模板复制遗漏——全局搜索替换修正 |\n| B类(Schema) | 缺失字段或无效值——补充/修正 |\n| C类(槽位) | 覆盖率不足——至少为核心域补全 |\n| D类(接口) | 照搬无定制——重写该领域特定内容 |\n| E类(范本) | 未创建——建立空框架 |\n\n### 校验通过标志\n\n当满足以下条件时，校验通过：\n- A类: 6/6 PASS\n- B类: 5/5 PASS\n- C类: ≥3/4 PASS\n- D类: 3/3 PASS\n- E类: ≥2/3 PASS\n\n### 内容质量评估（结构校验通过后）\n\n结构校验只验证\"有没有\"，以下维度评估\"好不好\"：\n\n| 维度 | 评估方法 | 合格标准 |\n|------|---------|---------|\n| **任务覆盖度** | 核对领域核心工作流是否都被catalog中的任务覆盖 | 核心工作流无遗漏，可接受少量边缘任务缺失 |\n| **域间边界清晰度** | 检查各域的任务是否有重叠或归属模糊 | 无同一任务出"},{"path":"references/structure-template.md","content":"# 三层结构模板\n\n本文件定义了领域负载物技能的标准三层结构模板。生成新技能时，将 `{变量}` 替换为实际内容。\n\n---\n\n## SKILL.md 模板\n\n```markdown\n# {技能中文名}知识参考库\n\n## 定位\n\n本技能是 **Universal Task OS 的领域负载物仓库**，不包含任何执行框架。只提供{领域名}的\"是什么\"和\"长什么样\"——执行全部委托UTOS。\n\n| 本技能提供 | UTOS消费方式 |\n|-----------|-------------|\n| {领域名}任务清单+依赖拓扑 | 内容轴·清单法的任务目录 + 执行轴·管线编排的依赖输入 |\n| {任务类型}要求 | 内容轴·清单法的组件清单 |\n| 优秀范本（待填充） | 内容轴·样本法的样本 |\n\n## 三层结构\n\n```\n第一层：{清单名称} + 依赖拓扑 → references/{catalog-filename}.md\n第二层：{第二层名称} → references/{requirements-filename}.md\n第三层：{第三层名称} → references/exemplars.md\n```\n\n## 依赖声明\n\n本技能**强依赖** Universal Task OS (universal-task-os)。没有UTOS，本技能只有参考查阅能力，无法执行任何{任务类型}任务。\n\n**加载检查流程**（每次激活时执行）：\n\n1. 检测 `universal-task-os` 技能是否已安装\n2. **未安装** → 自动安装 `universal-task-os` 技能\n3. **安装成功** → 同时加载UTOS，按本技能\"使用规则\"执行\n4. **安装失败** → 降级为**只读参考模式**：\n - ✅ 允许：查阅{清单名称}、{第二层简称}、范本索引\n - ❌ 拒绝：任何涉及{任务类型}产出、管线编排、内容生成的任务，并提示\"需先安装 Universal Task OS\"\n\n**任务模式判定**：\n\n| 任务类型 | 无UTOS | 有UTOS |\n|---------|--------|--------|\n| 查阅{清单名称}/要求/范本 | ✅ 只读参考 | ✅ 完整 |\n| 按{方法论}产出{成品类型} | ❌ 拒绝 | ✅ UTOS编排执行 |\n| 依赖拓扑推导{管线名称} | ❌ 拒绝 | ✅ UTOS执行轴 |\n| {合规/质量}检查点插入 | ❌ 拒绝 | ✅ UTOS守护单元 |\n\n## 使用规则\n\n1. **依赖检查**：激活时按上述流程检测并安装UTOS\n2. **首次加载**：读取 `references/{catalog-filename}.md`，获取域分类、依赖拓扑、UTOS元操作映射提示\n3. **按需深入**：确认目标{任务}类型后，读取 `references/{requirements-filename}.md` 获取组件清单；如需样本法，读取 `references/exemplars.md` 获取范本\n4. **委托UTOS**：将{清单名称}作为清单法输入、范本作为样本法输入、依赖拓扑作为管线编排输入，交给UTOS执行轴+内容轴处理\n5. **{用户填充说明}**\n\n## 与UTOS的接口\n\n当UTOS处理{领域名}领域任务时：\n\n- **Step 0 三轴判定**：{领域}任务通常为{复杂度判定}+{内容类型判定} → {激活的轴}\n- **Step 1 领域校准**：{领域}的R1(信息密度)={描述}+R2(创造性)={描述}+R3(交互性)={描述}+R4(规范性)={描述}+R5(迭代性)={描述} → {权重推导结论}\n- **Step 2 内容轴**：清单法用本技能的{requirements-filename}；样本法用本技能的exemplars\n- **Step 3 执行轴**：管线编排基于本技能的依赖拓扑自动推导元操作序列\n- **Step 4 交付**：G类守护单元自动插入{质量检查点类型}\n\n## {领域特有维度标题}\n\n{特有维度的表格或列表说明}\n\n## {域概览标题}\n\n按{组织原则}组织，共{域数}域{总任务数}种{任务类型}：\n\n| 域 | 任务数 | 典型任务 |\n|----|--------|---------|\n{域概览表格行}\n\n完整清单见 `references/{catalog-filename}.md`。\n```\n\n### SKILL.md 变量替换表\n\n| 变量 | 说明 | 示例值 |\n|------|------|--------|\n| `{技能中文名}` | 技能的中文名称 | 医药行业文档 / 网络小说创作 |\n| `{领域名}` | 领域的简称 | 医药 / 网络小说 / 智能硬件 |\n| `{任务类型}` | 领域中的工作单元 | 文档 / 写作任务 / 开发任务 |\n| `{catalog-filename}` | 第一层文件名 | document-catalog / writing-catalog |\n| `{第二层名称}` | 三层结构第二层的显示名称 | 内容要求清单 / 结构要求清单 |\n| `{第三层名称}` | 三层结构第三层的显示名称 | 优秀范本库 / 经典范本库 |\n| `{第二层简称}` | 第二层在只读模式等处的简写（不含\"清单\"后缀） | 内容要求 / 结构要求 |\n| `{requirements-filename}` | 第二层文件名 | content-requirements / structure-requirements |\n| `{成品类型}` | 最终交付物 | 文档 / 章节 / 产品 |\n| `{方法论}` | 内容轴方法 | 清单法 / 样本法 |\n| `{合规/质量}` | 领域的质量约束 | 合规 / 风格一致性 / 功能测试 |\n| `{复杂度判定}` | Step 0 判定结果 | 中等+结构化 / 复杂+结构化 |\n| `{R1-R5描述}` | Step 1 领域校准各规则描述 | 见分析框架A-2 |\n| `{质量检查点}` | G类守护单元插入点 | 平台合规 / 安规认证 / 语法验证 |\n| `{组织原则}` | 域划分依据 | 价值链 / 生命周期 / 职能分工 |\n| `{域概览标题}` | 域概览章节的标题（含前缀） | 域概览 / 文档域概览 / 产出域概览 |\n\n---\n\n## 第一层：Catalog 文件模板\n\n```markdown\n# {清单名称}与依赖拓扑\n\n{领域名}按{组织原则}组织的{任务类型}清单，附{任务间关系}和UTOS元操作映射提示。\n\n**域间逻辑流**：{D1} → {D2} → ... → {Dn}\n\n---\n\n## {第一个域名}\n\n| ID | 任务类型 | 说明 | 依赖 | UTOS映射提示 |\n|----|---------|------|------|-------------|\n| {"}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"领域负载物技能制作器（Meta-Skill）——Universal Task OS的技能工厂。独立创建与UTOS完全兼容的领域负载物技能，不依赖任何被创建的目标技能。提供领域分析框架（R1-R5分类定位/价值链拆解/任务枚举/UTOS映射推导）、三层结构模板（SKILL.md+catalog+requiremen... Skill: Domain Payload Generator Owner: wangjiaocheng Summary: 领域负载物技能制作器（Meta-Skill）——Universal Task OS的技能工厂。独立创建与UTOS完全兼容的领域负载物技能，不依赖任何被创建的目标技能。提供领域分析框架（R1-R5分类定位/价值链拆解/任务枚举/UTOS映射推导）、三层结构模板（SKILL.md+catalog+requiremen... Tags: latest:1.0.3 Version history: v1.0.3 | 2026-06-16T06:17:21.990Z | user - 增加UTOS接口校验清单项目数：从20项提升至21项，增强兼容性保障 - 「参考文件索引」和相关说明同步更新为21项校验 - 其余结构与功能保持一致 v1.0.2 | 2026-05-27T10:38:37.300Z | user -","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":715,"uniquenessScore":53,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T04:06:21.189Z","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-11T04:06:21.189Z","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-11T07:41:46.804Z","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"}]}}}