For a few weeks, my Claude Code setup felt noticeably heavier than it should have. I had pulled in too many Skills from public repos, and /help no longer fit on a single screen. Worse, when something went sideways, I could not trace which Skill had fired. I have seen the same complaint from several developers lately, so today I want to write down how I eventually pruned that list.
I have been shipping iOS and Android apps as a solo developer since 2014. The wallpaper apps alone have crossed 50 million downloads, and these days I run four AI-focused tech blogs — including Claude Lab — through a Claude Code pipeline. About sixteen articles get generated and pushed every day across those sites. With that volume, a bad Skill choice does not stay isolated; it shows up as quality drift across the entire surface. After comparing the Skills that survived a month against the ones I removed within days, five filters quietly emerged. I will walk through them while referencing the Zenn article by inari111 ("Claude Code Skills I use in daily development") where the same Skills come up from a different angle.
Filter 1: Keep Skills That Persist a Plan to Disk
The first Skills I removed were the ones that planned entirely in conversation and slid straight into implementation. For short tasks that is fine, but a cross-site refactor that runs three to five hours quickly loses its thread.
What stayed is the combination of brainstorming and writing-plans from obra's superpowers. Forcing "the plan must always be saved as Markdown into the given directory" creates an artifact I can actually review later. In my own setup I lock the path to something like plans/{site}/00x_{topic}/plan.md, sitting outside each site's repository in a shared parent folder.
There is a useful side effect. When I open a new Claude Code session a week later, "where did I stop thinking?" becomes a question that is answered by feeding plan.md back in. Whether a Skill leaves an artifact you can park outside your head is, for me, the single biggest predictor of whether it stays in daily use.
Filter 2: Does It Physically Block Missed Requirements?
The second filter is about requirements gathering — Skills that recursively dig out what you forgot. I run fumiya-kume's dig and decomposition together. Before adding them, I would routinely rework generated articles two or three more times than I do now.
dig uses AskUserQuestionTool to keep asking until the requirements are tight. I start with cursory inputs — category, level, premium or free — but dig keeps probing: who is the reader stuck, are similar articles already on the other three sites, what changed in this topic in the last thirty days. It felt fussy at first, but answering those questions forced me to re-articulate the brief properly.
decomposition then breaks the plan into small enough tasks that, once handed to the implementation phase, Claude Code can run for thirty to forty minutes without stopping. Even without auto mode, that continuous stretch is generous; while the evening publish slot is running for the four blogs, I can put the same hours into a wallpaper-app version bump.
Filter 3: Does the Output Survive Future Human Editing?
The third filter is about output format. Adding the drawio-mcp skill-cli increased how often I draw architecture diagrams. It tends to be introduced in the context of Go applications, but it works the same for my use cases — wallpaper-app version bumps on iOS and Android, or the shared Cloudflare Workers topology that powers the four blogs.
What I like is that the final output is both .drawio source and a PNG or SVG, all tracked in Git. If an AI-generated diagram only lives as an image, "I want to tweak one line three months from now" becomes "I have to redraw from scratch." With the source preserved, a human can hand-edit a single arrow. Since I started screening Skills for "can a human meaningfully edit this artifact later?", almost every pure image-generation Skill has fallen out of daily use.
Filter 4: Bootstrap Custom Skills by Copying Someone Else's Blog Post
The fourth filter applies to custom Skills. The custom Skill that has lasted longest on my machine is feature-dev, which is essentially boris's How I Use Claude Code rewritten as a Skill, almost verbatim.
The three-phase structure — research, planning, implementation — fits my pipeline, and phase 2 with its annotation cycle is what makes it stick.
<!-- NOTE: a suggestion or addition -->
<!-- REJECT: this part is rejected because... -->
<!-- QUESTION: I want to confirm... -->
Three comment tags carry every signal I need to send back. Reviewing a plan feels closer to dropping Slack emoji reactions than writing a proper response.
What I have come to believe is that the first version of any custom Skill should be a near-verbatim copy of a blog post you already trust. I lifted boris's structure, ran it through two weeks of four-site publishing, and only then tweaked the edges. When I tried to write a custom Skill from my own original outline first, fuzzy AI-driven blocks crept in, and within a month I could no longer remember exactly what the Skill was supposed to do for me. boris puts it well:
I want implementation to be boring. The creative work happened in the annotation cycles.
Implementation should be boring; the creative work belongs in the annotation cycle. The same is true for solo work. The reason my pipeline can keep producing sixteen articles a day is precisely because the Skill steps are boringly fixed.
Filter 5: Keep at Least One "Different-Family" Reviewer Skill
The last one is the codex Skill I cannot give up. I first wrote my own, inspired by owayo's article on moving Claude Code × Codex from MCP to a Skill, and these days I run it alongside the official openai/codex-plugin-cc.
Usage is simple: after Claude Code finishes an implementation, I type /codex please review the diff. Codex regularly catches things the planning phase missed — for instance, a forgotten DEPLOY_VERSION bump on Cloudflare Workers, or a missing cache invalidation after rewriting articles.json. Across eight weeks it has flagged six issues specific to my setup, each of which would have left the entire site cached against a stale build. That alone earned the Skill its slot.
The wider lesson is this: keep at least one Skill that calls out to a different model family as a final reviewer. It compensates for the blind spots created by Skills you wrote yourself in the same voice. Reserving one slot for a "different-family" reviewer is my last filter.
A Mundane Detail That Mattered: Where to Park the Plans
A quick aside for anyone who has read this far. Where you store the plan.md files that these Skills produce is more important than it sounds. I started by putting _plans/ inside each site's repository. Doing that across four sites made git status noisier than I liked, and reusing plans across repos became awkward.
Now I keep a single plans/ folder next to the repositories themselves, broken down by site.
~/Workspace/
├── claudelab.net/
├── gemilab.net/
├── antigravitylab.net/
├── rorklab.net/
└── plans/
├── claudelab/
│ ├── 001_skill-md-grep-guard/
│ │ ├── research.md
│ │ └── plan.md
│ └── 002_premium-rescue-pipeline/
│ └── plan.md
└── gemilab/
└── 001_gemini-canva-mcp-coverage/
└── plan.md
When I want to read them in a browser I serve the directory with k1LoW/mo.
My Final Check Before a Skill Earns a Daily Slot
When I try a new Skill now, I run it past three quick questions of my own:
- Will the output still be legible to a future me three months from now?
- Is the workflow enforced as structure (directories, file formats, checklists), not just as natural-language guidance?
- Is there still room for a different model family — or a human — to act as the final reviewer?
If a Skill clears all three, it is unlikely to cause incidents inside a pipeline that publishes sixteen articles a day. If your own daily workflow gets even a little lighter as a result, Friday evening might end a little earlier. Thanks for reading.