Redesign software interfaces and workflows to prevent human and system errors.
npx skills add https://github.com/NlightNFotis/skills --skill mistake-proofing
Please help me install this Agent Skill. Skill: mistake-proofing Source: https://github.com/NlightNFotis/skills/tree/main/mistake-proofing Command: npx skills add https://github.com/NlightNFotis/skills --skill mistake-proofing
This Skill helps prevent costly software and operational mistakes by redesigning APIs, CLIs, configs, and workflows so unsafe actions cannot be expressed or are rejected immediately. It is especially useful when teams keep relying on training, warnings, or after-the-fact detection instead of building safety into the system itself.
Use the mistake-proofing skill to audit a risky API, CLI, config, or runbook and propose design changes that make the most dangerous mistakes impossible or immediately rejected.
High-intent search queries and answers about installing and using this skill.
To prevent invalid states in API design, you apply poka-yoke methods using strict types, schemas, and state machines so unsafe actions cannot be expressed or are rejected immediately at the boundary. This moves defects from production incidents to structural impossibility.
Making destructive CLI actions impossible by design involves auditing flag combinations and implementing safer defaults. You redesign the CLI workflow using fixed-value and motion-step poka-yoke methods to prevent dangerous commands from executing.
You stop repeated operator mistakes by redesigning deployment workflows and migrations so skipped steps or invalid inputs are structurally blocked. Applying contact and motion-step poka-yoke methods ensures unsafe actions are rejected immediately at the boundary.
Error prevention should be used over after-the-fact detection when teams repeatedly rely on training or warnings instead of building safety into the system. Prevention-first design uses schemas and safer defaults to make invalid states unrepresentable, moving defects up the ladder from incidents to structural impossibility.
When you cannot fully prevent dangerous actions in a configuration schema, you design andon failure behavior. This defines loud, visible stop-the-line mechanisms that halt the process immediately, ensuring residual risks are caught instead of silently causing incidents.
stacklokValidate documentation YAML examples against Kubernetes CRD schemas.
diiviikk5Warn on destructive commands and restrict file edits to a specified directory.
TabTabGoGenerate, edit, and validate Expo EAS workflow YAML files against schema standards.
fockusApply kaizen principles to incrementally improve software quality and process design.
