Mistake-Proof Code Using Toyota Production System Principles

This skill applies Shigeo Shingo's poka-yoke (mistake-proofing) method from the Toyota Production System to software design. Its core premise: a comment, docstring, wiki page, code-review checklist, or CLAUDE.md line saying "don't do X" is not a poka-yoke - it is training, and training degrades. A real poka-yoke is a device: a type, a constraint, a hook, a schema, a state machine, something that either makes the mistake physically impossible or announces it the instant it happens. The method classifies every hazard on two axes. The first, regulatory function, is a strict preference ladder: Control (the mistake is impossible - a type that won't compile, a NOT NULL/CHECK/unique constraint, a protected branch), Warning (the mistake is possible but announced immediately - a lint error, a failing CI gate, a runtime assertion, a confirmation prompt naming the exact thing being destroyed), and Detection (the mistake ships and something finds it afterward - tests, monitoring, reconciliation). The second axis, setting function, gives three inspection lenses to run over any interface: Contact (can the wrong thing fit - distinct types instead of shared primitives, parse-don't-validate at boundaries), Fixed-value (can the wrong count or an incomplete set pass - exhaustive matches, required fields, row-count guards), and Motion-step (can steps happen out of order or be skipped - typestates, builders that can't .build() early, illegal-transition-free state machines, idempotency keys).

Use it when the user asks to "poka-yoke this", "mistake-proof it", or "make this harder to get wrong"; when designing an interface, schema, or state machine and the goal is to make invalid states unrepresentable; when auditing existing code for footguns; or after an incident, when the fix needs to close the whole class of mistake rather than just the one instance that already happened - especially around money, auth, permissions, deletion, migrations, and pipelines, where failure tends to be silent. It is not a substitute for domain review, security review, testing, observability, or incident response - it complements them. It also does not prove a design is correct; it only reduces predictable misuse and cannot cover hazards the analysis never identifies.

• Input: any subject with a workflow to protect - a diff, an interface, a schema, a runbook, a release checklist, a prompt template, even a non-software process, plus (if the request is bare) the current diff or file under discussion as the default subject.
• Output: for each hazard found, a named mistake, what happens when it occurs, whether it is silent, what exists today to stop it, and a proposed device stated with the exact rung (Control/Warning/Detection) it reaches - with an explicit note of what a higher rung would have required when the proposal lands on Warning or Detection instead of Control.

Engineers and reviewers designing interfaces, schemas, or state machines - or investigating an incident - who want mistakes designed out of the system rather than documented against, particularly for destructive, financial, authentication, and authorization flows.