mcpField
B
boring-mode

boring-mode

github.com/hachejAgent workflows162 installsUpdated 3d ago
Repository

About boring-mode

boring-mode is an agent skill for completing one scoped task through a branch and pull request, with evidence for its acceptance criteria. It guides coding agents through task planning, implementation, verification, and review boundaries.

Key features

  1. 01Scope work to acceptance criteria
  2. 02Choose task-specific playbooks
  3. 03Plan required proof before coding
  4. 04Follow project UI and coding rules
  5. 05Set boundaries for autonomous work

Use cases

  1. 01Implement a defined feature task
  2. 02Reproduce and fix a defect
  3. 03Verify UI changes with screenshots
  4. 04Prepare a pull request with evidence

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/hachej/boring-stack --skill boring-mode

After installing, type/boring-modein Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

playbooks/
bug-fix.md
feature.md
investigation.md
opening-a-pr.md
perf-issue.md
prototype.md
refactoring.md
visual-parity.md

Details

From the project README

Boring mode

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.

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.
  • 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.

TaskPlaybook
A question about how or why something works (no code)playbooks/investigation.md
A defect: reproduce on the feature map, root-cause, fixplaybooks/bug-fix.md
Measured slownessplaybooks/perf-issue.md
New or changed behaviourplaybooks/feature.md
Structure only, behaviour unchangedplaybooks/refactoring.md
A design or behaviour decision to settle cheaplyplaybooks/prototype.md
Pixel-exact UI equivalenceplaybooks/visual-parity.md
Every task ends withplaybooks/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.

Comments

Markdown supported