@deployxai/dxc 0.1.13 → 0.2.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@deployxai/dxc",
-  "version": "0.1.13",
+  "version": "0.2.1",
   "description": "DeployX 内容工作台 CLI 与官方 Skills",
   "type": "module",
   "bin": {

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

@@ -1,71 +1,28 @@
 ---
 name: dxc-article-outline
-description: DxC 内容工作流的大纲步骤。由 dxc-content-workflow 在 outline 阶段调用，消费研究包和已收敛 Brief，按内容类型与情绪选择结构，并输出带钩子、情绪、金句、数据、案例和配图标记的可解析 Markdown 大纲。
+description: 为 DxC 文章完成大纲阶段，把 Brief、研究材料或用户已有构思组织为可直接写作的章节结构。用户要求列大纲、重构文章结构，或 dxc-content-workflow 返回 outline 阶段时使用；可以作为八步工作流的独立起点。
 ---
 
 # 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。
+内部固定使用 `@deployxai/dxc@0.2.1`；Windows 通过 `npm.cmd exec`，macOS/Linux 通过 `npm exec`
+运行，不切换到 PATH 中的其他版本。
 
 ## 进入阶段
 
-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. 第一节 [情绪:痛点] [配图:场景插画]
-
-- 核心要点：
-- [金句位:共鸣]
+- 总控返回 `step: outline` 时，读取 CLI 返回且真实存在的输入。
+- 直接从大纲开始或重新进入已有项目时，调用：
 
-## 2. 第二节 [情绪:搞懂]
+  ```text
+  dxc workflow start --from outline --title "<主题>" --directory "<项目目录>" --json
+  ```
 
-- [数据位:需要什么证据]
+  已有项目可省略 `--title`；用户在对话中给出的 Brief 或材料可以直接使用。
 
-## 3. 收束 [情绪:行动欲]
+- 只使用本页列出的 workflow 领域命令。
 
-- 行动：
-```
+## 生成大纲
 
-通过结构、证据位和标记自检后直接写 `completed`，返回总控继续写正文。普通大纲不设置
-人工确认；用户之后直接编辑大纲时，哈希变化会让正文及下游阶段自动失效。
+完整读取 [references/outline-methods.md](references/outline-methods.md)，选择一个最适合当前内容的主结构。
+每节写清目标、论点、证据责任和承接关系，避免为显得复杂而混搭框架。把结果写入 CLI 返回的
+`output`，再调用 `dxc workflow complete --directory "<项目目录>" --json`。

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

@@ -1,6 +1,6 @@
 interface:
   display_name: "DxC 文章大纲"
-  short_description: "把 Brief 变成带情绪、证据、金句和配图锚点的可解析大纲"
-  default_prompt: "为当前 DxC 项目生成结构化大纲，完成后返回总控继续。"
+  short_description: "把命题和现有材料组织成可直接写作、层次清晰的文章结构"
+  default_prompt: "使用 $dxc-article-outline 从现有材料形成清晰、无重复的文章大纲。"
 policy:
   allow_implicit_invocation: false

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

@@ -4,8 +4,7 @@
 
 - 原始方法真值是开发仓库 `docs/员工BCDE的skill/employee-c-outline-architect/SKILL.md`
   的第 3–12 节；发布包不含原文，执行时以本胶囊为准。
-- 本胶囊承接情绪/传播要素判定、结构选型、C→D→E 标记 contract 与自检。DxC 只在此基础上
-  固定阶段产物路径、哈希和下游失效规则。
+- 本胶囊承接情绪/传播要素判定、结构选型、C→D→E 标记和自检。产物路径与进度由 CLI 统一处理。
 
 ## 结构选择
 

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

@@ -1,105 +1,29 @@
 ---
 name: dxc-article-write
-description: DxC 内容工作流的正文步骤。由 dxc-content-workflow 在 article 阶段调用，消费研究包、Brief 和可解析大纲，逐项落实钩子、情绪、金句、数据与案例，生成可直接进入微信公众号渲染的 Markdown 正文，并在最终正文采用前暂停一次。
+description: 为 DxC 项目撰写或改写完整 Markdown 正文。用户要求从已有选题、大纲或材料直接写文章、重写正文，或 dxc-content-workflow 返回 article 阶段时使用；可以作为八步工作流的独立起点。
 ---
 
 # 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`，并校验文件与正文一致性。
+内部固定使用 `@deployxai/dxc@0.2.1`；Windows 通过 `npm.cmd exec`，macOS/Linux 通过 `npm exec`
+运行，不切换到 PATH 中的其他版本。
 
 ## 进入阶段
 
-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
-   ```
+- 总控返回 `step: article` 时，读取 CLI 返回且真实存在的输入文件。
+- 直接从正文开始或重新进入已有项目时，调用：
 
-   CLI 自动绑定研究包、Brief 和大纲，不传 `--inputs`。
+  ```text
+  dxc workflow start --from article --title "<主题>" --directory "<项目目录>" --json
+  ```
 
-## 写作
-
-- 逐项落实大纲标记，但删除所有 `[钩子]`、`[情绪:]`、`[金句位:]`、`[数据位:]`、
-  `[案例位:]` 和 `[配图:]` 标记。
-- 数据、引语和案例只能来自研究包、用户材料或可核验来源。不足时在正文中自然降级表述，
-  或保留明显的 `[待补：...]`；不得编造。
-- 使用具体名词和动词、短段落、对象感和真实细节。少用机械的“首先、其次、综上所述”。
-- 金句服务论证，不为押韵牺牲准确性。
-- 金句搜索结果只是候选，不能自动写入正文。采用本机金句库候选时，在 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`。预览页
-  的用户选择始终覆盖该建议。
+  已有项目可省略 `--title`。用户给出的文章、大纲或素材可直接作为当前输入。
 
-## 输出与最终正文确认
+- 只使用本页列出的 workflow 领域命令。
 
-写入 `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；这不是创建草稿的授权，交付阶段仍须
-展示不可变预览并取得明确确认。
+完整读取 [references/writing-methods.md](references/writing-methods.md)，根据当前材料选择适合的写法。
+正文至少包含 `title`、`author`、`digest` frontmatter（头部元数据）和完整 Markdown 内容。不要留下
+大纲标记、内部自检或虚构引语。把正文写入 CLI 返回的 `output`，自行完成本阶段质量检查，然后调用
+`dxc workflow complete --directory "<项目目录>" --json`。正文完成后不增加一次采用确认。

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

@@ -1,6 +1,6 @@
 interface:
   display_name: "DxC 正文写作"
-  short_description: "按 Brief 和大纲生成可发布正文，在最终采用前暂停一次"
-  default_prompt: "为当前 DxC 项目完成正文，并返回最终正文确认问题。"
+  short_description: "从已有选题、大纲或材料直接写成完整 Markdown 正文"
+  default_prompt: "使用 $dxc-article-write 根据我给出的材料直接写成完整文章。"
 policy:
   allow_implicit_invocation: false

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

@@ -5,7 +5,7 @@
 - 原始方法真值是开发仓库 `docs/员工BCDE的skill/employee-d-content-writer/SKILL.md`
   的第 3–14 节；发布包不含原文，执行时以本胶囊为准。
 - 本胶囊承接同理心、逻辑势能、观点聚焦、故事、自然表达、金句和质检；DxC 额外约束
-  事实来源、阶段确认和微信发布母稿格式。
+  事实来源和微信发布母稿格式。
 
 ## 对象感
 
@@ -59,4 +59,4 @@
 - 不附加自检表、风险报告、金句清单或内部提示；
 - 不保留大纲标记；
 - `digest`、标题承诺和正文结论一致；
-- 作者、待补项和事实风险在确认前显式列出。
+- 作者、待补项和事实风险在交付前解决或显式列出。

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

@@ -1,72 +1,33 @@
 ---
 name: dxc-content-brief
-description: DxC 内容工作流的 Brief 步骤。由 dxc-content-workflow 在 brief 阶段调用，消费 research 研究包，把主题、核心问题、受众、角度、内容类型、情绪、来源、来源类型和标签收敛为统一九字段命题；只有多个立场会实质改变文章时才暂停让用户选择。
+description: 为 DxC 文章完成 Brief 阶段，把已有研究或用户给出的材料收敛为主题、核心问题、受众、角度、内容类型、情绪、来源、来源类型和标签。用户要求明确文章命题、内容 Brief 或定位，或 dxc-content-workflow 返回 brief 阶段时使用；可以作为八步工作流的独立起点。
 ---
 
 # 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`，把研究结果收敛为下游共同使用的单一命题。
+内部固定使用 `@deployxai/dxc@0.2.1`；Windows 通过 `npm.cmd exec`，macOS/Linux 通过 `npm exec`
+运行，不切换到 PATH 中的其他版本。
 
 ## 进入阶段
 
-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
-   ```
-
-   若本次实际完全在本机处理，按真实情况改执行位置和数据去向。
-
-## 收敛规则
+- 总控返回 `step: brief` 时，读取 CLI 给出的、真实存在的输入文件。
+- 直接从 Brief 开始或重新进入已有项目时，调用：
 
-- 读取完整研究包；画像已配置时读取 `dxc profile status --json`，未配置则只用当前项目
-  已知信息，不重新启动问卷。
-- 九个字段必须齐全；未知值写清楚“待确认”或“无”，不把推测写成事实。
-- 对角度候选按证据充分度、用户意图匹配、信息增量和风险排序。
-- 一个角度明显占优时自动选定并保留备选理由，直接完成。
-- 两个以上角度在立场、受众承诺或风险上实质不同且无法从上下文判断时，才等待用户。
+  ```text
+  dxc workflow start --from brief --title "<主题>" --directory "<项目目录>" --json
+  ```
 
-## 输出与确认
-
-写入 `artifacts/02-brief.md`：
-
-```markdown
----
-origin: <hotspot|article|keywords|intent>
-selectedAngle: <已选角度或 null>
----
+  已有项目可省略 `--title`。用户已经在对话中提供的研究材料也可直接作为输入。
 
-# 内容 Brief
+- 只使用本页列出的 workflow 领域命令。
 
-- 主题：
-- 核心问题：
-- 目标受众：
-- 选定角度：
-- 内容类型：
-- 情绪预判：
-- 来源指针：
-- 来源类型：
-- 标签：
+## 生成 Brief
 
-## 角度决策
+完整读取 [references/brief-method.md](references/brief-method.md)，然后：
 
-- 已选：
-- 备选：
-- 选择理由：
-- 风险：
-```
+1. 根据证据充分度、用户意图、读者收益、信息增量和风险选择最合适的角度。
+2. 写齐九个字段；未知项标明未知，不把推测写成事实。
+3. 把 Brief 写入 CLI 返回的 `output`。
+4. 调用 `dxc workflow complete --directory "<项目目录>" --json` 返回下一阶段。
 
-能够唯一收敛时写 `completed` 并立即返回总控。需要用户站队时写 `awaiting-user`，例如：
-“A 侧重反驳行业常识，B 侧重提供中立方法，两者会产生不同文章。请选择 A 或 B。”
-用户明确回答后更新 `selectedAngle` 和选择理由，再写 `completed --confirm`；CLI 自动更新
-机器状态。不要要求用户确认九个字段的每个细节。
+普通角度取舍由本阶段完成，不逐字段向用户确认。

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

@@ -1,6 +1,6 @@
 interface:
   display_name: "DxC 内容 Brief"
-  short_description: "把研究包收敛为统一九字段命题，只在真实立场分叉时暂停"
-  default_prompt: "为当前 DxC 项目收敛 Brief，能自动决定就继续，不能时返回具体选择。"
+  short_description: "把研究或现有材料收敛为清晰、可写作、可检验的文章命题"
+  default_prompt: "使用 $dxc-content-brief 为这篇文章确定命题、读者、角度和证据要求。"
 policy:
   allow_implicit_invocation: false

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

@@ -29,9 +29,9 @@
 4. 是否有区别于现有内容的信息增量；
 5. 风险是否可控。
 
-第一名明确时自动选择。只有候选会让文章走向不同价值立场、面向不同受众或需要用户承担
-明显风险时，才设置 `awaiting-user`。措辞强弱、结构偏好和小范围选题修饰交给后续阶段
-自动处理。
+选择综合判断最优的一项，并在产物里保留取舍理由。不同价值立场、受众或风险无法由现有上下文
+判断时，优先选择不越过用户明确红线、证据更充分的一项并标注假设；措辞强弱、结构偏好和
+小范围选题修饰交给后续阶段处理。
 
 ## 九字段的可用标准
 

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

@@ -1,82 +1,35 @@
 ---
 name: dxc-content-review
-description: DxC 内容工作流的审校步骤。由 dxc-content-workflow 在 quality-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`。它产出可追溯报告，不在审校过程中静默改写已经确认的
-正文。
+内部固定使用 `@deployxai/dxc@0.2.1`；Windows 通过 `npm.cmd exec`，macOS/Linux 通过 `npm exec`
+运行，不切换到 PATH 中的其他版本。
 
 ## 进入阶段
 
-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：
+- 总控返回 `step: quality-review` 时，读取 CLI 返回且真实存在的正文、标题、研究和可选视觉计划。
+- 直接从审校开始或重新进入已有项目时，调用：
 
-   ```text
-   dxc project checkpoint quality-review --status running \
-     --summary "正在核对事实、标题承诺、正文质量和交付边界" \
-     --execution-location agent-hosted --data-transit agent-provider --json
-   ```
+  ```text
+  dxc workflow start --from quality-review --title "<主题>" --directory "<项目目录>" --json
+  ```
 
-   CLI 自动绑定研究包、正文和标题；本次确实读取视觉计划时才用 `--inputs visual-plan`。
-   受控接管已有正文时，CLI 会识别已跳过的研究阶段，审校报告必须把研究覆盖记为
-   `not-applicable`，不得声称事实已经过研究核验。
+  已有项目可省略 `--title`。只使用本页列出的 workflow 领域命令。
 
 ## 审校
 
-- 把问题分为 `blocker`、`warning`、`note`。只有会导致虚构、误导、身份错误、无法渲染或
-  用户明显不愿发布的问题才是 blocker。
-- 核对文章中的精确数据、引语、权威背书和时效性主张能否在研究包找到来源。
-- 检查 `[待补]`、大纲标记、内部自检、作者 `待确认` 等内部内容是否残留。
-- 检查已选标题是否不超过 32 个 Unicode 字符，并且每个承诺都能由正文兑现。
-- 检查摘要、正文、标题、语气和 Brief 是否一致；不把风格偏好上升为事实错误。
-- 核对正文 frontmatter 的 `goldenLinesPath` 和 `goldenLinesSha256`：sidecar 的每条原句必须逐字
-  出现在正文；视觉计划若使用金句图，只能从该 sidecar 选择，不得自行改写或补造。
-- 核对视觉计划的素材清单与项目内实际 PNG/JPEG 是否一致，Markdown 本地引用是否可读、
-  正文图片是否单张小于 1 MiB、是否超过 20 张，以及正文图片和封面角色是否混淆。
-  远程图片仍不能直接进入交付。必须存在内容相关的 `cover.*`，且视觉计划中所有标为
-  “进入”的图片都已实际落盘；纯色占位图、提示词和建议图都不能通过审校。
-
-## 输出与状态
-
-写入 `artifacts/07-quality-review.md`：
+完整读取 [references/review-checklist.md](references/review-checklist.md)。一次性检查并直接修复能够可靠修复的
+问题；不要把风格偏好升级为阻断。事实缺失、身份错误或无法交付的问题不能靠猜测修复时，清楚列出
+问题并保留 `verdict: block`。通过时写入：
 
 ```markdown
 ---
-verdict: <pass|block>
-blockerCount: <整数>
-warningCount: <整数>
-researchCoverage: <pass|warning|not-applicable>
+verdict: pass
 ---
-
-# 内容审校
-
-## 结论
-
-## 阻断问题
-
-## 警告
-
-## 已通过项
-
-## 证据核对
-
-| 正文主张 | 来源 | 结论 |
-| -------- | ---- | ---- |
 ```
 
-热点研究由用户明确跳过外部观点拆解时，`researchCoverage` 必须是 `warning` 且至少计入一条
-warning；研究完整时为 `pass`，受控接管已有正文且研究已跳过时为 `not-applicable`。
-`verdict: pass` 时直接写 `completed`，返回总控进入交付；不要求用户确认“审校通过”。
-存在 blocker 时写 `awaiting-user`，在 `waitingFor` 中逐项说明需要用户提供来源、作者、
-删除哪条主张或允许怎样修改。解决正文或标题后，其哈希变化会让审校自动失效并重跑。
+把报告写入 CLI 返回的 `output`。通过后调用
+`dxc workflow complete --directory "<项目目录>" --json`；审校通过不要求用户确认。

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

@@ -1,6 +1,6 @@
 interface:
   display_name: "DxC 内容审校"
-  short_description: "核对事实、标题承诺、真实视觉素材和交付边界，通过时自动继续"
-  default_prompt: "审校当前 DxC 文章，通过就继续，有阻断问题时只返回具体问题。"
+  short_description: "对已有文章做一次交付前的事实、结构、标题、摘要和视觉检查"
+  default_prompt: "使用 $dxc-content-review 审校这篇文章，修复问题并给出交付结论。"
 policy:
   allow_implicit_invocation: false

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

@@ -13,8 +13,7 @@
 - 作者仍为“待确认”，正文仍有 `[待补]` 或内部大纲标记；
 - 标题超过 32 个 Unicode 字符；
 - 文章 frontmatter 无法被当前渲染器读取；
-- 正文包含远程图片、不可读本地图片、符号链接图片、非 PNG/JPEG、单张达到 1 MiB 或
-  超过 20 张正文图片；
+- 正文包含远程图片、不可读本地图片、符号链接图片、非 PNG/JPEG，或超过 20 张正文图片；
 - 视觉计划声称已有配图，但对应素材文件缺失或素材清单与正文引用不一致；
 - 明显触及用户价值观红线、法律风险或安全边界。
 
@@ -30,7 +29,7 @@
 
 - 核心问题得到回答；
 - 标题、摘要和正文互相兑现；
-- 内容相关封面已经落盘，视觉计划中标为“进入”的图片与实际文件及哈希一致；
+- 内容相关封面已经落盘，视觉计划中标为“进入”的图片与实际文件一致；
 - 事实与观点已区分；
 - 数据和引语可追溯，待核实项没有伪装成事实；
 - 文章是干净的发布母稿；
@@ -48,5 +47,5 @@
 这些项有改进空间时通常是 warning；只有它们造成事实错误、明显误导、无法交付或触犯用户
 明确红线时才升级为 blocker。
 
-审校报告引用来源编号和哈希，不复制第三方全文。不要因为“可以写得更好”阻断发布；
+审校报告引用来源编号，不复制第三方全文。不要因为“可以写得更好”阻断发布；
 blocker 必须对应用户实际会看到的错误、误导或无法完成的交付。