Five Filters I Use Before Wiring a Claude Code Skill Into My Daily Workflow

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.

When you juggle several repositories and subject areas at once, a single bad Skill choice does not stay isolated; it shows up as quality drift across everything you touch. The awkward part is that you cannot feel the drift while it is happening. You notice days later, rereading what came out. I had inflated the list to nearly twenty Skills, and in the end only six stayed in daily use. Comparing the Skills that survived a month against the ones I removed within days, the filters I used to pick those six quietly emerged. There are five of them. I will walk through each 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.

Here is the short version first. Each of the five filters looks at a different property of a Skill.

Of the five, filter 1 turned out to prune my collection far harder than the rest. I will come back to why later in the article, together with the numbers I got from scoring my own Skill collection mechanically.

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 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. On one article, the single question "is there already a similar piece on the other sites?" caught a duplicate, and I swapped out the topic before writing a word.

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 an article is being written, 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 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 real 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 daily blogging stays stable 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.

Which of the Five Filters Actually Does the Pruning

It feels odd to list five filters and then admit they are not equally useful, but they are not. Skills kept coming and going after I first wrote this, and as an indie developer maintaining four sites on my own, I could not afford to keep guessing. At some point I scored the whole collection in one pass. Counting seemed more honest than asserting from memory that "filter 1 matters most."

The scoring is deliberately crude: run each SKILL.md body through three regular expressions. Filter 1 becomes "is an output path named anywhere?" Filter 2 gets a proxy — how structured the procedure is, counted as numbered steps, checkboxes, and Step headings. The third check looks for any mention of a verification or review stage.

# skill_audit.py — score the SKILL.md files on disk against three properties
import re, sys, pathlib
 
root = pathlib.Path(sys.argv[1])   # e.g. ~/.claude/skills
 
PERSIST = re.compile(
    r'(?:write|save|output|create|\u751f\u6210|\u4fdd\u5b58|\u66f8\u304d\u51fa)'
    r'[^\n]{0,80}?[`"\']?[\w./{}-]+\.(?:md|json|ya?ml|csv|html|txt)', re.I)
STEP = re.compile(
    r'(?:^\s*\d+\.\s|^\s*- \[ \]|^#{2,3}\s*(?:Step|Phase|\u30b9\u30c6\u30c3\u30d7|\u624b\u9806))', re.I | re.M)
REVIEW = re.compile(
    r'(?:verify|validate|review|checklist|gate|\u30c6\u30b9\u30c8|\u691c\u8a3c|\u30ec\u30d3\u30e5\u30fc)', re.I)
 
rows = []
for p in sorted(root.glob('*/SKILL.md')):
    t = p.read_text(errors='ignore')
    if 'DEPRECATED' in t[:200] or len(t.splitlines()) < 15:
        continue                      # skip relocation stubs
    rows.append({
        'name': p.parent.name,
        'persist': bool(PERSIST.search(t)),
        'steps': len(STEP.findall(t)),
        'review': bool(REVIEW.search(t)),
    })
 
n = len(rows)
proc = [r for r in rows if r['steps'] >= 3]    # procedural
ref = [r for r in rows if r['steps'] < 3]      # reference
ok = [r for r in proc if r['persist'] and r['review']]
 
print(f'audited={n} procedural={len(proc)} reference={len(ref)}')
print(f'persist={sum(r["persist"] for r in rows)} review={sum(r["review"] for r in rows)}')
print(f'procedural passing all three = {len(ok)}/{len(proc)}')
for r in ok:
    print('  -', r['name'], 'steps=', r['steps'])

My SKILL.md files are a mix of English and Japanese, so the patterns cover both. Run against my collection of 42 Skills, four of which are relocation stubs, it leaves 38 scored files. Here is what came back.

Two things clicked into place once I had the numbers.

The first is that only 13.2% of these Skills name an output path. Verification gets a mention in 68.4% of them, and structured steps appear in 81.6%. Of the three properties, filter 1 is the one almost nobody satisfies — and a selection criterion is only useful in proportion to how many candidates it rejects. What I had been reading as a personal preference for filter 1 was really a property of how published Skills tend to be written.

The second is that the 38 files split cleanly into two populations. All seven of the reference-type files turned out to be design conventions or framework implementation rules. Demanding an output path from those is a category error: a reference Skill exists to hand over material for a judgment call, not to execute a procedure, so leaving no artifact behind is not a defect.

Which means the five filters in this article are, more precisely, criteria for procedural Skills only. I spent a stretch measuring reference Skills with the same ruler and dropping them for it, and I have since restored several. I could not see that my own criteria carried an unstated precondition until I ran the count on disk.

Record a Skill Added a Second Entrance to Filter 4

Filter 4 said the first version of a custom Skill should start as a near-verbatim copy of a blog post you trust. That premise shifted a little on 21 July 2026. Pro, Max, and Team users can now open Record a Skill from the + menu in the desktop app, record their screen, and talk through the steps out loud. When the recording stops, the steps and the reasoning behind them are written out as a Skill you can re-run. Details and availability are documented in the Claude Code What's new page, and since conditions do change, it is worth checking the primary source before you rely on it.

Copying and recording fill different gaps, in my experience. Copying is strong when you need a pattern you do not yet have. Recording is strong when you already have the procedure but cannot articulate it. My own pre-publish checks live entirely in muscle memory, and every written version of them dropped a step somewhere. A recording does not drop steps.

That said, a recorded Skill does not satisfy filter 1 on its own. On-screen actions get captured, but "which file the result should land in" never appears as an action. Given that only 13.2% of my collection names an output path, this is not really a quirk of recording — it is how procedures get written down in general. Record the first version, then add one line for the output path. Whether you spend that extra minute is, as far as I can tell, what decides whether the Skill is still on your machine a month later.

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 every site 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:

1. Will the output still be legible to a future me three months from now?
2. Is the workflow enforced as structure (directories, file formats, checklists), not just as natural-language guidance?
3. 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 daily publishing workflow. If your own daily workflow gets even a little lighter as a result, Friday evening might end a little earlier. Thanks for reading.