My Claude Code setup

Claude Code is the harness at the centre of NicAI. Out of the box, it knows nothing about me. Everything that makes it NicAI lives in configuration: instruction files, settings, hooks, memory and skills. This note describes each part, so you can copy what fits your own setup.

Instruction files in layers

Claude Code reads every CLAUDE.md from the global one down to the folder I work in, and combines them. I use that to split the rules by scope, 1 layer per file.

The more specific file adds detail and doesn't repeat the general one. The work file opens with where the other rules live, then: "This file owns KA-specific rules only."

When 2 rules collide, the files state the order in writing. For writing rules, clarity beats my own conventions, which beat the style guide, which beats the STE mechanics. For German text, correct German beats my voice.

The notes site sits outside ~/ai, so its rules don't load from the personal folder. The personal file points to ~/notes/CLAUDE.md for anything about the site. The layout itself is in The NicAI workspace.

Writing and communication rules

For how the agent talks to me, the global file stacks 3 standards: Zinsser's 4 principles set the goal, Google's developer documentation style sets the format, and Simplified Technical English (ASD-STE100) sets the mechanics. They govern chat only. Emails, decks and posts in my name follow my voice files, covered in The NicAI voice stack.

Output conventions

2 rules close every task:

• An artifacts list. Any task that creates files ends with the full paths of the deliverables, most important first. No build scripts, no temp files.
• A stats line. The last line of every answer shows the duration and an estimate of the tokens used.

The list saves me a search through a long answer. The stats line keeps the cost of each task in view.

Hooks

Hooks are shell commands that Claude Code runs at fixed points. The agent can't skip them, which makes them the right place for rules that must hold every time.

The client-notes guard shows the layers together. A deny rule blocks direct edits. The hook checks every write and shell command that touches the folder: new files and appends pass, overwrites and deletes don't. Its own header calls it a soft guardrail, since a path hidden in a variable can still slip through.

The publish hook has a gap I learnt the hard way: it fires on Write, not Edit. A new note publishes by itself, an edited one needs a manual publish. The pipeline is in The notes pipeline.

Auto-memory

Claude Code can keep memories: small Markdown files it writes when it learns something worth keeping. Each project folder under ~/.claude/projects/ has a memory/ folder with a MEMORY.md index, 1 line per memory, that loads at every session start. The agent opens a full memory only when its topic comes up.

Each memory has a type:

By default, each project gets its own store. Since 17th May 2026, 7 of my project folders point to 1 shared store through symlinks, so a lesson learnt in one applies in all. The personal folder keeps its own store of 15 memories, so home topics stay out of work sessions.

2 harmless examples: "always open the files you generate, so they pop up for review", and "any text output is .md, never .txt". Both started as a correction I typed once.

Permissions

The permission rules decide what the agent can do without asking:

• Global allow rules (131). Read anywhere, edit in ~/ai and ~/.claude, and a list of routine commands.
• Global deny rules (25). No edits to system folders, credential folders, my personal document folders or the client-notes folder. A deny rule wins over any allow rule.
• A sandbox on the workspace. In ~/ai, shell commands run in a sandbox that can write only inside the project.

The trade-off is prompts against speed. Parallel agents that stop to ask me lose most of their value, so I put the effort into hard limits, deny rules and hooks, instead of approving every step.

Skills, agents and connectors

• Skills. 59 work skills in ~/ai/ka/.claude/skills, 13 personal ones in ~/ai/me/.claude/skills, 4 global ones in ~/.claude/skills, and 1 in a lab project. Claude Code loads a skill only when a task matches its description. The skill design is in The NicAI skills catalogue.
• Sub-agents. The work and personal folders each define the agents for the review loop in The Council, plus a /council command to start it.
• MCP connectors. Connected: Apollo.io, Buffer, Gmail, Google Calendar and Claude Docs. Added but not signed in: Firecrawl, Google Drive and ZoomInfo. A local Perplexity server runs at user level, and a Google Forms server is set for 1 project.
• Status line. A small script shows the model, how full the context is, and how much of the 5-hour and weekly limits I've used.

What works

• Rules in files beat rules in prompts. I correct once, the fix lands in a CLAUDE.md or a memory, and every future session starts with it.
• Hooks for the must-haves. Anything that must happen every time, or must never happen, is a hook, not a sentence in a prompt.

What doesn't

• Duplication creeps in. The stats-line rule sits in both the global and the personal file. When one changes, the other drifts.
• Long files cost context. The global and work files add up to over 650 lines before I type a word. Every rule competes with the task for attention.
• Soft guardrails are soft. A hook that parses shell commands can't catch everything. For a hard guarantee, the operating system has to enforce it.

Related notes

• The overview: What is NicAI
• The folder layout and task queue: The NicAI workspace
• How the skills are built: The NicAI skills catalogue
• My writing voice: The NicAI voice stack
• How this site publishes: The notes pipeline
• Claude Code's own docs on memory and hooks