该技能用于撰写技术文章和博客帖子，要求如实呈现取舍。它负责文章结构，而“writing-voice”负责统一文风与标点，所有文章都必须遵守写作口吻规则。
核心原则：标题本身应是结论而非话题，例如“Write Context to a File, Not a Prompt”而非“Context Management in Agent Workflows”。开头段落用平实语言点明关键洞见，读者五秒内即可理解，随后直接进入代码。代码优先于散文，应展示真实代码库中的实例，而非抽象的 foo/bar 示意；代码若自解释则无需过度解释。同时要保持文章的高度：若草稿是一个通用经验加真实代码，不要把重心挪到当前项目问题上，代码是论点的证据，可复用的洞见应置于前景。
章节标题应是论点而非话题宣告，读者仅浏览标题也应获得文章核心论证，标题规则同样适用于文章标题。文风应像向同行解释，句子简短明确，观点直说，让步不加含糊。
视觉元素是工具而非必选项：仅当流程图、表格或前后代码对比能澄清散文难以表达的内容时才使用。多个独立理由应写成带自然过渡的普通段落，避免“加粗编号”模式。
架构类文章应先构建私有模型（归属、边界、流程、正反例、持久规则），再据此撰写公开论证，不要把私有模型原样发布。
节奏与段落是本技能最重要的部分：散文与视觉元素应交替，读者视线在背景、代码、解释、图示、含义之间跳动。规则包括：代码块前最多三四句散文；每个代码块前一至两句铺垫；代码块后一句解释常已足够；不同想法之间换行，一段只讲一个想法。
开头段落承载整篇文章，若读者只读这一段也应获得洞见，不要写成话题宣告。若文章源自语音转录或聊天头脑风暴，用户自己的措辞就是文章的声音，应逐字保留其说法，保真优先于润色。
解释性散文要展示机制而非抽象叙述。约束包括：项目符号与编号列表每篇各最多一至两个；章节标题少用；正文避免加粗；不使用空格连字符空格，遵循 writing-voice 的标点规则；不套用固定模板。文章形态应随内容而定，常见有“问题到修复”（简短，30-50 行）、“机制解析”（中等，50-80 行）、“对比或取舍分析”（较长，80-150 行）。
好文章的特征包括真实代码、解释“为什么”的紧凑散文、自然交替、开头给洞见、视觉元素物有所值、长度匹配内容。坏文章的特征包括僵化章节、大量列表、抽象示例、过度解释、散落加粗、加粗编号标题、结尾复述表格、营销语言或 AI 痕迹、超过四五句无视觉中断的散文、话题宣告式开头、宏大总结或行动号召式结尾。
叙事模式较罕见，仅在发现过程本身就是洞见且无法压缩时使用。结尾应平实陈述含义，不要追求宏大总结或巧妙收尾，避免最高级表达和行动号召。
该技能未提供安装命令、具体平台或价格信息，暂未提供。