7.4 KiB
name, version, description, allowed-tools, compatibility
| name | version | description | allowed-tools | compatibility | ||||
|---|---|---|---|---|---|---|---|---|
| product-marketing | 1.0.0 | 编排产品事实、功能列表、招标参数、产品 PPT、技术方案、一页纸、白皮书、招标响应、 演示套件、客户案例和竞品定位等多个独立技能。用于一次请求需要选择或组合多种 产品市场产物，并确保它们共享同一事实版本、术语和承诺边界。 |
|
可独立规划；执行节点需要对应子技能可用 |
产品市场总编排
本技能只负责需求澄清、路由、依赖、门禁和跨产物一致性。各产物的方法和模板由 对应独立技能负责，不能在总技能中重新实现一份简化版本。
子技能
| 技能 | 唯一职责 |
|---|---|
product-evidence |
冻结产品事实、状态、证据和限制 |
product-feature-catalog |
功能目录和版本矩阵 |
tender-technical-spec |
可采购、可验收的招标技术规格 |
product-presentation |
产品介绍 PPT 与讲稿 |
technical-proposal |
客户或投标技术方案 |
product-one-pager |
一页纸产品概览和彩页文案 |
solution-whitepaper |
原理、架构、证据和边界白皮书 |
tender-response-matrix |
招标要求逐条响应、缺口和偏离 |
sales-demo-kit |
可执行演示套件、回退和演练材料 |
customer-case-study |
经授权且可复核的客户案例 |
competitive-positioning |
有来源的竞品矩阵和定位 |
deai-writing 和 longdoc-docx 是可选质量与导出技能，不承担产品事实判断。
第一步：形成任务简报
必须确认：
- 产品和版本。
- 目标受众、决策目标和发布渠道。
- 需要的产物、格式、篇幅、语言和截止时间。
- 公开级别、客户信息和竞品信息的使用权限。
- 原始事实材料、招标文件、客户需求和品牌资产。
- 最终审批人。
信息不足时把缺口写入计划，不默认补齐。
第二步：生成路由计划
复制 templates/route-plan.example.json，只选择完成请求所需节点：
先探测可用的 Python 3 解释器：Windows 优先使用 python，macOS/Linux
优先使用 python3。下文 <python> 表示探测成功的解释器命令。
<python> "<skill-dir>/scripts/validate_route_plan.py" ./route-plan.json
所有产物必须直接或间接依赖唯一的 product-evidence 节点。节点缺少对应技能时
明确报告缺失，不允许由总技能静默生成低质量替代物。
depends_on 表示硬依赖：被依赖节点未 completed 时，本节点不能进入 running
或 completed。可选输入（例如尚无授权的客户案例）不要写进 depends_on，而是
在 reason 中说明“可用则引用，不可用则不提及”。
推荐路由
投标响应（我方应标）
product-evidence
→ tender-response-matrix（提取要求与缺口）
→ technical-proposal
→ tender-response-matrix（回填方案章节和证明材料）
招标文件编制（采购方）
product-evidence → product-feature-catalog → tender-technical-spec
tender-technical-spec 面向采购参数编写，不参与我方符合性判定，两条路由不要
混用。
客户方案
product-evidence
→ product-feature-catalog
→ technical-proposal
→ [product-presentation, product-one-pager]
PPT 和一页纸从已批准方案摘要派生，避免重新解释范围。
产品发布与销售
product-evidence
→ product-feature-catalog
→ [competitive-positioning, customer-case-study]
→ product-one-pager
→ product-presentation
→ sales-demo-kit
客户案例没有授权时把该节点标记 skipped 且 required 为 false，其他节点可
继续，但不得引用该案例。
白皮书
product-evidence → product-feature-catalog → solution-whitepaper
第三步：执行门禁
每个节点开始前检查依赖是否通过；失败节点的下游必须阻断，不能标记成功。执行
过程中更新 status，交付前用 final 阶段复核：
<python> "<skill-dir>/scripts/validate_route_plan.py" ./route-plan.json \
--phase final --output-root .
final 阶段要求必需节点全部 completed、依赖链无未完成节点，并核验每个声明产物
文件存在且非空。
门禁分两类：
evidence-validation、cross-artifact-consistency由本套件自行判定，必须passed，不能豁免。confidentiality-review、human-approval取决于组织流程。需要评审时记为passed；组织不要求时记为waived并在waiver写明责任人与理由，校验通过 但会输出警告，保留豁免记录。
最终统一核对：
- 产品名称、版本、功能状态和术语一致。
- 相同参数的数值、单位、条件和统计口径一致。
planned、beta、released没有跨产物变形。- 客户案例、Logo、引语和竞品结论权限一致。
- 技术方案、PPT、一页纸和演示套件使用相同架构与工作流。
- 所有对外主张可追溯到同一版
product-evidence.json。 - 不含密钥、私有地址、内部证据路径和未批准承诺。
第四步：质量与导出
中文叙事产物可调用 deai-writing；长文可调用 longdoc-docx；PPT 使用
product-presentation 自带构建器。质量工具只能修正表达和排版，不能更改事实、
成熟度、参数或授权边界。
交付物形态
Markdown 与 JSON 是中间产物，不是交付物。除非用户另有指定，交付物为：
| 产物 | 交付格式 |
|---|---|
| 文档类（技术方案、白皮书、功能列表、响应矩阵、招标规格、一页纸、演示套件、竞争定位） | DOCX |
| 产品 PPT | PPTX |
PDF 只作为排版核验中间件，核验后删除，不放入交付目录；用户明确要求时才交付。
目录与密级
中间产物与交付物必须分离，交付目录按各产物自身声明的密级分区：
build/ # 事实清单、路由计划、Markdown、构建配置
check/ # 核验用 PDF、核验报告、页面 PNG
deliverables/
public/ # 可公开
restricted/ # 受控客户交流与投标
internal/ # 仅内部
各子技能的 output 一律指向 deliverables/<密级>/，核验产物一律写入
build/check/。交付目录内只允许出现 DOCX 与 PPTX。
单文件产物直接放 build/<产物名>.md。技术方案、白皮书等需要分章节的长文，改用
build/<产物名>/ 子目录，内部按 longdoc-docx 的 chapters/、assets/、
drafts/ 分层，避免多个长文的章节文件在 build/ 根目录互相混淆。
密级以产物自身标注为准，不得由编排者主观下调。分区后须扫描公开级产物，确认 未夹带受控结论、内部路径与凭据。
路由计划节点的 outputs 必须声明真实交付物路径，Markdown 与 JSON 记入
intermediates。若 outputs 指向中间产物，交付门禁将只校验中间产物而放行缺失
的真实交付物。
完成标准
路由计划通过校验；所有必需节点完成；无失败依赖被忽略；各产物共享同一事实版本； 跨产物一致性、保密审查和人工审批全部通过，并保留选择、跳过和阻断理由；交付目录 中每个产物都以约定格式实际存在，且已按密级分区。