@deployxai/dxc 0.1.0

package/skills/dxc-article-outline/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: dxc-article-outline
+description: DxC 内容工作流的大纲步骤。由 dxc-content-workflow 在 outline 阶段调用，消费已收敛 Brief 和可选研究包，按内容类型与情绪选择结构，并输出带钩子、情绪、金句、数据、案例和配图标记的可解析 Markdown 大纲。
+---
+
+# DxC 文章大纲
+
+本 Skill 只负责 `outline`。大纲是正文和视觉计划共同读取的结构 contract。
+
+## 进入阶段
+
+1. 运行 `dxc project status --json`，确认 `brief` 已就绪；研究包存在且本次需要证据锚点
+   时一并读取。
+2. 完整读取
+   [../dxc-content-workflow/references/stage-contract.md](../dxc-content-workflow/references/stage-contract.md)
+   和 [references/outline-methods.md](references/outline-methods.md)。
+3. 以实际输入写 `running` checkpoint：
+
+   ```text
+   dxc project checkpoint outline --status running \
+     --skill dxc-article-outline --skill-version 0.1.0 \
+     --inputs brief,research \
+     --summary "正在选择文章结构并生成可解析大纲" \
+     --execution-location agent-hosted --data-transit agent-provider --json
+   ```
+
+   未读取研究包时只写 `--inputs brief`。
+
+## 生成
+
+1. 从 Brief 提炼一句话主张、目标读者、内容类型和主情绪。
+2. 选择一个主结构，不为了显得复杂而混搭多个框架。
+3. 每节写清楚要点、情绪动作、证据或案例责任。
+4. 使用以下精确标记，不自创新拼写：
+   `[钩子]`、`[情绪:...]`、`[金句位:共鸣|观点|反讽]`、
+   `[数据位:...]`、`[案例位:...]`、`[配图:...]`。
+5. 开头前三行进入读者问题；结尾给明确收束或行动，不留空章节。
+
+## 输出
+
+写入 `artifacts/03-outline.md`：
+
+```markdown
+---
+dxc:
+  contract: dxc-content-stage@1
+  workflowId: dxc-article@1
+  projectId: <项目 UUID>
+  stage: outline
+  skill: dxc-article-outline@0.1.0
+  createdAt: <ISO 8601>
+  artifactStatus: complete
+  inputs:
+    - kind: brief
+      path: artifacts/02-brief.md
+      sha256: <Brief 哈希>
+structure: <结构名称>
+primaryEmotion: <主情绪>
+---
+
+# 文章大纲
+
+## 0. 开头 [钩子] [情绪:好奇]
+
+- 前三行：
+
+## 1. 第一节 [情绪:痛点] [配图:场景插画]
+
+- 核心要点：
+- [金句位:共鸣]
+
+## 2. 第二节 [情绪:搞懂]
+
+- [数据位:需要什么证据]
+
+## 3. 收束 [情绪:行动欲]
+
+- 行动：
+```
+
+通过结构、证据位和标记自检后直接写 `completed`，返回总控继续写正文。普通大纲不设置
+人工确认；用户之后直接编辑大纲时，哈希变化会让正文及下游阶段自动失效。

package/skills/dxc-article-outline/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "DxC 文章大纲"
+  short_description: "把 Brief 变成带情绪、证据、金句和配图锚点的可解析大纲"
+  default_prompt: "为当前 DxC 项目生成结构化大纲，完成后返回总控继续。"
+policy:
+  allow_implicit_invocation: false

package/skills/dxc-article-outline/references/outline-methods.md

@@ -0,0 +1,38 @@
+# 大纲结构与标记
+
+## 结构选择
+
+| 内容与情绪           | 首选结构                             |
+| -------------------- | ------------------------------------ |
+| 怕、怒、问题需要解决 | PAS：痛点、放大、方案                |
+| 暖、敬、人物经历     | 目标、阻碍、努力、转折、结果         |
+| 站队、观点争议       | 痛点、新观点、正例、反例、价值、行动 |
+| 搞懂、认知升级       | SCQA：情境、冲突、问题、答案         |
+| 方法教程             | 问题、原则、方法、案例、清单         |
+| 专业论证             | 结论先行、分论点、证据               |
+| 深度叙事             | 起、承、转、合                       |
+
+只选最符合 Brief 的主结构。情绪型结构必须有出路，不能只放大焦虑。
+
+## 标记 contract
+
+| 标记              | 下游动作                                                                                         |
+| ----------------- | ------------------------------------------------------------------------------------------------ |
+| `[钩子]`          | 正文前三行直接进入冲突、问题或具体场景                                                           |
+| `[情绪:<类型>]`   | 类型可选痛点、放大、方案、好奇、愤怒、释然、满足、行动欲或搞懂                                   |
+| `[金句位:<类型>]` | 类型可选共鸣、观点或反讽；正文写一句可独立成立且服务当前段落的话                                 |
+| `[数据位:说明]`   | 只补有来源的数据，缺失时保留待核实                                                               |
+| `[案例位:说明]`   | 补真实、用户提供或明确脱敏的案例                                                                 |
+| `[配图:<类型>]`   | 类型可选思维导图、概念图、流程图、数据图、金句图、场景插画或氛围；视觉计划读取，不在正文直接插图 |
+
+标记必须位于相关章节内。不要把标记堆到文末。三层以上层级、概念关系、步骤、数据和金句
+分别是思维导图、概念图、流程图、数据图和金句图的信号。
+
+## 自检
+
+- 大纲是否回答 Brief 的核心问题；
+- 每节是否承担一个明确任务；
+- 证据与案例是否有放置位置；
+- 开头是否在前三行进入问题；
+- 情绪放大后是否有方案；
+- 金句和视觉锚点是否服务内容，而不是凑数量。

package/skills/dxc-article-write/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: dxc-article-write
+description: DxC 内容工作流的正文步骤。由 dxc-content-workflow 在 article 阶段调用，消费 Brief、可解析大纲和可选研究包，逐项落实钩子、情绪、金句、数据与案例，生成可直接进入微信公众号渲染的 Markdown 正文，并在最终正文采用前暂停一次。
+---
+
+# DxC 正文写作
+
+本 Skill 只负责 `article`。正文必须是可发布母稿，不能把内部自检表、提示词或大纲标记
+混进最终正文。
+
+## 进入阶段
+
+1. 运行 `dxc project status --json`，确认 `brief` 和 `outline` 已就绪；只有实际需要核对
+   证据时才读取可选 `research`。
+2. 完整读取
+   [../dxc-content-workflow/references/stage-contract.md](../dxc-content-workflow/references/stage-contract.md)
+   和 [references/writing-methods.md](references/writing-methods.md)。
+3. 运行 `dxc profile status --json`。画像存在时用于语气和读者偏好，不存在时从 Brief
+   与大纲推断，不重新打断用户。
+4. 按实际输入写 `running` checkpoint，通常为：
+
+   ```text
+   dxc project checkpoint article --status running \
+     --skill dxc-article-write --skill-version 0.1.0 \
+     --inputs brief,outline,research \
+     --summary "正在把 Brief 和大纲写成可发布正文" \
+     --execution-location agent-hosted --data-transit agent-provider --json
+   ```
+
+## 写作
+
+- 逐项落实大纲标记，但删除所有 `[钩子]`、`[情绪:]`、`[金句位:]`、`[数据位:]`、
+  `[案例位:]` 和 `[配图:]` 标记。
+- 数据、引语和案例只能来自研究包、用户材料或可核验来源。不足时在正文中自然降级表述，
+  或保留明显的 `[待补：...]`；不得编造。
+- 使用具体名词和动词、短段落、对象感和真实细节。少用机械的“首先、其次、综上所述”。
+- 金句服务论证，不为押韵牺牲准确性。
+- 正文 frontmatter 必须同时满足微信文章字段和 DxC 阶段元数据。`author` 未知时写
+  `待确认`，并把它列入最终确认问题；不得自行冒用用户身份。
+- 在生成正文时，Agent 应按文章实际形态填写 `dxc_wechat_template_hint`，作为预览页的
+  初始建议，不向用户提问，也不把它当作发布确认：教程、清单和知识整理优先
+  `wechat-knowledge-base@1`；研究和长报告优先 `wechat-academic-paper@1`；品牌故事和
+  观点文章优先 `wechat-morandi-forest@1`；没有明显匹配时使用 `wechat-minimal@1`。预览页
+  的用户选择始终覆盖该建议。
+
+## 输出与最终正文确认
+
+写入 `artifacts/04-article.md`：
+
+```markdown
+---
+title: <工作标题，最终发布标题以后续 titles 产物为准>
+author: <作者或待确认>
+digest: <正文可兑现的摘要>
+commentsEnabled: true
+dxc_wechat_template_hint: <Agent 建议的云端模板 ID>
+tags: [<标签>]
+dxc:
+  contract: dxc-content-stage@1
+  workflowId: dxc-article@1
+  projectId: <项目 UUID>
+  stage: article
+  skill: dxc-article-write@0.1.0
+  createdAt: <ISO 8601>
+  artifactStatus: awaiting-user
+  inputs:
+    - kind: brief
+      path: artifacts/02-brief.md
+      sha256: <Brief 哈希>
+    - kind: outline
+      path: artifacts/03-outline.md
+      sha256: <大纲哈希>
+---
+
+# 工作标题
+
+正文……
+```
+
+完成自检后把 checkpoint 写为 `awaiting-user`，`waitingFor` 必须具体：
+“正文已经生成。请确认是否采用这版正文；若作者仍为待确认，请同时给出作者名。”
+用户只做明确确认且正文可见内容未变化时，把 `artifactStatus` 改为 `complete`，再写
+`completed --confirm`。用户提出修改时，先更新正文并重新写一次 `awaiting-user`
+检查点、展示修改后的内容；只有用户确认这个新内容快照后才能完成。不要把一句模糊的
+“继续”解释为正文确认，也不得把修改后的新正文直接绑定到旧确认。

package/skills/dxc-article-write/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "DxC 正文写作"
+  short_description: "按 Brief 和大纲生成可发布正文，在最终采用前暂停一次"
+  default_prompt: "为当前 DxC 项目完成正文，并返回最终正文确认问题。"
+policy:
+  allow_implicit_invocation: false

package/skills/dxc-article-write/references/writing-methods.md

@@ -0,0 +1,42 @@
+# 正文写作方法
+
+## 对象感
+
+- 想象一个具体读者和具体阅读场景，直接回答他此刻的问题。
+- 多用“你”和具体场景，少用“大家都知道”。
+- 抽象概念用真实例子、类比或动作细节翻译。
+- 每节至少提供情绪价值、认知增量或可执行方法中的一种。
+
+## 大纲标记落实
+
+| 大纲标记  | 正文动作                                 |
+| --------- | ---------------------------------------- |
+| 钩子      | 前三行进入冲突、痛点、问题或反常识结论   |
+| 痛点/放大 | 写具体后果，但随后必须给方案             |
+| 好奇/搞懂 | 设问后及时回答，不制造空悬念             |
+| 释然/满足 | 给可相信的收束，不灌鸡汤                 |
+| 行动欲    | 给低门槛、可执行的下一步                 |
+| 金句位    | 写短、准、可独立成立且不偏离主题的句子   |
+| 数据位    | 有来源才写精确数字；否则降级或待补       |
+| 案例位    | 人物、冲突、动作和结果必须真实或明确脱敏 |
+
+## 自然写作
+
+- 一段一意，长句拆短，优先具体名词和动词；
+- 删除空洞形容词、重复结论和模板化过渡；
+- 不堆排比，不机械套所有写作框架；
+- 朗读检查节奏，保留适量口语和停顿；
+- 不虚构名人语录、权威背书、数据、案例或热点关系。
+
+## 金句
+
+先确定句子承担认知压缩、情绪共鸣、行动推动或价值宣言中的哪一个功能，再选择对比、
+反转、比喻、对仗或重新定义。朗读后压缩到不能再删。金句必须能从正文论证中推出。
+
+## 发布母稿
+
+- YAML frontmatter 之后只放会进入微信正文的内容；
+- 不附加自检表、风险报告、金句清单或内部提示；
+- 不保留大纲标记；
+- `digest`、标题承诺和正文结论一致；
+- 作者、待补项和事实风险在确认前显式列出。

package/skills/dxc-content-brief/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: dxc-content-brief
+description: DxC 内容工作流的 Brief 步骤。由 dxc-content-workflow 在 brief 阶段调用，消费 research 研究包，把主题、核心问题、受众、角度、内容类型、情绪、来源、来源类型和标签收敛为统一九字段命题；只有多个立场会实质改变文章时才暂停让用户选择。
+---
+
+# DxC 内容 Brief
+
+本 Skill 只负责 `brief`，把研究结果收敛为下游共同使用的单一命题。
+
+## 进入阶段
+
+1. 运行 `dxc project status --json`，确认 `research` 已就绪。
+2. 完整读取
+   [../dxc-content-workflow/references/stage-contract.md](../dxc-content-workflow/references/stage-contract.md)
+   和 [references/brief-method.md](references/brief-method.md)。
+3. 写入：
+
+   ```text
+   dxc project checkpoint brief --status running \
+     --skill dxc-content-brief --skill-version 0.1.0 --inputs research \
+     --summary "正在把研究证据收敛为九字段内容 Brief" \
+     --execution-location agent-hosted --data-transit agent-provider --json
+   ```
+
+   若本次实际完全在本机处理，按真实情况改执行位置和数据去向。
+
+## 收敛规则
+
+- 读取完整研究包；画像已配置时读取 `dxc profile status --json`，未配置则只用当前项目
+  已知信息，不重新启动问卷。
+- 九个字段必须齐全；未知值写清楚“待确认”或“无”，不把推测写成事实。
+- 对角度候选按证据充分度、用户意图匹配、信息增量和风险排序。
+- 一个角度明显占优时自动选定并保留备选理由，直接完成。
+- 两个以上角度在立场、受众承诺或风险上实质不同且无法从上下文判断时，才等待用户。
+
+## 输出与确认
+
+写入 `artifacts/02-brief.md`：
+
+```markdown
+---
+dxc:
+  contract: dxc-content-stage@1
+  workflowId: dxc-article@1
+  projectId: <项目 UUID>
+  stage: brief
+  skill: dxc-content-brief@0.1.0
+  createdAt: <ISO 8601>
+  artifactStatus: <complete|awaiting-user>
+  inputs:
+    - kind: research
+      path: artifacts/01-research.md
+      sha256: <研究包哈希>
+origin: <hotspot|article|keywords|intent>
+selectedAngle: <已选角度或 null>
+---
+
+# 内容 Brief
+
+- 主题：
+- 核心问题：
+- 目标受众：
+- 选定角度：
+- 内容类型：
+- 情绪预判：
+- 来源指针：
+- 来源类型：
+- 标签：
+
+## 角度决策
+
+- 已选：
+- 备选：
+- 选择理由：
+- 风险：
+```
+
+能够唯一收敛时写 `completed` 并立即返回总控。需要用户站队时写 `awaiting-user`，例如：
+“A 侧重反驳行业常识，B 侧重提供中立方法，两者会产生不同文章。请选择 A 或 B。”
+用户明确回答后更新 `selectedAngle`、`artifactStatus` 和选择理由，再写
+`completed --confirm`。不要要求用户确认九个字段的每个细节。

package/skills/dxc-content-brief/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "DxC 内容 Brief"
+  short_description: "把研究包收敛为统一九字段命题，只在真实立场分叉时暂停"
+  default_prompt: "为当前 DxC 项目收敛 Brief，能自动决定就继续，不能时返回具体选择。"
+policy:
+  allow_implicit_invocation: false

package/skills/dxc-content-brief/references/brief-method.md

@@ -0,0 +1,34 @@
+# Brief 收敛方法
+
+## 九字段
+
+1. `topic`：一句话主题；
+2. `coreQuestion`：文章必须回答的问题；
+3. `audience`：具体读者及所处阶段；
+4. `angle`：最终立场或切入方式；
+5. `contentType`：观点、案例、方法、清单、深度或资讯；
+6. `emotion`：怕、怒、暖、敬、站队、搞懂，或更准确的自然语言；
+7. `sources`：研究包内的来源编号和待核实项；
+8. `origin`：hotspot、article、keywords 或 intent；
+9. `tags`：用于本地检索和内容归档的关键词。
+
+## 自动选择
+
+给角度按以下顺序比较，不必输出虚假精确分数：
+
+1. 证据能否支撑；
+2. 是否回答用户真正想写的问题；
+3. 是否给目标读者清晰收益；
+4. 是否有区别于现有内容的信息增量；
+5. 风险是否可控。
+
+第一名明确时自动选择。只有候选会让文章走向不同价值立场、面向不同受众或需要用户承担
+明显风险时，才设置 `awaiting-user`。措辞强弱、结构偏好和小范围选题修饰交给后续阶段
+自动处理。
+
+## 边界
+
+- 参考文章的作者立场不是用户立场。
+- 本地历史文章用于风格和既有观点一致性，不自动证明当前事实。
+- `[待核实]` 可以保留到审校，但不得在 Brief 中改写成已确认。
+- Brief 只定命题，不提前写大纲或正文。

package/skills/dxc-content-review/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: dxc-content-review
+description: DxC 内容工作流的审校步骤。由 dxc-content-workflow 在 quality-review 阶段调用，消费正文和已选标题，并可核对研究证据与视觉计划，检查事实、待补项、结构、标题承诺、作者、风格和当前微信公众号交付边界；通过时自动继续，只有阻断问题才暂停。
+---
+
+# DxC 内容审校
+
+本 Skill 只负责 `quality-review`。它产出可追溯报告，不在审校过程中静默改写已经确认的
+正文。
+
+## 进入阶段
+
+1. 运行 `dxc project status --json`，确认 `article` 与 `titles` 已完成。
+2. 完整读取
+   [../dxc-content-workflow/references/stage-contract.md](../dxc-content-workflow/references/stage-contract.md)
+   和 [references/review-checklist.md](references/review-checklist.md)。
+3. 研究包和视觉计划就绪且本次需要核对时一并读取。以实际输入写 `running` checkpoint：
+
+   ```text
+   dxc project checkpoint quality-review --status running \
+     --skill dxc-content-review --skill-version 0.3.0 \
+     --inputs research,article,titles,visual-plan \
+     --summary "正在核对事实、标题承诺、正文质量和交付边界" \
+     --execution-location agent-hosted --data-transit agent-provider --json
+   ```
+
+## 审校
+
+- 把问题分为 `blocker`、`warning`、`note`。只有会导致虚构、误导、身份错误、无法渲染或
+  用户明显不愿发布的问题才是 blocker。
+- 核对文章中的精确数据、引语、权威背书和时效性主张能否在研究包找到来源。
+- 检查 `[待补]`、大纲标记、内部自检、作者 `待确认` 等内部内容是否残留。
+- 检查已选标题是否不超过 32 个 Unicode 字符，并且每个承诺都能由正文兑现。
+- 检查摘要、正文、标题、语气和 Brief 是否一致；不把风格偏好上升为事实错误。
+- 核对视觉计划的素材清单与项目内实际 PNG/JPEG 是否一致，Markdown 本地引用是否可读、
+  正文图片是否单张小于 1 MiB、是否超过 20 张，以及正文图片和封面角色是否混淆。
+  远程图片仍不能直接进入交付。必须存在内容相关的 `cover.*`，且视觉计划中所有标为
+  “进入”的图片都已实际落盘；纯色占位图、提示词和建议图都不能通过审校。
+
+## 输出与状态
+
+写入 `artifacts/07-quality-review.md`：
+
+```markdown
+---
+dxc:
+  contract: dxc-content-stage@1
+  workflowId: dxc-article@1
+  projectId: <项目 UUID>
+  stage: quality-review
+  skill: dxc-content-review@0.3.0
+  createdAt: <ISO 8601>
+  artifactStatus: <complete|blocked>
+  inputs:
+    - kind: article
+      path: artifacts/04-article.md
+      sha256: <正文哈希>
+    - kind: titles
+      path: artifacts/05-titles.md
+      sha256: <标题哈希>
+verdict: <pass|block>
+blockerCount: <整数>
+warningCount: <整数>
+---
+
+# 内容审校
+
+## 结论
+
+## 阻断问题
+
+## 警告
+
+## 已通过项
+
+## 证据核对
+
+| 正文主张 | 来源 | 结论 |
+| -------- | ---- | ---- |
+```
+
+`verdict: pass` 时直接写 `completed`，返回总控进入交付；不要求用户确认“审校通过”。
+存在 blocker 时写 `awaiting-user`，在 `waitingFor` 中逐项说明需要用户提供来源、作者、
+删除哪条主张或允许怎样修改。解决正文或标题后，其哈希变化会让审校自动失效并重跑。

package/skills/dxc-content-review/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "DxC 内容审校"
+  short_description: "核对事实、标题承诺、真实视觉素材和交付边界，通过时自动继续"
+  default_prompt: "审校当前 DxC 文章，通过就继续，有阻断问题时只返回具体问题。"
+policy:
+  allow_implicit_invocation: false

package/skills/dxc-content-review/references/review-checklist.md

@@ -0,0 +1,35 @@
+# 内容审校清单
+
+## Blocker
+
+- 精确数据、引语、案例或权威背书没有来源，且正文把它写成事实；
+- 标题承诺正文无法兑现，或使用虚构数字、人物关系、热点关系；
+- 作者仍为“待确认”，正文仍有 `[待补]` 或内部大纲标记；
+- 标题超过 32 个 Unicode 字符；
+- 文章 frontmatter 无法被当前渲染器读取；
+- 正文包含远程图片、不可读本地图片、符号链接图片、非 PNG/JPEG、单张达到 1 MiB 或
+  超过 20 张正文图片；
+- 视觉计划声称已有配图，但对应素材文件缺失或素材清单与正文引用不一致；
+- 明显触及用户价值观红线、法律风险或安全边界。
+
+## Warning
+
+- 来源较旧、只有二手材料或立场单一；
+- 摘要、标题和正文重点轻微偏移；
+- 开头较慢、段落重复、术语未解释、行动建议太泛；
+- 内容封面构图或品牌一致性仍有改进空间，但已经是可交付的真实素材；
+- 语气和本地画像不完全一致，但不构成误导。
+
+## Pass
+
+- 核心问题得到回答；
+- 标题、摘要和正文互相兑现；
+- 内容相关封面已经落盘，视觉计划中标为“进入”的图片与实际文件及哈希一致；
+- 事实与观点已区分；
+- 数据和引语可追溯，待核实项没有伪装成事实；
+- 文章是干净的发布母稿；
+- 已选标题合法且唯一；
+- 当前交付能力、正文图片、封面来源与视觉声明一致。
+
+审校报告引用来源编号和哈希，不复制第三方全文。不要因为“可以写得更好”阻断发布；
+blocker 必须对应用户实际会看到的错误、误导或无法完成的交付。