feat: improve skill import and runtime delivery
This commit is contained in:
lofyer
@@ -0,0 +1,200 @@
|
||||
---
|
||||
name: product-marketing
|
||||
version: 1.0.0
|
||||
description: |
|
||||
编排产品事实、功能列表、招标参数、产品 PPT、技术方案、一页纸、白皮书、招标响应、
|
||||
演示套件、客户案例和竞品定位等多个独立技能。用于一次请求需要选择或组合多种
|
||||
产品市场产物，并确保它们共享同一事实版本、术语和承诺边界。
|
||||
allowed-tools:
|
||||
- Read
|
||||
- Grep
|
||||
- Glob
|
||||
- Execute
|
||||
compatibility: 可独立规划；执行节点需要对应子技能可用
|
||||
---
|
||||
|
||||
# 产品市场总编排
|
||||
|
||||
本技能只负责需求澄清、路由、依赖、门禁和跨产物一致性。各产物的方法和模板由
|
||||
对应独立技能负责，不能在总技能中重新实现一份简化版本。
|
||||
|
||||
## 子技能
|
||||
|
||||
| 技能 | 唯一职责 |
|
||||
|---|---|
|
||||
| `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>` 表示探测成功的解释器命令。
|
||||
|
||||
```bash
|
||||
<python> "<skill-dir>/scripts/validate_route_plan.py" ./route-plan.json
|
||||
```
|
||||
|
||||
所有产物必须直接或间接依赖唯一的 `product-evidence` 节点。节点缺少对应技能时
|
||||
明确报告缺失，不允许由总技能静默生成低质量替代物。
|
||||
|
||||
`depends_on` 表示硬依赖：被依赖节点未 `completed` 时，本节点不能进入 `running`
|
||||
或 `completed`。可选输入（例如尚无授权的客户案例）不要写进 `depends_on`，而是
|
||||
在 `reason` 中说明“可用则引用，不可用则不提及”。
|
||||
|
||||
## 推荐路由
|
||||
|
||||
### 投标响应（我方应标）
|
||||
|
||||
```text
|
||||
product-evidence
|
||||
→ tender-response-matrix（提取要求与缺口）
|
||||
→ technical-proposal
|
||||
→ tender-response-matrix（回填方案章节和证明材料）
|
||||
```
|
||||
|
||||
### 招标文件编制（采购方）
|
||||
|
||||
```text
|
||||
product-evidence → product-feature-catalog → tender-technical-spec
|
||||
```
|
||||
|
||||
`tender-technical-spec` 面向采购参数编写，不参与我方符合性判定，两条路由不要
|
||||
混用。
|
||||
|
||||
### 客户方案
|
||||
|
||||
```text
|
||||
product-evidence
|
||||
→ product-feature-catalog
|
||||
→ technical-proposal
|
||||
→ [product-presentation, product-one-pager]
|
||||
```
|
||||
|
||||
PPT 和一页纸从已批准方案摘要派生，避免重新解释范围。
|
||||
|
||||
### 产品发布与销售
|
||||
|
||||
```text
|
||||
product-evidence
|
||||
→ product-feature-catalog
|
||||
→ [competitive-positioning, customer-case-study]
|
||||
→ product-one-pager
|
||||
→ product-presentation
|
||||
→ sales-demo-kit
|
||||
```
|
||||
|
||||
客户案例没有授权时把该节点标记 `skipped` 且 `required` 为 false，其他节点可
|
||||
继续，但不得引用该案例。
|
||||
|
||||
### 白皮书
|
||||
|
||||
```text
|
||||
product-evidence → product-feature-catalog → solution-whitepaper
|
||||
```
|
||||
|
||||
## 第三步：执行门禁
|
||||
|
||||
每个节点开始前检查依赖是否通过；失败节点的下游必须阻断，不能标记成功。执行
|
||||
过程中更新 `status`，交付前用 final 阶段复核：
|
||||
|
||||
```bash
|
||||
<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 只作为排版核验中间件，核验后删除，不放入交付目录；用户明确要求时才交付。
|
||||
|
||||
### 目录与密级
|
||||
|
||||
中间产物与交付物必须分离，交付目录按各产物自身声明的密级分区：
|
||||
|
||||
```text
|
||||
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` 指向中间产物，交付门禁将只校验中间产物而放行缺失
|
||||
的真实交付物。
|
||||
|
||||
## 完成标准
|
||||
|
||||
路由计划通过校验；所有必需节点完成；无失败依赖被忽略；各产物共享同一事实版本；
|
||||
跨产物一致性、保密审查和人工审批全部通过，并保留选择、跳过和阻断理由；交付目录
|
||||
中每个产物都以约定格式实际存在，且已按密级分区。
|
||||
Reference in New Issue
Block a user