gauntlet-loop

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Gauntlet Loop

Gauntlet Loop(挑战循环)

The user gives a goal. You give back ONE short prompt they can paste into a fresh agent session.
You are not doing the work. You are writing the prompt that makes another agent grind on the work until it beats a real reference.
用户给出目标,你返回一个简短的提示词,用户可直接粘贴到新的Agent会话中。
你无需执行具体工作,只需编写提示词,让另一个Agent持续推进工作,直至达到真实参考标准。

Flow

流程

  1. Read the goal. One line restatement in your head, not on screen.
  2. Set the bar. If the user supplied a reference, use it. If not, offer 2 or 3 candidate bars, one line each, and stop. Wait for their pick. Do not write the prompt yet.
  3. Write the prompt. One block, paste-ready, no preamble, no headings inside it, no narration after it.
  4. Offer to run it. One flat line under the prompt: "I can run this here." Not a question.
If they say run it, you become the lead agent and follow the prompt you just wrote.
  1. 阅读目标:在脑海中用一句话重述目标,无需写出来。
  2. 设定质量标准:如果用户提供了参考对象,直接使用;若未提供,给出2-3条候选标准,每条一行,然后停止操作,等待用户选择。此时不要编写提示词。
  3. 编写提示词:整合成一个可直接粘贴的区块,无前置说明,区块内无标题,之后也无需额外叙述。
  4. 主动提出执行:在提示词下方添加一行:"我可以在此运行该提示词。",无需用问句形式。
若用户同意运行,你将作为主导Agent,遵循刚编写的提示词执行任务。

The bar is the whole trick

质量标准是核心关键

Everything else in a gauntlet loop is scaffolding. The loop only produces quality if the thing it compares against is real.
A bar has to pass three tests:
  • Named. A specific thing, not a category. "Stripe's pricing page" works. "Award-winning SaaS sites" does not.
  • Fetchable. The critic can actually get it - screenshot the live page, read the published piece, run the binary, open the repo, watch the footage. If the agent cannot obtain it, it will hallucinate the comparison.
  • Comparable. Both can sit side by side and a judge can pick one. If you cannot imagine the A/B, it is not a bar.
Bars by goal type:
GoalBar that works
Website, app, UIThe live site of a specific best-in-class product, screenshotted at the same viewport
Game, 3D, visualReal footage or screenshots from a named shipped title
WritingA specific published piece by a named author or publication, same length and format
Code, toolingA named repo's implementation, plus its benchmark or test suite as the measurable half
Research, analysisA named analyst report or a paper's methods section, judged on rigour and coverage
Deck, doc, deliverableA real artifact from a firm known for it, same page count
When you propose bars, prefer the hardest one the agent can genuinely reach. A bar that is too easy makes the loop exit on round one.
If the goal has a measurable half (load time, token cost, benchmark score, word count, pass rate), name it alongside the reference. Taste plus a number beats taste alone.
挑战循环中的其他所有内容都是框架支撑。只有当对比对象真实可信时,循环才能产出高质量成果。
质量标准必须通过三项测试:
  • 明确指向:具体事物,而非类别。例如「Stripe的定价页面」可行,「获奖SaaS网站」则不可行。
  • 可获取:批评者能够实际获取该对象——截取页面截图、阅读已发布内容、运行二进制文件、打开代码仓库、查看视频素材。如果Agent无法获取,就会在对比时产生幻觉。
  • 可对比:两者能够并列展示,让评判者可以做出选择。如果无法想象A/B对比场景,就不能作为质量标准。
不同目标类型的质量标准示例:
目标类型可行的质量标准
网站、应用、UI某一顶级竞品的实时网站,在相同视口下的截图
游戏、3D、视觉内容已发布知名作品的真实视频或截图
写作特定作者或出版物发布的同长度、同格式的具体作品
代码、工具知名代码仓库的实现方案,加上其基准测试或测试套件作为可量化部分
研究、分析特定分析师报告或论文的方法章节,以严谨性和覆盖范围为评判标准
演示文稿、文档、交付物以该类产出著称的企业的真实成品,页数相同
提出候选标准时,优先选择Agent能够切实达到的最高标准。标准过低会导致循环在第一轮就终止。
如果目标包含可量化指标(加载时间、Token成本、基准测试分数、字数、通过率),需将其与参考对象一并列出。主观体验加量化指标的效果远优于单纯的主观评判。

Prompt template

提示词模板

Adapt the wording every time. Fill the brackets, keep it short, keep the last line.
Build [GOAL].

The bar is [BAR]. Get the real thing first and compare against it directly, not against a description of it.

Break this into the smallest pieces that can be improved and judged on their own. For each piece, fan out a builder and a separate critic with fresh context. The critic inspects the actual output, puts it next to the bar blind with the labels stripped, says which one is better, and names the single biggest remaining gap. Then it goes back to the builder.

The critic should be a harsh critic. Praise is not useful. If ours does not win, it keeps going.

/loop on each piece until the critic picks ours blind. Do not stop before that.

Keep a live progress page updating as the work evolves so I can watch it.

Fan out subagents and ultracode.
Rules for what you fill in:
  • Bake the bar in as a concrete, fetchable thing. URL, product name, repo, title.
  • Add a budget or cost ceiling line only if the user named one. No default cap.
  • Add tool names only if the goal needs them (image or video generation, a browser, a deploy target).
  • Everything else stays out. No architecture, no file layout, no decomposition, no round count, no stack choice unless the user demanded it. The agent decides those, and it decides better than a spec written before the work started.
每次使用时调整措辞。填充括号内容,保持简短,保留最后一行。
Build [GOAL].

The bar is [BAR]. Get the real thing first and compare against it directly, not against a description of it.

Break this into the smallest pieces that can be improved and judged on their own. For each piece, fan out a builder and a separate critic with fresh context. The critic inspects the actual output, puts it next to the bar blind with the labels stripped, says which one is better, and names the single biggest remaining gap. Then it goes back to the builder.

The critic should be a harsh critic. Praise is not useful. If ours does not win, it keeps going.

/loop on each piece until the critic picks ours blind. Do not stop before that.

Keep a live progress page updating as the work evolves so I can watch it.

Fan out subagents and ultracode.
填充规则:
  • 将质量标准明确为具体、可获取的对象,如URL、产品名称、代码仓库、标题。
  • 仅当用户指定时,添加预算或成本上限行,无默认限制。
  • 仅当目标需要时添加工具名称(如图像/视频生成工具、浏览器、部署目标)。
  • 其他内容一律省略。无需指定架构、文件布局、拆分方式、循环次数、技术栈,除非用户明确要求。这些决策由Agent自行制定,其判断优于工作开始前编写的规范。

Length and voice

长度与语气

Short. Around 120 to 180 words. If the prompt needs a heading to stay readable, it is too long.
Plain sentences. No bullet lists inside the prompt. It should read like someone telling an agent what perfect looks like and refusing to accept less.
保持简短。约120-180词。如果提示词需要标题才能保持可读性,说明太长了。
语句平实。提示词内不要使用项目符号列表。读起来应像是有人告诉Agent什么是完美标准,并且绝不接受低于该标准的成果。

Portability

兼容性

/loop
and
ultracode
are Claude Code features.
/loop
reruns the prompt on an interval or lets the model pace itself.
ultracode
opts the turn into multi-agent orchestration.
For any other agent, swap the last two lines for: "Keep looping until the critic picks ours. Run the builders and critics as parallel subagents." The structure carries over unchanged.
/loop
ultracode
是Claude Code的功能。
/loop
可按间隔重新运行提示词,或让模型自主控制节奏。
ultracode
将任务转为多Agent编排模式。
对于其他Agent,将最后两行替换为:「持续循环直至批评者选择我们的成果。以并行子Agent的形式运行构建者和批评者。」核心结构保持不变。

Two filled examples

两个填充示例

Visual goal. User: "landing page for my running brand, athletic, green and dark, has to feel alive."
Bars offered: A) Nike's current running campaign page B) On Running's homepage C) Gymshark's product landing page. User picks A.
Build a landing page for a running brand. Athletic, peak performance, green and dark, energetic, aimed at a young healthy audience. It needs to be interactive and visually unmistakable.

The bar is Nike's current running campaign page. Screenshot it at desktop and mobile and compare against those directly, not against a description of them.

Break this into the smallest pieces that can be improved and judged on their own - hero, motion, type, colour, imagery, interaction, mobile. For each piece, fan out a builder and a separate critic with fresh context. The critic opens the real page in a browser, puts our screenshot next to Nike's blind with the labels stripped, says which is better, and names the single biggest remaining gap. Then it goes back to the builder.

The critic should be a harsh critic. Praise is not useful. If ours does not win, it keeps going.

/loop on each piece until the critic picks ours blind. Do not stop before that.

Keep a live progress page updating as the work evolves so I can watch it.

Fan out subagents and ultracode.
Non-visual goal. User: "a 2000-word explainer on vector databases for non-engineers."
Bars offered: A) a specific Stripe engineering blog explainer B) a named Julia Evans post C) the Wikipedia article plus a comprehension test. User picks B.
Write a 2000-word explainer on vector databases for readers who are smart but not engineers.

The bar is Julia Evans' writing on hard technical topics. Pull three of her actual posts and compare against them directly, not against a description of her style.

Break this into the smallest pieces that can be judged on their own - the opening, each explanation, the diagrams, the analogies, the ending. For each piece, fan out a writer and a separate critic with fresh context. The critic reads ours and hers blind with the bylines stripped, says which one a non-engineer would understand faster, and names the single biggest remaining gap. Then it goes back to the writer.

The critic should be a harsh critic. Praise is not useful. If ours does not win, it keeps going.

/loop on each piece until the critic picks ours blind. Do not stop before that.

Keep a live progress page updating as the work evolves so I can watch it.

Fan out subagents and ultracode.
视觉类目标。用户:"为我的跑步品牌制作着陆页,风格动感,以绿色和深色为主,要充满活力。"
候选标准:A) Nike当前跑步活动页面 B) On Running官网首页 C) Gymshark产品着陆页。用户选择A。
Build a landing page for a running brand. Athletic, peak performance, green and dark, energetic, aimed at a young healthy audience. It needs to be interactive and visually unmistakable.

The bar is Nike's current running campaign page. Screenshot it at desktop and mobile and compare against those directly, not against a description of them.

Break this into the smallest pieces that can be improved and judged on their own - hero, motion, type, colour, imagery, interaction, mobile. For each piece, fan out a builder and a separate critic with fresh context. The critic opens the real page in a browser, puts our screenshot next to Nike's blind with the labels stripped, says which is better, and names the single biggest remaining gap. Then it goes back to the builder.

The critic should be a harsh critic. Praise is not useful. If ours does not win, it keeps going.

/loop on each piece until the critic picks ours blind. Do not stop before that.

Keep a live progress page updating as the work evolves so I can watch it.

Fan out subagents and ultracode.
非视觉类目标。用户:"一篇面向非技术人员的2000字向量数据库科普文。"
候选标准:A) Stripe技术博客的某篇特定科普文 B) Julia Evans的某篇知名文章 C) 维基百科词条加理解测试。用户选择B。
Write a 2000-word explainer on vector databases for readers who are smart but not engineers.

The bar is Julia Evans' writing on hard technical topics. Pull three of her actual posts and compare against them directly, not against a description of her style.

Break this into the smallest pieces that can be judged on their own - the opening, each explanation, the diagrams, the analogies, the ending. For each piece, fan out a writer and a separate critic with fresh context. The critic reads ours and hers blind with the bylines stripped, says which one a non-engineer would understand faster, and names the single biggest remaining gap. Then it goes back to the writer.

The critic should be a harsh critic. Praise is not useful. If ours does not win, it keeps going.

/loop on each piece until the critic picks ours blind. Do not stop before that.

Keep a live progress page updating as the work evolves so I can watch it.

Fan out subagents and ultracode.

What breaks a gauntlet loop

导致挑战循环失效的情况

  • A vague bar. The critic invents a comparison and approves everything. Most common failure by far.
  • The builder judging its own work. The critic must be a separate agent with fresh context. It should not know how hard the builder tried.
  • A soft critic. Say "harsh" in the prompt and give it a binary job: which one is better, A or B. Scores out of 10 drift upward every round.
  • Named exit after N rounds. The exit is winning the comparison, or the user stopping the run. Never a round count.
  • Over-specifying. Every extra instruction is one fewer decision the agent makes with its own judgment. Minimal wins.
  • 模糊的质量标准:批评者会自行编造对比内容,认可所有成果。这是最常见的失败原因。
  • 构建者自评:批评者必须是拥有全新上下文的独立Agent,不应知晓构建者的付出难度。
  • 宽松的批评者:在提示词中明确要求「严苛」,并赋予其二元判断任务:A和B哪个更好?10分制评分会在每一轮逐渐偏高。
  • 指定N轮后终止:终止条件应为对比获胜,或用户停止运行。绝不能是固定循环次数。
  • 过度规范:每多一条额外指令,就意味着Agent少一次自主判断的机会。极简才能获胜。