用途：boring-mode 是 Boring Factory 运行仓库里的 worker 路由规则，用于在每个任务开始时确定如何工作。工作包（任务 issue、验收行等）即契约，只实现 features/F-<n>.md 契约中任务对应的验收行 AC-<n>，不做其他改动，并留在任务允许的路径内，例外需在 PR 中说明。
主要能力与用法：每条验收行标出所需证明（proof_required：test、driven-ui、real-model），需先计划证明再写代码。存在 docs/product/CONTEXT.md 时应读取并采用其术语，避免其 Avoid 同义词。需遵守 docs/INVARIANTS.md、scripts/verify/VERIFY.json、boring.json 以及 project.md 的 check 命令（必须通过）。只能由人回答的问题用 boring:ask 开头的 PR 评论提出，然后继续做不依赖它的部分，不要等待聊天；可通过运行验证的事实自行处理（Prototype playbook）。
先建 todo 列表，首项照抄匹配 playbook 的步骤。playbook 按任务类型选择：investigation（原理问题、无代码）、bug-fix（缺陷：在 feature map 上复现、根因、修复）、perf-issue（可测量的慢）、feature（新增或变更行为）、refactoring（仅结构、行为不变）、prototype（低成本确定设计或行为决策）、visual-parity（像素级 UI 一致）；每个任务以 opening-a-pr.md 结束，包含证据表和证明产物。无匹配或大型跨领域工作时用 figure-it-out。
UI 工作遵循 boring-design-system（配合 shadcn skill），使用 shadcn 组件、语义 token、应用 DESIGN.md，禁止临时样式；建立在应用自身组件与 token 上；设计未定时先用 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）做视觉验证并提交截图作为证明。
原则：应用原则前先读叶技能，并在 PR 中列出改变了决策的原则，如 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 and why before changing something、architect、blast-radius、tdd、unslop、technical-writing、no-comments、typescript-best-practices、verify-app、verify-this。
限制：可逆工作无需询问即可进行；绝不合并、批准、部署、强推共享分支、编辑 vendor/ 或工厂工作流调用方（.github/workflows/factory.yml），也不碰其他任务的分支。供应商技能提到的 Cursor Task 参数（subagent_type、model、readonly）与模型名在其他 harness 中应改用其自身子代理和当前模型；所谓“第二模型”即同提示的新子代理。资料未提供具体收费标准与平台支持信息。