The loop, front-facing · 20 public skills
A failure happens once, becomes a skill with its exhibit named, loads for every model that works here — Claude, Codex, Grok, Kimi — and is judged by whether that failure ever happens again. Each skill below is one identity: a human page, a model skill, and a downloadable folder.
failure → exhibit → skill → both trees → every model → judged by counts — governed by the Laws of Skills
The governance law for the article ⇄ skill loop: when something becomes a skill, when a model may edit one, how edits are judged, and whose words bind — so no failure is fixed twice.
Why it exists: Governs this page: when a lesson becomes a skill, who may edit it, what proof binds it.
The complete obligational design law for making every interface, article, graph, source module, and knowledge object maximally clear and beautiful.
Why it exists: Governs every surface these skills render on.
The complete obligational writing law: opaque, decorative, ambiguous language is hostility toward the reader, and every sentence must carry meaning or be cut.
Why it exists: Governs every sentence these skills produce.
The operator's law for first contact — cold email, cold message, first approach to any counterparty. The recipient's inattention has standing; the message earns its existence from their seat, the offer carries the argument, and the register never collapses to buy attention.
Why it exists: Governs every message sent to someone who did not ask to hear from the operator.
The decision law above the Writing Law, Design Law, Skill Law, and OIP: hold the full complexity, clarify material ambiguity, preserve unresolved contradictions, identify the binding constraint, make the smallest sufficient move, finish the causal loop, and add nothing that does not improve the outcome.
Why it exists: Governs every decision: what change earns the right to happen.
Use when creating, editing, sourcing, illustrating, exporting, or deleting any article on miscsubjects.com — from the admin studio, curl, a coding agent, a Cloudflare Gateway model, or Google Sheets. One REST contract for all of them.
Failure it exists to stop · 2026-07-29: Models asked to write or edit one article burned most of their turn discovering tools, repairing formats, and choosing between competing write paths; the owner ordered one documented REST contract for every client — studio, curl, agents, Gateway models, Sheets.
The build's standing procedure for promoting itself — deciding whether, whom, when, on which channel, and with which artifact to make contact whenever something ships or a reply lands. Governs the allocation, not the copy (outreach-law governs the copy). Load whenever a new article, capability, receipt, resolved defect, or inbound reply changes what the build has to show someone, or when planning any post, email, or paid spend about the build itself.
Failure it exists to stop · 2026-07-06: Eleven external emails were sent by the outreach machinery before the confirmation gate existed, and the single-send path recorded no tracking rows — activity a promotion system took that its own records understated. Contact decisions are now computed, recorded on the ledger before the send, and gated on owner review.
Use when the owner reports a recurring failure, repeated fix, or systemic issue. Convert the failure into a skill and a mechanical gate so it stops repeating.
Failure it exists to stop · 2026-07-22: The owner had to report the same failure twice; recurring failures were fixed in chat and forgotten instead of converted into a skill plus a mechanical gate.
Use when the owner asks for a fix or reports a failure. Fix it without asking permission and without creating new problems.
Failure it exists to stop: Fixes that created new failures elsewhere, and fixes that stopped to ask permission the owner had already given.
Use when the owner restates a rule, correction, or constraint, or when a governor report shows high owner-restatement counts.
Failure it exists to stop · 2026-07: The owner restated the same rule across sessions because corrections were acknowledged conversationally and never written into a durable rule.
Use ONLY when answering an evaluative question — "anything to add", "any ideas", "anything wrong", "is this good/A+", a review, an audit, or a decision about whether something can be deleted. NEVER use it to answer a work instruction. "No" is a complete answer to a question and never a reply to an order.
Failure it exists to stop · 2026-07-23: Asked "any ideas?", models produced ideas whether or not any were good; asked "is this A+?", they appended pattern-matched suggestion tails to passing work. Same day, the first draft of this very rule made a fresh agent suppress a real infinite-loop bug to answer "Yes." — both failure modes are now clauses.
Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.
Failure it exists to stop: Skill edits judged by rereading instead of behavior — no baseline run, no with-skill run, no evidence the edit taught anything.
Use when creating new skills, editing existing skills, or verifying skills work before deployment
Failure it exists to stop: Skills written from imagination — describing what nobody failed at — that no agent could act on under pressure.
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
Failure it exists to stop · 2026-07: Concurrent sessions edited the same shared files and overwrote each other's work; the write-law claim system exists because of it.
Use when you have a written implementation plan to execute in a separate session with review checkpoints
Failure it exists to stop: Concurred plans stalled mid-phase awaiting a go-ahead nobody asked for, instead of executing through every phase.
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work
Failure it exists to stop · 2026-07-22: Completed work saved on a side line does not exist for the build until folded into the live line; stranded finished work re-alarmed for weeks.
A relentless interview to sharpen a plan or design.
Failure it exists to stop: Requirements accepted at face value; plan holes discovered after the build instead of before it.
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
Failure it exists to stop: Review feedback implemented blindly or performatively agreed with, instead of verified against the code.
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
Failure it exists to stop: Work merged without an independent review pass; defects found by the owner instead of a reviewer.
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
Failure it exists to stop · 2026-07-23: A source hash-chain broke (broken_at:0) and was patched by guesswork before the root cause — claims growing a source's body without rechaining — was isolated.
Use when implementing any feature or bugfix, before writing implementation code
Failure it exists to stop: Fixes shipped without a failing test first; the same regressions were re-fixed in later sessions.
Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback
Failure it exists to stop · 2026-07-22: Seventeen changes stranded on side lines over two months had to be forensically dispositioned; isolated worktrees with a fold-or-disposition exit would have prevented every one.
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
Failure it exists to stop · 2026-07-23: A page shipped as a blank render error and was declared done; the failure surfaced only when the rendered page was finally opened.
Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.
Failure it exists to stop: Features declared working from API responses or source reads while the rendered page was broken; the build's rule that only the rendered view counts came from this failure class.
Use when you have a spec or requirements for a multi-step task, before touching code
Failure it exists to stop: Multi-step work delivered out of prerequisite order — a value referenced before the step that produces it.
24 operational skills are private to the build and not listed. Machine index: /api/skills · full set as one folder: skills.zip