Stop Repeating Yourself: How Plugins and Skills Turn Claude Code Into a Teammate That Remembers

You know the feeling. Monday morning, you open your coding agent, and it has forgotten everything: the naming convention you agreed on last week, the edge case that took an hour to debug, the fact that this repo never uses that library. You paste the same instructions again. By Friday, half your "AI-assisted" time is spent re-explaining context.

The fix is usually not a cleverer prompt. It is a better setup. Claude Code — like other agentic coding tools — can be extended with plugins and skills: small, reusable pieces of configuration that teach the agent how your project works, once, and then apply that knowledge every session. Here is how the pieces fit together, and how to build your first ones.

What "plugins" actually means

The word gets thrown around loosely, so it helps to separate the building blocks:

• Skills are markdown files with a short description. When your request matches the description, the agent loads the skill and follows it — a checklist, a workflow, a set of conventions.
• Slash commands are shortcuts you invoke explicitly, like /review or /deploy-check, each backed by a prompt file.
• MCP servers connect the agent to outside tools — your issue tracker, docs, database, or calendar — so it can pull real context instead of guessing.
• Hooks run a script automatically at certain moments, for example formatting code after every edit or blocking a commit without tests.
• CLAUDE.md is a plain markdown file at your project root. The agent reads it every session. It is the simplest form of memory there is.

None of this is magic. It is configuration, versioned in your repo like any other code — which means it can be reviewed, improved, and shared with your team.

Five things worth extending

1. Route work to the right model

Not every task needs your strongest, most expensive model. A quick rename or a docstring fix can run on a smaller, faster one; a gnarly refactor deserves the heavyweight. Some setups add routing that picks a model per task, or falls back to a second provider when the first hits a rate limit, so a long session does not die halfway through. The principle matters more than any specific tool: match the model to the job, and make the fallback automatic instead of manual.

2. Shrink the context bill

The most expensive thing an agent does is re-read your codebase. If it scans the same ten files every time you ask a question, you pay for those tokens on every turn. Two habits help more than any plugin: keep a short architecture note in CLAUDE.md (folder layout, where the important modules live, what not to touch), and let the agent query an index or map of the code instead of dumping whole files into context. Small, targeted reads beat full-file reads — for your bill and for the quality of the answer.

3. Give it memory that survives the weekend

CLAUDE.md covers project facts. Session memory is the other half: decisions you made, bugs you already fixed, preferences you stated out loud. A simple pattern is a MEMORY.md or notes file the agent updates at the end of each session — "we chose library X over Y because…", "the flaky test is caused by…". Next session, it reads the note first. It is unglamorous, and it is the single highest-leverage habit I have found.

4. Encode your workflow, not just your rules

Most teams already have a workflow: plan, implement, test, review. A skill turns that workflow into something the agent actually follows. Instead of saying "write tests" every time, you write a testing skill once — what "done" means, which commands run the suite, what coverage you expect — and the agent applies it whenever it writes code. The same goes for code review, commit messages, and release checklists. You are not automating judgement; you are automating the boring parts of it.

5. Connect the tools you already use

An agent that can read your issue tracker will write a fix that matches the ticket. One that can see your docs will not invent an API that does not exist. MCP servers are the standard way to wire these in, and the setup is usually a few lines of JSON. Start with one connection that removes a real annoyance — for most teams, that is issues or docs — and add more only when the first one earns its keep.

A worked example: a review skill in ten minutes

Say you want every change reviewed against your own standards before you see it. Create a skill file:

.claude/skills/review/SKILL.md

---
name: review
description: "Review code changes for correctness, security, and consistency with this repo's conventions. Use after implementing a feature or fixing a bug."
---

# Code review

1. Read the diff, not the whole file. Focus on what changed.
2. Check: does it handle the error paths? Are inputs validated at the boundary?
3. Check: does it follow the conventions in CLAUDE.md (naming, error handling, logging)?
4. List findings as: BLOCKER, SHOULD-FIX, NIT. Never rewrite the code yourself — report and let the human decide.
5. If tests are missing for changed behaviour, say so explicitly.

Add the project facts it should check against in CLAUDE.md:

# Project conventions

- Language: TypeScript, strict mode. No `any` in new code.
- Errors: return typed errors, never throw across module boundaries.
- Tests: vitest, colocated `*.test.ts` files. Run `npm test` before claiming done.
- Never commit secrets. Never edit `migrations/` by hand.

Now type "review this change" and the agent loads the skill, reads the diff, and reports against your rules. You can go further with a hook that runs the formatter and linter after every edit, so style arguments never reach a human at all:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{ "type": "command", "command": "npm run lint:fix" }]
      }
    ]
  }
}

Start with one skill. Use it for a week. Notice what it gets wrong, fix the wording, and only then add the next one.

What to watch out for

A few honest caveats before you install half the internet's plugin lists:

• A plugin runs in your repo. Read what it does before installing it, especially anything that executes code or touches your shell. Treat third-party skills like third-party dependencies: pin them, review them, update them deliberately.
• Savings claims vary. A "50% fewer tokens" claim measured on someone else's codebase means little for yours. Measure your own usage before and after — most tools show token counts per session — and keep what demonstrably helps.
• Plugins do not replace review. The whole point of the review skill above is that a human still decides. An agent with better memory is still an agent; it will still confidently produce the wrong thing, just faster and with better formatting.
• Less is more. Five well-written skills beat fifty installed ones. Every skill the agent has to choose between is a chance to pick the wrong one.

The real shift

The demos make it look like the model is the product. In daily use, the product is the setup around the model: the memory files, the checklists, the routing, the connections. That setup is boring, it is yours to build, and it compounds — every good skill you write pays off in every session after it.

Build one skill this week. The one you keep re-explaining is the right place to start.

— Written by Davis George · zhuan.xyz