Skills & Project Rules – Teaching Claude About Your Project

You've already installed your first plugin (the Vercel plugin) in the setup lesson. Now let's make this the backbone of how you work: giving Claude persistent context so it gives consistent, relevant help every time – without re-explaining your project in every prompt.

1. Skills, plugins, and project rules

Three things give Claude that context, and they work together. Think of onboarding a teammate: skills and plugins are the professional training they already have; project rules are the company handbook for this project.

Skills – reusable expert playbooks (how to set up Next.js, wire auth, take a payment). Claude loads the right one automatically when a task matches, so your prompts stay short: you say "add login," and Claude reaches for the auth skill.

Plugins – a plugin bundles related skills together with MCP servers and other resources, so you install a whole capability in one step. The Vercel plugin you already added is exactly this: it brought a full set of skills for our stack at once.

Project rules – CLAUDE.md – a Markdown file at your project's root that Claude reads automatically at the start of every session. It holds what no skill could know: what your app does, your conventions, and your do's and don'ts.

Outcome: You understand how skills, plugins, and project rules give Claude lasting context.

2. Installing the right skills for your stack

You already added the Vercel plugin. As you build, you'll install a few more – auth and payments skills land in their own lessons. The pattern is always the same, and in the Claude desktop app it all happens through the app and the chat – no terminal for you:

• Plugins: add them from the + → Plugins menu in Claude (or browse claude.com/plugins), then restart Claude to activate them.
• Community skills: just ask Claude in the chat – "install the <publisher>/<skill-name> skill" – and it runs npx skills add <publisher>/<skill-name> for you. Then start a new chat so it loads.
• Either way, Claude only picks up something new when a session starts (the desktop app has no reload button) – so restart after a plugin, start a new chat after a skill.
• You rarely pick a skill by hand. Once installed, Claude loads it on its own when the work matches.

The mindset shift: before you write a long prompt, ask whether a skill already covers it. Most of the stack does.

The handover habit (important)

There's a catch to starting a new chat: the fresh session is a blank slate – it doesn't remember what you were just doing. So whenever you install a skill and start a new chat before building something, hand the new session its context with a short prompt. This is the single most important habit in this whole process.

A good handover prompt does three things: points Claude at your project's context, confirms the new skill is loaded, and states what to build. You'll reuse this exact shape every time a later lesson says "install X, then hand off":

Because your CLAUDE.md (next section) is read automatically every session, the handover mostly just points Claude at your concept and what you're building – and reminds it to lean on the freshly installed skill.

Outcome: You know how to add skills, and how to hand a fresh session the context it needs.

3. Refine your project's handbook – CLAUDE.md

You already have a CLAUDE.md – Claude set one up when you scaffolded the app in Local Setup. It's the file Claude reads at the start of every session to remember your project, so now's the moment to understand it and sharpen it.

What it's for: the handful of things about your product that Claude can't infer – what you're building and for whom, the conventions you care about, and anything it should never do. Skills already know your tech stack, so you don't document that here.

Have Claude review and tighten what's there:

After Claude updates it: read it through, fix anything that doesn't match your intentions, and commit it so it travels with your project.

Outcome: Your CLAUDE.md is accurate, lean, and genuinely useful to Claude.

4. Baking in your standards (like security)

Want Claude to always follow certain standards – security, accessibility, a tone for your copy? You have two levers:

• Lean on skills first. Security, payments, and auth all have dedicated skills that carry best practices. When a skill exists, that's where the expertise should live – don't duplicate it by hand.
• Add a short "Standards" section to your CLAUDE.md for the rules specific to you that no skill enforces.

A good security note in your CLAUDE.md might say:

## Standards

- Never use the `any` type without a documented reason – prefer specific types or `unknown`.
- Validate and sanitize all user input (use Zod) – never trust data from forms, URLs, or external APIs.
- Keep secrets in environment variables; never commit them or hardcode keys.
- Never use `eval()` or execute code from strings.

Keep it short and high-signal. A handbook nobody can hold in their head gets ignored – by people and by AI alike.

Outcome: Your project standards are enforced by the right mix of skills and a focused CLAUDE.md.

5. Confirming Claude has the context

You want to be sure Claude is actually using all this before you rely on it.

• Check at session start: Claude reads CLAUDE.md automatically – you'll see it reference your conventions without being told.
• Ask it directly: "What do you know about this project?" It should describe your product and standards back to you.
• Test with a real request: Ask for a small change and check that the result follows your conventions.
• If something's off: make sure CLAUDE.md is at the project root, then tighten any vague or contradictory lines.

Outcome: You can confirm Claude is loading both your skills and your project rules.