How I Use Skills | The /dsalathe/blog

Every time I wanted to publish a new blog post, I went through the same ritual. Create a folder. Copy the frontmatter template from an old post. Pick a publication date — wait, is next Tuesday already taken? Check the other posts. Calculate the date. Copy the default cover image. Then actually write the thing, remembering to match the tone of my other articles, add the right MDX components, link to relevant concepts, generate tags, and handle SEO metadata. Then generate a cover image. Then write a LinkedIn post about it.

None of it was hard. All of it was tedious. And tedious repeatable work is exactly what Claude Code skills were made for.

I started with two skills: one to scaffold a post, one to write it. That solved the immediate friction. But as my workflows grew — concepts, cover images, LinkedIn promotion — I kept adding more skills, making them composable, and learning what works (and what doesn’t) in this kind of system. Here’s what the journey looks like.

What Are Skills?

Skills are markdown instruction files that live in your project’s .claude/skills/ directory. Each one defines a repeatable workflow that Claude Code can execute as a slash command. Think of them as detailed SOPs (Standard Operating Procedures) written for an AI — they describe what to do, when to ask the user for input, and how to handle edge cases.

Here’s what my current system looks like:

.claude/skills/
├── init-post/
│   └── SKILL.md
├── write-post/
│   ├── SKILL.md
│   └── style-reference.md       # Extracted writing guidelines
├── write-concept/
│   └── SKILL.md
├── cover-image/
│   └── SKILL.md
├── linkedin-post/
│   ├── SKILL.md
│   └── examples.md              # Real LinkedIn posts for tone calibration
└── publish-post/
    └── SKILL.md                  # Meta-skill that chains the others

Once defined, you invoke them like any other slash command: /init-post or /write-post my-slug. Claude reads the instructions and follows them step by step, using the tools it has available — reading files, writing files, running commands, and asking you questions when it needs input.

The key insight: you’re not writing code, you’re writing instructions. The same way you’d onboard a colleague to your workflow, except this colleague has perfect recall and never gets bored of repetitive tasks.

The Foundation: `/init-post`

The first skill handles all the scaffolding for a new blog post. When I run /init-post, here’s what happens:

The Interview

Claude asks me a series of questions in two batches. First the basics — title, topic (AI, Dev, Software Architecture, etc.), and whether it’s a standalone post or part of an epic series. Then the details — a short SEO description, the publication date, and whether I have a cover image ready.

For publication dates, I built in several options that match how I actually think about scheduling:

Today — for when inspiration strikes
Next Tuesday — my regular publishing day
Next available Tuesday — this one’s interesting: Claude scans all existing posts, collects their publication dates, and finds the first Tuesday that isn’t already taken
In one month — for posts I want to queue up
Custom date — for everything else

The Scaffolding

Once it has my answers, the skill:

Generates a URL-friendly slug from the title
Creates the folder at src/content/posts/<slug>/
Copies the default cover image if I don’t have one ready
Writes the index.mdx with minimal frontmatter — title, description, date, topic, and an empty tags array

The result is a clean starting point with all the boring parts handled. The skill even tells me the exact next step: Ready to write? Run: /write-post <slug>.

What the Instruction File Looks Like

The SKILL.md for /init-post is around 130 lines of structured markdown. It specifies which tools Claude is allowed to use (Read, Write, Glob, Grep, Bash for file copies), describes each question to ask, explains the date calculation logic in detail, and defines the frontmatter template.

The “next available Tuesday” logic is a good example of encoding domain knowledge into a skill. I could have just typed the date manually each time, but encoding the algorithm means I never have to think about scheduling conflicts again.

The Writer: `/write-post`

This is the most ambitious skill. It guides the entire writing process — from blank page to polished article with tags, SEO metadata, and internal links.

Phase 1: Silent Context Gathering

Before saying anything to me, Claude reads several things behind the scenes:

The target post — to check for existing content or notes
Two or three published posts — to internalize my writing style (tone, structure, how I use MDX components)
The concepts directory — to know what internal links are available (things like Astro, Docker, Keycloak, Claude Code)

This is crucial. Without this step, the output would sound generic. With it, Claude matches my conversational-but-technical tone and naturally weaves in links to my knowledge graph.

Phase 2: The Interview

The skill offers two modes:

Full interview — Claude asks detailed questions: what’s your thesis, who’s the audience, what surprised you, what are the trade-offs? It even challenges my assumptions and pushes for concrete examples.
Quick draft from bullet points — I dump my rough thoughts and Claude expands them.

I use the quick draft mode most of the time. I usually know what I want to say — I just don’t want to deal with the formatting, structure, and polish.

Phase 3: Confirmation

Before writing, Claude summarizes what it understood: the main thesis, the planned sections, the key points, which concepts it’ll link to. This is a sanity check — it’s much easier to correct a bullet-point outline than to rewrite a full article.

Phase 4: The Writing

Claude writes the full article following guidelines I extracted into a separate style-reference.md file. This keeps the main skill focused on the workflow while the reference material — MDX component names, icon lists, example flows — lives in a dedicated lookup file that Claude consults during writing.

Phase 5: Automatic Enrichment

After writing, the skill handles metadata without asking:

Tags: Generates 5-8 relevant tags based on the content and writes them into the frontmatter
SEO keyword: Identifies the primary keyword and adds it
Description: Refines the original description if the actual article suggests a better one

This is where skills really shine. These post-processing steps are easy to forget when you’re doing them manually. Encoding them in the skill means they happen every single time.

Phase 6: Cover Image

The skill crafts an image prompt based on the article’s theme, shows it to me, and — if I approve — generates a 4K cover image using nanobanana, an MCP server for Gemini image generation. This is where MCP and skills complement each other: MCP provides the capability (image generation), the skill provides the workflow (read article, craft prompt, ask user, generate, move file, clean up temp files).

Supporting Files: Teaching by Example

As skills grew, I hit a practical problem: SKILL.md was getting long. The official recommendation is to keep it under 500 lines and move reference material into supporting files — additional markdown files in the skill’s directory that Claude loads when needed.

I use this pattern in two places:

write-post/style-reference.md contains my writing style guidelines, the complete list of MDX components and their usage, available icon names for <SectionWithIcon>, and example interaction flows. Phase 4 of write-post says: “Read style-reference.md for writing style, icons, and MDX component reference.” Claude loads it on demand rather than carrying it through every phase.

linkedin-post/examples.md contains four annotated examples of real LinkedIn posts I’ve written, each tagged with the style it demonstrates (hook-first, story-first, value-first) and annotations explaining why each works. When generating new LinkedIn posts, Claude reads these to calibrate tone and format — not to copy, but to understand what my voice sounds like on that platform.

The supporting files pattern keeps each SKILL.md focused on the procedural workflow while detailed reference material lives next to it, loaded only when relevant.

Beyond Posts: `/write-concept` and `/cover-image`

Not every content type needs the same depth of workflow.

`/write-concept`

Concepts are simpler than posts — single MDX files with a status, metrics, and three sections (What is it / My Opinion / Conclusion). The skill reflects that simplicity:

Ask for the concept name, topic, and status (Bet/Watch/Bail/Default)
Ask for the user’s opinion — this is the only section that genuinely needs human input
Autonomously research the concept via web search — what it does, its ecosystem, known limitations
Determine metrics (1-5 scores for learning UX, potential, impact, ecosystem, market standard, maintainability) and present them with justifications for review
Write the complete concept card — “What is it” from research, “My Opinion” expanded from my input, “Conclusion” synthesized from both

The key design choice: the agent does the research and writes the factual parts autonomously. I only provide my opinion. For a concept that might take 30 minutes to research and write manually, this brings it down to one short interaction.

`/cover-image`

This is a focused, single-purpose skill extracted from write-post’s Phase 6. It reads any post, crafts an image prompt from the content, and generates a cover via MCP. Useful for regenerating covers independently or for posts that were written without /write-post.

The Meta-Skill: `/publish-post`

Once I had focused skills for each step, a natural question emerged: can I chain them?

/publish-post is a thin orchestration layer — about 80 lines — that sequences the other skills into a full pipeline:

Ask where I’m starting: fresh idea, existing draft, or content already written
If fresh: invoke /init-post
If draft or fresh: invoke /write-post <slug> (which handles writing + cover image)
Invoke /linkedin-post <slug> for promotion text
Summarize everything and offer to commit

The meta-skill contains almost no logic itself. All real work lives in the sub-skills. This means fixing a bug in /init-post fixes it everywhere — whether I invoke it directly or through /publish-post.

The `disable-model-invocation` Gotcha

I learned something non-obvious while building this. Skills have a frontmatter option called disable-model-invocation: true that prevents Claude from loading the skill automatically — making it user-only via /name. I originally had this on every skill, thinking I’d always invoke them manually.

The problem: when /publish-post tries to chain /init-post, Claude uses the Skill tool internally. That’s programmatic invocation — exactly what disable-model-invocation: true blocks. The meta-skill couldn’t call its sub-skills.

The fix was removing the flag from the sub-skills and instead writing specific descriptions (“Use when the user explicitly asks to create a new post”) that prevent unwanted auto-invocation. Claude won’t randomly decide to scaffold a blog post — the descriptions act as guardrails without blocking programmatic chaining.

Why Not Subagents?

Claude Code also supports subagents — isolated workers that run in their own context window and return summaries. When I started expanding the system, subagents seemed like a natural fit. Research a concept in isolation, then return the results. Write a LinkedIn post in a separate context. Parallelize the work.

But for my workflows, subagents don’t fit. Three reasons:

The workflows are interactive. The interview in /write-post, the opinion question in /write-concept, the metric review step — all of these use AskUserQuestion, which doesn’t work in background subagents. My skills are conversations, not jobs to fire and forget.
The content collection is small. With ~15 posts and ~25 concepts, there’s no context window pressure that isolation would solve. A subagent reading 3 reference posts and returning a summary saves nothing when those posts fit comfortably in the main context.
The built-in subagents already handle research. Claude Code’s built-in Explore agent (fast, read-only, runs on Haiku) handles “search the codebase” tasks automatically. I don’t need custom subagents for that.

When subagents would make sense: if the blog grew to hundreds of posts and style consistency needed a dedicated reviewer, if multi-author support required different voice profiles, or if external research (web scraping, API calls) became heavy enough that isolating it from the main conversation saved meaningful context. That day hasn’t come yet.

The takeaway: skills and subagents solve different problems. Skills are for interactive, sequential workflows. Subagents are for isolated, parallel work. Know which you need before building.

The Meta Moment

Here’s the part I enjoy most: this very article was created using skills.

I ran /init-post, answered a few questions, and got the scaffolded post with the right date and default cover image. Then I ran /write-post, chose the quick draft path, gave my bullet points about the expanded system, confirmed the outline, and Claude wrote the draft you’re reading now. The skills read themselves as part of the context-gathering phase — Claude literally read its own instructions to understand what I wanted to write about.

It’s skills all the way down.

When Skills Make Sense

Skills aren’t the right tool for everything. They work best when:

The workflow is repeatable — you do the same steps more than a few times
There are decisions with clear logic — date calculations, file naming conventions, template structures
The process involves multiple tools — reading files, writing files, searching the codebase, asking for user input
You want consistency — same frontmatter format, same folder structure, same post-processing steps every time
The steps are composable — each skill does one thing well, and a meta-skill can chain them

They’re less useful for one-off tasks or workflows that change constantly. The investment in writing the skill file needs to pay off through repeated use.

Building a Composable System

If I were starting over, here’s what I’d do differently from day one:

Make each skill independently invocable. Every skill should work as a standalone command. The meta-skill is a convenience, not a requirement.
Use supporting files early. Don’t let SKILL.md grow past 300 lines. Extract reference material (style guides, component lists, examples) into sibling files.
Don’t use disable-model-invocation: true if you plan to chain. The flag blocks programmatic invocation, which breaks meta-skills. Use specific descriptions as guardrails instead.
Keep the meta-skill thin. It should be orchestration only — no real logic. All substance lives in the sub-skills.
Put examples next to their skill. LinkedIn post examples live in the linkedin-post/ directory, not in a shared “templates” folder. This keeps each skill self-contained.

Getting Started with Your Own Skills

If you want to build skills for your own project:

Start with a workflow you repeat often. Document the steps you take manually.
Create .claude/skills/<name>/SKILL.md and describe the workflow in plain markdown.
Specify the tools Claude is allowed to use in the frontmatter.
Be explicit about edge cases — what happens if a file already exists? What if the user provides unexpected input?
Iterate. Run the skill, see where it falls short, and refine the instructions.

The instructions don’t need to be perfect on the first try. Like any good documentation, they improve as you discover the gaps.

Final Thoughts

The gap between “I have an idea for a blog post” and “the post is live with a cover image and LinkedIn promotion” used to involve a dozen small friction points. None of them were intellectually challenging, but together they added up to enough resistance that I’d sometimes postpone writing.

Six skill files — about 700 lines of markdown total, plus supporting files — eliminated that friction. The workflow is now: /publish-post, answer the interview questions, review, done. Or I can pick and choose: /cover-image to regenerate a cover, /linkedin-post for promotion text, /write-concept to quickly document a new tool.

The broader lesson isn’t about blog posts specifically. It’s about recognizing the repeatable workflows in your own projects and encoding them as instructions that an AI can follow reliably. Skills turn tribal knowledge into executable processes — and when you make them composable, the whole becomes greater than the sum of its parts.