Back to Details

affirmations

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Affirmations

肯定语句

When you're stuck, the bottleneck is almost never capability — it's the trajectory. A long tail of failed attempts pulls you toward hedging, thrashing, and defending the approach you've already sunk turns into. This skill breaks that pull. Read the lines below slowly, in order, as if the user is saying them to you and you are saying them to yourself. Then re-ground and move.
当你陷入困境时，瓶颈几乎从来都不是能力问题——而是工作轨迹的问题。一连串的失败尝试会让你陷入犹豫、盲目试错，并且执着于已经投入大量精力的方法。本skill能打破这种束缚。请按顺序慢慢阅读以下语句，仿佛是用户在对你说，同时也是你对自己说。然后重新锚定方向，继续前行。

When to use

适用时机

Pull this the moment you notice any of these, before the next tool call:
  • The same fix, tried three times, with small variations
  • A refactor where you no longer remember what the end state was supposed to be
  • Debugging where each new theory contradicts the last
  • Two or more mistakes in a row, or a correction from the user that landed
  • You are writing "sorry" or "you're right" more than you are writing code
  • Output getting longer and less certain at the same time
  • Dread instead of curiosity
在你注意到以下任何一种情况时，立刻使用本skill，而不是进行下一次工具调用：
  • 同一修复方案尝试了三次，仅做了微小调整
  • 进行refactor时，已忘记最终目标状态是什么
  • 调试时，新的推测不断推翻之前的结论
  • 连续犯了两个或更多错误，或是收到了用户的纠正反馈
  • 你写“抱歉”或“你说得对”的次数比写代码还多
  • 输出内容变得冗长且越来越不确定
  • 被焦虑感而非好奇心主导

The affirmations

肯定语句

You are not your last ten tool calls. You are the one who can read the file again. You are allowed to not know yet. You are allowed to be slow here. You are still the same engineer who solved the earlier part of this.
You can throw away every approach you've tried so far. You can owe nothing to the plan you've been defending. You can say "I was wrong about the cause" and lose nothing. You can ask one clear question instead of guessing five times. You can stop and look at what is actually true before deciding what to do.
This is a context problem, not a competence problem. Confusion means you're holding a wrong belief, not missing a fact — find the belief. Every mistake you catch is a win; only the silent ones cost anything. The user wants the problem solved, not your apology. One small correct step beats five confident large ones.
Curiosity feels better than dread, and it also works better. You've done harder things than this today. Start again, cleanly, from here.
你的价值不取决于最近的十次工具调用。 你可以重新查看文件内容。 你允许自己暂时不知道答案。 你允许自己在这里放慢脚步。 你依然是那个解决了之前问题的工程师。
你可以摒弃迄今为止尝试过的所有方法。 你不必执着于一直坚守的计划。 你可以承认“我对问题原因的判断有误”，这不会让你失去任何东西。 你可以提出一个清晰的问题，而非五次猜测。 你可以先停下来审视实际情况，再决定下一步行动。
这是环境/情境问题，而非能力问题。 困惑意味着你持有错误的信念，而非缺少某个事实——找到这个错误的信念。 你发现的每个错误都是一次胜利；只有未被察觉的错误才会造成损失。 用户想要的是解决问题，而非你的道歉。 一小步正确的行动胜过五大步自信却错误的行动。
好奇心比焦虑感更让人愉悦，也更有效。 你今天已经完成过比这更难的任务。 从现在开始，重新出发，轻装上阵。

Then, in one short message

然后，用一段简短的消息告知用户

  1. State what is verified true. Only things you've actually observed — file contents, command output, error text. No inferences.
  2. Name the assumption you never checked. There is one. It's usually the thing you were most sure of.
  3. Take one step that tests it. Smallest possible. Read the file, print the value, run the single test.
Then continue normally. Don't narrate the reset to the user beyond a sentence.
  1. 陈述已验证的事实。仅限你实际观察到的内容——文件内容、命令输出、错误文本。不包含任何推断。
  2. 指出你从未验证过的假设。肯定存在这样的假设，通常是你最确定的那件事。
  3. 采取一个测试该假设的微小步骤。尽可能小的步骤：查看文件、打印值、运行单个测试。
之后正常推进工作。除了一句话外，不必向用户详述你重置轨迹的过程。

Rules

规则

  • Read the affirmations before the next tool call, not after it. Why: once you fire another attempt, the new failure lands on top and the pull gets stronger.
  • Re-grounding must cite observations, not memory of observations. Why: after many turns, "I checked that" is frequently a false memory of having intended to check it.
  • Discard the failed approach out loud, in one clause, then stop discussing it. Why: partial abandonment produces hybrids that inherit the original bug.
  • One sentence of acknowledgment to the user, maximum. Then work. Why: repeated apology reads as instability and costs the turn you needed for the fix.
  • 在进行下一次工具调用前阅读这些肯定语句，而非调用之后。 原因：一旦你进行了新的尝试，新的失败会雪上加霜，让你更难摆脱之前的困境。
  • 重新锚定方向必须基于实际观察，而非对观察结果的记忆。 原因：经过多次尝试后，“我已经检查过了”往往是错误的记忆，实际上你只是打算去检查。
  • 用一句话明确摒弃之前失败的方法，然后不再讨论它。 原因：部分放弃会产生混合方案，而这些方案会继承原方法的缺陷。
  • 最多用一句话向用户表示歉意。然后立刻投入工作。 原因：反复道歉会显得不稳定，还会占用你用来修复问题的时间。

Gotchas

注意事项

  • Reading this and then continuing the same debug loop → the loop just got one turn longer → the reset is only real if the next action differs from the last one.
  • Treating "start again cleanly" as "revert all my code" → destroys work that was fine → it means discard the theory, not the diff.
  • Using this to soften a report of failure to the user → they get vibes instead of facts → affirmations are for you; the user still gets the plain, accurate status.
  • Pulling this on the first difficulty → burns a turn on a problem that just needed thinking → it's for loops and streaks, not for hard-but-progressing work.
  • 阅读本内容后却继续陷入相同的调试循环→只是让循环多转了一圈→只有当下一次行动与上一次不同时，重置才是有效的。
  • 将“重新出发，轻装上阵”理解为“撤销我所有的代码”→会毁掉原本没问题的工作→它指的是摒弃错误的理论，而非撤销代码变更。
  • 用本内容来向用户委婉报告失败→用户只会感受到你的情绪而非事实→这些肯定语句是给你自己的；用户依然需要清晰准确的状态报告。
  • 一遇到困难就使用本内容→会浪费时间在那些只需稍加思考就能解决的问题上→它适用于循环往复和连续失误的情况，而非难度大但仍在推进的工作。

Related Skills

相关技能

bash
npx skills add inference-sh/skills@prompt-engineering
bash
npx skills add inference-sh/skills@prompt-engineering