Stop Re-Explaining Yourself to Your AI Coding Tools

Most people use AI coding tools — Claude Code, Codex, Gemini CLI — like a chat window: open it, explain the project, explain how you like things done, get some work, close it. Tomorrow you open it again and explain all of it from scratch. It works, but you’re paying the same setup tax every single day, and the tool never seems to get any better at your projects specifically.

The fix isn’t a secret prompt or a bigger model. It’s a shift in how you think about what these tools are. Once it clicks, you stop repeating yourself, your day-to-day tasks start automating themselves, and the assistant behaves like it actually knows your codebase. This post is the mental model plus a concrete ladder of mechanisms, with examples that work across Claude, Codex, and Gemini.

What you’ll learn

By the end you should be able to:

Explain why an AI tool “starting from scratch every time” is inevitable — and what to do about it.
Pick the right mechanism for each kind of repetition: project rules, memory, commands, skills, hooks, or MCP.
Set up event-driven automation so routine checks happen without you asking.
Apply the same ideas across Claude Code, Codex, and Gemini CLI, and know which layer is truly portable.

The core insight: the model doesn’t remember — the filesystem does

Here is the thing nobody tells you up front. The model behind any of these tools begins every session with no memory of your past sessions. It cannot learn, in the neural sense, from yesterday’s chat. That sounds like a limitation, and it is — but it also tells you exactly what to do.

Aha moment: “Making the tool learn” doesn’t mean training the model. It means writing your knowledge into files the tool loads automatically, and promoting anything you’ve explained twice into a reusable asset. The tool doesn’t have a brain that remembers across sessions. It has a filesystem. Use it.

Every technique below is just a different kind of file or config that the tool reads on startup. Getting efficient is mostly one habit: noticing repetition and moving it down to the right layer. Here’s the ladder, lightest to heaviest.

Layer 1: Project rules — the file loaded every session

The single highest-leverage file is the one your tool reads into context on every run, for a given repo:

Claude Code reads CLAUDE.md.
Codex reads AGENTS.md (now a cross-tool convention).
Gemini CLI reads GEMINI.md.

This is where the durable, non-obvious truths about your project live: the commands that matter, the one weird build step, the convention a newcomer would get wrong. “There’s no test command, only a pre-commit validator.” “Escape \$ inside diagram labels.” That kind of thing. Concretely: if you catch yourself re-explaining “use npm run build; there’s no test suite, just the pre-commit validator” at the start of every session, that’s the signal — write it here once and never type it again.

Term to know: A context file is a markdown file the tool injects into every session for a project. It’s persistent, project-scoped memory you author by hand — the opposite of re-typing your conventions each morning.

Two disciplines make or break it:

Keep it tight. Everything in this file gets fed to the model on every turn, and the model can only hold so much text at once — its context window. A bloated file crowds out the actual task (and can cost more per request). It’s not a wiki: only put in what’s durable and not obvious from reading one file.
Avoid drift across tools. If you run multiple assistants, you don’t want three diverging copies. Two good options: keep one canonical file and have the others import it, or symlink them. Gemini, for instance, lets GEMINI.md pull in another file:
```
# GEMINI.md
@AGENTS.md
```
Now Gemini reads the exact same conventions as Codex, and you maintain one source.

Layer 2: Memory — facts that accumulate

Separate from the hand-authored context file, some tools keep a memory store: facts captured during conversation that should survive to the next one. The distinction:

The context file is what you deliberately write down.
Memory is what the tool learns about you and saves — “prefers cheaper models,” “ships this series weekly,” “hates emoji in commits.”

The payoff is you stop re-establishing who you are and what you want. When you tell the assistant something it’ll need again, ask it to remember (in Claude Code, a line starting with # quick-saves). This is the most direct cure for “starting from scratch.” Where it earns its keep: the tool keeps reaching for the priciest model after you’ve twice said you watch costs — have it save “default to the cheap model unless I ask” once, and the nagging stops.

Layer 3: Slash commands — a saved prompt

When you catch yourself typing the same instruction repeatedly, promote it to a command. A slash command is just a file containing a prompt, invoked by name.

Tool	Where	Invoke
Claude Code	`.claude/commands/<name>.md`	`/<name>`
Gemini CLI	`.gemini/commands/<name>.toml`	`/<name>`
Codex	`~/.codex/prompts/<name>.md`	`/<name>`

They take arguments ($ARGUMENTS / {{args}}), so they’re parameterized. A blog-writer might have a /new-post command that encodes the whole house style — frontmatter schema, required sections, “always start as a draft” — so a single line replaces a paragraph of instructions. Another everyday one: you keep asking for “a conventional-commit message for the staged changes” — that’s a five-second /commit-msg command you’ll reach for daily.

Aha moment: The first time you explain something, just explain it. The second time, stop and promote it. That one reflex — “I’ve said this before, where does it belong?” — is most of what separates a power user from someone re-typing context forever.

Layer 4: Skills — a procedure, not just a prompt

The upgrade from a command: a command is a prompt; a skill is a prompt plus its own reference docs, templates, and scripts that load only when relevant. Reach for a skill when the task has steps and conventions worth bundling, or helper code worth shipping alongside the instructions. For example, a release skill might bundle the step-by-step checklist, a changelog template, and a script that bumps the version and tags the commit — and the tool pulls all of that in only when you actually start a release, not on every unrelated request.

Skills are also where the ecosystem is converging — OpenAI now recommends skills over custom prompts for reusable instructions in Codex, and Claude Code skills work the same way. They keep your everyday context lean because the tool only pulls a skill’s details in when the work calls for it.

Layer 5: Hooks — automate the routine

This is the layer most people never reach, and it’s the one that makes daily work feel automated. A hook is a shell command that the tool itself — not the AI model — runs automatically on an event. Because plain code runs it rather than the model choosing to, it always happens.

Claude Code fires hooks on events like PostToolUse (after an edit), Stop (when the assistant finishes), and SessionStart. A few that pay for themselves immediately:

After any edit to a content file → run your validator, so format errors surface the instant you save.
After the assistant finishes → run the build and ping you if it broke.
After an edit → auto-format with prettier.

Term to know: A hook turns “please remember to validate every time” into “the system validates every time, whether or not anyone remembers.” It’s the difference between a habit and a guarantee.

Notice that every example so far reacts to something the assistant did. But hooks also fire on your input — Claude Code’s UserPromptSubmit runs the moment you hit enter, before the model sees your message. That unlocks a slightly meta use: making the system nudge you toward the very commands and skills you built.

The failure mode is familiar. You spend an afternoon creating a /new-post command, use it twice, then a week later absent-mindedly type “hey, can you write up a post about X” and do the whole thing by hand again. A UserPromptSubmit hook fixes that: point it at a small script with a rules table — “if the prompt looks like a blog request and isn’t already /new-post, remind me it exists” — and the assistant surfaces the command before you waste the effort. Covering a new skill is one more line in the table.

Aha moment: The hooks you reach for first react to the model — validate its edits, build its output. The ones you’ll come to value most react to you. Externalizing your knowledge into commands and skills is wasted effort if you forget to reach for them; a UserPromptSubmit nudge turns “I built these shortcuts and never use them” into a loop that closes itself.

The catch worth knowing: Claude Code has rich edit-time hooks; Codex and Gemini don’t (yet) in the same form. Which is exactly why the most portable automation doesn’t live inside any assistant at all —

The portable layer: git hooks and scripts

If you only take one automation idea away, take this. A git pre-commit hook that runs your checks fires no matter which tool — or which human — made the change. A plain script (validate.mjs, lint.sh) that all your assistants are told to run is a single source of truth they can each call.

Aha moment: Tool-specific features are nice, but the automation that survives switching assistants lives in git and scripts, not in Claude or Codex or Gemini. Build the portable layer first; let each tool’s native hooks be a convenience on top.

This is the trick to staying tool-agnostic (working the same way no matter which assistant you use). Your conventions live in a shared context file, your checks live in scripts, and your safety net lives in git. Any assistant you point at the repo inherits all of it.

Layer 6: MCP servers — connecting the outside world

Everything so far lives in files inside your repo. The last rung of the ladder reaches outside it. MCP is a standard way to plug external systems into your assistant as tools it can call directly: your database, GitHub, a Slack workspace, your calendar, an internal API.

Term to know: MCP (Model Context Protocol) is like a universal adapter for AI tools. Instead of you copy-pasting data into the chat, you connect an MCP server once and the model can fetch or act on that system itself — read a ticket, query the database, open a pull request.

Two practical notes for when you get here: connect servers deliberately (each one adds tools the model has to weigh on every turn), and prefer a command-line tool you already have when one exists — running gh for GitHub is often simpler than wiring up a whole server. MCP earns its keep for login-protected or stateful systems you reach for a lot.

Commands you already have: the built-in toolkit

The ladder so far is about commands and skills you create. But every one of these tools also ships a set of built-in commands out of the box — and most people never learn past the first one or two. The names differ across Claude, Codex, and Gemini, but the categories are the same. The ones worth knowing, grouped by what they’re for:

Context management. Start a fresh conversation, or compress a long one when it starts to wander. A bloated conversation is slower, costs more, and quietly gets worse at the task. When you’d reach for it: you’ve spent an hour debugging a flaky test and now want to build an unrelated feature — clear the conversation first, or the model keeps dragging the debugging context into the new work.
Project onboarding. Point the tool at a repo and have it generate a first draft of the context file by reading the code. When you’d reach for it: you clone an unfamiliar codebase and run the onboarding command — a minute later you have a CLAUDE.md / AGENTS.md describing the build, the test command, and the layout, instead of writing it from a blank page.
Planning before editing. Ask the tool to lay out its approach and wait for your approval before it touches any files. When you’d reach for it: “migrate this module from REST to gRPC” — have it produce a step-by-step plan first, so you can correct the direction before it rewrites ten files the wrong way.
Code review. Have the assistant review your current changes for bugs and cleanups before you commit. When you’d reach for it: right before opening a PR, run it on your diff to catch the off-by-one or the missing error check while it’s still cheap to fix.
Delegation. Spin up scoped helper agents for a self-contained chunk of work, so it doesn’t clutter your main conversation and you can run things in parallel. When you’d reach for it: “find every place we still call the old payments API” — hand that search to a sub-agent so the results don’t flood your main thread, and keep working while it digs.
Config and models. Switch models or settings on the fly. When you’d reach for it: draft boilerplate or rename variables with a fast, cheap model, then switch to the top-tier one only when you hit a genuinely hard design problem.

Aha moment: The highest-leverage built-in is the most boring one: clearing or compacting the conversation. Treat context like a workbench, not a diary — wipe it between unrelated tasks. Nearly every “the tool got dumber halfway through” complaint is really a context that grew too long and noisy.

A worked example

To make it concrete, here’s a single workflow — “draft a new blog post correctly” — implemented across all three layers in one small repo:

Shared foundation: a validate-posts.mjs script, run by a git pre-commit hook. Works for every tool and for manual commits.
Per-tool command: /new-post defined three times — .claude/commands/new-post.md, .gemini/commands/new-post.toml, ~/.codex/prompts/new-post.md — all encoding the same recipe.
Context files: CLAUDE.md and AGENTS.md, with GEMINI.md importing AGENTS.md so there’s one canonical set of conventions.
Edit-time hook (Claude): a PostToolUse hook that re-runs the validator the moment a post is edited.

The setup cost is an afternoon and one restart of each tool (commands and hooks load at startup). After that, “write a post the right way” is a single command in whichever tool you happen to be in, and the format can’t silently break.

What’s new in 2026 (and why it reinforces all of this)

Two trends in the latest releases push hard in the same direction as everything above.

The unit of work is getting bigger. The flagship tools moved from “answer my prompt” to “pursue this objective in the background.” Claude Code’s workflows let it write a step-by-step plan and run it across many background sub-agents (helper copies of the AI it spawns to work in parallel) for a job too big for one conversation — a codebase-wide audit, a large migration. Codex’s Goal Mode drives toward an objective for hours or even days. You’re no longer chatting; you’re delegating a mission. And a mission needs the project’s rules, scripts, and guardrails to already be on disk — an agent running unattended for an hour can’t stop to ask you how you like things done.

The unit of reuse is getting more portable. Skills have graduated from personal config files only you had (dotfiles) into shared files committed to the repo and reviewed like code that travel with the codebase — so every contributor (and every agent) inherits the conventions with no setup step. Gemini went furthest, bundling prompts, MCP servers, commands, hooks, sub-agents, and skills into a single installable extension.

Aha moment: Both trends are the thesis of this post, accelerated. Longer-horizon autonomy raises the cost of not having externalized your knowledge, and portable skills/extensions are just the mature form of “turn repetition into a committed asset.” The tools are racing to make the filesystem layer first-class — which means the habit pays off more every release, not less.

What to take away

The model doesn’t remember; the filesystem does. Everything else follows from this. Externalize knowledge into files the tool auto-loads.
Match the layer to the repetition. Durable rule → context file. Learned fact → memory. Repeated prompt → command. Repeated procedure + files → skill. “Do it automatically on an event” → hook. External system → MCP.
Notice the second time. The reflex of promoting anything you’ve explained twice is the whole game.
Build the portable layer first. Shared context files, scripts, and git hooks outlive any single assistant; let each tool’s native features sit on top.

Do this and the daily setup tax disappears. The tool stops feeling like a forgetful intern you re-brief every morning and starts feeling like it actually works here — because, in the only sense that matters, you taught it to.