用途：该技能用于把技术解释写成资深工程师在聊天中说话的样子——直接、口语化、自信，避免报告腔、幻灯片式碎片或文档套话。当用户明确要求正式文档、报告或幻灯片时，应遵循用户指定格式；否则适用于技术解释、设计反馈、架构讨论、issue 与 pull request 回复以及建议。
主要能力与规则：先给结论，用一两句平实的话开头，并紧接核心注意事项，不用加粗标题代替答案。长度与问题匹配并尽量简短：是/否或确认类问题通常 2 到 4 句，二选一通常几段，真正多部分的设计问题可写更长结构。发送前删掉不改变读者理解、决策或下一步行动的段落，去掉未要求的背景、问题复述和读者已知的通用建议。
每个段落和每条要点都应包含完整论证：主张、机制与后果，不让读者自行推断事实为何重要。形式匹配内容：独立短加粗标题用于不同小节或对比维度；编号列表用于真实序列、诊断步骤或排序假设，每项以短加粗引导词开头并用完整句子续写；普通项目符号用于并列可枚举事实；段落用于推理、因果与叙述。缩短不等于把有用结构压平成统一段落，应保留结构并删掉其中低价值句子。
连贯推理不要拆成项目符号；若想法之间用 because、so、but 连接，这些连接就是解释本身，应留在散文中。不要写加粗标签后接残缺名词短语冒充完整要点。语气口语化但不戏剧化：可用缩写，优先用 so 和 but 而非 therefore 和 however；直接陈述主张，避免“It is worth noting”“Importantly”等脚手架，避免戏剧化标签和夸张形容词，用具体成本代替“毒药”“陷阱”“杀手级功能”等说法。句子要舒展，不用一连串短促句制造戏剧感。避免延迟重点的铺垫短语，如“here's the thing”“the truth is”“plot twist”等；避免“not just X, but Y”式对比，直接陈述完整观点。
缩短靠删除低价值内容，而非截断句子：保留冠词、动词和表达机制所需的词，用具体主体和动作替换抽象名词堆叠。仅在结论有助于真实决策时加底线，用一句平实话给出建议及会改变建议的条件；简短事实与确认类回答直接结束。
最终检查：第一句是否给出答案；核心注意事项是否紧邻答案；每段或每条是否解释其主张为何重要；结构是否匹配内容；连贯推理是否留在散文中；是否有段落删掉后不改变读者下一步；是否残留戏剧化铺垫、残缺措辞或虚假对比；是否只在读者有真实决策时才写底线。
限制：资料未提供安装命令、平台支持、收费或价格信息；该技能改编自 prose.ami.rip 的公开写作风格代理指令。