@deployxai/dxc 0.2.6 → 0.3.1

package/package.json

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

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

@@ -1,30 +1,19 @@
 ---
 name: dxc-article-outline
-description: 为 DxC 文章完成大纲阶段，把 Brief、研究材料或用户已有构思组织为可直接写作的章节结构。用户要求列大纲、重构文章结构，或 dxc-content-workflow 返回 outline 阶段时使用；可以作为八步工作流的独立起点。
+description: 完成 DxC 文章大纲阶段。设计章节逻辑、论证顺序、案例与证据位置；支持总控路由或独立进入。
 ---
 
 # DxC 文章大纲
 
-内部固定使用 `@deployxai/dxc@0.2.6`；Windows 通过 `npm.cmd exec`，macOS/Linux 通过 `npm exec`
-运行，不切换到 PATH 中的其他版本。
+内部调用 DxC CLI 时固定使用以下入口，不依赖全局 PATH：
 
-## 进入阶段
+- Windows：`npm.cmd exec --yes --registry=https://registry.npmjs.org/ --package=@deployxai/dxc@0.3.1 -- dxc <参数>`
+- macOS/Linux：`npm exec --yes --registry=https://registry.npmjs.org/ --package=@deployxai/dxc@0.3.1 -- dxc <参数>`
 
-- 总控返回 `step: outline` 时，读取 CLI 返回且真实存在的输入。
-- 直接从大纲开始或重新进入已有项目时，调用：
+设计大纲前完整读取 [大纲结构方法](references/outline-methods.md)，根据内容选择主结构并用自然语言交代章节职责。
 
-  ```text
-  dxc workflow start --from outline --title "<主题>" --json
-  ```
+用 `dxc workflow next --work-item <ID> --json` 获取研究、Brief 等命名输入和当前输出。独立进入时用 `workflow start --title <主题> --from outline --json`，已有项目按项目 ID 进入。
 
-  已有项目改为 `--project "<项目 ID>"` 并省略 `--title`；用户在对话中给出的 Brief 或材料可以直接使用。
+用自然语言组织开头、主要章节、论证递进、案例和结尾，不创建供下游解析的私有标签或隐藏标记。大纲应让正文作者理解每节为什么存在，而不是只列同义小标题。
 
-- 只使用本页列出的 workflow 领域命令。
-
-## 生成大纲
-
-完整读取 [references/outline-methods.md](references/outline-methods.md)，选择一个最适合当前内容的主结构。
-每节写清目标、论点、证据责任和承接关系，避免为显得复杂而混搭框架。把结果写入 CLI 返回的
-`output`。若进入阶段时 CLI 返回 `requiresConfirmation: true`，展示完整大纲并让用户选择采用或
-修改；明确采用后调用 `dxc workflow complete --project "<项目 ID>" --confirm --json`。为
-`false` 时调用不带 `--confirm` 的同一命令并继续。
+写完指定输出并替换未填写标记后，调用 `dxc workflow complete --work-item <ID> --json`，再按返回动作展示、确认或交回总控。

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

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

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

@@ -1,45 +1,19 @@
 ---
 name: dxc-article-write
-description: 为 DxC 项目撰写或改写完整 Markdown 正文。用户要求从已有选题、大纲或材料直接写文章、重写正文，或 dxc-content-workflow 返回 article 阶段时使用；可以作为八步工作流的独立起点。
+description: 完成 DxC 微信文章正文阶段。结合命名研究、Brief 和大纲写出标题、作者、摘要与 Markdown 正文；支持总控路由或独立进入。
 ---
 
 # DxC 正文写作
 
-内部固定使用 `@deployxai/dxc@0.2.6`；Windows 通过 `npm.cmd exec`，macOS/Linux 通过 `npm exec`
-运行，不切换到 PATH 中的其他版本。
+内部调用 DxC CLI 时固定使用以下入口，不依赖全局 PATH：
 
-## 进入阶段
+- Windows：`npm.cmd exec --yes --registry=https://registry.npmjs.org/ --package=@deployxai/dxc@0.3.1 -- dxc <参数>`
+- macOS/Linux：`npm exec --yes --registry=https://registry.npmjs.org/ --package=@deployxai/dxc@0.3.1 -- dxc <参数>`
 
-- 总控返回 `step: article` 时，读取 CLI 返回且真实存在的输入文件。
-- 直接从正文开始或重新进入已有项目时，调用：
+写作前完整读取 [正文写作方法](references/writing-methods.md)，落实大纲的自然语言意图，同时保持事实、案例和表达边界。
 
-  ```text
-  dxc workflow start --from article --title "<主题>" --json
-  ```
+先调用 `dxc workflow next --work-item <ID> --json`。只从 `resources.inputs` 读取命名材料，只写 `resources.output.path`；平台字段限制以 CLI 返回的 `constraints` 为准，不在 Skill 中复制数值。独立进入使用 `workflow start --title <主题> --from article --json`，已有项目按项目 ID 进入。
 
-  已有项目改为 `--project "<项目 ID>"` 并省略 `--title`。用户给出的文章、大纲或素材可直接作为当前输入。
+保留证据边界，写出自然、具体、适合微信阅读的正文。填写 CLI 已创建的 frontmatter（前置信息）和正文，移除未填写标记；不得自行发明机器版本、阶段或路径字段。
 
-- 只使用本页列出的 workflow 领域命令。
-
-## 写作
-
-完整读取 [references/writing-methods.md](references/writing-methods.md)，根据当前材料选择适合的写法。
-正文必须从以下 frontmatter（头部元数据）开始，三个值都据当前内容填写：
-
-```markdown
----
-title: 当前文章标题
-author: 用户的公开署名
-digest: 不超过 120 字的摘要
----
-```
-
-不要在正文中手写项目素材的 Markdown 图片链接；正文配图统一由视觉计划声明，CLI 在预览时插入。不要留下
-大纲标记、内部自检或虚构引语。把正文写入 CLI 返回的 `output`，自行完成本阶段质量检查，然后调用
-完成命令：
-
-- `requiresConfirmation: true`：向用户展示当前完整正文和作者、摘要，让用户选择“采用并继续”或
-  “返回修改”。只有明确采用当前版本后，调用
-  `dxc workflow complete --project "<项目 ID>" --confirm --json`；任何修改都要重新展示和确认。
-- `requiresConfirmation: false`：调用
-  `dxc workflow complete --project "<项目 ID>" --json` 自动继续。
+完成后调用 `dxc workflow complete --work-item <ID> --json`。若返回确认动作，向用户展示实际正文；用户修改后重新用生产 ID 校验，明确采用时只用 CLI 返回的确认 ID 加 `--confirm`。

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

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

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

@@ -1,35 +1,19 @@
 ---
 name: dxc-content-brief
-description: 为 DxC 文章完成 Brief 阶段，把已有研究或用户给出的材料收敛为主题、核心问题、受众、角度、内容类型、情绪、来源、来源类型和标签。用户要求明确文章命题、内容 Brief 或定位，或 dxc-content-workflow 返回 brief 阶段时使用；可以作为八步工作流的独立起点。
+description: 完成 DxC 文章 Brief 阶段。判断目标读者、核心问题、角度、内容价值和情绪方向；支持总控路由或独立进入。
 ---
 
-# DxC 内容 Brief
+# DxC Brief
 
-内部固定使用 `@deployxai/dxc@0.2.6`；Windows 通过 `npm.cmd exec`，macOS/Linux 通过 `npm exec`
-运行，不切换到 PATH 中的其他版本。
+内部调用 DxC CLI 时固定使用以下入口，不依赖全局 PATH：
 
-## 进入阶段
+- Windows：`npm.cmd exec --yes --registry=https://registry.npmjs.org/ --package=@deployxai/dxc@0.3.1 -- dxc <参数>`
+- macOS/Linux：`npm exec --yes --registry=https://registry.npmjs.org/ --package=@deployxai/dxc@0.3.1 -- dxc <参数>`
 
-- 总控返回 `step: brief` 时，读取 CLI 给出的、真实存在的输入文件。
-- 直接从 Brief 开始或重新进入已有项目时，调用：
+收敛命题前完整读取 [Brief 方法](references/brief-method.md)，把其中的要素当作语义检查清单，不得改造成下游机器 schema（模式）。
 
-  ```text
-  dxc workflow start --from brief --title "<主题>" --json
-  ```
+先用 `dxc workflow next --work-item <ID> --json` 取得当前命名输入、输出脚手架和约束。独立进入时使用 `workflow start --title <主题> --from brief --json`；已有项目必须先按项目 ID 选择。
 
-  已有项目改为 `--project "<项目 ID>"` 并省略 `--title`。用户已经在对话中提供的研究材料也可直接作为输入。
+阅读 CLI 返回的研究输入，判断这篇内容写给谁、解决什么问题、采用什么角度、读完获得什么，以及应避免什么。缺少必需输入时原样说明 CLI 指出的输入名称，不猜测不存在的材料。
 
-- 只使用本页列出的 workflow 领域命令。
-
-## 生成 Brief
-
-完整读取 [references/brief-method.md](references/brief-method.md)，然后：
-
-1. 根据证据充分度、用户意图、读者收益、信息增量和风险选择最合适的角度。
-2. 写齐九个字段；未知项标明未知，不把推测写成事实。
-3. 把 Brief 写入 CLI 返回的 `output`。
-4. 若进入阶段时 CLI 返回 `requiresConfirmation: true`，展示完整 Brief 并让用户选择采用或修改；
-   明确采用后调用 `dxc workflow complete --project "<项目 ID>" --confirm --json`。为 `false` 时
-   调用不带 `--confirm` 的同一命令并继续。
-
-普通角度取舍由本阶段完成，不逐字段向用户确认；需要确认时只对完整 Brief 确认一次。
+把 Brief 写入指定输出并替换未填写标记，然后调用 `dxc workflow complete --work-item <ID> --json`。按统一动作继续，不传路径或自建字段给下一阶段。

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

@@ -1,52 +1,24 @@
 # Brief 收敛方法
 
-## 专家方法来源
+## 写清六件事
 
-- 原始方法真值是开发仓库 `docs/员工BCDE的skill/employee-b-research-analyst/SKILL.md`
-  的第 3、5、7、9–11 节；发布包不含原文，执行时以本胶囊为准。
-- 本胶囊把研究阶段的四类输入和角度光谱压缩为可供 C/D/E 消费的九字段命题；它不替代
-  研究包，也不提前决定文章结构或措辞。
+用自然语言回答，不创建供下游解析的字段协议：
 
-## 九字段
+1. 文章讨论什么，边界在哪里；
+2. 必须回答哪个具体问题；
+3. 写给处于什么场景的读者；
+4. 最终主张或切入角度是什么；
+5. 读者看完获得什么认知、情绪或行动变化；
+6. 哪些来源可用、只作背景或仍待核实。
 
-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. 风险是否可控。
-
-选择综合判断最优的一项，并在产物里保留取舍理由。不同价值立场、受众或风险无法由现有上下文
-判断时，优先选择不越过用户明确红线、证据更充分的一项并标注假设；措辞强弱、结构偏好和
-小范围选题修饰交给后续阶段处理。
-
-## 九字段的可用标准
-
-- `topic` 说明文章对象与边界；`coreQuestion` 必须是正文能够回答的问题，而不是“介绍一下”。
-- `audience` 写明读者处境、已有认知或要完成的动作；`angle` 用完整、可辩护的主张表达。
-- `contentType` 与 `emotion` 共同决定后续结构，但情绪只能描述读者体验或文章张力，不能
-  代替事实结论。
-- `sources` 区分可直接引用、只作背景和仍待核实的来源；`tags` 只用于检索与归档，不能伪装
-  成 SEO 承诺。
-- 生成 3–5 个角度时，要覆盖延续、反向、辩证或跨界中的真实分歧；不存在真实分歧时，不
-  为凑数量要求用户选择。
+依次比较证据支撑、用户意图、读者收益、信息增量和风险。保留真正不同的候选，不用换词凑数；
+现有上下文不足以判断价值立场时，选择证据更充分且不越过明确红线的一项，并写明假设。
 
 ## 边界
 
-- 参考文章的作者立场不是用户立场。
-- 本地历史文章用于风格和既有观点一致性，不自动证明当前事实。
-- `[待核实]` 可以保留到审校，但不得在 Brief 中改写成已确认。
-- Brief 只定命题，不提前写大纲或正文。
+- 参考文章作者的立场不是用户立场；
+- 历史片段只帮助判断风格和既有观点，不自动证明当前事实；
+- 待核实项不得改写成已确认；
+- Brief 只确定命题，不提前写大纲或正文。

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

@@ -1,40 +1,19 @@
 ---
 name: dxc-content-review
-description: 对 DxC 文章做交付前审校，检查事实、结构、重复、标题承诺、摘要、引用和图片。用户要求审校、质检、发布前检查，或 dxc-content-workflow 返回 quality-review 阶段时使用；可以从已有文章直接作为八步工作流的独立起点。
+description: 完成 DxC 审校阶段。检查事实、结构、逻辑、表达、标题承诺和视觉一致性，修正可修问题并给出 pass 或 block 结论。
 ---
 
 # DxC 内容审校
 
-内部固定使用 `@deployxai/dxc@0.2.6`；Windows 通过 `npm.cmd exec`，macOS/Linux 通过 `npm exec`
-运行，不切换到 PATH 中的其他版本。
+内部调用 DxC CLI 时固定使用以下入口，不依赖全局 PATH：
 
-## 进入阶段
+- Windows：`npm.cmd exec --yes --registry=https://registry.npmjs.org/ --package=@deployxai/dxc@0.3.1 -- dxc <参数>`
+- macOS/Linux：`npm exec --yes --registry=https://registry.npmjs.org/ --package=@deployxai/dxc@0.3.1 -- dxc <参数>`
 
-- 总控返回 `step: quality-review` 时，读取 CLI 返回且真实存在的正文、标题、研究和可选视觉计划。
-- 直接从审校开始或重新进入已有项目时，调用：
+开始审校前完整读取 [内容审校清单](references/review-checklist.md)，只检查当前命名输入能够证明的内容，不推断未提供的画像或真实素材状态。
 
-  ```text
-  dxc workflow start --from quality-review --title "<主题>" --json
-  ```
+先用 `dxc workflow next --work-item <ID> --json` 获取命名输入、审校输出脚手架和当前约束。独立进入使用 `workflow start --title <主题> --from quality-review --json`，已有项目按项目 ID 进入。
 
-  已有项目改为 `--project "<项目 ID>"` 并省略 `--title`。只使用本页列出的 workflow 领域命令。
+核对正文是否忠于研究证据、结构是否完整、标题是否兑现、摘要是否准确，以及可选视觉计划是否服务对应内容。当前资源允许且能安全修正的问题应在相应产物中修正；仍有阻断问题时记录具体问题并保持 `block`，只有达到可交付标准才写 `pass`。不要为了推进而弱化事实或视觉问题。
 
-## 审校
-
-完整读取 [references/review-checklist.md](references/review-checklist.md)。一次性检查并直接修复能够可靠修复的
-问题；不要把风格偏好升级为阻断。事实缺失、身份错误或无法交付的问题不能靠猜测修复时，清楚列出
-问题并保留 `verdict: block`。通过时写入：
-
-```markdown
----
-verdict: pass
----
-```
-
-把报告写入 CLI 返回的 `output`。通过后：
-
-- `requiresConfirmation: true`：展示审校结论、已修改项和剩余 warning，让用户确认采用当前审校结果
-  并进入预览；明确采用后调用
-  `dxc workflow complete --project "<项目 ID>" --confirm --json`。
-- `requiresConfirmation: false`：调用
-  `dxc workflow complete --project "<项目 ID>" --json` 自动进入交付。
+调用 `dxc workflow complete --work-item <ID> --json`，按返回动作展示真实审校结果、确认或交回总控。

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

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