Claude Code Best Practice Guide

The Power-ups feature provides 10 specific lessons covering advanced Claude Code capabilities:

1. Talk to your codebase: Using @ files and line references.
2. Steer with modes: Using shift+tab to switch between plan and auto modes.
3. Undo anything: Using /rewind or Esc-Esc to revert changes.
4. Run in the background: Managing tasks via /tasks.
5. Teach Claude your rules: Using CLAUDE.md and /memory to persist instructions.
6. Extend with tools: Using MCP (Model Context Protocol) via /mcp.
7. Automate your workflow: Using skills and hooks.
8. Multiply yourself: Using subagents via /agents.
9. Code from anywhere: Using /remote-control and /teleport.
10. Dial the model: Using /model and /effort to control model selection and reasoning depth.

Claude's advanced tool use features (GA as of February 18, 2026) are designed to reduce token consumption, decrease latency, and improve tool accuracy.

Strategic Layering Recommendation:

• If facing context bloat from tool definitions: Use the Tool Search Tool.
• If facing large intermediate results: Use Programmatic Tool Calling (PTC).
• If facing web search noise: Use Dynamic Filtering.
• If facing parameter errors: Use Tool Use Examples.

Sand Castle is a TypeScript library designed for running AI agents

// Conceptual usage of Sand Castle workflow
// 1. Planner selects issues from a backlog
// 2. For each issue, create a sandbox and run an implementer
// 3. Review the resulting commits
// 4. Pass commits to a merger agent to merge branches and fix type/test errors

The RPI Workflow is a systematic development methodology based on three distinct phases: Research → Plan → Implement. It uses validation gates at each phase to prevent wasted effort on non-viable features and ensures that comprehensive documentation is generated alongside the code.

Each feature follows a specific lifecycle:

1. Describe: Define the initial requirement.
2. Research: Analyze feasibility and strategic alignment (resulting in a GO/NO-GO verdict).
3. Plan: Create detailed user stories, UX flows, and technical architecture.
4. Implement: Execute the technical tasks in phases.

When a user provides an instruction that matches multiple extension mechanisms (e.g., a Skill and an Agent), Claude prefers the lightest-weight option that satisfies the request:

1. Skill: Preferred because it runs inline with no context overhead.
2. Agent: Used if a skill is unavailable or if the task is complex enough to require an autonomous, separate context.
3. Command: Only used if the user explicitly types the /command-name.

Note: If a skill has disable-model-invocation: true, Claude will skip it and move to the next available option (like an Agent) or fall back to general knowledge.

You can extend Claude Code's capabilities by integrating other models (such as Codex, Gemini, GPT, DeepSeek, or local models) using three primary architectural mechanisms:

1. Plugin: Runs another model's CLI directly inside Claude Code using slash commands (e.g., /codex:review).
2. MCP (Model Context Protocol): Allows Claude Code to call another model as a tool via an MCP server.
3. Router: Swaps Claude Code's underlying API endpoint to a different provider, allowing you to use different models for the main Claude Code session.

For a specific implementation example, see the Cross-Model (Claude Code + Codex) Workflow, which uses a manual two-terminal flow where Claude handles the 'Plan' and Codex handles the 'QA-Review'.

MCP servers use different transport methods depending on whether they are local processes or remote services:

• stdio: Spawns a local process. Common commands include npx, python, or direct binary execution.
• http: Connects to a remote URL using HTTP/SSE endpoints.

When using http type servers, use environment variable expansion for secrets (e.g., ${MCP_API_TOKEN}) instead of hardcoding API keys in your configuration files.

{
  "mcpServers": {
    "remote-api": {
      "type": "http",
      "url": "https://mcp.example.com/mcp?token=${MCP_API_TOKEN}"
    }
  }
}

Choose the right MCP based on your primary goal:

• Playwright MCP: Best for E2E Test Automation. Features cross-browser support (Chromium, Firefox, WebKit), high token efficiency (~13.7k tokens), and reliable accessibility tree selectors. Ideal for CI/CD.
• Chrome DevTools MCP: Best for Performance & Debugging. Features deep network inspection, performance traces, and console log access. Limited to Chrome only.
• Claude in Chrome: Best for Manual/Exploratory Testing. Uses your actual browser session (cookies/logins) and visual context. Not suitable for CI/CD.

A sub-agent is a delegated LLM instance with an isolated context window. In workflows like the grill me skill or exploration phases, the orchestrator (parent agent) delegates heavy lifting—such as exploring a large codebase—to a sub-agent.

Key characteristics:

• Delegation: The sub-agent performs intensive tasks (e.g., searching, reading files, summarizing).
• Drip-feeding: Instead of returning the entire raw exploration, the sub-agent reports a summary back to the parent agent.
• Token Efficiency: While a sub-agent might consume a large number of tokens (e.g., 90k+ tokens on a model like Opus) to perform its task, the parent agent's context remains relatively clean because it only receives the summarized results, preventing the user's primary context window from being flooded with irrelevant data.

Agents and Skills are separate abstractions designed for reusability and precision:

• Agents represent the role (the 'who'). An agent is a persona with a job description that ensures a consistent approach to a task.
• Skills represent the capability (the 'how'). A skill contains the exact technical instructions, such as specific API URLs to call or specific fields to extract from a response.

Relationship Pattern:

• One agent can have multiple skills: A daily-report-agent might use a weather-fetcher skill, a calendar-reader skill, and an email-summarizer skill.
• One skill can be used by multiple agents: A single weather-fetcher skill can be utilized by both a weather-agent and a daily-report-agent.

In Mixture-of-Experts (MoE) architectures, a learned router activates only a subset of model parameters ('experts') for each input.

The Batching Problem: Because inference is often batched, the specific composition of a batch (the mix of queries from different users) can determine which experts your specific query is routed to. This creates non-deterministic results where the same model can produce different quality outputs on different days purely due to infrastructure routing, even without software bugs.

When designing products with LLMs, avoid the pattern of 'putting the model in a box' where the application dictates a single component for the model to perform.

Instead, use the inverted approach:

• Treat the model as the product.
• Provide minimal scaffolding around the model.
• Provide a minimal set of tools.
• Allow the model to decide which tools to run and in what order.

This approach aligns with the concept of being 'on distribution'—observing what the model is naturally attempting to do and facilitating those actions.