Most Claude Code advice is about prompting.

I've found the leverage is somewhere else: the config layer. The files that tell Claude Code how to behave before you ask it to do anything.

After six months of daily Claude Code use across Python API projects, data pipelines, and agent builds, here are the config files I actually use — and what each one does.

The CLAUDE.md problem

A blank CLAUDE.md is worse than no CLAUDE.md.

I tried the "just dump your stack into it" approach first. Claude Code read it and mostly ignored the parts that mattered. The problem: CLAUDE.md needs to tell Claude Code what to do and what not to do — not just what your stack is.

The structure that works for me:

## Stack [versions + tools — so it doesn't guess]

## Project structure [directory layout — so it knows where things belong]

## Conventions [the rules that aren't obvious from the code]

## What to do when [common task] [explicit workflow — the thing you'd tell a new dev on day one]

## What to avoid [the list of things…