I Applied Anthropic's Internal Skills Playbook to My Projects - Here's What Changed

@trq212 recently published "Lessons from Building Claude Code: How We Use Skills", Anthropic's internal playbook for how they build and use Skills in Claude Code.

I don't come from a software engineering background. I work in accounting, and I use Claude Code across projects ranging from helping with my bookkeeping automation, AWS Lambda (which I used for the AWS 10,000 Ideas competition) recently to backends to mobile appications (I was very excited to publish my first application to the Google and iOS stores :D). Skills sounded useful but I never knew how to implement them appropriately or how to structure them properly.

I spent an afternoon applying every recommendation from the article to my own setup across 5 active projects in Claude Code. The following is what I built, what worked, and I recommend you use for your own projects.

Let's start with this: Skills are "just markdown files"

They're surprisingly not. A skill is a folder. It can contain scripts, config files, reference data, templates, anything Claude might need.

Here's what my AWS debugging skill now looks like:

aws-debug/
SKILL.md: main instructions
config.json: which AWS profile to use per project
references/services.md: maps my projects to Lambda functions, log groups, common errors

The key thing here: Claude sees the SKILL.md when I say "check the logs." But it only opens references/services.md when it actually needs to look up a specific log group or service mapping. So it's only loaded when relevant.

The 6 skills that changed my workflow:

1. /gotcha, the skill that improves all other skills

This one is my favourite. Every time Claude makes a mistake, I can type:

/gotcha Claude forgot --profile flightmap

And it figures out which skill that belongs to, opens the file, and adds it to the Gotchas section. It's quick and simple.

The original article makes this point that the Gotchas section is the most valuable part of any skill. I completely agree. But the problem is nobody goes back and updates their skills after writing them. /gotcha fixes that.

1. /careful, on-demand production safety

An on-demand hook that blocks destructive commands (rm -rf, DROP TABLE, git push --force, AWS deletes) for the current session only.

I mentioned it before - I come from a non technical background so this is incredibly useful. Not ideal to have on all the time but something you should initiate before pushing anything live or anywhere near production.

1. /aws-debug, a debugging runbook

Instead of me manually going into CloudWatch every time something breaks, this skill walks Claude through a proper investigation. Checks the logs, look for cold start timeouts, missing env vars, permission errors, and then writes up a structured report.

I put a config.json in there with my AWS profiles for each project. That way Claude never forgets which --profile flag to use. That was literally one of the first gotchas I wrote into the skill because it kept getting it wrong.

1. /bookkeeping-verify, domain-specific verification

This is where it gets interesting for non-engineers. I categorise bank transactions for accounting clients, hundreds of them per company, into Sage 50 nominal codes. After I'm done categorising, this skill runs through everything and checks: did I miss any? Is the same payee showing up under different categories? Any duplicates? Any codes that don't exist?

There's a reference file in there (references/categories.md) with all the valid categories and a table of common mistakes. Things like PayPal fees ending up under General Expenses when they should be Bank Charges, or HMRC payments going to the wrong nominal code or account. Claude reads that file during verification but it's not loaded the rest of the time.

This is a good example of skills going beyond pure software engineering. If your work has any kind of quality checklist, you can turn it into a skill.

1. /explain, making code accessible

I built this one because I'm not from a technical background (have I mentioned this before?) and sometimes I Want Claude to explain what a piece of code does in plain English. Either using analogies or starting with the big picture before the details.

If you're learning as you go or working with code outside your comfort zone, something like this is worth building.

1. Enhanced /preflight with progressive disclosure

I already had a preflight skill that runs before every commit. But it was a single file trying to cover security, frontend, backend, and accessibility. Now it looks like:

preflight/
SKILL.md: the main orchestrator (reads sub-files as needed)
checks/security.md: detailed security checklist + project-specific notes
frontend.md: accessibility, performance, design consistency
backend.md: API safety, Lambda gotchas, Python patterns

Claude reads the main file and then only pulls in the relevant checks file based on what kind of project it's in. Working on a React app? It reads frontend.md. Working on a Lambda backend? It reads backend.md. The rest stays out of the way.

A few things I have since learned:

Write descriptions for Claude, not for you

The description field at the top of your SKILL.md isn't a summary. It's what Claude uses to decide whether to trigger the skill. So write it like a trigger condition.

Bad: "AWS debugging tool"

Good: "Debug AWS Lambda errors, API Gateway issues, or CloudWatch anomalies. Use when the user reports a Lambda failure, 5xx error, timeout, or says 'check the logs'"

Wire skills into your project CLAUDE.md

The skill knows how to do something. Your project's CLAUDE.md tells Claude when to do it.

In my bookkeeping project I added:
Run /bookkeeping-verify after categorising any company

In my AWS projects:
Run /careful before touching live AWS resources
Use /aws-debug when Lambda errors occur

The skills work in any project, but each project's CLAUDE.md gives them context.

Use config files for stuff that changes per project

If your skill needs something specific to you or your project (AWS profile, a channel name, a database), put a config.json in the skill folder. Claude reads it when the skill runs.

Global skills vs project overrides

I put reusable skills in ~/.claude/skills/ so they're available everywhere. Some projects also have their own skills in .claude/skills/ that override the global ones. Right now I've got 13 global skills and 6 project-level overrides across 4 projects.

If you're starting from scratch

Start with two skills: /preflight and /gotcha. Preflight stops you committing broken code. Gotcha captures mistakes so they don't happen twice. Build everything else from there.

Don't try to write a perfect skill on day one. Anthropic's own team says their best skills started as a few lines and one gotcha, and got better over time because people kept adding to them. That tracks with my experience too.

Use folders. The moment your skill has more than a couple of sections of reference material, split it into sub-files. Claude only reads what it needs.

Don't write stuff Claude already knows. Focus on things that are specific to you: your project requirements, your conventions, the edge cases that keep tripping you up.

Always launch Claude from your project directory. I know this sounds obvious and, to be honest, I still forget to do this myself. When Claude starts in the right place, it picks up your project CLAUDE.md and all your project-level skills. Start from the wrong directory and none of that loads instantly.

And if you're not an engineer, that's fine. If your work has repeatable processes or domain knowledge that Claude doesn't have by default, it works the same way. My bookkeeping verification skill has nothing to do with code. It's just a quality checklist for accounting data.

How long did this take?

One afternoon to set everything up. After that it's just /gotcha whenever something goes wrong. The skills keep getting better on their own.

My full setup

~/.claude/skills/ (13 global skills)

• audit: weekly codebase audit
• aws-debug: AWS debugging runbook (+config, +references)
• bookkeeping-verify: transaction verification (+references)
• careful: on-demand prod safety hook
• docs: documentation generation
• explain: plain English code explainer
• gotcha: capture mistakes into skill gotchas
• migrate: dependency upgrades
• perf: performance analysis
• preflight: pre-commit gates (+checks/ sub-files)
• refactor: code cleanup
• release: generic release pipeline
• test: test generation

Plus 6 project-level overrides across 4 projects for specific release and preflight workflows.

Thank you very much to @trq212 for publishing the original article. Went from "I should probably sort out my skills at some point" to actually having a setup I am very happy with (for now :D).

What skills have you built? I would be keen to see what others are doing with this.

The key thing here: Claude sees the SKILL.md when I say "check the logs." But it only opens references/services.md when it actually needs to look up a specific log group or service mapping. So it's only loaded when relevant.