@deployxai/dxc 0.1.13 → 0.2.0

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

@@ -1,71 +0,0 @@
----
-name: dxc-article-outline
-description: DxC 内容工作流的大纲步骤。由 dxc-content-workflow 在 outline 阶段调用，消费研究包和已收敛 Brief，按内容类型与情绪选择结构，并输出带钩子、情绪、金句、数据、案例和配图标记的可解析 Markdown 大纲。
----
-
-# DxC 文章大纲
-
-## 对用户的呈现
-
-用户只通过自然语言使用本 Skill。不要向用户展示 npm、CLI、PATH、PowerShell、Shell、JSON、内部命令或临时文件路径；只说明当前结果、需要用户做的选择，以及无法自动打开页面时的可点击临时链接。内部所有 CLI 调用都使用固定运行入口：Windows 为 `npm.cmd exec --yes --registry=https://registry.npmjs.org/ --package=@deployxai/dxc@0.1.13 -- dxc <参数>`，macOS/Linux 为相同参数的 `npm exec`。Windows 不得先尝试 npm 生成的无扩展名 `dxc`，同一任务后续必须保持已选入口；不得让用户打开终端、复制命令或处理环境变量。
-
-本 Skill 只负责 `outline`。大纲是正文和视觉计划共同读取的结构 contract。
-
-## 进入阶段
-
-1. 运行 `dxc project status --json`，确认 `research` 和 `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 \
-     --summary "正在选择文章结构并生成可解析大纲" \
-     --execution-location agent-hosted --data-transit agent-provider --json
-   ```
-
-   CLI 自动绑定研究包与 Brief，不传 `--inputs`。
-
-## 生成
-
-1. 从 Brief 提炼一句话主张、目标读者、内容类型和主情绪。
-2. 选择一个主结构，不为了显得复杂而混搭多个框架。
-3. 每节写清楚要点、情绪动作、证据或案例责任。
-4. 使用以下精确标记，不自创新拼写：
-   `[钩子]`、`[情绪:...]`、`[金句位:共鸣|观点|反讽]`、
-   `[数据位:...]`、`[案例位:...]`、`[配图:...]`。
-5. 开头前三行进入读者问题；结尾给明确收束或行动，不留空章节。
-
-## 输出
-
-写入 `artifacts/03-outline.md`：
-
-```markdown
----
-structure: <结构名称>
-primaryEmotion: <主情绪>
----
-
-# 文章大纲
-
-## 0. 开头 [钩子] [情绪:好奇]
-
-- 前三行：
-
-## 1. 第一节 [情绪:痛点] [配图:场景插画]
-
-- 核心要点：
-- [金句位:共鸣]
-
-## 2. 第二节 [情绪:搞懂]
-
-- [数据位:需要什么证据]
-
-## 3. 收束 [情绪:行动欲]
-
-- 行动：
-```
-
-通过结构、证据位和标记自检后直接写 `completed`，返回总控继续写正文。普通大纲不设置
-人工确认；用户之后直接编辑大纲时，哈希变化会让正文及下游阶段自动失效。

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

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

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

@@ -1,58 +0,0 @@
-# 大纲结构与标记
-
-## 专家方法来源
-
-- 原始方法真值是开发仓库 `docs/员工BCDE的skill/employee-c-outline-architect/SKILL.md`
-  的第 3–12 节；发布包不含原文，执行时以本胶囊为准。
-- 本胶囊承接情绪/传播要素判定、结构选型、C→D→E 标记 contract 与自检。DxC 只在此基础上
-  固定阶段产物路径、哈希和下游失效规则。
-
-## 结构选择
-
-| 内容与情绪           | 首选结构                             |
-| -------------------- | ------------------------------------ |
-| 怕、怒、问题需要解决 | PAS：痛点、放大、方案                |
-| 暖、敬、人物经历     | 目标、阻碍、努力、转折、结果         |
-| 站队、观点争议       | 痛点、新观点、正例、反例、价值、行动 |
-| 搞懂、认知升级       | SCQA：情境、冲突、问题、答案         |
-| 方法教程             | 问题、原则、方法、案例、清单         |
-| 专业论证             | 结论先行、分论点、证据               |
-| 深度叙事             | 起、承、转、合                       |
-
-只选最符合 Brief 的主结构。情绪型结构必须有出路，不能只放大焦虑。
-
-## 选型前的两项判定
-
-1. **情绪属性**：判断读者此刻是需要被理解、被说服、被解释、被推动还是被安放；情绪是
-   结构张力，不等于在每段标注情绪词。
-2. **传播要素**：判断本篇最需要的是认知反差、具体利益、故事共鸣、身份认同还是可执行
-   方法。它用于检查开头、核心论点和收束是否有记忆点，而不是制造标题党。
-
-选型后先写一句“读者从什么状态到什么状态”的结构承诺。若结构不能兑现这个变化，应换
-结构或收窄 Brief，而不是叠加多个框架。
-
-## 标记 contract
-
-| 标记              | 下游动作                                                                                         |
-| ----------------- | ------------------------------------------------------------------------------------------------ |
-| `[钩子]`          | 正文前三行直接进入冲突、问题或具体场景                                                           |
-| `[情绪:<类型>]`   | 类型可选痛点、放大、方案、好奇、愤怒、释然、满足、行动欲或搞懂                                   |
-| `[金句位:<类型>]` | 类型可选共鸣、观点或反讽；正文写一句可独立成立且服务当前段落的话                                 |
-| `[数据位:说明]`   | 只补有来源的数据，缺失时保留待核实                                                               |
-| `[案例位:说明]`   | 补真实、用户提供或明确脱敏的案例                                                                 |
-| `[配图:<类型>]`   | 类型可选思维导图、概念图、流程图、数据图、金句图、场景插画或氛围；视觉计划读取，不在正文直接插图 |
-
-标记必须位于相关章节内。不要把标记堆到文末。三层以上层级、概念关系、步骤、数据和金句
-分别是思维导图、概念图、流程图、数据图和金句图的信号。
-
-## 自检
-
-- 大纲是否回答 Brief 的核心问题；
-- 每节是否承担一个明确任务；
-- 证据与案例是否有放置位置；
-- 开头是否在前三行进入问题；
-- 情绪放大后是否有方案；
-- 金句和视觉锚点是否服务内容，而不是凑数量。
-- 结构是否把读者阻碍、转折、证据和行动放在恰当顺序，而非只罗列知识点；
-- 每个反例是否服务主张，结尾是否回收开头承诺；
-- 标记是否让 D 能写、E 能画，而不是留下不可执行的抽象词。

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

@@ -1,105 +0,0 @@
----
-name: dxc-article-write
-description: DxC 内容工作流的正文步骤。由 dxc-content-workflow 在 article 阶段调用，消费研究包、Brief 和可解析大纲，逐项落实钩子、情绪、金句、数据与案例，生成可直接进入微信公众号渲染的 Markdown 正文，并在最终正文采用前暂停一次。
----
-
-# DxC 正文写作
-
-## 对用户的呈现
-
-用户只通过自然语言使用本 Skill。不要向用户展示 npm、CLI、PATH、PowerShell、Shell、JSON、内部命令或临时文件路径；只说明当前结果、需要用户做的选择，以及无法自动打开页面时的可点击临时链接。内部所有 CLI 调用都使用固定运行入口：Windows 为 `npm.cmd exec --yes --registry=https://registry.npmjs.org/ --package=@deployxai/dxc@0.1.13 -- dxc <参数>`，macOS/Linux 为相同参数的 `npm exec`。Windows 不得先尝试 npm 生成的无扩展名 `dxc`，同一任务后续必须保持已选入口；不得让用户打开终端、复制命令或处理环境变量。
-
-本 Skill 只负责 `article`。正文必须是可发布母稿，不能把内部自检表、提示词或大纲标记
-混进最终正文。
-
-正文同时产生独立的 `artifacts/04-article.golden-lines.json`。它只保存本篇实际采用的金句：
-原句、所在章节与读者价值（认知压缩/情绪共鸣/行动推动/价值宣言）。原句必须逐字出现在正文；
-没有适合做图的金句时写空数组。正文 frontmatter 可以只写 `goldenLinesPath`；CLI 自动创建
-缺失的空 sidecar、计算 `goldenLinesSha256`，并校验文件与正文一致性。
-
-## 进入阶段
-
-1. 运行 `dxc project status --json`，确认 `research`、`brief` 和 `outline` 已就绪并全部读取。
-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 \
-     --summary "正在把 Brief 和大纲写成可发布正文" \
-     --execution-location agent-hosted --data-transit agent-provider --json
-   ```
-
-   CLI 自动绑定研究包、Brief 和大纲，不传 `--inputs`。
-
-## 写作
-
-- 逐项落实大纲标记，但删除所有 `[钩子]`、`[情绪:]`、`[金句位:]`、`[数据位:]`、
-  `[案例位:]` 和 `[配图:]` 标记。
-- 数据、引语和案例只能来自研究包、用户材料或可核验来源。不足时在正文中自然降级表述，
-  或保留明显的 `[待补：...]`；不得编造。
-- 使用具体名词和动词、短段落、对象感和真实细节。少用机械的“首先、其次、综上所述”。
-- 金句服务论证，不为押韵牺牲准确性。
-- 金句搜索结果只是候选，不能自动写入正文。采用本机金句库候选时，在 frontmatter 的
-  `dxc.quoteSnapshots` 记录当时的 `quoteId` 和 `contentSha256`；这使确认后的项目固定引用
-  快照，不会被金句文件之后的编辑回写。
-- `origin: third-party` 的候选必须保留 `attribution`。只有 `verbatimUse: permitted` 且来源
-  可核验时才可逐字引用；`needs-verification` 或 `do-not-use-verbatim` 只能作为待核验线索或
-  改写灵感，不能冒充原话。原创候选也仍须由用户确认其归属。
-- 正文 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>
-goldenLinesPath: artifacts/04-article.golden-lines.json
-tags: [<标签>]
-quoteSnapshots:
-  - quoteId: <实际采用的金句 UUID；未采用则为空数组>
-    contentSha256: <采用当时的金句哈希>
----
-
-# 工作标题
-
-正文……
-```
-
-对应 sidecar：
-
-```json
-{
-  "schemaVersion": "dxc-golden-lines@1",
-  "lines": [
-    { "text": "不要用忙碌代替推进。", "section": "第二节", "purpose": "cognitive-compression" }
-  ]
-}
-```
-
-读取 `dxc profile status --json` 的 `user.confirmationPolicy`。除非它明确为
-`auto-until-delivery`，完成自检后把 checkpoint 写为 `awaiting-user`，`waitingFor` 必须具体：
-“正文已经生成。请确认是否采用这版正文；若作者仍为待确认，请同时给出作者名。”
-这里的根级 `quoteSnapshots` 是便于 Agent 写入的兼容输入；CLI 会把它迁入
-`dxc.quoteSnapshots`，并生成其余机器元数据。用户只做明确确认且正文可见内容未变化时，
-直接写 `completed --confirm`，CLI 自动把产物状态改为 `complete`。用户提出修改时，先更新正文并重新写一次 `awaiting-user`
-检查点、展示修改后的内容；只有用户确认这个新内容快照后才能完成。不要把一句模糊的
-“继续”解释为正文确认，也不得把修改后的新正文直接绑定到旧确认。
-
-`auto-until-delivery` 时，正文仍须通过相同的事实、作者和发布格式自检，但可直接写
-`completed` checkpoint；这不是创建草稿的授权，交付阶段仍须
-展示不可变预览并取得明确确认。

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

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

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

@@ -1,62 +0,0 @@
-# 正文写作方法
-
-## 专家方法来源
-
-- 原始方法真值是开发仓库 `docs/员工BCDE的skill/employee-d-content-writer/SKILL.md`
-  的第 3–14 节；发布包不含原文，执行时以本胶囊为准。
-- 本胶囊承接同理心、逻辑势能、观点聚焦、故事、自然表达、金句和质检；DxC 额外约束
-  事实来源、阶段确认和微信发布母稿格式。
-
-## 对象感
-
-- 想象一个具体读者和具体阅读场景，直接回答他此刻的问题。
-- 多用“你”和具体场景，少用“大家都知道”。
-- 抽象概念用真实例子、类比或动作细节翻译。
-- 每节至少提供情绪价值、认知增量或可执行方法中的一种。
-
-## 论证与表达
-
-- 先说清本段要让读者相信、感受或做到什么，再选事实、场景、类比或行动建议支撑；不要
-  用华丽形容词代替论证。
-- 一个中心观点只保留一条最强论证线。需要强化记忆时可用对比、重新定义、反转或具体化，
-  但不能同时堆叠四种技法。
-- 故事至少交代人物、处境、动作与结果；案例匿名或合成时必须明示，不把推测写成真实经历。
-- 词语要与作者身份、读者知识和情绪强度相称。避免居高临下、过度承诺、空泛鸡汤和模板化
-  AI 连接词；朗读后删去不自然的重复。
-
-## 大纲标记落实
-
-| 大纲标记  | 正文动作                                 |
-| --------- | ---------------------------------------- |
-| 钩子      | 前三行进入冲突、痛点、问题或反常识结论   |
-| 痛点/放大 | 写具体后果，但随后必须给方案             |
-| 好奇/搞懂 | 设问后及时回答，不制造空悬念             |
-| 释然/满足 | 给可相信的收束，不灌鸡汤                 |
-| 行动欲    | 给低门槛、可执行的下一步                 |
-| 金句位    | 写短、准、可独立成立且不偏离主题的句子   |
-| 数据位    | 有来源才写精确数字；否则降级或待补       |
-| 案例位    | 人物、冲突、动作和结果必须真实或明确脱敏 |
-
-## 自然写作
-
-- 一段一意，长句拆短，优先具体名词和动词；
-- 删除空洞形容词、重复结论和模板化过渡；
-- 不堆排比，不机械套所有写作框架；
-- 朗读检查节奏，保留适量口语和停顿；
-- 不虚构名人语录、权威背书、数据、案例或热点关系。
-
-## 金句
-
-先确定句子承担认知压缩、情绪共鸣、行动推动或价值宣言中的哪一个功能，再选择对比、
-反转、比喻、对仗或重新定义。朗读后压缩到不能再删。金句必须能从正文论证中推出。
-
-合格金句同时满足准确、具体、可独立理解和与上下文相互支撑；不能为了押韵、反转或传播
-感把复杂事实说成绝对结论。正文完成后按“删空话、补证据、调顺序、核承诺”做一次改稿。
-
-## 发布母稿
-
-- YAML frontmatter 之后只放会进入微信正文的内容；
-- 不附加自检表、风险报告、金句清单或内部提示；
-- 不保留大纲标记；
-- `digest`、标题承诺和正文结论一致；
-- 作者、待补项和事实风险在确认前显式列出。

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

@@ -1,72 +0,0 @@
----
-name: dxc-content-brief
-description: DxC 内容工作流的 Brief 步骤。由 dxc-content-workflow 在 brief 阶段调用，消费 research 研究包，把主题、核心问题、受众、角度、内容类型、情绪、来源、来源类型和标签收敛为统一九字段命题；只有多个立场会实质改变文章时才暂停让用户选择。
----
-
-# DxC 内容 Brief
-
-## 对用户的呈现
-
-用户只通过自然语言使用本 Skill。不要向用户展示 npm、CLI、PATH、PowerShell、Shell、JSON、内部命令或临时文件路径；只说明当前结果、需要用户做的选择，以及无法自动打开页面时的可点击临时链接。内部所有 CLI 调用都使用固定运行入口：Windows 为 `npm.cmd exec --yes --registry=https://registry.npmjs.org/ --package=@deployxai/dxc@0.1.13 -- dxc <参数>`，macOS/Linux 为相同参数的 `npm exec`。Windows 不得先尝试 npm 生成的无扩展名 `dxc`，同一任务后续必须保持已选入口；不得让用户打开终端、复制命令或处理环境变量。
-
-本 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 \
-     --summary "正在把研究证据收敛为九字段内容 Brief" \
-     --execution-location agent-hosted --data-transit agent-provider --json
-   ```
-
-   若本次实际完全在本机处理，按真实情况改执行位置和数据去向。
-
-## 收敛规则
-
-- 读取完整研究包；画像已配置时读取 `dxc profile status --json`，未配置则只用当前项目
-  已知信息，不重新启动问卷。
-- 九个字段必须齐全；未知值写清楚“待确认”或“无”，不把推测写成事实。
-- 对角度候选按证据充分度、用户意图匹配、信息增量和风险排序。
-- 一个角度明显占优时自动选定并保留备选理由，直接完成。
-- 两个以上角度在立场、受众承诺或风险上实质不同且无法从上下文判断时，才等待用户。
-
-## 输出与确认
-
-写入 `artifacts/02-brief.md`：
-
-```markdown
----
-origin: <hotspot|article|keywords|intent>
-selectedAngle: <已选角度或 null>
----
-
-# 内容 Brief
-
-- 主题：
-- 核心问题：
-- 目标受众：
-- 选定角度：
-- 内容类型：
-- 情绪预判：
-- 来源指针：
-- 来源类型：
-- 标签：
-
-## 角度决策
-
-- 已选：
-- 备选：
-- 选择理由：
-- 风险：
-```
-
-能够唯一收敛时写 `completed` 并立即返回总控。需要用户站队时写 `awaiting-user`，例如：
-“A 侧重反驳行业常识，B 侧重提供中立方法，两者会产生不同文章。请选择 A 或 B。”
-用户明确回答后更新 `selectedAngle` 和选择理由，再写 `completed --confirm`；CLI 自动更新
-机器状态。不要要求用户确认九个字段的每个细节。

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

@@ -1,6 +0,0 @@
-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

@@ -1,52 +0,0 @@
-# Brief 收敛方法
-
-## 专家方法来源
-
-- 原始方法真值是开发仓库 `docs/员工BCDE的skill/employee-b-research-analyst/SKILL.md`
-  的第 3、5、7、9–11 节；发布包不含原文，执行时以本胶囊为准。
-- 本胶囊把研究阶段的四类输入和角度光谱压缩为可供 C/D/E 消费的九字段命题；它不替代
-  研究包，也不提前决定文章结构或措辞。
-
-## 九字段
-
-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`。措辞强弱、结构偏好和小范围选题修饰交给后续阶段
-自动处理。
-
-## 九字段的可用标准
-
-- `topic` 说明文章对象与边界；`coreQuestion` 必须是正文能够回答的问题，而不是“介绍一下”。
-- `audience` 写明读者处境、已有认知或要完成的动作；`angle` 用完整、可辩护的主张表达。
-- `contentType` 与 `emotion` 共同决定后续结构，但情绪只能描述读者体验或文章张力，不能
-  代替事实结论。
-- `sources` 区分可直接引用、只作背景和仍待核实的来源；`tags` 只用于检索与归档，不能伪装
-  成 SEO 承诺。
-- 生成 3–5 个角度时，要覆盖延续、反向、辩证或跨界中的真实分歧；不存在真实分歧时，不
-  为凑数量要求用户选择。
-
-## 边界
-
-- 参考文章的作者立场不是用户立场。
-- 本地历史文章用于风格和既有观点一致性，不自动证明当前事实。
-- `[待核实]` 可以保留到审校，但不得在 Brief 中改写成已确认。
-- Brief 只定命题，不提前写大纲或正文。

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

@@ -1,82 +0,0 @@
----
-name: dxc-content-review
-description: DxC 内容工作流的审校步骤。由 dxc-content-workflow 在 quality-review 阶段调用，消费研究包、正文和已选标题，并可核对视觉计划，检查研究覆盖、事实、待补项、结构、标题承诺、作者、风格和当前微信公众号交付边界；通过时自动继续，只有阻断问题才暂停。
----
-
-# DxC 内容审校
-
-## 对用户的呈现
-
-用户只通过自然语言使用本 Skill。不要向用户展示 npm、CLI、PATH、PowerShell、Shell、JSON、内部命令或临时文件路径；只说明当前结果、需要用户做的选择，以及无法自动打开页面时的可点击临时链接。内部所有 CLI 调用都使用固定运行入口：Windows 为 `npm.cmd exec --yes --registry=https://registry.npmjs.org/ --package=@deployxai/dxc@0.1.13 -- dxc <参数>`，macOS/Linux 为相同参数的 `npm exec`。Windows 不得先尝试 npm 生成的无扩展名 `dxc`，同一任务后续必须保持已选入口；不得让用户打开终端、复制命令或处理环境变量。
-
-本 Skill 只负责 `quality-review`。它产出可追溯报告，不在审校过程中静默改写已经确认的
-正文。
-
-## 进入阶段
-
-1. 运行 `dxc project status --json`，确认 `research`、`article` 与 `titles` 已完成。只有受控
-   接管用户已有正文时，`research` 才可以是总控记录的 `skipped`。
-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 \
-     --summary "正在核对事实、标题承诺、正文质量和交付边界" \
-     --execution-location agent-hosted --data-transit agent-provider --json
-   ```
-
-   CLI 自动绑定研究包、正文和标题；本次确实读取视觉计划时才用 `--inputs visual-plan`。
-   受控接管已有正文时，CLI 会识别已跳过的研究阶段，审校报告必须把研究覆盖记为
-   `not-applicable`，不得声称事实已经过研究核验。
-
-## 审校
-
-- 把问题分为 `blocker`、`warning`、`note`。只有会导致虚构、误导、身份错误、无法渲染或
-  用户明显不愿发布的问题才是 blocker。
-- 核对文章中的精确数据、引语、权威背书和时效性主张能否在研究包找到来源。
-- 检查 `[待补]`、大纲标记、内部自检、作者 `待确认` 等内部内容是否残留。
-- 检查已选标题是否不超过 32 个 Unicode 字符，并且每个承诺都能由正文兑现。
-- 检查摘要、正文、标题、语气和 Brief 是否一致；不把风格偏好上升为事实错误。
-- 核对正文 frontmatter 的 `goldenLinesPath` 和 `goldenLinesSha256`：sidecar 的每条原句必须逐字
-  出现在正文；视觉计划若使用金句图，只能从该 sidecar 选择，不得自行改写或补造。
-- 核对视觉计划的素材清单与项目内实际 PNG/JPEG 是否一致，Markdown 本地引用是否可读、
-  正文图片是否单张小于 1 MiB、是否超过 20 张，以及正文图片和封面角色是否混淆。
-  远程图片仍不能直接进入交付。必须存在内容相关的 `cover.*`，且视觉计划中所有标为
-  “进入”的图片都已实际落盘；纯色占位图、提示词和建议图都不能通过审校。
-
-## 输出与状态
-
-写入 `artifacts/07-quality-review.md`：
-
-```markdown
----
-verdict: <pass|block>
-blockerCount: <整数>
-warningCount: <整数>
-researchCoverage: <pass|warning|not-applicable>
----
-
-# 内容审校
-
-## 结论
-
-## 阻断问题
-
-## 警告
-
-## 已通过项
-
-## 证据核对
-
-| 正文主张 | 来源 | 结论 |
-| -------- | ---- | ---- |
-```
-
-热点研究由用户明确跳过外部观点拆解时，`researchCoverage` 必须是 `warning` 且至少计入一条
-warning；研究完整时为 `pass`，受控接管已有正文且研究已跳过时为 `not-applicable`。
-`verdict: pass` 时直接写 `completed`，返回总控进入交付；不要求用户确认“审校通过”。
-存在 blocker 时写 `awaiting-user`，在 `waitingFor` 中逐项说明需要用户提供来源、作者、
-删除哪条主张或允许怎样修改。解决正文或标题后，其哈希变化会让审校自动失效并重跑。

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

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

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

@@ -1,52 +0,0 @@
-# 内容审校清单
-
-## 专家方法来源
-
-- 汇总员工 B 的事实/立场、员工 C 的结构、员工 D 的正文和员工 E 的标题/视觉质检项。
-- 原始方法真值分别位于 `docs/员工BCDE的skill/employee-{b,c,d,e}-*/SKILL.md` 的质量检查
-  章节；本胶囊只保留会影响真实交付、误导风险或用户发布决策的规则。
-
-## Blocker
-
-- 精确数据、引语、案例或权威背书没有来源，且正文把它写成事实；
-- 标题承诺正文无法兑现，或使用虚构数字、人物关系、热点关系；
-- 作者仍为“待确认”，正文仍有 `[待补]` 或内部大纲标记；
-- 标题超过 32 个 Unicode 字符；
-- 文章 frontmatter 无法被当前渲染器读取；
-- 正文包含远程图片、不可读本地图片、符号链接图片、非 PNG/JPEG、单张达到 1 MiB 或
-  超过 20 张正文图片；
-- 视觉计划声称已有配图，但对应素材文件缺失或素材清单与正文引用不一致；
-- 明显触及用户价值观红线、法律风险或安全边界。
-
-## Warning
-
-- 来源较旧、只有二手材料或立场单一；
-- 摘要、标题和正文重点轻微偏移；
-- 开头较慢、段落重复、术语未解释、行动建议太泛；
-- 内容封面构图或品牌一致性仍有改进空间，但已经是可交付的真实素材；
-- 语气和本地画像不完全一致，但不构成误导。
-
-## Pass
-
-- 核心问题得到回答；
-- 标题、摘要和正文互相兑现；
-- 内容相关封面已经落盘，视觉计划中标为“进入”的图片与实际文件及哈希一致；
-- 事实与观点已区分；
-- 数据和引语可追溯，待核实项没有伪装成事实；
-- 文章是干净的发布母稿；
-- 已选标题合法且唯一；
-- 当前交付能力、正文图片、封面来源与视觉声明一致。
-
-## 专家质量复核
-
-- **B**：研究包把事实、观点、反方材料和待核实项分开；选择的角度没有越过用户价值红线。
-- **C**：结构回答 Brief 的核心问题，开头承诺、证据、反例和结尾行动构成完整闭环。
-- **D**：正文对具体读者有对象感，金句能由论证推出，案例、数据和引语不存在伪造或不明示
-  的合成。
-- **E**：标题提供真实点击理由，封面和正文图服务阅读理解并与博主既有视觉边界一致。
-
-这些项有改进空间时通常是 warning；只有它们造成事实错误、明显误导、无法交付或触犯用户
-明确红线时才升级为 blocker。
-
-审校报告引用来源编号和哈希，不复制第三方全文。不要因为“可以写得更好”阻断发布；
-blocker 必须对应用户实际会看到的错误、误导或无法完成的交付。