Claude Code ships blind — no context gauge, no quota counter. I built a 7-segment statusline and baked in a 50% context handoff rule, backed by Lost-in-the-Middle research. Every segment, every color rule, and the full production script explained.
Intelligence isn't about what you know — it's about how you interact with the world. That one insight explains why AI is growing up in exactly the same order as a human child, and doing it a million times faster.
70 prompt tips for Claude Code are floating around. 7 actually moved the needle for me. Real before/after terminal sessions, a copy-paste cheat sheet, and the 3 patterns I dropped.
I built 8 Claude Code Skills in three months. 5 still live on my machine. 3 are deleted. Full SKILL.md snippets for the survivors, honest post-mortems on the rest, and the 5-gate decision tree I use before building the next one.
TL;DR
My first Claude Code Skill was a commit-message-generator. I spent a Saturday afternoon on it. It had a long SKILL.md, a markdown template, three example commits. I was proud of it.
Over the next six weeks, it triggered exactly three times. Each time, I had to rewrite the commit message anyway. On week seven I deleted it.
That's when I realized: I'd been treating Skills like trophies — evidence I was a "power user." But a Skill that doesn't get invoked is just dead code in your home folder, quietly eating startup context every session.
The 5 Skills below are the ones I actually reach for. The 3 I deleted are a warning shot for anyone about to spend their own Saturday afternoon.
If Skills are brand new to you, spend 3 minutes on the official Skills overview first — I'll skim the mechanics below, but the doc is the source of truth.
If you're still on the "prompts vs Skills" fence, read my prompt-pattern cheat sheet first. The rough rule: a prompt you run three times in a week is a Skill candidate. A prompt you run once a month is not.
If you already have Skills installed, skip to The 5 Survivors or The Decision Tree.
A Skill is a folder under .claude/skills/{skill-name}/ containing at minimum one file called SKILL.md. That file has two parts:
name and a single-line description that tells Claude when to invoke the Skill---
name: outline-from-research
description: Turn a folder of research files into a ranked outline. Use when the user asks to outline, structure, or summarize a research folder.
---
# Steps
1. Read every file in the path the user mentions
2. Group by theme, then by recency
3. Return a bulleted outline...
Two things the docs don't emphasize enough but matter a lot:
description loads at startup. The full SKILL.md body only loads when Claude decides to invoke the Skill. That's what makes Skills cheap to keep around — the body is lazy-loaded (official confirmation here).That's it. Skills are simpler than they look.
Three months, eight Skills, one spreadsheet of shame. Here's the full list:
| # | Skill | Built | Deleted | Why / Why not |
|---|---|---|---|---|
| 1 | commit-message-generator | Month 1 | Month 2 | Too one-off. Prompt was faster. |
| 2 | outline-from-research | Month 1 | — | ✅ Triggers weekly |
| 3 | tone-checker | Month 1 | Month 2 | CLAUDE.md covered 90% of it |
| 4 | voice-match | Month 2 | — | ✅ Triggers on every draft |
| 5 | markdown-formatter | Month 2 | Month 3 | Prettier did it better |
| 6 | weekly-roundup | Month 2 | — | ✅ Triggers every Sunday |
| 7 | source-check | Month 3 | — | ✅ Triggers before publishing |
| 8 | format-draft | Month 3 | — | ✅ Triggers on every finished piece |
Three observations after looking at this spreadsheet for an hour:
Each Skill below is shown the way I'd actually paste it into .claude/skills/{name}/SKILL.md. Trigger phrasing matters — bad description, no invocation.
What it does: Takes a folder of research notes (articles I've collected, PDFs I've read, interview transcripts) and returns a ranked outline for a new piece.
When it triggers: "outline my research on X," "turn /research/ai-memory/ into an outline," "what are the best threads in this folder?"
---
name: outline-from-research
description: Create a ranked outline from a folder of research files. Use when the user asks to outline, structure, or summarize a research directory.
---
# Inputs
- Folder path (required)
- Target audience (default: the audience from CLAUDE.md)
- Length target (default: pillar, ~2,500 words)
# Steps
1. List every file in the folder with word count
2. Group by theme; inside each theme, sort by recency
3. Pick the 3-5 strongest themes for the target audience
4. For each theme, propose 1-3 subpoints
5. Return outline as bullets. No prose.
# Output format
- Theme (1 line)
- Subpoint (1 line)
- Next theme...
Why it works: It replaces a task I was doing in my head badly. I used to scroll a research folder for 20 minutes before writing. Now I paste the path, get a ranked outline in 90 seconds, and skip the scroll.
Real trigger log from last week: 4 invocations.
What it does: Takes a piece of my previously-published writing, uses it as a voice sample, and rewrites a new draft to match.
---
name: voice-match
description: Rewrite a draft to match the voice of a previously-published piece. Use when the user says "match my voice," "rewrite in my tone," or pastes a sample followed by a draft.
---
# Inputs
- Sample: a previously-published piece (file or pasted text)
- Draft: the new piece to adjust
# Steps
1. Read the sample; note sentence length, sign-off style, vocabulary quirks
2. Read the draft
3. Rewrite the draft to match the sample's rhythm and word choices
4. Keep all facts, data, and quotes intact. Only change voice.
# Rules
- No em-dashes (unless they appear in the sample)
- No "leverage," "unleash," "seamlessly"
- If the sample uses contractions, the output uses contractions
Why it works: Without this Skill, I was pasting a voice sample into every prompt. Manually. Redundantly. This turns 200 tokens of every prompt into one word: "voice-match."
Real trigger log from last week: 6 invocations.
What it does: On Sunday, reads my week of notes and drafts a short newsletter-style roundup.
---
name: weekly-roundup
description: Compile a short weekly newsletter draft from this week's notes. Use when the user says "weekly roundup," "summarize my week," or "draft Sunday newsletter."
---
# Scope
- Read /notes/ for files dated in the last 7 days
- Read /articles/ for any pieces published this week
# Output
- 3 sections: What I wrote / What I learned / What I'm watching next week
- 3-5 bullets per section
- Plain English. No "I'm excited to share" intros.
- Under 400 words total
# Sign off
- End with a question for readers
- Close with "— Leo"
Why it works: Newsletter fatigue is real. Sitting down to write on Sunday is miserable. The Skill turns it into editing instead of writing. 80% there in 30 seconds.
Real trigger log from last month: 4 invocations (weekly, as expected).
What it does: Scans a finished draft, lists every factual claim that doesn't have a source link, and asks me to either add one or downgrade the claim.
---
name: source-check
description: Audit a draft for unsourced factual claims. Use when the user says "source check," "audit sources," or "am I cited right?"
---
# Steps
1. Read the draft file (path provided)
2. Extract every factual claim (numbers, dates, quotes, data, "research shows")
3. For each, check if a source link is present within 2 lines
4. Output a 2-column table: Claim | Has source? (Yes/No)
5. For No rows, suggest: (a) add link, (b) reword as opinion, or (c) remove
# Notes
- Don't fact-check content. Just check for sources.
- Treat first-person experience as exempt ("I spent 2 hours" doesn't need a source)
Why it works: Every article I publish has claims. I forget to link half of them. This Skill is a pre-flight check, and it's saved me from three factually-thin drafts in the last month alone.
Real trigger log: Once per pillar piece. ~2x per month.
What it does: Applies my publication's frontmatter and Markdown conventions to a finished draft in one pass.
---
name: format-draft
description: Apply publication frontmatter and Markdown formatting rules to a finished draft. Use when the user says "format this for publishing" or "add frontmatter."
---
# Steps
1. Check if the file starts with YAML frontmatter (between --- markers)
2. If missing, add frontmatter template with placeholders (title, slug, date, tags, excerpt)
3. Ensure H1 matches the title
4. Ensure TL;DR bullet block directly follows H1
5. Verify there is exactly one blank line between sections
6. Ensure the final line is "*— Leo*"
# Do NOT
- Rewrite the content
- Reorder sections
- Touch anything outside the format rules
Why it works: Every piece I publish has the same skeleton. Applying it by hand takes 10 minutes and I always miss one thing. The Skill does it in 5 seconds and never forgets the sign-off.
Real trigger log: Once per finished piece. Weekly or more.
Not every Skill earns its slot. Here are the three that got cut, with the autopsy.
What it tried to do: Generate semantic commit messages from git diff output.
Why I built it: I thought every repetitive task deserved a Skill.
What went wrong: I commit 2-3 times a day. The Skill was invoked 3 times in 6 weeks — because I commit inside Claude Code's flow, where the next prompt naturally is "write a commit message," no Skill needed. Prompt was faster than remembering the trigger phrase.
Lesson: If a task is already inside a natural Claude prompt flow, adding a Skill just creates a second path for the same thing. Second paths rot.
Decision rule learned: If the task happens fewer than ~3 times a month and you're already in a Claude session when it happens, it doesn't need a Skill.
What it tried to do: Scan a draft and flag "AI-sounding" words — leverage, unleash, seamlessly, game-changer.
Why I built it: I was tired of fishing these out by hand.
What went wrong: I already had a rule in my ./CLAUDE.md that said "No corporate voice. No 'leverage,' 'unleash,' 'seamlessly.'" That rule alone prevented 90% of the offenders from ever appearing in a draft. The Skill was cleaning up a mess that had mostly stopped happening.
Lesson: Don't build a Skill to detect what a CLAUDE.md rule can prevent. Prevention always beats cleanup.
Decision rule learned: Before you build a corrective Skill, ask if a single CLAUDE.md line could make the problem go away upstream.
What it tried to do: Normalize indentation, tabs vs spaces, blank lines in Markdown files.
Why I built it: My drafts had inconsistent formatting.
What went wrong: Prettier does this deterministically. Prettier always returns the same output. Claude doesn't. I was asking a probabilistic tool to do a deterministic job — which is exactly what I argued against in my post on CLAUDE.md. A Reddit user put it bluntly: "Why does this need to be a Claude Skill when it could be a bash script? That seems incredibly wasteful, inefficient and simply slower."
Lesson: If a deterministic tool (linter, formatter, script) can do the job in one command, it's not Skill material.
Decision rule learned: Before building a Skill, ask: can a bash one-liner, a Prettier config, or a 5-line Python script do this? If yes, do that instead.
Every new Skill idea goes through these five gates. If any answer is a clear "no," I don't build it.
Under 3 invocations a month, a Skill is negative-value: you spent an hour building it, you'll spend 20 seconds a month using it, and it eats startup context tokens every session whether you use it or not.
If the problem can be prevented by a 1-2 line rule in ./CLAUDE.md or ~/.claude/CLAUDE.md, do that. Skills are for actions, CLAUDE.md is for rules. Don't use one to do the other's job.
Prettier, ESLint, sed, a bash script, a Make target — all faster, cheaper, and more predictable than a Skill. Use the probabilistic tool only where probabilistic behavior is the feature (creative, reasoning, judgment), not the bug.
The YAML description field must be a single line that tells Claude when to invoke the Skill. If you can't write that sentence, you haven't yet formed a clean enough mental model to make this a Skill — and Claude will invoke it inconsistently.
The best signal you need a Skill is that you're tired of repeating the same prompt. 5+ times is my personal threshold. Fewer than that, you're optimizing a fantasy.
If a Skill passes all five gates, it's worth an hour of your Saturday. If it fails any, don't build it — and you'll have more time to use the Skills that do.
If you want one Skill to start with, use the outline-from-research one above. Here it is again in a complete .claude/skills/outline-from-research/SKILL.md form:
---
name: outline-from-research
description: Create a ranked outline from a folder of research files. Use when the user asks to outline, structure, or summarize a research directory.
---
# Inputs
- Folder path (required)
- Target audience (default: the audience from CLAUDE.md)
- Length target (default: pillar-length piece, ~2,500 words)
# Steps
1. List every file in the folder with word count
2. Group by theme; inside each theme, sort by recency
3. Pick the 3-5 strongest themes for the target audience
4. For each theme, propose 1-3 subpoints
5. Return outline as bullets. No prose.
# Output format
- Theme title (1 line)
- Subpoint (1 line)
- Next theme...
# Notes
- Do not read files outside the folder
- Do not write to disk — return outline only
Drop that file in place, open Claude Code in a project, say "outline my research in /notes/ on AI workflows," and you should see it fire.
Based on my own math and public discussions from heavy users, roughly 10-15 Skills is where diminishing returns kick in. Past that, you're paying startup context for descriptions Claude rarely uses. Audit quarterly. Delete the bottom third.
Skills work anywhere Claude Code runs, including in the free tier of Claude Code itself. The Skill files live on your disk. The only requirement is that you have an active Claude Code session — Skills don't call out to extra services unless you explicitly script them to.
Two ways: (1) watch the session output — Claude usually mentions the Skill name when it fires, and (2) run /context inside a session to see whether the Skill's content is currently in context. If you never see a Skill invoked when you expect it to, rewrite the description field. That's almost always the culprit.
Project Skills (./.claude/skills/) commit to your repo and load only for that project. User Skills (~/.claude/skills/) are personal and global. My rule: if the Skill depends on a specific project's structure, it goes project-local. If it's about how I write or how I work, it goes user-global. Voice-match is user-global. Format-draft is project-local.
They solve different problems. CLAUDE.md is for always-on rules. Skills are for on-demand actions. If you're asking every session, it's a CLAUDE.md rule. If you're asking sometimes, in specific situations, it's a Skill. Mistaking one for the other is the single most common beginner error.
95% of the time, the description is the problem. Make it single-line. Make it specific about when to invoke. Include 2-3 likely trigger phrases. If that doesn't fix it, check that SKILL.md is exactly that filename (not skill.md, not README.md) and sits inside {skill-name}/ under one of the skills folders.
— Leo
Claude Code ships blind — no context gauge, no quota counter. I built a 7-segment statusline and baked in a 50% context handoff rule, backed by Lost-in-the-Middle research. Every segment, every color rule, and the full production script explained.
Intelligence isn't about what you know — it's about how you interact with the world. That one insight explains why AI is growing up in exactly the same order as a human child, and doing it a million times faster.
70 prompt tips for Claude Code are floating around. 7 actually moved the needle for me. Real before/after terminal sessions, a copy-paste cheat sheet, and the 3 patterns I dropped.
The CLAUDE.md I actually use — 67 lines, rewritten three times. Full copy, what I deleted between versions, and the six rules that made the final version stick.
Hands-on AI coding tutorials and workflow deep-dives, straight to your inbox every week.