The first few weeks of using Claude Code, I noticed a pattern. Every conversation started the same way. Claude would write a component using the wrong layout structure. I would correct it. Claude would pick a colour that did not match our system. I would explain the system. Claude would create a branch with a naming convention we do not use. I would re-explain the convention.
Claude knows React. It knows TypeScript. It knows Tailwind. What it does not know — cannot know — is that our sidebar is a specific width, that our colour palette uses a specific system, that our mobile breakpoint replaces the sidebar with bottom navigation, or that we name branches a certain way. These are decisions that live in our heads, and every new conversation wipes them clean.
Skills and hooks are how I solved this. They give Claude persistent memory of the project it is building.
Skills: Decisions That Survive Between Sessions
A skill is a markdown file that loads into context when you invoke it with a slash command. No special syntax, no plugin system. You write a document describing something about your project, and Claude reads it on demand.
The important distinction: skills are context loaders, not instruction manuals. Claude already knows how to use every framework in our stack. What it does not know is how we use them. Our specific model choices, our fallback patterns, our naming conventions, our layout architecture. A skill encodes those decisions in a few hundred lines. Every session after that starts from our last decision, not from zero.
My co-founder Hugo and I share skills via the repo. When I encode a decision on Tuesday, his Claude sessions pick it up on Wednesday. Skills became a form of async knowledge transfer that does not require a meeting or a document that nobody reads.
Three Levels of Memory
Claude Code reads configuration from the working directory upward. I use the same layering for skills:
Global — Available in every session regardless of project. Vault search, session management, visual QA tools.
Company — Shared infrastructure patterns that apply across all our products. Framework conventions, deployment patterns, common service configurations.
Product — Specific to one codebase. Our main product has around 20 skills covering UI architecture, AI model configuration, deployment workflows, error handling, video composition, social publishing, and more.
This hierarchy means decisions are encoded at the right level. A framework convention lives at company level and applies everywhere. A product-specific UI pattern lives at product level and only loads when you are working in that codebase.
What Good Skills Look Like
The skills that pull their weight are the ones that encode opinions, not knowledge.
Our UI skill covers layout architecture, responsive patterns, the colour system, sidebar behaviour, and component organisation. Before it existed, Claude would occasionally put a page in a different layout structure or use hardcoded colours. Now every page follows the same skeleton because the context is always one command away.
Our deployment skill documents branching conventions, commit message format, error investigation workflow, and deployment commands. When Claude creates a branch, it follows the convention. When it writes a commit, it uses the right format. Not because I told it to in this session — because the skill encoded the convention once and it persists.
Our AI configuration skill documents the model hierarchy, fallback patterns, and usage logging approach. Any new AI feature follows the same architecture because the context is loadable on demand.
Hooks: Memory That Runs Itself
Skills are on-demand. Hooks are automatic. They run at session boundaries without anyone invoking them.
Session end — When I finish a Claude Code conversation, a hook summarises it, tags it, embeds it, and stores it in our knowledge system. Every session becomes searchable. Weeks later I can query "that time we debugged the webhook issue" and find the full conversation with context. Institutional memory accumulates without anyone writing documentation.
Session start — Notes I drop into a vault inbox get flagged at the start of the next session. I can sort them immediately or ignore them. It takes seconds and keeps the knowledge base from accumulating noise.
These are small automations individually. Compounded across hundreds of sessions, they build a searchable archive of every decision, every bug fix, every architectural choice either of us has made.
The Compound Effect
The real value is not any single skill or hook. It is the pattern: make a decision, encode it, never re-explain it.
Over time, sessions start faster. Output gets more consistent. Corrections get rarer. The AI layer accumulates your team's opinions and preferences until Claude is not just writing code that works — it is writing code that looks like your team wrote it.
For a two-person team, skills replace half the communication overhead that would otherwise go into code reviews, messages, and style guides. The skill is the style guide, and it is enforced at the point of creation rather than after the fact.
The setup cost is low. Each skill is a markdown file you could write in fifteen minutes. Most of ours started as explanations we gave Claude once and then thought "I should not have to say this again." That instinct — the moment you explain a project decision for the second time — is the signal to write a skill.