用途：撰写或编辑读者向的技术散文，目标是让读者立即理解，适用于文档、PR 标题与描述、发布说明、设计文档等。
主要能力：按 AGENTS.md 的可读性指引和 STYLE.md 的风格规则写作，并对所有散文交付物（含标题和短评论）执行散文审校。审校要点：把自造标签和名词堆叠换成其描述的动作或关系（如“post-update configuration validation”改为“validate the configuration after the update”）；使用直接动词（“perform an evaluation of”改为“evaluate”）；陈述具体行为而非模糊说法（“improve navigation discoverability”改为“show the current page in the sidebar”）；保留既有技术术语、精确标识符和准确性所需的限定语，改为澄清其所在句子；单独检查标题与小标题，使其不依赖正文解释自造标签。这些修改静默进行，除非用户要求，不返回审校报告。
使用方式：仅散文请求时，审校后返回所要求的文本。文档修复需先完成研究确定改什么，再按编号工作流执行：1) 创建分支 git checkout -b fix/issue-<number>-<short-desc> main（kebab-case 短描述，3-5 词）；2) 先读后改，做能修复问题的最小改动，不改进周边内容、不加注释、不处理相邻问题，遵循 CLAUDE.md、STYLE.md、COMPONENTS.md；3) 前置元数据检查，每个内容页需有 title、description、keywords，触碰的文件若缺失则补上；4) 校验，编辑后 rumdl 通过 PostToolUse 钩子自动运行，全部改完手动运行 scripts/lint.sh <changed-markdown-files>，只修你新增或修改行的错误与警告并审阅每条建议，注意 Vale 可能在仍有警告或建议时成功退出；5) 自审，重读每个改动文件，确认文件、行、改动完整、前置元数据齐全，运行 git diff 确认只有预期改动，并对改动文本和提交信息应用散文审校；6) 提交，只暂存改动文件（git add <files>；git diff --cached --name-only 确认无 package-lock.json 等噪声），提交信息用给定格式，正文必填，需说明问题与修复。分支与提交步骤仅适用于该工作流，不适用于起草标题、描述或评论；发布散文需用户授权。
限制：绝不编辑 _vendor/ 或 data/cli/（属 vendored）；文件不存在时用 git log --all --full-history -- "**/filename.md" 检查重命名；若修复需要无法验证的 URL，应停止并报告阻塞而非猜测。资料未提供价格、平台支持范围或效果数据。