A lot of people first meet Claude Code as a coding assistant in the terminal. Useful, yes, but that description undersells it. Used properly, it is closer to an agentic development environment: it can gather context, form a plan, use tools, edit files, run commands and iterate on the result. That matters because the biggest productivity gains rarely come from faster autocomplete. They come from better context, more reliable execution and less repeated setup work.
This post focuses on the practical habits that make that happen. Some of these are specific to Claude Code, such as /init, CLAUDE.md, hooks, custom commands, Skills and MCP servers. Others belong more to the Claude API, such as stop_sequences, streaming, tool-calling blocks, prompt caching, citations and extended thinking. A third group sits above both: general agent design choices like workflows versus agents, context management and evaluation. Keeping those layers separate is useful because it helps teams choose the right mechanism for the job instead of throwing every feature at every problem.
If you have only used ad hoc prompts in a terminal session, start by giving Claude Code a durable operating context. The most important first step is /init, which generates a CLAUDE.md file for the repo or working directory. That file acts as the project’s standing instructions: how to build, how to test, where things live and what “good” looks like in this codebase. There are a few locations worth knowing: the project-level CLAUDE.md, the user-level ~/.claude/CLAUDE.md, and additional files pulled in with @path imports from within CLAUDE.md. The project file is for shared conventions, the user-level file is for instructions you want applied across every project on your machine, and imports let you layer in extra context — including personal or machine-specific files — without duplicating it.
You should also be deliberate about history and context management. Use @ mentions to point Claude Code at specific files or folders rather than hoping it infers the right context. Use /clear when you are changing task entirely and want a clean history. Use /compact when the session has become long and you want to preserve progress while compressing the conversation into a shorter summary. That is not glamorous, but it is one of the simplest ways to reduce drift and keep the model focused on the current job.
The best CLAUDE.md files read like a practical operating manual for the repo. Include build, test and lint commands. Add coding standards that matter in this repository, not generic style advice. Note architecture constraints, important directories, naming conventions and areas where changes are risky. If your team has strong repo-specific habits, for example around migrations, feature flags or data contracts, put them there.
Commit CLAUDE.md to source control. That is where the compounding value comes from. Instead of each engineer re-explaining the same conventions, the project carries that context with it. Keep personal shortcuts, local environment quirks and anything sensitive out of the shared file — pull them in with an @path import, or put them in your user-level ~/.claude/CLAUDE.md instead. A good rule is simple: if another engineer should benefit from it, it belongs in the shared file. If it is about your workstation, preferences or private credentials, it does not.
When to use this: on every project with more than one engineer, more than one service, or more than one way to get something wrong.
For larger changes, planning first is one of the highest-leverage habits you can build. Shift+Tab enters plan mode. Whether you use the hotkey or simply ask for a plan explicitly, the pattern matters: ask Claude Code to inspect the relevant files and produce a step-by-step implementation plan before it edits anything.
This is especially useful for refactors, debugging across modules, data pipeline changes and anything with side effects. A plan exposes whether the model has actually understood the shape of the task. It also gives you a natural pause point to challenge assumptions, trim risky steps and ask for missing tests. In practice, this often saves more time than letting it charge ahead and then untangling a half-right implementation.
When to use this: any change that touches multiple files, affects production behaviour, or depends on architecture rather than syntax.
You can use trigger phrases such as “think”, “think hard” and “ultrathink” to encourage deeper reasoning in Claude Code. Used selectively, this can help on tricky debugging, design trade-offs and awkward refactors where a shallow first pass is likely to miss something. The important word is selectively. More thinking can mean more latency, and depending on how you are using the wider Claude stack, potentially more cost as well.
It is also worth distinguishing this from the API feature usually described as extended thinking. In the API, extended thinking is a specific capability with its own budgeting trade-offs and output blocks. In Claude Code, asking it to think harder is more of an interaction pattern than an application architecture feature. Treat one as a prompting habit in the terminal, and the other as an explicit API decision when building products.
When to use this: hard bugs, ambiguous requirements and decisions you would not want to approve from a one-paragraph answer.
Skills are one of the most underused productivity features available. The key idea is that Skills load on demand rather than being dragged into every conversation. That makes them a good fit for task-specific expertise, such as “dbt migration reviewer”, “PR comment generator” or “Databricks job triage”. There is also a hierarchy across enterprise, personal, project and plugin skills, plus controls for allowed tools and model selection.
The best Skills follow progressive disclosure. Keep the main skill concise, with a descriptive name and description, then link to supporting files where needed. That preserves context window space while still giving the agent richer guidance when it needs it. A useful mental model is this: use CLAUDE.md for project-wide defaults, Skills for task-specific expertise, subagents when you need isolation or different tool access, and hooks when you want event-driven automation rather than request-driven behaviour.
When to use this: when you notice yourself pasting the same framing, checklist or review criteria more than twice.
Custom commands are a practical way to package common workflows. They live in .claude/commands/*.md and can be invoked as slash commands, with support for arguments. That makes them ideal for things like PR reviews, migration checklists, boilerplate test generation or drafting release notes from changed files.
The difference from Skills is subtle but important. Skills are about loading task-specific know-how when the request calls for it. Custom commands are about making frequent workflows fast and consistent to trigger. If a team regularly performs the same multi-step interaction, a command lowers friction and reduces variation.
When to use this: repeated team rituals or delivery tasks that follow a recognisable pattern.
Hooks are event-driven automation. PreToolUse and PostToolUse are two of the most useful lifecycle points, with configuration in .claude/settings.json (or .claude/settings.local.json for personal, uncommitted settings). That makes hooks a good fit for quality gates such as formatters, linters, tests, policy checks or guardrails around certain tools.
The caveat is scope. Hooks can become noisy, slow or counterproductive if they fire too often or on the wrong files. Scope them to the directories and tools that matter. Use permissions carefully. And keep the distinction clear: hooks are not Skills. Hooks fire because an event occurred. Skills load because the request requires them. Once you treat those as different mechanisms, the overall system becomes much easier to reason about.
When to use this: to enforce boring-but-important checks that humans forget under delivery pressure.
MCP matters because it gives AI tools a standard way to connect to external capabilities. Public MCP explainers describe it as a standard integration layer that lets clients connect to tools, data sources and services through a consistent interface, reducing one-off integrations and making reuse easier. In practice, that shows up through Playwright MCP for browser automation, GitHub interaction and custom server connections.
This is where security and permissions become real engineering concerns. Set explicit permissions for each MCP server, using .claude/settings.local.json for allow and deny lists. That is exactly the right instinct. An MCP server is useful because it can do things. That also makes it risky if you connect the wrong thing too broadly. It helps to remember the MCP distinction as well: tools are model-controlled, resources are app-controlled context, and prompts are user-controlled workflows. That is a useful lens for server design and for deciding what you expose.
When to use this: when the work requires browser access, repository actions, external systems or domain tools that a terminal-only assistant cannot reach alone.
This distinction is architectural, not cosmetic. Workflows are predefined sequences for known problems, while agents are given tools and expected to plan and act flexibly. Workflows are easier to test and evaluate because the steps are known. Agents are more flexible, but harder to instrument and validate consistently.
That trade-off matters in professional delivery. If you know the sequence in advance, for example “read files, generate migration summary, check tests, draft PR notes”, a workflow will usually be easier to maintain. If the task is open-ended, such as investigating a production issue across logs, code and documentation, an agent is often the better fit. The common mistake is to build an agent when a workflow would have been simpler and more reliable.
When to use this: default to workflows for known patterns; reach for agents when flexibility is genuinely worth the complexity.
This one belongs mainly to the Claude API, but it is useful even if you mostly live in Claude Code. The fundamentals here are clear, direct instructions, XML tags for separating instructions, context, examples and output requirements, and explicit controls such as max_tokens, stop_reason and stop_sequences. These are not just niceties. They are reliability tools. XML-like tags make boundaries clearer. stop_sequences can prevent unwanted trailing output. stop_reason tells you whether the model ended naturally, hit a tool-use turn, ran out of tokens or stopped on one of your provided sequences.
For application builders, that means fewer brittle parsing hacks and better observability when something fails. It also makes prompts easier to evaluate because the structure is visible rather than implied. Even if your team is using Claude Code day-to-day, these API habits carry over into how you phrase requests and how you think about controlled outputs.
When to use this: whenever you need machine-readable outputs, typed responses or predictable stopping behaviour.
Again, this is mostly API territory. Response streaming is a flow of events such as message start, content block start, content deltas and message stop. At the application level, that means faster perceived responsiveness and earlier feedback to users. Tool calling introduces blocks such as ToolUseBlock, plus server-side tool patterns such as ServerToolUseBlock and WebSearchToolResultBlock. Those names matter because they reflect that tool use is not a single blob of text. It is structured interaction you can inspect and route.
Prompt caching is one of the easiest wins for repeated long context. It relies on ephemeral cache control, repeated prefix matching and constraints such as minimum cached length and multiple breakpoints. You do not need to turn that into an API reference in your app, but you should know when it helps: long system prompts, repeated document context, repeated workflows and evaluation loops. Used well, it can reduce both latency and waste.
When to use this: interactive products, long-context applications and any system that repeatedly sends the same large prefix.
Citations are not only a research feature. They are a trust feature. The API supports citations for document-grounded answers, including metadata such as cited text, document index, document title and page numbers. That is exactly the kind of traceability that matters in client-facing work, regulated environments and internal knowledge tasks where “it sounds right” is not enough.
If you are producing summaries, recommendations or Q&A over supplied documents, citations can change the conversation from “do we trust the model?” to “can we verify the source?”. For professional delivery, that is a far more useful place to be.
When to use this: document Q&A, research synthesis, compliance-heavy outputs and anything a reviewer might challenge.
Evaluation should be a habit, not a final gate. There are three grader types: code graders, model graders and human graders. That is a useful practical framing. Code graders are programmatic checks. Model graders use a model to score or classify output quality. Human graders remain essential where judgement, correctness or risk cannot be reduced to a simple rule.
For delivery teams, this applies well beyond model prompts. Evaluate generated code, agent outputs, document answers, workflow reliability and failure modes. Planning, tool use and memory are all useful, but none of them replace a feedback loop. In production, the difference between a clever demo and a maintainable system is usually the quality of that loop.
When to use this: continuously rather than as a one-off, across generated code, agent outputs and workflow reliability, and above all before anything ships to production or reaches a client.
Claude Code becomes far more useful when you stop treating it like a chat window and start treating it like a configurable agentic development environment. Start with the foundations: /init, a solid CLAUDE.md, clear file targeting with @, and disciplined use of /compact and /clear. Then add planning, deeper thinking, Skills, custom commands, hooks and MCP servers as your usage matures. For application teams, layer in the API patterns that improve control and reliability: structured prompts, stop_sequences, streaming, tool calling, citations, prompt caching and evaluation.
The real win is not just speed. It is repeatability. The teams getting the most value from AI-assisted development are the ones designing for shared context, safe extensibility and measurable quality. That is where these features stop being tricks and start becoming delivery capability.