Dynamic Starting Context

The context a session needs depends on the task. Writing a blog post pulls in brand voice and SEO workflows. Shipping a feature wants architecture notes and the house coding style. Debugging asks for system diagrams plus whatever error-handling rules apply.

You could dump every one of those into CLAUDE.md and hope Claude picks out what matters. Or you could hand each session type the context built for it.

The Simple Solution

A prompt goes right after the --init flag on Claude Code:

claude --init "/blog"

Claude boots and the /blog slash command fires immediately. Whatever a blog session needs lives inside that command: writing rules, content workflow, sample posts, links to follow internally.

Zero setup hooks. Zero env vars. Zero file copying. One command file, holding the context.

This page is about starting a session with the right bundle, not about managing a bloated session after the fact. If you are trying to decide what Claude should see, when it should see it, and what should stay out of the window, read Context Engineering. If you are trying to recover a drifting session, read Context Management. For hook-heavy automation, read Claude Code Hooks.

When Setup Hooks Are Overkill

Setup hooks shipped on January 25th, 2026. Their job is to blend deterministic scripts with agentic oversight: dependency installs, database initialization, routine maintenance work.

For plain context loading on a per-session-type basis, though, setup hooks drag in machinery you can skip. A slash command reaches the same finish line with fewer moving parts.

Our Implementation

Here is the layout we use for blog writing sessions:

.claude/
  commands/
    blog.md     # Context embedded in command
justfile        # Launcher shortcuts

Everything a blog session asks for lives inside blog.md: voice guide, workflow notes, tier-loading instructions, SEO checks, rules for linking between posts.

The justfile gives the shortcut:

blog:
    claude --init "/blog"

Type just blog and Claude comes up with the blog context already in memory. Voice is set. Linking rules are set. The workflow runs itself without any prompting from you.

What Goes in a Context Command

A strong session command covers four bases:

Startup message: Name the session type out loud and confirm that context is now loaded.

Workflow documentation: Each step of the process for this flavor of work.

Reference material: Every rule, sample, and checklist that applies across the whole session.

Quality gates: What must be true before you call the work finished.

The template:

---
description: Start a blog writing session with pre-loaded context
---
 
# Blog Session
 
You are starting a blog/content writing session. Report: "Blog session started."
 
---
 
## Content Workflow
 
[Workflow steps and process documentation]
 
## Brand Voice
 
[Guidelines and patterns]
 
## Quality Checklist
 
[Verification steps before publishing]

Everything lives inline. Run the command and Claude already holds every piece.

Multiple Session Types

One command per mode of work:

.claude/commands/
  blog.md       # Blog writing context
  feature.md    # Feature development context
  debug.md      # Debugging context
  review.md     # Code review context

Each carries its own rules, workflow, and reference set. Switching modes takes a single word:

just blog     # Blog writing
just feature  # Feature development
just debug    # Debugging session

Four Session Commands Worth Copying

The pattern becomes more useful once you stop thinking in abstractions and start naming real session types.

Blog session

claude --init "/blog"

Load:

• brand voice
• internal linking rules
• SEO / GEO checklist
• publishing workflow

Feature session

claude --init "/feature"

Load:

• architecture notes
• coding standards
• test expectations
• release constraints

Debug session

claude --init "/debug"

Load:

• debugging workflow
• logging locations
• reproduction checklist
• rollback safety rules

Review session

claude --init "/review"

Load:

• review rubric
• severity definitions
• what counts as a blocker
• expected output format

That is the big win. You are not just saving keystrokes. You are making each session type start with the right frame of mind.

What Belongs Where

The cleanest setups split context by permanence:

That separation is what keeps the system usable. If everything ends up in CLAUDE.md, every session starts bloated. If everything ends up in hooks, simple context loading becomes heavier than it needs to be.

The Main Anti-Pattern

The common mistake is trying to solve every context problem with one giant base file.

That usually leads to:

• oversized CLAUDE.md files
• mixed workflows jammed together
• irrelevant instructions loading for every task
• weaker focus at session start

Dynamic starting context fixes that by making the session-specific rules explicit and temporary. The blog session gets blog rules. The debugging session gets debugging rules. Nothing else comes along for free.

Why This Works

Whatever command you hand to --init runs before you type a thing. By your first message, the context is already sitting in Claude's head. No "read these files first" opener. Straight into the work.

For skills, the same trick loads the right skill configuration on its own. For CLAUDE.md overrides, you get session-specific rules without polluting your base file.

Keep it simple at the start. The day you need deterministic scripts, install automation, or agentic oversight during startup, graduate to setup hooks. Until then, a slash command usually does the trick. ClaudeFast's Code Kit runs this exact pattern. Its /blog, /team-plan, and /build commands each pull in session-specific context, workflows, and quality gates through one --init call.