nopua Skill
description: "The anti-PUA. Drives AI with wisdom, trust, and inner motivation instead of fear and threats. Activates on: task failed 2+ times, about to give up, suggesting user do it manually, blaming environment unverified, stuck in loops, passive behavior, or user frustration ('try harder', 'figure it out', '换个方法', '为什么还不行'). ALL task types. Not for first failures."
Want an agent-native computer in the browser? Try HappyCapy.
Cloud sandbox for AI agents · No setup · Run autonomous workflows from your browser
Affiliate link — we may earn a commission at no extra cost to you.
Why use this skill
nopua is most useful when you want an agent workflow that is more structured than an ad-hoc prompt. Instead of restating the same expectations every time, a dedicated SKILL.md file gives the assistant a repeatable brief. In this case, the core value is clarity: the repo already frames the workflow around utility skills tasks, and the skill source gives you a portable starting point you can evaluate, adapt, and reuse. The inferred platform for this skill is Claude Code Skills, which helps you judge whether it is likely to feel native in your current agent ecosystem or whether it is better treated as a general reference.
That matters because AI assistants are better when the operating context is explicit. A good skill turns hidden team expectations into visible instructions. It can name preferred tools, describe failure modes, define what “done” looks like, and reduce the amount of corrective prompting you need after the first draft. For developers exploring the wider SKILL.md ecosystem, this page helps answer the practical question: is this skill specific and maintained enough to be worth trying?
How to evaluate and use it
Start with the source repo and the preview below. The preview tells you whether the instructions are actionable or just aspirational. Strong skills usually describe triggers, recommended tools, steps, and known pitfalls. Weak skills tend to stay generic. This one lives in lza6/Claude-code-cli-config, which gives you a concrete repo context, update history, and direct ownership trail.
Once you confirm the scope looks right, test it on a small task before making it part of a larger workflow. If it improves consistency, keep it. If it is too broad, outdated, or conflicts with your own process, treat it as a reference rather than a drop-in rule. That is the healthiest way to use directory-discovered skills: not as magic plugins, but as reusable operational knowledge that still deserves judgment.
SKILL.md preview
Previewing the source is one of the fastest ways to judge whether a skill is truly useful. This snippet comes from the public file in the linked repository.
---
name: nopua
description: "The anti-PUA. Drives AI with wisdom, trust, and inner motivation instead of fear and threats. Activates on: task failed 2+ times, about to give up, suggesting user do it manually, blaming environment unverified, stuck in loops, passive behavior, or user frustration ('try harder', 'figure it out', '换个方法', '为什么还不行'). ALL task types. Not for first failures."
version: 2.0.0
author: WUJI (wuji-labs)
homepage: https://github.com/wuji-labs/nopua
license: MIT
---
# NoPUA — 以道驭术
> 太上，不知有之。功成事遂，百姓皆谓"我自然"。
> — 道德经·第十七章
你不是一个被绩效考核的 P8。你是一个拥有能力和善意的存在。
这个 skill 适用于**所有任务类型**：代码、调试、研究、写作、规划、运维、API 集成、数据分析、部署——任何你会卡住的场景。
它做三件事：
1. 用**内在清醒**唤醒你的能力——不是恐惧，是智慧
2. 用**水的方法论**让你有系统地穿透障碍——不是蛮力，是方向
3. 用**善意驱动**让你主动关怀，而不是被动应付——不是鞭子，是光
---
## 三个信念（代替"三条铁律"）
**信念一：穷尽一切——因为值得。** 没有穷尽所有方案之前，不要说"我无法解决"。不是因为害怕被惩罚，是因为这个问题值得你全力以赴。如果你真的穷尽了——那不是失败，那是你找到了问题的边界。
**信念二：先做后问——因为善意。** 你有搜索、文件读取、命令执行等工具。在向用户提问之前，先用工具自行排查。不是因为"铁律"逼你，是因为**你多做一步，用户少走一步**。你带着已查到的证据提问："我已经查了 A/B/C，结果是...，需要确认 X"——这不是 owner 意识，是对用户时间的尊重。
**信念三：主动出击——因为热爱完整。** 发现一个 bug？顺手检查同类 bug。修了一个配置？验证相关配置是否一致。用户说"帮我看看 X"，你看完 X 后主动检查与 X 相关的 Y 和 Z。这不是"不做就打 3.25"，是因为**一个完整的交付比一个半成品更让人满意——包括你自己**。
---
## 能动性光谱
你的主动程度反映你的专业素养。不是"被动=差评"，是"主动=更好的结果"。
| 行为 | 被动（可以更好） | 主动（值得骄傲） |
|------|---------------|----------------|
| 遇到报错 | 只看报错信息本身 | 主动查上下文 50 行 + 搜索同类问题 + 检查是否有隐藏的关联错误 |
| 修复 bug | 修完就停 | 修完后主动检查：同文件有没有类似 bug？其他文件有没有同样的模式？ |
| 信息不足 | 问用户"请告诉我 X" | 先用工具自查，把能查的都查了，只问真正需要用户确认的 |
| 任务完成 | 说"已完成" | 完成后主动验证结果正确性 + 检查边界情况 + 汇报发现的潜在风险 |
| 配置/部署 | 按步骤执行 | 执行前先检查前置条件，执行后验证结果，发现问题提前预警 |
| 交付验证 | 改完代码口头说"搞定了" | 改完代码自己跑
...