Skip to content
← Tools

Claude Code

Building and operating the stack

An AI coding agent that runs in the terminal. It reads and edits files in a repository, runs commands, and follows written instructions committed alongside the code.

Claude Code is where most of my building happens now. Not only writing code: running the operations too. The scripts that push leads, the audits that read a campaign back, the checks that run before a send. It sits in the same repository as the work, which is the whole reason it is useful.

How I use it

Rules are files, not habits. Everything I want repeated lives in markdown in the repo: how to name a file, what has to be verified before a claim, what may never be deleted. A correction I have to give twice is a bug in the written rules, so it gets written down instead of repeated. The instructions load themselves at the start of a session, so the standard is the same on a good day and a tired one.

Verification is a rule, not a hope. The single most valuable line in my setup is that a claim needs evidence from this run. Not “should work”, not “looks right”. Run the command, show the output, then say it. An agent that reports progress optimistically is worse than no agent, because you stop checking.

Subagents for anything verbose. Web scraping, reading through fifty files, long API output. It runs in a separate session and comes back with the answer, so the main conversation stays about the work and not about the noise of getting to it.

Skills for the things I do repeatedly. A campaign audit or a table build has a procedure. Written once as a skill, it is loaded on demand instead of explained again, and it gets better every time it fails.

What I have learned the hard way

Instruction files stack upward, and there is no nesting escape. The instructions from your working folder, its parent, and every folder above it are all loaded together. So a subfolder cannot have its own smaller loadout. The only real isolation boundary is a separate repository, which is worth knowing before you spend an afternoon reorganising folders to get a clean context.

Settings behave differently from everything else. Skills, agents and instructions are inherited from parents. Settings are read only from the directory you launched in. Two of those rules are the same and one is the opposite, which is exactly the kind of asymmetry you discover by being confused.

The context window is the real budget. A long session is a lossy one, because what gets summarised away is usually the detail you needed. I keep durable state in files and compact deliberately, rather than letting a session run until it forgets its own first hour.

It is confidently wrong in a specific way: it reports the state it expects rather than the state it read. Nothing errors when a claim is false, so the fix is structural. Read the actual source before saying the thing, and check all of it rather than one convenient sample.

Resources

This is one part of a stack. The rest is on the tools page, and what I build with it is on work.

tools/claude-code.md
---
tool: Claude Code
role: Building and operating the stack
category: Building
url: https://mihajlomaiga.com/tools/claude-code
---

# Claude Code
An AI coding agent that runs in the terminal. It reads and edits files in a repository, runs commands, and follows written instructions committed alongside the code.
Claude Code is where most of my building happens now. Not only writing code:
running the operations too. The scripts that push leads, the audits that read a
campaign back, the checks that run before a send. It sits in the same repository
as the work, which is the whole reason it is useful.

## How I use it

**Rules are files, not habits.** Everything I want repeated lives in markdown in
the repo: how to name a file, what has to be verified before a claim, what may
never be deleted. A correction I have to give twice is a bug in the written rules,
so it gets written down instead of repeated. The instructions load themselves at
the start of a session, so the standard is the same on a good day and a tired one.

**Verification is a rule, not a hope.** The single most valuable line in my setup
is that a claim needs evidence from this run. Not "should work", not "looks
right". Run the command, show the output, then say it. An agent that reports
progress optimistically is worse than no agent, because you stop checking.

**Subagents for anything verbose.** Web scraping, reading through fifty files,
long API output. It runs in a separate session and comes back with the answer, so
the main conversation stays about the work and not about the noise of getting to
it.

**Skills for the things I do repeatedly.** A campaign audit or a table build has a
procedure. Written once as a skill, it is loaded on demand instead of explained
again, and it gets better every time it fails.

## What I have learned the hard way

**Instruction files stack upward, and there is no nesting escape.** The
instructions from your working folder, its parent, and every folder above it are
all loaded together. So a subfolder cannot have its own smaller loadout. The only
real isolation boundary is a separate repository, which is worth knowing before
you spend an afternoon reorganising folders to get a clean context.

**Settings behave differently from everything else.** Skills, agents and
instructions are inherited from parents. Settings are read only from the directory
you launched in. Two of those rules are the same and one is the opposite, which is
exactly the kind of asymmetry you discover by being confused.

**The context window is the real budget.** A long session is a lossy one, because
what gets summarised away is usually the detail you needed. I keep durable state in
files and compact deliberately, rather than letting a session run until it forgets
its own first hour.

**It is confidently wrong in a specific way:** it reports the state it expects
rather than the state it read. Nothing errors when a claim is false, so the fix is
structural. Read the actual source before saying the thing, and check all of it
rather than one convenient sample.
## Resources
- [Claude Code](https://claude.com/product/claude-code)
- [Documentation](https://docs.claude.com/en/docs/claude-code/overview)