Claude Skills Explained — and How We Turn One Draft Into Three Platform-Tuned Posts

Cross-platform posting is a 45-minute tax per idea — three different audiences, three sets of rules, three rewrites. We codified our workflow into a Claude Skill that turns one draft into three platform-tuned posts in 30 seconds.

What are Claude Skills?

Anthropic released Claude Skills to give Claude persistent specialist behavior without you re-explaining the same rules every session. A Skill is a folder. Inside it is one file — SKILL.md — that holds the instructions Claude should follow when the situation matches.

The mechanic is simple:

1. You create a folder like .claude/skills/my-skill/.
2. Inside, a SKILL.md with YAML frontmatter and markdown instructions.
3. At session start, Claude reads the frontmatter (name and description) of every available Skill.
4. When your request matches a Skill's description, Claude pulls in the full file and applies it.

No slash command. No /skill use. No manual loading. The Skill is just there when the work calls for it, and dormant when it doesn't.

This is a different model from prompts you paste each time. Prompts are ephemeral — you have to remember they exist and copy them in. Skills are persistent specialists Claude already knows about across every session in that project.

The SKILL.md mechanic

A SKILL.md has two parts. The top is YAML frontmatter between --- fences. The body is plain markdown.

The frontmatter carries the two fields that matter most:

• name — a short, kebab-case identifier (necl-content-poster).
• description — one or two sentences describing when to use the Skill, ideally with trigger phrases.

The description is the part Claude reads to decide whether a Skill applies. A vague description means the Skill never fires. A description that names concrete triggers ("Use when the user wants posts across channels — 'write a post', 'cross-post'") fires reliably. Write the description for the matcher, not for a human reader.

Everything below the frontmatter is the actual instruction set: structure rules, examples, checklists, banned phrases. Claude only loads this body when the Skill activates.

Project vs global install

Skills live in one of two places:

• Project-level — .claude/skills/ — checked into the repo, shared with the team, scoped to that project. Best for workflows specific to one product or codebase.
• Global — ~/.claude/skills/ — available in every project on your machine. Best for personal workflows you want everywhere, like a content Skill or a commit-message Skill.

For teams, project-level wins: the Skill ships in git, so prompt-craft becomes a versioned artifact instead of a Slack thread titled "latest version of the prompt."

Progressive disclosure

Skills are built so Claude reads only what it needs, in three layers:

1. Metadata — name + description. Loaded for every Skill, every session. Cheap.
2. SKILL.md body — loaded only when the Skill activates. Holds the full instructions.
3. references/ — extra files (long tables, style guides, examples) the Skill body points to. Loaded only when the task reaches for them.

This keeps the context window lean. You can ship a Skill with 5,000 words of reference material and Claude pays the token cost only on the rare request that needs it. The top layer stays tiny, so dozens of Skills can coexist without bloating every session.

Why Skills beat a prompt library

Most teams accumulate folders of "good prompts" — linkedin-post-prompt.md, pricing-email-prompt.md, and so on. The problem: you have to remember they exist and paste each one by hand.

Skills fix that with three changes:

1. Discoverability — Claude reads the frontmatter automatically. You write naturally; the Skill activates on its own.
2. Versioning — Skills live in your project's git repo. Team edits track. No more hunting for the current version.
3. Composability — Claude can apply several Skills in one response. A pricing email might pull a pricing-rules Skill and a cold-email-voice Skill at once.

For solo builders this saves minutes a day. For teams, it turns prompt-craft into a shipping artifact rather than tribal knowledge.

How to write your first SKILL.md

You can build a working Skill in a few minutes. Here is a small, annotated one that turns rough notes into a clean standup update.

---
name: standup-writer
description: >
  Turn rough notes into a 3-line standup update (Yesterday / Today / Blockers).
  Use when the user pastes work notes and asks for a standup, status, or daily update.
author: Your Name
license: MIT
version: 0.1.0
---

# Standup Writer

Take messy work notes and return a tight standup in exactly three lines.

## When to apply
- "Write my standup"
- "Turn these notes into a status update"
- User pastes a list of what they did and wants it formatted.

## Output format
- **Yesterday:** one line, past tense, concrete outcomes only.
- **Today:** one line, the single most important thing.
- **Blockers:** one line, or "None."

## Rules
- No filler ("worked on", "looked into"). Name the result.
- Keep each line under 120 characters.
- If notes are empty, ask what they did instead of inventing work.

Three things make this Skill work, and they apply to any Skill you write:

• The description names triggers. "standup", "status", "daily update" — these are the words Claude matches on. Without them the Skill stays dormant.
• The body is rules, not prose. Short imperatives Claude can follow ("Name the result," "under 120 characters") beat paragraphs of explanation.
• It handles the empty case. "If notes are empty, ask" stops Claude from fabricating output — the most common failure in content Skills.

Save that as ~/.claude/skills/standup-writer/SKILL.md, open Claude Code, and ask "write my standup" with some notes. The Skill fires on its own.

Why we built necl-content-poster

We run a Telegram channel (@necl_company), a LinkedIn profile, a Threads account, and an X account. Each one has its own rules:

• Telegram (RU): warm, founder-shares-cool-stuff. Brand mentions welcome.
• LinkedIn (EN): decision-makers reading on mobile. Calm, anti-hype. 1,200–1,800 characters.
• Threads (EN): one inference, screenshot-bait, 15–50 words.

Writing three posts by hand from one idea is roughly 45 minutes of tone-tuning. We did the math — that friction was holding us to maybe two posts a week.

So we codified the cross-posting workflow into a Skill. Now one draft becomes all three posts in about 30 seconds. The Skill lives in the adjacentai/necl-skills repo, which doubles as a Claude Code plugin marketplace — it carries a .claude-plugin/marketplace.json, so the Skill installs natively. It is also published on skills.sh and Smithery.

What's inside the Skill

The Skill encodes three things we worked out the hard way.

1. The 8 hook archetypes

The LinkedIn algorithm rewards posts that survive the "see more" cut. To survive it, the first one or two lines have to stop a scroller. We codified eight hook patterns that do, and the Skill makes Claude pick exactly one and commit — no mushy mixed hooks:

• Shock-stat — "After 4 years with ChatGPT, it still doesn't know who I am."
• Counter-narrative — "Speed is no longer your competitive advantage."
• Confession — "I used to do 10-hour days. The result? Full burnout."
• Provocation — "Most 'AI productivity hacks' are just theater."
• Dated story — "Last Tuesday, our agent stack burned $400 in 90 minutes."
• Question — "What if cache hit rate is now a moat?"
• List teaser — "5 things I stopped doing after we hit $50K MRR."
• Comparison — "I tried 3 frameworks. Only one survived production."

2. The banned-phrases rule

A LinkedIn audience spots GPT-text in about two seconds and scrolls past. The Skill carries a banned list and rewrites any line that hits it:

• "In an era where…", "In today's fast-paced world", "Let's dive in"
• "It's not just X — it's Y" (the em-dash sandwich)
• "navigating the landscape", "harness the power of", "at the intersection of"
• "unlock", "unleash", "leverage", "game-changer", "paradigm shift"

We built this list by reading hundreds of GPT-written posts and noting which patterns repelled engagement. If a draft would contain any of them, the Skill rewrites the line before it reaches you.

3. Per-platform structure rules

LinkedIn — the 6-block structure:

1. Hook — one or two lines, visible before the "see more" cut. One archetype, committed.
2. Context — two or three short lines, anchored in specific facts, names, or numbers.
3. Twist — the reframe that flips the obvious reading. This is the keystone; skipping it produces a blog post, not a LinkedIn post.
4. Useful core — a short list, micro-framework, or two-to-three concrete lessons.
5. Close + one specific question — name a number, a role, or a decision. Never "thoughts?"
6. PS (optional) — a small aside, counter-point, or softener.

Threads — the one-inference rule: one thought, distilled. Not three connected beats, not an essay. 15–50 words, under 30 when possible. If it could split into two posts, cut harder. No bullets, emojis, hashtags, or CTAs.

Telegram (RU): warm founder-tone, emojis as semantic markers (3–7 per post, line-starts only), light brand mentions welcome, a soft CTA in question form at the end. Plain text, no markdown. 80–220 words.

The company-context.md mechanic

Before its first run, the Skill looks for a company-context.md in your project root or .claude/ folder and reads it. The file carries your brand voice, audience per platform, tone rules, banned phrases, CTAs, common topics, reference accounts, and a few of your best-performing posts to mirror.

If the file is missing, the Skill asks you for the essentials instead of inventing a brand. We ship a template — fill in the fields, save, done. Without context, posts read generic. With it, they sound like you.

Install in under 30 seconds

Option 1 — native Claude Code plugin (recommended)

The repo is a Claude Code plugin marketplace. Add it once; every current and future NeCL Skill becomes installable with one command:

# add the NeCL marketplace (once)
claude plugin marketplace add https://github.com/adjacentai/necl-skills

# install the skill
claude plugin install necl-content-poster@necl-skills

Updates flow through the plugin system — no re-cloning when we ship improvements.

Option 2 — npx skills add (works across 70+ agents)

The skills.sh CLI installs into any supported agent — Claude Code, OpenCode, Codex, Cursor, and more:

# project-level
npx skills add adjacentai/necl-skills

# or globally for all your projects
npx skills add adjacentai/necl-skills -g

Then, in Claude Code, confirm it loaded:

What Skills are available?

You should see necl-content-poster in the list. From there, just describe what you want:

Write a post about our new RAG system that cut due-diligence from 2 months to 15 minutes.

You get all three versions in one shot.

Real example output

Input:

Just shipped a RAG system for an investment fund. Due-diligence reviews went from 2 months per deal to 15 minutes. 258 deals processed in the first quarter. Runs on-premise.

Telegram (RU):

📊 За первый квартал — 258 сделок прошло через нашу RAG-систему.

Раньше каждая сделка = 2 месяца ручного due-diligence в фонде. Теперь — 15 минут.

✅ Загружают пачку PDF → агент находит риски, инвест-тезис, цифры. ✅ Аналитик читает summary, лезет только в спорные места. ✅ Конфиденциально — модель локальная, ничего не уходит в облако.

Если у вас тонна документов и одни и те же вопросы — пишите в комментарии, разберём.

LinkedIn (EN), excerpt:

Last quarter, we shipped a RAG system that turned a 2-month due-diligence process into 15 minutes per deal. 258 deals went through it in Q1.

The lesson isn't "AI is fast." Every team knows that by now. The bottleneck in most knowledge work isn't thinking — it's the retrieval layer between the question and the source paragraph.

Threads (EN):

Replaced 2 months of analyst work with 15 minutes of retrieval.

The bottleneck in knowledge work was never thinking. It was finding the paragraph that has the answer.

Three posts, one input, about 30 seconds. Each anchored to the same facts (258 deals, 2 months → 15 minutes, on-premise), pitched to its platform.

More example outputs (illustrative)

The Skill is content-agnostic. The same structure works in any industry. Here are two illustrative inputs and their LinkedIn hooks plus Threads lines (made up to show range, not from a client).

Example — e-commerce

Input: "Built an AI returns-triage system for a DTC brand. Refund decisions dropped from 3 days to under a minute. Support tickets down 40%."

LinkedIn hook (Dated story):

Three days. That's how long a refund used to sit in this brand's queue before anyone touched it.

We wired an AI triage step at the front. Refund decisions now land in under a minute, and support tickets are down 40%. Same policy, same team — just no human reading every "where is my order" twice.

Threads (one inference):

Most support backlogs aren't a staffing problem. They're a routing problem. Sort the easy 80% automatically and the queue stops being a queue.

Example — B2B SaaS

Input: "Added semantic search to our docs. Support deflection up, ticket volume on 'how do I' questions fell by a third."

LinkedIn hook (Counter-narrative):

More documentation didn't reduce our support tickets. Better retrieval did.

We left the docs the same and swapped keyword search for semantic search. "How do I" tickets fell by a third. People weren't missing answers — they were missing the page.

Threads (one inference):

Your docs are probably fine. Your search is the bottleneck. Users don't read what they can't find.

Same skeleton — hook, anchored context, a twist, a sharp Threads line — applied to different domains.

Skills vs Prompts vs MCPs vs Custom GPTs

Four different tools, four different jobs. They are not competitors; they sit at different layers.

The short version: a prompt is a one-time instruction. A Skill is a reusable instruction Claude reaches for on its own. An MCP gives Claude hands — access to data and tools outside the chat. A Custom GPT is a packaged assistant locked to ChatGPT. Most teams overuse prompts, set up MCPs for infrastructure, and skip the persistent-expertise layer in between — which is exactly where the daily friction lives.

Common mistakes when writing Skills

A few patterns we see kill Skills before they earn their keep:

• A vague description. "Helps with content" never matches a real request. Name concrete triggers and verbs ("write a post", "cross-post").
• Writing for a human, not the matcher. The description is read by the model deciding whether to fire the Skill. Front-load the when, not the what.
• Dumping everything into SKILL.md. Long reference tables and examples belong in references/ so they load only when needed. A bloated body costs tokens on every activation.
• No empty/edge case handling. Without an instruction like "if input is missing, ask," Claude invents content. Always tell it what to do when the input is thin.
• Soft rules. "Try to keep it short" gets ignored. "Under 120 characters per line" gets followed. Give numbers and hard limits.
• No examples. One worked input → output in the Skill anchors the model better than three paragraphs of guidance.
• Overlapping Skills with identical triggers. If two Skills both claim "write a post," activation gets unpredictable. Keep description scopes distinct.

See also

• necl-content-poster Skill on GitHub — install + source
• Our publishing playbook — how to ship your own Skill to every marketplace
• necl-hn-mcp — pair it with this for a full HN → posts pipeline
• Stop using GPT-4 for everything — picking the right model per task

FAQ