Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[External Plugin]: poka-yoke

Open
  • Is something wrong?
#2,793 4 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
58/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
github, python
Domain
content

Research direction

Start by reviewing the pinned ref 18e2bc17d682ece3f13892e7415409a9da57d031 and the submitted external.json metadata, then compare the full plugin submission with the repository’s listing conventions. Check the relationship to the skill-only submission in #2792; done means the submission is validated and either listed as the full plugin or its duplication status is resolved.

Written by the indexing model from the issue text.

Description

external-plugin needs-review:MEDIUM ready-for-review
Plugin name

poka-yoke

Short description

Mistake-proof your code, your pipeline, and your agents. Audits code for mistakes that are possible, designs APIs where misuse cannot be expressed, installs guardrails, and turns incidents into devices that prevent recurrence.

GitHub repository

rainmanjam/poka-yoke

Plugin path inside the repository

plugins/poka-yoke

Ref to review

v0.2.0

Commit SHA to review

18e2bc17d682ece3f13892e7415409a9da57d031

Version

0.2.0

License identifier

MIT

Author name

rainmanjam

Author URL

https://github.com/rainmanjam

Homepage URL

https://github.com/rainmanjam/poka-yoke

Keywords

poka-yoke, mistake-proofing, error-prevention, guardrails, code-review, defensive-design, type-safety, footgun, reliability, zero-defects

Additional notes for reviewers

poka-yoke is 11 skills, a dependency-free hazard scanner, and installable pre-commit / CI / hook templates. It applies Shigeo Shingo's mistake-proofing method to code: prefer a device that makes a wrong action impossible or self-announcing over an instruction asking someone to avoid it.

Executables, disclosed rather than left to be found. Nothing runs on install and nothing reaches the network:

  • scripts/detect_hazards.py — static scanner, standard library only, runs when a skill or the user invokes it
  • scripts/cli.py — thin dispatcher for the scanner
  • scripts/device_registry.py — regenerates a docs table; developer and CI only
  • assets/devices/claude-hooks/* — templates, not installed automatically. A PreToolUse guard the user chooses to copy in. There is no hook registration in the plugin manifest

Evidence and its limits. 591 blind-graded runs across six model families, assertions written before the runs, grader blind to configuration. The behaviour it most reliably changes is stating what a design forecloses: 45% of responses did that unprompted, 80% with the skills applied, across 132 graded verdicts. That average conceals where the effect lives: asked squarely to design an interface models already do it 77% of the time, and the large gains are in tasks where nobody asked for a design review (endpoint 14% to 79%, agent feature 33% to 83%, form 29% to 64%).

Stated with its limits, because they matter: every run is the first turn of a fresh session, so this measures the ceiling rather than what survives a long working session. The baseline is no methodology rather than a different one, so it does not establish that this method in particular caused the gain — control arms exist in the repo but have not been run. And the method costs something measurable: responses became worse at spotting a raw SQL interpolation already on the page (92% to 69%) while becoming better at changing the shape that allowed it. Raw runs, the harness and the assertion checklists are in benchmarks/.

The plugin ships to 19 runtimes via native manifests; six were behaviourally benchmarked (Fable 5, Opus 5, Sonnet 5, Haiku 4.5, Codex gpt-5.6-terra, Gemini 3.1 Pro). The other thirteen are untested and docs/install.md says so in a support-tier table.

Note on keywords: plugin.json carries 24 keywords, several containing spaces for the Claude directory's own search. The list above is the hyphenated subset your validator accepts; I have not edited plugin.json to satisfy this form, since external.json carries its own keywords field.

A skill-only copy is also open as #2792. These are complementary: that entry is for discovery in the skills index, this listing tracks the full plugin at a pinned tag so updates flow from one source rather than a fork drifting. If you would rather have only one, this listing is the one to keep.

Submission checklist
  • The plugin lives in a public GitHub repository.
  • The ref and/or sha I provided is immutable (release tag and/or full 40-character commit SHA), not a branch.
  • This submission follows this repository's contribution, security, and responsible AI policies.
  • This plugin is not already listed in the Awesome Copilot marketplace.
Dominant language
JavaScript
Stars
39.2k
Forks
5k
Avg merge
1d 17h
Merged PRs (30d)
106

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from github/awesome-copilot

All issues in github/awesome-copilot

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.