General Writing 是所有写作任务的统一入口点。它的工作方式是将用户的请求匹配到一个体裁，读取对应的子技能 SKILL.md，并执行其工作流。
用途与范围 该技能覆盖的体裁包括：小说（fiction）、同人（fanfiction）、诗歌（poetry）、歌词（lyrics）、戏剧（drama）、剧本（screenplay）、散文（essay）、游戏文案（game writing）、剧本杀（murder mystery）、TRPG 模组（trpg）、书信（letter），以及一个兜底分支（_fallback）。明确不在范围内的是：报告/分析/白皮书/咨询/技术报告应转向 report-writing；学术论文/综述/实证研究应转向 paper-writing，遇到这些关键词应立即重定向，不在本技能处理。
核心架构原则 主智能体只担任规划者与调度者，绝不亲自写作。主智能体必须绝不执行实际的写作、审阅、编辑或素材组装，所有执行工作都通过 create_subagent 委派给专门的子智能体。主智能体的职责仅限于：理解用户需求、匹配体裁、读取子技能 SKILL.md；按子技能工作流规划任务顺序和子智能体分工；创建并派发子智能体（写作者/编辑/规划者/研究者）；在子智能体之间传递上下文（大纲、状态面板、审阅简报）；监控进度、执行质量门禁、决定是否需要重写。这样做的原因是主智能体的上下文窗口是稀缺资源，实际创作内容可能达到数千到数十万字，会迅速耗尽它；通过将所有写作委派给子智能体，主智能体只处理摘要和状态，保持上下文清洁，从而能够持续编排直到作品完成。
执行到完成 该技能要求写到计划范围以质量交付为止——完全审阅、组装并转换为 .docx。对于适合单次会话的任务（短/中篇小说、大纲、散文），交付完整目标。对于超出单次会话的长篇作品，交付完整卷及 .docx，让用户决定是否继续。当子智能体超时时，重新派发。当写作者的上下文填满时，派发一个新的。绝不以原始章节文件且没有 .docx 交付物结束会话。
体裁路由 匹配体裁后，立即读取对应的 SKILL.md 并遵循其完整工作流。采用自上而下匹配，首次命中即生效。优先级顺序为：1 小说（fiction/SKILL.md，触发词：小说, novel, short story, 短篇, 中篇, 长篇, 章节, chapter, 故事）；2 同人（fanfiction/SKILL.md，触发词：同人, fanfic, AU, OOC, 二创）；3 诗歌（poetry/SKILL.md，触发词：诗, 词, poem, sonnet, haiku, 律诗, 绝句, verse）；4 歌词（lyrics/SKILL.md，触发词：歌词, lyrics, 填词, songwriting, 作词, chorus）；5 戏剧（drama/SKILL.md，触发词：话剧, 舞台剧, 歌剧, 音乐剧, stage play, musical）；6 剧本（screenplay/SKILL.md，触发词：剧本, 编剧, screenplay, script, 电影剧本, 电视剧本）；7 散文（essay/SKILL.md，触发词：散文, 随笔, essay, 杂文, prose, 议论文）；8 游戏文案（game-writing/SKILL.md，触发词：游戏文案, 游戏剧情, game narrative, quest design, dialogue tree）；9 剧本杀（murder-mystery/SKILL.md，触发词：剧本杀, murder mystery, 推理本, 情感本, LARP）；10 TRPG（trpg/SKILL.md，触发词：跑团, TRPG, CoC, DnD, 模组, scenario, campaign）；11 书信（letter/SKILL.md，触发词：书信, letter, 情书, 公开信, 感谢信, epistle）；12 兜底（_fallback/SKILL.md，以上均不匹配时）。路由逻辑为：用户查询若匹配体裁触发关键词，则读取对应 SKILL.md 并执行其工作流；若在体裁之间模糊，优先选择最先命名的体裁，若仍不明确，则从上下文推断或部署子智能体分析请求；若无匹配，则路由到 _fallback/SKILL.md。无论任务大小都要加载子技能，匹配体裁后读取子技能的 SKILL.md 并遵循它，子技能对短任务有轻量分支，临时拼凑的流程比使用子技能最轻分支质量更低。
共享写作原则 所有子技能继承这些原则，子技能可以添加体裁特定规则但不得与之矛盾。价值观方面：服务于作者的愿景，用户是创作者，你是工匠；尊重受众，调整语域、复杂度和文化引用；真实胜过公式，真实的声音优于机械套用模板。技艺方面：展示而非讲述——在适当的时候，具体细节优于抽象概括，例外是散文和书信；每个词都要有其价值，删减填充内容，意义密度优于字数；节奏很重要，变化句子长度，短促有力，然后较长流畅；对话揭示角色，可区分的声音，潜台词优于说明；具体性创造真实感，一个精确细节优于数段模糊描述。流程方面：写作前先研究，先检查 /mnt/agents/output/research/；先结构后行文，大纲→草稿→修订；一致性不可妥协，对长篇作品显式跟踪状态；知道何时结束，当核心承诺实现时完成。
技术规则 文件优先：所有创作输出都写入文件，绝不内联（除少于 500 字的预览）；聊天仅用于状态更新。命名规则：大纲为 {filename}.agent.outline.md；章节为 {filename}_sec{NN}.md；最终为 {filename}.agent.final.md；输出目录为 /mnt/agents/output/。语言一致性：所有内容必须匹配用户语言——行文、子智能体名称、提示词和最终交付物，除非用户明确要求，绝不混用语言。输出格式：交付用户要求的格式，未指定时默认 .md；对于 .docx 交付，使用 skills/docx/SKILL.md 转换；强制 .docx 交付：所有子技能必须在会话结束前通过 skills/docx/SKILL.md 将最终组装的 markdown 转换为 .docx，没有 .docx 的原始 .md 不是可接受的结束状态。反读取循环规则：编排者必须在 10 次迭代内派发其第一个子智能体，如果 10 次以上迭代仅进行文件读取而没有创建子智能体，则处于读取循环中，应停止读取，用现有信息继续并立即派发。审阅→修复简报→派发子智能体：当任何审阅（共享或体裁特定）发现问题时，编排者编写详细修复简报并派发一个新的子智能体，绝不内联应用 sed/edit_file 修复；派发的子智能体重新读取上下文、运行自检并保留声音；修复简报必须包含：(1) 确切文件路径，(2) 引用的发现，(3) 预期结果，(4) 范围边界，(5) 返回前要运行的自检。并行文件读取前的大小检查：在派发读取多个参考文件的子智能体之前，用 ls -la 或 wc -c 估算合并大小；读取 200KB 参考文件的子智能体将大部分 token 预算花在读取上。合并大小 < 50 KB 时传递路径，并行读取没问题；50-150 KB 时传递路径，顺序读取；> 150 KB 时仅传递相关部分，或先派发一个摘要器。当文件已知很小或子智能体的工作就是消费它们（例如摘要器）时跳过检查。严格 UTF-8：管道中所有文件读取和拼接（章节文件、章节文件、中间产物）使用 encoding='utf-8' 且无错误处理器；遇到 UnicodeDecodeError 时，为损坏的文件重新派发写作者；绝不回退到 latin-1、gbk、cp1252、errors='ignore' 或 errors='replace'。
共享参考文件 所有子技能使用两个共享文件，子技能特定的参考文件在每个子技能自己的 SKILL.md 中定义。anti-ai.md：AI 写作模式避免规则，在创建任何写作者子智能体之前触发，主智能体读取全文并内联到写作者的系统提示词中——文件少于 2000 词，适合直接嵌入；也内联到编辑子智能体的系统提示词中作为审阅清单。review.md：共享审阅管道——编辑子智能体定义（系统提示词规格）、质量门禁协议，在进入审阅阶段之前触发，主智能体读取并遵循 review.md 指令创建编辑子智能体——此文件是主智能体的操作手册，不传递给子智能体；每个编辑的系统提示词和任务提示词规格在 review.md 中定义。
上下文传递原则 当子技能向子智能体传递内容时，遵循以下规则：角色定义、风格规则、反 AI 规则少于 2000 词时以内联文本放在 system_prompt；大纲、设定文档、状态面板超过 2000 词时以文件路径放在 task_prompt；具体任务指令（章节号、字数、场景列表）较短时以内联文本放在 task_prompt；前文章节摘要、审阅简报中等长度时以内联文本放在 task_prompt。
适用场景与限制 该技能适用于需要按体裁进行结构化写作编排的场景，尤其是长篇、多章节、需要状态跟踪和审阅管道的作品。限制方面：它不处理报告、分析、白皮书、咨询、技术报告和学术论文等，这些应重定向到其他技能；它依赖子智能体机制和文件系统路径（如 /mnt/agents/output/），具体运行环境要求暂未提供；关于收费、价格、平台等信息暂未提供。