/publish replaced a 40-line shell script and 6 manual steps
/sync keeps 3 platforms aligned from one source file
/qa catches broken links and word-count fails before publish
Command design lesson: narrow inputs, one job, loud failures
I run a solo studio. There is no second person to catch my mistakes, so I built five Claude Code slash commands to be the second person. They replaced about 200 lines of fragile glue code and roughly 30 minutes of manual checking per article. Here is what each one does, what it replaced, and what I learned about designing commands that actually get used.
Why Slash Commands Beat Loose Scripts
Before the slash commands, my workflow was a folder of shell scripts I had to remember the order of. Run one, copy the output, paste it into another, hope I did not skip a step. The problem was never the scripts. The problem was me, at 11pm, forgetting that step four had to run before step five.
A slash command fixes the memory problem. I type /publish and Claude Code already knows the sequence, the file paths, and the checks. The command is a markdown file with instructions. That is the whole trick. There is no compiled binary, no framework, just a prompt that tells Claude what to do and which tools it is allowed to touch.
The first thing I learned is that a command should do one job. My early attempt was a single mega-command that built, checked, and shipped everything. It failed constantly because when one part broke, I could not tell which part. Splitting it into five narrow commands cut my debugging time roughly in half. Each one now has a clear input and a clear output.
The second thing I learned is that commands need to fail loudly. A silent failure in a script means a broken article goes live and I find out from a reader. So every command I built ends with a verification step that prints a pass or fail line in plain text. If /qa finds a dead link, it says so in red-flag language I cannot miss. No green checkmark unless everything actually passed.
I built these on top of a standard Claude Code project setup. If you have not configured your project files yet, the structure matters more than the commands do. I walked through my full configuration in Claude Code Setup, which covers the project files these commands read from. Get that base right first. The commands are only as good as the context they sit on top of.
The third lesson: keep the inputs narrow. A command that asks "what do you want to do?" is useless. A command that takes one file path and does exactly one thing to it is reliable. Every command below takes the smallest input it can.
/publish and /sync: The Daily Workhorses
/publish is the one I run most. It takes a draft markdown file and ships it to my Shopify blog. Before, this was a 40-line shell script that handled auth tokens, image uploads, and the API call. It worked until it did not, usually because a token expired and the error message was buried in 200 lines of curl output.
Now /publish reads the draft, confirms the word count is in range, uploads the hero image, and posts. It prints the live URL when done. If anything fails, it stops and tells me the exact step. The command itself is about 25 lines of instructions. The actual heavy lifting still happens through the Shopify admin API, but I never touch the raw request anymore. I describe the outcome I want and the command handles the plumbing.
What surprised me is how much the confirmation step matters. /publish does not post blind. It shows me the title, the tags, and the word count, then waits. That two-second pause has saved me from publishing three drafts with placeholder titles still in them. The cost of the pause is nothing. The cost of a placeholder going live is an embarrassing edit history.
/sync is the second workhorse. I write once and the same content needs to appear in three places: the blog, a social schedule, and an email queue. Before, I copied and pasted and reformatted by hand, which meant the three versions drifted apart over time. A typo fixed on the blog stayed broken in the social version.
Now /sync reads one source file and generates the three formats. The blog version stays full length. The social version gets cut to the platform limit with a link back. The email version gets a subject line and a preview snippet. I push the social schedule out through Buffer, which lines up a week of posts from one run. The drift problem is gone because there is only ever one source of truth.
The design lesson from /sync was about output formatting. Each platform has different rules, so I gave the command explicit format blocks rather than letting it guess. Guessing produced posts that were 15 characters over the limit and got truncated mid-word. Explicit rules produced posts that fit every time.
/qa: The Command That Catches Me
/qa is the one that made the biggest difference to quality. It runs before /publish and checks the draft against every rule I keep breaking. Word count in range. No broken internal links. No banned words. At least three outbound links. Currency formatted correctly. Heading structure intact.
I built it because I kept shipping articles that broke my own style rules. I would write "we" instead of "I", or drop an em dash out of habit, or link to a page that did not exist yet. Each mistake was small. Together they made the blog look sloppy, and a sloppy blog is a blog nobody trusts.
The command works like a linter for prose. It reads the file, runs each check, and prints a table of pass and fail lines. A failed check blocks the publish. The first week I ran it, it caught 11 issues across 4 articles. Things I would have sworn were clean. One article had two links to the same handle with two different anchor texts, which I never would have spotted by eye.
The hardest part of building /qa was deciding what counts as a hard fail versus a warning. Early on I made everything a hard fail and the command was so strict I could not ship anything. A single passive sentence would block the whole article. That is not quality control, that is a hostage situation. I moved most style issues to warnings and kept only the real problems as blocks: broken links, word count out of range, banned terms, missing internal links.
That split is the actual lesson. A QA tool that blocks everything gets disabled within a day. A QA tool that blocks the things that genuinely hurt, and merely flags the rest, gets used forever. I check the warnings, fix what matters, and ship. The hard fails are non-negotiable. The warnings are advice. Knowing which is which is the whole design.
For the visual side, I run hero images through Magnific before /qa checks the file, so the image link is already live and the check passes on the first run. Sequencing the steps right means fewer loops.
/seo and /audit: The Slow-Burn Tools
/seo and /audit are the two I run less often but value most over time. /seo takes a finished draft and checks it against search intent. Does the title match the topic. Is the main keyword in the first 100 words. Are the headings descriptive instead of clever. Is there a clear answer near the top for the obvious question a reader would ask.
It does not stuff keywords. I learned early that keyword stuffing reads like a robot wrote it, and readers leave. Instead /seo checks that the article actually answers the question its title promises. If the title says "5 commands" and the article only covers four, it flags that. That kind of mismatch is what makes people bounce, and it is invisible when you are too close to your own draft.
The lesson from /seo was that good search optimization and good writing are mostly the same thing. Clear headings help readers and search engines equally. A direct answer near the top helps both. I stopped treating SEO as a separate task and started treating it as a final readability pass. The command just enforces that I actually do the pass instead of skipping it when I am tired.
/audit is the slow burn. Once a week it crawls my published articles and reports on the whole blog as a system. Which articles have no internal links pointing to them. Which clusters are thin. Which old posts link to handles that have since changed. The orphan-page problem is the one it catches best. I had 6 articles last month with zero inbound links, which means readers could land on them but never find them by browsing. /audit listed all six. I added links and the cluster started holding together.
Building /audit taught me that the most useful commands operate on the whole system, not one file. /publish and /qa care about one article. /audit cares about how the articles relate. That second view is the one that catches structural problems, and structural problems are the ones that quietly cost you the most readers.
If you want the full picture of how these commands fit into a working studio, the Claude Blueprint lays out the whole system end to end, from project files through publishing. The five commands here are the operational layer that sits on top of that blueprint.
Bottom Line
Five commands, each doing one narrow job, replaced about 200 lines of glue code and roughly 30 minutes of manual checking per article. That is the headline number, but the real win is consistency. I do not forget steps anymore because the command remembers them for me.
The design principles transfer to any tool you build. One job per command. Narrow inputs. Loud failures. A clear split between what blocks and what merely warns. A system-level view alongside the file-level ones. None of these are clever. They are just the rules that keep a solo operation from drowning in its own process.
If you are running Claude Code already, start with one command, not five. Build the one that fixes your most annoying repeated task, use it for a week, then build the next. The compounding comes from the set, but the habit comes from the first one working reliably. Get the base setup right, build narrow, fail loud, and let the commands do the remembering.
This article contains affiliate links. If you sign up through them, I may earn a small commission at no extra cost to you. (Ad)
Top comments (0)