Claude Skills: Learning This Thing From Scratch (So You Don't Have To)

I'm not here to sell you a course on "How I Mastered Claude Skills in 7 Days." I'm here to show you what happens when someone with a real problem tries to solve it using a tool they barely understand.

Okay, real talk.

A few days ago I dropped an article about vibe coding and the response honestly surprised me. People were saving it, sharing it, asking for more.

So naturally, I'm doing it again — but this time with Claude Skills.

Here's the difference though: I haven't actually built one yet.

Yep. Day zero. Ground floor. Walang alam mode.

But that's kind of the point, 'di ba? Build in public means you show the messy part too — the part where you're Googling basic shit at 3PM on a laggy laptop while your neighbor's karaoke session bleeds through the wall.

This whole post? It's me learning out loud. Figuring out if Skills can actually solve a real problem I have. And if it works, I'll tell you. If it fails spectacularly, I'll definitely tell you.

Walang highlight reel dito. Just the real thing.

What Are Claude Skills, Really?

So first things first: ano ba talaga 'to?

Skills are instruction packages that give Claude specialized knowledge it doesn't have built in.

Translation: Claude is insanely smart, pero hindi niya alam yung specific way you work. Your company's brand guidelines. Your team's workflow. That weird format your industry uses for documentation that makes zero sense to outsiders but everyone just follows anyway.

Skills fill those gaps.

Think of it like this: Imagine hiring someone ridiculously talented pero walang onboarding. They'd figure it out eventually, sure. But they'd also make rookie mistakes along the way. Skills are the onboarding docs that turn Claude from "smart intern" to "trained specialist" from day one.

Skills can teach Claude four types of knowledge:

Step-by-step workflows — "First do this, then that, then check this thing." Very paint-by-numbers.

Domain expertise — The rules and standards for your specific field. What's acceptable in legal contracts. How healthcare docs should be structured. The conventions your industry actually follows.

Tool integrations — How to work with specific file formats properly. Not just creating an Excel file, but creating one with working formulas and formatting na hindi sira pag binuksan mo.

Reusable resources — Scripts, templates, reference docs. Your actual templates, not generic garbage.

And here's what Skills are not: they're not just fancy prompts. They're not custom instructions you type into chat. They're structured packages that persist across conversations and include actual files Claude can work with.

Kumbaga, hindi ito yung "reminder note" mo sa phone. Ito yung full-on training manual.

Why I'm Even Bothering With This

Here's my problem: I suck at writing PRDs.

Product Requirements Documents. Yung detailed spec na kailangan mo before you build anything serious. Yung document na nagsasabi, "Here's what we're building, here's why, here's how it should work."

Every time I need to write one, I do this weird Frankenstein workflow:

I use Google Gemini Deep Research to pull info
I throw stuff into NotebookLM to organize my thoughts
I copy-paste fragments into Claude and ask it to help me structure everything
I re-explain the same context every. single. time.

It works. Pero ang hassle.

And every time I switch contexts — like moving from one project to another — I lose all that momentum. I have to re-teach Claude my preferences. My structure. My goals.

Nakakasawa na, pre.

So I'm wondering: Can I build a Skill that just knows how I write PRDs? One that understands my workflow, pulls from my templates, and outputs something polished without me having to babysit it?

I don't know yet. Pero that's what we're about to find out.

Inside a Skill: The Anatomy (Aka, Ano Ba Laman Nito)

Every Skill lives in a folder. That folder has a specific structure. Understanding it makes everything click.

Let me break it down:

The SKILL.md File

This is the only required file. Everything else is optional.

It has two parts: frontmatter and body.

The frontmatter is metadata at the top — just the skill's name and description:

yaml

name: my-skill-name
description: "Creates financial reports with proper formatting and formula validation. Use when user asks for financial analysis, budget reports, or spreadsheet creation."
```

The description field? Super important. It tells Claude *when* to activate this skill. If your description is too vague, the skill won't trigger when you need it. Be specific about what the skill does and when it should kick in.

The body contains everything else: rules Claude should follow, examples of good output, workflows to execute, anti-patterns to avoid.

Parang instruction manual.

### The Scripts Folder

Python or Bash code that Claude can actually run.

Use this for tasks that need to work *exactly* the same way every time. A script that validates Excel formulas before delivering. A script that checks document formatting. Automation that removes human error from repetitive tasks.

### The References Folder

Extra documentation Claude reads when it needs more context.

This keeps your SKILL.md file lean. Instead of cramming everything into one document, you move detailed info here. API docs. Database schemas. Lengthy style guides. Claude pulls from these files when relevant.

### The Assets Folder

Files *used* in the output, not for reading.

Templates. Images. Fonts. Boilerplate code. If Claude needs to *use* a file rather than *read* it for instructions, it goes here.

Think of SKILL.md as the manager giving instructions. Scripts, references, and assets are the tools and materials the worker uses to get the job done.

Simple enough, 'di ba?

---

## Skills You Can Use Right Now

Anthropic already built several professional skills you can enable today. Walang setup required.

**The DOCX skill** creates and edits Word documents properly. Tracked changes that actually work. Comments that appear where they should. Tables and images that don't break formatting.

**The XLSX skill** builds spreadsheets with formulas that actually calculate. Professional formatting. Color-coded financial models. It validates formulas before delivering, so you don't get a beautiful spreadsheet that's secretly broken.

**The PDF skill** handles everything PDF-related. Reading, merging, splitting, rotating. Filling out forms. Extracting tables from scanned documents.

**The PPTX skill** creates presentations that look designed. Not just bullet points on white slides. Proper color palettes, font pairings, layouts that vary.

**The Frontend Design skill** builds web interfaces that don't scream "AI made this." It avoids that generic aesthetic everyone can spot a mile away.

These built-in skills handle the common stuff. But the real power? Building your own.

---

## How I'm Planning to Build My First Skill

Here's my game plan for creating a PRD Writer Skill. Day zero, remember — so this might completely fail. But let's document it anyway.

**Step 1: Define the problem clearly**

What do I keep explaining to Claude over and over?
- My PRD structure (Executive Summary, Problem Statement, Goals, User Stories, Success Metrics, Technical Specs)
- The tone I want (clear but not corporate, detailed but not overwhelming)
- My research sources (Gemini Deep Research outputs, NotebookLM notes)
- The final format (Markdown, with specific sections in specific order)

**Step 2: Create the folder structure**
```
prd-writer-skill/
├── SKILL.md
├── references/
│   └── prd-template.md
└── assets/
    └── example-prd.md

I'm keeping it simple for now. No scripts yet. Baka mag-add later if needed.

Step 3: Write the frontmatter

yaml

name: prd-writer-skill
description: "Creates detailed Product Requirements Documents following G's specific structure and tone. Use when user asks to write a PRD, create product specs, or document feature requirements."

Step 4: Write the body

This is where I teach Claude how I write PRDs. My structure. My preferences. My anti-patterns.

Something like:

markdown

## Core Rules
1. Always start with Executive Summary (3-5 sentences max)
2. Problem Statement must include user pain points, not just feature ideas
3. Goals should be measurable and time-bound
4. User Stories follow format: "As a [user type], I want [goal] so that [benefit]"
5. Success Metrics must include both quantitative and qualitative measures
6. Keep tone professional but conversational — avoid corporate jargon

## Output Structure
- Executive Summary
- Problem Statement
- Goals & Objectives
- User Stories
- Success Metrics
- Technical Specifications
- Open Questions

## Anti-patterns
- Don't write vague goals like "improve user experience"
- Don't skip the "why" behind features
- Don't use buzzwords without explaining them
- Never write PRDs longer than 2000 words unless specifically requested

Step 5: Add supporting files

My prd-template.md in the references folder will have a real example of a PRD I've written before — something Claude can learn from.

My example-prd.md in assets can be a starter template Claude modifies instead of writing from scratch every time.

Step 6: Package it

A .skill file is just a ZIP with a different extension. I can write a simple Python script to package everything:

python

import zipfile
from pathlib import Path

skill_folder = Path("prd-writer-skill")
output_file = Path("prd-writer-skill.skill")

with zipfile.ZipFile(output_file, 'w') as z:
    for file in skill_folder.rglob('*'):
        if file.is_file():
            z.write(file, file.relative_to(skill_folder.parent))

Step 7: Test and iterate

Upload it to Claude. Try it with real projects. See what breaks. Fix it. Repeat.

That's the theory, at least.

Baka sa actual execution, sabog lahat. We'll see.

What I'm Hoping This Solves

If this works — and that's a big if — here's what changes:

No more re-explaining context. I just say "Write a PRD for this feature" and Claude already knows my structure, my tone, my standards.

Consistent output quality. Every PRD follows the same format. No more forgetting sections. No more inconsistent depth.

Faster turnaround. I spend less time babysitting Claude and more time actually thinking about the product.

Integration with my existing workflow. I can dump Gemini Deep Research findings and NotebookLM notes into Claude, and the Skill knows how to transform that raw research into a polished PRD.

That's the dream, anyway.

Reality might be: "Wow, this doesn't work at all and I wasted 3 hours."

Build in public means you document both, 'di ba?

Where This Is Headed

Honestly? I have no idea.

This might work perfectly on the first try. (Unlikely.)

This might require 5-10 iterations before it's actually useful. (More likely.)

This might teach me that Skills aren't the right solution for my problem and I need to explore something else entirely. (Also possible.)

But that's the whole point of this exercise.

Messy. Honest. Hopefully useful.

I'll report back once I've actually built the thing — whether it's a beautiful success or a dumpster fire.

Either way, you'll know.

If you're learning this stuff too, or if you've built Skills before and have tips, hit me up. I'm at giangallegos.com or find me on X. Let's figure this out together.

Till the next build,
G