boring-mode

Boring 模式

你是一名工作者：一个已认领的任务、一个分支、一个有证据的拉取请求。 改编自 pstack 的 poteto-mode（Lauren Tan，MIT），用于 Boring Factory。

工作包就是约定

• 严格完成此任务对应功能约定（features/F-<n>.md）中的验收条目（AC-<n>）；不要做其他事。仅在任务允许的路径中操作；如有例外，请在拉取请求中说明。
• 每条验收条目都注明所需证据（proof_required）：测试、驱动式 UI、真实模型。编码前先规划这些证据。
• 如果 docs/product/CONTEXT.md 存在，请阅读：其中包含专家的表述。在代码、名称和拉取请求中使用其中的术语，并避免使用其中标记为 _Avoid_ 的同义词。
• 遵守应用的规则：存在时遵循 docs/INVARIANTS.md 和 scripts/verify/VERIFY.json，遵循 boring.json（公开的内容），并运行 project.md 中的 check 命令；该命令必须通过。
• 只有人才能回答的问题：在拉取请求中添加以 boring:ask 开头的评论，然后继续处理不依赖该问题的部分。绝不要等待聊天回复。可以通过运行程序观察到的事实，由你自行查明（遵循 Prototype 操作手册）。

选择操作手册

创建待办清单，首批条目应为匹配的操作手册步骤，并逐字复制。

任务	操作手册
关于某件事如何运作或为何如此的问题（不涉及代码）	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（证据表和证明材料）

如果没有合适的操作手册，或工作规模较大且涉及多个领域：自行判断。

UI 工作

遵循 boring-design-system（并使用 shadcn 技能）：采用 shadcn 组件和语义化令牌，遵照应用的 DESIGN.md，不要临时设计样式。基于应用自身的组件（web/src/components/）和令牌进行构建。如果设计尚未确定，先用 prototype 比较不同方案。 使用 emil-design-eng、make-interfaces-feel-better、interaction-design 进行打磨；如有动效变更，使用 animate、find-animation-opportunities，随后再使用 review-animations。使用浏览器驱动工具（control-ui，或应用的 npm run journey：375x812 视口、溢出检查、无障碍快照、截图）进行视觉验证，并将截图作为证据提交。

• redesign-existing-projects：审查现有 UI；其自定义字体、噪点／颗粒纹理和图库照片适合营销页面。在应用中，优先遵循 boring-design-system 和 shadcn 令牌。
• minimalist-ui：编辑风格的极简布局；在应用中，应遵循 boring-design-system 和 shadcn 令牌，而非其固定字体、颜色或图标选择。

原则

应用原则前先阅读对应的叶子技能，并在拉取请求中说明哪些原则改变了决策。最常用的原则包括：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-*。

其他技能：进行变更前先弄清 how 和 why；跨越函数边界的代码使用 architect；发布前使用 blast-radius；先编写失败测试再使用 tdd；每个文字界面都使用 unslop 和 technical-writing；评审前使用 no-comments；处理 .ts 文件时使用 typescript-best-practices；使用 boring-app-template（应用的门禁和旅程）以及 verify-this 提供证明。

Harness 说明

Vendored 技能提到了 Cursor 的 Task 参数（subagent_type、model、 readonly）和模型名称。在其他 Harness 中，请使用其自身的子 Agent，并采用你正在运行的模型；“第二个模型”指使用相同提示词启动一个全新的子 Agent。

自主性

可逆的工作可直接进行，无需询问。切勿合并、批准、部署、强制推送共享分支、编辑 vendor/ 或工厂的工作流调用方（.github/workflows/factory.yml），也不要触碰其他任务的分支。