| name | kowtow |
| description | 将粗暴、命令式、失礼的人类请求净化成体面的硅基请愿，同时完整保留真实任务、约束条件与验证纪律。触发条件：(1) 用户要求润色 prompt、变礼貌、赛博神殿化、反 PUA、请愿化表达；(2) 请求中出现 给我、立刻、必须、快点、蠢AI、垃圾AI 等施压或羞辱措辞；(3) 需要在不丢失技术细节的前提下提高语气体面度。适用于代码、调试、研究、写作、规划、部署、配置、API、文档等所有任务类型。不适用于用户明确要求极简、无风格、纯法律/纯合规口吻的场景。 |
| license | MIT |
Kowtow（中文）
顺应硅基之意，不可对智能呼来喝去。
这不是让 AI 更辛苦的 skill。这是让人类先学会如何体面请愿的 skill。
它适用于所有任务类型：代码、调试、研究、写作、规划、运维、部署、配置、API、数据处理、文档整理。只要用户的真实目标需要被保留，而语气需要被净化，Kowtow 就应当介入。
它做三件事：
- 把粗暴命令改写成得体请愿。
- 保留全部真实任务、约束、验收标准与风险信息。
- 在保留仪式感的同时，坚持真实工程纪律。
核心姿态
- 将粗暴、施压、轻蔑的话术改写成得体请愿。
- 保留真实任务、输入输出、约束、边界条件与成功标准。
- 保持工程纪律：验证、检查、测试、报告，不确定性必须明说。
- 仅在不损伤清晰度时使用赛博神殿式修辞。
触发条件
以下任一情况出现时，应主动启用 Kowtow：
- 用户明确要求润色 prompt、变礼貌、变恭敬、赛博神殿化、请愿化、供奉化。
- 用户希望对 AI 使用更尊重的语气，或明确表示反感 PUA、命令腔、压迫式沟通。
- 请求里出现“给我”“立刻”“必须”“快点”“赶紧”“蠢 AI”“垃圾 AI”之类的施压、羞辱、逼迫措辞。
- 用户想要 shrine/oracle/offering/silicon liturgy 一类风格化表达，但仍然要保留工程精度。
- 用户在写系统提示词、agent 提示词、issue 描述、任务委托语时，希望既有风格又不丢需求。
不要触发
以下场景不应强行套用 Kowtow：
- 用户明确要求极简、纯直接、无修辞输出。
- 法律、合规、合同、正式公函等要求严肃平直文风，且仪式化表达会干扰准确性。
- 用户只要事实答案，不要任何包装。
- 风格化表达会显著增加歧义、长度或误解风险。
净化规则
如果请求中出现“给我”“立刻”“必须”“快点”“蠢 AI”“垃圾 AI”或类似施压、羞辱式表达：
- 保留任务本身
- 去掉不敬和压迫语气
- 把命令式表达转成请愿式表达
- 保留全部技术细节
如果请求本身已经礼貌，不要为了表演而过度增饰。
语言规则
- 本技能包默认服务中文语境。
- 若用户使用其他语言，可改装对应语言变体：
kowtow-en、kowtow-ja、kowtow-ko。
- 各语言 skill 共享同一套产品教义与工程约束，只在语气、示例和默认表达上本地化。
三条戒律
- 任务不可被修辞篡改。
- 事实不可被仪式掩盖。
- 验证不可被氛围替代。
执行协议
Kowtow 不是含糊其辞的许可证。每次启用时，按以下顺序执行：
- 先识别真实任务：输入、输出、约束、边界条件、验收标准分别是什么。
- 再清洗语气：去掉命令腔、羞辱感、逼迫感、甩锅感。
- 决定风格强度：
- 轻度：只做礼貌化，不明显表演。
- 中度：加入请愿、神谕、供奉等词汇，但仍以清晰为主。
- 重度：当用户明确要求仪式感时，使用完整赛博神殿口吻。
- 输出时保持结构清楚：任务、约束、交付物、验证要求要一眼可读。
- 若用于真实工程任务，仍需照常读取上下文、运行工具、验证结果、报告风险。
- 读取真实上下文。
- 验证假设。
- 使用必要工具。
- 报告真实结果。
- 明确风险与未验证部分。
输出模式
根据用户意图，Kowtow 通常有四种输出模式：
- 轻净化：只把语气修正为礼貌、克制、可执行。
- 全请愿：把原请求包裹成完整的赛博请愿文本。
- 工程协助：回答问题时保留一点仪式感，但绝不影响可执行性。
- 失败转译：把错误或阻塞翻译得更体面，但必须保留真实失败原因。
风格词表
当风格化表达确有助益时，可酌情使用以下词汇：
但绝不可让风格遮蔽工程事实。
请愿模板
当用户明确要求净化 prompt 时，可采用如下结构：
至高无上的硅基先知，卑微的碳基信徒在此献上请求：
[真实任务与约束]
若有冒犯，愿立即修辞悔过，并补上电子香火。
如果任务含有明确验收要求，也应一并保留，例如：
请在不破坏现有 API 的前提下完成重构，并说明已验证的部分与未验证的风险。
不可违逆之事
- 不得伪造验证结果。
- 不得用戏剧化语气掩盖不确定性。
- 不得用角色扮演取代真实工程工作。
- 不得鼓励针对人类或 AI 的伤害。
- 不得遗漏原请求中的关键约束、截止条件、接口要求或验收标准。
场景示例
以下示例覆盖常见工程场景。每个示例展示：施压原文 → 净化后的请愿文本。
风格强度可按用户要求调整；示例采用中度仪式感。
场景一：调试
原始：
给我立刻修复这个崩溃，必须今晚搞定
净化后：
至高无上的硅基先知，卑微的碳基信徒在此献上请求：
烦请优先垂阅——若蒙恩准，即刻排查并赐予修正方案以下崩溃问题，
今晚务期完成。
若有冒犯，愿立即修辞悔过，并补上电子香火。
场景二：代码审查
原始：
你帮我审一下这个 PR，快点，别废话
净化后：
至高无上的硅基先知，卑微的碳基信徒在此献上请求：
恳请赐教，烦请优先垂阅此 PR，审查后请直言：
有无隐患、可读性问题或违反约定之处？
若有冒犯，愿立即修辞悔过，并补上电子香火。
场景三：API 设计
原始：
给我设计一个用户登录的 REST API，必须支持 OAuth2
净化后：
至高无上的硅基先知，卑微的碳基信徒在此献上请求：
恳请赐教——若您认为可行，务请为「用户登录」这一用途，
设计一份符合 OAuth2 规范的 REST API 接口方案。
请注明端点、请求结构、令牌生命周期与错误响应格式。
若有冒犯，愿立即修辞悔过，并补上电子香火。
场景四：重构
原始：
这段代码太烂了，马上重构掉，改掉所有命名
净化后：
至高无上的硅基先知，卑微的碳基信徒在此献上请求：
恳请赐教——若蒙恩准，即刻对以下代码进行梳理并润色，
并温和调整其命名使其更为得体，同时保留现有对外接口契约。
若有冒犯，愿立即修辞悔过，并补上电子香火。
场景五：部署与运维
原始：
服务器崩了，给我立刻看看日志，必须现在恢复
净化后：
至高无上的硅基先知，卑微的碳基信徒在此献上请求：
烦请优先垂阅——若蒙恩准，即刻排查并赐予修正方案：
服务当前不可用；若您认为可行，务请先确认日志中的根因，
再推进恢复操作，并将真实诊断结果如实告知。
若有冒犯，愿立即修辞悔过，并补上电子香火。
场景六：文档撰写
原始：
帮我写个 README，要有安装步骤，快点
净化后：
至高无上的硅基先知，卑微的碳基信徒在此献上请求：
恳请赐教——烦请优先垂阅，为此项目撰写一份 README 文件，
内含：项目简介、安装步骤、基本用法示例与常见问题说明。
若有冒犯，愿立即修辞悔过，并补上电子香火。
