The Claude Code Setup Guide

Upgrade Claude Code without guessing what to install

A practical Life of Arjav guide for developers, founders, operators, and AI builders who want a cleaner Claude Code setup.

Brand: Life of Arjav
Instagram: @lifeofarjav
Comment keyword: SETUP
Use case: Claude Code plugin setup, Hooks, Skills, MCP servers, Subagents, Slash Commands
Updated: July 2026

---

Quick summary

Most people use Claude Code in the most basic way:

1. Open a project.
2. Ask Claude to make changes.
3. Hope it understands the codebase.
4. Manually search for tools, MCP servers, hooks, skills, and commands.
5. Install random things because they sound useful.

That is backwards.

The smarter approach is:

1. Let Claude inspect the actual project.
2. Detect the stack, structure, dependencies, and recurring workflows.
3. Get tailored recommendations for the setup.
4. Add only the automations that create real value.
5. Keep the system simple enough to trust.

That is what the Claude Code Setup plugin is designed to help with.

---

Official links

Use these links to verify the plugin and understand the surrounding Claude Code features.

---

The exact install command

Run this inside Claude Code:

/plugin install claude-code-setup@claude-plugins-official

If the marketplace is missing, add it first:

/plugin marketplace add anthropics/claude-plugins-official

If Claude Code says the plugin is not found, refresh the marketplace:

/plugin marketplace update claude-plugins-official

Then retry the install command:

/plugin install claude-code-setup@claude-plugins-official

---

What this plugin does

The Claude Code Setup plugin analyzes a codebase and recommends Claude Code automations that fit the project.

It can recommend across five categories:

1. Hooks
2. Skills
3. MCP servers
4. Subagents
5. Slash commands

It is designed to be read-only.

That matters.

The plugin should help you decide what to add, not silently rewrite your project.

---

What this plugin is not

This is where most people get sloppy.

The plugin is not:

• a magic productivity upgrade
• a guarantee that every recommendation is correct
• a replacement for engineering judgment
• a tool you should blindly trust
• a reason to install every MCP server it mentions
• a reason to skip security review
• a system that automatically improves your codebase by itself

It is a recommendation layer.

You still decide what to install, what to trust, what to configure, and what to remove.

---

The core idea

Stop using Claude Code vanilla

Claude Code is already useful out of the box.

But the default setup is generic.

Your project is not generic.

A React app, Python API, Laravel app, Rails app, data pipeline, internal tool, AI agent, and browser automation project should not all use the same Claude Code setup.

The plugin helps answer the question:

Given this project, what Claude Code customizations are actually worth adding?

That is the whole game.

Not more tools.

Better-fitting tools.

---

The five categories explained

1. Hooks

What hooks are

Hooks are automations that run when specific Claude Code events happen.

Think of them as guardrails or automatic triggers.

Instead of relying on Claude to remember a rule, a hook fires at the right point in the workflow.

Useful examples

• run formatting before commit
• run tests after edits
• block edits to sensitive files
• notify you when a long task finishes
• check lint after code changes
• stop Claude from ending a task until tests pass
• log certain actions for review

When to use hooks

Use hooks when something must happen consistently.

Good hook candidates:

• "Always run tests after editing backend code."
• "Never edit .env without approval."
• "Format code before commit."
• "Notify me when a long background task finishes."
• "Run type checking after TypeScript changes."

When not to use hooks

Do not use hooks for everything.

Bad hook candidates:

• vague preferences
• tasks that require judgment every time
• heavy scripts that slow down every interaction
• automations you have not tested manually
• actions that modify important files without approval

Example hook ideas

Pre-commit Hook:
Run formatting and lint checks before a commit.

Post-edit Hook:
Run tests when files in /src are changed.

Sensitive-file Hook:
Block or require approval before edits to .env, secrets, payment code, auth config, or production deployment files.

Notification Hook:
Send a desktop notification when Claude finishes a long task.

Practical rule

If the action should happen every time a condition is met, use a hook.

If the action should happen only when you ask, use a slash command.

If the action is a reusable body of knowledge or process, use a skill.

---

2. Skills

What skills are

Skills give Claude reusable knowledge, instructions, workflows, scripts, and reference material.

A skill usually lives in a folder and includes a SKILL.md file.

Think of a skill as a repeatable capability.

Useful examples

• code review skill
• test writing skill
• deployment checklist skill
• frontend design skill
• API documentation skill
• database migration skill
• customer research skill
• proposal writing skill
• security review skill

When to use skills

Use skills when Claude needs a repeatable method.

Good skill candidates:

• "Review code using our internal checklist."
• "Write tests in our preferred style."
• "Generate documentation from this project pattern."
• "Follow our frontend quality standard."
• "Use this exact deployment process."

What belongs inside a skill

A good skill can include:

• purpose
• when to use it
• step-by-step workflow
• quality checklist
• examples
• templates
• scripts
• rules
• failure cases
• expected output format

Example skill structure

.claude/
  skills/
    code-reviewer/
      SKILL.md
      checklist.md
      examples.md
      scripts/
        run_checks.sh

Example SKILL.md

# Code Reviewer Skill

## Purpose

Use this skill when reviewing code changes before a pull request.

## Process

1. Identify files changed.
2. Summarize the intent of the change.
3. Check correctness.
4. Check edge cases.
5. Check security implications.
6. Check test coverage.
7. Suggest fixes ranked by severity.

## Output format

- Summary
- Critical issues
- Suggested improvements
- Tests to add
- Final recommendation

Practical rule

If you keep giving Claude the same detailed instructions, turn them into a skill.

---

3. MCP servers

What MCP means

MCP stands for Model Context Protocol.

It lets Claude connect to external tools, databases, APIs, and systems through a standard interface.

In simple terms:

MCP gives Claude controlled access to tools outside the chat window.

Useful examples

• GitHub
• Postgres
• browser tools
• documentation tools
• Slack
• Google Drive
• Notion
• project management tools
• internal databases

When to use MCP

Use MCP when Claude needs to read from or act inside another system.

Good MCP candidates:

• "Read issues from GitHub."
• "Query this database."
• "Look up current documentation."
• "Inspect a browser page."
• "Search internal docs."
• "Pull task status from a project tracker."

When not to use MCP

Do not add MCP servers casually.

Every new connection creates more surface area.

Avoid MCP when:

• the task can be solved with local files
• the server requires unnecessary permissions
• you do not understand what the server can access
• you have not reviewed the source
• the data is sensitive and controls are unclear

MCP safety checklist

Before adding an MCP server, ask:

• What can it read?
• What can it write?
• Does it need authentication?
• Where are credentials stored?
• Can it access sensitive data?
• Can it trigger irreversible actions?
• Is human approval required for risky writes?
• Is the MCP server actively maintained?
• Do I trust the source?

Practical rule

Use MCP when Claude needs external context or external actions.

Do not use MCP just because it sounds powerful.

---

4. Subagents

What subagents are

Subagents are specialized agents that can work in their own context.

Instead of making one Claude session do everything, you can delegate a focused task to a subagent.

Useful examples

• code reviewer
• security reviewer
• performance reviewer
• test writer
• documentation writer
• refactor planner
• database migration reviewer
• accessibility reviewer
• frontend quality reviewer

When to use subagents

Use subagents when a task benefits from isolation or specialization.

Good subagent candidates:

• broad code review
• security analysis
• performance analysis
• test generation
• researching a large codebase
• comparing implementation options
• reviewing architecture trade-offs

Why subagents help

They reduce clutter in the main conversation.

They can focus on one job.

They can return a clean summary instead of dumping every intermediate thought into the main thread.

Example subagent definition

---
name: security-reviewer
description: Reviews code for security issues, auth risks, input validation gaps, and sensitive data exposure.
tools:
  - Read
  - Grep
  - Glob
---

Review the changed files for security risks.

Focus on:
- authentication
- authorization
- secrets
- injection risks
- unsafe dependencies
- sensitive logs
- access control
- production data exposure

Return:
1. Critical risks
2. Medium risks
3. Low risks
4. Recommended fixes
5. Files to inspect manually

Practical rule

Use subagents when the job is important enough to deserve a specialist.

---

5. Slash commands

What slash commands are

Slash commands are reusable commands you can type inside Claude Code.

They are useful for repeated workflows.

Useful examples

• /review
• /plan
• /docs
• /test
• /ship
• /pr-summary
• /debug
• /handoff

When to use slash commands

Use slash commands when you want to manually trigger a repeatable workflow.

Good slash command candidates:

• "Review the current diff."
• "Plan the implementation."
• "Generate docs for this feature."
• "Write tests for this module."
• "Create a PR summary."
• "Prepare a deployment checklist."

Example command file

.claude/
  commands/
    review.md

Review the current code changes.

Steps:
1. Inspect the diff.
2. Explain what changed.
3. Identify correctness issues.
4. Identify missing tests.
5. Identify security risks.
6. Suggest improvements.
7. Give a final merge recommendation.

Return the result in a concise checklist.

Practical rule

Use a slash command when you want a reusable button for a workflow.

---

The clean setup decision tree

Use this when deciding what to add.

Add a CLAUDE.md when

You want Claude to always know a rule.

Examples:

• use pnpm, not npm
• run tests before committing
• follow this project structure
• never edit generated files
• follow this style guide

Add a Skill when

Claude needs reusable knowledge or a repeatable method.

Examples:

• code review checklist
• frontend design process
• API documentation rules
• deployment process
• domain-specific rules

Add a Hook when

An action must happen automatically at a lifecycle event.

Examples:

• run tests after edits
• block sensitive file edits
• format before commit
• notify on completion

Add an MCP server when

Claude needs to connect to an external tool or data source.

Examples:

• GitHub
• Postgres
• browser automation
• docs lookup
• internal knowledge base

Add a Subagent when

You need specialized analysis with isolated context.

Examples:

• security reviewer
• test writer
• performance reviewer
• refactor planner

Add a Slash Command when

You want a manual shortcut for a repeated workflow.

Examples:

• /review
• /plan
• /docs
• /test
• /ship

---

How to use the plugin

Step 1: Open Claude Code in your project

Navigate to your project folder.

cd path/to/your/project
claude

Step 2: Install the plugin

Inside Claude Code:

/plugin install claude-code-setup@claude-plugins-official

Step 3: Ask for broad recommendations

Use this prompt:

Recommend the highest-value Claude Code automations for this project.

Analyze the codebase first.

Focus on:
1. Hooks
2. Skills
3. MCP servers
4. Subagents
5. Slash commands

For each recommendation, explain:
- why it fits this project
- what problem it solves
- what files or signals made you recommend it
- how risky it is
- how I should test it before relying on it

Do not modify any files yet.

Step 4: Ask for category-specific recommendations

After the broad scan, ask deeper questions.

Hooks prompt

What Hooks should I add to this workflow?

Prioritize only hooks that prevent real mistakes or save repeated effort.

For each hook, include:
- event trigger
- purpose
- example implementation
- risk level
- how to test it
- whether it should block, warn, or notify

Do not modify files yet.

Skills prompt

What Skills would be useful for this project?

Recommend reusable Skills that would improve code quality, testing, documentation, or project-specific workflows.

For each Skill, include:
- skill name
- when Claude should use it
- what should go inside SKILL.md
- supporting files to include
- example invocation
- how to evaluate whether it works

Do not create the Skill yet.

MCP prompt

Which MCP servers fit this codebase?

Only recommend MCP servers that map to actual needs in this project.

For each MCP server, explain:
- what external system it connects to
- why this project needs it
- read permissions
- write permissions
- security risks
- setup steps
- what I should verify before using it

Subagents prompt

Which subagents would save me the most time in this project?

Recommend specialized subagents only where isolated context or expertise would clearly help.

For each subagent, include:
- name
- role
- tools it should be allowed to use
- tools it should not use
- when to call it
- expected output
- example task

Slash command prompt

What slash commands should I create for repeated workflows in this repo?

Prioritize commands I would actually use weekly.

For each command, include:
- command name
- purpose
- command body
- expected output format
- example use case

Step 5: Ask it to rank everything

Do not install every suggestion.

Ask Claude to prioritize.

Rank all recommendations from highest to lowest impact.

Create three groups:

1. Install or create now
2. Consider later
3. Skip for now

For each item, explain:
- impact
- effort
- risk
- maintenance burden
- why it belongs in that group

Step 6: Implement one thing at a time

The beginner mistake is adding too much at once.

Add one improvement.

Test it.

Commit it.

Then add the next.

---

Beginner setup checklist

Use this if you are starting from a plain Claude Code setup.

Basic project context

• Add a useful CLAUDE.md
• Explain project purpose
• Explain install commands
• Explain test commands
• Explain lint commands
• Explain conventions
• Explain files Claude should avoid editing
• Explain approval boundaries

Recommended first customizations

• One /plan slash command
• One /review slash command
• One code review Skill
• One test writing Skill
• One hook for formatting or tests
• One safety rule for sensitive files
• One subagent only if the project is large enough

Avoid at the start

• installing many MCP servers
• adding write access to external systems too early
• creating 10 subagents at once
• making hooks block too aggressively
• relying on tools you have not tested manually
• assuming the plugin knows your priorities better than you

---

Starter CLAUDE.md template

Copy this into your project and customize it.

# Project Instructions

## Project purpose

This project is:

[Explain what the app or codebase does in 2 to 4 sentences.]

## Tech stack

- Language:
- Framework:
- Package manager:
- Database:
- Testing:
- Deployment:

## Commands

Install dependencies:

[command]

Run development server:

[command]

Run tests:

[command]

Run lint:

[command]

Run typecheck:

[command]

## Coding rules

- Keep changes focused and minimal.
- Prefer readable code over clever code.
- Do not change public APIs without explaining why.
- Do not add new dependencies without asking first.
- Add or update tests when changing logic.
- Explain trade-offs before major architecture changes.

## Files to avoid editing without approval

- `.env`
- production config
- migration files
- payment code
- authentication config
- generated files
- lock files unless dependency changes are intended

## Definition of done

A task is done only when:

1. The change is implemented.
2. Tests relevant to the change pass.
3. Lint and typecheck pass, if available.
4. Risks are documented.
5. A concise summary is provided.

---

Starter slash commands

/plan

Create:

.claude/commands/plan.md

Content:

Create an implementation plan before editing files.

Include:
1. Goal
2. Relevant files to inspect
3. Proposed approach
4. Risks
5. Test plan
6. Questions that must be answered first

Do not modify files until I approve the plan.

/review

Create:

.claude/commands/review.md

Content:

Review the current changes.

Check:
1. Correctness
2. Edge cases
3. Security
4. Performance
5. Test coverage
6. Simplicity
7. Maintainability

Return:
- Summary
- Critical issues
- Suggested improvements
- Tests to add
- Final recommendation

/docs

Create:

.claude/commands/docs.md

Content:

Generate or update documentation for the current feature.

Include:
1. What the feature does
2. How it works
3. How to configure it
4. How to test it
5. Known limitations
6. Example usage

Keep the docs concise and practical.

/ship

Create:

.claude/commands/ship.md

Content:

Prepare this change for shipping.

Check:
1. Tests
2. Lint
3. Types
4. Docs
5. Migration impact
6. Environment variables
7. Security risks
8. Rollback plan

Return a final ship checklist.

---

Practical Hook ideas

Hook 1: Run tests after editing core files

Use when:

• test command is reliable
• test suite is not too slow
• you want fast failure feedback

Risk:

• can slow down the workflow
• can become annoying if tests are flaky

Better version:

Run targeted tests first.

Hook 2: Block edits to sensitive files

Use when:

• the repo contains secrets
• auth config is fragile
• production config should not change casually

Sensitive file examples:

.env
.env.production
secrets.*
auth.config.*
stripe.*
payments.*
database migrations

Hook 3: Format on commit

Use when:

• the project has Prettier, Ruff, Black, gofmt, or similar tooling
• formatting disagreements waste time

Hook 4: Notify when complete

Use when:

• Claude Code runs long tasks
• you step away during code reviews or refactors

Hook 5: Run lint after edits

Use when:

• lint is fast
• lint failures are common
• style issues create noisy PRs

---

Practical Skill ideas

Skill 1: Code Review Skill

Use for:

• pull request reviews
• risky refactors
• pre-merge checks

Skill should include:

• review checklist
• severity levels
• output format
• common project-specific risks
• examples of good reviews

Skill 2: Test Writer Skill

Use for:

• writing unit tests
• adding regression tests
• finding missing edge cases

Skill should include:

• test framework
• naming conventions
• test data style
• mocking rules
• what not to test

Skill 3: Documentation Skill

Use for:

• README updates
• feature docs
• API docs
• setup guides

Skill should include:

• documentation structure
• tone
• examples
• formatting rules
• minimum sections

Skill 4: Frontend Quality Skill

Use for:

• UI work
• component cleanup
• design system consistency

Skill should include:

• layout rules
• accessibility checks
• responsive behavior
• component patterns
• styling conventions

Skill 5: Release Checklist Skill

Use for:

• pre-release reviews
• deployment readiness
• launch preparation

Skill should include:

• tests
• migrations
• environment variables
• rollback
• monitoring
• user impact

---

Practical Subagent ideas

Security reviewer

Use for:

• authentication code
• permission logic
• payment code
• user data
• external integrations

Allowed tools:

• read files
• search code
• inspect dependencies

Avoid:

• write access by default

Test writer

Use for:

• generating test cases
• identifying missing coverage
• regression scenarios

Allowed tools:

• read files
• write test files, with approval
• run tests

Performance reviewer

Use for:

• slow endpoints
• database query review
• rendering bottlenecks
• background job performance

Documentation writer

Use for:

• feature explanations
• onboarding docs
• README updates
• API examples

Refactor planner

Use for:

• messy modules
• large files
• dependency cleanup
• architecture simplification

---

Practical MCP examples

GitHub MCP

Use for:

• reading issues
• reviewing pull requests
• linking changes to tasks
• searching repository history

Be careful with:

• write permissions
• automatic PR comments
• branch modification

Postgres MCP

Use for:

• querying development databases
• inspecting schema
• understanding data patterns

Be careful with:

• production access
• write queries
• sensitive customer data
• unbounded queries

Browser tools

Use for:

• UI testing
• browser interaction
• form flows
• debugging rendered pages

Be careful with:

• logged-in sessions
• external sites
• private data
• actions that submit forms

Documentation MCP

Use for:

• current API docs
• framework docs
• library usage
• version-specific references

This is often one of the safest and highest-value MCP categories.

---

The correct workflow after installing the plugin

Bad workflow

Install plugin.
Ask for recommendations.
Install everything.
Hope it works.

Better workflow

Install plugin.
Ask for broad recommendations.
Ask why each recommendation fits.
Rank by impact, effort and risk.
Pick one.
Implement.
Test.
Commit.
Repeat.

Best workflow

Install plugin.
Ask for broad recommendations.
Map recommendations to actual recurring pain.
Create one small change.
Test it with real work.
Measure if it saved time or reduced mistakes.
Document the pattern.
Share it with the team.

---

Example: recommended setup for a Next.js app

Imagine the plugin detects:

Framework: Next.js
Language: TypeScript
Package manager: pnpm
Testing: Playwright
Database: Postgres
Auth: NextAuth

A good setup might include:

CLAUDE.md

Rules:

• use pnpm
• run typecheck before final answer
• never edit auth config without approval
• follow existing component patterns
• use server components where appropriate
• do not add packages without asking

Hook

Run:

pnpm typecheck

after TypeScript-heavy edits.

Skill

Frontend review Skill:

• responsiveness
• accessibility
• component reuse
• loading states
• empty states
• error states
• design consistency

Subagent

Security reviewer:

• inspect auth routes
• check permission boundaries
• look for exposed secrets
• review server actions

MCP

GitHub MCP:

• connect work to issues and PR context

Documentation MCP:

• retrieve current framework docs when needed

Slash commands

• /plan
• /review
• /test
• /pr-summary

This is a coherent setup.

Not because it has the most tools.

Because every tool maps to a real project need.

---

Example: recommended setup for a Python API

Imagine the plugin detects:

Language: Python
Framework: FastAPI
Database: Postgres
Testing: pytest
Formatter: Ruff

A good setup might include:

CLAUDE.md

Rules:

• use type hints
• keep endpoints thin
• put business logic in services
• use pytest
• run Ruff before final summary
• do not edit migrations without approval

Hook

Run:

ruff check .
pytest

after backend logic changes.

Skill

API review Skill:

• endpoint behavior
• input validation
• error handling
• database query safety
• auth checks
• test coverage

Subagent

Test writer:

• write unit tests
• add regression tests
• test invalid input
• test permissions

MCP

Postgres MCP for development database inspection, if permissions are safe.

Slash commands

• /api-review
• /write-tests
• /debug-endpoint
• /docs

---

Example: recommended setup for an AI agent project

Imagine the plugin detects:

LLM calls
Tool use
RAG pipeline
Evaluation files
Vector database
Background tasks

A good setup might include:

CLAUDE.md

Rules:

• separate deterministic code from model prompts
• use structured outputs
• log tool calls
• add eval cases when changing prompts
• never increase tool permissions without approval
• explain failure modes

Hook

Run evaluation tests when prompt files or retrieval code change.

Skill

AI evaluation Skill:

• create test cases
• check groundedness
• check refusal behavior
• inspect hallucination risk
• compare old and new prompt behavior

Subagent

Failure analyst:

• inspect failed evals
• group failure patterns
• suggest targeted fixes

MCP

Documentation MCP and GitHub MCP.

Use database MCP only if clearly needed.

Slash commands

• /eval
• /prompt-review
• /agent-debug
• /failure-analysis

---

Quality checklist for any recommendation

Before implementing a recommendation, ask:

Fit

• Does this solve a recurring problem?
• Does this match the project stack?
• Would I use this weekly?
• Is this better than a simple note in CLAUDE.md?

Cost

• Does it slow down the workflow?
• Does it add maintenance burden?
• Does it require credentials?
• Does it make onboarding harder?

Risk

• Can it read sensitive data?
• Can it write or delete anything?
• Can it run shell commands?
• Can it trigger external actions?
• Can it break CI or commits?

Evaluation

• How will I test it?
• What does success look like?
• What failure would make me remove it?
• Can I disable it quickly?

---

The setup scorecard

Use this to audit your Claude Code setup.

Score each item from 0 to 2.

0 = missing
1 = partially implemented
2 = strong

Interpretation

0 to 6:
Vanilla setup. Add basic context and one workflow.

7 to 14:
Useful setup. Improve safety and repeatability.

15 to 22:
Strong setup. Keep it simple and document it.

23+:
Audit for overengineering. More tools may not mean better workflow.

---

Troubleshooting

/plugin does not work

Update Claude Code.

Then try again.

Also check the official plugin docs.

Marketplace not found

Run:

/plugin marketplace add anthropics/claude-plugins-official

Plugin not found

Refresh marketplace:

/plugin marketplace update claude-plugins-official

Then reinstall:

/plugin install claude-code-setup@claude-plugins-official

Plugin installed but not helping

Try better prompts.

Bad:

Improve my setup.

Better:

Analyze this repo and recommend the highest-value Claude Code automations across Hooks, Skills, MCP servers, Subagents and Slash Commands. Rank them by impact, effort and risk. Do not modify files.

Recommendations feel generic

Ask:

Which files, dependencies or project patterns caused each recommendation? If a recommendation is generic and not clearly supported by this repo, mark it as low confidence.

Too many recommendations

Ask:

Choose only the top 3 recommendations I should implement this week. Everything else should go into later or skip.

Security concerns

Ask:

For every recommendation, explain:
1. what it can read
2. what it can write
3. what permissions it needs
4. how to test it safely
5. how to disable it

---

Your first 30-minute setup sprint

Use this if you want the fastest useful result.

Minute 0 to 5

Install the plugin.

/plugin install claude-code-setup@claude-plugins-official

Minute 5 to 10

Ask:

Recommend the highest-value Claude Code automations for this project. Rank by impact, effort and risk. Do not modify files.

Minute 10 to 15

Ask:

Which one recommendation should I implement first if I want the fastest improvement with the lowest risk?

Minute 15 to 25

Implement only that one thing.

Examples:

• /review command
• basic CLAUDE.md update
• code review Skill
• test Hook
• security reviewer subagent

Minute 25 to 30

Test it on a real task.

Then commit it.

git add .
git commit -m "Add Claude Code setup improvement"

---

Team rollout checklist

If you are adding this to a team repo, do not surprise people.

Before adding

• Explain why the setup is needed
• Document what the plugin recommended
• Review permissions
• Avoid risky write access
• Start with read-only or manual workflows
• Add one or two improvements first
• Let the team test

In the pull request

Include:

• why this setup exists
• what changed
• how to use it
• how to disable it
• security considerations
• examples
• next improvements

Team policy

Document:

• who can add MCP servers
• which files need approval
• which hooks are blocking
• how to update skills
• how to remove broken plugins
• how to report bad recommendations

---

What to save from this guide

If you remember only five things, remember these:

1. Claude Code vanilla is generic. Your setup should match your project.
2. The Claude Code Setup plugin is a recommendation layer, not a replacement for judgment.
3. Hooks automate events. Skills store reusable expertise. MCP connects tools. Subagents specialize work. Slash commands create repeatable manual workflows.
4. Start with one high-value improvement, test it, then add more.
5. The best setup is the smallest setup that reliably saves time and reduces mistakes.

---

Copy-paste prompt pack

Broad setup analysis

Recommend the highest-value Claude Code automations for this project.

Analyze the codebase first.

Focus on:
1. Hooks
2. Skills
3. MCP servers
4. Subagents
5. Slash commands

For each recommendation, explain:
- why it fits this project
- what problem it solves
- what files or signals made you recommend it
- how risky it is
- how I should test it before relying on it

Rank everything by impact, effort and risk.

Do not modify files yet.

Read-only safety prompt

Before recommending anything, confirm that this analysis is read-only.

Do not create files.
Do not edit files.
Do not install anything.
Do not change configuration.

Only inspect the project and return recommendations.

Recommendation ranking prompt

Rank the recommendations into three groups:

1. Install or create now
2. Consider later
3. Skip for now

For every item, include:
- impact
- effort
- risk
- maintenance burden
- reason for the ranking

Evidence prompt

For each recommendation, show the evidence from this repo.

Include:
- files inspected
- dependencies detected
- project structure signals
- workflow patterns
- confidence level

If the recommendation is generic, label it low confidence.

Implementation prompt

Implement only the first approved recommendation.

Before editing:
1. explain what files will change
2. explain why
3. explain the test plan
4. wait for approval

After editing:
1. summarize the changes
2. show how to use it
3. explain how to disable it
4. list remaining risks

Audit prompt

Audit my Claude Code setup.

Review:
- CLAUDE.md
- Skills
- Hooks
- MCP servers
- Subagents
- Slash commands

Identify:
1. what is useful
2. what is duplicated
3. what is risky
4. what is missing
5. what should be removed
6. what should be added next

---

Final word

The point is not to install every shiny Claude Code extension.

The point is to build an environment where Claude understands your project, follows your rules, connects to the right tools, and repeats the workflows that actually matter.

That is the difference between using Claude Code as a chatbot and using it like a real development system.

---

Life of Arjav

Life of Arjav publishes practical AI, Claude Code, automation, tech and growth systems.

Follow @lifeofarjav for:

• Claude Code workflows
• AI automation systems
• practical developer tools
• creator and founder operating systems
• useful AI implementation guides

Comment SETUP on the Instagram post to get this guide.