Claude Skills in 14 Minutes: The Layer Above Projects

By Lazar Milicevic · Published June 10, 2026 · 8 min read

Most founders I audit have the same setup: five or six Claude Projects, each one carrying a 400-line system prompt, and a sticky note on the monitor reminding them which Project does what. By month three they're back to copy-pasting context into raw chats because they can't remember which Project handles invoices vs. proposals. The fix isn't a better prompt. It's the layer above Projects: Skills.

Prompts vs. Projects vs. Skills — pick the right tool

The official docs make this sound harder than it is. Three layers, three jobs:

• Prompt — a one-time instruction. You type it, Claude responds, it's gone.
• Project — a workspace with persistent context. You pick it from a dropdown before you start chatting. Good for "I'm working on Client X all week."
• Skill — a markdown file with YAML frontmatter that lives in a skills folder. Claude auto-invokes it the moment your message matches a trigger condition. You don't pick it. You don't load it. You just talk.

That last part is what people miss. A Skill activates itself. You write "parse this invoice" and Claude reaches into the folder, pulls the right SOP, and executes — without you selecting anything from a dropdown.

The decision tree I use with every client:

• Doing it once? → Prompt.
• Doing it repeatedly inside one topic for a bounded period? → Project.
• Doing it repeatedly across many sessions and contexts with a stable SOP? → Skill.

The honest test: if you've pasted the same instructions into Claude more than three times this month, that's a Skill waiting to be born.

Anatomy of a working Skill — five fields, no code

Open any Skill file and you'll see exactly five things. No API calls. No Python. Just markdown.

---
name: invoice-parser
description: Parse incoming supplier invoices and extract line items, totals, VAT, and due dates into structured JSON.
triggers:
  - "parse this invoice"
  - "extract from this PDF"
  - "invoice attached"
  - file_type: application/pdf
---

# Instructions

You are an invoice parsing specialist for a Serbian small business.
When the user provides an invoice (PDF, image, or text), extract:

1. supplier_name (handle Cyrillic — transliterate to Latin in a `supplier_name_latin` field)
2. supplier_tax_id (PIB, 9 digits)
3. invoice_number
4. issue_date (ISO 8601)
5. due_date (ISO 8601 — if missing, compute as issue_date + 15 days and flag `due_date_inferred: true`)
6. line_items: [{ description, quantity, unit_price, vat_rate, line_total }]
7. subtotal, vat_total, grand_total
8. currency (default RSD)

If VAT is missing entirely, set `vat_total: 0` and add a warning
in the `parser_notes` array. Never fabricate VAT.

Return ONLY valid JSON. No prose, no markdown fences.

# Examples

## Example 1: Standard RSD invoice with VAT
Input: [invoice text...]
Output:
{ "supplier_name": "Дунав осигурање", "supplier_name_latin": "Dunav osiguranje", ... }

## Example 2: EUR invoice, no VAT line
...

## Example 3: Cyrillic supplier, multiple line items
...

That's the whole file. The five fields:

• name — short, kebab-case (invoice-parser, lead-qualifier)
• description — one sentence, written so Claude knows when to use it
• triggers — phrases or file types that activate the Skill
• instructions — the SOP, written like a brief for a new hire
• examples — two or three concrete input-output pairs

The invoice-parser above is ~120 lines. It replaces ~300 lines of context the client used to paste into every chat. The math matters: that's roughly 70% fewer tokens per invocation, because the Skill only loads when triggered instead of sitting in the context window all day.

The six Skills running an agency back-office

This is a real stack I deployed for a small agency. Six Skills handle the repetitive back-office layer:

Each one replaces between 200 and 400 lines of repeated prompt context. None of them required code. None of them required an API integration. They are markdown files in a folder.

What a live invocation actually looks like

I open a fresh chat. No Project selected. No context loaded. I type:

hey, can you triage my inbox, here's the snapshot [pastes 40 thread subjects + senders]

Claude detects the trigger phrase, the gmail-triage Skill auto-loads, and within ~10 seconds I get back a clean four-bucket sort: respond-now, respond-this-week, delegate, archive — with one-line suggested replies for the respond-now items. I didn't pick a Project. I didn't paste an SOP. I didn't even mention the word "Skill."

Writing your first Skill — a folder structure that scales

Most people overthink this. Here's the structure I use across every client:

~/claude-skills/
├── back-office/
│   ├── invoice-parser.md
│   ├── gmail-triage.md
│   └── weekly-report.md
├── sales/
│   ├── lead-qualifier.md
│   ├── proposal-writer.md
│   └── client-onboarding.md
└── personal/
    ├── meeting-notes.md
    └── calendar-prep.md

Group by job function, not by tool. The folder name doesn't activate anything — it's purely for your own sanity when you're maintaining 15+ Skills six months from now.

Three rules I enforce on every Skill I ship:

• One Skill = one job. If your description has the word "and" twice, split it.
• Examples are non-negotiable. Skills without examples drift. Two or three input-output pairs anchor the output shape better than 50 lines of instructions.
• Trigger phrases must be how a human actually talks. Not "INVOICE_PARSE_REQUEST" — write "parse this invoice", "extract from this PDF", "here's the supplier bill."

Common failure modes — and how I debug them

I've shipped enough of these to know where they break.

Failure 1: The Skill doesn't activate. Almost always a trigger problem. Open the Skill, look at your triggers, and ask: "Would I actually phrase it that way?" Add 2-3 more natural variants. Skills should activate on the intent, not the magic word.

Failure 2: The Skill activates when it shouldn't. Your triggers are too generic. "report" will fire weekly-report on every message containing the word. Tighten to "Friday update", "weekly report for", "status report for [client]".

Failure 3: Output drifts over time. Your examples are stale or you only have one. Add a third example that covers the edge case you keep hand-correcting. The example is the contract — Claude takes its shape cues from there, not from the instructions block.

Failure 4: The Skill is too long. If your instructions block crosses 200 lines, you've packed multiple jobs into one Skill. Split it. invoice-parser should parse. A separate invoice-validator should check for compliance issues. Two Skills, two triggers, cleaner outputs.

When NOT to use Skills

Skills aren't a hammer for every nail. Skip them when:

• The SOP changes weekly. A Skill is for stable processes. If you're still iterating on the workflow, stay in raw prompts until it settles.
• You need real tool execution (API calls, database writes, file system actions). Skills generate output. They don't do things. For execution you want an agent with tool use, not a Skill.
• The task is genuinely one-off. Don't write a Skill for something you'll run twice.

The line I draw with clients: a Skill is for institutional knowledge — the stuff you'd brief a new hire on during week one. If a junior employee would need it written down, write a Skill. If it changes daily, keep it in a Project.

Why bizflowai.io helps with this

A lot of the work we do at bizflowai.io starts exactly here — auditing where a client is spending tokens and hours on context they should have packaged as Skills, then building the 5-10 Skills that handle the repeatable back-office layer (invoice parsing, lead qualification, inbox triage, proposal drafting, weekly reporting). The Skills layer is usually the cheapest, highest-leverage thing we deploy in the first two weeks, before we touch any agent infrastructure or integrations.

Frequently asked questions

What is a Claude Skill?

A Claude Skill is a markdown file with YAML frontmatter that lives in a skills folder and auto-invokes when your message matches a trigger condition. Unlike Projects, which you pick from a dropdown, Skills activate themselves based on triggers. Each Skill contains five parts: a kebab-case name, a one-sentence description, trigger conditions, an instructions block written like a new-hire brief, and two or three input-output examples.

What is the difference between a Claude prompt, Project, and Skill?

A prompt is a one-time instruction you type into chat. A Project is a workspace with persistent context that you manually select from a dropdown before chatting. A Skill is the layer above Projects: a markdown file that Claude auto-loads the moment your message matches its trigger phrases. You don't pick a Skill or load it — you just talk normally and the right one activates.

How do I structure a Claude Skill file?

A working Skill file contains five elements: a short kebab-case name (like invoice-parser), a one-sentence description of what it does and when to use it, trigger conditions (phrases or contexts that activate it), an instructions block written like an SOP for a new hire, and two or three concrete input-output examples. It's just a markdown file with YAML frontmatter — no code or API calls required.

Why do Skills reduce token usage compared to Projects?

Skills cut token usage per invocation by roughly seventy percent compared to pasting an SOP into every chat. Instead of repeatedly loading two hundred to four hundred lines of context into a prompt or Project, the Skill auto-loads only when its trigger fires. One example invoice-parser Skill replaced roughly three hundred lines of context the client used to paste into every single chat.

When should I use a Skill instead of a Claude Project?

Use a Skill when you have a repeatable SOP that should activate automatically based on the task — like parsing invoices, qualifying leads, or triaging email. Use a Project when you need persistent workspace context you consciously switch into. Founders who paste giant system prompts into multiple Projects often forget which Project does what; Skills solve this by auto-invoking on trigger phrases instead of requiring manual selection.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.