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.
Read docs/product/CONTEXT.md when it exists: the expert's words. Use its terms in code, names and the pull request, and avoid its _Avoid_ synonyms.
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).

Pick the playbook

Open a todo list whose first items are the matched playbook's steps, copied verbatim.

Task	Playbook
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.

UI work

Follow boring-design-system (with the shadcn skill): shadcn components, semantic tokens, the app's DESIGN.md, no ad hoc styling. 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 a browser driver (control-ui, or the app's npm run journey: a 375x812 viewport, overflow, accessibility snapshot, screenshot) and commit the screenshots as proof.

redesign-existing-projects: audit existing UI; its custom fonts, noise/grain textures and stock photos suit marketing pages. In apps, follow boring-design-system and shadcn tokens first.
minimalist-ui: editorial minimalist layouts; in apps, follow boring-design-system and shadcn tokens rather than its fixed fonts, colours or icon choices.

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, boring-app-template (the app's gate and journey) and verify-this for proof.

Harness notes

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.

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.

boring-mode

Boring mode

The work packet is the contract