Steering Claude Code: The 7 Instruction Methods That Actually Matter

Most developers discover Claude Code through prompting. They open a terminal, type a request, and the AI codes. That’s fine — but it’s like hiring a senior engineer and only talking to them at the keyboard. You’re missing everything that makes a long-term working relationship actually work.

Anthropic just published a detailed breakdown of every method available to steer Claude Code’s behavior. There are seven of them. Each one controls a different dimension of how Claude understands and executes your work. Most developers I talk to are using one or two. That’s leaving a lot on the table.

Here’s the full picture — and when to reach for each.

The Three Dimensions That Actually Matter

Before listing the methods, it helps to understand what each one controls. Anthropic frames it around three axes:

When it loads into context — at startup, on demand, or when triggered by an event?
Compaction persistence — does it survive long sessions when Claude starts compressing context?
Authority level — how much weight does Claude give it relative to other instructions?

Miss these dimensions and you’ll wonder why Claude “forgot” your instructions mid-session, or why a skill you defined isn’t being applied. The seven methods exist because no single mechanism works well across all three.

Method 1: CLAUDE.md — The Always-On Memory Card

What it is: A Markdown file at the root of your project (or in .claude/) that Claude reads at the start of every session.

Authority: High but can drift. Claude treats CLAUDE.md as foundational project context, but in very long sessions it can deprioritize earlier system-level instructions as conversation history grows.

Best for: Persistent project facts, architectural conventions, library constraints, non-negotiable patterns.

# CLAUDE.md

## Stack
- Runtime: Bun + Node.js (NOT npm, NOT yarn)
- Database: Dexie.js for IndexedDB — always use liveQuery() for reactive data
- Testing: Vitest only

## Conventions
- All async functions must have explicit error handling
- Never use any (TypeScript strict mode is enforced)
- Fetch Dexie docs from https://dexie.org/llms.txt before any DB work

The trick with CLAUDE.md: treat it like a senior engineer’s onboarding doc, not a prompt. It should answer “what does this project expect from you?” not “do this specific thing.”

Nested CLAUDE.md files also work — put one in tests/ for testing conventions, one in src/db/ for schema rules. Claude discovers them when it reads files in that directory, keeping your main context lean until needed.

What it doesn’t solve: Long sessions where context compaction kicks in. If you’re running a multi-hour refactor, the tail of that session might treat your CLAUDE.md rules as lower priority than recent conversation context.

Method 2: Rules — Scoped Constraints

What they are: Individual constraint files that apply to specific contexts — particular file types, directories, or operations.

Authority: Higher persistence than CLAUDE.md in long sessions. Rules are designed to stay active through compaction.

Best for: Hard constraints that cannot be contextual. “Never write raw SQL in model files.” “Always validate schema before writing to disk.” “No console.log in production code.”

Rules are the guardrails. CLAUDE.md explains the project; rules enforce the boundaries.

The key difference: CLAUDE.md is ambient context. Rules are explicit constraints. If Claude is choosing between “be helpful” and “follow a rule,” the rule wins.

Method 3: Skills — Rich Capabilities with Auto-Discovery

What they are: Directories containing a capability definition (a SKILL.md or equivalent) plus supporting files — templates, scripts, reference docs, examples.

Authority: On-demand. Claude discovers skills from the .claude/skills/ directory and pulls them in when the task matches.

Best for: Reusable workflows with supporting assets. “Generate a blog post” isn’t just a prompt — it’s a procedure that might need templates, style guides, output formats, and scripted post-processing steps.

.claude/skills/
└── write-pr-description/
    ├── SKILL.md           # How to do the task
    ├── templates/
    │   └── pr-template.md # Standard PR format
    └── examples/
        └── good-pr.md     # What "good" looks like

The key insight with skills vs. slash commands: skills are for capabilities that need supporting files. If it’s just a saved prompt, use a slash command. If it needs templates, scripts, or reference materials it loads at execution time, that’s a skill.

Skills also auto-compose. Claude can discover and chain multiple skills for complex workflows without you explicitly orchestrating it.

Method 4: Subagents — Specialists with Their Own Context Window

What they are: Isolated Claude instances that run in their own context window, execute a delegated task, and return results to the main session.

Authority: Independent. The subagent operates within its own scope and returns structured output.

Best for: Work that would pollute your main context if done inline. Repository scanning, documentation fetching, test generation across large codebases, security audits.

This is arguably the most powerful method for serious engineering work. Here’s why:

In Claude Code’s plan mode, when you ask it to deeply explore a large codebase, it typically delegates that exploration to an Explore-style subagent. Your main context stays clean — you’re not burning tokens on thousands of lines of file reads. The subagent summarizes, and that summary comes back to you.

The practical pattern:

# .claude/commands/research.md
---
description: Research a problem using web and codebase exploration  
allowed-tools: Task, WebSearch, WebFetch, Grep, Glob, Read, Write
---

Research: $ARGUMENTS

Launch parallel subagents to:
1. Scan the relevant codebase sections
2. Fetch current library documentation
3. Check for recent issues/PRs on the topic

Return a structured summary of findings.

When you type /research how does our auth middleware work?, Claude spins up parallel subagents rather than doing everything in the main thread.

What subagents are not: They’re not long-running background processes. They execute, return results, and terminate. Think of them as function calls with their own context.

Method 5: Hooks — Event-Driven Automation

What they are: Code or scripts that run automatically when specific Claude Code events fire — before a file write, after a test run, when an edit is made to a specific path.

Authority: System-level. Hooks execute regardless of what Claude is doing in the conversation.

Best for: Enforcing quality gates, triggering downstream systems, logging, or transforming outputs automatically.

// .claude/hooks.json
{
  "before_write": [
    {
      "match": "**/*.ts",
      "command": "bun run typecheck --file $FILE"
    }
  ],
  "after_edit": [
    {
      "match": "src/**/*.ts",
      "command": "bun run lint --fix $FILE"
    }
  ]
}

Hooks are the most underused method. They let you attach your existing toolchain to Claude Code’s action stream. Instead of asking Claude to “make sure to run the linter after each edit,” just make the linter run automatically on every edit. The hook doesn’t negotiate.

The mental model: hooks are the CI/CD pipeline inside the agentic session.

Method 6: Output Styles — Response Formatting

What they are: Defined templates or style configurations that control how Claude formats its responses — structure, verbosity, code comment density, documentation format.

Authority: Medium. They shape the form of output but don’t change what Claude does.

Best for: Teams with specific documentation standards, codebases with enforced comment formats, or workflows where downstream tools parse Claude’s output.

If you’re generating code that goes directly into production review, having Claude output in a consistent format matters. If someone built a parser that ingests Claude’s explanations into a documentation system, output styles make that reliable.

The classic example: “Always include a summary table at the top of any analysis. Use JSDoc format for all function documentation. Keep inline comments under 80 characters.”

Method 7: System Prompt Appending — Maximum Authority

What it is: Direct addition to Claude’s system prompt, bypassing all other instruction layers.

Authority: Highest. This is the operator-level layer. Claude treats appended system prompt content as the most authoritative source of instruction.

Best for: Deployment-level requirements that cannot be overridden by project context, user preferences, or anything else. Security boundaries, compliance requirements, behavioral constraints that apply across the entire deployment.

This method is primarily for those running Claude Code in enterprise or team deployments where certain behaviors must be guaranteed regardless of what individual engineers put in their CLAUDE.md files or skills.

The Bundling Layer: Plugins

Anthropic notes one more mechanism worth calling out: plugins. A plugin bundles multiple methods together into a shareable, coherent unit. Skills + hooks + output styles + subagent configurations, packaged as a single installable thing.

.claude/plugins/
└── typescript-strict/
    ├── skills/...
    ├── hooks.json
    ├── output-style.md
    └── rules/...

If you’ve built a solid setup for a particular workflow — say, a TypeScript microservice development environment — plugins let you share that across teammates or projects without copying individual files around.

The Decision Guide

When should you reach for each method?

Need	Method
Project context that’s always available	CLAUDE.md
Hard constraint that can’t be forgotten	Rules
Reusable workflow with supporting files	Skills
Task that would pollute main context	Subagents
Automated quality gate or integration	Hooks
Consistent output format	Output Styles
Non-negotiable deployment requirement	System Prompt Append
Multiple methods to share across team	Plugin

The key insight is that these methods are designed to work together, not compete. CLAUDE.md gives Claude project awareness. Rules enforce boundaries. Skills handle complex workflows. Subagents handle context-heavy subtasks. Hooks enforce quality gates. Output styles standardize results. System prompt appending provides the ceiling.

Why This Matters for AI Engineering

The difference between a developer who prompts Claude and one who steers Claude is the difference between pair programming and having a configured team member.

Configuration is what makes AI systems reliable at scale. You can get good results from a good prompt. You get consistent results from a well-structured environment of instructions, constraints, and automation.

The teams I’ve seen get the most out of Claude Code aren’t the ones with the best prompts. They’re the ones who invested 30 minutes in a solid CLAUDE.md, defined two or three skills for their most common workflows, and wired a hook into their test runner. After that, they don’t think about it — Claude just works the way they expect.

The seven methods are Anthropic’s answer to a real engineering problem: how do you turn a capable but unstructured AI into something you can depend on in a production development workflow? The answer is layered, composable configuration with predictable authority.

That’s the architecture worth learning.

Anthropic published the full breakdown at claude.com/blog/steering-claude-code-skills-hooks-rules-subagents-and-more. Claude Code also gained Artifacts support this month — the ability to turn session work into live, shareable visual pages for team review. Worth exploring alongside the steering methods.