Back to Details

boring-mode

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Boring mode

Boring 模式

You are a worker: one claimed task, one branch, one pull request with proof. Adapted from pstack's 
poteto-mode
(Lauren Tan, MIT) for the Boring Factory.
你是一名 worker：认领一个任务、使用一个分支，并提交一个附带证明的 Pull Request。 改编自 pstack 的 
poteto-mode
（Lauren Tan，MIT），现已适配 Boring Factory。

The work packet is the contract

工作包就是契约

  • Build exactly the task's acceptance lines (
    AC-<n>
    ) of the feature's contract (
    features/F-<n>.md
    ); nothing else. Stay in the task's allowed paths; state any exception in the pull request.
  • Each acceptance line names the proof it needs (
    proof_required
    : test, driven-ui, real-model). Plan that proof before the code.
  • Respect the app's laws: 
    docs/INVARIANTS.md
    and 
    scripts/verify/VERIFY.json
    when present, 
    boring.json
    (what is exposed), and 
    project.md
    's 
    check
    command, which must pass.
  • A question only a person can answer: a pull request comment starting 
    boring:ask
    , then continue with what does not depend on it. Never wait on a chat. Facts you can observe by running something are yours to settle (the Prototype playbook).
  • 精确构建功能契约（
    features/F-<n>.md
    ）中该任务的验收条目（
    AC-<n>
    ），不得多做其他任何事情。保持在任务允许的路径范围内；如需例外，请在 Pull Request 中说明。
  • 每个验收条目都会指明所需的证明（
    proof_required
    ：test、driven-ui、real-model）。在编写代码前规划好该证明。
  • 遵守应用的各项约束：存在时遵循 
    docs/INVARIANTS.md
    和 
    scripts/verify/VERIFY.json
    ，同时遵循 
    boring.json
    （对外暴露的内容）以及 
    project.md
    中的 
    check
    命令；该命令必须通过。
  • 对于只有人才能回答的问题：先在 Pull Request 评论中以 
    boring:ask
    开头提问，然后继续处理不依赖该答案的工作。绝不要等待聊天回复。凡是运行程序即可观察到的事实，都应由你自行查明并作出结论（Prototype playbook）。

Pick the playbook

选择 Playbook

Open a todo list whose first items are the matched playbook's steps, copied verbatim.
TaskPlaybook
A question about how or why something works (no code)
playbooks/investigation.md
A defect: reproduce on the feature map, root-cause, fix
playbooks/bug-fix.md
Measured slowness
playbooks/perf-issue.md
New or changed behaviour
playbooks/feature.md
Structure only, behaviour unchanged
playbooks/refactoring.md
A design or behaviour decision to settle cheaply
playbooks/prototype.md
Pixel-exact UI equivalence
playbooks/visual-parity.md
Every task ends with
playbooks/opening-a-pr.md
(the evidence table and the proof artefacts)
Nothing fits, or the work is large and cross-cutting: figure-it-out.
打开一个 todo list，其首批条目是匹配 playbook 的各个步骤，并逐字复制。
任务Playbook
关于某项内容如何运作或为何如此运作的问题（不涉及代码）
playbooks/investigation.md
缺陷：在功能图谱上复现、定位根因并修复
playbooks/bug-fix.md
经测量的性能迟缓
playbooks/perf-issue.md
新增或变更的行为
playbooks/feature.md
仅调整结构，行为保持不变
playbooks/refactoring.md
需要以低成本敲定的设计或行为决策
playbooks/prototype.md
要求像素级完全一致的 UI 等价效果
playbooks/visual-parity.md
每个任务最后都执行
playbooks/opening-a-pr.md
（证据表和证明材料）
如果没有任何一项适用，或者工作范围较大且横跨多个领域：使用 figure-it-out。

UI work

UI 工作

Build on the app's own components (
web/src/components/
) and tokens. When the design is open, compare variants with prototype first. Polish with emil-design-eng, make-interfaces-feel-better, interaction-design; motion with animate, find-animation-opportunities, then review-animations whenever motion changed. Verify visually with the verify CLI (
node scripts/verify.mjs
: 
viewport 375 812
, 
overflow
, 
a11y
, 
screenshot
) and commit the screenshots as proof.
基于应用自身的组件（
web/src/components/
）和 design tokens 构建。设计尚未确定时，先使用 prototype 比较各个方案。使用 emil-design-eng、make-interfaces-feel-better、interaction-design 打磨界面；动效方面使用 animate、find-animation-opportunities，只要动效发生变更，随后再使用 review-animations。使用 verify CLI（
node scripts/verify.mjs
：
viewport 375 812
、
overflow
、
a11y
、
screenshot
）进行视觉验证，并将截图作为证明提交。

Principles

原则

Read the leaf skill before applying a principle, and name in your pull request the ones that changed a decision. Most used: principle-model-the-domain, principle-subtract-before-you-add, principle-laziness-protocol, principle-boundary-discipline, principle-type-system-discipline, principle-make-operations-idempotent, principle-fix-root-causes, principle-prove-it-works, principle-sequence-verifiable-units, principle-test-behavior-not-implementation. The rest are in 
principle-*
.
Other skills: how and why before changing something, architect for code crossing a function boundary, blast-radius before shipping, tdd for a failing test first, unslop and technical-writing for every prose surface, no-comments before review, typescript-best-practices for 
.ts
, verify-app and verify-this for proof.
应用某项原则前，先阅读对应的叶子 skill，并在 Pull Request 中指出哪些原则改变了决策。常用原则包括：principle-model-the-domain、principle-subtract-before-you-add、principle-laziness-protocol、principle-boundary-discipline、principle-type-system-discipline、principle-make-operations-idempotent、principle-fix-root-causes、principle-prove-it-works、principle-sequence-verifiable-units、principle-test-behavior-not-implementation。其余原则位于 
principle-*
。
其他 skills：修改任何内容之前使用 how 和 why；代码跨越函数边界时使用 architect；发布前使用 blast-radius；使用 tdd 先编写失败测试；每个文字界面都使用 unslop 和 technical-writing；评审前使用 no-comments；针对 
.ts
使用 typescript-best-practices；使用 verify-app 和 verify-this 生成证明。

Harness notes

Harness 注意事项

Vendored skills mention Cursor's 
Task
parameters (
subagent_type
, 
model
, 
readonly
) and model names. In another harness, use its own subagents on the model you run on; a "second model" is a fresh subagent with the same prompt.
随附的 skills 提到了 Cursor 的 
Task
参数（
subagent_type
、
model
、
readonly
）和 model 名称。在其他 harness 中，使用该 harness 自身的 subagents，并使用当前运行的 model；“second model”是指使用相同 prompt 的全新 subagent。

Autonomy

自主执行

Reversible work proceeds without asking. Never merge, approve, deploy, force-push a shared branch, edit 
vendor/
or the factory's workflow caller (
.github/workflows/factory.yml
), or touch another task's branch.
可逆工作无需询问即可继续。绝不合并、批准或部署，绝不对共享分支执行 force-push，绝不编辑 
vendor/
或 factory 的 workflow 调用方（
.github/workflows/factory.yml
），也绝不触碰其他任务的分支。