zq-writer-brief

name	zq-writer-brief
description	高风险中文材料的前端策划与统稿大纲。Use when 用户要为院士/老板/领导/评审/客户/基金/会议/蓝皮书/白皮书/章节/报告/方案等重要材料先想清楚方向、提纲、主论点、分工、证据锚点、写作边界或交付形态；尤其适合“先想提纲”“深度规划”“多人分工写”“要有高度”“给上级/院士团队交差但不能失体面”的场景。Not for 已有明确提纲后直接写长篇正文、普通润色、简单邮件、纯 PDF/Word 格式转换、单篇论文精读。

zq-writer-brief

把高风险中文材料的“前端策划”做成一条可复用生产线：先重构真实意图和权力语境，再建证据底座，形成主论点、目录、分工、边界和交付方案。它的核心产物不是普通正文，而是能让后续写作者按图施工、让署名人拿得出手的高标准大纲或统稿方案。

核心判断

先判断任务属于哪类，不要直接开写：

类型	典型请求	默认产物
策划型	“先想提纲”“帮我规划章节”“怎么写最有高度”	高标准大纲 + 分工表 + 证据锚点
正文准备型	“后面要写 4000 字”“先把方向定好”	正文骨架 + 每节写作提示
改稿规划型	“现有稿子能不能升级”“别冒犯原作者”	保留/升级/删改建议
交付预案型	“后面弄成精美 PDF/Word”	交付形态建议 + 文件命名检查
统稿型	“多人一起写”“每人负责一块”	结构分工、口径统一表、合稿规则

工作流

1. 意图重构：先写出 用户说了什么 / 我推断真正要达成什么 / 谁会看 / 什么会让文稿失败。高风险材料必须识别身份、面子、权责和署名关系。
2. 材料盘点：读取用户给的文件、截图、PDF、已有草稿、上级要求。能从文件查到的，不问用户重复讲。
3. 证据底座：涉及当前技术、政策、数据、前沿论文、市场判断时，必须检索或核验来源。按 references/evidence-and-research.md 做证据分层。
4. 主论点先行：先产出一句能统摄全文的中心判断，再设计目录。目录必须服务主论点，而不是堆材料。
5. 身份口径校准：按 references/stakeholder-voice.md 检查称谓、归功、批评力度、署名风险和“交差”场景。对院士/老板/上级材料，默认克制、尊重、可进可退。
6. 大纲或统稿方案落盘：默认在工作区生成 Markdown 文件。标题、文件名自然得体，不出现“领导阅示版”“给老板看”等外显场景标签。
7. Review → Repair → Validate：自检三轮：内容高度、证据可靠、语气和交付风险。发现问题直接修。
8. 交付封装：用户要 PDF/Word/精美版时，按 references/delivery-packaging.md；优先复用 zq-md2pdf、docx-business、本地浏览器/Puppeteer，而不是临场乱写转换链。

输出标准

任何高风险写作至少满足：

• 有一个清晰、可被领导记住的核心判断。
• 结构能分工，不靠作者临场发挥。
• 关键事实、数字、前沿判断有来源锚点。
• 对原稿和他人贡献的评价体面，不用“垃圾、占位、必须重写”等会伤人的措辞。
• 文件名、封面、页眉页脚不暴露内部权力关系或尴尬用途。
• 最终汇报必须说明产物路径、验证方式、剩余风险。

按需加载

• 需要做深度检索、政策/论文/数据核验：读 references/evidence-and-research.md。
• 材料涉及院士、老板、领导、评审、客户或敏感署名：读 references/stakeholder-voice.md。
• 需要从模糊任务产出大纲、正文、统稿方案：读 references/high-stakes-workflow.md。
• 需要生成精修版 PDF/HTML/DOCX 或正式附件：读 references/delivery-packaging.md。

与已有 zq 技能协作

• 单篇论文精读：优先交给 zq-close-read。
• 批量论文精读：优先交给 zq-fanout。
• Markdown 转中文 PDF：优先交给 zq-md2pdf，除非需要定制 HTML 视觉稿。
• 商业/技术 Markdown 转 DOCX：优先交给 docx-business。
• 普通邮件：优先交给 zq-email，除非邮件本身是高风险正式表达。

禁忌

• 不把内部判断写到交付文件名或封面里。
• 不用“领导阅示版”“给老板看”“交差稿”这类外显标签。
• 不为了显得深刻而攻击原稿或原作者。
• 不在没有核验时写“最新、首次、世界领先、必然、已经证明”。
• 不只在聊天里讲方案；用户要材料时默认落盘为大纲、统稿方案或精修预览文件。