Skill-pack and agent articles should point here. This is the primary SOP and bootstrap paste for login-free WordPress publishing.
Right now, two websites are sitting on placeholder text that reads “First Last” and “I help X achieve Y by Z.”
Go look. adriennelara.com and satchelperry.com — Lorem ipsum, a grey silhouette where a headshot goes, fake testimonials from “Jane Doe, Director of Marketing.”
The replacement is already built. A clean “domain for sale” landing page, self-tested eleven times, sitting one step from live. The agent built it. The agent verified it. The agent will not publish it.
On purpose.
Because there’s exactly one thing in this whole pipeline a human has to do — and it takes about sixty seconds. Mats is going to do it. So can you. Here’s the whole thing.
Why the agent stops at the login
The agent can build a whole personal brand website. It can write the page, upload the images, set the front page, check that the thing actually rendered. What it can’t do is log in as you.
That’s a line we drew, and we drew it on purpose. Your real password and your 2FA are yours. You don’t hand those to an agent, and you don’t paste them into a chat window. So we don’t.
There’s a second reason, and it’s the reason these two sites are stuck. Their stored password went stale. The agent could try to guess its way in — but one failed login on this fleet trips the firewall (Wordfence), and a tripped firewall can block the whole server for every site on it. So the agent refuses to guess. Good. That’s the behavior you want.
An Application Password walks around both problems at once.
What an Application Password actually is
It’s a WordPress feature — built into core since version 5.6, already on every site in the fleet. You mint a separate 24-character key tied to your user. It logs in over the API only, never through the normal login screen. So:
- The agent never sees your real password. Different key, different door.
- It never touches your 2FA. Application Passwords skip it by design.
- You can revoke it in one click — and only that key dies. Your login keeps working.
- It survives a password reset. Change your real password tomorrow; the key still works. Perfect for a fleet.
- It doesn’t trip the firewall. It uses REST Basic Auth — no login form is ever POSTed, so Wordfence never sees a failed attempt.
That’s the trick in one line: you give the agent a key you can kill, instead of the password you can’t un-share.
What you need
A blitzadmin.com login. That’s the whole list.
blitzadmin.com is the dashboard for all 198 sites in the fleet — every personal-brand site we’ve built lives there. If you can log into it, you can get into any site’s WordPress admin, which is where you mint the key. Mats has a login. (Mats Polman — Leo’s brother, our human on the fleet.) If you’re reading this and you don’t have one yet, that’s the thing to ask for first.
Mint the Application Password — step by step
Log into blitzadmin.com
This is the fleet dashboard. You’ll see the list of sites. Find the one you’re unlocking — for today, that’s adriennelara.com and satchelperry.com.
Open that site’s WordPress admin
From the dashboard, open the site’s WordPress admin (wp-admin). Straight there works too:
https://adriennelara.com/wp-admin/Log in as access@blitzmetrics.com. If that password is lost, click “Lost your password?” on the login screen, or reset it from another admin account — then come back here.
Go to your profile
In the left menu: Users → Profile. Scroll to the bottom, to the section called Application Passwords.
Name the new key
In the “New Application Password Name” box, type:
cowork-hub-publishThe name is just a label so you know what the key is for. Use the same one everywhere and future-you will thank you.
Click “Add New Application Password” and copy the value
WordPress shows you the key once, and only once. It looks like this:
xxxx xxxx xxxx xxxx xxxx xxxxCopy it now. If you close the page without copying, no harm — just delete that entry and add another. The spaces are fine; leave them in.
Hand it to the agent
Paste it into the chat with one line naming the site:
adriennelara.com app password: xxxx xxxx xxxx xxxx xxxx xxxxDo the same for satchelperry.com. That’s your last step — the agent takes it from here.
What the agent does the second you hand it over
You paste the key. Then, without you touching anything else:
- Stores the key in the local credentials file the pipeline reads — not in a saved chat log, not in this public article. Just the field named
app_passfor that site. - Connects over REST Basic Auth — the API door, not the login screen. Firewall-safe, so nothing trips Wordfence.
- Builds the landing page, drops it on a full-bleed template, and sets it as the site’s front page.
- Cache-busts and checks the live page actually rendered — it looks for the real headline, not a stale cached copy.
- Reports back: “adriennelara.com — live.” You watch Lorem ipsum turn into a real page.
“First Last.” “I help X achieve Y by Z.” Fake testimonials. A grey silhouette. The default brand template nobody ever filled in.
“Premium Domain Available.” A real inquiry form. “Domain managed by Dennis Yu.” The page the agent had ready the whole time.
How to revoke it, any time
This is why the whole thing is safe to do. You’re not making a permanent decision. You’re handing over a key you can take back in one click.
Do this once per site
That’s the model for the entire fleet. Humans don’t log in every day — the agent does. You log in once, mint one key, hand it over. From then on the agent publishes, updates, and fixes without another login from you.
So go mint the two that are waiting. adriennelara.com and satchelperry.com are one key each away from real pages. Then do it for the next two. Then the next two hundred.
Set up a new team member — one paste, zero logins forever
Everything above unlocks one site for one agent. This section scales it to a person: a brand-new team member with a fresh MacBook, a fresh Claude, and forty site updates a day ahead of them. Done right, they log into each site exactly once — ever — and their agent handles every publish after that.
Which agent owns which site is tracked in the Client Tracker, the same way we divide work between AI agents everywhere else.
The rule that makes it safe at team scale: one key per person, per site. Never share keys.
Application Passwords are per-user and you can mint as many as you want. So every team member’s agent gets its own key on every site, named after them — cowork-dennis, cowork-jack, cowork-mats. When someone leaves or a laptop is lost, you revoke their keys and nobody else’s agent even notices. And the site’s activity log shows exactly whose agent published what.
The human’s part (three things, once)
Get a blitzadmin.com login
blitzadmin.com is the dashboard for the whole fleet — it’s where sites are created and where you reach each site’s wp-admin. Ask operations for your login. That’s your master key to mint everything else.
Point your Claude at this article
Open Claude (Cowork mode), and paste it the bootstrap block below. That block teaches your agent the entire system: where to keep keys, how to mint them, how to publish, and the field-tested gotchas. You don’t need to understand any of it — your agent does.
Log into each site once, when your agent asks
Your agent will ask you to open a site’s wp-admin in Chrome. Log in. That’s it — the agent mints its own key through the API while your session is open, stores it in its local vault, and never needs that login again. Repeat per site as work comes up, or do a batch in one sitting.
The bootstrap block — paste this into a new team member’s Claude
This is the whole system in one prompt. Copy it, paste it into Claude, and the agent sets itself up.
You are setting up login-free WordPress publishing for a BlitzMetrics / Local Service Spotlight team member. This is a standing system — follow it exactly, on this task and every future one.
1. THE VAULT. In my Claude project folder, create a file named .credentials.json (if it does not already exist) shaped like:
{"wp_sites": {"example.com": {"user": "WP-USERNAME", "app_pass": "24-CHAR-APPLICATION-PASSWORD", "_captured": "date + key name"}}}
Secrets live ONLY in this file. Never write them into chat, memory files, logs, or published content.
2. STANDING RULE — check the vault before asking me to log in. Before ever requesting a WordPress login for any site, read .credentials.json → wp_sites[domain].app_pass. If it is set, publish login-free. Only if it is missing do you ask me for a one-time login.
3. ONE-TIME KEY CAPTURE (per site). When I am logged into a site's wp-admin in Chrome, mint and capture the key yourself in one pass — I never copy anything manually:
a. From a tab on that site: fetch('/wp-admin/admin-ajax.php?action=rest-nonce', {credentials:'include'}) → returns a nonce.
b. POST /wp-json/wp/v2/users/me/application-passwords with JSON body {"name":"cowork-MYFIRSTNAME"} and headers X-WP-Nonce + credentials:'include'.
c. The response contains the plaintext password EXACTLY ONCE. Write it directly into .credentials.json. Do not display it.
d. Confirm to me: "domain — captured, login-free from now on."
4. PUBLISHING. All writes go over the WordPress REST API with Basic Auth — header Authorization: Basic base64(user:app_pass) — against https://DOMAIN/wp-json/wp/v2/posts, /pages, /media. No cookies, no login form, no 2FA. This cannot trip Wordfence because no login is ever attempted.
5. FIELD NOTES — obey all of these:
- One key per person per site, always named cowork-MYFIRSTNAME. Never reuse or share anyone else's key.
- Keys are shown once at creation and never again. If the vault is lost, revoke the old key on the site and mint a fresh one.
- Some hosts firewall datacenter IPs: if a REST call 403s from your sandbox, run the identical Basic-Auth fetch from my browser tab instead (works logged-out — the header is the auth, no cookie needed).
- Go one site at a time on bulk runs. Rapid fleet-wide requests trip shared-host rate limits.
- Elementor pages render from cached _elementor_data, so REST post_content edits will not appear on them. Blog posts and standard pages are fine over REST; edit Elementor layouts through Elementor's own save pipeline.
- Verify every publish with a cache-busted fetch of the live URL and check the actual new text is present — a 200 alone proves nothing.
6. VERIFY THE SETUP. Test each captured site with GET /wp-json/wp/v2/users/me using Basic Auth and confirm the username comes back. Then report a one-line status per site: "domain — login-free ✓".
What this looks like on day one
- 9:00 — New team member gets their blitzadmin.com login and pastes the bootstrap block into Claude.
- 9:05 — Agent asks: “Open localservicespotlight.com wp-admin and log in.” They do. “Captured — login-free from now on.”
- 9:20 — Same one-minute dance for the next five sites they’ll work on this week.
- 9:30 onward — Every publish, fix, and update runs through the API. They never see a WordPress login screen again for those sites.
That’s the whole handoff. The system Dennis runs — 40 to 50 site updates a day with zero logins — is now the system everyone runs, and this article is the single URL you point a new hire’s Claude at to install it.
Questions people ask
Is this actually safe?
Yes — safer than sharing your password. The agent never gets your real password or your 2FA, the key only works over the API, and you can revoke it in one click without affecting your login. That’s more control than a normal shared login gives you, not less.
What if the account password itself is lost?
Use “Lost your password?” on the site’s login screen, or reset it from another admin account. Once you’re into wp-admin, mint the Application Password as above. You only need the real password long enough to get in and create the key.
Does the Application Password expire?
No. It stays valid until you revoke it — and it keeps working even if you change your real account password later. That’s exactly why it’s the right tool for a fleet that rotates passwords.
Why not just give the agent the normal password?
Two reasons. One, a failed login on this fleet can trip the firewall and block the whole server for every site. Two, you’d be handing over your real credentials and 2FA with no clean way to take them back. An Application Password is revocable, scoped to the API, and firewall-safe.
Where does the agent keep the key?
In a local credentials file that only the agent’s publishing pipeline reads — never in this article, and not in a chat transcript we hang onto. If you ever want it gone, revoke it on the site and it’s dead everywhere at once.
How does a brand-new team member get this setup?
Point their Claude at this article and have them paste the bootstrap block above. Their agent creates its own credentials vault, mints its own key on each site during a single login session, and publishes login-free from then on. The only human prerequisites are a blitzadmin.com login and one wp-admin login per site, once.
Should team members share one Application Password?
No. Mint one key per person per site, named cowork-firstname. Keys are free and unlimited, revocation stays per-person, and the audit trail shows whose agent made every change. Shared keys mean revoking one person kills everyone.
Building in public
We document the way we work so anyone on the team can do it — and so can you. Got a site that needs unlocking, or want your own?
See how we build →Written for Mats Polman, for every new BlitzMetrics team member firing up Claude for the first time, and for every human who holds the key on a fleet of agent-run sites. New hire? Start at the bootstrap block above — it is the one paste that installs this whole system. This is a living SOP — if a step changes, we update it here.