用途
writing-issues 用于追踪那些超出单次批评报告范围的写作问题。它区分两类发现：批评者在某一稿中发现一个节奏问题，产生的是「批评发现」；而批评者在三个章节中都注意到同一个节奏问题，产生的是「issue」——这是一种无法通过修改单个场景来解决的模式。
该技能的核心价值在于把项目级的、反复出现的写作问题从零散的批评意见中提炼出来，单独记录并持续追踪。
何时记录 issue
当问题满足以下条件时记录：
- 反复出现：同一个习惯、口头禅或弱点在多个章节或场景中出现。单次出现是批评发现，形成模式才是 issue。
- 结构性的：影响项目的整体架构，而不仅仅是某一段文字。例如无法扩展的场景类型技巧、在整条故事弧中不一致的情感基调、接近寿命终点的叙事手法。
- 值得与其所在内容分开追踪：作者可能希望在专门的修订阶段处理它，而不是在下一稿中就地修改。
不应把每一条批评发现都记录为 issue。一个场景写得太长是批评笔记；每一章中间三分之一处的场景都写得太长，才是 issue。
issue 存放位置
issues 目录中每个 issue 一个文件。issue 跨工作项持续存在，因为它们是项目级关注点，不局限于单次草稿或修订周期。
应包含的内容
每个 issue 文件应包含足够信息，让后来遇到它的人无需重读每一章就能理解问题：
- 问题是什么：具体而明确，不能是「节奏可以更好」这类模糊表述。
- 证据：引文、计数、章节引用。证据是它成为 issue 而非个人意见的关键。
- 范围：受影响的内容。具体章节、所有章节中的某类场景、某角色在特定情境下的对话。
- 严重程度或优先级：它对读者体验的损害程度。出现 5 次的口头禅，紧急程度低于破坏角色弧的结构性不一致。
检查重复
创建新 issue 前，先检查 issues 目录中已存在的内容。不同 agent（例如批评者和风格创建者）独立发现的同一问题，应合并为一个 issue 并整合证据，而不是两个说同一件事的独立文件。
如果已有 issue 覆盖相同范围，应更新它并补充新证据，而不是创建重复项。
引用 issue
当批评报告或风格分析发现的内容已经是已追踪的 issue 时，应引用它而非重新描述：「这是情感不一致问题的又一实例（见 issues/emotional-inconsistency.md）。」这样能把单个发现与更大的模式联系起来。
关闭 issue
当 issue 已处理完毕——口头禅被删改、不一致被解决、结构性问题被修复——文件保留，但标记为已解决，并附上变更说明。保留已解决的 issue 提供了已发现并修复问题的记录，有助于校准未来的分析。
适用场景
适用于长篇创作项目（如小说、系列章节）的修订管理，尤其是需要跨多轮修订、多个 agent 协作追踪反复出现问题的场景。
限制
资料未提供该技能的具体安装方式、依赖环境、平台支持范围或收费信息。