These are my top 5 takeaways from Anthropic Skilljar

I spent 1.5 years using Claude almost daily. Drafting code, writing docs, debugging the same way I had since 2023. Then I took the Anthropic Skilljar curriculum over a few evenings and realised I had been using maybe 20% of the product. Five features specifically, all of them sitting in the project directory I had been editing in for months, none of them surfaced by the chat-only workflow. I am writing this in case you are running the same workflow I was.

Hooks are the only thing that actually enforces behaviour

If you have ever told Claude “from now on, before X, do Y” and watched it forget by the third turn, you wanted a hook. Memory cannot enforce behaviour, because memory is just text the model has to choose to honour. A hook is a process. It runs whether the model remembers or not.

A hook is a shell command that the Claude Code harness runs in response to an event. Pre-tool-use, post-tool-use, on-stop, on-prompt-submit. They live in .claude/settings.json, and the part that matters is who runs them. The harness runs them. Not the model.

The first hook I wrote auto-runs npm run typecheck after any TypeScript edit and surfaces the result back into the context. The second one logs every Bash command Claude executes to a timestamped local file, so when something breaks later I can replay what happened. These two alone made the difference between Claude as an assistant I had to babysit and Claude as a teammate I could leave running for forty minutes.

Skills are how you stop telling Claude the same thing twice

A skill is a folder under .claude/skills/, with a SKILL.md describing when to trigger and what to do, plus any supporting templates or guides. Claude invokes it through the Skill tool when a user message matches the trigger description. The cover image at the top of this article was generated by one. I have an svg-cover skill that loads the moment I ask for a new thumbnail. It reads the existing covers in public/covers/, anchors on the dark palette and geometric style I have already established, picks a visual metaphor that fits the piece, and writes the SVG to disk at the matching slug. Every cover on this site sits in the same visual register because the skill enforces it. I never re-explain the aesthetic.

That is the entire pitch. The reason most Claude output looks AI-shaped is that people keep telling Claude what to do in a chat message instead of writing it down once in a skill. The chat message disappears. The skill stays. The svg-cover skill I wrote months ago means every article ships with a thumbnail that looks like it belongs on the site, without me ever opening Illustrator, and I did the work once.

The bigger lifehack came when I built a skill for something I had been dodging for years. Layering commits on GitHub. Writing the kind of commit messages that explain why a change exists, not just what it changed. I had been shipping fix bug and update files for years, leaving my teammates to git-blame their way back to context every time something broke. The skill flipped that overnight. When I tell Claude to ship a feature now, it stages logical chunks, writes a proper message for each one, and produces a commit history my future self can actually read.

Here is roughly what the skill file looks like:

# .claude/skills/layered-commit/SKILL.md
---
name: layered-commit
description: Stage and commit recent changes as logical, layered commits with detailed messages. Trigger when the user says "commit this" or "ship this".
---

Workflow:
1. Run `git diff` and `git status` to see all changes.
2. Group changes into logical layers (refactor, feature, test, docs).
3. Stage each layer with explicit file paths. Never `git add -A`.
4. Write each commit message in this format:

   <type>: <short summary in imperative mood>

   <why the change exists: the constraint, bug, or motivation>
   <what it does at a high level, only if not obvious from the diff>

5. Never collapse layers into one commit.
6. If a layer touches more than five files, ask before staging.

The skill is forty lines. The result is a commit history that reads like documentation. My teammates stopped pinging me to ask what a change was for. I stopped dreading the commit step because I no longer have to think about it.

Build skills for the things you do repeatedly. Code review, PR descriptions, meeting notes, client follow-ups. Thirty minutes of setup, permanent productivity gain.

Subagents are how you stop blowing up the context window

The chat-only workflow forces every conversation into one long thread. Research a library, plan the implementation, write the code, debug the failing test, all in the same context. By turn forty the model is sitting on 200k tokens of half-relevant history and quality degrades. You have probably noticed this and blamed the model.

Subagents fix it by spawning isolated child agents that do one job, return a summary, and disappear. The Explore subagent searches the codebase and returns “here is what you need to know” without dragging 80 file reads into the main thread. The Plan subagent designs an implementation strategy and returns a step list. The general-purpose subagent goes off and does a multi-step research task while the main thread keeps moving on something else.

The mental model that locked in for me: subagents are staff, the main thread is you. You delegate, you read the report, you keep working. The context window stays clean. The model stays sharp. Multi-step research tasks that used to require a fresh chat now happen inline without poisoning the main conversation.

The permission system is why Anthropic engineers let Claude run unattended

In any Claude Code project, .claude/settings.json defines a permission boundary. Which tools are auto-allowed, which require asking, which are blocked outright. Combined with Auto Mode, this is what lets the agent work for ten or twenty minutes without prompting you on every Bash command.

{
  "permissions": {
    "allow": ["Read", "Edit", "Grep", "Bash(npm run test:*)"],
    "ask": ["Bash(*)", "WebFetch"],
    "deny": ["Bash(rm -rf *)", "Bash(git push --force *)"]
  }
}

I used to babysit Claude. Every Bash command, every file write, every web fetch was a manual approval, and I assumed that was just the cost of using the tool safely. The actual cost was that I had never configured what I trusted. Once I wrote that config, Claude could run lint, run tests, edit files, search the codebase, and grep for symbols without asking. Everything risky still gates on me. The permission boundary is a contract between you and the agent. Here is what you may do alone. Here is what you must clear with me. The Anthropic engineers writing 75% of new code with AI assistance are not typing faster. They are configured better.

CLAUDE.md and slash commands are how the project teaches Claude itself

A CLAUDE.md at the root of a project (and nested in subdirectories where it makes sense) loads automatically into every Claude session running in that directory. It is where you put the things that are true forever about this codebase. The architecture diagram in prose. The testing convention. The naming rules. The deploy command. The thing this project does differently from the last one because of a decision made in a meeting nine months ago.

Slash commands extend this. A .claude/commands/<name>.md file defines a custom command Claude can invoke. I have /review (runs my code-review checklist against the current branch), /ship (runs tests, checks the branch is clean, drafts a PR description in my style), and /scaffold (bootstraps a new module with the layout I always use). They are not magic. They are written instructions I do not have to type out again every time.

The first time you commit a CLAUDE.md to a real project and watch a teammate’s Claude session pick it up automatically, the model stops being a per-developer trick. It becomes part of the codebase.

The chat window is the demo. The real product is a stack of small text files in your project directory that tell Claude how this team actually works.

Why the curriculum is worth the evenings

None of these five features are hidden behind a paywall. None of them require an enterprise plan. They are documented, free, and most of them were already on your filesystem the day you installed Claude Code. The reason you are not using them is that nobody told you to look, and the chat window is good enough that you never had to.

Take the Skilljar curriculum seriously for two evenings. Pick three of these five and wire them into one real project this week. Write the CLAUDE.md. Define the permission config. Build one skill for something you do twice a week. Watch what changes. The gap between the developer using Claude as a chat box and the developer using Claude as a configured agent is not a 10% productivity difference. It is the difference between a tool and a teammate, and the only thing standing between those two versions of you is a few hours of reading the official docs.

If you want the catalogue, it is at anthropic.skilljar.com. The free version is the same as the paid version, which is the same version the Anthropic engineering team uses to onboard new hires. The chat window will still be there when you finish.