$ man how-to/top-10-claude-code-tips
CLI Toolsintermediate
Top 10 Claude Code Tips for Power Users
Practical tips from daily use - not the obvious ones
PATTERN
1. Use Plan Mode for Anything Non-Trivial
Before Claude Code writes a single line of code, enter plan mode. Type /plan or ask Claude to plan the approach. It explores the codebase, identifies affected files, considers edge cases, and presents an implementation strategy for your approval.
Without plan mode: Claude starts coding immediately, realizes halfway through that the approach does not work, backtracks, and produces messy results.
With plan mode: Claude spends 30 seconds mapping the problem, you approve or adjust the approach, then it executes cleanly. The 30-second investment saves 10 minutes of debugging.
The rule: any task touching 3 or more files gets plan mode. No exceptions.
PATTERN
2. Write Skills for Repeating Workflows
If you do something more than twice, it should be a skill. A skill is a Markdown file in .claude/skills/ that defines a step-by-step workflow Claude follows when triggered.
Examples of skills worth building: /deploy (build, test, commit, push, verify), /morning (read handoffs, check git status, surface priorities), /draft-email (gather context, write email, push to drafts folder). Each skill replaces 5-10 manual instructions with a single command.
Skills compound. Every time the skill runs and you notice an edge case, fix the skill. After 20 uses, it handles scenarios you never planned for. After 50 uses, it runs flawlessly without intervention.
The skill directory structure: .claude/skills/skill-name/SKILL.md. The SKILL.md file contains the trigger description, the step-by-step instructions, and any context the skill needs.
PATTERN
3. Run Parallel Sessions in Separate Terminals
Open three terminal tabs. Run Claude Code in each. Give each session a different task. You just tripled your throughput.
Tab 1: Refactoring the API layer. Tab 2: Writing tests for the new feature. Tab 3: Updating documentation. All three run concurrently on the same codebase.
Watch for conflicts: if two sessions edit the same file, the second write wins. Scope your parallel sessions to different directories or modules. API work in one session, UI work in another, docs in a third.
For maximum safety, use git worktrees. Each session gets its own branch and working directory. No conflicts possible. Merge when done.
PATTERN
4. Use Subagents for Research, Not Just Coding
Subagents are not just for parallel code changes. They are research assistants. When Claude Code needs to understand a complex module before making changes, spawn an Explore subagent.
"Before we refactor, I want to understand the auth module. Spawn an explore agent to map all authentication flows, find every place tokens are validated, and identify any hardcoded secrets."
The subagent digs through the code, returns a structured summary, and the main session makes decisions with full context. This keeps the main context window clean - the research happens in the subagent's context, and only the summary comes back.
PATTERN
5. Set Up a Morning Routine Skill
The first five minutes of a coding session set the tone. Instead of manually checking status, build a /morning skill that does it automatically.
A good morning skill: reads the context handoff from yesterday, runs git status, checks for unmerged PRs, surfaces the top three priority tasks, and prints a clean summary. You open Claude Code, type /morning, and get a full situational brief.
This one skill saves 10 minutes every morning and ensures you never start a session without context. Over a month, that is 3+ hours saved on just status checking.
PRO TIP
6. Use /compact Before Context Gets Long
Claude Code conversations consume context window space. After 20-30 turns, the context fills up and performance degrades. The /compact command summarizes the conversation so far and frees up space.
The trick: use /compact proactively, not reactively. After completing a major chunk of work, compact before starting the next chunk. This gives Claude fresh context space for the new task while preserving a summary of what was already done.
Do not wait until Claude starts forgetting things or repeating itself. That means the context is already saturated. Compact early, compact often.
PATTERN
7. Write Context Handoffs at Session End
Never close a Claude Code session without writing a handoff. The handoff captures what was done, what is the current state, and what should happen next. The next session reads it and starts with full context.
Automate this with a skill or a hook. A Stop hook can prompt Claude to write a handoff before exiting. A /handoff skill can generate a structured handoff document on demand.
The handoff is the bridge between sessions. Without it, every session starts from scratch. With it, sessions build on each other. After a week of handoffs, Claude knows your project as well as you do.
PATTERN
8. Use Hooks for Safety, Not Just Convenience
The highest-value hooks are not formatters or notifiers. They are safety gates.
A PreToolUse hook that blocks git push --force has prevented data loss more than once. A hook that scans edited files for API keys before they are written catches secrets before they hit disk. A hook that prevents edits to migration files avoids breaking the database.
Safety hooks are set-and-forget insurance. You configure them once and they protect you forever. The 30 minutes to set them up saves hours of crisis response.
ANTI-PATTERN
9. Keep CLAUDE.md Under 200 Lines
A 500-line CLAUDE.md is worse than a 100-line CLAUDE.md. It consumes context space that Claude needs for actual code. It buries important instructions under walls of detail. The model's adherence to instructions drops as the file grows.
The fix: keep CLAUDE.md lean. Use @imports for detailed docs. Point to files instead of copying content. Cut any instruction that Claude already follows by default.
Every line in CLAUDE.md should earn its place. If Claude would do the right thing without the instruction, delete the instruction. Only include rules that override defaults or enforce project-specific conventions.
PRO TIP
10. Build a Lessons File for Self-Improvement
Every time Claude Code makes a mistake and you correct it, add the lesson to a file. I use tasks/lessons.md. The CLAUDE.md tells Claude to read this file at session start.
Format: date, context, rule. "2026-03-01: MCP create_note double-escapes newlines. Rule: Never use MCP create_note for multi-line content. Use the REST API directly."
Over time, this file becomes a custom knowledge base of project-specific gotchas. Claude reads it, avoids the same mistakes, and your error rate drops to near zero. The lessons file is the fastest path to a Claude Code instance that feels like it has months of experience on your project.
The meta-lesson: AI agents do not learn between sessions unless you build the mechanism. The lessons file is that mechanism.
knowledge guide
related guides