A better setup.
A clearer mind.

Use the CLI inside your editor’s terminal, or install Anthropic’s official VS Code extension. Pick native Windows for Windows projects; use WSL 2 when your project needs Linux tools or shell sandboxing.

1. Install Git for Windows for version control and Bash support. Install the runtime your app needs separately.
2. Open PowerShell and run the official native installer below. It downloads and executes Anthropic’s installer; review the linked instructions first.
3. Restart the terminal, verify the version, then run Claude from your project folder and follow sign-in.

irm https://claude.ai/install.ps1 | iex
claude --version
# Open your actual project folder before continuing.
claude

Success check You can open a session, read project files and explain the repository structure.

Reference: Installation & Windows options ↗ · VS Code extension ↗

Open /model to see what your account can use. Aliases resolve differently by provider and can change over time. Check the active model with /status; avoid copying old model IDs from videos.

/model sonnet
/status

Use Plan mode to explore unfamiliar code or settle an approach before edits. Keep ordinary permission prompts while learning. Review usage as you go; a subscription and API billing are different access paths.

References: Model configuration ↗ · Permission modes ↗

Keep personal preferences in ~/.claude/CLAUDE.md and project conventions in the repository’s CLAUDE.md. Run /init for a starting point, then edit it. Make instructions short and specific; keep detailed product knowledge in separate documents.

my-project/
  CLAUDE.md
  docs/
    brief.md          # audience, problem, acceptance criteria
    architecture.md   # boundaries and data flow
    decisions.md      # choice, reason, date
    design.md         # visual references and design rules
    handoff.md        # state, checks, next action
  .claude/
    skills/
      feature-review/SKILL.md

Claude’s auto memory records learnings across sessions; it complements reviewed project instructions. Use /memory to inspect what is loaded. Your documents still need explicit reading when a task depends on them.

# Working agreement
Read docs/brief.md and docs/design.md before product changes.
Check package.json for the actual install, test and build commands.
Follow existing architecture and naming patterns.
For UI changes, verify small and large screens and keyboard use.
For behaviour changes, run relevant checks and report failures.
Record significant choices in docs/decisions.md.
Keep credentials out of source, prompts and logs.
Summarise changed behaviour, checks and remaining work.

Reference: Project instructions & auto memory ↗

When you repeat a useful prompt, save the method in a SKILL.md. Project skills live in .claude/skills/<name>/; personal skills live in ~/.claude/skills/. Start with one review skill and improve it after real use.

1. Create .claude/skills/feature-review/SKILL.md.
2. Paste this example and tailor the checks to your app.
3. Run /feature-review in a session. Confirm it reports evidence and file locations.

---
name: feature-review
description: Review a completed website or app feature before release.
disable-model-invocation: true
---
Review the current diff against the acceptance criteria.
Check error, empty, loading and success states where relevant.
Inspect accessibility and responsive behaviour for UI changes.
Run available relevant checks; report anything not run.
Return prioritised findings with file locations and evidence.
Do not publish or modify files during this review.

disable-model-invocation: true keeps this workflow manually invoked. Add supporting scripts or reference files only when needed. Skill instructions do not guarantee correct execution; review the results.

Reference: Skill locations, frontmatter & invocation ↗

Type /plugin to browse and manage plugins. Prefer a small, relevant set from trusted maintainers. For frontend work, look for design guidance and code intelligence for your language. Inspect the publisher, added tools and scope before installing.

References: Plugin management ↗ · Mods & version requirements ↗ · Settings hooks ↗

MCP gives Claude tools from external services. Add a connection when the work needs it: design files, issue tracking, a browser, or a development database. Built-in file and shell tools already cover many local tasks.

1. Choose the service’s official integration and read its current setup instructions.
2. Use its exact endpoint or launch command. The command below is a template, not a working service.
3. Open /mcp, authenticate if supported and test a read-only action.
4. Inspect requested permissions. Keep production data and write access limited to the actual task.

claude mcp add --transport http example https://mcp.example.com/mcp
claude mcp list

Never paste access tokens into a shared configuration or a screenshot. Treat third-party tool output and downloaded instructions as untrusted input.

Reference: MCP setup, scopes & authentication ↗

Give each task a visible finish line. Work in a branch, build a small vertical slice, and inspect what changed before expanding it. A screenshot or a passing build alone cannot prove the whole feature works.

Read CLAUDE.md, docs/brief.md and the existing implementation.
Build [feature] for [user] so they can [outcome].
Acceptance criteria:
- [observable success behaviour]
- [important error or empty state]
- [keyboard and small-screen requirement]
First identify the relevant files and propose a short plan.
After implementation, run relevant checks and test the user flow.
Report changed behaviour, evidence and anything still unverified.

For websites: check mobile navigation, long text, focus states and actual form submissions. For apps: also test permissions, validation, data persistence and failure recovery. Use preview or browser tools available in your environment.

Reference: Claude Code best practices ↗. The loop and prompt above are suggested working conventions.

Before ending a session, ask Claude to update a short handoff document. Read and correct it, especially claims about completed checks. Commit intentional project knowledge with the code so it stays reviewable.

Update docs/handoff.md with:
1. The current objective and branch.
2. What changed and why.
3. Checks actually run, with their results.
4. Known issues and unverified assumptions.
5. The next concrete action and files to read.
Keep it concise. Do not include secrets or personal data.
Propose durable decisions for docs/decisions.md separately.

At the next session, ask Claude to read the handoff and verify it against the current repository. Archive stale notes, remove superseded rules, and keep experimental ideas separate from accepted decisions.

Success check A fresh session can explain the next step without your retelling the whole project.

Use a preview deployment for review, run the app’s relevant checks, and verify the published URL after release. Keep credentials in your hosting platform’s secret storage. For Cloudflare work, consult current platform docs and separate frontend assets from server secrets.

/*
  X-Robots-Tag: noindex, nofollow, noarchive
  Referrer-Policy: strict-origin-when-cross-origin
  X-Content-Type-Options: nosniff

References: Pages response headers ↗ · Direct Upload ↗ · How noindex works ↗

WATCH & LEARN

Start with the people building it.

These official videos are useful for working methods. They predate this guide; use the linked docs for current commands, model names and features.

Prefer a structured lesson? Try the official Claude Code in Action course ↗.