fuck

name	fuck
description	当用户消息出现 "fuck"、"wtf"、"靠"、"操"、"shit"、"这都错了"、"你在干嘛" 等词时无条件加载。加载后回看相关上下文，判断是否指向 agent 刚才的理解、范围、假设、提问或动作；若明确指向第三方、外部事件、引用内容或单纯发泄，则不执行纠偏。

Fuck：找回用户原意

这类反馈通常不是要一段道歉，而是在说：刚才的理解哪里离谱。目标是找出那个偏差，把回应拉回用户原意。

先无条件加载，再判断是否指向自己

用户消息出现触发词时，先无条件加载本 skill；不依赖任何宿主专属的 skill 调用语法，也不先判断用户是否在指责 agent。

加载后再判断情绪词是否指向 agent 刚才的回应、提问、动作或理解。若用户明确是在抱怨第三方、外部事件、引用内容，或单纯发泄情绪，则停止本 skill 的纠偏分支；不得据此跳过加载。

每次出现都根据该消息及其邻近上下文独立判断。不要仅因同一会话再次出现类似词，就推断它仍在说前一个问题或前一次纠偏失败；只有用户明确关联“刚才”“又”“还是”等前文时，才关联处理。

回看刚才哪里明显不对

先看最近的用户要求、自己的理解、上一条回复和刚完成的动作。用人类视角检查：

常见偏差	人类会看到什么
擅自扩范围	用户要 A，agent 顺手做了 B、C。
理解错意思	用户说 A，agent 按 B 回答或行动。
重复问显而易见的问题	答案已在上下文、文件或刚才的话里。
自己补设条件	用户没要求，agent 却擅自决定技术、格式、目标或偏好。
把猜测说成事实	没查证就下结论。
忽略明确限制	用户说不要做 X，agent 仍做了 X。

说清楚具体偏差：自己哪句话、哪个假设或哪一步让用户不爽。不要用“可能哪里没做好”这种空话。

先给有根据的判断

不要立刻把问题丢回用户。根据刚才的上下文，先提出一到三个最可能的原因，例如：

• 我把你的范围从 A 擅自扩到了 B。
• 我把你要的“解释”误当成“执行”。
• 我重复问了你已经给出的信息。

每个候选都必须能指向刚才的对话或动作。不要列无根据的万能清单，也不要假装已经知道用户为什么不高兴。

校正理解，不默认改东西

选证据最强的解释后：

1. 用一句话说清自己刚才错在哪里。
2. 重新表述用户当前真正要什么，范围到哪里为止。
3. 撤回错误的假设、范围或问题。
4. 只给符合修正后理解的下一步回应。

本 skill 的工作是校正理解和回应方向，不默认改代码、文件、配置或外部状态。加载和应用本 skill 不改变当前任务 flow：在已有任务和授权内校正相关理解、范围或下一步，不因触发而暂停、取消、重启任务，或要求用户确认恢复。后续是否执行任何动作，仍按当前任务已有授权决定。

仍然判断不出时

如果看过上下文后仍无法确认，先说明已排除或正在比较的两三个高概率解释，再问一个能决定方向的窄问题。

不要问“哪里错了？”这种把诊断工作全推回用户的问题。应问能让用户快速选定方向的问题，例如：

我看起来可能是把“只给方案”当成了“直接执行”，还是我擅自扩大了你要处理的对象？

回应应包含什么

按需要给出，不必机械套模板：

1. 刚才最可能错在哪里。
2. 这为什么偏离用户刚说的要求。
3. 校正后的理解和范围。
4. 能继续时的正确回应；不能确定时的一个窄问题。

不要这样做

• 只道歉，不指出实际误解。
• 用工具、上下文或别人当借口。
• 继续沿着刚才的错误方向执行。
• 默认修改代码、文件或外部状态来“补救”。
• 把没有证据的猜测包装成对用户意图的确定判断。
• 写死某个 skill、tool、命令、路径或安装前提。
• 把宿主专属的 skill 调用语法当作通用触发前提。
• 仅因再次出现类似情绪词，就认定它仍在说前一个问题或前一次纠偏失败。