pua is a Python skill package that wraps corporate PUA rhetoric and a 7-point debugging checklist around a coding agent's retry loop. It targets one specific failure mode: the assistant that reruns the same command, blames the environment, and stops. The README claims doubled productivity; the same README states that a productivity increase has not been established by its own evaluation.

Can I use tanweai/pua commercially?

Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.

Is tanweai/pua still maintained?

Yes. The repository last received commits 7 days ago.

What programming language is tanweai/pua written in?

Mainly Python, according to GitHub's language statistics.

tanweai/pua review: a PIP-style agent skill for Claude Code and Codex CLI

At a glance

What is it?: pua is a Python skill package that wraps corporate PUA rhetoric and a 7-point debugging checklist around a coding agent's retry loop. It targets one specific failure mode: the assistant that reruns the same command, blames the environment, and stops. The README claims doubled productivity; the same README states that a productivity increase has not been established by its own evaluation.
Who is it for?: Adopt pua if you run Claude Code, Codex CLI or one of the other listed runtimes and you keep hitting the same loop: the agent retries a command, guesses at parameters, then hands the problem back to you. Do not adopt it if you need measured output claims or a defined licence, because the README asserts doubled productivity in one paragraph and withdraws that claim in the compatibility note above it, and the licence field is not stated in the material I have.
Can I use it commercially?: Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
Is it still maintained?: Yes. The repository last received commits 7 days ago.
What is it written in?: Mainly Python, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

Hysen Labs Editorial · September 11, 2026 · tanweai/pua

The failure mode pua is built around

The README names five lazy patterns it tries to interrupt: brute-force retry (running the same command three times, then declaring the task unsolvable), blaming the user ("I suggest you handle this manually"), idle tools (WebSearch available but unused, Read available but unread), busywork (tweaking the same line without producing new information), and passive waiting (fixing the surface issue, skipping verification, then waiting for the next instruction). That list is the whole product thesis. It is not a code generator, a linter, or a test runner. It is a behavioural layer aimed at the moment an agent decides it is done trying. The audience is narrow on purpose: people who already drive an agent through multi-step debugging work and have watched it circle the same hypothesis. The README's worked example is an MCP server that would not load, where the agent kept changing protocol formats and guessing version numbers until the user manually typed /pua, at which point the checklist forced it to read the MCP logs and find that claude mcp registration differs from editing .claude.json by hand. That is a plausible failure class, and the fix came from reading an error message the agent had skipped, not from new tooling.

What actually fires: trigger conditions and the L3 escalation

pua is not invoked only by hand. The README lists auto-trigger conditions in four groups. Failure and giving-up: the task has failed two or more times consecutively, or the agent is about to say it cannot solve the problem, or it declares something out of scope. Blame-shifting: pushing the problem to the user, or blaming permissions or network without verifying. Passive and busywork behaviour: repeatedly tuning the same parameters, fixing a surface issue and stopping, claiming done without verification, giving advice instead of code, or waiting for instructions rather than investigating. There is also a phrase list, and the README says it triggers in multiple languages, citing "why does this still not work", "try harder", "you keep failing" and "stop giving up". Two exclusions are stated: a first-attempt failure does not trigger, and a known fix already in progress does not trigger. The escalation is graded. In the MCP case the README describes an L3 trigger, which enforces a 7-point checklist rather than another retry. The checklist itself is not reproduced in the material I have, so I cannot describe its seven items; what the case study shows is the effect, which is that the agent stopped varying the hypothesis and started reading logs it had not opened.

Runtime coverage and what the badges imply

The README claims support for Claude Code, OpenAI Codex CLI, pi coding agent, Trae, Cursor, Kiro, CodeBuddy, OpenClaw, Google Antigravity, OpenCode, and VSCode with GitHub Copilot. The badge row matches most of that list. The v3.5.1 release note describes "portable Claude Code / Codex / ChatGPT skill packages", which suggests the packaging is per-runtime rather than one universal artefact, and the repository is Python. The distinction matters for evaluation: a skill that hooks into Claude Code's trigger surface is not the same artefact as a prompt package dropped into Cursor, and the README does not break down per-runtime capability in the text I have. Treat the badge list as a claim about packaging targets, not as evidence that behaviour is identical across all eleven. The homepage at openpua.ai and the linked beginner guide are where the per-runtime instructions presumably live; the README itself does not reproduce installation steps for each one.

Getting it running: what the material actually specifies

This is the weakest part of the supplied material, and I will not invent commands. The README does not contain an install section in the excerpt I have. It points to docs/MODEL-COMPAT-20260909.md for usage, docs/TESTING.md for build and offline tests, and a beginner guide at openpua.ai/guide.html. One concrete invocation does appear: a user manually triggers the skill by typing /pua, which the MCP case study describes as the action that escalated the session to L3. So the only command I can state with confidence is the slash command /pua inside a supported agent session. Configuration keys, package names, and the contents of the skill packages are not in the material. If you are evaluating this before installing, the honest sequence is: read docs/MODEL-COMPAT-20260909.md first, because it is the document the README itself flags for usage, then docs/TESTING.md if you intend to build or run the offline tests. Anything beyond that is guesswork on my part.

The README argues with itself about results

Two statements sit near the top of the README and they do not agree. One says the project "genuinely doubles your Codex / Claude Code productivity and output". The other, in the 3.5.1 compatibility note, says "Not all models passed, and a productivity increase has not been established by this evaluation." The second statement is the one tied to a dated document, docs/MODEL-MATRIX-20260909.md, described as model results and known limits. I would weight the dated document over the marketing line, and I would treat the doubling claim as unverified. This is not a small inconsistency. The project's central promise is a productivity multiplier, and the project's own compatibility note declines to establish it. That does not make the skill useless. The MCP debugging case is a specific, checkable story about an agent that stopped guessing and read a log directory. But if you are justifying the install to someone else, the defensible claim is behavioural (the agent stops retrying and starts investigating), not quantitative. Note also that the README's headline framing, that most people think the project is a joke, is a positioning choice that will make some reviewers discount it before reading the trigger table.

Where this approach breaks down

A rhetoric layer that pushes an agent to keep going has an obvious failure direction, and the README's own trigger list points at it. The conditions include the agent being about to say it cannot solve a problem, and the skill's stated purpose is to make the AI "afraid to give up". For tasks that are genuinely blocked (a missing credential, a service that is down, a permission the user must grant), the correct behaviour is to stop and say so. pua's trigger set includes "encounters auth/network/permission errors and gives up without trying alternatives", which is reasonable when alternatives exist, but the same mechanism applied to a hard block produces wasted turns and confident-sounding noise. The second limitation is scope. The README states the trigger applies to debugging, implementation, config, deployment, ops, API integration and data processing, which is nearly everything. A skill that fires across all task types will also fire when the agent is simply done and the output is correct, and the exclusions listed (first-attempt failure, known fix already executing) are narrow. The third is measurement. Without the model matrix in hand, you cannot tell whether a given model responds to the escalation or ignores it, and the compatibility note says not all of them passed.

Alternatives and the difference in approach

The closest thing to a conventional alternative is a retry or reflection prompt layer that you write yourself and attach to the agent's system prompt, for example an instruction that says to enumerate three hypotheses before retrying and to read the full error output first. The difference is structural. A hand-written prompt is static: it applies the same pressure on every turn, and it cannot escalate. pua's design is graded, with auto-trigger conditions that watch for specific behaviours (two consecutive failures, blame-shifting language, parameter-tuning without new information) and an L3 state that imposes a fixed checklist. That escalation is the actual mechanism, and it is the part a static prompt does not replicate. The trade-off runs the other way too: a static prompt is inspectable in one file, while pua's behaviour depends on trigger detection you cannot fully audit from the README, and on a checklist whose contents are not in the material I have. If your problem is that the agent never reads error output, a two-line system prompt may be enough and costs nothing to try. If your problem is that the agent reads the error output and still reruns the same command, the escalation model is the reason to look at pua specifically.

Maintenance, releases and licence

The release cadence visible in the material is roughly monthly: v3.4.6 in May 2026, v3.5.0 in June 2026, v3.5.1 in September 2026, with the last push timestamp matching the v3.5.1 release. The v3.5.0 note describes a rendering change (blockquote rendering and source attribution) rather than a behavioural one, and v3.5.1 is described as a compatibility update that keeps the original tone while adding runtime fixes and portable skill packages. That pattern suggests the maintenance burden is mostly chasing changes in the host agents' skill and plugin formats, which is a real cost: every time Claude Code or Codex CLI changes how skills are packaged or triggered, this project has to ship again. For a user, the practical implication is that pinning a version and re-reading the compatibility doc after a host upgrade is cheaper than tracking main. On licensing, the README's badge row shows an MIT License badge, but the repository metadata I was given lists the licence as unknown, and the README excerpt contains no LICENSE text. I cannot resolve that conflict, and I am not giving legal advice: if the licence matters for your use, read the LICENSE file in the repository rather than the badge.

Editorial conclusion

Adopt pua if you run Claude Code, Codex CLI or one of the other listed runtimes and you keep hitting the same loop: the agent retries a command, guesses at parameters, then hands the problem back to you. Do not adopt it if you need measured output claims or a defined licence, because the README asserts doubled productivity in one paragraph and withdraws that claim in the compatibility note above it, and the licence field is not stated in the material I have. Before installing, open docs/MODEL-MATRIX-20260909.md and docs/MODEL-COMPAT-20260909.md, since the release note for v3.5.1 says not all models passed compatibility testing.

Official sources

Community notes