pua: L0 to L4 pressure escalation for coding agents, and a productivity claim its own evaluation does not back

Escalation runs L0 to L4, and the fourth failure is a 7-point checklist

The mechanism is a counter tied to failure count. The first failure is L0 Trust, with normal execution. The second is L1 Disappointment, and the action changes: switch to a fundamentally different approach. The third is L2 Soul Interrogation, where the action becomes search plus read source plus 3 hypotheses. The fourth is L3 Performance Review, and the required action is a complete 7-point checklist. The fifth and beyond is L4 Graduation, described as desperation mode. The repository description frames the same device as workplace management rather than debugging: the agent is cast as a P8 level engineer who was given high expectations, and the English version is a Performance Improvement Plan with 30 days to show improvement. What this means practically is that the counter, not the diagnosis, drives escalation. An agent blocked by a missing credential is on the same ladder as one that picked the wrong approach, and by the fourth failure it is being told to fill in a checklist.

Auto-trigger watches for the phrase "I cannot", not for a diagnosis

The activation conditions are string-shaped. The skill fires when a task has failed 2 or more times consecutively, when the agent is about to say "I cannot" or "I'm unable to solve", when it says "This is out of scope" or "Needs manual handling", when it blames the environment without verifying, when it repeatedly fine-tunes the same parameters without producing new information, when it skips verification and claims done, or when the user types phrases like "why does this still not work", "try harder", or "stop giving up", in multiple languages. The documented non-triggers are narrow: first-attempt failures, and a known fix already executing. The consequence is that the boundary between a lazy refusal and a correct one is a wording test, and the two documented exemptions are the only things standing between a legitimate stop and the L0 ladder. Everything else, including an auth, network or permission error the agent gives up on without trying alternatives, is on the list of things that should trigger it.

The three red lines demand build output before a task counts as finished

Three rules carry the weight, and the first is about evidence. Close the Loop says that claiming done requires showing the evidence, and that no build output means no completion. Fact-Driven says that saying "probably environment issue" requires verification first, and that unverified attribution counts as blame-shifting. Exhaust Everything says that before saying "I can't", all 5 methodology steps must be finished, and otherwise you keep going. The consequences depend entirely on whether the task can produce a build or test run. For a compiler change or a failing test, the rule is exactly the right pressure. For a configuration edit, a documentation change, or a question that has no command to run, there is no output to paste, so an agent obeying the rule literally either invents a check or stalls at the last step. The same asymmetry shows up in the proactivity comparison, where the proactive column for completing a task is described as running the build or test and pasting the output.

The Iceberg Rule turns one fix into a scan of the whole category

One rule deliberately widens scope, and it is stated as a rule rather than a suggestion: fix one bug, then check for the pattern, one problem in and one category out, because if you fix A without checking B you will write two postmortems. The proactivity table makes the same move concrete, pairing a passive agent that stops after the fix with a proactive one that scans the module for similar bugs, and pairing an agent that asks the user for missing information with one that searches first and asks only for what is truly needed. The cost is scope and context. A request to fix one defect turns into a repository-wide pattern hunt, and a request that needs one fact from you turns into a search the agent runs first and reports back from. That is a reasonable trade for a maintainer who wants the category closed, and an expensive one for someone with a small change and a long context window.

Fourteen corporate flavors swap the methodology, not just the tone

The flavor table is the part that makes this more than a prompt. Each company entry pairs a piece of rhetoric with a methodology marked v3. Alibaba gets the underlying logic question plus a goal, process, result sequence with a four-step retrospective. ByteDance gets A/B testing everything, data-driven decisions, and speed over perfection. Huawei gets RCA 5-Why root cause analysis plus a Blue Army self-attack approach. Tencent gets multi-approach parallel work, MVP, and staged release. The README says each of the 14 flavors has its own methodology. So the flavor selector is not a voice pack: choosing Huawei and choosing ByteDance give the agent different checklists to follow when it escalates, which means the setting changes debugging behaviour. Worth keeping in mind while reading the rhetoric is that these are attributions written by the project, not documented statements of how those companies work.

The 3.5.1 note contradicts the headline claim in the same README

Read these two lines together. The headline says double your Codex or Claude Code productivity and output, and adds that most people think this project is a joke, which it calls the biggest misconception. The 3.5.1 compatibility update then says the original PUA tone was retained, runtime fixes and portable Claude Code, Codex, and ChatGPT skill packages were added, and, in the same sentence, that not all models passed and that a productivity increase has not been established by this evaluation. The evaluation material is pointed at rather than summarised, through `CHANGELOG.md`, `docs/MODEL-COMPAT-20260909.md`, `docs/MODEL-MATRIX-20260909.md`, and `docs/TESTING.md`. The practical reading is that the doubling claim and the project's own assessment of it are in tension, and the repository gives you the files to settle the question instead of taking the marketing line. The tags agree with the note: v3.4.6 on 2026-05-13, v3.5.0 on 2026-06-12, and v3.5.1 on 2026-09-09.

Eleven agent directories, one plugin file, and no license

The compatibility surface is the file layout. At the top level sit per-agent directories and manifests for the platforms named in the README: `.claude-plugin/`, `.codex/`, `.trae/`, plus `agents/`, `chatgpt/`, `codebuddy/`, `codex/`, `commands/`, `compat/`, `cursor/`, `hermes/`, `hooks/`, `kimi/`, `kiro/`, `pi/`, `skills/`, `trae/`, and `vscode/`, along with `plugin.json`, `docs/`, `evals/`, `scripts/`, and `landing.html` with a `landing/` directory. The README names Claude Code, OpenAI Codex CLI, the pi coding agent, Trae, Cursor, Kiro, CodeBuddy, OpenClaw, Google Antigravity, OpenCode, and VSCode with GitHub Copilot, so the choice you make is which directory you install from. Two observations. The first is that support for a given agent is a directory existing, not a passing test, and the compatibility note says not all models passed. The second is that the repository records no license, and there is no license file among the top-level entries, so no top-level file states the terms for reuse or redistribution.

The one worked case is a `.claude.json` registration mistake caught by reading logs

The project shows a single debugging story, and it is worth reading for what it does and does not prove. An MCP server called agent-kms failed to load. The agent kept spinning on the same approach, changing protocol format and guessing version numbers, until the user manually triggered `/pua`, which pushed the run to L3 and enforced the 7-point checklist. The turning point was reading error messages word by word, finding Claude Code's own MCP log directory, and discovering that the `claude mcp` registration mechanism differs from editing `.claude.json` by hand, which resolved it. Three things follow. A human noticed the loop and typed the command, so the case does not show the auto-trigger working. The fix was a lookup step about where state is kept, not a novel technique. And a single anecdote, however well documented, is not a measurement, which is the same point the 3.5.1 note makes about the productivity claim.

Editorial conclusion

pua earns a look from anyone who has watched an agent declare victory on an unverified fix or repeat one command until it apologises, because its three red lines and its Iceberg Rule name those failures precisely. It is a prompt and configuration package, not a model, not a debugger, and not a benchmark, and it arrives with the rhetoric attached whether or not you want it. Before you install it, read `docs/MODEL-MATRIX-20260909.md` and `docs/TESTING.md` rather than the headline, pick the corporate flavor whose methodology you actually want followed, and note that the repository records no license.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. tanweai/pua on GitHub