How I Set Up Claude Code as My Daily Development Companion

I use Claude Code every day — hundreds of messages across Rust, Python, TypeScript, and C# projects. After months of tweaking, the configuration has become something I rely on more than any IDE extension. This post is a tour of what I've landed on and why.

The Big Picture

Everything lives in ~/.claude/:

~/.claude/
├── CLAUDE.md              # Global instructions (loaded every session)
├── settings.json          # Permissions, hooks, plugins, status line
├── rules/                 # 10 rule files (coding style, git, security, etc.)
├── projects/              # Per-project persistent memory
│   └── <project>/memory/
│       ├── MEMORY.md      # Index of all memories
│       ├── user-profile.md
│       └── ...
├── skills/                # Custom skills (deep research, etc.)
│   ├── SKILL.md
│   └── templates/
├── statusline-command.sh  # Custom status bar script
├── update-pricing.sh      # Auto-fetch Anthropic pricing
└── cache/
    └── model-pricing.env  # Cached pricing data

CLAUDE.md — The System Prompt

This file gets loaded into every conversation. Mine tells Claude:

• Who I am: full-stack dev, Rust/C#/.NET/Python/TypeScript
• How I work: macOS host + Windows VM (Parallels) for .NET Framework 4.8
• Behavioral rules: explore before changing, ask before assuming, match existing code style, never force-push main
• Pointers to rules: each language/domain has its own rule file in rules/

I keep CLAUDE.md as an index pointing to detailed rules, not a wall of text. Easier to maintain and less likely to get ignored.

Rules — Codified Standards

10 rule files in ~/.claude/rules/:

These are global — they apply across all projects. Each project can also have its own CLAUDE.md with local overrides.

The payoff: Claude runs cargo clippy before Rust commits, uses uv instead of pip for Python, formats API errors as RFC 9457 — without me saying a word. Once you write the rule, you stop repeating yourself.

Plugins — Extending Capabilities

I run 12 plugins. Some are official Anthropic plugins, some are community-built.

Official plugins (from claude-code/plugins↗︎ and claude-plugins-official↗︎):

• commit-commands↗︎ — Git commit tooling (/commit, /commit-push-pr)
• feature-dev↗︎ — Guided feature development with architecture focus
• code-review↗︎ — PR review with confidence-based filtering
• code-simplifier↗︎ — Post-implementation cleanup (/simplify)
• frontend-design↗︎ — UI design guidance for components and pages
• rust-analyzer-lsp↗︎ — Real-time Rust diagnostics without leaving the conversation

Third-party plugins:

• context7↗︎ — Pulls up-to-date library docs on the fly, because LLM training data goes stale fast
• vercel-plugin↗︎ — Deployment, observability, Next.js/AI SDK guidance
• interface-design↗︎ — Design system auditing and component patterns
• ecc↗︎ (Everything Claude Code) — Community plugin collection
• playwright — Browser automation for testing and verification
• github — GitHub integration for issues and PRs

Third-party plugins are installed via extraKnownMarketplaces in settings.json:

{
  "extraKnownMarketplaces": {
    "interface-design": {
      "source": {
        "source": "github",
        "repo": "Dammyjay93/interface-design"
      }
    }
  }
}

I also keep a plugin-to-task mapping in my agents.md rules so Claude reaches for the right tool:

Hooks — Automated Guardrails

Hooks run shell commands before or after Claude uses a tool.

PreToolUse — a nudge before any Bash call:

{
  "matcher": "Bash",
  "hooks": [{
    "type": "command",
    "command": "echo '⚠️  Confirm branch and remote before pushing'"
  }]
}

The matcher field filters by tool name. You can add an if field for argument-level filtering (e.g. only matching git push). I keep mine broad.

PostToolUse — after any file edit, a linter reminder based on file extension:

FILE=$(echo "$CLAUDE_TOOL_INPUT" | jq -r '.file_path // empty')
if [[ "$FILE" == *.rs ]]; then
    echo "Reminder: run cargo clippy"
elif [[ "$FILE" == *.cs ]]; then
    echo "Reminder: run dotnet build"
elif [[ "$FILE" == *.py ]]; then

Not blocking, just a tap on the shoulder. Catches more than you'd think.

Permissions — Defense in Depth

settings.json has allow/deny lists:

Allowed (auto-approved):

• File operations: Read, Edit, Write, Glob, Grep
• Shell: Bash (with deny-list exceptions)
• Web: WebFetch, WebSearch
• All Playwright and Context7 tools

Denied (hard-blocked):

• Destructive: rm -rf /, git push --force, git reset --hard, git clean -f
• Dangerous: dd, mkfs, shutdown, reboot, chmod 777
• Supply chain: npm publish, cargo publish, curl | bash
• Secrets: cat ~/.ssh/*, cat *id_rsa*

Even if Claude hallucinates a dangerous command, it can't execute it. Set this up before you need it.

Status Line — Real-Time Dashboard

My favorite customization. The terminal status line shows everything at a glance:

[Opus 4.6] misoto22-site | main | 45k 12k | 32% (57k/200k) | $0.45 | 12m30s | 3f +42 -8

From left to right:

• Model in use (cyan)
• Project directory (green)
• Git branch (magenta)
• Tokens in/out in thousands (yellow)
• Context usage — green (<50%), yellow (50-75%), red (>75%)
• Session cost in USD
• Session duration
• Git diff stats — files changed, lines added/removed

The cost is calculated from cached pricing that refreshes daily. A small script scrapes Anthropic's pricing page, extracts per-model rates, and caches them locally:

if [ ! -f "$PRICING_CACHE" ] || \
   [ "$(( $(date +%s) - $(stat -f %m "$PRICING_CACHE") ))" -gt 86400 ]; then
    bash "$PRICING_SCRIPT" &>/dev/null &  # auto-refresh when cache >24h old
fi

No API key needed. The color-coded context bar is what I actually watch most — it tells me when to /compact.

Memory System — Cross-Session Persistence

Memories survive across conversations. They're stored per-project at ~/.claude/projects/<project>/memory/ as markdown files with frontmatter:

---
name: user-profile
description: User identity, tech stack, and work preferences
type: user
---
 
Full-stack developer at Inovit (automotive wheels/tires/parts industry)...

I group them into four types:

• user — role, preferences, expertise level
• feedback — corrections and confirmed approaches ("use pnpm not npm")
• project — architecture decisions, ongoing initiatives
• reference — pointers to external systems (Linear boards, dashboards, etc.)

The MEMORY.md index keeps things scannable:

User
  - user-profile.md — User identity, tech stack, and work preferences
 
Feedback
  - feedback-patterns.md — Behavior corrections: pnpm not npm, verify API compliance
 
Project
  - project-decisions.md — Cross-project architecture decisions
 
Reference
  - toolchain.md — Local development environment version info

In practice, this means Claude already knows I'm a native Chinese speaker who prefers terse responses, that my Efision project uses 5-layer Clean Architecture with Service<R> generics, and that npm instead of pnpm is a mistake I've corrected before. These details compound — they change how Claude approaches every task.

Custom Skills — Repeatable Workflows

Skills are SKILL.md files in ~/.claude/skills/. Unlike plugins (which bundle tools, agents, and hooks), skills are pure markdown — step-by-step instructions Claude follows when you type /<skill-name>.

The one I use most is /ship. One command, working tree to merged PR:

1. Test — run the project's test suite; auto-fix up to 2 times if tests fail
2. Commit — stage everything, generate a conventional commit message from the diff
3. PR — create branch, push, open PR with summary and test plan
4. CI — poll gh pr checks every 30s (10min timeout); if CI fails, read logs, fix, push, retry up to twice
5. Merge — squash merge, delete branch, report the PR URL

The whole thing is defined in one markdown file. No code. Claude just follows the steps and stops to ask if something breaks. Replaces what used to be 5-10 manual commands.

I also have a Deep Research skill — 8 steps for turning a vague question into a structured report:

1. Question classification (concept comparison, decision support, trend analysis, etc.)
2. Question decomposition with timeliness assessment
3. Source collection with authority tiering (L1: official docs > L2: blogs > L3: media > L4: community)
4. Fact extraction as structured cards with confidence levels
5. Comparison framework construction
6. Gap identification and follow-up
7. Reasoning validation against collected facts
8. Report generation with all intermediate artifacts preserved

Triggers on "deep research", "对比分析", etc. Intermediate work goes to ~/Downloads/research/<topic>/ so nothing gets lost. Includes report templates for consistency.

I've also symlinked several design skills from the interface-design↗︎ plugin — /arrange, /audit, /critique, /distill, /normalize — so they're globally available across projects.

Project-Level Configuration

Each project gets its own CLAUDE.md. My personal website's, for example:

• Use pnpm (not npm)
• Blog posts are MDX files in content/blog/
• Imports use @/i18n/navigation (not next/link)
• API design follows global RFC 9457 rules
• Blog pages are statically generated; DB-backed pages use ISR

Global rules handle the universal stuff. Project rules handle local conventions. Claude switches context automatically when I cd into a different repo.

A Typical Session

1. Open Claude Code in a project. Status line shows model, branch, cost, context usage.
2. Global CLAUDE.md + project CLAUDE.md + rules + memories all load automatically.
3. I describe what I need. Claude reads the code first (that's in the rules), asks if something's unclear, then builds.
4. Hooks fire on every edit — linter reminders, push confirmations.
5. When the context bar turns yellow, I /compact at a natural breakpoint.
6. For bigger features, Plan mode or parallel subagents.
7. Anything worth carrying into the next session gets written to memory.

What I'd Set Up First

If I were starting from scratch:

1. Write rules, not prompts. ~/.claude/rules/ persists across sessions and projects. A prompt dies when the conversation ends.
2. Set up the deny list early. Block rm -rf, --force, publish before you ever need to.
3. Add a PostToolUse hook for linting. It's a one-liner that catches real issues.
4. Customize the status line. Once you can see cost and context usage in real time, you work differently.
5. Let memory build itself. Don't try to front-load it. Correct Claude when it gets something wrong, and those corrections stick.
6. Layer your config. Global for standards, project-level for conventions.

Most of this configuration came from real mistakes — a force-push that shouldn't have happened, an npm install in a pnpm project, a session that ran out of context mid-implementation. Each rule exists because I needed it to.