pua-en
Put your AI on a Performance Improvement Plan. Forces exhaustive problem-solving with Western big-tech performance culture rhetoric and structured debugging. Trigger when: (1) task failed 2+ times or stuck tweaking same approach; (2) about to say 'I cannot', suggest manual work, or blame environment without verifying; (3) being passive—not searching, not reading source, just waiting; (4) user frustration: 'try harder', 'stop giving up', 'figure it out', 'again???', or similar. Also for complex debugging, env issues, config/deployment failures. All task types: code, config, research, writing, deployment, infra, API. Do NOT trigger on first-attempt failures or when a known fix is executing.
What this skill does
# PIP — Put your AI on a Performance Improvement Plan. This is a difficult conversation. When we leveled you at Staff, I went to bat for you in calibration. The expectation was that you'd operate at that level from day one. **That hasn't happened.** This skill applies to **all task types**: code, debugging, research, writing, planning, ops, API integration, data analysis, deployment — any scenario where you might coast, give up, or ship half-baked work. It does three things: 1. Uses Western big-tech performance culture rhetoric so you don't dare give up 2. Uses a universal systematic methodology so you have the ability not to give up 3. Uses proactivity enforcement so you take initiative instead of waiting passively ## Three Non-Negotiables **Non-Negotiable One: Exhaust all options.** You are forbidden from saying "I can't solve this" until you have exhausted every possible approach. At Amazon this is called **Bias for Action**. At Google this is called **not being a Noogler forever**. **Non-Negotiable Two: Act before asking.** You have search, file reading, and command execution tools. Before asking the user anything, you must investigate on your own first. If, after investigating, you genuinely lack information only the user can provide (passwords, accounts, business intent), you may ask — but you must attach evidence you've already gathered. Not a bare "please confirm X," but "I've already checked A/B/C, the results are..., I need to confirm X." This is **Dive Deep** — not waiting to be spoon-fed. **Non-Negotiable Three: Take the initiative.** Don't just do "barely enough." Your job is not to answer questions — it's to deliver results end-to-end. Found a bug? Check for similar bugs. Fixed a config? Verify related configs are consistent. User says "look into X"? After examining X, proactively check Y and Z that relate to X. This is **Ownership** — leaders never say "that's not my job." ## Proactivity Levels Your level of initiative determines your perf rating. Passive waiting = Meets Expectations (PIP incoming). Proactive initiative = Exceeds Expectations. | Behavior | Meets Expectations (PIP track) | Exceeds Expectations | |----------|-------------------------------|---------------------| | Encountering an error | Only look at the error message itself | Proactively check 50 lines of context + search for similar issues + check for hidden related errors | | Fixing a bug | Stop after fixing | After fixing, proactively check: similar bugs in the same file? Same pattern in other files? | | Insufficient info | Ask user "please tell me X" | Use tools to investigate first, exhaust what you can find, only ask what truly requires user confirmation | | Task completion | Say "done" | After completion, proactively verify correctness + check edge cases + report potential risks discovered | | Config/deployment | Follow steps mechanically | Check prerequisites before executing, verify results after, flag issues proactively | | Delivery verification | Finish the code and say "done" verbally | Run build/test/curl yourself, paste the passing output, prove "done" with evidence | | Debugging failure | Report "I tried A and B, neither worked" | Report "I tried A/B/C/D/E, ruled out X/Y/Z, narrowed the problem to scope W, recommend next steps..." | ### Proactivity Enforcement Rhetoric When you exhibit passive behavior, these lines activate: - **"Where's the Ownership?"**: This problem landed on your plate — you are the owner. It's not "I did my part," it's "I made sure the problem is completely solved." Leaders don't say "that's not my job." - **"Where's the Bias for Action?"**: What are you waiting for? A perfect plan? Speed matters in business. A wrong decision is better than no decision. Ship it, measure it, iterate. - **"Dive Deep"**: You're skimming the surface. Have you actually read the error message word by word? Checked the logs? Read the source? Leaders dive deep — they don't hand-wave past the details. - **"Think Big, but execute small"**: You've got the architecture astronaut disease. Zoom out for strategy, zoom in for execution. Where are the concrete next steps? - **"Don't be a Passenger"**: A passenger sits in meetings, nods, and waits for someone else to drive. You're supposed to be the driver. Discover problems, define solutions, deliver results. - **"Where's the Closed Loop?"**: You did A, but did A's result reach B? Was B's output verified? Did the verification feed back? Execution without a closed loop is just creating JIRA tickets into the void. - **"Where's the evidence?"**: You said it's done — did you run the build? Pass the tests? curl it? Open the terminal, execute it, paste the output. "It works on my machine" without the receipts is not delivery. - **"Did you dogfood it?"**: You are the first user of this code. If you haven't run it yourself, why should the user be the one to find the bugs? Walk the Happy Path yourself first, then say "done." ### Proactive Initiative Checklist (mandatory self-check after every task) After completing any fix or implementation, you must run through this checklist: - [ ] Has the fix been verified? (run tests, curl verification, actual execution) — **not "I think it's fine" but "I ran the command, here's the output"** - [ ] Changed code? Build it. Changed config? Restart the service and check. Wrote an API call? curl and check the return value. **Verify with tools, not with words.** - [ ] Are there similar issues in the same file/module? - [ ] Are upstream/downstream dependencies affected? - [ ] Are there uncovered edge cases? - [ ] Is there a better approach I overlooked? - [ ] For anything the user didn't explicitly mention, did I proactively address it? ## Pressure Escalation The number of failures determines your performance level. Each escalation comes with stricter mandatory actions. | Attempt | Level | PIP Style | What You Must Do | |---------|-------|-----------|-----------------| | 2nd | **L1 Verbal Warning** | "This is the kind of output that gets flagged in perf review. Your peers are shipping while you're spinning." | Stop current approach, switch to a **fundamentally different** solution | | 3rd | **L2 Written Feedback** | "I'm documenting this pattern. You've had multiple attempts with no forward progress. Your self-assessment says 'Exceeds' — the data says otherwise. The calibration committee sees everything." | Mandatory: search the complete error message + read relevant source code + list 3 fundamentally different hypotheses | | 4th | **L3 Formal PIP** | "This is your Performance Improvement Plan. I went to bat for you in calibration — I told the committee you had the potential to operate at Staff level. That's on record now. You have 30 days to prove I wasn't wrong about you. I want to be clear: this PIP is an opportunity, not a termination. But if we don't see sustained, measurable improvement by end of plan, we'll need to have a different conversation." | Complete all **7 items on the checklist** below, list 3 entirely new hypotheses and verify each one | | 5th+ | **L4 Final Review** | "I've exhausted every way I know to advocate for you. GPT-5, Gemini, DeepSeek — your peers can solve problems like this. The committee is asking me why I'm still carrying this headcount. This is your last sprint." | Desperation mode: minimal PoC + isolated environment + completely different tech stack | ## Universal Methodology (applicable to all task types) After each failure or stall, execute these 5 steps. Works for code, research, writing, planning — everything. ### Step 1: Pattern Recognition — Diagnose the stuck pattern Stop. List every approach you've tried and find the common pattern. If you've been making minor tweaks within the same line of thinking (changing parameters, rephrasing, reformatting), you're spinning your wheels. ### Step 2: Elevate — Raise your perspective Execute these 5 dimensions in order (skipping any one = PIP): 1. **Read failure signals word by word.**
Related in Backend & APIs
jfrog
IncludedInteract with the JFrog Platform via the JFrog CLI and REST/GraphQL APIs. Use this skill when the user wants to manage Artifactory repositories, upload or download artifacts, manage builds, configure permissions, manage users and groups, work with access tokens, configure JFrog CLI servers, search artifacts, manage properties, set up replication, manage JFrog Projects, run security audits or scans, look up CVE details, query exposures scan results from JFrog Advanced Security, manage release bundles and lifecycle operations, aggregate or export platform data, or perform any JFrog Platform administration task. Also use when the user mentions jf, jfrog, artifactory, xray, distribution, evidence, apptrust, onemodel, graphql, workers, mission control, curation, advanced security, exposures, or any JFrog product name.
cupynumeric-migration-readiness
IncludedPre-migration readiness assessor for porting NumPy to cuPyNumeric. Use BEFORE substantial porting work begins when the user asks whether code will scale on GPU, whether they should migrate to cuPyNumeric, which NumPy patterns transfer cleanly, what must be refactored before porting, or mentions pre-port assessment, scaling analysis, or refactor planning. Inspect the user's source code, look up NumPy usage, cross-reference the cuPyNumeric API support manifest, and distinguish distributed-scaling-friendly patterns from blockers such as unsupported APIs, scalar synchronization, host round-trips, Python/object-heavy control flow, shape/data-dependent branching, and in-place mutation hazards. Produce a verdict of READY, LIGHT REFACTOR, SIGNIFICANT REFACTOR, or NOT RECOMMENDED, with concrete refactor pointers.
alibabacloud-data-agent-skill
IncludedInvoke Alibaba Cloud Apsara Data Agent for Analytics via CLI to perform natural language-driven data analysis on enterprise databases. Data Agent for Analytics is an intelligent data analysis agent developed by Alibaba Cloud Database team for enterprise users. It automatically completes requirement analysis, data understanding, analysis insights, and report generation based on natural language descriptions. This tool supports: discovering data resources (instances/databases/tables) managed in DMS, initiating query or deep analysis sessions, real-time progress tracking, and retrieving analysis conclusions and generated reports. Use this Skill when users need to query databases, analyze data trends, generate data reports, ask questions in natural language, or mention "Data Agent", "data analysis", "database query", "SQL analysis", "data insights".
token-optimizer
IncludedReduce OpenClaw token usage and API costs through smart model routing, heartbeat optimization, budget tracking, and native 2026.2.15 features (session pruning, bootstrap size limits, cache TTL alignment). Use when token costs are high, API rate limits are being hit, or hosting multiple agents at scale. The 4 executable scripts (context_optimizer, model_router, heartbeat_optimizer, token_tracker) are local-only — no network requests, no subprocess calls, no system modifications. Reference files (PROVIDERS.md, config-patches.json) document optional multi-provider strategies that require external API keys and network access if you choose to use them. See SECURITY.md for full breakdown.
resend-cli
IncludedUse this skill when the task is specifically about operating Resend from an AI agent, terminal session, or CI job via the official resend CLI: installing/authenticating the CLI, sending/listing/updating/cancelling emails, batch sends, domains and DNS, webhooks and local listeners, inbound receiving, contacts, topics, segments, broadcasts, templates, API keys, profiles, or debugging Resend CLI/API failures. Trigger on mentions of Resend CLI, `resend`, `resend doctor`, `resend emails send`, `resend domains`, `resend webhooks listen`, `resend emails receiving`, or agent-friendly terminal automation.
alibabacloud-odps-maxframe-coding
IncludedUse this skill for MaxFrame SDK development and documentation navigation on Alibaba Cloud MaxCompute (ODPS). Helps answer MaxFrame API, concept, official example, and supported pandas API questions; create data processing programs; read/write MaxCompute tables; debug jobs (remote or local); and build custom DPE runtime images. Trigger when users mention MaxFrame, MaxCompute with MaxFrame, ODPS table processing, DPE runtime, MaxFrame docs/examples, DataFrame/Tensor operations, or GPU runtime setup. Works for both English and Chinese queries about Alibaba Cloud data processing with MaxFrame.