Poka-Yoke's 11 skills (install via
claude install) force Claude Code to state design trade-offs, lifting closure awareness from 42% to 81%—but avoid them for direct bug-finding, where they degrade performance.
What Changed — A Mistake-Proofing Skill Set for Claude Code
rainmanjam/poka-yoke is a new open-source skill pack that applies Shigeo Shingo's industrial mistake-proofing method to Claude Code workflows. It ships 11 skills, a dependency-free hazard scanner for TypeScript, Python, Go, Rust, and SQL, and a pre-commit/CI integration. The core claim: with these skills loaded, Claude Code names what a design decision forecloses 81% of the time, versus 42% unprompted—measured across 591 blind-graded runs on six model families, including Opus 5 and Sonnet 5.
What It Means For You — The Trade-Off Is the Product
The key insight from the repo's honest benchmark: these skills change what Claude attends to. They make responses more constructive and forward-looking, but they measurably degrade the model's ability to spot a specific defect already present in the code. The author puts it bluntly: "If you want the bug in front of you found, use a reviewer. If you want the shape changed so that class of bug stops being expressible, use this."
So this is not a universal upgrade. It's a deliberate shift from reactive bug-fixing to proactive design hardening. For Claude Code users, that means:
-
Use Poka-Yoke during design phases — when you're planning a new feature, refactor, or interface, load the
designskill to force the model to articulate trade-offs. - Don't use it as a code reviewer — for finding existing bugs, stick with your current review workflow or a dedicated reviewer skill.
- Expect a measurable trade — loading the skill at the start of a session makes the model worse at spotting immediate defects, so sequence your tasks accordingly.
Try It Now — Setup and First Commands
Installation is straightforward:
# Clone the repo
git clone https://github.com/rainmanjam/poka-yoke.git
# Follow the install instructions (detailed in the repo's README)
# Typically involves copying skills into your ~/.claude/skills directory
Then invoke the design skill in a fresh Claude Code session:
claude> /design "I'm planning to add a caching layer to our API. What does this design foreclose?"
The skill will prompt Claude to enumerate constraints, trade-offs, and what becomes impossible—not just what it fixes. The repo also includes a hazard scanner that you can wire into pre-commit hooks:
# Example pre-commit hook (from repo)
poka-yoke scan --lang typescript --path src/
The Method — Two Axes That Do the Work
Poka-Yoke's method rests on two axes: closure (what the design makes impossible) and constraint (what it mandates). By forcing the model to address both, the skills prevent the common failure mode where an agent proposes a fix without acknowledging the new limitations it introduces. This is especially valuable for Claude Code users who rely on the agent for architectural decisions, not just code generation.
Benchmarks — What the Numbers Actually Show
The repo provides 591 blind-graded runs across six runtimes, scored by a grader that never sees which configuration produced a response. Results: Fable 5 +8.3 pp, Opus 5 +3.6 pp, Sonnet 5 +8.6 pp, Haiku 4.5 +12.9 pp—all with 95% confidence intervals excluding zero. Only 9 of 52 cells came out negative, where chance would predict ~18, suggesting the skills rarely hurt. However, the author is transparent: blind grading controls bias, not accuracy, and every run is a first turn—so real-world performance after accumulated context may differ.
What This Doesn't Do
The author explicitly lists limitations: it doesn't test against other structured methods, it doesn't measure long-session performance, and it's not a replacement for a human code review. But for Claude Code users who want to reduce design regressions, it's a promising, evidence-backed addition.
Bottom Line
Install Poka-Yoke if you want Claude Code to think in terms of what a design prevents, not just what it enables. Use it at the start of a session, and pair it with a separate review step for bug-finding. The 81% closure rate is a measurable improvement that could catch real architectural mistakes before they become defects.
Source: github.com
[Updated 25 Aug via devto_claudecode]
Separately, a bug report filed against Claude Code (issue #88346) documents a data-loss incident affecting multi-agent coordination: task JSON files in ~/.claude/tasks/ vanished roughly 5.1 seconds after a teammate completed the highest-numbered task, across versions 2.1.234–2.1.237 on Ubuntu. Four occurrences were logged with no Task tool call, external deletion, or lock contention explaining it. The issue is labeled bug, has repro, and data-loss, and remains open with no maintainer response as of publication. The loss is confined to Claude Code's internal task metadata, not user source code [per StupidLLM].
[Updated 25 Aug via reddit_claudecode]
A production-scale pain point is emerging: a Reddit user reports that Claude Design exports exceeding 5MB (300k+ characters in a single HTML file) overwhelm Claude Code, which then falls back to screenshot-based understanding and degrades frontend quality. Splitting projects page-by-page didn't help and hurt cross-page consistency. The team ships AI-powered enterprise apps in under a month and can't abandon the workflow due to Figma's credit costs. The post asks for sustainable structuring strategies without burning credits [per Reddit r/ClaudeCode].
Originally published on gentic.news
Top comments (0)