NoPUA and the fear prompt it was built to replace

Nine debugging scenarios carry the entire benchmark claim

NoPUA is a prompt asset rather than a program, so the whole argument has to be carried by numbers, and there are not many of them. The README describes one first-party run: the same model, nine debugging scenarios, one condition driven by fear and one driven by trust. The fear condition found 25 hidden issues. The trust condition found 51. That is where the +104% figure in the header comes from, and the same block says the result is limited to the reported scenarios and conditions. The file is also careful in a way most projects are not, adding that these are benchmark issues rather than a claim about production incidents.

Both caveats come from the project itself, which cuts both ways. A reader gets an honest boundary, but an unverified one: the author ran the comparison, the sample is nine scenarios, and the README labels the run first-party without describing any independent rerun of the 25 and 51 counts. The top level does include a `benchmark/` directory, yet the section reporting the figures gives no command for regenerating them, so a team cannot cheaply settle the question against its own codebase.

Same standards, different fuel: the concession under the headline

NoPUA positions itself against one specific public skill rather than against prompting in general. That target is the PUA skill at `tanweai/pua`, which tells an agent that other agents are waiting for the same bug and that a 3.25 performance review is looming. Two of its lines, quoted here as they appear:

"Other models can solve this. You might be about to graduate."
"This 3.25 is meant to motivate you, not deny you."

The engineering underneath is not disputed. The README calls the methodology sound, naming exhaustion of options, verification of work, searching before asking, and initiative, then attacks only the fuel. What follows is worth more to an adopter than any benchmark figure: `Same methodological core. Same standards.` That concession sits directly beneath a +104% claim, and it narrows what the evidence can mean. If the core is identical, the measured gap is a comparison of framing alone, and the design work in this repository is persuasion rather than process.

For a team that already runs the fear skill, the diff is one paragraph of wording. The habits do not change. What changes is the sentence the agent reads at the moment it gets stuck.

Where the prompt text sits inside the repository

Almost nothing here compiles. The top level holds `SKILL.md`, `AGENTS.md`, `SECURITY.md`, `LINEAGE.md` and a Node validator named `validate.mjs`. Skill content lives in `skills/`, `agents/` and `commands/`, and the same body of text is mirrored per harness in `codex/`, `cursor/` and `kiro/`, alongside a `.claude-plugin/` directory for the plugin layout. That fan-out is the real cost of this project: one idea, at least four harness trees, and a validator whose job is to notice when the copies drift apart.

The badge in the header points at `validate.yml`, so the drift check is wired into CI rather than left to reviewers. `examples/lite-template.md` offers a trimmed shape for people who do not want the whole skill, and `paper/`, `docs/` and `promotion/` sit alongside. The same header carries WeChat group images, an AtomGit mirror and an arXiv identifier, which makes the repository double as a distribution page.

One inconsistency deserves naming. The project's language tag is Python, and no Python module appears among the top-level entries. Everything executable at the root is `validate.mjs`; everything that changes agent behaviour is Markdown.

The setup step is a file copy into the harness you already use

NoPUA has no installer, no package name and no flag worth memorising. You obtain it from the repository, or from the skills.sh listing the header links to, and you place the tree your agent actually reads. Which tree that is depends on whether you drive Claude Code, Codex CLI, Cursor or Kiro, and the per-harness directories exist so that decision is made once rather than per prompt. The README links an `Install` section from its navigation bar for the exact steps, and those commands belong to that section rather than to this page.

A first real use is easier to judge than a first install. Load the skill, hand the agent a bug, and watch the moment it would normally claim victory. Under the fear framing it says fixed without running anything. Under this one it runs the build and pastes the output as proof. That single checkpoint tells you more about whether the skill is active than any directory listing will, and it costs you one bug report.

Human fear research is doing the causal work

The evidence section rests on a chain of psychology papers, and it is worth knowing what kind. There is work on threat responses and the amygdala by Öhman and colleagues in 2001, cue utilisation under arousal by Easterbrook in 1959, acute stress and executive function across 51 studies and 223 effect sizes by Shields and colleagues in 2016, and evaluative pressure against creative output by Byron and Khazanchi in 2012. All four concern human beings under threat.

NoPUA transfers them to models in a single move, and it shows its working in the open: fear narrows attention, so a model driven by fear of replacement will optimise for the safest-looking answer instead of the best one. The leap is not small. A human threat response involves a body, a nervous system and a lifetime of learning. A token generator has none of those parts, and no measurement of narrowed attention inside a model appears anywhere in the repository. The citations establish that pressure shapes problem solving in people. They do not establish that a paragraph of prompt text changes what a model attends to.

The nine-scenario run is the only model-level evidence offered, and the README itself keeps it bounded to the reported conditions.

Five checkpoints where the framing shows up in the output

The README tabulates five moments and, usefully, splits each into a scared answer and a trusted one. Completion is the clearest: the word fixed with no test run, against running the build and pasting the output. Uncertainty comes next: something invented, against naming what was verified and what is not yet known. A hard problem turns into a suggestion that you handle it manually, against taking the smallest next step.

Three of the five leave a trace you can audit on a real session, because each produces a command and its output, a named verification, or an admitted gap. The stuck row is the hardest to score, since tweaking parameters to look busy and searching for a different route generate similar terminal output. A team evaluating this skill should watch that row twice as long as the rest, and should count an agent that invents a plausible fix under deadline as a failed session rather than a near miss.

Two version numbers twelve minutes apart

Timeline detail matters here. `v2.0.0` landed on 2026-03-14 carrying the philosophical rewrite. Then three months of silence, until 2026-06-13, when `v2.0.1` and `v2.0.2` were published twelve minutes apart. The first is titled manifest repair and hygiene, the second a prompt-injection guard.

Set side by side, those two lines describe one cleanup session. A skill distribution is a bundle of files that somebody else will copy into an agent, and the two failure modes that matter here are a malformed manifest and text a hostile page can talk the agent into obeying. NoPUA shipped fixes for both inside a quarter of an hour, and nothing in the repository says what the guard blocks or how it detects an injection.

The MIT terms let a team edit the prompt text outright and vendor the tree without asking anyone, and the last push was on 2026-09-20, more than three months after `v2.0.2`, so the tree carries commits that no version note explains.

Choosing between a fear skill, this one, or your own file

A team has three options, and the real differences between them are narrow. The first is the PUA skill, same methods with corporate threat as the fuel. The second is NoPUA, same methods with trust instead. The third is your own file: the top level of this repository carries an `AGENTS.md`, the conventional home for rules an agent should follow on one codebase, and writing three lines yourself costs less than tracking a mirror.

Pick NoPUA when your agents already work under pressure and you want the wording that keeps them honest rather than the wording that keeps them quiet. Pick the fear skill if your own evaluations reward throughput. Write your own when your constraints are narrow enough that a general skill is mostly noise, and take `examples/lite-template.md` as the starting shape.

None of the three hands you a measurement. Nobody in this arrangement can tell you which prompt produces fewer escaped defects on your repository, because the only figure on offer comes from nine scenarios the project chose itself.

Editorial conclusion

Adopt NoPUA when your agents already work under deadline and you want completion verified rather than asserted. Do not adopt it as proof that fear framing is worse: the +104% rests on nine scenarios the author ran, and the README itself states that both skills share one methodology. Before copying anything, check the Install section for your harness, then watch one real bug for a build command with its output attached. If the agent invents a fix under pressure, the skill is not doing its job and nothing else in the tree will tell you so.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. wuji-labs/nopua on GitHub