Skip to content
Back to skills

Boringoperator Wo

ASecurity

Author a work order for a boringoperator lane (terra build or sol review) with proper context loading, per James's professional-process directive

  • 47 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 3, 2026
ai-agentsgoawsgitapidatabase

Works with

  • cli
  • api

Security analysis

A100/100

Scanned September 20, 2026

npx -y skills add boringmarketer/kimi-first --skill boringoperator-wo --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Boringoperator Wo?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Boringoperator Wo
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/boringmarketer-boringoperator-wo/badge)](https://www.skillsdirectory.com/skills/boringmarketer-boringoperator-wo)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: boringoperator-wo
description: Author a work order for a boringoperator lane (terra build or sol review) with proper context loading, per James's professional-process directive
---

# boringoperator WO authoring

Every codex WO for ~/Code/boringoperator follows this contract:

1. FIRST LINE of every prompt: "Read dev-docs/wo-context-pack.md at the repo
   root FIRST — it is binding context (mission, laws, dialect, loop, hygiene)."
   Never re-paste pack content into prompts; reference it. Add ONLY:
   - the lane's goal in one paragraph
   - verified defects/evidence (file:line, DB audit results) — never vibes
   - lane-specific constraints (files owned by other unmerged waves, migration
     number claimed after checking main AND open branches, gates that stay off)
   - the proof contract and output shape
2. Builder lanes: terra ultra, fresh worktree, npm ci first. Reviewer lanes:
   sol, high for product surfaces, xhigh when migrations/custody in scope;
   sol writes REVIEW-<LANE>.md and is the only one who touches it.
3. Fix rounds: reference the review file by name, quote nothing that the
   review already states — "read Round N in full" + clear-condition list.
4. After every lane lands: Claude live-films, records the design verdict,
   then dispatches sol. Merge order: one train at a time; capability-map
   conflicts resolve by regeneration on the merged tree; hosted migrations
   apply BEFORE app deploys that read them.
5. SIMPLICITY COUNTERWEIGHT (James, Sep 1): codex tends to overengineer.
   Every builder WO carries the context pack's "Solution style" section as
   binding; when reviewing terra's output, treat unrequested abstraction,
   knobs, layers, or breadth as findings to strip, not bonuses. Ask of every
   diff: is there a smaller true change?
6. WO IS A FILE (Sep 1): every WO lives at dev-docs/wo-<lane>.md and is
   committed to main BEFORE dispatch; "ready to dispatch" in memory alone is
   not ready (the readback-truth WO had to be re-derived from scratch).
   Evidence rows the WO cites go to dev-docs/evidence/<lane>-<date>.json.
7. EVIDENCE-FIRST DIAGNOSIS (Sep 1): before a root-cause lane, Claude pulls
   the hosted rows read-only (Management API `database/query` as postgres,
   wrapped in `begin; set transaction read only; …; commit;`; token =
   keychain "Supabase CLI" go-keyring-base64 decoded) and states in the WO
   what is VERIFIED, what is NOT a defect, and what is NOT evidence. Two of
   three checkpointed hypotheses were wrong on the readback lane; a codex
   lane dispatched on them would have chased phantoms. When live provider
   reads are needed, D0 of the lane = a read-only diagnostic script Claude
   runs with creds — codex never sees creds.
8. MERGE TRAIN READS THE WORKTREE, NOT MEMORY: migration list, conflict
   dry-run (`git merge-tree --write-tree --name-only main <branch>`), and
   the recovery drill on the MERGED chain (main's newer migrations + the
   branch's have never been applied together). Design verdict gates the
   merge alongside sol's; the merge itself is mechanical → Sonnet seat,
   Fable reviews the merge diff and pushes.
9. Zoom-out check before dispatching any lane: does this serve the mission
   (finished work, one gesture, Main Street)? Is it dollar-ranked? Is it
   class-1 (ceremony) or product-speed (no ceremony)? Would James call it
   overengineering?
7. LESSONS COMPOUND IN THE PACK (James, Sep 2): after every certification,
   distill any NEW blocker class into dev-docs/wo-context-pack.md
   "Standing lessons" (binding; builders report against it, reviewers attack
   it first). A lesson that lives only in Claude's memory never reaches a
   lane. Keep the list short; retire items that stop recurring.
8. READ RESULTS BEFORE STAMPING: assert `gh pr view --json state` == MERGED
   before any "merged" record line or worktree removal; stamps from
   `date -u`; one proof run per worktree at a time; never
   `codex exec resume --last` with parallel lanes.

7. LOOP V3 (James, Sep 3 — binding; see `ship-lane` skill and repo dev-docs/loop-v3.md):
   classify the lane A/B/C first and never mix; ONE review pass with a checklist
   (sol once for A, design once on frames for B, none for C), ONE fix, merge;
   residue → the weekly punch batch; activation is supervised-first; ship through
   scripts/train.sh → verify-<n>-live.sh → scripts/activate-flag.sh; done = live on
   DD with a receipt. Every WO uses dev-docs/wo-template.md. The "after every lane
   lands: film → design → sol" sentence in item 4 is superseded by this item.

8. SEAT BRIEFS (Sep 4): every builder/reviewer brief says "no watcher or monitor will wake you; poll yourself (sleep 30, bounded to 40 min)". Three seats stalled on armed watchers in one night.

9. DESIGN VERDICTS (Sep 4): the design seat writes into the main checkout; the driver commits the verdict file immediately ([skip ci]) — an untracked file there makes the deploy guards refuse (dirty tree) and cost a redeploy tonight.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.