06 / Extend your workspace

Teach Claude
how you work.

Start with project instructions. Add reusable workflows and integrations only when they solve a real need.

Which extension does what?

Create a useful CLAUDE.md

Inside your project, run /init, then inspect the generated file. Keep facts concise and accurate. Replace guessed build commands with commands that actually work in the repository.

# Project guidance

## Purpose
A simple personal website for learning.

## Working rules
- Explain a plan before large changes.
- Make the smallest change that satisfies the request.
- Match the existing project style.
- Do not add unrelated features or dependencies.
- Never include secrets in code or logs.

## Verification
- Review your own diff after every implementation or code change.
- Run the relevant checks supported by this project.
- For visible changes, inspect the page and keyboard behavior.
- Report checks performed, results, and anything untested.

## Delivery
- Summarize changed files and the reason for each change.
- Ask before publishing, merging, or changing external accounts.

Use /memory to inspect and manage instruction files and auto memory. Repository instructions can travel with Git; personal machine settings and memories do not automatically travel to cloud sessions.

Create your first custom command

Create .claude/skills/preflight/SKILL.md in your project. This defines the command /preflight. The example requests a review and does not grant tool permissions.

---
name: preflight
description: Review the current change before a commit.
disable-model-invocation: true
---

Inspect the current diff without changing files.
1. Explain the intended behavior.
2. Look for correctness and security problems.
3. Identify relevant tests and missing evidence.
4. Report findings by severity with file references.
Do not commit, push, publish, or send messages.

Run /reload-skills, then /preflight. The frontmatter disables automatic invocation, so you choose when to run it. Older .claude/commands/*.md files are still supported; skill folders provide room for additional reference files and scripts.

Connect tools with MCP

MCP means Model Context Protocol. A server offers tools Claude can call, such as querying an issue tracker. Some servers run locally; others are remote services. Neither the protocol nor a marketplace listing proves a server is trustworthy.

Hooks and plugins

Hooks react to lifecycle events such as PreToolUse or PostToolUse. They can run real programs, so inspect the command and its inputs. Start with a hook that reports information before allowing one to modify files or block actions. Use /hooks to review configuration.

Use /plugin to inspect available plugin management. Prefer known publishers and review the package’s skills, hooks, and MCP connections. Removing a plugin is separate from revoking a credential it used.

Subagents, worktrees, and teams

Ask Claude to create a narrowly scoped reviewer or researcher when separate context is useful. Agent definitions may live in .claude/agents/ for a project or ~/.claude/agents/ for your machine. Separate worktrees provide separate working copies of a Git repository; they are not complete security isolation.

Agent teams coordinate multiple sessions and are an advanced, availability-dependent feature. More agents can increase cost and conflicting edits. Start with one assistant, then use parallel work only for tasks with clear boundaries.

Official references: Project instructions and memory ↗ · Skills ↗ · Hooks ↗ · MCP connections ↗ · Plugin marketplaces ↗ · Custom subagents ↗ · Agent teams ↗