API Key Fetcher

The pattern in one phrase: tiered fallback — cheapest method first, escalate only on failure.

1. What it does

When you need an API key from some service's dashboard, it goes and gets it for you — trying the fast, clean way first and falling back to heavier methods only if the easy one fails.

2. The problem it solves

Setting up a new app means hunting down keys — those long secret passwords that let your app talk to other services like a payment processor or a database. The old dance: the agent says "go log into your dashboard, click Settings, find the API tab, copy this key, paste it here." So you stop building and become a copy-paste mule. Worse, when one method hits a wall — a login screen, an expired session — a lazy agent just shrugs and says "I can't access that," and now you're stuck. It's like a delivery driver who turns around the second the front gate is locked, instead of trying the side door, the call button, or the neighbor with a spare key.

This skill refuses to shrug. It keeps trying different routes until the key is in hand.

3. The core pattern (the part you steal)

Tiered fallback: stack your methods cheapest-to-heaviest, fail forward.

Here's the whole idea. You don't pick *one* way to do a job. You line up several ways, ordered from "fast and easy" to "slow but bulletproof," and you only move to the next one when the current one fails. The job gets done without bugging the person who asked.

Think of how you'd actually get into your own house if you forgot your keys. First you try the front door — maybe it's unlocked (cheapest, instant). No? Check under the mat for the spare (still easy). No? Call your roommate to buzz you in (a little slower, needs someone else). Still nothing? Climb through the window you left cracked (slow, ugly, but it works). You don't start with the window. And you don't give up after the front door. You escalate — each rung of the ladder is more effort but more likely to work, and you stop the instant one rung succeeds.

In this skill the ladder is five rungs: first check if the service has a direct tool or API that just *hands over* the key (no browser at all). If not, use the service's command-line login (the official, clean path). If there's no command-line tool, drive a hidden browser that's already logged in. If the login expired, take over the actual screen and click through it like a human. And as a last resort, use a cloud browser. Five rungs, each heavier, each only tried when the one above it fails.

That "cheap-first, escalate-on-failure, never give up silently" shape is the part you steal. It works for anything with multiple ways to get it done: fetching data, sending a message, recovering a file, reaching a person.

4. How the skill is actually built

Look at the real file: ~/.claude/skills/api-key-fetcher/SKILL.md. Here's its shape.

Frontmatter (the block up top): name: api-key-fetcher plus a description packed with trigger phrases — "get api keys", "grab my keys", "get my stripe keys." Those phrases are the doorbell. They're how the agent knows, on its own, that a request is a key-fetching job and this skill should fire.
The body: the heart of it is a numbered ladder labeled Tier 0 through Tier 4, each tier a different method ordered cheapest to heaviest. There's a "pre-flight check" before the ladder (make sure the tools you'll need actually work first), a hard rule at the top ("the agent fetches the keys, period — never tell the human to go log in"), and a banned-behaviors table that names the lazy excuses out loud — "I can't access that" — and pairs each one with "do this instead." That table is what stops the agent from quitting on rung one.
The reference shelf: most of the file is lookup material the agent leans on while climbing the ladder — a per-service cheat sheet (for each known service: the dashboard web address and where the keys live), a generic flow for services it's never seen, a small cache so a key shared across projects gets fetched once not five times, and safety rules for writing keys to disk (never overwrite a real key, never log it, never commit it). The ladder is the engine; this shelf is the fuel.

5. How YOU could build your own

You don't need browser automation to use this pattern. Here's the minimum:

Pick a job that has more than one way to get done. "Find this person's email," "pull today's sales number," "reach my contractor." Any task where Plan A can fail but Plan B, C, D exist.
Rank your methods cheapest-to-heaviest. Cheapest = fastest, least likely to bug anyone (a saved file, a direct tool). Heaviest = slow but works no matter what (manually digging, or the one move that needs the human). Write them as a numbered list, easy at the top.
Write the rule: try in order, drop down only on failure, never quit silently. Tell the agent plainly: "Try method 1. If it fails, try 2. Keep going. If everything fails, tell me the ONE specific thing you need — don't hand me a list of excuses."
Add trigger words to the description so the agent reaches for this on its own when the job comes up.

That's a working fallback ladder. The fancy browser-driving is just one possible rung — the *pattern* is the ladder itself.

6. When to use it — and when NOT to

Use it when: a task has several possible routes and the easy ones sometimes fail — fetching credentials, gathering data, contacting someone, recovering something. Anywhere "don't make the human do it" matters and there's a real chance the first try won't land.
Skip it when: there's genuinely only one way to do the thing. A ladder with one rung is just a regular task wearing a costume — the structure adds nothing. Also skip it for jobs where escalating is *dangerous*, not just slow (you don't want a "fall back to deleting it" rung). The ladder is for "more effort," never "more damage."

7. The stripped-down version

This is a complete, working fallback-ladder skill. Paste it, swap in your own job and rungs, done:

---
name: fetch-it
description: Get <the thing> using a fallback ladder. Try the easy way first, escalate on failure, never give up silently. Use when I ask to fetch, grab, or get <the thing>.
---

# Fetch It

When I ask for <the thing>, work this ladder IN ORDER. Only drop to the next rung when the current one fails:

1. Check if a saved copy or direct tool already has it — instant, no work.
2. Use the official clean method (a CLI, an API call).
3. Use the heavier automated method (drive a browser, scrape a page).
4. Take manual control as a last resort.

RULES:
- Never tell me to go do it myself unless every rung above failed.
- If all rungs fail, tell me the ONE specific thing you need — not a list of excuses.
- Never log or commit secrets.