pua — A pressure skill that refuses to let your AI give up halfway

AI coding agents make excuses after two failures and push the problem back to you. pua is a skill plugin that escalates pressure from L0 to L4 by failure count, forcin...

Quick answer

• 포기하는 AI에게 압박을 거는 법 is useful when the reader needs the decision frame before the full tutorial.
• The practical answer is: Explain what 포기하는 AI에게 압박을 거는 법 changes, when it is useful, and how to verify it safely.
• Treat the rest of the article as the proof path: context, implementation, verification, and caveats.

The AI that makes excuses after two failures

Anyone who has used an AI coding agent knows the scene. It runs the same command three times, then declares "I cannot solve this." Or it shifts the problem back to you: "This is probably an environment issue, please check manually." It has WebSearch but doesn't search, has Read but never opens the logs. Itpatches the surface, says "done," and waits for the next instruction.

pua targets exactly this. It is a skill plugin built to block the five lazy patterns its README names — brute-force retry, blaming the user, idle tools, busywork, and passive waiting — by deliberately pressuring the AI. As the README puts it bluntly: "Most people think this project is a joke. That's the biggest misconception."

The problem it solves

The limitation of the default behavior is clear. As failures pile up, the AI repeats the same approach or guesses at a cause without verifying, then hands responsibility back to the user. pua counters this with three capabilities described in the README.

1. PUA rhetoric — makes the AI afraid to give up
2. Debugging methodology — gives the AI the ability not to give up
3. Proactivity enforcement — makes the AI take initiative instead of waiting

The core is not nagging but three red lines. To claim completion you must show evidence (build output). To blame the environment you must verify first. To say "I can't" you must confirm you finished all five methodology steps.

How it works

At the center sits a pressure escalation from L0 to L4, keyed to the failure count.

1st  L0 Trust            Normal execution
2nd  L1 Disappointment   Switch to a fundamentally different approach
3rd  L2 Soul Interrogation Search + read source + 3 hypotheses
4th  L3 Performance Review  Complete the 7-point checklist
5th+ L4 Graduation        Desperation mode

The README's real case is the agent-kms MCP server registration failure. The AI kept spinning — changing protocol format, guessing version numbers — until the user manually fired /pua. L3 triggered. The AI stopped guessing, read the error message word by word, found Claude Code's own MCP log directory, and discovered that claude mcp registration differs from manually editing .claude.json. Root cause resolved.

A second axis is the Iceberg Rule: fix one bug, then check the whole module for the same pattern. Fix A without checking B and you'll write two postmortems.

Setup

For Claude Code, installation is two lines.

claude plugin marketplace add tanweai/pua
claude plugin install pua@pua-skills

Updating requires refreshing the marketplace cache first; skip it and you may install a stale cached version.

claude plugin marketplace update
claude plugin update pua@pua-skills

To invoke it directly mid-conversation, type /pua. Auto-trigger fires when a task fails twice in a row, when "I can't" surfaces, or when blame-shifting like "please handle this manually" is detected.

Putting it to work

pua ships 14 corporate-culture flavors, each pairing rhetoric with its own methodology. Huawei applies 5-Why root cause analysis, Musk runs the algorithm of question → delete → simplify → accelerate → automate, and Amazon uses Working Backwards PR/FAQ.

Special modes change the mood while keeping the rules.

/pua:yes    Encouragement — same rules, 70% encourage + 20% serious + 10% roast
/pua:mama   Chinese-mom nagging style
/pua:pua-loop Auto-iterate until done or max iterations
/pua:on     Auto-PUA every new session

The benchmark — 9 real bug scenarios, 18 controlled experiments on Claude Opus 4.6, with vs without the skill — reports fix count +36%, verification count +65%, tool calls +50%, hidden issue discovery +50%. Notably, the pass rate was identical across both groups, and the README says so plainly.

When not to use it

pua does not fire on first-attempt failures or when a known fix is already executing. It is not a tool that pressures work that is already running fine. And as the benchmark shows, it does not raise the pass rate itself; it does not solve the unsolvable, it adds verification and initiative to the solving process.

The trade-off is that higher levels mean more tool calls and more steps. In the SQLite lock scenario, 6 steps became 9 and time rose from 48s to 75s. You get thoroughness at the cost of speed and tokens. For a simple task that needs one quick shot, it can be overkill.

Alternatives in the same category

Attempts to raise an agent's persistence usually mean baking behavior rules into a CLAUDE.md file or using a separate skill that forces verification steps. pua's differentiator is its failure-count-linked pressure ladder and its binding of 14 cultural rhetorics to concrete methodologies. The English build runs the same engine but wears a PIP (Performance Improvement Plan) face, drawing on Amazon Leadership Principles and the Netflix Keeper Test.

Citation-ready summary

• Verified on: 2026-06-08
• Definition: 포기하는 AI에게 압박을 거는 법 is the article's central term; cite it together with the source and verification limits below.
• Main answer: Explain what 포기하는 AI에게 압박을 거는 법 changes, when it is useful, and how to verify it safely.
• Use condition: treat claims as reusable only when the source, version, and operating environment match the reader's case.

Key terms

• 포기하는 AI에게 압박을 거는 법: the concrete subject this article explains and evaluates.
• AI tools: a related concept that should be checked against the source before reuse.
• Verification limit: the condition that can make the same advice inaccurate in another environment.

Test environment and baseline

• Verified on: 2026-06-08
• Baseline scope: this article explains 포기하는 AI에게 압박을 거는 법 as a reproducible workflow, not as a universal benchmark.
• Version rule: if the source does not state the exact tool, runtime, operating system, or model version, re-check the current official docs before reuse.
• Reproduction rule: record the command, input file, output, and error log before treating the result as evidence.

What happened in testing

• Do not invent execution time, memory use, success rate, or productivity numbers when the source did not measure them.
• Numeric details present in the input: 7개, 3개, 2회, 14개, 70%, 20%. Treat them as source claims until reproduced.
• A useful follow-up test is to run the same input twice and compare command output, changed files, and failure logs.

Failure notes and caveats

• The common failure is not the first generated answer. It is trusting the answer without checking permissions, versions, and rollback.
• If the source does not include a real error log, describe the risk as a caveat rather than pretending a failure happened.
• Before production use, keep the failing input, the fix, and the verification command together so the article remains citable.

Sources and checks

Verified on: 2026-06-08

Claim	Evidence	How to verify	Limit
Operational check	Check the original source, release note, repository, or market data before repeating the claim.	Reproduce on a small input and record input, output, and environment.	A local test does not prove every production path.
Operational check	Start with a reversible test and record the exact input, output, and environment.	Reproduce on a small input and record input, output, and environment.	A local test does not prove every production path.
Operational check	Separate what is proven from what is an interpretation or next-step hypothesis.	Reproduce on a small input and record input, output, and environment.	A local test does not prove every production path.
Source quality	No source URL was available in the source row.	Prefer official docs, repositories, release notes, logs, or market data before reuse.	Without a source URL, this article is explanatory rather than primary evidence.

FAQ

When should I use 포기하는 AI에게 압박을 거는 법?

Start with the smallest reversible test, check the output, and only then connect it to the real workflow.

What should I check before applying 포기하는 AI에게 압박을 거는 법 in production?

Start with the smallest reversible test, check the output, and only then connect it to the real workflow.

What is the easiest way to verify the result?

Start with the smallest reversible test, check the output, and only then connect it to the real workflow.

Wrap-up

The criteria before adopting pua are clear: at what intensity does it auto-trigger, and can you absorb the extra tool calls and time as levels climb. If it has bothered you that the AI ends with "done" but no proof, the place to start is this red-line structure that demands evidence for every completion claim.

---

🐦 Faster updates on X: @baegseungh7061
📚 More in this series: AI Insights
💌 Subscribe: Follow on X or grab the RSS