I spend a lot of time in the terminal these days. Between Claude Code conversations, git workflows, and general tinkering, my hands rarely leave the keyboard. So when I found myself repeatedly copying blog post drafts from Claude Code, opening WordPress, pasting content, formatting it in Gutenberg, adding tags, and hitting “Save Draft,” I knew something had to change.
I was manually shuttling text between two interfaces like it was 2015. I wanted Claude Code to take the content we just wrote together, format it properly, and push it to WordPress as a draft. All from the terminal. No browser tabs, no copy-paste.
So I built a skill to do that.
What’s a Claude Code skill?
If you haven’t played with skills yet, think of them as reusable instruction sets. You write a SKILL.md file describing what the skill does and what steps to follow. When you invoke it, Claude reads those instructions and executes them using its available tools: reading files, running shell commands, asking you questions.
They’re not code. They’re more like playbooks. You encode a workflow once and reuse it whenever you need it.
wp-cli over SSH
My WordPress site runs on a remote server. I don’t have a local installation, and I didn’t want to deal with the REST API or application passwords. What I do have is SSH access with key-based auth and wp-cli on both machines.
wp-cli is a command-line tool for managing WordPress. You can create posts, manage taxonomies, update settings, basically anything from the admin panel but in the terminal. The part that matters here is the SSH integration. You configure an alias in ~/.wp-cli/config.yml:
@produzione:
ssh: user@yourserver.com/path/to/wordpressThen wp @produzione post list runs on your remote server, transparently. Just prefix your commands with the alias.
Setting this up took maybe two minutes: install wp-cli locally via Homebrew, confirm it was already on the server (it was), create the config file, test with wp @produzione option get siteurl. Done.
What the skill does
The flow mirrors what I’d do manually, minus the context switching.
It starts by looking at the conversation. Usually Claude and I have already been working on a blog post: brainstorming, drafting, revising. The content is sitting right there. The skill picks it up.
Then it prepares metadata. It proposes a title, selects tags from my existing tag list, writes a short excerpt. I see all of this before anything happens.
Next, Gutenberg formatting. WordPress uses a block editor, and if you dump raw HTML into a post, it shows up as a “Classic” block. It works, but looks messy when you try to edit it later. The skill wraps every paragraph, heading, list, and code block in the proper Gutenberg comments:
<!-- wp:paragraph -->
<p>Your paragraph text here.</p>
<!-- /wp:paragraph -->
<!-- wp:heading {"level":2} -->
<h2 class="wp-block-heading">Your heading</h2>
<!-- /wp:heading -->When I open the post in WordPress, each block is recognized and editable. Small detail, but it matters if you ever need to tweak something after the fact.
After formatting, the skill shows a preview: title, type, status, tags, excerpt, and the first few hundred characters. It waits for my confirmation. Only then does it create the draft.
The creation itself is two steps: upload the formatted content to a temp file on the server via SSH, then run wp @produzione post create with all the metadata flags. It returns the post ID and a direct link to the WordPress edit screen.
Design decisions
A few choices shaped how this works. They all came from thinking about what could go wrong.
I never let it publish directly. The skill always uses --post_status=draft. I go to the admin panel, read through the post one more time, click Publish myself. That last step stays human. I don’t want any automated tool posting to my blog without me looking at the final result in the actual editor.
It always asks before doing anything. The preview shows exactly what’s about to be created. If the tags are wrong or the title is off, I fix it before anything touches WordPress.
And the Gutenberg formatting, while it would have been easier to skip, prevents a mess in the editor later. Posts created this way look exactly like posts I’d write manually in the block editor.
How authentication works
This part might be the most transferable idea if you’re building your own skills.
The skill contains zero credentials. No passwords, no API keys, no tokens anywhere in the SKILL.md file. It just tells Claude to run wp @produzione post create and the system handles the rest. The SSH key lives in ~/.ssh/, the wp-cli alias in ~/.wp-cli/config.yml. Configured once, at the system level, before the skill ever runs.
The skill file is just markdown. You could share it or put it in a repo without leaking anything. Claude never sees your credentials during the conversation. If you rotate keys or change servers, you update the system config, not the skill.
The same approach works for email (msmtp with credentials in ~/.msmtprc), file transfers (rsync over the same SSH keys), or API calls (environment variables). The skill describes what to do. The environment handles access.
Testing
Claude Code has a skill-creator tool for iterating on skills. I set up two test cases: one with content already in English, one in Italian needing translation. For each, I checked that the output used draft status, had proper Gutenberg blocks, proposed valid tags, showed a preview, and used the right wp-cli alias.
All eleven assertions passed on the first try. The skill is simple enough that there wasn’t much to get wrong, which is kind of the point. A good skill should be focused and predictable.
Wrapping up
The whole thing took about thirty minutes, including installing wp-cli and setting up SSH. Now when I finish writing a post with Claude, I say “publish this on the blog” and it handles the formatting, metadata, and upload. I still go to WordPress to hit the publish button myself.
If you want to try something similar, here’s what I’d keep in mind:
- Skills are instructions, not programs. You’re writing a playbook for Claude, not compiling code.
- Keep credentials out of skills entirely. SSH keys and config files handle auth at the system level.
- Always keep a human checkpoint before anything irreversible. Draft-only mode and confirmation prompts are what make this trustworthy enough to actually use.
- Format for your target system. Proper Gutenberg blocks take a bit more work upfront but save time every time you edit a post later.
Start with wp-cli, get the SSH connection working, and build from there. The pattern extends to anything you can run from the command line.